Early Warning Signs That Your Agile Metrics Are Not Set Right!

Setting up the metrics that help the Scrum Team can indeed be a very difficult job and, in this article, I want to write about some smells that you may observe. These smells are an early warning system or indications which tell you that your metric friend work needs some tweaking.

• Metrics That Take Time To Prepare If a Scrum Team needs time to prepare a set of metrics that usually is a Red flag indicating that the metrics are not coming from one place and need some collation effort. Such a collation effort does not add any specific value and should be discouraged. Also there is always and risk of such manually calculated metrics maybe based on somebody’s perception rather than an universally accepted single source of truth. Where possible it is a better idea to automate the Metrics calculation that way the team’s effort is not vested in calculating the metric.

• Teams Seem Hassled About Metrics / Teams cannot explain rationale Metrics are meant to help the Scrum Teams continually improve their performance. This purpose cannot be achieved if the teams are hassled about the additional burden metrics collection and tracking puts on them. If the Scrum Team is unhappy about some Metrics that they have to track or capture, it usually indicates that either the team does not understand why they are being asked to capture certain data or how the data is going to be used. In such a case being transparent with the Scrum Team about the rationale behind asking for this data helps the team to align better with the ask. Where possible enabling automated data capture also reduces the overhead the Scrum Team has to bear and that can further reduce their resistance.

• Metrics That Are Judgy /Random R-Y-G windows Purpose of metrics should be to help the script to continuously improve their performance. Often the Metrics are structured not as a way to improve the performance continually but to create arbitrary service level agreements which are tried to agile contacts. Many times such metrics have been created with artificial designed acceptable tolerance limits or random Red-Amber-Green ranges rather than tolerance limits which Scrum Teams can understand. In such a scenario Scrum Team might focus on representing data in such a way that their own performance falls into the desirable limit. This might defeat the very purpose of metrics which is to find out ways to improve not to judge a Scrum Teams’ performance.

• Metrics that create barriers Purpose of metrics is to enable the Scrum Team to inspect and adapt in such a way to continually improve its performance. This becomes difficult to achieve when there are Metrics which set team members against each other. Most efficient tester/ the developer with zero defects against his or her name/ star of the month may be some examples of such individual metrics. In such cases it is possible that such metrics create a hindrance for the Scrum Team to work as a single unit and encourage the team members to work as independent players since they want to protect their own metric level. We have to take similar care while we try to pitch 1 Scrum Team against another especially when these teams are working on the same product goal and the product backlog. Such Metrics that compare one team against the another may discourage collaboration among the teams which in the end might hamper the value delivered to the customer

The post Early Warning Signs That Your Agile Metrics Are Not Set Right! appeared first on World Of Agile.

 Figure 1 – Defining Your Metrics Framework

Setting up the metrics that helps Scrum Team can indeed be a very difficult job and, in this article, I will explore some things to keep in mind while you are setting up your Metrics

• Metrics Are Not About Keeping Things Green – In my experience I have seen quite a lot of Scrum Teams where the focus of metrics reporting is to show how what we are doing is working or in other words we are all green- this usually stems from metrics that are defined in agile contracts and are tied with payment for services rendered. This makes the Scrum Team focus on ensuring that there always seen green. In such a case the focus cannot be on what we need to do in order to improve. I usually guide the teams not to have these service level agreements in their Agile Contracts – I rather focus on having metrics that are measure the right things like value of work delivered. 

• Focus on End-to-End Metrics – It is usually a better idea to have metrics which measure the value end to end across the value chain rather than measuring value at interim points. To give an example, it is better to have metrics that capture into and time required for a feature rather than tracking time for a specific task like coding or testing. Another example can be, number of zero defects features delivered is a better Metrics than number of defects identified during testing phase. When defined in this manners Metrics encourage Scrum Team to work as a unit. It becomes a challenge to define such metrics in a multi-vendor scenario. 

