Category: Agile Coaching

Scrum Master the (over) protector of the Team – An Antipattern

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do the Scrum Masters feel that they have to always protect the team?

  • The earlier version of the Scrum Guide mentioned the following statement 

“The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team”. 

This was interpreted by most Scrum Masters that they always shield the team from the outside world.

  • What ended up happening was that the Scrum Master became a liaison between the organization and the team. This way the Scrum Master became over-protective of the team and literally assumed the role of a “Dad” or a “Mom” for the team.

Some common observations when Scrum Master becomes overprotective

  • Scrum Master deals with all impediments personally, even when the team members may be able to solve themselves
  • Scrum Master filters feedback from stakeholders. Negative feedback is often not shared with the team. Only the goody-goody ones is shared with the team
  • Scrum Master pampers the team by taking care of all administrative stuff (more like a PMO or a secretary)
  • Scrum Master always becomes a bad-cop when it comes to harsh discussions with any stakeholder
  • Scrum Master prevents the team from failing
  • Scrum mom is not really challenging the team
  • Scrum Master does not enforce boundaries and often remains too flexible with the boundaries
  • “Right or wrong – its my team” behaviour starts getting seen

Negative consequences and what could be done

  • Failure is not the opposite of success. Failure is in-fact a necessary stepping stone towards success. Like parents train their kids by letting go sometimes. Parents prepare the child for the real world by helping the child take up challenges. Scrum Master should allow the team to make mistakes and let go. There is no need to be over-protective. Let the team learn by failing. Scrum Master’s job is to keep showing the mirrors when failures happen.
  • A Scrum Master’s good intentions can become an impediment for the Scrum team’s progress. This is particularly true in the case of an over-protective Scrum Master, when her shielding of the team prevents its members from learning by failing.
  • Scrum Master’s job is to make the team independent and ready to face the world and not make them crippled by handling everything
  • The greatest success of the Scrum Master is to see his/her team not needing a lot of bandwidth from the Scrum Master.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/scrum-master-the-over-protector-of-the-team-an-antipattern/

Scrum Master the solver of all impediments – An Anti Pattern

What is an antipattern? – An idea which seems good but has more negatives than positives. Click here to read the definition of Anti-Pattern.

Why do people feel that Scrum Master should solve all impediments

  • In the 2017 version of Scrum Guide the accountability of the Scrum Master was mentioned as “Removing impediments to the Development Team’s progress;”. This sentence was often misunderstood and it was assumed that Scrum Master is the one who runs around and solves impediments.
  • The term “Facilitator” is commonly misunderstood as a “coordinator”. Most teams come from a waterfall background and are used to having a Project Manager. In most organizations, the Project Manager is nothing more than a PMO who coordinates and does administrative activities. The essence of facilitation is to make it easy for the team to get to conclusions and decisions. Impediment solving is only one aspect of the Facilitation.
  • Most organizations implement Scrum Master as a replacement for the PMO responsibilities and expect Scrum Master to run around and solve impediments.
  • From the outside, this looks to be a great idea to have developers do the work and Scrum Master run around and get the administrative stuff done.

Negative Consequences of having a Scrum Master solve all impediments

  • One of the fundamental elements of Scrum is “Self Management” where the team manages itself. The Scrum Master’s job is to teach the team to be self managed and cross functional so that they can get the work done.
  • Team members other than the Scrum Master might be better qualified to solve an impediment
  • People often then shrug off their accountability and expect Scrum Master to be the PMO and even solve problems which they could solve internally
  • Problems are often too complex to be solved by one person and therefore Scrum Master may not be the correct person to solve the problem
  • Viewing an impediment from different angles helps to find effective solutions
  • Many problems have to do with the way how people work together, solving such a problem cannot be done by one person

What could be done to avoid this anti-pattern

  • The first line of defence for the team should be the team members themselves. The Scrum Master must teach the team to do this and not push everything into Scrum Master’s plate
  • The Scrum Master should not get overloaded with solving impediments. The Scrum Master should be an observer, a coach and making sure that facilitation is done.
  • For impediments which actually need Scrum Master’s help, only those Scrum Master should focus his/her attention on.
  • Scrum Master should use his anticipation skills to anticipate issues so that the team can start looking for solutions a little bit in advance.
  • In short, Scrum Master should become a coach and facilitator rather than just being a PMO.
  • To clarify the actual accountability of Scrum Master with regards to impediment solving, the sentence has been reworded in the 2020 version of Scrum Guide to “Causing the removal of impediments to the Scrum Team’s progress” – which essentially means that it is not necessary that everyone just dumps all impediment solving on the shoulders of the Scrum Master.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/scrum-master-the-solver-of-all-impediments-an-anti-pattern/

Myth about Scrum only being useful for small projects

It is a common mis-conception that Scrum is only useful for small projects.

The fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution. Read more to find out more

It is a common mis-conception that Scrum is only useful for small projects.

The real fact is that Scrum is used for solving complex problems. Complex problem is a problem where there are “unknowns” about requirements or the solution.

For solving complex problems, the decisions have to be taken based on what has been done in the recent past. It is extremely difficult to base your decisions based on long-term assumptions. This way of solving problems is called Empiricism or Empirical process control. Scrum is a framework based on Empirical Process Control Theory and therefore, used for solving complex problems.

A complex problem may be big or small. Therefore, the size of the problem has nothing to do with usage of Scrum or other frameworks/methods. A few examples of massive complex problems

  • Merger or separation of a bank – When two banks merge or separate, there are a lot of unknown factors on the products in the resultant merged or separated bank. For example, one bank may be a risk-taking bank have an investment product based on a mix of equity, commodities, and derivatives, whereas, second bank might have a more conservative approach based on fixed-deposits, company-fixed-deposits of blue-chip companies and debt market involving only government securities. Now what would be the product applicable for the new merged bank? Would both products be offered by the new bank or would they be another combination product, or if the merged bank carries the image of the conservative bank then should it even offer the risky product? There are a lot of unknowns here. Would the image of a new merged bank be conservative or risk taking? Would the customers of the risk-taking bank accept the conservative products? Would the customers of the conservative bank accept the risky products or accept a risky profile of the new merged bank? This is an example of an unknown scenario. Unless things are tried out, there is no way you could take decisions. As a business, you may try various combinations, but the answers are possible only after trying different products and taking feedback from customers.
  • Development of a medicine or vaccine for an unpredictable disease – The whole world grappled with the Covid-19 pandemic in 2020. The solution to solve this problem was two-fold – either develop a vaccine to prevent the disease or develop a medicine to kill the virus if anyone gets infected. Both were big unknowns. How the infections spread was unpredictable and also how the disease affects the patients was also unpredictable. Scientists and researchers had no option but to use the trial-and-error approach based on the past knowledge of various viruses. However, the majority of the decisions were based on what was the result of the trails done on various animals and eventually on human beings. Again a complex problem where decision can only be taken based on what has been done in the recent past. The decisions cannot be taken based on long-term planning.

Naturally, the approach for solving these kinds of problems is to shorten your planning horizons, try out things, if things do not work then try something else, if things work then try something else to make the solution stronger. So isn’t Scrum a way of solving such problems? Scrum shortens the planning horizon to maximum one month, then uses the inspect-adapt cycles (at the bare-minimum) through Sprint Reviews, Daily Scrums and Sprint Planning. The implementation of the Product Backlog is in-fact a way of adapting the requirements as you move forward and as more is known about the problem you are solving.

Therefore, it is a myth that Scrum is for small projects.

Conclusion

The size of the project has nothing to do with the use of Scrum or not.

  • Scrum is based on Empirical Process Control Theory.  Empiricism asserts that knowledge comes from experience and making decisions based on what is observed.
  • Scrum combines four formal events (Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective within a containing event, the Sprint) and three Artifacts (Product Backlog, Sprint Backlog and Increment) to implement empiricism. These events work because they implement the empiricism pillars of transparency, inspection, and adaptation.
  • Thus, Scrum is being used for solving complex problems (unknown requirements or unknown solutions) for small as well as large projects where constant inspection and adaptation is necessary and decisions have to be taken based on what is observed. Scrum Team observes what is happening based on the feedback received and adapts to the changes.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-scrum-only-being-useful-for-small-projects/

Myth about creating multiple Sprint Backlogs before first sprint starts

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. Is this rught way – read on to discover

Common Misconceptions and negative implications

Some teams treat the Sprint Backlog as just a smaller version of the bigger plan (Product Backlog) and start creating baselined Sprint Backlogs for multiple future Sprints. The negative implication of this practice is that the “Inspect and Adapt” cannot happen. This becomes just disguising the waterfall and calling it Scrum.

Recommendations

  • There should only be one Sprint Backlog. This represents the forecast for the current Sprint. At the end of the Sprint, the Sprint Backlog is emptied. All remaining items are taken back to the Product Backlog. All completed and done items are taken into Increment. The reason why this is done this way is to give opportunity to the Product Backlog to be re-ordered if needed.
  • It is possible that the Product Backlog item changes the order since there might be change of business priorities. If the Sprint Backlog is baselined for multiple sprints at the start then an important opportunity for inspection and adaptation is lost.
  • The discussions in the Sprint Planning result into a new Sprint Backlog based on the business objective to be achieved this Sprint. Even during the sprint, the Sprint Backlog emerges – more details get added and new things get clarified.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-creating-multiple-sprint-backlogs-before-first-sprint-starts/

