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

343
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

Join the Discussion

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

Suggested Blogs

Scrum Master and Product Owner: Understanding the differences

 Agile methodology imparts the easy and convenient path to work. Scrum is one of the famous Agile methodologies. Agile methodologies consists of 4 main roles, viz. Product Owner, Scrum Master, Scrum team and Stakeholder. Each role has its share of responsibilities. These roles are all about commitment. Scrum master and the Product owner are two vital roles in the Scrum Software Development Methodology. Since they both are working on different areas of the project, they are indispensable for the project. Scrum Master is a mediator between the Product owner and the Development Team.       Product Owner vs Scrum Master- Though the Product Owner and the Scrum master vary in their roles, they complement each other. Scrum master should support the product Owner in every step possible. There should be an amicable relationship between the Product owner and the Scrum master. Disputes may happen between them if the roles are not clarified. Let us have a look at the differences in roles between the product owner and the scrum master. The Scrum Master concentrates on the project success, by assisting the product owner and the team in using the right process for creating a successful target and establishing the Agile principles.    Scrum Master Skills (SM): SM creates a friendly environment for the team for Agile development. SM improves the quality of the product. Certified Scrum Master Certification, adds advantage to become effective. SM protects his team from any kind of distraction and allows them to stay tuned. SM helps product owner to maximize ROI (return on investment) to meet the objectives. SM removes disputes between the product owner and the development team. SM encourages the team to meet the project deadline. SM acts like a coach for a team to perform better. A good Scrum Master should possess the skills like project management, engineering, designing, testing background and disciplines. SM provides continuous guidance to teams   Duties of Scrum Master: SM facilitates team for better vision and always tries to improve the efficiency of the teams. SM manages Scrum processes in Agile methodology. SM removes impediments for the Scrum team. SM arranges daily quick stand-up meetings to ensure proper use of processes. SM helps product owner to prepare good product backlog and sets it for the next sprint. Conducting retrospective meetings. SM organizes and facilitates the sprint planning meeting. The Product Owner’s responsibility is to focus on the product success, to build a product which works better for the users and the customers and to create a product which meets business requirements. The product owner can interact with the users and customers, stakeholders, the development team and the scrum master.   Product Owner Skills (PO): PO should have an idea about the business value of the product and the customers’ demands. Certified Scrum Product Owner Certification (CSPO) will be beneficial for the sales team. The development team consults PO, so he should always be available for them to implement the features correctly. PO should understand the program from the end-user point of view. Marketing is discussed on the sales level in most of the Organizations. So it is the PO’s duty to guide the marketing persons to achieve the goals successfully. PO is responsible for the product and the ways to flourish a business. PO has to focus for the proper production and ROI as well. PO should be able to solve the problems, completing trade-off analysis and making decisions about business deliverables. After CSPO course, PO can work with the project managers and the technical leads to prioritize the scope for product development. Sometimes PO and the Customers are same, sometimes Customers are thousands or millions of people.   Duties of the Product Owner: PO has to attend the daily sprint planning meetings. PO prioritizes the product features, so the development team can clearly understand them. PO decides the deadlines for the project. PO determines the release date and contents. PO manages and creates the product backlog for implementation, which is nothing but the prioritized backlog of user stories. PO defines user stories to the development team. Spending some time to prioritize the user stories with few team members. One can enhance his/her knowledge in many directions and beyond boundaries, after undergoing the Certified Scrum Product Owner (CSPO) training.
Rated 4.0/5 based on 1 customer reviews
2742
Scrum Master and Product Owner: Understanding the ...

 Agile methodology imparts the easy and convenien... Read More

The Increasing Role and Importance of Scrum Masters

