top

Search

Get ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile

After working with several Agile teams across locations in India, I identified one thing that is imperative for successful Agile Software Development- knowing when you are ready to start. In the Agile world, we call it being “Ready-Ready”. Many times you will see teams kick-starting their software development even before the requirements are laid clearly. Under the misconception of being agile with continuous customer feedback and change, they will end up re-doing software most of the times. Solid software architecture and having a forward-thinking attitude are considered as anti-agile by such teams. Sometimes it becomes a challenge for the Agile preachers in such teams to help the team or the leadership understand the true value and meaning of being Agile. No doubt, with Agile comes a freedom to incorporate customer feedback early in the software cycles for more realistic and expected outcomes, but it never says not to perform detailed requirement discussions. A good set of requirements is vital for a good start and spending some time initially to understand the customer’s needs is crucial to a project’s successful execution and delivery. With “Ready-Ready”, one cannot only put a tab on the requirements front but also on other crucial aspects that are required for setting the stage right.    Using a Definition of Ready Correctly https://t.co/AXfaANNib7 #agile #scrum pic.twitter.com/XYr0EEKbJs — Mike Cohn (@mikewcohn) August 9, 2016 A few key items that I feel should be a part of the ready-ready checklist could be- A story that is prioritized by the Product Owner. A story that has story points assigned to it. A story that contains a ‘Who’ (Persona), ‘What’ (Feature) and ‘Why’ (Benefit). Where an acceptance criteria are defined in the story. Non-Functional Requirements (NFRs) if applicable, are also mentioned in the story. The design is discussed and documented to conform to the current architecture. All dependencies and risks are identified, documented and mitigated. All assumptions are captured in the story. UX is defined for the story’s implementation. Code Reviewers are identified and involved in all related discussions. Not all items apply to all teams, but overall these capture the major things that one may miss when starting with a story. For instance, if we do not identify & involve the code reviewer from the beginning, the code review session will end up being a syntax check with almost no focus on the end-to-end functionality and impact on other modules. Likewise, if NFRs are not defined well in advance it can pose a big bottleneck for a software release because of performance issues surfacing later in the development process. It becomes very important to ensure that during the backlog grooming sessions, the ready-ready checklist  is looked upon and the stories which score a 10 on the list goes for development in future sprints. Most of the elements are common sense but in the haste of starting development and delivering features we sometimes miss the real basics which we end up paying for, at later stages. But it is not only how well you start a story’s execution that matters, closing the story is equally important. Missing a critical element to cater to for a story, can sometimes be disastrous for the whole project. For instance, I read about a team who missed running a check on usage of open-source code snippets in their application code and released the software, they were lashed with huge fines for infringing copyright laws. Having a ‘Done-Done’ checklist helps manifold, without that we will never know when a story is done or a feature is complete. In almost all the teams I have worked with, we had a well-defined Done-Done checklist that the team decides early on in the project and adheres to during the course of the project. Having a well-defined ‘Definition of Done’ or ‘Done-Done Checklist’ as I like to call it, not only makes it simple for the team to tick off and claim a story but also gives a clear picture of what is left of the story to push it out of development. Most of the items could be very obvious ones such as code checked-in into source control and reviewed etc., but there are a few that I feel are the real value-adds. Listing all that I feel should be a part of a standard Done-Done checklist- High-level design documented. Test Cases discussed among Dev. & Q.A. and documented Unit Tests written ( X% code coverage) Code checked-in into source control Code Reviewed UX Design followed All Unit Tests passing Install/Deployment changes completed & tested Regression is passing Help document updated By simply ticking items off this list, teams can be crystal clear with the pending items and focus their attention on the closure of the same. This not only helps the team to drive stories to closure, but also it will help identify any regular roadblocks that hinder a team’s ability to claim story points within a sprint. For instance, team X works on software aspects of a product and is dependent on Y for update of Help & Troubleshooting documentation. Though Y is also involved in many other aspects of the software and Help documentation is not a priority for them. If team X fails to complete a story every sprint because of this dependency, the checklist will eventually highlight the issue and suitable actions can then be taken to prioritize items beyond teams and ensure timely closure. Having a comprehensive checklist for both ‘Ready-Ready’ and ‘Done-Done’ sometimes might appear an overkill and some items might even seem too obvious and no-brainer to have on the checklist, but the benefits eventually surface in long term and ultimately help the team to accomplish high quality and on-time delivery of software products.  
Get ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile
Ankit Goyal
Rated 3.5/5 based on 5 customer reviews
Get ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile 175
Get ‘Ready’ Before You Get ‘Done’: Productivity Route To The Next Level In Agile

