Agile - Painful to developers?

[Ashwin Vuyala]

I am a newbie to Agile methodology. As I do not have much knowledge on this methodology, I see that Agile will be painful to developers because at times the developer will hit at a technical roadblock and will take time to work around the same. However, I see that in Agile, we need to provide the daily status/progress in scrum calls. Definitely this would have been though before socializing Agile. Please clarify what we have in Agile to handle this situation.

- Ashwin Kumar V S

[Junilu Lacar]

I think what you're saying is that because you meet up daily and talk about progress, developers will be uncomfortable during these calls if they cannot report any progress in solving a major technical hurdle that they can't resolved in a day.

A few points about that:

- The daily scrum is not a status meeting
- The daily scrum is where you can identify obstacles that are hindering progress -- making it known that you are stuck is a good thing and you shouldn't see it as something that puts you in a bad light.
- The team should decide on what to do about those obstacles - either they need to help each other resolve the problem or ask for outside help

[Ashwin Vuyala]

That's a good thing. Thanks!

[Andrew Stellman]

I want to make sure I understand the question correctly. Are you asking how agile teams handle things when they hit a technical roadblock, because it will take time to work around the roadblock, and that will throw off all of their agile planning? If that's the question, then what I've seen many times on many different agile teams is that they handle this situation much better than traditional software development teams.

What would traditional team that does most of their requirements gathering and planning up front do in this situation? The team are working on a spec and following a project plan, which were both approved by managers, and they discover a technical roadblock. Now they need to go through some sort of change control process. This could mean a simple change to the plan, but it might require a major spec rewrite. All of that will delay the project, and cause plenty of emails, meetings, and trouble.

The reason that this is a problem for a traditional team is because when they approve specs and plans, they assume those specs and plans are mostly correct, and that changes can be handled individually. When unexpected technical problems happen, if the plan highly detailed that can severely derail the project.

Agile teams, when they're effective, don't assume that they have near-perfect knowledge at the beginning of the project. Instead, they put off most project decisions -- especially planning and requirements decisions -- as late as possible in the project. They expect that they'll hit technical roadblocks, so they use iterations to deliver the software in small increments, and use what they learn in each increment to go back and constantly adjust their plans. And all the while, they constantly collaborate with their users, stakeholders, and managers, so that everyone can keep their expectations in line with the project team.

The big difference between these two teams is that the traditional team has committed to delivering a specific piece of software, as defined in the spec, and they've committed to build it in a very specific way, as defined in the plan. The agile team, on the other hand, hasn't made those commitments. They've made a commitment that's much more valuable to their company: to deliver the most valuable software that they can, as quickly as possible (without being unrealistic), and to collaborate with their users, stakeholders, and managers to really understand what "valuable" means to them and the company.

This is one of the big reasons that agile teams handle technical roadblocks better than traditional teams. There are other reasons as well -- especially XP teams, who use test-driven development, refactoring, and incremental design to build software that can be changed easily, which allows them to have an attitude where they welcome and embrace change, and which helps them discover technical roadblocks earlier in the project. Jenny and I have a lot of discussion of this throughout Learning Agile.

[Jeanne Boyarsky]

Also, keep in mind that this is progress:

"Yesterday, I got stuck on problem X. I tried 6 things that didn't help. Then I paired with Sally and we tried 7 more things that didn't work. This is an impediment. Who can pair with me for a fresh point of view".

[Andrew Stellman]

That's a really good point, Jeanne. Agile teams work very hard to make sure everyone knows that roadblocks and mistakes are okay, and we can learn from them. Typical waterfall teams exist in an environment where a roadblock is seen by everyone as a serious problem. And this attitude makes sense when an unexpected roadblock can throw the entire project management and business analysis teams into a tailspin, because they have to stop what they're working on to rebuild plans and rewrite specs.

[Aaron Shawlington]

Please clarify what we have in Agile to handle this situation.

Agility.



Don't think of 'Agile' as all of those processes and ceremonies. It's not.

Agile[ software development] is all about having agility. That is (from my not very good - needs attention - blog post here: http://blog.aaronshaw.net/2014/05/17/agile-is-for-losers/ ):

The agility to change direction as quickly as possible, and as cheaply as possible. The agility to fail fast and fail cheap. The agility to continuously adapt and improve our own processes and techniques in order to deliver maximum value over a given period of time.

And I'd sumarize the intention of 'Agile' methods like this:

Only do what adds value. Don’t do what costs more than the value it adds.
Agility is valuable, so a present cost may be worth future agility.
Embrace collaboration in order to leverage the agility you’ve built into your engineering processes. ‘

It's all about deferring commitment and working in such a way that project momentum doesn't make us too clumsy to avoid disaster - just like the Titanic having too much momentum for it;s small rudder and being unable to avoid the looming iceberg.

So to get back to your technical roadblock; which sounds better - an unexpected roadblock in a project which has already has 8 months of detailed design and planning, plus a further 4 months of development put into it up until this point? Or an roadblock in a project which is set-up to have the agility to handle unexpected issues which might occur, and to uncover such problems sooner rather than later?

It's the agility - not some process - that allows the dev team (and customer if necessary) to handle such situations.

'Agile' is about accepting that there will be (among other things) surprise potholes further down the road. Waterfall is about imagining that you're clever enough to foresee them from the start.

Waterfall has it's place, but the certainty it requires to be confident of success comes with a dollar cost.

So in short, in 'Agile', technical roadblocks are something that is accepted as inevitable from time to time. There is no specific mechanism to handle them, other than to figure it out. That's the fun bit!