Myth about Sprint Planning consisting of three parts Part1, Part2, Part3 vs Topic1, Topic2, Topic3

Many teams imagine Sprint planning as 3 parts being done serially – one after another. However that reduces the collaboration among teams – Let us understand why

Common Misconceptions and negative implications

Most teams implement Sprint Planning as three parts – Part 1, Part 2 and Part 3. The Product Owner comes in part 1 and 2, helps with setup of the Sprint Goal (WHY) selection of functionality (WHAT) and then the Developers sits and thinks over the technical (HOW) during the Part 2 of the sprint planning. The implication of this is that PO then does not get involved in the detailing and the road-blocks that team faces and technical feasibility problems that result during the Part 3 becomes a back-and-forth discussion between PO and Developers. This obviously results in a loss of productivity.

Recommendations

  • The whole Sprint Planning process is an iterative, incremental and collaborative process and therefore there are three Topics and not three Parts to the meeting.
  • First topic – WHY – is the business objective
  • Second topic – WHAT – is the selection of the Product Backlog Items which may help achieve the goal. So, it is forecasting what items should be part of this Sprint.
  • Third Topic – HOW – is the discussion of details and feasibility of the items and the help required from Scrum Master or Product Owner to get this done.
  • So, you can consider the WHAT and HOW are iterative in nature where the HOW revolves around the WHAT and joint discussions are necessary. There are possible considerations that may happen to the WHAT because of the HOW. Technicalities do influence to a large extent on WHAT can be done and what cannot.
  • The Sprint Planning Event can end with a decision on THE WHY – Sprint Goal, a forecast of WHAT needs to be done and the HOW for at-least a few things to be done over the next few days. However, the Sprint Planning PROCESS does not end with Sprint Planning EVENT. The Product Owner and Developers keep doing the discussion on the two topics – WHAT and HOW throughout the Sprint. Many-a-times, the teams do these detailed discussions on the HOW for the WHATs after daily scrums on the plan for next 24-48 hours.

So, my recommendation is not to call the Sprint Planning as Part1, Part2 and Part3 but iterative, incremental and collaborative process of Topic1, Topic2 and Topic3 which starts with Sprint Planning and continues throughout the Sprint.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-sprint-planning-consisting-of-three-parts-part1-part2-part3-vs-topic1-topic2-topic3/

Agile Antipatterns

The anti-pattern is a commonly-used process, structure of pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones –

Anti patterns are common solutions to common problems where the solution is ineffective and may result in undesired consequences. An antipattern is different from bad practice when It is a common practice that initially looks like an appropriate solution but ends up having bad consequences that outweigh any benefit or there is another solution that is known, repeatable, and effective. – Agile Alliance

Read the following Antipatterns published on this site

This article is re-published on WORLD OF AGILE website – https://worldofagile.com/blog/what-is-an-antipattern/

Myth about Sprint Review being a sign-off event or a demo forum

Teams some times think of Sprint Revierw as a “sign off” from the Product Owner – this reduces the opportunity to get feedback from stakeholders –

Common Misconceptions and negative implications

Sprint Review is thought to be a “sign-off event by the Product Owner” or “a demo forum by developers” by most organizations. This is an INCORRECT understanding of the Sprint Review.

Sprint Review is actually a feedback solicitation forum. The Scrum Team seek feedback from the stakeholders during the Sprint Review. This helps address the deviations. The Product Owner and Developers work together on a day-to-day basis. The Product Owner DOES NOT wait till the end of the sprint to give feedback to the Developers.

Recommendations

  • Product Owner needs to participate during the Sprint and provide feedback throughout the Sprint to the team. This gives an opportunity to the team to work on the feedback by the PO and adapt if required. This also gives opportunity for the PO to get the product ready by the time the Sprint ends.
  • Product Increment is considered as an INPUT into the Sprint Review and not an output as thought by many people. Therefore, sign offs (if any) have to be done before the Sprint Review starts. Also the sign-off – if anyone has to do – it has to be the Product Owner. That’s why the word “Owner”.
  • When the Sprint Review starts, the Product Owner and Developers have to be in sync with what is being shown to the stakeholders. If both the roles are in sync, then Sprint Review becomes an excellent opportunity to solicit feedback from stakeholders – who could be sales teams, marketing teams, sponsors, end-user representatives etc.
  • If one wants to use the word “Demo”, then my recommendation is to use the word during the Sprint when Developers demos the product continuously and seeks feedback from the PO. Demo should be ongoing and day-to-day where-as the Sprint Review is the minimum opportunity to solicit feedback from stakeholders.
  • Some may argue that getting Increment is impossible considering that stakeholder feedback happens in a Sprint Review. What we really recommend is that Sprint Review should be a “minimum” forum to seek feedback from stakeholders. Scrum does not stop you from getting more feedback from stakeholders during the Sprint.
  • The objective of the Sprint is to get a “usable” Increment at the end of the Sprint. This is possible if feedback is taken frequently from stakeholders – at a bare minimum during the Sprint Review. The Product Owner feedback should be day-to-day

