In the article before, we have discussed many metrics that can be used by the Product Owners or the Developers in order to help them generate value at a regular frequency and in a efficient as well as effective manner. However, one accountability that we have not yet discussed is the master of the scrum, our Scrum Master. Does this mean that Scrum Master does not have any metrics ? Or that the Scrum Masters performance can not be quanitified at all?

If that has to be true, then how will the Scrum Masters improve their own way of working and ensure more effective as well as efficient outcomes for the whole Scrum Team? 

In order to decide what metrics, the Scrum Master can track and use we need to consider the key accountabilities of Scrum Master as explained in the Scrum Guide. The Scrum Guide says, master is accountable to ensure that 

• The team continuously improves its effectiveness
• Developers are able to create high value increment that meet definition of done
• And the Scrum Team implements scrum the way it is defined.

Considering the about 3 asks from the Scrum Master, Scrum Master needs to track the trends in other metrics so that the Scrum Master can help Developers or the Product Owners to help improve their own ways of working.

Also, the Scrum Master is a coach for the Scrum Team and at such needs to ensure that the team is self-managed where the team is empowered, enabled and capable of taking decisions independently without excessive support from the Scrum Master. Scrum Master also ensures that the Scrum Team is implementing scrum the way defined in the guide and to do that scram master may track how the various Scrum Events and are the rules stated in the guide are being followed by the team not only in the words but also in the spirit that they are meant.

When considered in this perspective, it is the Scrum Master who is helping the Scrum Team and the rest of the organisation to create a metric framework that can act as a backbone which supports the Scrum Team to continually improve its way of working leading to better value delivered more frequently.

Below I have given some sample Metrics that can help the Scrum Master.

1. Number of times Scrum Master has to be the interface for the developers – with PO /With Organization
2. Team Independence
3. Over All team effectiveness – trends in other metrics
4. Metrics which are found useful by Scrum Team / Metrics which are found cumbersome

The post Agile Metrics and The Scrum Master appeared first on World Of Agile.

Within the Scrum Team the Product Owner and the Developers often have different focus and different perceptions on what do they mean by value or how to improve the effectiveness of their own work and that of the entire Scrum Team.

This means Developers and product on us need different set of metrics in order to be really effective and efficient.  A common anti pattern often seen in Scrum is to have a metrics framework that is generic and not tailored for the individual accountabilities. In my experience it is worthwhile to spend time and energy into deciding specific metrics for both these accountabilities.

Each team needs to define Metrics that help them inspect and adapt. Below I have given some metrics Product Owner as well as Developers can use

Measuring Value –

A Product Owner is tasked with maximizing value of the product and the most important metric from a Product Owners’ perspective will be those which has centred around the net value or the end value delivered to the final customer. Developers. on the other hand will see value of their work reflected into the quality of outcomes that they have achieved.

The table below shows some sample Metrics that can help the Product Owner and Developers measure “value”

Table 1 Scrum Metrics Around Value

Measuring Frequency –

Agile manifesto states the importance of delivering value early and in a continuous or frequent manner. 

To measure the frequency, a Product Owner will like to measure the frequency at which the Scrum Team is able to put the features or the work into hands of end user. However, Developers will want to measure the frequency at which they are able to turn out usable and useful increments. 

The table below shows some sample Metrics that can help the Product Owner and Developers measure “Frequency”

Table 2 Scrum Metrics Around Frequency

Measuring Day to Day Work

The Product Owner plays a critical role in order for the Scrum Team to be efficient and effective. Product Owner has to support the Developers and work as an integral part of the Scrum Team so that the increment created is of best possible value. Developers will want to ensure how they work together collaboratively and support each other while creating the increment. 

The table below shows some sample Metrics that can help the Product Owner and Developers measure “Day to Day effectiveness”

Table 3 Scrum Metrics Around Working Effeicently

Following are some of the articles on Agile Metrics

• Agile Metrics – Friend or foe
• What metrics should we focus on in Agile projects?
• Some sample Agile metrics
• Agile Metrics and Scrum Master
• Defining your own agile metrics framework
• Early warning signals of incorrect choice of metrics for your agile projects
• Velocity

The post Some Sample Agile Metrics appeared first on World Of Agile.

How to create a Metric framework for your Program – How to choose Agile metrics, How to derive value from your Agile metrics?

 

Metrics are hot topic of discussion with Agile Enthusiasts. Both sides are equally passionate in their belief. Some people Believe that everything that can be measured should be measured. These people believe in the adage, “only what gets measured, gets improved”.  They insist that measuring the work progress, helps people to keep on track, to ensure that we are working up to our potential. They also argue that Metrics help baseline and these baseline data helps stake holders know what to expect

