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 278
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 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!!
  • 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?
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’ 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

Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum implementation in an organization. The entire effort of transforming teams with Agile ways of working is bound to fail if the role of a Product Owner is not understood clearly. Listed below some of the anti-patterns seen while the person is playing the role of a Product Owner in a team- Busy or Missing Product Owner, not being part of the development team Working software demo to the PO during Sprint Review Expressing the backlog in Technical user stories instead of focusing on business-related user stories Writing detailed user stories (no scope for negotiation) Questioning the estimates given by the Dev Team Not having a clear acceptance criteria for every story Too large user stories Not questioning the customers while collecting the requirements Not allowing the Dev Team to work on Technical Debt Not validating the customer’s idea before implementing the idea Not allowing Development Team members to talk with the Stakeholders directly Not empowering the Proxy POs Lack of vision on the product being developed Delivering more features than valuable features Not having well-defined prioritization mechanism in delivering user stories Changing priorities or requirements during the Sprint No single Product Owner, required governance missing in case of multiple POs Missing in Scrum Ceremonies Relying on mail communication for answering queries from Dev Team No emphasis on Quality Treating estimates as deadlines Instructing team on what needs to be done, acting as a Manager Expecting user stories to be created by team, considering SM and PO to be there only to review the stories Pushing team to do extra work for finishing everything forecasted during Sprint Planning Holding the team responsible for any rework post feedback from stakeholders during Sprint Review  Not showing interest in answering team queries for clarifications after Sprint planning Task monitoring Not coachable by Scrum Master Unable to prioritize the work Consistently changes priorities during the Sprint Accepting partially completed PBI’s Allowing dev team to change the Story points of a user story post implementation Not saying “No” to the stakeholders and allowing the product backlog to grow in size   There's nothing more paralysing than a Scrum team with a bad Product Owner! The characteristics stated above lead to nothing but a Product Owner “Fishbowl” where new ideas and innovative thoughts pertaining to Scrum processes find no entry at all.  The Product Owner  is... The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. It’s a one-person role that brings the customer’s perspective of the product to a Scrum Team.  The Product Owner is responsible for:  Developing and maintaining a product vision and market strategy Product management  Ordering and managing the Product Backlog  Involving stakeholders and end-users in Product Backlog refinement and backlog management  Alignment with other Product Owners when needed from an overall product, company or customer perspective.  #MostPopular in 2017: "Product Owner Anti-Patterns — 31 Ways to Improve as a PO" https://t.co/sryCdoxVKu pic.twitter.com/q5Sxj9kF6F — Stefan Wolpers (@StefanW) 22 December 2017 A GREAT PRODUCT OWNER…  Grasps, shares and spreads the product vision: A great Product Owner acts as the client's voice (also called a proxy-client at times) and makes a product vision together with the stakeholders. Each choice is taken on account of the product vision. This guarantees sustainable product improvement, gives clearness to the development team and expands the chances of product success definitely. Understanding the customer’s goals: A great Product Owner truly understands the customer’s goals with the product and is able to outpace its expectations. After all, pleasing the customer is the ultimate goal. Is a good decision maker: A great Product Owner is an authorized person to take product-related decisions. It may take some time to support his/her decisions, but this is an essential condition for an economical pace of the development team. Manages the product backlog: A great Product Owner comprehends that the product backlog should be in sequence. Priority, risk factor, quality, getting to learn and dependencies are all considered and balanced with each other. Prefers one-to-one communication: A good Product Owner believes in one-to-one communication to convey information. User stories are used as a medium of conversation. Knows modeling techniques: A great Product Owner has a knapsack full of worthful modeling techniques. Actually, the PO has an idea about when to apply a specific model. Based on the model application he/she drives the project success.  Shares experiences: A great Product Owner offers experiences with peers. This may be inside the organization, and outside it. Additionally, courses and meetings are the great approaches to share experiences and garner information. Furthermore, recording your lessons can be significant for other Product Owners. Claims user story mapping: A great Product Owner should ace the idea of user story mapping. It is a method that enables you to add a second dimension to your backlog. The visualization empowers you to see the master plan of the product backlog. Keeps an eye on functionality: A successful Product Owner keeps an eye on functional as well as on the non-functional aspects of the product. The motto of the Product Owner is to exceed the quality expectations the customer and enabling functionality that provides value to the product. So, the functionality is the main focus of the Product Owner.  Is knowledgeable: A great Product Owner has a deep product knowledge and comprehends the technicality. Larger products might be difficult to understand and scale. In this case, the PO should know the formula to solve the large queries.   Comprehends the business domain: A great Product Owner knows the ins and outs of his domain. A product should be built with a clear idea of every aspect being dealt with. This not only entails understanding the organization and paying for the development but also being aware of the current market trends. No matter how great your product is, shipping it after the window of opportunity closes is a waste of time and barely of any value.  Acts on different levels. A great Product Owner is capable of acting on different levels. These levels are popularly denoted as- strategic, tactical and operational. At the board level, a PO should know how to demonstrate the product strategy. Thereafter, he should create a strong support at middle management and facilitate the development team to cope with their daily challenges.  Knows the 5 levels of Agile planning. Within Agile, planning is done continuously. Every product needs a vision (level 1) which will provide input to the product roadmap (level 2). The roadmap is a long-range strategic plan of how the business would like to see the product evolve. Based on the roadmap, market conditions and status of the product the Product Owner can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on Product Backlog Items they are confident they can complete during the Sprint and help them achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team's progress towards realizing the Sprint Goal.  Is available. A great Product Owner is characterised by his availability to the stakeholders, customers, development team and most important, the Scrum Master. This helps important questions to be answered quickly and valuable information to be provided on time. The Product Owner always makes sure that his availability never becomes the bottleneck of the progress of the development team.  Is able to say 'no'. A great Product Owner knows the best time and way to say “no”. This indeed is a difficult trait to master. While it is easy to give any new idea or feature the nod, there is a flip side. Good backlog management necessitates creating a manageable product backlog with items that will mostly get realized. Appending non-productive items to the backlog will only create false expectations.  Acts as a "Mini-CEO". A great Product Owner basically is a mini-CEO for his product. He has a sharp eye for opportunities, focuses on business value and the Return On Investment and acts promptly on all possible risks and threats. Every growth aspect such as size, quality, market share of the product is taken into consideration.  Knows the different types of valid Product Backlog items. A great Product Owner can clarify the fact that the Product Backlog consists of more than only new features. For example, technical innovation, bugs, defects, non-functional requirements and experiments, should also be taken into account.  Takes Backlog Refinement seriously. A successful Product Owner spends sufficient time refining the Product Backlog. Backlog Refinement is essentially the act of adding detail, estimates and order to items in the Product Backlog. The result should be a Product Backlog that is granular enough and easily understandable. On an average, the Development Team spends no more than 10% of their capacity on the refinement activities. There is no such prescribed approach. The Product Owner can also involve stakeholders and the Development Team in backlog refinement. Each for a valid reason. The stakeholders are given the opportunity to state their expectations. The Development Team can clarify functional and technical implications. This will ensure a holistic understanding and enhance the quality of the Product Backlog considerably. Consequently, the opportunity to build the right product with the desired quality will also increase.  Concluding Thoughts: A Product Owner is indispensable for a functional Scrum team. He not only bridges the gap between the development team and the client but also ensures a streamlined product delivery. Ill-defined Product Owner roles and some of the critical PO anti-patterns are some of the impediments many of the Agile organizations are battling at present. The only long-term solution to such persistent issues is a clarity of PO roles and a proper understanding of the end-to-end Scrum processes. 
Rated 4.0/5 based on 7 customer reviews
Product Owner Anti-Patterns You Should Be Aware Of