The presence of an experienced and skilled Scrum Master is an important part of the success of Scrum teams. He is responsible for overseeing the correct implementation of the Scrum Framework and ensures effective product delivery by his team. This article throws light on the role and importance of Scrum Masters in context to prevailing job markets.   Increasing use and popularity of Scrum The Scrum Framework is fast becoming an indispensable component for projects involving agile methodology. A recent survey undertaken by Version One 2016 reveals that over 58 percent teams are using the pure Scrum approach; while 75 percent teams are including hybrid agile approaches(e.g. a combination of Scrum with Kanban to create Scrumban) to enable successful project deliveries. Given these figures, and recent growth trends in the IT industry, it is no small wonder that the job profile of a Scrum Master has scored a ranking of #10 on “LinkedIn’s list of The Most Promising Jobs for 2017. The role has been assigned with a median base salary of $100,000 USD. With the predicted year-over-year job growth being 400%, base salaries are expected to reach higher levels as the demand for Scrum Masters increases.     Role and importance of a Scrum Master According to a much-quoted role definition by Tech Target, a scrum master is responsible for the overall facilitation of his agile development team. He uses the potential of Scrum; specifically as a methodology that permits any team to make changes and self-organize itself quickly, and in accordance with laid down agile principles. A skilled Scrum Master has in-depth understanding of the software delivery processes of his organization and knows how to implement the steps needed for bringing products to the market. He has the ability to connect, build and retain relationships with team members and all stakeholders. In the role of a Scrum Master, he also understands the importance of other agile approaches such as XP, Kanban, Lean, etc. He readily involves team members with setting up processes, recognizes and takes action on team conflict, and dares to take up a disruptive approach. A Scrum Master is responsible for training agile teams in a way that helps them remain on a clear path to success. He encourages ownership, shares experiences, and coaches professionally. With a strong understanding of all components and processes, an adept Scrum Master helps team members interpret agile concepts and methods in effective ways. This role also incorporates proper transmission and management of information across all channels; facilitation of meetings with product owners to ensure smooth development and deliveries; removal of all impediments to progress, etc. Certification courses for Scrum Master by Scrum Alliance Certified Trainers (CSTs) Comprehensive understanding of the critical areas of change linked with Scrum Framework – Self-Management, Iterative Development, and Visibility -are essential for aspiring Scrum Masters to perform the above-mentioned roles effectively. With this in view, individuals with prior knowledge of agile methodology and Scrum Framework are opting for training for CSM or Scrum Alliance Certified Scrum Master Certification as well as PSM or Professional Scrum Master Certification.   Way forward Do you desire to don the rewarding role of a Scrum Master? Do you have it in you to blend technology, leadership, and different business acumen to deliver great work? Make the most of your existing knowledge of Scrum and related methodology by honing your skills even further. You may like to acquire new credentials by enrolling for a Certified Scrum Master certification at the earliest.
Rated 4.0/5 based on 20 customer reviews
The Increasing Role and Importance of Scrum Master...

The presence of an experienced and skilled Scrum M... Read More

Best Ways To Split User Stories For Efficient Product Backlog Refinement