Other side of the coin are those people who object to this very “base lining” as they believe the comparison leads to people focusing on Metrics rather than value …They argue that metrics add overheads and often can be manipulated to paint whatever picture you want to depict. Often metric frameworks become bloated and defy the principle of simplicity. These are the people who believe that traditional metrics have no place in scrum way of working

The debt will go on. However, we all know that Metrics will always be part of work management for us. We need to find out ways to set up metrics which are not very cumbersome but still help us to take decisions based on quantified data. In this section I am planning to discuss all about Agile Metrics – Some topics I have in mind are

1. Do Agile Projects really Need Metrics? If yes, why we can’t use the same old metrics that we have been using for ages?
2. Some metrics that are useful in Agile or Scrum way of working
3. Metrics and the Scrum Master
4. How to set up a lean but efficient Metrics Framework
5.  What are some potential pitfalls you are likely to encounter?

Of Course, Metrics can never be defined in isolation – they need to be thought in context with your Agile contracts as well as your own scrum implementation. I hope this section helps you set up metrics that are useful for your own projects and products

The post Agile Metrics – Friend or Foe? appeared first on World Of Agile.

Common Misconceptions

People think that just by moving to Scrum all their issues will get resolved and magically all timelines will be met, no budgets will ever get overrun, all people will be happy, all customers will be happy, all changes come free and so on….

What Really is Scrum?

Scrum is a framework for solving Complex Adaptive Problems. Complexity means “Unknown-ness”. The Unknowns can be on requirements or on solutions. Where things are unknown, you cannot make detailed plans and just track the plan to closure. In such situations where things are unknown, what you see in front of you can be the only decision factor. Taking decisions based on what you see and constantly Inspect and Adapt based on what you see is called “Empiricism” or “Empirical process Control”. Scrum is a framework which sits on the “Empirical Process Control Theory”. For known problems (requirements known and solutions known), you will not need the inspect-adapt approach. The approach used for known problems is called “Defined Process Control”. Waterfall framework is based on “Defined Process Control”

Recommendations

One must understand that Scrum does not necessarily reduce cost and timelines. In Empirical process control, there will always be a feedback structure since the decisions are taken based on what you see. That means, we think about short-term in detail and long-term at a high level. When we see the results of short-term, we get feedback and then we inspect and adapt based on what we see. Therefore, there may be repetitions due to the feedback structure. Repetitions may mean that some re-work may happen. One must not think that just by doing Scrum, the cost and time will be lesser. If we use Scrum for problem statements which could have been solved using waterfall (or Defined process control), then unnecessary overheads and unnecessary inspect-adapt cycles may increase the cost and timelines. My recommendation is to choose the right framework for the right purposes. Taking a “one-size-fits-all” is not a great idea.

The teams are not necessarily happy doing Scrum. In the Scrum way of doing things, the timeframes are short. Delivery cycles shrink to a few week cycles. There is a constant pressure on teams. Many times, you will notice comments in the team like “Waterfall was better”. Scrum is actually Pervasive. That means people don’t like this drastic change in their lives. This change touches people’s lives. My recommendation is to ensure that every organization first implements a culture which sustains this pressure. The earlier model, where there was “push culture” should change first. Management should not create unnecessary pressure on the teams. Agile principle number 8 should be implemented first “Agile processes promote sustainable development. Sponsors, Developers and Users should be able to maintain a constant pace indefinitely”

The business teams are not necessarily happy doing Scrum. The Business teams were used to pushing accountability conveniently on the technical team’s side under the umbrella of a few terms like “Managed Services” or “Managed Outcomes”. The IT companies also marketed these terms like “Managed Services” to create differentiators for themselves. The Business teams suddenly start feeling the heat when they are held accountable for ensuring that the delivery happens properly and making sure that they have to work with the technical teams on a day-to-day basis. In Scrum, we define the accountability “Product Owner” where participation from a Business perspective is extremely important. My recommendation that the Business Teams must be made to understand that Accountability cannot be outsourced and one cannot toss the accountability on the technical side. The business should be brought in sync with the Agile principle “Business People and Developers must work together daily throughout the project”. Scrum emphasizes that the right people take the right accountability and accountability cannot be outsourced.

