Search

Make Your Agile ‘WAIT’ Visible & Worthwhile

Waiting for something or someone is one of the most annoying things in life. I’m sure all of you have faced such situation in a real life. How about waiting nervously till your examination results arrive? How about waiting for your fiancé or fiancée to come and meet you? And how about waiting till you get your increment or promotion? Strenuous and frustrating isn’t it? It just eats you away minute-by-minute, day-by-day fretting away at what might just be a risky unknown.Well, waiting is a common thing. May it be personal life or even when executing software development projects. This is no difference even in a change-driven Agile project. In Agile terms, waiting is the result of an impediment of any shape or form.So what is an impediment?The dictionary definition of an impediment is ‘a hindrance or an obstruction to doing something’. In Agile terms, an impediment is ‘anything that is slowing down the team’. In PMP terms an impediment is ‘any kind of issue’. An impediment simply makes an Agile team wait!!So, what can make an Agile team wait?An Agile team may end up waiting forInformationResources; human or non-humanAnother task or a featureAdviceFeedbackTools or TechnologyManagement decisions, or lack of itWork environment itselfAbove are just some reasons while a team may get blocked from achieving their objectives. It will stop them from getting things ‘Done’ which finally affects their velocity.So what should you do with the thing that makes you wait? Let’s take a look at it next!!Making the ‘wait’ visibleA core concept in Agile is to make everything transparent and visible. We achieve this mainly by showing things in the information radiator (or our scrum board) or by discussing things during the scrum ceremonies. Here are a few things that you can do to make the ‘wait’ visible.Add a ‘waiting’ column to your scrum board – Move the tasks or user stories that are blocked to a swimlane named ‘waiting’ and make it visible for everyone as soon as you identify it. Don’t wait!!The swimlane alone does not suffice. Add some more notes (in coloured sticky notes or cards) with information such as why it is blocked, who are you waiting for, what are you waiting for, when do you expect a resolution, how the impediment will be removed, and what is the impact etc.Notify the relevant stakeholders about the impediment – Your scrum master is your ‘Protector’. Make him aware of all your impediments as soon as you identify it. Bring it up during the immediate daily scrum meeting so that the scrum master can identify a way forward and facilitate a process to resolve the impedimentMaking the ‘wait’ worthwhileIt’s all good to identify and highlight impediments as explained above. Action or steps to find solutions for these impediments will take some time. In software development, a minute wasted may result in delays in project timelines that may have detrimental consequences on time, cost, and scope. So, how can you make the wait worthwhile?The team members blocked must make maximum use out of the waiting time. Below are some of the paths that he or she can tread while ‘waiting’.Add more information as to why you are waiting. Information and collaboration is the key to resolving issues. The more guidance and information that can be provided on the issue itself will make it easier for the assignee to resolve that blocker.Move on to another task – If there is nothing else to do on the item blocked then just move on and keep the flow of other tasks going. Agile stresses on the progress of stories and tasks in a sprint on a daily basis and you will achieve this only by working on the other tasks.Help others or get help – Don’t be shy!! Collaboration and communication is the key in Agile. Work with team members to either solve the issue or help them resolve the blocker.Research on the root cause of the blocker or on a resolution for the impediment. Agile teams need to be innovative and this is the best way of making use of ‘waiting time’ judiciouslyThe following video will give you a clear picture of the impediments encountered by Agile and Scrum teams.ConclusionImpediments and wait is an inevitable thing in Agile projects. It is up to the team members to identify the best way to identify, record, manage, update and resolve impediments. Agile principles and values provides guidance on what needs to happen but it is up to the team to ascertain what works well for the team while ‘waiting’.So, happy waiting to you!!
Rated 4.5/5 based on 3 customer reviews

Make Your Agile ‘WAIT’ Visible & Worthwhile

308
Make Your Agile ‘WAIT’ Visible & Worthwhile

Waiting for something or someone is one of the most annoying things in life. I’m sure all of you have faced such situation in a real life. How about waiting nervously till your examination results arrive? How about waiting for your fiancé or fiancée to come and meet you? And how about waiting till you get your increment or promotion? Strenuous and frustrating isn’t it? It just eats you away minute-by-minute, day-by-day fretting away at what might just be a risky unknown.

Well, waiting is a common thing. May it be personal life or even when executing software development projects. This is no difference even in a change-driven Agile project. In Agile terms, waiting is the result of an impediment of any shape or form.