Product Backlog and User Stories: Product Backlog is an essential artefact of Scrum Framework. It comprises of a list of items (referred as PBI) that are planned to be implemented in the future. PBIs are generally in the form User Stories. A user story is the concise representation of a functional or technical requirement of a system. Writing appropriate user stories forms a strong base for achieving the sprint goals successfully and progressing towards the product vision eventually. "If you want to know more about a 'user story' you may also watch“ INVEST  The attributes of a well formed user story goes by the acronym INVEST, which was coined by Bill Wake in his book "Extreme Programming": Independent - Each story should be atomic and not dependent on any other stories Negotiable - Should have scope to allow negotiation between the scrum team and business team on the grounds of technical , functional  and budget constraints and modify itself accordingly Valuable - Must deliver some value to the stakeholders. If it is a functional user story, then there should be provide some business value , whereas technical user story should focus on architectural and non functional improvements. Estimable - Team should be able to arrive at a fair estimation for implementing the user story in terms of story points.  Small - Should be small enough to plan and implement within a sprint Testable - Should have a clear acceptance criteria , which gives the team all the necessary information to test every possible flow.   Product Backlog Refinement Product owners have to maintain a healthy backlog by frequently grooming the user stories in it. In the grooming sessions (Product Backlog Refinement), PO discusses with the team and work on improvising the poorly written user stories, breaking down the large user stories into manageable size, adding more clarity to the acceptance criteria , prioritizing the user stories and estimating them. As a Scrum Master, we should guide the team and PO in this backlog refinement activity by aiding them with the best practices in writing user stories of right size and prioritization. User Story Splitting Splitting user stories is a significant task in product backlog grooming. A user story should be neither too small nor too big. It has to be sized appropriately , in such a way that , the implementation of it could be decomposed into one or more tasks. All the tasks planned must be completed within a sprint. Generally , user stories of size more than 8 or 13 story points are split further. However this number may vary from one scrum team to another based on their capacity and velocity. Benefits of splitting a story: Smaller is always better. User stories of relatively less story points are  * Easy to understand and groom * Leads to accurate estimation * Results on quicker implementation * Aids thorough testing   Size of an user story is said to be optimal if it could be implemented within 0.5 day (half a day) to 10 days. Methods of splitting :  A user story can be split: Horizontally - through architectural tiers as one layer at a time Vertically - as functional pieces across all the layers at a time. The horizontal layers split accordingly can be further divided as tasks. A common metaphor used to differentiate both these methods is cutting a cake layer by layer ( horizontal) and portion by portion of all the layers (vertical). Only by tasting a portion of all the layers, one would be able to feel the essence of the entire cake. Same is the case with story splitting. Vertical (Functional) splitting is more valuable than the horizontal one. Advantages of vertical splitting: Dependencies and risks could be identified at an earlier stage Nice to have features can be segregated and deferred for later sprints Considerable progress can been seen on functional part every day, whereas in horizontal slicing no benefits are seen until all related stories are complete Leads to quicker testing and faster feedback loop - in horizontal , need to wait until all the dependent stories are done  Helps to prioritize based on incremental value Techniques for splitting stories vertically: User stories can be split vertically based on the following patterns: Generic Terms: If an user story has more generic terms, then there is a possibility to split it vertically.  For eg : As a library member, I want to search the availability of various kinds of books for children and share it with my network. Here, "various kinds" , "share it" are more generic terms. They provide a way to split the story incrementally as below : * Develop a UI that displays all the book categories when a registered library member login * Provide a search functionality to the member, where in results are also categorized such as "fiction for kids under 10", "fiction for kids 11-15" and so on * Enable to users to share the result via email, whatsapp etc Connectors : If the user story is represented using a compound sentence, then it is obvious that it can be split vertically. In such cases, look out for conjunctions in the user story like "and, or, as well as, when, if" and split it based on these connecting words or conjunctions like : and, or, if, when, but, as well as. Acceptance criteria:  Read out the acceptance criteria; if it is too complex and some parts of it can be pulled out and developed as an independent user story, follow the same. Eg:  As a senior associate  of the organization, I want to register for the in house training programs so that I can attend the trainings and upskill myself. Acceptance criteria :  All the senior associates must be informed about the training programs through mail. Senior associates should be able to submit their details through a form for registration. Mail confirmation must be sent on successful registration. In the above scenario, each of the criteria can be designated as a separate user story. Workflow steps:  Identify the workflows that connect different roles for a specific function, and if they can be completed independently split them as a separate user story. Eg: For an assignment approval system in a school, the following can be the possible user stories        As a student, I should be able to submit my assignments to the teacher for grading         As a teacher , I should be able to view the assignments submitted by the students        As a teacher, I should have the UI to request for more clarifications Apart from the above, below are the other patterns based on which user stories can be split vertically: Operations - Create, Read, Update, Delete operations required for a functionality Business Rules deviations Variations in Data given as input to the system Variations in User Interface Spikes - If there are many unknowns in a user story and it requires research for uncovering the grey areas, then create spikes to get the insights of the user story. Based on the spike's outcome, we can proceed with the implementation of actual user story. Best practices for story splitting: * Do not split the stories too early - split just in time, when it's priority for implementation is high. * Do not compromise quality / non functional requirements - NFRs must be taken into consideration while splitting. If having a choice between a couple of user story splitting strategies, prefer the one that will result in similarly sized sub-stories. — Wojciech Zawistowski (@velesin) May 29, 2015 * Ensure that there is no feature debt - splitting should not leave out any functionality without implementation. * Story splitting is not a task to be owned by the PO alone - Along with the Scrum Master, other team members also give their view on best possible ways to split the stories as they are the actual persons who are going to develop the stories into working functionalities.
Rated 4.0/5 based on 16 customer reviews
Best Ways To Split User Stories For Efficient Prod...

Product Backlog and User Stories: Product Backl... Read More

other Blogs