Facing the Challenge of Agile
It’s no secret. I’m a huge supporter of Agile software development methodology. I’m convinced that at my former job, when we did correctly implement Agile, our team’s development effort was easily fifty percent more productive than it otherwise was. Moreover, as stated in the Career Objective summary at the top of my resume, I assert that I seek “employment in an environment that… implements or desires to implement Agile methodology” right up there front and center.
So when Mike put me on the spot asking me to be the company’s Agile champion, I jumped at the opportunity. Well, closer to the truth I said something like “sure, why not…” after all, as a software development professional, I don’t exactly have the physical wherewithal to be doing handsprings. Programming and website design do not naturally lend themselves to Olympic prowess.
The challenge, of course, is to get more out of Agile than what you put into it. If I’m going to interrupt the team’s workflow for fifteen minutes each day and two hours once each month, I’d darn well better have something to show for this. Figure 2 hours plus 18 days times 15 minutes times 6 developers. That’s thirty-nine hours, just about one programmer-week of development time each month. I need to be able to demonstrate at least a five percent productivity increase to justify the effort.
Simple, right? What could possibly go wrong? I’ve already asserted that my former team was “easily fifty percent more productive than it otherwise was” just a few scant paragraphs ago. It’s a little different when it’s your own neck on the line. The magic that happened behind the curtains? Now I have to make all of that happen. And the results? They’re not a given, and they’re certainly not immediate.
With that said, my next step is to formulate a plan, estimate costs and benefits and establish milestones. I will follow up with this post as I progress with improving ThoughtLab’s Agile processes.