After working with several Agile teams across locations in India, I identified one thing that is imperative for successful Agile Software Development- knowing when you are ready to start. In the Agile world, we call it being “Ready-Ready”.

Many times you will see teams kick-starting their software development even before the requirements are laid clearly. Under the misconception of being agile with continuous customer feedback and change, they will end up re-doing software most of the times. Solid software architecture and having a forward-thinking attitude are considered as anti-agile by such teams. Sometimes it becomes a challenge for the Agile preachers in such teams to help the team or the leadership understand the true value and meaning of being Agile.

No doubt, with Agile comes a freedom to incorporate customer feedback early in the software cycles for more realistic and expected outcomes, but it never says not to perform detailed requirement discussions. A good set of requirements is vital for a good start and spending some time initially to understand the customer’s needs is crucial to a project’s successful execution and delivery.
With “Ready-Ready”, one cannot only put a tab on the requirements front but also on other crucial aspects that are required for setting the stage right. 

 

A few key items that I feel should be a part of the ready-ready checklist could be-

  • A story that is prioritized by the Product Owner.
  • A story that has story points assigned to it.
  • A story that contains a ‘Who’ (Persona), ‘What’ (Feature) and ‘Why’ (Benefit).
  • Where an acceptance criteria are defined in the story.
  • Non-Functional Requirements (NFRs) if applicable, are also mentioned in the story.
  • The design is discussed and documented to conform to the current architecture.
  • All dependencies and risks are identified, documented and mitigated.
  • All assumptions are captured in the story.
  • UX is defined for the story’s implementation.
  • Code Reviewers are identified and involved in all related discussions.

Not all items apply to all teams, but overall these capture the major things that one may miss when starting with a story. For instance, if we do not identify & involve the code reviewer from the beginning, the code review session will end up being a syntax check with almost no focus on the end-to-end functionality and impact on other modules. Likewise, if NFRs are not defined well in advance it can pose a big bottleneck for a software release because of performance issues surfacing later in the development process.

It becomes very important to ensure that during the backlog grooming sessions, the ready-ready checklist  is looked upon and the stories which score a 10 on the list goes for development in future sprints. Most of the elements are common sense but in the haste of starting development and delivering features we sometimes miss the real basics which we end up paying for, at later stages.

But it is not only how well you start a story’s execution that matters, closing the story is equally important. Missing a critical element to cater to for a story, can sometimes be disastrous for the whole project. For instance, I read about a team who missed running a check on usage of open-source code snippets in their application code and released the software, they were lashed with huge fines for infringing copyright laws.

Having a ‘Done-Done’ checklist helps manifold, without that we will never know when a story is done or a feature is complete. In almost all the teams I have worked with, we had a well-defined Done-Done checklist that the team decides early on in the project and adheres to during the course of the project. Having a well-defined ‘Definition of Done’ or ‘Done-Done Checklist’ as I like to call it, not only makes it simple for the team to tick off and claim a story but also gives a clear picture of what is left of the story to push it out of development.
Most of the items could be very obvious ones such as code checked-in into source control and reviewed etc., but there are a few that I feel are the real value-adds. Listing all that I feel should be a part of a standard Done-Done checklist-

  • High-level design documented.
  • Test Cases discussed among Dev. & Q.A. and documented
  • Unit Tests written ( X% code coverage)
  • Code checked-in into source control
  • Code Reviewed
  • UX Design followed
  • All Unit Tests passing
  • Install/Deployment changes completed & tested
  • Regression is passing
  • Help document updated

By simply ticking items off this list, teams can be crystal clear with the pending items and focus their attention on the closure of the same. This not only helps the team to drive stories to closure, but also it will help identify any regular roadblocks that hinder a team’s ability to claim story points within a sprint. For instance, team X works on software aspects of a product and is dependent on Y for update of Help & Troubleshooting documentation. Though Y is also involved in many other aspects of the software and Help documentation is not a priority for them. If team X fails to complete a story every sprint because of this dependency, the checklist will eventually highlight the issue and suitable actions can then be taken to prioritize items beyond teams and ensure timely closure.




Having a comprehensive checklist for both ‘Ready-Ready’ and ‘Done-Done’ sometimes might appear an overkill and some items might even seem too obvious and no-brainer to have on the checklist, but the benefits eventually surface in long term and ultimately help the team to accomplish high quality and on-time delivery of software products.
 

Ankit

Ankit Goyal

Blog Author

Ankit Goyal is a Tech Enthusiast and Scrum Master at GE. He enjoys solving complex problems with simple solutions, creating model Agile teams by driving cultural and mindset shifts within individuals and organizations.

Leave a Reply

Your email address will not be published. Required fields are marked *

Trending blog posts