So what is an impediment?
Impediment in Agile TermsThe dictionary definition of an impediment is ‘a hindrance or an obstruction to doing something’. In Agile terms, an impediment is ‘anything that is slowing down the team’. In PMP terms an impediment is ‘any kind of issue’. An impediment simply makes an Agile team wait!!

So, what can make an Agile team wait?

An Agile team may end up waiting for

  • Information
  • Resources; human or non-human
  • Another task or a feature
  • Advice
  • Feedback
  • Tools or Technology
  • Management decisions, or lack of it
  • Work environment itself

Above are just some reasons while a team may get blocked from achieving their objectives. It will stop them from getting things ‘Done’ which finally affects their velocity.

So what should you do with the thing that makes you wait? Let’s take a look at it next!!

Making the ‘wait’ visible

A core concept in Agile is to make everything transparent and visible. We achieve this mainly by showing things in the information radiator (or our scrum board) or by discussing things during the scrum ceremonies. Here are a few things that you can do to make the ‘wait’ visible.

  • Add a ‘waiting’ column to your scrum board – Move the tasks or user stories that are blocked to a swimlane named ‘waiting’ and make it visible for everyone as soon as you identify it. Don’t wait!!
    Add a ‘waiting’ column to your scrum board
  • The swimlane alone does not suffice. Add some more notes (in coloured sticky notes or cards) with information such as why it is blocked, who are you waiting for, what are you waiting for, when do you expect a resolution, how the impediment will be removed, and what is the impact etc.
  • Notify the relevant stakeholders about the impediment – Your scrum master is your ‘Protector’. Make him aware of all your impediments as soon as you identify it. Bring it up during the immediate daily scrum meeting so that the scrum master can identify a way forward and facilitate a process to resolve the impediment

Making the ‘wait’ worthwhile

It’s all good to identify and highlight impediments as explained above. Action or steps to find solutions for these impediments will take some time. In software development, a minute wasted may result in delays in project timelines that may have detrimental consequences on time, cost, and scope. So, how can you make the wait worthwhile?
Making the ‘wait’ worthwhileThe team members blocked must make maximum use out of the waiting time. Below are some of the paths that he or she can tread while ‘waiting’.

  • Add more information as to why you are waiting. Information and collaboration is the key to resolving issues. The more guidance and information that can be provided on the issue itself will make it easier for the assignee to resolve that blocker.
  • Move on to another task – If there is nothing else to do on the item blocked then just move on and keep the flow of other tasks going. Agile stresses on the progress of stories and tasks in a sprint on a daily basis and you will achieve this only by working on the other tasks.
  • Help others or get help – Don’t be shy!! Collaboration and communication is the key in Agile. Work with team members to either solve the issue or help them resolve the blocker.
  • Research on the root cause of the blocker or on a resolution for the impediment. Agile teams need to be innovative and this is the best way of making use of ‘waiting time’ judiciously

The following video will give you a clear picture of the impediments encountered by Agile and Scrum teams.

Conclusion
Impediments and wait is an inevitable thing in Agile projects. It is up to the team members to identify the best way to identify, record, manage, update and resolve impediments. Agile principles and values provides guidance on what needs to happen but it is up to the team to ascertain what works well for the team while ‘waiting’.

So, happy waiting to you!!

Rumesh

Rumesh Wijetunge

Chief Innovation Officer - Zaizi Limited, Chief Operating Officer - LearntIn (Pvt) Ltd., Director /

Rumesh is an IT business leader with over 12 years of industry experience as a business analyst and project manager. He is currently the CIO of Zaizi Limited, a UK based data management company heading the operations in Sri Lanka, the COO of LearntIn, a global training institute based in Sri Lanka and is also a lecturer / trainer at multiple private universities on management, IT, business analysis and project management subjects. He is the current president of the IIBA Sri Lanka chapter and is one of the most qualified and sought after trainers in Sri Lanka. Refer his LinkedIn profile for more details and to see more articles he has written on linkedin

Leave a Reply

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

Suggested Blogs

The Importance of the Transparency Value in Agile

