Process oriented approach to
Agile Software Development
  Tomasz de Jastrzebiec Wykowski
      Agileee, 18 Sep 2009
      ...
Let me introduce myself
Distributed teams – the pain
• Different location, different time zones
  – “phone” stand-ups
  – How to make demo, retros...
The Pain
• Anyone who’s attended an Agile planning
  meeting knows they can often last about an
  hour longer than you can...
Distributed teams – the pain
• The pain is increasing with team size
Process
• definition
Let’s combine
• Discuss stories in advance
• When you finish your story:
  – Demo to product owner (can even be done durin...
Profs
• Iteration planning becomes a be-weekly review (much
  shorter)
• Shorter stand-ups – concentrate on critical thing...
Cons
• Limited value of iteration burn-down, as
  stories can be added in the middle of iteration
• Required “agile”-educa...
Thank you!
Upcoming SlideShare
Loading in …5
×

Process oriented approach to Agile Software Development

2,796 views

Published on

Talk by Tomasz Wykowski on “Process oriented approach to Agile Software Development” at Agileee.org conference

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,796
On SlideShare
0
From Embeds
0
Number of Embeds
35
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Process oriented approach to Agile Software Development

  1. 1. Process oriented approach to Agile Software Development Tomasz de Jastrzebiec Wykowski Agileee, 18 Sep 2009 Kiev, Ukraine
  2. 2. Let me introduce myself
  3. 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. 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. 5. Distributed teams – the pain • The pain is increasing with team size
  6. 6. Process • definition
  7. 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. 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. 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. 10. Thank you!

×