Archive for January, 2013


January 18, 2013 Leave a comment

I’ve been doing a lot of soul searching lately. There have been a lot of changes recently. Some for the better and some for the worse. While watching the video below, I nearly jumped out of my seat a few times because of the deja vu moments.

The two presenters are highly entertaining to watch. Although the title may be a little sensational, I still think the video promotes important messages. I’m sure a lot of people recognize the topics they discuss, but it’s still good to hear someone else talk about it openly. There are numerous topics in this video that resonate with me.

This is a 10 minute video about what motivates people. It’s an interesting video to watch, but I would take it with a grain of salt. There’s actually an entire book about this. The examples they use may or may not correlate to what happens in an actual work environment. While it may work for a subset of people, this certainly isn’t something that would work for everyone. However, I do agree with the three factors they discuss that lead to better performance and personal satisfaction:

  • Autonomy
  • Mastery
  • Purpose

This last video is John Carmack’s keynote at QuakeCon 2011. John Carmack is a brilliant programmer and is an inspiration to me. Just listening to him talk motivates me to go try and build something great.


January 16, 2013 1 comment

I was speaking with my manager recently and the conversation derailed a bit. Somehow we ended up discussing what I consider a good manager. In the past five years, I’ve reported to seven different people, each possessing their own unique traits that I respect. There are articles all over the web that lists the ideal traits of a manager. Just to list a few:

  • Empower your team and don’t micromanage.
  • Communicate well and listen to your team.
  • Encourage professional development.
  • etc…

However, I consider two things of utmost importance above all else:

If a manager promises my team something, then backtracks without discussing it with us, I will forever look at that manager differently. There is nothing that will demotivate me faster than working for someone I can’t trust.

To quote the fair process page:

  • Engagement. Involve individuals in the decisions that involve them. Get their input, allow them to actively PeerReview the ideas on the table. Respect individuals for their ideas.
  • Explanation. Everyone involved and affected must understand the reason why the decisions were made. Demonstrating the rationale behind decisions shows people that you have considered their opinions thoughtfully and impartially. Not only will this make people trust the decision maker but it will help them learn.
  • Expectation clarity. Once a decision is made, clearly specify the expectations for the people involved, what responsibilities they have. Even if the expectations are demanding, people want to know by what standards they will be judged and what penalties there will be for failure. Understanding what to do reduces useless political maneuvering and it allows people to focus on the task at hand.

Fair process goes hand in hand with trust. If decisions are being made without input from my team, I feel completely disengaged with the task in hand. If my manager cannot trust me enough to value my input, why should I go above and beyond for them?

For the managers I’ve worked with that employed fair process, it was an absolute pleasure working with them. I was committed and motivated to get the task done because I felt like I had a stake in the result.

A lot of the traits that I value can be found in the book Peopleware. Just like how the agile manifesto states, software development is more than just processes. If you value processes over people, you’re probably a bad manager.

User stories, features, and epics

January 10, 2013 1 comment

There have been a lot of discussions in my team recently about the definitions of a user story, feature, and epic. I’m by no means an agile expert, so this is just my opinion and interpretation. I’m the type of person who trusts their intuition, so the way we’re currently forced to group our requirements feels extremely awkward to me.

Currently every user story that is created must be grouped under a feature. All features must be grouped under an epic. By the way I’ve described things so far, it appears there is a hierarchical structure that must always exist: Epic -> Feature -> User story.

To be honest, I hate this. I don’t like it at all. If a user story is small enough to implement on its own, why do I need to bother creating a feature or epic? This screams process over pragmatism. If we’re forced to always create features and epics, they are no longer features that describe how a system works. Instead, we’re using them as categories or buckets of work.

After reading multiple articles around the web, I found this article by Mike Cohn that contains a very simple and concise definition for each.

To me, a user story is a requirement that can stand on its own. It doesn’t need to be grouped under a feature or epic. If a user story is too large but not large enough to be considered an epic, it may be broken down into “tasks” that will eventually be absorbed back into the user story after completion. Many people have the opinion that a user story should be sliced into multiple smaller stories instead of tasks. I disagree because that story will be sliced to the point where it doesn’t provide any business value on its own. Instead, they become system or technical stories. A user story should be something that delivers business value on its own.

If a user story may be broken down into multiple smaller stories that can provide business value on its own, then it may be considered an epic. I really like the way Mike Cohn described themes, or what we would consider features. They are simply a “rubber band” around a collection related of user stories. There isn’t a hierarchy between a feature and epic. Since a feature is simply a collection of related stories, there are times when a feature may be larger than an epic or vice versa.

Neither epics nor features are required. If a requirement is small enough to fit inside a single user story, then that is all there needs to be.

Again, I’m not an agile expert, so this is just my opinion and interpretation.

Team discipline over forced processes

January 8, 2013 1 comment

I always strive for my team to be as autonomous as possible. The best way for a team to perform well is to have the responsibility to decide how they work. The process should work for the team, not the other way around.

It really irritates me when I see agile zealots blindly following their step-by-step checklist. For example, some people have forgotten who our customers are. As a developer, my customer is the business. A typical agile zealot will value processes over business value. If it goes against their prescribed set of agile processes, the business must be wrong and we have set them straight right? Absolutely ridiculous.

“But that’s not Scrum”. Well guess what? I don’t care because no process is perfect. The process is not more important than the customer’s satisfaction. These agile zealots always claim to care about people and results more than processes, but they will interject if you don’t follow their checklist to the letter.

Great teams should always have the power to decide how they work, because ultimately they will be responsible for the outcome. Mistakes will be made, but it’s part of the learning process. At the same time, I’m not saying that once a process has been decided upon that it needs to be written in stone. A disciplined team will fine tune their workflow as the project progresses.