Many people want to try agile software development techniques but they just can’t convince enough other people in the company to give them a try. Making the situations more complex, even if most agree that agile development is the way to go, they can’t agree on which agile techniques to apply — Scrum, Kanban, XP, ATDD, BDD, TDD, xDD, etc.
The result is that they either do nothing or they make minor changes to their current processes and call it a day. Doing nothing is never a good idea. And, as for tweaking the existing process, that’s almost as bad. Retrospectives are for tweaking. Enterprise-wide change goes far beyond tweaks.
If you find yourself lost in this change limbo, here’s an idea — go lean. Rather than approach the problem from the agile perspective, approach it from the waste perspective. Don’t try to sell agile benefits. Sell waste elimination benefits such as lower costs, faster turn-around, and reduced complexity.
Every situation is unique so there’s no rule book for getting leaner. However, the basic principles can be applied to every situation. Here’s what I suggest:
1. Lay out the current software development process.
You can use a process diagramming tool like Visio. Or, you can simply list the steps in tabular format. Or, you could take advantage of a Kanban board to show the flow. Any technique can work. Don’t agonize over how to lay out the process. Just do it. You can always adopt another visualization tool later.
2. Engage all the major stakeholders involved in the current process.
Be sure they understand and agree upon how things work today. Remember, the goal at this stage is to understand the current process only. No one should be trying to improve it.
3. Identify the waste.
Of course, the obvious question will be “what constitutes waste?”. Waste to one person may be a critically important item to someone else. Focus on two major types of waste.
3a. Artifacts or process steps that are completely unnecessary. For example, a paper signoff form that could easily be replaced by a simple email exchange.
3b. Artifacts or process steps that are longer and more complex than they need to be. For example, a document that contains large quantities of boilerplate information and other content pulled from related documents.
I encourage you to begin with the premise that everything is waste, yes, everything. Force everyone to justify the need for every artifact and process step. That includes the source code — why not simply buy a software package instead of building one? Once the must-have artifacts and process steps are identified, dig deeper. What content within each artifact can be eliminated without compromising its value? Unless the content value can be articulated, it’s waste and has to go. The same applies to process steps or phases. If there’s little or no value, its got to go.
This won’t be easy or quick. It forces everyone to think about what really matters. If they care about an artifact or a process element, they’ll defend it. If not, they’ll let it go. In the end, you’ll have a leaner, streamlined process. But, it won’t be agile.
That’s okay. The idea behind this exercise is to get lean not necessarily agile. If you succeed, the next challenge is to deliver sooner by breaking up large projects into smaller chunks. More on this topic in my next post.