• Measure Only What You Want to Improve – Metrics Should NOT be cast in stone – Often, I see very complicated and detailed metric structures that texts up a lot of time and energy for the Scrum Team to create and maintain the data. These metrics frameworks often are collecting data for it sake without a concrete plan of how the data will be utilised in order to help the Scrum Team to be more effective and efficient. Such metric frameworks make it difficult for the Scrum Teams to derive meaningful in inferences out of huge amount of data being collected. I have seen that it instead works better to have a smaller number of metrics that the Scrum Team has to track. This way the team can actually use the data being captured. Some of the most effective organisation and Scrum Teams are known to choose their focus for the upcoming period of 6 months to an year and then decide the metrics that will help them achieve their goals for the said period. This also aligns with the Scrum Value of Focus

• Avoid metrics that Compare one team or one person against another – Agile believes into collaboration. For a Scrum Team working collaboratively is the best way to ensure frequent delivery of valuable software. If the metrics are structured to measure an individual performance or productivity it may sometimes lead to people working against each other to protect their own Metrics level. It is a better idea to measure value delivered as the whole team. The same principal can be applied to creating a competition between the teams- for large products requiring many teams it can hamper the collaboration amongst Scrum Teams. It works better if the teams are measured against their own last performance and encourage to have a continuous improvement in their way of working rather than comparing against other teams.

• Trends Need To Be Monitored – NOT individual numbers – Sometimes a particular metric may show a bad value. This can happen because of multiple transient reasons and it may not be worth it to really worry about an isolated value or reading in a metric. It is much more useful to monitor the trends and analyze if the Scrum Team is going in the right direction.

The post Defining Your Metrics Framework appeared first on World Of Agile.

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.

Can we use Traditional metrics as-is in Agile?

Figure 2 Traditional Metrics do not fit in Scrum

Traditional Metrics usually focus on measuring various aspects of planned versus actual. The idea is to track any variances against the detailed plan. They also measure quantum or size  of scope delivery. 

Intention of these metrics is to measure and showcase the efficiency of the delivery be it the schedule or cost adherence, Scope delivered or quality of the delivery.

Some of the usual metrics companies track are

1. Schedule Variance or Cost Variance
2. Size of work packets (KLOC / No of use cases / No of test cases etc)
3. Scope adherence – how we track Scope variance or rework and how we reduce the rework
4. Productivity  

The above metrics are set to track if we are delivering as per agreed plan. – But in Scrum and Agile the plans are changing often as we believe that while planning is indeed valuable – plans need to be updated often. Then these metrics to track against a plan do not seem relevant when plans are being updated very often.

Another key point missing in the above metrics is the focus on value – Agile Manifesto says that as agilists our highest priority is to deliver Valuable Software. The metrics listed above measure only “what work the team did” they do not measure “what Value was generated” – For a Scrum Team to ensure their effectiveness and efficiency we need metrics that can quantify the Value.

Do we need Metrics in Agile Projects?

We saw in earlier section that traditional metrics do not help when working in an Agile manner. The question then comes to mind is, do you really need metrics while working in Agile?

The answer is a definite yes – When done well, Metrics provide us with transparency by giving quantified information that does not depend upon individual perception. This quantified information helps us to inspect the work we are doing and the value we are delivering. The inspection then allows us to adapt our way of working to improve the value we deliver.

In other words, metrics help us to work in an empirical manner.

Figure 3 Why do we need Metrics in Agile?

What should we measure while working in Scrum?

In my experience there are 3 major dimensions where metrics provide us basis or the transparency to inspect and adapt

1. Value – Are we delivering Value? Scrum focuses on Value and our Product Owner is tasked in maximizing value of product. We need to have metrics that quantify and capture the value we have created. 
2. Frequency – Are we delivering value frequently enough so that we help our customers have competitive advantage? – Agile Manifesto tells us that we believe in continuous delivery of valuable products. 
3. Day to Day Metrics – These are the metrics which helps the Scrum Team to inspect and then adapt their way of working so that they become more effective and efficient.

The post Metrics in Agile Projects – What Should We Focus On? 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.