1. Introduction In this article I’ll be writing about Agile and the importance of transparency in Agile Software Development.  This article is focused mostly around Scrum teams, but many points would apply to Lean and Kanban environments as well. Transparency is one of the core values of Agile.  Transparency is critical to the success of organizations and groups adopting Agile.  In Scrum we use burndown and/or burnup charts to report the progress of the team throughout the Sprint.  In Scrum we also have “ceremonies” or meetings that help with transparency, which include the Daily Standup, Sprint Planning, Sprint Review, and Retrospective meetings.  These all give the team and product owner a chance to raise issues and be honest about things like the team’s progress.  The meetings also give the team a chance to adapt and improve. 2. Why is transparency important to Agile Transparency in Agile Software Development cannot be overstated.  In some organizations it is not easy to be transparent and open.  There are lots of pressures to say what the business wants to hear.  But I believe in the long-run a lack of transparency hurts an Agile team, the project, the organization, and ultimately the company.  I've seen firsthand organizations that claim they want “openness” but then, I can say that true transparency is not easy.  Transparency is critical to the success of Software Development using Agile Methodology  and it is well worth the effort.  Without full transparency there are lots of bad things that happen, including: Lack of trust with the Product Owner Team has to get caught-up in politics instead of focusing on what needs to be delivered Team morale can suffer Measuring future work is more difficult The team’s true velocity is not known 3. How teams can be more transparent with a Product Owner There are several steps a team can take to prevent the issues raised in the previous section.  In this section, we will cover some of those steps.  Use burndown charts to be honest about how the team is performing in a given Sprint. A burndown chart tells the true story of how the team is performing. Some teams also use a burnup chart for this purpose. If you cliff-dive at the end of the Sprint, that's not the greatest, but at least you are being honest to the Product Owner in terms of what happened.  If you are not going to make the Sprint commitment, at least that will be more obvious during the Sprint (i.e. the burndown will show that the team is not closing enough points each day and is at risk of either cliff-diving or not meeting the commitment). The point is that the team is being completely transparent.  The velocity is what it is.  The product owner knows what the team is capable of delivering. Using the raw data and not hiding anything from the business frees an Agile team. I believe it is Kent Beck that has an excellent quote in one of his presentations about what he calls “schedule chicken.” He tells a story about people around the table during a typical project meeting and the project manager is going around asking each team how things are going. Everyone wants to put on a good face and says “umm, yeah we are on schedule” even when they are not. Now they have to sit there and know that they might be caught in a lie later. Better to just be honest and say “Well, we are about 2 Sprints behind.” Done.  Now there is nothing to hide and you can move on and deal with the reality of the situation you are faced with. There are a couple things that happen when the team is honest with the Product Owner.  The first, as mentioned previously, is the relationship between the Product Owner’s trust in a team and the team’s transparency.  Figure 1 below shows this relationship.   But there is another benefit we get from being transparent: the team’s velocity becomes more accurate.  This can be seen in Figure 2 below.   4. What Product Owners Should Ask If you are a Product Owner what are some of the signs that a Scrum team is not being 100% transparent?   This section will focus on some of the red flags or “smells” that may indicate a team is not being truthful and transparent.  If a team does not want to share their burndown and/or burnup charts, that is an obvious red flag and is simply not acceptable. If the velocity of a team is very static, that may also indicate issues.  This may indicate that the team has a fixed amount of points they will always commit to for a Sprint, regardless of their actual capacity.  More on this in the section below on case studies.  Another possible red flag is when most User Stories have the same point value.  It could indicate that the team is using a “one size fits all” for their estimates.  The Product Owner should not be afraid to press the team if they feel the team is not accurately estimating User Stories.  But you need to ask in a way that is not accusatory. 5. Case studies In one Scrum team I saw a real lack of transparency and it really was not a good experience. Soon after joining this Scrum team, I attended my first Sprint Planning meeting on this team. In the meeting I noticed something odd. Their true velocity was let's say, 40 points, but they would only commit to around 30 points. They would then find a few more stories and put them in the next Sprint. These additional stories were what they would call “a stretch goal”. But they knew their velocity was much higher than what they were committing to. This seemed very wrong to me. It was a total lack of transparency and honesty. Not surprisingly, the team would typically finish the stories in the current Sprint and then work on a few more stories from the next Sprint that they had put aside. For the most part, this was a management decision because they did not trust the team to meet their velocity in a consistent fashion. This led to a lack of transparency with the business, and normal tools like burndown charts could not be trusted. Also, it did not make the team feel very good because they knew they were not being honest with the business. Instead of using this "stretch goal" approach, use the velocity of the team to measure how much work can be done in a given Sprint. Then, based on capacity, commit to what you know your team can complete that Sprint. Be honest about the team’s velocity and don't give into political games about trying “to look good” on some presentation slide. This type of misrepresentation does not benefit anyone in the long run. 6. Conclusion The bottom line is to let the quality of the team’s work speak for itself. Have a consistent velocity, deliver software without defects, deliver business value, and adapt to what the business needs.  This will lead to more trust with the Product Owner and will make the team feel better since they are being 100% honest not having to play any games.  This lets the team focus on what truly matters:  delivering quality software that adds value.  
Rated 4.0/5 based on 20 customer reviews
The Importance of the Transparency Value in Agile

