Coping with change on Scrum projects (Part III)

Introduction

In the next two posts, I'll take a look at how the lives of QA testers and Developers are expected to change on Agile (scrum) projects. Frankly, I think that for these two disciplines, life gets much better i.e. developers and testers benefit most transitioning to Agile from Waterfall.

Developers

Developers love to do things right. Nine times out of ten, they'll argue against taking short cuts. They hate the fact that they are forced to deploy code that they know deep down is less than stellar. As with anything in life, making the shift to agile swings the pendulum over to the complete opposite side. So for the one out of ten code hackers out there - beware. The biggest change a developer can expect from a shift to agile is that engineering discipline or rigor is set to the max.

So what can you expect?

#1. You no longer have to estimate tasks on your own. This activity, arguably one of the hardest, will be done as a team playing planning poker. As a result, you'll get better at estimating, and you'll take a much broader outlook on estimates, so as to include all aspects of the development life-cycle including time to test, to document etc i.e. according to your definition of "DONE". Additionally, you don't shoulder the complete responsibility for a bad estimate.

#2. You will have to learn how to pair program. If you're doing XP, you'll be doing this more often than not. This is a huge mental shift that developers must make as for the first time, you are forced to open up your code to peer review. This means that you're being critiqued every step of the way. It's hard at first. But the benefit is huge - you're going to be a better programmer for it - guaranteed! This can also be a lot of fun by the way, especially with pair ping pong.

#3. No longer are you expected to throw code over the fence and expect testers to find the bugs for you. In fact you're going to be responsible for building quality in right from the start. So, you're going to have to learn how to write unit tests. You'll get to learn lots about Test Driven Development and Test first driven development. This is where your skills as an engineer are challenged, to produce the best possible, highest quality code. The rewards are great, trust me on this one.

#4. You will participate in the complete end-to-end process from beginning to end. This gives you a new perspective on things as you're part of the initial user story workshops. Consequently you get to hear things first hand from the Customer/Product Owner as they're there to elaborate at the Sprint planning meeting. You're also part of the retrospective at the end so you get to close the loop, reflect on what went right, what went wrong and to make it all better sprint by sprint.

#5. You won't have to burn continuously. In fact if you're true to Scrum, you shouldn't have to burn at all. Velocity tracking sets your maximum sustainable team throughput, which governs how much work-in-progress there is at any given time. Too much in the pipeline and you'll deliver less than what you should, too little and you'll deliver less than what you should. Instead mature Scrum teams will set things up just right so that you can continuously produce code without long periods of drought producing nothing like in waterfall projects. As I have probably mentioned before, our Agilebuddy team deploys new builds to production every two weeks without fail. This is a huge competitive advantage. We're able to do this by setting the discipline dials to eleven and ensuring that the pipe is optimally primed for just enough work. We can learn a lot here from Lean thinking and the Toyota Product System.

#6. You wont have to worry about death marches, or code blues. Rather, at the end of each Sprint you will feel proud of what you have produced, and you'll never want to work any other way again. This requires that all Stakeholders are bought into this new process right from the start.

#7. At the end of every Sprint you get to demo what you have done - this is the cherry on the cake. This is a time for you to shine rather than hide, where on waterfall projects you'd never know where or when the next bug was going to surface.

#8. You'll work as a team and cross each milestone as a team. This is not about I's and Me's. Instead, you'll seek opportunities out to help team members when in need.

Next week, I'll be going over QA testers which will be the last part of the series. Additionally, if you have any comments on any of the above or previous posts on this topic, please contribute, we'd love to hear from your experiences.

Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com

Comments

[Bob MacNeal]

As a developer, I agree developers and testers benefit most transitioning to Agile from Waterfall.

It seems like the discussion boards, blogs, and Twitter are full of "agile adoption ennui".

I'm not smart enough to offer solutions, but I did offer some general observations about change called Surfing the Transition Waves. Check it out.

http://bobtuse.blogspot.com/2009/09/surfing-transition-waves.html

[Craig Knighton]

I think a couple of the changes you mention above are harder than they seem and while beneficial will actually require some hard study. In particular, TDD and pair programming require weeks of extra effort to learn and both have a fairly high rejection rate. Both practices are important but not critical, so there is room for individual or team choice on the matters without having to toss out the whole methodology as flawed. I do think that TDD is worth the effort, but it also hinges on putting the effort into creating an architecture that is testable by design. This extra effort is awkward and time consuming (we had to bring in an expert to help us get our heads around applying MVC to a new application we were building). It might also be impractical to convert an existing code base to an architecture that allows for TDD, so you can be trapped by this as well. However, if you manage to overcome both obstacles the gains are phenomenal!

[Jack Milunsky]

Hi Craig,

Thanks for your comments. !00% agreed. All of this stuff is very hard. And the worst of it is that it's so easy to slip back into your old ways - doesn't take much.

But you have to keep chipping away at it. Even if you take baby steps. As you say, the benefits if you get it right are staggering.

Jack