Process oriented approach to Agile Software Development
2 likes1,726 views
The document discusses a process-oriented approach to agile software development, particularly addressing the challenges faced by distributed teams, such as time zone differences and lengthy planning meetings. It proposes strategies to enhance collaboration and efficiency, like focusing stand-ups on critical issues and allowing for more meaningful story sizes. While this approach has benefits, it also presents challenges such as variable velocity and the necessity of a motivated team.
Process oriented approach to Agile Software Development
- 1. Process oriented approach to Agile Software Development Tomasz de Jastrzebiec Wykowski Agileee, 18 Sep 2009 Kiev, Ukraine
- 2. Let me introduce myself
- 3. Distributed teams – the pain • Different location, different time zones – “phone” stand-ups – How to make demo, retrospection and planning in one meeting – How to share story – What to do if I’ve completed my story – Why shall I bother about other’s stories
- 4. The Pain • Anyone who’s attended an Agile planning meeting knows they can often last about an hour longer than you can stand it. Jeff Patton http://agileproductdesign.com/blog/2009/kan ban_over_simplified.html
- 5. Distributed teams – the pain • The pain is increasing with team size
- 7. Let’s combine • Discuss stories in advance • When you finish your story: – Demo to product owner (can even be done during development) – Select next story. Decompose and Estimate. • You can still share a story in one location • On stand-ups, concentrate on things “other need to know” like blockers or completed stories, rather than detailed info about tasks
- 8. Profs • Iteration planning becomes a be-weekly review (much shorter) • Shorter stand-ups – concentrate on critical things • Release Burn-down chart showing progress • Feedback from product owner received earlier than in traditional iteration (as soon as story is completed) • “Iteration” can be reduced to any short period of time • Stories can be bigger and more meaningful (no need to decompose stories to very low level to fit iteration) • Newly discovered work (bugs, new stories) can be implemented faster – no need to wait till the end of iteration to start it.
- 9. Cons • Limited value of iteration burn-down, as stories can be added in the middle of iteration • Required “agile”-educated and self motivated team • Might cause bigger variance to velocity. It’s not a problem for long running projects • This still does not solve “we vs. them” problem observed in multi-locations environment
- 10. Thank you!