1. Introduction In this article I’ll be writing... Read More

Patterns For Adopting & Spreading Scrum In Organizations

When we talk about adopting any new framework or methodology, we think about how we can incorporate these changes into our organization. We simply cannot impose any change in our organization and get started with it, there has to be some process or ways to incorporate that. Also, there are some ways to incorporate Scrum changes within our organization. There include five activities in adopting the Scrum successfully: Awareness Desire Ability Promotion Transfer So to remember, we call it by the acronym ADAPT.  Let’s now talk about the Patterns of Adopting and Spreading a Scrum: Patterns for Adopting Scrum   Start Small or Go All In Organizations go ahead with it like a Pilot project, like selecting few team members and implementing Scrum with them, It's a ‘Start Small’ pattern. The other approach can be Go All In, which is like the executives are convinced and want the whole organization to implement in one go. Reasons to prefer starting small It’s less expensive Early success guaranteed Avoids risks of going all in Less stressful Can be done without much change Reasons to prefer going all in Reduces resistance Avoids problems within different teams The All-in transition is Quick! Choosing between the two  As recommended by Mike Cohn, one should always Start Small! It involves less cost, and guaranteed early success. Going all in should be in limited cases, only when it’s a quick need. Also, it involves more cost/money as there are a lot of changes in different departments if required. Public Display of Agility or Stealth The next pattern that comes into the picture is whether to Publicize it or not. We can do the Public Display of Agility. In this approach, the organization announces that it is adopting Scrum. This can vary from announcing it in a meeting room to announcing it through the press release. The other approach is Stealth transition. In this, only team members know they are using Scrum until the project is complete.  Reasons for Public Display of Agility Everyone knows that team is doing it and they are more likely to be focussed Operating publicly is a firm statement of commitment You can solicit organizational support It sends a powerful message Reasons for Stealth Transition A chance to make progress before resistance starts It keeps pressure off No one knows until you tell them If no one knows, no one can tell you to stop Choosing between the two As recommended by Mike Cohn, always choose to make a public display of Agility when you are confident and committed to the transition and when you expect a lot of resistance but want to overcome it quickly. In contrast, choose a quiet approach, when you want to do an experiment using Scrum.    Patterns of adoption: "Going Through the Scrum Motions as Opposed to Being an Agile Jedi " https://t.co/tpv9kIVxNU @MichaelNir (via @InfoQ) — Stefan Wolpers (@StefanW) May 16, 2016 Patterns for Spreading Scrum   Getting started with Scrum is one thing, spreading it across the organization is another. Unless you choose an all-in transition, you will need to build upon the successes of the first few teams as you move Scrum to other teams.  There are 3 general patterns given by Mike Cohn that talks about spreading Scrum. Split and Seed This talks about taking a team that has begun to be successful with Scrum and using its team members to seed new teams. It’s typically put to use after the first few teams have successfully implemented and adopted Scrum. By this time, each team member understands how Sprint work and how the ready software is delivered at the end of the sprint.  In Split and Seed pattern, we split one functioning Scrum team into each half of the original team forming the basis of the new team. New people are then added to these split teams to form new Scrum teams.  A large initial team is used to seed as many as four new teams. Collated below are the reasons to prefer Split and Seed pattern. Add teams more quickly Each team has someone with Scrum experience to guide them Grow and Split The Grow and Split pattern involve adding team members until the team is large enough that it can be comfortably split in two. Immediately after splitting, each of the new teams will probably be on the small end of the desirable size ranging five to nine members. After allowing the new teams one sprint at this reduced size, new members are added until each team becomes a large enough that it can also be split. This pattern repeats until the entire organization has transitioned. In following cases, you can prefer Grow and Split pattern. Don’t have to destroy any existing teams Team members feel more continuity from sprint to sprint Internal Coaching The Third pattern of Spreading Scrum is Internal Coaching. In the organizations, there include types of teams. Some teams excel with the new agile approach, while others struggles. On each team, there exists one identified person who understands and implement Scrum successfully. That person is assigned as a Coach for other teams. Coaches were given responsibilities to attend sprint meetings, daily scrum each week and coach other teams. Reasons to prefer Internal Coaching Well running teams do not need to be Split Coaches can be selected for new teams Coaches can move from team to team Choosing your Pattern! In general, consider going with Split and Seed pattern, when in a hurry. It is the fastest way of spreading Scrum. However, if the technology doesn’t support moving people among teams, changing the team members can affect the productivity.  The Grow and Split pattern is simply more natural and direct approach. Consider using this approach if there is no sense of urgency as it is less risky.  Internal Coaching can be used on its own, mostly when the group is large enough and when splitting teams are not possible for the projects.
Rated 4.0/5 based on 13 customer reviews
Patterns For Adopting & Spreading Scrum In Organiz...