This article describes a routine Day in the life of a Scrum Master. A Scrum Master’s role is often misunderstood. People think that its a co-ordination role or worse still, Scrum Master is often considered a renamed “project manager”. The Scrum Guide says that Scrum Master is a true leader who serves. In this article I have shared some possible activities that I found useful as a scrum master in order to help the Scrum Team to implement Scrum – as defined in the guide and improve their effectiveness.

Day in the life of a Scrum Master – Supporting the Scrum Team(s)

Checking on the team space

Checking if everything is going fine could be a good start. Scrum master observes the team space to check if there are any infrastructure issues, anyone not able to work because of IDs locked out or zoom ID suspended etc. Scrum Master not necessarily checks with everyone however observation technique should be enough. If people are working remotely just a message on a messaging tool such as WhatsApp could be enough.

Sometimes human being related issues could affect. Resignations, unplanned leaves, sickness, demotivated team members could be some examples. It might be worthwhile for the Scrum Master to think about some suggestions that he/she might make to the developers or product owner during the day. 

Observation of Burn downs, Scrum Boards, impediment boards, happiness index

Observation of day to day boards, missing updates on scrum boards, deviations etc might be some good points for the Developers to talk to each other in the daily Scrum. If the developers don’t bring it up then politely coach them to discuss the deviations and what help they may need to bring things back on track.

Facilitation of Sprint Planning, Daily scrum, Sprint Review, Sprint Retrospective

Scrum Master does not run the daily scrum. However, Scrum Master must ensure that the daily scrum happens and developers know the intent. 

Many of the times daily scrums become a “show-off” forum for many people. Scrum Master must get the daily scrum back on track while ensuring people don’t get upset for stopping them. Saying things like 

“Hey Vinay, looks like you have done really substantial work on this aspect. Why don’t we have a coffee to discuss the same after the daily scrum. Anyone who wants to join is welcome”.

“Hey Dilip and Madhavi, it looks like you both are having a great conversation. Why don’t you do this after daily Scrum and I would also like to join the conversation if you both are ok? Anyone else wants to join the discussion, you are welcome as long as Dilip and Madhavi are ok”

Using facilitation techniques such as round-robin or tossing the ball after 30 seconds, those who have impediments first should speak etc could be good techniques.

Facilitation of Sprint Planning, Sprint Review

First, Scrum Master has to ensure that the Scrum Events happen and people know the essence of them. Other than the Daily Scrum (which is a daily event), Sprint Planning, Sprint Review and Sprint Retrospective are events which must happen in every Sprint.

Second, The participants of the meetings often do not come to conclusions and the meetings extend. Scrum Master should get the meetings focused and results achieved. For example, in a Sprint Planning, the Sprint Goal and PB Item selection should be done before the meeting ends. Sprint Review is about feedback process. Many a times the Sprint Review turns into a bashing forum for the stakeholders to bash the developers. Scrum Master should get the meeting focused back on the feedback rather than being a bashing forum or just a gate check forum.

Causing Impediment removal

There may be some impediments identified which the team may not be able to solve themselves. It might be worth contacting the right persons in the organization who may help with impediment removal.

Facilitating Product Backlog Refinements

Many times Product Owner and Developers come unprepared for Sprint Planning Events. This ends up being an understanding-of-requirements forum. The work should be split into smaller items much before and not during the sprint planning. Sprint Planning should be quick and should focus on any remaining clarifications. Understanding of what needs to be done over the next or next-to-next sprint should happen in a structured way in the form of product backlog refinement activity. While Scrum does not suggest any specific formats or timelines, it is worthwhile for Scrum Master to discuss it out with Product Owner and Developers on a frequency and format to understand the future. It is then worthwhile for Scrum Master to keep reminding the Product Owner and Developers on having the activity at a decided frequency to ensure that the Product Backlog is ready enough for the next couple of sprints.

Coaching, Mentoring, Teaching the Scrum Team in a Sprint Retrospective or elsewhere

Scrum Team members need help on various things on a day-to-day basis. They might get stuck on a problem (technical or non-technical). Scrum Master may wear a teacher hat if he/she knows the direct solution. Scrum Master may wear a mentor hat if direct solution is not known but if Scrum Master has faced similar problems in the past and help the team solve the problem using the experience. Sometimes if the solution is neither known to Scrum Master or to the Scrum Team, then one can wear the coaching hat and ask probing questions to lead the Scrum team to answers. This is usually done in a Sprint Retrospective but not limited to the forum.

