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.
photo credit: comedy_nose via photopin cc
I agree, Peter. There is much more ‘delay’ on projects than people realize. A few hours here, a day or two there and before you know it weeks have been wasted. Multitasking is a major contributor to the problem.
Nice article. Loved reading it! Another most seen type of waste is delay. Especially in our work, delay often means extra work. To get back at the item after a week/month or so, takes more time than picking it up and finishing it immediately. The extra time is spent on re-investigation, remembering what is said, remembering the details. That’s why Flow is very important to measure and improve continuously.
Comments are closed.