Product Owner plays a very critical role in the success of Agile/Scrum... Read More

Project Manager Vs Product Owner

Traditional waterfall projects had the Project Manager unquestionably at the helm of the ship. Today, as more companies migrate toward agile, the role of the Project Manager has become redundant. Agile advocates team work — wherein there are self- organizing teams, and much of the responsibility that was earlier shouldered by the Project Manager is shared by the group. In an agile environment, the Product Owner owns the product, the Scrum Master owns the process and the team works together toward fulfilling the tasks. In a traditional project, the Project Manager holds all the cards and owns the entire project. Today, Project Managers need to redefine their responsibilities in the agile context, and depending on their inclination frequently take on the mantle of the Product Owner or ScrumMaster. There has been much heated debate on this topic in many online Scrum forums, with differing results … but research shows that there is no definitive answer that squarely references the PM to the PO. While Scrum rejects the role of a Project Manager per se, there are many who believe that this role has been reframed to include the two roles of a Product Owner and a ScrumMaster. The ScrumMaster is by definition a servant leader. The Product Owner, by definition, is the person who represents the business stakeholders and keeps the team focussed on the product itself. As a Product Owner, his or her job is to tell the team what to do…but not how to do it. The ‘how’ is decided by the team members themselves. And that, in a large part, sums up the difference between a Project Manager — who needed to spell out the Hows, Whats and Whys — and the Product Owner, for whom only the definition of the problem…or the What… is all-important. In Scrum, there is no single management position. And that’s where the beauty of Scrum, and perhaps its efficacy, lies. Scrum teams are self-managing, and when each member of a Scrum takes on some responsibility, the project has a much higher chance of success.
Rated 4.0/5 based on 20 customer reviews
Project Manager Vs Product Owner