Creating a safe environment and remove fear for failure

Many organizations look at failures negatively and there is a culture of punishing failures. On a day-to-day basis, removal of fear is an important activity. If there is a fear for failure then encouraging and motivating is an ongoing activity. Ensuring that team members don’t get exposed even if the failure happens is important. If the culture of punishing failures is not removed, people don’t try things and always take a safe route. This inhibits innovation and risk taking abilities.

Creating a culture of Self Management

Team members often wait for directions from seniors. Discussing and talking it out with people on self management is extremely important. On a day-to-day basis it has to be discussed with the Scrum Team on the importance of managing their own taks, allocating their own tasks, alignment of team members to goals etc. Scrum Master’s job is to get the team self managed and in fact not increase dependency on self.

Facilitating Release Planning

Workshop may have to be facilitated between stakeholders, Product Owner and Developers to plan releases. Scrum Master’s job is to make sure this happens and things don’t progress in an ad-hoc fashion.

Facilitating communication with managers

Managers many times indulge in ad hoc requests which may cause flow problems for the teams. Evaluating, discussing, negotiating with managers might be required many of the times. Developers might not be equipped to speak up due to various issues such as cultures, customer-vendor relationships, unrealistic service levels etc. 

Relationship Management

Causing Impediment removal for your team might be easier said than done. People help you because you help others. Scrum Master is a lot about relationship management. Other Scrum Masters might need help from you. Checking if you can extend help to others may be a good idea. One must ensure that you don’t go overboard on providing help. However , if you don’t do it then why would anyone extend help when you need it for your team.

Tools and techniques demonstrations

Looking at the day to day should instigate the scrum master to find out possible ways to improve productivity and reduce routine repetitive work. Finding out from other teams, other organization’s or researching may give some ideas for the Scrum Master to suggest to the Scrum Team. These tools and techniques demonstrations or presentations can be arranged for the Scrum Team.

Awareness about what is going on around

Catering to organization invites for what is happening in the organization is necessary. If you are not aware about what is going on then how would you know what to offer to your team?

Team Building activities

Scrum cadence introduces a lot of stress for people. Relieving stress via some team building activities may be a good idea to arrange for the team.

Floor meets

Creating the euphoria and excitement of a change is an important job of a Scrum Master. When organizational design changes happen, it is important to hold floor meetings, communicate the desire to change. While Scrum Master may not himself/herself do all this, facilitating the floor meeting with the help of HR and leadership is an important activity.

Day in the life of a Scrum Master – Supporting the Scrum Team(s) – Working in a Multi-Team Environment for a large product setup

Facilitating Scrum of Scrums

Multi-team products require dependency resolution on a regular basis. Scrum of Scrum forum is a good way for representatives of teams to talk to each other and resolve dependencies. Scrum Master should help create a cadence for these meetings and help the teams resolve technical and inter-team dependencies.

Facilitating Meta Scrums

Multiple Products in the organization may need Meta Scrum to discuss business dependencies, release planning process, process to organize release trains etc. Scrum Masters across multiple products should organize the structure by suggesting a cadence for the multi-product releases.

Facilitation of DoD creation

Multiple teams may go out of sync on the quality criteria and may end up with a product which does not meet customer expectations. Scrum Master must facilitate discussions between various teams to discuss the DoD among themselves and agree upon the quality criteria. This should happen regularly so that the quality improves consistently.

Day in the life of a Scrum Master – Working with rest Of the organization

Organizational impediments often impact the delivery of products. This may involve the different departments causing impediments or there may be organizational support required by the teams on the ground to get success

Preparing for attritions or career moves

Attrition, job-moves, role-changes are part and parcel of real life. As a Scrum Master one must facilitate knowledge sharing sessions, prevent formation of silo cultures, prevent the hero cultures in organizations. Honing and getting the new generation ready as team members move from one role to another has to be a well planned process. This requires facilitating with managers and Product Owner for budgets to onboard new trainees, training budgets, time for cross-skilling etc.