When we talk about adopting any new framework or m... Read More

Are You Writing The Best User Stories In Agile?

WHAT IS A USER STORY?A user story is a part of an Agile software development approach to present the details of a requirement from a customer’s point of view. A user story specifies what type of user you are, what you want and the reason behind it. A user story helps to create a simple and short description of a requirement told from the user’s perspective.They generally follow a simple approach for a user story:As a < type of user >, I want < a goal > so that < a reason >.Another approach includes:As a , I want because .Originally, Agile user stories were meant to be very short and simple to write on sticky notes or index cards. They were fixed on tables or walls to simplify their planning and discussions. Therefore, they actively shift the target from writing about features to explaining them. In reality, these explanations are more important than the story is written. We can know them prominently in any major Agile process.What does a user story mean? Let us try to understand with an example.Imagine you are using an app on your phone. Now, you like the app, but you would love to have an additional feature in this app. How would you describe your wish to the developer of the app? You will say something like-"I want to have X functionality so that I am able to get Y benefit."While creating a user story, you write in the exact same way, the only additional information which you need to provide is about the type of user you are.The advantages of user stories can be written at different levels in details. We can write a user story to cover a huge amount of functionalities. These large user stories are generally called ‘epics’. Let us clarify this with a few more examples-“As a user, I can view the license terms before purchasing or subscribing so that I know what I’m getting.”“As an app user, I can read FAQs, so I can get quick answers.”“As a website admin, I want all the offers to get unpublished on the website after 7 days of publishing so that the expired offers are not still listed if I forget to delete them.”In all these examples, it is clear who want the features, what they want, and what benefits they would get with the additional functionality.WHO WRITES THE USER STORIES?Business people are responsible for writing the user stories in a customer-specific language. We have to do this because we want user requirements to be clean and clear to both the development team and the business. The role of a development team is to satisfy the end-user acceptance criteria of the storyboard. In Scrum process, the product owner is responsible to represent the business as well as to finish the activity.WHEN TO WRITE USER STORIES?In an Agile project, User stories are generally written in the end. Usually, writing a user story workshop is held close to the beginning of the project in Agile. Everyone should participate in writing or adding the user stories to the product backlog at any time. If your team members are predicted to deliver the stories, then roughly we have to maintain 3 sprints of user stories in the backlog. The additional aspects of efforts and features are a superset of user stories. In these cases, the product owner team interacts with the development team to split user stories into enough levels.WHY ARE USER STORIES USED IN SOFTWARE DEVELOPMENT?User stories are used because they provide many benefits in software development. Here are some of them.User stories help in delivering value to the customer.User stories talk about the immediate customer needs. Because of this, the features implemented and delivered to the end user is of  the highest value.User stories enable a project to be quickly adjustable.Since user stories help in adding small features one by one, it becomes easier for the developing team to steer towards new direction if it is required.User stories increase the collaboration of end user.Since user stories are short, the people involved in the project need more explanation from the end user to clearly understand the story. This increases user collaboration.User stories are followed by Acceptance Criteria. Acceptance Criteria clarifies the end user that in which situations the story will be fulfilled. They are a list of requirements. They are written in "Given, When, Then" format.Let us see an example for a clearer understanding of user stories. Suppose, there is a story for a website user which goes like this-"As a logged out user,I want to be able to sign in to the website,So that I can see my previous transactions."Now the acceptance criteria for this story can go something like thisScenario: The registered user signs in with a valid username and password“Given I am logged out of the websiteand I am on the Sign-In page.When I fill in the “Username” and “Password” fields with my valid credentialsand I click the Sign-In buttonThen I get signed in to the website”Acceptance criteria help in creating a clear understanding between the developers and the clients about when and how the features will work. The client understands what to expect from the project. And hence, the chances of miscommunication between the parties get reduced.
Rated 3.5/5 based on 4 customer reviews
Are You Writing The Best User Stories In Agile?

WHAT IS A USER STORY?A user story is a part of an ... Read More

other Blogs