Win a copy of Emmy in the Key of Code this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Agile - Painful to developers?

 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Marshal
Posts: 14322
237
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's a good thing. Thanks!
 
Author
Posts: 81
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
author & internet detective
Posts: 39586
781
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Author
Posts: 81
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 50
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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!
 
Forget this weirdo. You guys wanna see something really neat? I just have to take off my shoe .... (hint: it's a tiny ad)
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!