Creating and Nurturing communities

Impediment solving is easier said than done. Impediments are solved by a community of people and not by individuals. Nurturing communities and connecting people is the easiest way of solving problems. Scrum Masters of different teams should connect with each other and create communities for collaboration. This could be based on skills or cultures or regions. Many organizations call these guilds.

Coaching, Mentoring, Teaching the organizational players

Organizational players such as customers, management, HR, Administration may not be aware about Scrum, Agile or its benefits. They end up causing various impediments for teams. For example, some management’s take adhoc decision of using some framework such as Scrum. They may not know why they are doing it. HR might take decisions on individual rewards model not knowing what the implications of individual rewards in a collaborative environment are.

Facilitating Organizational Design Changes

As a change agent for the organization, the Scrum Master helps change the thought processes of the entire organization which may include Management, HR, Admin and other departments. Following could be some of the examples of organizational design changes brought about by the Scrum Master

Command and control leadership style to servant leadership style

Leadership is used to a particular leadership style. Many leaders resort to “Do it because I say so” kind of style. Servant Leadership style involves enabling the team to take decisions instead of forcing things on the team. This requires time and substantial convincing effort for the Scrum Master.

Establish Fear-free culture and creating a safe environment

One of the major issues with organizations is that the management is always judgmental of the people. Therefore, the team members rarely like to take risks. Being defensive may not always be the right behavior in the team. Scrum Master has to ensure that a safe environment is created for people to fail. This requires a lot of mentoring of Senior management and cultural change in the organizations. This requires a design change in the organizations in the way people think and the way people are appraised.

Feature teams vs Component teams

A Feature team takes end to end responsibilities of the product and creates viable products each sprint. To take end to end responsibility, the team restructuring and reskilling may be required. More importantly the culture within the organization may have to be relooked at. For example, the team needs to be cross functional to make a good feature team. That means, Scrum team needs to have all skills necessary within the teams to make products. This involves teaching and mentoring of the team members to find ways to build cross functional skills. The team members have to be made ready to not think in silos. Silo culture removal requires design changes such as convincing the team members, management and also making sure that the team members are ready for some cross training.

Collaborative mindset with vendors

Many a times the culture in the organizations is to look at the vendor as an outside entity. This creates divides between the customer and the vendor. Usually the PO accountability is taken up by someone from the customer side and the delivery is done by team members usually provided by vendors (usually in India in the IT world). If there is divide between the customer and the vendor, the collaboration gets affected and delivery may not happen properly. Scrum Master needs to make efforts so that the complaining mindset of many from customer has to go down and the vendor team members have to be made to feel a part of the product team. This needs Scrum Master’s effort in making thought process level changes in the organizations so that the collaboration happens. This may involve relationship building, confidence building and weeding out the bad behaviors – usually a long term design change.

The post Day in the life of a Scrum Master appeared first on World Of Agile.

Product Owner is the accountability in Scrum which Maximizes the value to the stakeholders using the bandwidth available to him/her via the Developers.
While the requirements can never be finalized in empirical work, one of the fundamental aspects of reducing wastage in Agile is to get the requirements ready for the developers “just in time” – not to early and not too late.
Product Owner’s role is to engage with the stakeholders and understand their needs and expectations. This involves

• Requirement elicitation techniques
• Need Analysis techniques
• Requirements classification techniques
• Collaborative Gaming techniques
• Requirements classification techniques
• Requirement Documentation techniques

Who does requirement elicitation in Scrum?

While the Product Owner remains accountable for requirements elicitation, rarely would a Product Owner have enough time to elicit it by himself/herself. Generally, Business Analyst does this (Business Analyst is called as Developer in Scrum) for the Product Owner. Elicitation techniques help people to understand the thoughts and feelings of participants, and to probe for more information.

Why is requirements elicitation different in Scrum?