Sprint Review therefore, is an informal opportunity for the Scrum Team to solicit feedback from stakeholders and make sure that the deviations are addressed.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-sprint-review-being-a-sign-off-event-or-a-demo-forum/

Busting Myths around Scrum

Myths

Scrum is a framework for solving complex adaptive problems. Scrum does not describe any tools, techniques and best-practices. Most people misunderstand Scrum and make assumptions on Scrum. The set of articles in this section are intended to bust some of these myths around Scrum.

Scrum is a framework to handle problems which are complex in nature. Complex Adaptive Problems are also called Empirical problems. That means for certain problems, knowledge can only come from experience and what you see. so the decisions are based on what you see in front of you. Scrum is an implementation of this principle.

One must understand that Scrum is purposefully incomplete. The tools, techniques and practices are not part of the core Scrum. The reason why Scrum is purposefully incomplete is because Scrum is generic and can be applied to any industry. The tools and techniques are specific to industries and are described in the industry specific methods.

Please refer to the following links to know more about Scrum Myths

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/busting-myths-around-scrum/

Myth about baselining the Sprint Lengths at the start of the project

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing the a contract – But like everything in scrum, the Sprint length needs to be open for Inspection and Adaptation

Common Misconceptions and negative implications

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing a SoW or a contract.

Recommendations

  • Scrum Guide recommendation is to keep the Sprint Length “Consistent”. Scrum Guide does NOT recommend a “Fixed” Sprint Length. We can change Sprint Length if there are negative implications being caused because of incorrect Sprint Lengths.
  • Considerations for changing the Sprint Lengths
  • Changing Longer Sprint Lengths to shorter Sprint Lengths (say 4 weeks to 2 week)
    • The scope keeps changing during the Sprint and Sprint Backlog becomes a mess. What we started off at the time of Sprint Planning and what we ended up in a Sprint Review is drastically different
    • Teams develop a “student syndrome”. Means – team takes it easy for the first couple of weeks. Then goes for a dash to the finish. The team then ends up working 18 hour days for last 2-3 days
    • The feedback is so drastic each Sprint Review that you need to re-work the whole thing. Think about the Sprint Length if this happens frequently.
    • Teams and PO don’t speak to PO often and communication breaks down resulting in no or minimal feedback during the Sprint.
  • Changing Short Sprint Lengths to Longer Sprint Lengths (say 1 week to 4 week)
    • Teams come under a huge stress. Deliverable every Friday is not easy. The stress levels take a toll and teams get sick of the stress.
    • Innovation goes down with very short sprint lengths. Teams become very “short-term” focussed.
    • Dividing items into smaller units becomes difficult. Beyond a point, breakdown of Product Backlog Items becomes a formality/academic rather than a real need.
    • Spilled-over work to next Sprint becomes common with very short sprint lengths. Teams are unable to create something useful.
    • Motivation goes down because of stress levels or not being able to get the Sprint to produce something usable every Sprint or stakeholders constantly feeling upset about not being able to complete.
  • DISCLAIMERS SO THAT YOU DON’T MIS-UNDERSTAND OUR STATEMENTS ABOVE
    • DO NOT keep changing the Sprint Lengths often. Try a Sprint Length, see if it works. If it does not work, then change. Once you find a length which is solving most of the problems, then stick with it. Be CONSISTENT. Being able to change the Sprint Length does not mean you become random and chaotic in the way you work.
    • DO NOT think that there is a “PERFECT Sprint Length”. There can never be a “Perfect Sprint Length”. See what Sprint Length solves “MOST” of your issues.
    • DO NOT change the Sprint Length when you are inside the Sprint. Just because you are not completing a Scope, does not mean, you change the Sprint Length by extending it. Sprint ends when a Timebox ends. You may think about changing the Sprint Length from the next sprint onwards.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-baselining-the-sprint-lengths-at-the-start-of-the-project/

Myth about Definition of Done being baselined before project starts

definition of done is often looked at a checklist that is set in stone-something not evolving – let us discuss how Definition of done evolves

Common Misconceptions and negative implications

  • Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
  • By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
  • Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Recommendations

  • Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
  • There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
  • As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
  • However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
  • For example : One could start with a definition of done as
    • Acceptance criteria for functionality is met
    • User Documentation is completed 
    • Integration testing is done
    • Regression testing is done
  • As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
    • Acceptance criteria for functionality is met
    • User Documentation is completed
    • Integration testing is done
    • Regression testing is done
    • Performance testing is done
  • So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
  • By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
  • It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-definition-of-done-being-baselined-before-project-starts/