The Business teams have conveniently understood that “Changes are free in Agile and Scrum”.  One has to understand that no changes are ever free. There is always a cost associated with a change. It is just differently looked at in Scrum. In Scrum, we tend to give importance to more valuable features. That means, the less valuable features go down the product backlog and may never get implemented. So, pushing the teams to do all requirements may not be a great idea, else the cost will obviously go up. My recommendation is to follow the Agile principle number 10 which says “Simplicity – The art of maximizing the work NOT done is essential”. The business has to know that nothing in this world is free and we need to learn to compromise less-value features for the more valuable ones

Conclusion

Scrum is not a magic-wand solution to solving all problems. In fact, if you do things incorrectly then the problems will multiply. It is better for organizations to understand Scrum and Agile correctly and apply only where required. “One-size-fits-all” is not a great approach.

The post Myth that Scrum is a Magic Wand to Solve all Project Issues appeared first on World Of Agile.

Common Misconceptions

Most people consider Daily Scrum is presumed to be a Status Meeting where Scrum Master takes status from the teams. One of the most common reasons for this is because people have used Project Manager as an entity for years and assume that Scrum Master is a renaming of Project Manager role and Daily Scrum to be a new name for “Status Meeting”.

What is Daily Scrum Really?

• Daily Scrum is not a Status Meeting. Daily Scrum is a inspect-adapt forum for the Developers to make a plan for next 24-48 hours by checking if the Sprint Goal is being met or not
• Developers sync up daily so that the plan for next 24-48 hours is effectively done
• Updating the Sprint Backlog should be the main goal of the Daily Scrum. This optimizes the probability of meeting the Sprint Goal
• Daily Scrum is a effective forum for improving communication and collaborations between Developers

Recommendation about Scrum Master’s Role in Daily Scrum

• Scrum Master may facilitate the Daily Scrum to ensure it gets over in 15 minutes and people do not make it a detailed discussion forum. However, Scrum Master is not considered the compulsory participant of Daily Scrum.
• Scrum Master’s role is to make the team independent and help them becoming self-managed team. Therefore, Scrum Master should teach the Developers to run the Daily Scrum effectively by doing a quick sync up and updating the Sprint Backlog
• Once the team becomes self-managed and know how to get the Daily Scrum completed within 15 minutes, Scrum Master should change his/her stance to an observer stance. That means the team has to talk to each other without Scrum Master’s intervention
• Scrum Master should teach the Developers to keep the status transparent through various tools and techniques such as Burn Up Charts, Burn Down Charts, Scrum Boards. This avoids a lot of wasteful status discussions in the Daily Scrum
• Once the Scrum Master feels that the Developers are managing on their own, the Scrum Master should purposely skip a couple of Daily Scrum and find out if the Developers still keeps doing the Daily Scrum on their own. If the Developers also skip the Daily Scrum, just because the Scrum Master was not there, then Scrum Master should treat this as an opportunity to coach the team again
• If Scrum Master notices that Product Owner is conducting reviews of Product during the Daily Scrum, then, Scrum Master should coach the PO not to do it and create another forum where the review of the product could be done
• Similarly, if Scrum Master notices that the line managers are wasting the time of Developers by taking status, then Scrum Master must intervene and prevent the line managers from doing this
• Sometimes, one of the Developers wastes a lot of time of others during the Daily Scrum trying to dominate the forum by showing off on his/her skills. Scrum Master’s job to facilitate and ensure that everyone gets equal chance during Daily Scrum. There are many facilitation techniques which could be used. For example, tossing the ball every 60 seconds to the next person to speak, introducing friendly penalties (buying a drink for everyone, doing 10 push-ups) for exceeding the time allocated to speak etc.

Conclusion

Thus, Scrum Master is not a mandatory participant of Daily Scrum. “Not Mandatory” does not mean that Scrum Master is always Absent in Daily Scrum. Scrum Master’s role is to make the team independent so that they can manage the Daily Scrum to inspect and adapt and optimize the probability of meeting the Sprint Goal. Once the team becomes independent, it is better for the Scrum Master to take a step back and take observer position.

The post Myth – Scrum Master being the Mandatory participant of Daily Scrum appeared first on World Of Agile.

Common Misconception

Most people treat Sprint Review as a “gate check” forum to release the product into production. Thus, the Sprint Review ends up being a formal meeting with gate-checking checklists to go through so that the product can be sent to production.

What really is a Sprint Review?

• Sprint Review is an informal forum to seek feedback from the Stakeholders
• Intention of the Sprint Review is for the Scrum Team to find out if they are on track to meet the Product Goal, and if not, inspect and adapt the Product Backlog for future Sprints
• Scrum de-links the “go-live” or “delivery to stakeholders” and “seeking feedback”. Sprint Review’s intent is to seek feedback. The product may be delivered to the stakeholders before or after the Sprint Review