Traditional waterfall projects had the Project Manager unquestionably ... Read More

Career Path Of A Scrum Product Owner

A scrum product owner has the dual capability of foresight and the decision-making power to make a project successful. A Scrum Product Owner will work on the product for its entire life-cycle and hence will have an idea of how things need to be prioritized, managed and executed. This decision-making and communicating power capability can be obtained by undergoing a CSPO certification program and the experience will enable the candidate to access a wide range of career opportunities. Listed below are some of the great career paths that await a Scrum product owner. 1. Business Analyst: Product Owners are well-suited for a business analyst profile as they have adequate knowledge on how to handle the business requirements and supplement with analysis and thus enable better decision-making. This knowledge can be used to improve the business and hence being a business analyst would be a great career path out there to choose from, after being a product owner. 2. Project Manager: The role of a Project Manager is another great career path that is available to a product owner. The candidate will be involved with project planning and management. This role is usually available after being a business analyst, and there are many companies out there who look out for Project Manager Candidates with the Scrum certification. 3. Product Manager: The other direction you can choose is the product management side where you will get to focus on expounding requirements for a product based on strategic requirements and product-market fit. The path to this position can be prolonged as it requires you to be a business analyst first and also have a Master of Business Administration Degree (MBA). But once pursued, this will work on to be one of the best career paths. 4. Chief Executive Officer (CEO): Senior Product Owners have a great probability of becoming the CEO of a company. Though this requires a lot of experience, perseverance and demands lots of time. The experience gained from being a product owner is a valuable asset as you get to learn about how to make the product successful, how to enliven the team, how to be dedicated, how a high return on investment can be achieved, how to engage the customers, etc. All these qualities are what is being looked for in a CEO, for managing the whole company and for taking it towards a great success path. So the product owners have got a great career prospect here! So go ahead! Take a course in CSPO (Certified Scrum Product Owner), become a great product owner and expose yourself to a wide range of sumptuous career paths.
Rated 4.0/5 based on 20 customer reviews
Career Path Of A Scrum Product Owner

A scrum product owner has the dual capability of foresight and the dec... Read More