If you have a development team, and you are considered switching from waterfall to Agile. And particularly if in your organization you have no people who have worked on an agile project for a year or more, there you must pay heed to these recommendations.
Dear Project Management,
I understand you would like to adopt an agile methodology. This is a very good thing. You will find that you can develop software that is both higher quality, and can be moved more quickly to meet the needs of customers, or to compete with other vendors. In fact, I believe if you do not adopt Agile approach, you will not succeed in the marketplace.
But if your organization has no experience in Agile approach, there are some very grave concerns.
The Agile approach is a completely different approach from waterfall. What you must understand, is that you will not understand Agile. It will make no sense to you. It will seem to be nonsense. This is something that everyone goes through on the way to Agile. Normally, you have a team such that half the members understand, and half do not. The half that understand can help the other half through the doubt and uncertainty. It cannot be explained, you have to experience it. It defies standard analytic logic, it defies what I call “enlightenment principles”. You cannot break the activity into a discrete process organized around features. The result emerges holistically from the activity, and not as separable units which could be performed individual. If this sounds like superstition or witchcraft, is it because you are trying to understand reduce the complexity to simpler forms. This reduction, in the fact of complexity, does not produce logical result. You need to think about it differently.
It is a huge problem without half the team having experience. Change from waterfall to agile in that case might be an impossible task.
If you still want to move forward, then in order to succeed, you will have to make a very drastic step.
There is no smooth path from waterfall to agile. There is no way to go half way. I compare to riding a bicycle:
You can walk, and you can ride a bicycle, but there is NO step which is half way in between. You cannot put one foot on the pedal, and one foot on the ground. If you do, you get an awkward movement that is neither walking, nor riding, and you learn nothing. At some point, you have to get all the way on the bike, and pick up your feet.
If you are serious about moving to Agile, you will set up to “release” the product every 2 weeks. You must abandon waterfall completely. You can not take a compromise position, and cycle every 2 months. It cannot be 1 month. You must go all the way to 2 week cycle, in order to force the entire team to learn a completely different way of thinking. When you understand, you will see that there is no need for the cycle to be longer, and there is no benefit of making the cycle longer. You will see that you could easily take the cycle to much shorter, even to the 12 hour cycle that Facebook uses.
Stop thinking about features first, and planning what features will be finished on a date 12 months from now. With Agile, features are not planned as features. You have no “complete” planning of a feature. It is thinking about “features” as a unit that blinds one to the agile approach. Instead, you have long term desires, which are expressed as small steps. You implement one step, and see how it looks. Then decide if you want to take another step. There is no need and no advantage in decideing ahead of time how many steps you are going to take.
The organization will change form. People will take on different roles. You might have everyone in the organization as exactly equal developers, but that is unlikely. You are likely to find that people will tend to specialize, and find new expert roles for themselves. Someone particularly good in testing will tend to find a role to help others in testing. Maybe you will have that, maybe you will not. One thing is certain: you can NOT IMAGINE the new roles that people will take today, because if requires a completely different mindset. Everyone is today in a particular role not because waterfall specifies very particular roles, but because over time we have found our relationships within the framework of a waterfall cycle. Everyone has hidden talents, and we have all worked out the current relationships. Disrupting this to Agile will rearrange how everyone works together but it is impossible to predict how that will look!
- Do not try to predict how the organization will change.
- Do not ask people why they have not been able to release every two weeks in the past, when they have no experience in agile development
The only thing you need to do is to decide to make a customer quality release every two weeks, no exceptions.
Everything else derives from this. This become the driving principle, and the main rule you cannot break. If you break this rule, then developers fall back into waterfall patterns. If you need help deciding how to break up a feature, I can help, but it is not hard to do.
- You make daily builds,
- On every build you run the tests. You will need to do some work to get the tests to run reliably every day.
- You ask every developer to run the tests BEFORE they check in. You will need to do some work so that the tests can be run by every developer.
- You don’t estimate how long it takes to implement a feature – you just don’t need to know that. Instead take the first step.
- If you see bugs that you did not expect, you fix them. You do it before you implement anything else. When the product is release, it has no bugs in it.
- You update the documentation to match the code changes that have been made. The ENTIRE job is done on each cycle.
- You update the installer, the upgrade path, the sample data, everything and anything necessary for the change.
- You do code reviews on the small step that has been implemented, all code reviews for all changes must be completed within the two week cycle.
- You do not implement anything part-way. You do not implement something that prevents you from accessing another feature or another section – that would be considered “breakage” (a.k.a. level-down)
- Once the step is completed, you can go on to the next step. Once you know for sure that the quality is already in the code, you don’t need to go back to it.
- You do not build up “technical debt” in the code base. You do not leave things in that you know has to be fixed later. You make small steps, but each step is done completely.
- At any point in time you can simply decide that it is time to ship one to a customer, and pull that build and ship it. You might not do that more than few times a year. But the point is: you need to approach this as if any build could be shipped at any time.
Switching to Agile requires that someone is able to MAKE A DECISION to switch to Agile. Perhaps this is difficult in your organization to do. I understand that much is decided by consensus, but since nobody has any experience with Agile, you will not get consensus. If you cannot make this decision and commit to it for more than 1 year, then don’t even try.
The only thing you, as management, need to do is to decide to make a customer quality release every two weeks, no exceptions. Everything else follows from that.
Get on the bike, and pick up your feet.