Recommendations

• Sprint Review should be a informal discussion between Product Owner, Stakeholders and Developers to discuss improvements in the product and increase the probability of reaching the Product Goal
• Sprint Review should be more like a working session instead of formalized presentations and checklists to go through
• It is better to create a separate gate check forum other than the Sprint Review. If any gate checking is done in Sprint Review, the real intent of getting feedback may be lost

Conclusions

Sprint Review is not a gate checking forum. It is a working session where Scrum Team and Stakeholders collaborate on how better to achieve the Product Goal

The post Myth – Sprint Review Being a Gate to Releasing Value appeared first on World Of Agile.

Common Misconception

A Product Owner is considered a “Client” or “Customer”. So, most people feel, how can you invite a “Client” for an internal forum to discuss “what went well, what did not?”

Recommendations

• Most Product Owners indeed behave like a “Client” or a “Customer” instead of a Scrum Team Member. Therefore, the Developers do not consider the Product Owner a part of them and consider him/her as an outsider. The Product Owner should be first part of the Scrum Team and then be a “Customer” or “Client”
• Product Owners often ridicule the teams or shout at their teams for not understanding the requirements properly. Product Owners often escalate against the teams to the Line Managers of the Developers. This creates a divide between the Product Owner and the Developers. The Developers then don’t feel comfortable about opening up in front of the Product Owner. The Product Owner’s job should be to get the Developers to feel comfortable and put the “fear-factor” to rest. This means, the Product Owner should be empathetic, calm, show patience and be looked at as a Leader instead of a manager.
• Sprint Retrospective is a forum to see what went well and what did not go well. This increases the effectiveness of the next Sprint. If the Product Owner is not there in the Sprint Retrospective, then effectiveness improvement will be looked at only from the perspective of the Developers. The Developers are doing the technical work for the Product itself. So if the Product Owner is absent in a Sprint Retrospective, the effectiveness improvement cannot be done from the Product perspective
• Sprint Retrospective is a good forum to discuss the DoD (Quality Measure for next Sprint). If the Product Owner does not attend, the Sprint Planning of the next Sprint may be an issue since DoD is not finalized.

Conclusions

As a part of the Scrum Team, the Product Owner is a mandatory participant of the Sprint Retrospective. Sprint Retrospective is an excellent forum to thrash out any opinion differences and plan for improvements and everyone from the Scrum Team must participate.

The post Myth – Product Owner should not be invited in a Sprint Retrospective appeared first on World Of Agile.

Common Misconceptions and Negative Implications

·        It is a common practice for a Product Owner to come up with a set of requirements in the Sprint Planning and disappear during the Sprint. Then appear directly at the Sprint Review forum and conduct the review of the Developers work during the Sprint Review.

·        By doing this, an important opportunity of giving feedback continuously is lost. The feedback becomes a big-bang-end-of-the-sprint activity

·        Since Product Owner is seeing the product first time during the Sprint Review, it can become difficult to take feedback from stakeholders

·        If Product Owner brings along the stakeholders to do a Sprint Review, the Product Owner ends up acting like the “Other party” and does not build confidence in the team doing the work

• When the Product Owner sees the newly increment only at review time, Sprint Review becomes a gate that holds back value from reaching the users. When the Product Owner sees the increment during Sprint an opportunity is created to release value earlier

Recommendations

·        The Product Owner owns the product. Therefore, it is important for the Product Owner to participate in the product development continuously and constantly provide feedback.

·        The Product Owner has to build confidence with the Developers. Developers being left alone is not a great idea. The Product Owner should not behave like an outsider and should not sit on the other side of the table. Once the Product Owner wears the “Product Owner Hat”, he/she is first part of the Scrum Team and then part of the Customer or Client or Stakeholder team

·        Developers must not fear the Product Owner. Feedback is not a cause for worry. Feedback is good. The earlier you receive the feedback, the better it is for the Product

·        Typical steps in the Sprint Review that are seen useful by many teams could be as below

o   The Product Owner should invite the relevant stakeholders for a Sprint Review

o   During the Sprint Review forum, the Product Owner should sit with the Developers

o   The Product Owner should thank the Developers in front of the stakeholders for the work done

o   The Product Owner should take ownership of the product during the Sprint Review and collaborate with stakeholders to make it a working session

o   During the Sprint Review, the feedback should be from Stakeholders and not from the PO. The PO feedback is assumed to have been taken already during the Sprint

o   The stakeholders and Product Owner should think about the next steps based on market place conditions and make adjustments to the Product Backlog

Conclusions

·        Sprint Review should be a working session between entire Scrum Team and Stakeholders

