New to agile? Keep it very simple
When dealing with an agile implementation, particularly in the case of a new agile team, we often make things too complex and difficult. We tend to keep putting band-aids on the process until we have something that is overly burdensome and no longer useful. I’ve now seen enough of this to know there needs to be an intervention! So take a deep breath, relax and read how to simplify your life on an agile team.
The starting point is the 6 basic principles of what I call “Simple Agile.” I mentioned I was going to be doing a talk for Agile Denver on this topic and I would follow-up with another blog post about the specifics, so here it is:
6 Principles of Simple Agile
- Work together
- Honor priorities
- Respect the customer, the process, the product, the team and each other
- Do the simplest thing that works – then stop
- Improve every iteration.
Let’s take them one at a time, but very quickly. I’ll probably write more about each of these in a future blog entry. Be sure to leave comments or questions if you want further clarification of any of them.
Very simply, “collaborate” to me means to communicate effectively with each other. There is no place on an agile team for a lack of communication. Communication needs to be as near to real-time as possible, and hopefully as high bandwidth as possible. In rare cases people on the team may not choose to use the best communication method available, but that should be the exception not the rule.
2. Work together
If we communicate well then we need to follow it up by working together. For example, a Product Owner, tester and developer have all agreed on what a specific story means. This does not imply the tester and developer go off their separate ways. Work closely together to make sure the shared understanding stays shared. I’m not sure what to call this other than “pairing.” I’m also in favor of pair programming for a lot of reasons. It has been proven pair programming signficantly increases product quality without affecting productivity.
3. Honor priorities
Always, always, always work from a RANKED product backlog. You must work on things in the order they appear in the backlog unless there are exceptional circumstances (like a story is too big to fit in the iteration so it is deferred until the next iteration in favor of a smaller story now). Everyone should follow the rule “the next thing you do should be a task in the highest priority story you can work on.” This implies more than one person will work on a story (swarming). It should also mean teams have fewer open stories (limiting work-in-progress). This will lead to delivering the maximum value every iteration.
4. Respect the customer, the process, the product, the team and each other
When does a customer know exactly what they want? When they see it of course! When do they know how they feel about your product? When they see it. Let them see it more often, gather feedback and utilize the feedback. Respect the process by sticking to it and holding each other accountable for process success. Respect the product by reducing complexity and technical debt. Respect the team by not having unrealistic goals, being sustainable and letting them solve their own problems. Respect each other by working together toward success and supporting each other at all times. I could go on and on with this topic (it is a personal pet peeve), but I won’t. If you get a chance, do the following exercise: On a piece of paper write down all the different ways respect of these things could be improved, and next to each write down a list of the downstream effects such a change would have. You’ll be amazed how much difference this can make toward success.
5. Do the simplest thing that works – then stop
Everyone in the product development industry has a tendency to do too much with every feature. We even have a name for it: goldplating. It is very easy to fall into doing it. Ever hear something like “While I was in the area I did XYZ.” or how about “The story didn’t say to do this, but I knew the user would want it so I did it.” Both statements should never be heard on agile teams. We should do the simplest thing that works – then stop. Ask the customer (remember we are respecting them by getting them involved) if we hit the mark.
6. Improve every iteration
Remember, 1% better every 2-week iteration will make a team more than 25% better after a year. Big improvements aren’t needed, just a lot of small ones. This might be the most key principle of “Simple Agile” because it enables us to understand we will never be perfect. Keep trying to get better and you will.
These 6 principles are designed to get teams back to thinking of what is important. They draw heavily from the principles of lean software development. In many ways they could be considered rewordings of those principles. I believe in these principles. I believe they make a huge difference when teams believe in them as well. How many are you violating and what are you going to do to get back to doing the basics?
Until next time I’ll be Making Agile a Reality® by continuing to coach teams to do the basics well, then improve.
Updated December 23, 2009: You can also see the presentation at SlideShare.