In Scrum, requirement elicitation is an ongoing job. The Product Backlog emerges throughout the project. Therefore, doing too much of upfront elicitation is a lot of wastage. However, doing the requirements elicitation should ensure that the process is quick, and bureaucracy involved with signoffs and baselines should be avoided. At the same time, the process has to be fast. You cannot have huge documentations done in the form of a Functional Specification or Business Requirements Specification.

Requirements Elicitation Techniques

• Brainstorming technique
• Focus Groups
• Interviews
• Prototypes, simulations, demonstrations
• Wireframes
• Nominal group techniques
• Voting techniques
• User story splitting

Requirements Classification Techniques

• Idea / Mind mapping
• Affinity Diagrams
• Multi-criteria decision analysis
• Wideband Delphi

Collaborative Gaming Techniques

• Remember the future
• Prune the product tree
• Sailboat technique

User Role Modeling Techniques

• User Proxies
• User Persona
• Extreme Persona

Need Analysis Techniques

• Five Why techniques
• Cause and effect diagram
• Cause and effect matrix
• SWOT analysis
• Value Stream Mapping

Process Flow Techniques

• Process flow diagram
• User Cases
• Spaghetti diagram
• Swimlane flowchart
• SIPOC diagram

Requirements Documentation Techniques

• User Story
• Context Diagram
• Use Case Diagrams

Business Rules Formats

• Business Rules Catalogue
• Decision Trees

Data Formats

• Entity Relationship Diagrams
• Data Flow Diagrams
• Data Dictionary
• State Table and State Diagrams

Interface Formats

• Report Table
• System Interface Table
• User Interface Flow diagram

The post Generally Accepted Product Management Practices appeared first on World Of Agile.

As part of the Introduction to Scaled Agile Framework series, this article with cover the Scaling Conetx and Some Basic Concepts like where scaling fits and how it works.

Let’s first understand what Scaling is?

As a word, Scaling means there are multiple teams working on a Product (Value Stream). 

Scaling Agile refers to the process where the established Agile methods (Scrum/Kanban) are applied to other layers of organization.

Look at the Matrix below to understand the layers of the organization. 

In any Project organization the ratio of Product and Teams is:

• 1 Team working on 1 Product
• 1 Team working on Many Products
• Many Teams working on 1 Product
• Many Teams working on Many Products 

The Matrix above shows the context of Product v/s Teams.

• When we define a Product – here we define an Independent Value Stream which makes sense from a market perspective.
• When we talk about teams, here we are talking about Development Team of Scrum which is 3-9 team members. This team excludes the Product Owner and Scrum Master.
• Scrum Only defines “One Team – One Product” Context. Scrum does not define the other contexts. Scaling is out of scope of Scrum.
• “Many Products – Many Team” context is defined by portfolio management, which is out of scope for most of existing scrum frameworks – SAFe is one of the most prevalent scaling framework that helps with
• “One Team – Many Product” quadrant is for Staff Pools who do heterogeneous type of work. Generally involved with ticketing systems in organizations. Kanban may work in this quadrant and the focus is here on resolving bottlenecks and getting heterogeneous work done without bottlenecks.

Context of Scaling and De-Scaling

When we think of larger products, we can think about descaling – that is, dividing the larger products first into smaller units of independent value streams (Products).

For the above product, the Scrum Context is that for each product (an independent value stream) there has to be a single product backlog, a single product owner and a single development team. Like the below diagram, each team works as an individual Scrum Team with their own “descaled” Product Backlog. There will have to be some considerations made to co-ordinate among the various dependent product backlogs. The diagram shows how the descaled products work.- Spotify is an example of framework which works on the principle of descaling

Context of Product Backlog and Product Owner

There is always a one to one relationship between a Product and Product Backlog and Product Owner. The context of the product backlog is shown below

The following structure where one is NOT OK. The accountability on the Product will go down if the following is implemented. It is better to descale the product instead of having a structure as shown below:

Context of a Product Owner and Development Team in Scaling

A Development team will always look up to Only one Product Owner.

A Development Team looking up to multiple PO means, the accountability is not central and conflicting decisions may come to the Development Team.

The post Scaling Context – Some Basics Concepts 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.