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
Rated 3.5/5 based on 5 customer reviews
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.

Posts by Ankit Goyal

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.  
Rated 3.5/5 based on 5 customer reviews
Get ‘Ready’ Before You Get ‘Done’: Product...

After working with several Agile teams across loca... Read More

Effective Retrospectives : Agile Management

Retrospectives have become a necessity in the world of software development. With things changing so rapidly each day, retrospectives are one of the few means to discover and identify the challenges and highlight the great achievements of a team. The way we need continuous feedback loop for our software products to get better each day, similarly, to create great teams, retrospective play a key role.   Retrospectives or ‘Retros’ as we call it have become a platform for teams to come up together and critically appreciate and review their own work. Many times, the intent of retrospectives is largely misunderstood, it should never be made a platform to point out mistakes of individuals or teams. Also, it should never be a means to compare individuals or teams. That will not only negatively impact the team’s morale and performance, it will greatly influence the individuals within the team.   Tip: Think very well about the participants of a retrospective. For instance, if the team isn’t matured enough they might not be comfortable bringing in points related to requirements in front of the PO or related to processes in front of the release manager. Ideally, there shouldn’t be any qualms in any individual in talking about any aspect but it might take some time for the team to reach that level of maturity.   Most of the times retros are considered as a waste of time or ineffective by team members. We might even notice that during retrospectives individuals are not actively participating or are not bringing up the real concerns that we might see during sprint executions.   It is imperative to understand that retrospectives should be focused on the following key aspects-  Processes Product Environment These form the bases of identifying the key challenges and opportunities within the team during a retrospective. If any item that eventually doesn’t impact any of the above can be set low on the priority for the team to work upon.   A concern may not necessarily be directly related to the above three but if we perform ‘5 Why Analysis’ of the problem is, we may end up drilling down to the real area of impact and understand the real problem. There is a big difference between actual and perceived problem. The Scrum Master here plays a key role in facilitating the discussion which leads to identifying the actual problem.   For instance, a team member brings out that, “Retrospectives are a waste of time, we spend a lot of time writing retro items. I can work on my sprint deliverables and be more efficient.” After performing a ‘5 Why Analysis’ on this statement we can probably uncover the actual problem. An individual might feel likewise if, ‘the team is overloaded and feels retros take away considerable work time’, or ‘the output of a retro is never worked upon, we never track the action items, hence it adds no value’, or a combination of both. A probable solution for this could be an efficient capacity planning in the first case or through follow-up and active tracking of each action item during the subsequent sprints. Tip: The Scrum Master can coach the team into doing such analysis by themselves to understand the root cause of an issue. This will bring about the true value of a retrospective and will motivate the team to participate in them.   There is no single magic method for conducting retrospectives, it varies with the team’s structure, size, and setup. Following are few of the many techniques that appeared interesting to me or have been used by me. Recurring Retrospectives   These are generally scheduled once each sprint, mostly after the end of a sprint, the whole team sits together and pens down the retro points followed by a discussion and defining action items on the key points. There are several techniques for these, and one can try what suits best for their team,   Went well / Did not go well / Things to try. Continue / Start / Stop Start / Stop / More/ Less / Keep  The idea behind each of these is the same, but how we execute them is different. It works well with co-located teams and brings out the key concerns and achievements of a team. The only challenge is that the entire team needs to think about all the key items for the entire sprint, one might miss a lot of those and the focus might get driven to the one or two major incidents which occurred towards the end of the sprint.   Tip: Ensuring that the team thinks about the entire sprint in totality, we can run through the sprint backlog before we start the retrospective. Focus on each story/defect that was worked upon, the key deliverable, and any challenges that individuals faced during the execution. It helps a lot to bring everyone into a similar thinking space.  Continuous Retrospectives This is a very innovative technique and is more effective than the recurring retrospectives, in terms of time and covering more ground. Instead of sitting together once at the end of the sprint, the team keeps putting down retro points as they encounter them or experience them during the sprint cycles.   These retro items can be either put on a board or dropped into a box as the team may agree to. Now, discussions of the retro item can also be done at regular intervals, or as soon as a specific number of items are identified or even in an ad-hoc manner based on the team’s availability.   With continuous retrospectives, we ensure that nobody spends time thinking and dwelling on the past to write the retro items, everyone can put their thoughts in real time and ensure that most of the crucial items are captured as and when they occur.   Tip: For new teams, it is very important to first perform retrospectives together, that will help individuals understand the thought process and help team define common goals towards being a better team and making better products.   There is no one single best way for retrospectives, but until we keep in mind the intent and desired outcomes of it, any methodology or technique can help us achieve them. Software development today is not just about making world-class software products but is also about making great teams and individuals, and retrospectives are one great tool for us to achieve that.  
Rated 4.0/5 based on 20 customer reviews
Effective Retrospectives : Agile Management

Retrospectives have become a necessity in the worl... Read More

Self-Organization: The Linchpin of a Successful Agile Team

