The Agile Approach to “Doing” Agile

Over the past few years, I have watched developers go to conferences and be filled with excitement over agile development. We love the thought of the rapid changes and better feedback. We get into the buzzwords like Scrum, and Kanban, and the term Burndown list excites every developer’s inner pyromaniac. Then, we take all that excitement back to our day to day lives and quickly find out that we are not in a position to change the process that is in place. Developers talk to me all the time about wanting to “do” agile, wanting to do that lean development that everyone is talking about, but they can’t because their boss, or manager, or the project manager say no.
The biggest mistake we make is trying to sell a whole agile process (Scrum, lean, Kanban, etc…) all at once. We are essentially walking up to our boss and saying, “let’s throw our process away and try a new one.” I can understand how this can be met with some reluctance. At this point there is almost no incentive for the manager to switch. You can promise him all the standard agile talking points, “working code more often”, “more communication”, etc, but to him it’s all just smoke with no substance. More often than not you have to prove to him that it will work before the people who make those decisions will say yes.
Now you find yourself in a difficult position, you can’t “do” agile without showing management that it works. You can’t show management that it works without “doing” agile. What is a developer to do?
One of the core agile tenants is small iterative changes delivered often. Write a small piece of functionality, then deploy it. Write the next piece, and deploy that. Repeat until you are done. It would seem that using the same process to implement agile methodologies into you organization would just make sense. What if, instead of walking in and saying “I want to do Scrum!” you just start doing it. What if you sat down and created a list of everything you had to do? Don’t call it a “product backlog,” just call it a list. Then, what if you meet every day among your team to discuss how the work on the list is going? Don’t call it a “stand-up”, just call it a meeting. Then, what if you start letting QA and the BU see what you have completed. Invite them to a meeting and say,” we just wanted to show you what we have been doing.” Don’t call it a “Sprint Review Meeting”, just call it a demo.
I hope it is obvious where this is going. At some point you can walk into your boss’s office and say, why don’t you just let me keep doing what I am doing? That seems so much easier than asking him to let you change the current process.
For that reason, don’t hide what you are doing. Let everyone know what you are doing and how it is going. You want to build some legitimate excitement around what is going on. Having the conversation with management that you are now tracking what is coming up in a list and meeting daily to talk about how that list is going is critical to getting them to buy in to the process.

Leave a Reply

Your email address will not be published. Required fields are marked *