Agile Blog Sponsored By  Agile Sponsor    Agile Sponsor   



Agile Planning and Its Success Patterns

Written by  Sudheer Raju | 31 October 2011
E-mail PDF

Agile PlanningAgile Planning is one of the first and biggest challenges that you will come across if you are intending to transition to agile. Senior Management within enterprise in my experience expect overnight results since we now have moved to agile mode of delivery from either not having a delivery model/principles or traditional models. Well does that sound familiar? Being involved in transitioning teams to agile off late, have come across some common patterns which i thought could be classified into 3 levels that all teams have to go through before any team can confidently say we are working in agile framework.

Like any transition i guess its imperative that the change cannot happen overnight and respective teams have to go through series of states to achieve the end goal. Agile planning as well is no exception.

Typically our planning process like any others consisted of

  • Scope Definition as user stories (backlog)
  • Prioritize, Estimate and Elaborate Stories
  • Define iterations based on prioritization. Define Releases based on achievable iterations by release date. 
  • With all of above a typical culture change that goes in parallel across

Fail & Learn (Level 1)

It is absolutely mandatory for any organization or team to understand that Failure is imperative at this state and to recognize that "Failure Is Imperative at this stage to Succeed in Future". The more you fail at this point the more you are set to learn and succeed later.

Its like a bird that learns to fly but fails, when its new to flying and in process learns the technique to fly. So unless the techniques are learnt its immature to expect that delivery will be smooth since we embraced agile.

The first pattern that can be expected with reference to stories, iterations, releases and change from various teams can be summarized as follows.

Story Definition: 
  • Able to identify the stories 
  • Not able to elaborate stories to detail 
  • Not able to provide judgmental estimates
  • A blind iteration plan with 100% chance of failure
  • Iterations are Longer, Uncomfortable Length
  • Iterations can't follow Calendar cycle and tend to have unconfirmed delivery dates
  • Releases are Internal first
  • Followed by Collaborative release to stakeholders
  • Finally to Production
Change Acceptance:
  • Change repulsion with deadlines being considered high priority
  • Not aligned with concept of scheduling change into sprints

      -- You are trying to embrace agile, so be prepared to fail for atleast first few iterations. Understand that this failure is what enables you to succeed in future. Put more pressure on the team, team may never recover leading to failure of transitioning to agile. Support the team to settle down and you shall see the overall risk to delivery goes down quickly and eventually resulting in continuous value delivery. --     

Continuous Improvement (Level 2)

Teams enter into this level of maturity once the basic techniques are learnt and have analyzed what is not being done right from the failures. It typically took close to around 8-10 sprints to move to this level from previous. A realization does come that only way to improve is fail and learn and embrace steady continuous improvement process. Many a times could see the first seeds of confidence coming into teams at this point and also some pride :) that we are implementing agile

What could be seen compared to previous life was

Story Definition:
  • Able to identify the stories
  • Able to elaborate stories to as much detail
  • Able to provide judgmental estimates
  • Refactoring is being talked about with less implementation
  • Iteration plan taken seriously
  • Iterations are timeframed realistically with some hiccups
  • Iterations tend to follow Calendar cycle and tend to have confirmed delivery dates
  • Software Demo Becomes Key
  • Followed by Collaborative release to stakeholders
  • Finally to Production
Change Acceptance:
  • Talks about Agile encouraging Change 
  • A broadened mindset to accept change
  • Team works with scope to absorb impact

--     Focus on Collaboration and Empowerment becomes key with increasing confidence levels. Team shows first signs of embracing agile philosophy in true sense with refactoring, TDD, Automation and other concepts coming into picture. Support from management is still the key to survive. 

Consistent Improvement and Implement (Level 3)

Typically from 20th sprint onwards (which probably takes a year or more) we tend to exhibit that we are getting hang of agile principles with few also terming themselves agile gurus :) and really getting into real collaborative mode of delivery. 

Powerful statistics are always at hand with team members quoting examples from previous sprints to put forward data supported arguments. Team is much more confident to sit with product owners sharing their views and stories, committing to aggressive timescales, accepting change and exhibiting a nature to question where there is a sense that value is not being delivered. 

Story Definition:
  • Able to identify/elaborate and question stories and its value
  • Able to provide comparative estimates based on previous sprints
  • Refactoring is part of every sprint
  • Iteration plans are default understood consistently
  • Iterations are timeframed realistically with risks considered
  • Iterations tend to follow a smooth flow with dates earmarked in advance and also met
  • Software Demo is still the key
  • Production Release with reduced release overheads
Change Acceptance:
  • Understood that Change is good
  • Value delivery becomes a routine

--     You now have an agile team that can cope with any kind of pressures or atleast collectively stand to face any kind of challenges. You may try to put pressure but team is matured enough to push things back and be sensible enough to play with scope, velocity and iteration length to schedule work items accordingly. You as a manager may be are receiving Continuous value delivery so why hassle anyone :).  --     

Sudheer Raju

Sudheer Raju

Founder of ToolsJournal, a technology journal on software tools and services. Sudheer has overall accountability for the webiste product development and is responsible for Sales and Marketing. With a flair to write, Sudheer himself writes for toolsjournal across all journal categories.

blog comments powered by Disqus