The biggest paradox of a Scrum Master’s role is to become obsolete. We all should aim at ensuring that we coach and build teams that do not need us in future and can run by themselves. Though this might raise concerns in minds of many, for me this was a challenge I took upon myself when we created a new product team in my company.   When you are set to reach a milestone, you need to start right. As they say the first step in the wrong direction sets you off-course for the entire journey. We were a few engineers with varied skills, levels of experience, and were from diverse cultural backgrounds, but we had one thing in common, the zeal and passion to succeed, and succeed together.   Bruce Tuckman's Forming, Storming, Norming, and Performing model describes to a great extent how a team evolves into a high performing team. But these are the times of getting things done at a pace never done before and with the quality never imagined before, hence we not only ensured that we gave every individual enough time and flexibility to understand the way of working of every other person in the team, but also ensured that the team started delivering as early as they could and probably skip a few steps in Tuckman’s model of team formation.                                                                        Fig: Bruce Tuckman's Model   As a leader one needs to ensure that the team is built up on a foundation of common goals and objectives. It is never X’s task or Y’s story, it is always the team’s work and the team’s success and also the team’s failures. We shall never provoke any internal competition in a team; in the short run we might gain results faster, but in the long run it creates barriers for growth within the team members.   Following are a few practices that I imbibed and which helped my team not only to become a self-organized team but a high-performing self-organized team.   1- Safety is the default. Have you ever noticed the smile on a kid’s face when we toss them in the air, they feel no fear of falling or getting hurt? Wonder why? Well, because the kid is more than sure that he will be grabbed safe when he comes down. That feeling of comfort and safeguard is what we have to instill in each and every one within the team. Risk taking shall be a default, and individuals should never be questioned on failures. Nobody would try going that extra mile, if they fear being questioned in case they fail.   2- Learning shall never stop With the way technology is changing today, it is extremely important to keep the team abreast with the latest technical knowledge. If we invest in our teams, we reap the benefits multifold in a long run. And it is not just about sending folks for technical trainings but keeping them equipped with appropriate tools and resources to help them train themselves when the need be. In my team, we ensure that every individual has a Pluralsight license, which gives them the flexibility to take up self-paced trainings.   There was once a time where my team was very new to Polymer, and we were expecting a lot of work coming our way in that. The team members themselves decided to spend a weekend and go through a couple of courses on Pluralsight and do a POC. After just a few days into Polymer, they were not only working on it, but soon enough guiding other teams as well.   3- Value individuals One thing that we should understand is that each and every individual in the team is equally important and valuable for the team’s success. A team is not a team without its people, if we do not value our team members’ personal life and well-being, they will never value the company or the products they work on.   In my team, we give due respect to individuals’ personal life. I don’t remember a time when anyone in my team was on leave and we called them for work, unless it was an emergency and couldn’t wait until the individual was back to work. One thing to understand is that an individual has voluntarily taken personal time off, that itself is an indication that he or she wants to be away from work, we don’t do any good by bombarding them with queries or favors to get work done while they are officially on leave. Also, denying leave is a thing of the past, these days I see emails floating in my company urging people to take break from work and spending time rejuvenating.   But this comes with a responsibility from the individual's’ side as well. In my team, we send details of any planned vacations as soon as we plan them, even if it is a month or two in advance. This not only makes everyone aware of your probable absence but mentally prepares everyone for it and any foreseen dependencies can be mitigated well in advance.   4- Empower teams and people With great power comes great responsibilities, and this aspect not only requires an open leadership but also a set of matured team members. When we empower people to take up responsibilities, not only things move faster towards completion, but we instill a sense of ownership within everyone. It motivates teams to take the right decisions for the success of the product. They manage their work as a group, they may still require mentoring and coaching but do not require command and control.   In my team, we ensure everyone owns some or the other part of the application from the code perspective or own a part of the process such as cybersecurity, defect tracking etc. This way we not only involve everyone while we take the product to completion, but we also ensure that every individual considers themselves an intrinsic part of the team and not just a resource working on code.   5- Appreciate and recognize teamwork and attitude Continuous appreciation for work well done, acts as the catalyst for multi-fold growth of a team and its members. Appreciation motivates people not just to do what they have been doing and but to do that more. Quoting a very unique observation by one of my leaders about my team,   “Keep up the great work that you all have been doing. It is great to see that you all work for each other’s success and go beyond boundaries to help each other achieve their goals, while focusing on your own priorities.”   These few lines of encouragement for the team, not only made the team bond better but they induced comradery and the “we are one” attitude; ultimately making the team more cohesive and efficient. So, appreciating the right attitude and teamwork is far more important and shall always precede over individual recognition. In most of the cases it is never a single hand, but always a team effort behind a successful outcome and a happy customer.   6- Deliver value and not just user stories. One of my fellow agilist Kalpesh Shah talks about not being Backlog Lumberjacks, and instead deliver value and think about outcomes for our users. The team should be delivering value and not just running the race for story points. As leaders, we shall never consider story points as a means to judge a team’s success or failure, they should only help the stakeholders keep a track of the timelines. If a lot of importance is given to completing more story points, it might lead to development of a software which has a lot of stories implemented but none of the features ultimately add value to the user and help them do their job well. Value shall take precedence over story points.   7- Processes are to help. Many times, we fail to understand that processes are there to help us do our jobs better and faster. In my team, if anyone feels that a process is stopping us from doing things better or faster, we simply get rid of it. If we do not see any repercussions of that, we continue or else, we change, try something new and repeat. The whole concept of Agile is to change for the better, and that is what we continue doing in my team. This not only delights the team but also makes them believe in the system.   8- Aim at product development and not just software development. When we build software, we think about features, but when we create products we think about usable features. That is the mindset we shall bring about in every individual within the team. I was once a part of a review meeting with a scrum team, and the discussion was going on about a feature being no value add for the user. I was shocked and surprised to witness one of the engineer state that he needs to get his tasks completed for the scrum update tomorrow and isn’t bothered about what will be used or not. Even if we add a feature which makes the software smart, but it is never used by the users, it adds no value. Grooming individuals to question the status quo and work with a product mindset is a must for the ever-changing competitive market. All in all, it is not about etching rules on stone, but setting the ideas and thoughts in practice and that's what makes it an amazing challenge for each one of us out there looking for making their teams self-organized.   
Rated 4.0/5 based on 20 customer reviews
Self-Organization: The Linchpin of a Successful Ag...

The biggest paradox of a Scrum Master’s role is ... Read More