·        Product Owner should be reviewing the product with stakeholders with help of the Developers

·        Product Owner should have provided feedback to the developers continuously throughout the Sprint and should not be seeing the product first time during the Sprint Review

The post Myth – Sprint Review being the review of the Developers done by Product Owner appeared first on World Of Agile.

Most people think that the Product Owner being the one-point-contact (mediator) to talk to stakeholders is a great way of reducing wastage and unnecessary discussions. While, apparently it might look like a helpful  pattern but actually it turns out to be an anti-pattern .This way of working has more negative consequences than positive.

Why do people feel that the Product Owner is a mediator?

• The Scrum Guide says “The Product Owner may represent the needs of many stakeholders in the Product Backlog”. When people read this sentence, they may  feel that the Product Owner is the only person  that is allowed to interface with the Stakeholder and no one else can interface with them.
• Fear of a “Customer” or a “Stakeholder” escalating to the management has always kept the developers away from the “Customer”. Some of the common fears that hold back a developer are –

o   “What if I understand incorrectly?”,

o   “What if the customer escalates to my manager?”,

o   “What if the customer laughs at me?”,

o   “What if the customer thinks I don’t know things?”

o   What if there are any contractual implications to what I agree?

• The reluctance of the Developers (Technical teams) to interact with Stakeholders has made the Product Owner a mediator or a middle-man/woman. The developers expect that the product owner will always talk on their behalf to the stakeholders.

Negative Consequences

• Product Owner may not be able to convey what exactly Developers views

o   Developers have a unique point of view about any solution. Information may be lost when the Product Owner conveys.

o   Developers know the technical feasibility of any solution to a business problem. Product Owner may not know all the details of technical issues

• Information may be conveyed incorrectly and thereby increasing misunderstanding between stakeholder and the technical teams
• Product Owner may become a bottleneck and overloaded with work related to conveying information back-and-forth between Developers and Product Owner

 Recommendations

• The Developers should talk directly to the Stakeholders while keeping the Product Owner informed about the discussions
• Let Product Owner be the final decision maker; however, the details can be discussed directly thus preventing the overload on Product Owner
• Developers should not take decisions directly by talking to the stakeholder. Once discussion with a stakeholder is done, they can update the PO and abide by the decision taken by PO
• Trust between Stakeholder and Developers should be increased. This may be possible if the Stakeholders do not keep escalating against the developers and don’t ridicule them for their mistakes and misunderstandings. Stakeholder must understand that the technical teams are good in technology and may not be able to understand business concepts easily
• Product Owners should not have a controlling mindset. Sometimes  Product Owners who are used to the traditional way of working may initially want to control all the requirements. That usually does not work. Scrum emphasizes on maximizing the value. The Developers may have a unique point of view which may provide a better value to the product. Therefore, Product Owner can consider this as a good way of getting better value by having the Developers talk directly to the stakeholder
• Likewise, sometimes a Product Owner who is used to erstwhile command and control leadership may  feel  insecure or out of control  when  developers talk directly to the stakeholders. In such a scenario, the Product Owner may need to be coached to focus on maximizing the value . Many brains are better than one brain.

The post Antipattern – Product Owner as the mediator between Developers and Stakeholders appeared first on World Of Agile.

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 Hardening Sprint seems a good idea?

Scrum Teams are under constant pressure to deliver features. The stakeholders and Product Owners often push the Developers for going to production as soon as possible. 

In these situations, the developers often postpone a lot of work to be done later. Examples include – documentation, code cleanup, defect fixing, commenting of code, hard-coding, bypassing checks etc.

Then the Scrum team introduces a “Hardening Sprint” after 4-5 Sprints to take care of all these pending activities. Therefore introducing Hardening Sprints is generally considered a good idea by a lot of teams.

Negative consequences of Hardening Sprint

User of Hardening Sprint introduces following problems

• Pending work increases. Many times the Hardening Sprint does not get taken and the work just keeps accumulating
• It becomes more and more difficult to tidy up the mess
• Teams end up forgetting things later on
• Increase in the possibility of the defects since things get fixed later

What could be done instead of Hardening Sprint

• Follow the agile principle of “Simplicity” – the art of maximizing the work not done. That is, don’t push more features. Try to complete a lesser number of features with all things done.
• Slow down – focus on quality rather than speed
• Make the Definition of Done more stringent
• Focus on engineering practices such as Automations, CI/CD, Automations, TDD
• Say NO to a hardening sprint. Do not keep pending activities.

The post Hardening Sprint – An Anti Pattern appeared first on World Of Agile.