Malvin Ly

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.

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:

• Honor your commitments (trust)
• Fair process

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.

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.

If I were a consultant or if I were working for a consulting firm that charged clients per hour of work, I would see why logging hours spent on a task is necessary and important.

If I am a salaried employee working 40 hours a week, the idea of forcing me to record how many hours I spend on bugs, new features, meetings, etc… is completely absurd.

Hours spent on a task is a poor metric in these cases. The idea behind logging how much time is spent on bugs or new features is that goals can be created around how much time is spent on bugs. For example, we want to spend 5% less time on bugs next quarter.

Unfortunately, that’s a poor way of motivating people. Developer “A” is responsible for 10 bugs and each takes 5 minutes to fix. Developer “B” is responsible for a single bug that takes 3 days to debug and resolve because it’s a rare race condition. Why should developer “B” be penalized in this case when clearly developer “A” needs to work on improving his code? Metrics should be formed around the number of bugs introduced and the complexity of each bug. Our goals should be to reduce the number of trivial bugs that make it into production, rather than reducing the amount of time spent on fixing bugs.

Creating goals around how much time is spent on bugs per sprint creates deceit. People will be more focused on adding new features to their sprint rather than prioritizing the bugs in order to show management that they spent more time on features than bugs that sprint. This will create software full of bugs. Yes you’ll have plenty of new features, but buggy software is still buggy software.

There are times when we need to find out how much money it took to create a feature. Since these features are estimated in story points, I don’t see why it’s so difficult to write a query in your project management software to find out it took 2 developers and half the sprint to create this feature. Same concept can be applied to any bugs that were fixed or maintenance work.

These are all estimates anyway. If you think forcing people to log how many hours they worked on a feature will yield more accurate results, you’re in for a rude awakening. People will forget how much time they spent on a feature and most people people already estimate the approximate time they spent on a work item anyways. You’ll get more accurate results by querying your project management software.

I also hear the argument that logging hours will help us identity when people are attending too many meetings, responding to too many emails, or other administrative work. That may work for code monkeys that do nothing but follow orders, but now you’re burdening other people. This relates to my previous post about discipline over forced processes. If someone feels they are attending too many meetings and cannot get enough work done, then that person needs to take responsibility and stop attending useless meetings. As long as I’m producing results on time, why should anyone care how many meetings I attend? Getting the job done is why I get paid. If someone isn’t producing value, then it should be the supervisors job to take notice and step in. It doesn’t take a rocket scientist to identify people who can’t carry their weight.

The bottom line is that management needs to trust the people working for them and treat adults like adults.

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.

Before I go any further, I want to mention that this post is based purely on my observations, my current state, and most importantly my sole opinion. Your mileage may vary. I’m sure there are teams that are living in Scrum bliss. I’ve debated for a few days whether to actually post this or not, due to the fact that it may seem like I’m railing against the blind and unthinking practitioners of “Agile”. I removed half of this post because I wanted to keep it somewhat compact and not just rant on.

I’ve mentioned a few times that I’m a fan of the ideas behind the Agile Manifesto. However, I’m not a fan of the Agile (capital “A”) methodology/process/bullshit that is forced on me. Here is Wikipedia’s definition of Scrum:

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development.

The problem is “managing projects”. This is what happens when people becomes overzealous about a process. All I see is a narrow-minded, fixed set of steps that inhibits rationality. Scrum is designed for mediocre developers who can’t think for themselves. There, I said it.

People tell you that if you don’t follow this approach, you’re doing it wrong. If your project succeeds, then it’s because you did “Agile”. If you fail, then you were doing “Agile” wrong. This mindset breeds mediocre teams. Their goal is to teach everyone what a scrum is, what a sprint is, what are user stories, what the product owner is responsible for, etc…. The problem is that they know how to do “Agile” (noun), but they don’t know how to be agile (adjective).

When people tell me that I can’t clarify requirements with the business because the business analyst will do that for me in a separate meeting, I can’t help but think whether they’ve actually read the manifesto or not. This tells me that they’ve adopted the garden variety pseudo “Agile” bullshit and have simply cherry picked what looks good on paper.

The fourth principle of the manifesto states that “business people and developers must work together daily throughout the project”. But in a dysfunctional Scrum world, this just means that the development team sits in the same meeting with the business without contributing. I was even scolded last week when I attempted to clarify requirements during a meeting. If I hear “we shouldn’t care how the business prioritizes tasks” one more time, my blood pressure will go through the roof.

Some people may not care, but I certainly do care about why a task is prioritized in a certain order and the business history behind such a decision. Domain experts and developers do not have to be separate roles, yet this mindset of “we don’t care” completely misses the point of the fourth principle from the manifesto. People are too focused on what the software should do instead of what business goal we are solving. They are tasked with delivering a set of stories and measured on that, so they won’t see any benefit in coming up with alternative or better solutions.

The manifesto for half-arsed agile software development is amazingly accurate:

Individuals and interactions over processes and tools and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact.

Scrum is nothing more than just a bunch of rigid processes. Being agile is supposed to be about flexibility and the ability to react. It’s not supposed to be about rigid processes and managers who are blindly devoted to their metrics.

“Agile slave” is an accurate description. I am told all that time that if a story isn’t completely defined, then throw it back to the business and it doesn’t make it into the current sprint. This tells me two things: the team doesn’t trust the business partners and you’re blindly following a process without thinking about the long term benefits. There is still this mentality of “us” vs “them” when it comes to IT and business. Yes, you’re protecting your team and velocity in the short term, but why should I put so much emphasis on velocity? It’s just a number, an estimate.

Rather then working with the business partners to build that knowledge and educate people, you’re throwing items over the fence and moving on. People are missing the big picture. As time goes on, a relationship is formed and both sides work in unison. I don’t have to constantly question the business and vice versa because there is trust. If you’re not working towards this goal, then you’re not trying.

More and more shops now think of themselves as Agile. They’re investing in Agile training and attempting to adopt Agile methods such as Scrum and Kanban. But they’ve missed the point. Instead of becoming enlightened freethinkers, they’ve drunk the Kool-Aid and joined the Cult of Agile. Dogma and orthodoxy are alive and well. At the cutting edge of our profession are the people Andy Hunt calls “Agile slaves.”

I just got home after spending a week in Miami attending Udi Dahan’s “Advanced distributed systems design” course. This was by far the best training course I have ever attended. In fact, I believe it was one of the best investments I’ve ever made for my career. I’m sure it will take me many weeks of reviewing my notes to fully digest all the information that was presented. I am extremely excited to start thinking about and using some of the techniques and concepts that I learned during this course. There is no doubt that it will take me several years of being a practitioner for these concepts and principles to become second nature, but the end result will be worth it.

If you are interested in distributed systems, I highly recommend attending this course if you ever get the opportunity.