Scrum Your Meetings

How can we make our meetings productive. This is a billion-dollar question. Even if each one of us improve our meetings by 1% we save $$$ s for our organizations.

In this article, we look at one such technique called  Scrum Your Meetings:

Why Scrum Your Meetings:

In the first few pages of the book called Design Sprint, there is a picture which is worth million dollars. ( Picture modified a bit based from the book)

Normal Work Day for Most Companies:

Scrum Your Meetings Version

In the teams I have been recently we have been trying this and seeing really great results.

How do we Scrum The Meetings :

Work the Work is one way to think of this. The host of the meetings invites people. Recommend time not more than 60 minutes for a session. The goal is what can we get done in 60 minutes.

Step 1 - Goal Setting 10 minutes

The hosts present what is the goal that we are trying to achieve as a team in the next hour.

Notice the way the doing column does not have any more than one task for the team. This style of work is called Single Piece workflow.

Sometime you may do more than one task but as a general rule Don’t to start anything that cannot be done in an hour. 

Step 2: Close IM, phones , chats etc.

Step 3: Start Task ( Swarming around the first task )

The entire group works on the first task. Sometimes this means we are talking, sometime we may be writing a document, it depends on the work.

Suppose our goal is to create some document, we can start a shared document on google docs, or word docs and share it on a large screen. The first person types and others contribute to the document. You can also try a variant of this called Mobbing.

At 10 minutes the keyboard moves to the next person. Complete first task and pull next one. This way everyone has to work and no one gets to chill back and just talk.

Step 3: Close with action items or parking lot items

Conclusion

What if we can actually go home and eat dinner with the family and not worry about work. Imagine how much we can save by not context switching Every time someone randomly pings you in a chat, you are going to get distracted from the work you are doing now.

This kind of working even if your teams can practice once a week and once a week do a no meeting day. You will see infinite improvements to productivity and you will see many satisfied employees returning back home with a smiling face every day.

–Go for it , be the change and make it happen

How much of Agile is too much?

Many years ago, by which I mean 1996, I got attracted to something called Extreme Programming. I loved the fact that we could work in small teams, created tested products.

People like Martin Fowler, Uncle Bob, Dave Thomas made things more real. Using Scrum was easy as Scrum mostly works nicely at the team level.

I have seen Scrum work really well up to groups of 100 or so people. Beyond that, in theory, it’s supposed to scale. I was part of one of the largest and best implementations of Scrum at scale, I believe that the program had 1000 or so people, and after 2 years, the product died. It was the best process implementation I had ever seen of Scrum at scale, Scrum of Scrums, distributed Agile and yet it failed for one reason – They delayed the shipping of the product, by trying to gold plate it with more and more features. Then bad things happened, people were fired, many have now become agile coaches in other companies.

Then came Agile transformation. – To me, it meant applying Agile at a large program or portfolio level. When large companies started adopting Agile, they found immediate issues in terms of scaling. With that was born a billion dollar industry. Scaled Scrum Frameworks.

• SAFe
• LeSS
• Nexus
• ….

• Certification bodies sprung up
  • ScrumAlliance
  • Scrum.org .
  • Lean Kanban Training etc.

So far I have not seen even many successful implementations of any of these large scale frameworks. The reason no framework can fit is our organizations are complex adaptive systems.

Even in the phase of Agile Transformation mostly everything was still in the IT side. One of the financial giants I know after 8 years of trying agile, many millions help from consulting companies, just closed down their agile coaching office.

And now the year 2019 seems to be the year of Business Agility. Essentially running the agile business in an agile manner. While these are fundamentally sound principles, the agile community has not had much success in Agile beyond IT level.

At the core, if we follow simple rules that small teams work better, form many two pizza teams and have each manager to have not more than two pizza teams. Give them the autonomy they need to solve the complex problems of the business.

I am curious to see the certification bandwagons like SAFe now add new tracks for business agility. I am convinced that small groups, cross-functional armies are better. Too much structure in scaling may not yield the desired results

We can create learning organizations, we can use systems thinking to learn from our organizational units, however, I don’t think there is enough data yet to prove that running everything under the banner of agile may be a wise thing.

These theories may be proven wrong in some years, who knows.

But i guess only time will tell.

What is the role of HR in the Success of an employee in an Agile Organization?

In Organizations that practice Agility, there is a growing need now to reimagine the role of HR. In this article, we see just from an employees perspective areas when HR interacts with an employee during the employee life cycle.

Mark has worked for 12 years. He has a masters degree. He is well respected in his field. His skill is sought out in the industry and he is really happy with what he is doing.

Employee Lifecycle

Let’s look at this lifecycle where typical involvement of HR happens.

The term human resources is a challenging one. Irrespective of what we call this group its what this group does that can make a huge shift to an Agile Organization.

Recruitment:

In most cases, if you are really good at what you do, you probably have a good job. So if you are a recruiter who is hiring for experienced professionals you need to do a lot more than just searching for profiles on job boards or LinkedIn. Most experienced recruiters have a tactic of approaching candidates, and over a period of time, getting them to think about possible future opportunities.

A few years back, I had hired one of the best Agile recruiters ever. As soon as she joined, all of a sudden our recruitment pipeline would look really good. She would organize events that looked more like meetups, and in those meetups, she would invite some of the candidates she was targeting either as a speaker or an attendee.

Good recruiters make the whole process seamless. Every small detail would have been thought through. Each email that goes out or the phone call has a fun human touch. Even when people are not hired, they would get an email why they were not hired, and what would they have to do to get hired. We have had numerous cases where people would come back after months saying, I completed all the items in the list, now hire me.

On-Boarding New Employees

Why do we celebrate only when people leave the company? While we should do that, why not make a lot of noise and make someone feel awesome. on the day they join the company.

Here are some ideas to make Mark’s first day memorable.

• Send Mark something he/she likes a few days before they start.
• Stand with your team and clap and invite Mark as he joins the organizations.
• Keep paperwork on day 1 to a minimum.
• Laptops should be ready when they arrive not after a few days.
• Keep a task board of things they have to do and give them a few days to complete the work.
• Don’t bore them with corporate training on the first day. let them do the work they joined to do.

Professional Development

Most work not always but in many cases has come down to teamwork. Every employee needs to set for themselves a few goals and they should be measured on reaching those goals.

1. Goals to help grow self.
2. Goals to help the team
3. Goals to help the organization.

Separate feedback systems from Financial Incentives. Dan Pinks Drive  Drive: The surprising truth about what motivates us. Are you creating ways in the organization to encourage Autonomy, Mastery, and Purpose?

Minimize Titles, Promote roles instead. All organizations do need some sort of internal numerical systems, which should only be used for salary purposes. In some organizations, these levels are given so much importance that it ends up killing creativity

Retention

It’s easier to hire new employees but tough to retain them. Each person has many reasons to work. Most of us work to get paid. But beyond that, we work to use our creative mind and make a difference to the community around us.

People leave when they have a bad boss, and when work does not motivate them anymore. This is where leadership role is critical in creating organization systems where people have the freedom to work, but are working towards clear goals for the group that they are working on.

A big part of retention is the ability of an employee to feel like they own the organization.

There is a difference between happy employees and engaged employees. What you want are employees who are engaged in what they are doing and hence happy doing it.

HR can play a critical role in creating 360 feedback systems, happiness surveys, enabling organization-wide collaboration tools. video conferencing systems, work from home policies, timesheet only for billable work, open PTO,

Exit

When people decide to leave, support them. Don’t try to stop them. There is a reason they are leaving. Treat them as future customers, future employees. Ask them in the exit interview what the company could have done differently . In some cases, employees do leave just because they are following the money, and those kinds of employees who are only motivated by money are better off to leave.

What you don’t want to lose are those dedicated employees who would not have left, if they felt they had been heard, they felt their work mattered and when work gets fun, people often don’t leave.

In all of this having even one strong leader in your HR team who understand that can bring agile values to the work they do, they will make a huge difference to your workforce. Find the right leader to lead your HR group. And as you do so maybe call it Resources for Human not Human Resources.

Can Agile work for Infrastructure and Ops Groups?

Yes. Agile can work with Infra and ops groups. This article outlines some basic principles during your agile transformation journey.

When an organization gets more and more Agile soon they realize that one of their bottlenecks in their own IT operations department. With the concept of physical datacenters slowly moving to the cloud the nature of work done in operations groups are also changing drastically with time.

The DevOps movement has been successful in moving parts of the operations, upstream so that the engineering teams can mostly be self sufficient and not have to deal with handovers and delays due to large wait periods before things get deployed. Concepts like SAAS, IAAS, PAAS, Cloud etc fundamentally changed the notion of network engineers, DBA and many roles that were typically there in classical IT operations groups.

Organizations that have tried Agile in Operations are moving from processes like ITIL and are heavily invested in specialized skills, network engineers, DBA’s etc.

Here are some pointers to transforming your Infra and Ops group to an agile organization.

First things first

1. Identify all the Service Lines that your group supports and align cross-functional scrum teams around these service lines. For large services, consider using the concept of PODS which compose many small cross-functional feature teams. Set up Scrum of Scrums across PODS. These teams can follow a Scrum or Scrumban model of working. Use dedicated Scrum master for a team or an agile coach for a POD model . Teams need help during the change. Don’t ignore this role.
2. Identify one or more product owner for the service lines.
3. Move some of the operations folks upstream to directly work with engineering teams to enable DevOps and provide the necessary automation required to seamlessly deploy to production.
4. For incidence response teams, involve the actual dev teams in the process. The first level response teams may not be able to use Scrum as most of the work they do may be demand based.
5. Streamline ticketing systems so ticket duplications in systems like Service Now are removed. The same ticket should be used by teams to solve the incident. In earlier organizations since the org was siloed each group had its own ticket ending up in a lot of duplication and coordination of work.
6. Education for leadership and middle management is key.
7. Consider rolling this change to the entire org in some sort of structured manner using internal and external coaches so that there is minimal disruption to the operations.
8. Set up leadership impediment board to relentlessly remove impediment across the organization.
9. performance measurement systems should be changed to encourage more cross-functional learning than a siloed expert based learning the culture.

Scrum Essentials

What is Scrum?

Role:  Scrum Product Owner

Role: ScrumMaster

Role: Team

Artifact: Working Agreement?

Artifact: Product Backlog

Artifact: Sprint Backlog

Artifact: Definition of done?

Artifact: Definition of ready?

Event: Sprint Planning Defined

What is the most important role in the Scrum team?

Paper napkin design?

What is MosCow Rule?

Measuring success in agile projects?

How do we do effective Daily Scrum?

How do we select velocity?

How do we measure productivity?

What is 13 forms of leadership?

What is the relationship between user stories and use cases?

What is a story point?

Can we change the length of a sprint?

How soon can we see improvements when we start using Scrum?

How can I estimate on something I know nothing about?

What are different techniques to size stories?

What is a ScrumMaster mission statement?

What is a book list for agile teams?

Is there an Agile meeting cheatsheet?

What is a ideal source structure for a .NET project that is agile?

What are product owner teams and how do we set them up?

What is metascrum?

What is the relationship between story point and complexity?

1. What is a self-organizing team?

What is Sprint Planning?

Why Sprint Planning:

Remember is Scrum we work in baby steps. Sprint Planning is the event where we plan what we can achieve as a Scrum Team in Two weeks. We need all members of the team in the Sprint Planning. Giving a sports analogy this is the meeting on the day of the big game in the locker room.

Agenda:

1. OPENING   – Welcome, Parking Lot, Working Agreement, Action Items  for meeting
2. WHAT CAN WE DO IN THIS SPRINT –  This is a discussion between the PO and the team to decide how many Product Backlog items can be completed in this sprint.
3. THINK ABOUT PLANNED vs UNPLANNED WORK
4. DECIDE A SPRINT GOAL- Collectively the team and PO write a sprint goal defining the purpose of the sprint.
5. TASK BREAKDOWN- The team members work in groups to break down tasks for each Product Backlog Item. (This can take a while)
6. SPRINT FORECASTING AND CONFIDENCE VOTE. Scrum Master checks with the team if they feel comfortable with the work they have planned.
7. CLOSE – Clear Parking Lot. Assign names to Action Items and do a Retrospective on how the meeting went.

10 Smells of an InEffective Sprint Plan

1. The team pulls stories that do not have acceptance criteria
2. The meeting finishes really quickly
3. The meeting goes forever 6 to 8 hours
4. Everyone has laptops open and no one is talking to each other
5. Team members are being told what to do
6. Stories and Acceptance Criteria are being written for the first time here
7. The team is estimating the story here for the first time
8. The Scrum Master is controlling the entire meeting
9. New Team members feel lost
10. Managers are sitting idle watching the plan instead of participating in it

Note: In Distributed teams sometimes the sprint planning is done over two days. Esp when you have PO in one country like the USA and the team in completely opposite time zone like Singapore.

 

Paper Plane Game

Purpose:

To demonstrate the power of time-box or Sprint that makes the heartbeat of an agile framework like Scrum.

Type:  Team Game

How many can you build in three minutes?

Time Needed: 45 minutes

Number of people per team: 6

Supplies Needed:

1. Used Printer Paper 50 per team
2. One flip chart and a marker to keep score

The goal of the game:

The goal of the game is for each team to create as much high quality tested planes that can fly a distance of at least 30 meters . The world record holder last checked in June 2016 was somewhere in Germany

Each iteration last 9 minutes.

One fold at a time

1. 3 minutes for planning,
2. 3 minutes of actual build ( test included) time,
3. 3 minutes for review/retrospective – 

Rules for playing the game:

1. Build as many paper planes as you can in a 3-minute time box.
2. One player can only do one fold at a time. That rules stays true for all three time-boxes.
3. The planes should be built

   

   Rules

   and tested in the 3-minute increment

4. Only planes that cross 30 meters will be counted
5. Each team should give a count of how many planes they are going to build before the time-box starts.
6. Subtract the final count of planes that actually flew from the planes that were built but were not tested or completed.  Eg: Team A said they will make 4 planes, 7 planes flew all the way but 5 were WIP ( work in progress). Subtract WIP so the actual is 7-5 =2
7. The team has to come up with one idea of improvement at the retrospective. Have one member in the team be the counter.
8. The front of the plane should be blunt to avoid injury to the team members.
9. You cannot crush the plane into a ball and throw.

Please recycle the paper once done

Debrief: ( pick any two )

• Each table talks about what made them improve over the three iterations
• Talk about what would have happened if the time box was not there
• Talk about how waterfall may be different from this.
• Talk about who made the final design decisions in the team.
• Talk about any wastes they removed from the system that helped them get better.

Disclaimers:

Original Creator: Not me. I am still trying to find out. I learned it from another trainer.

There are many variations of this game. This is one way I  use it in my workshops

 

Unlike Monopoly – The Best Scrum Simulation Game for Workshops

Overview:

I have been teaching Agile workshops since 2007. I have experimented with various games over the years. In 2014 or so I modified the Scrum Simulation game which I do in day 2 of my workshop and found that people got hooked into this.
Some twists this game has makes it a real learning This article is a facilitator guide on how to run this game. I have played this game more than 100 times and always had amazing results.

Name of the Game – Unlike Monopoly – A Scrum Simulation

Length of this game:  3 hours 

Learning Objectives

1. Learn how to use the Scrum Framework
2. Learn the power of Timeboxing
3. That architecture evolves over Sprints.
4. The power of working increment at the end of every sprint
5. Experience high-performance teamwork
6. Learn about how learning about the product in each sprint is essential to build better products
7. Learn how early  Customer feedback is critical to the success
8. Learn that even adults can have some fun and draw, paint, dance etc

Supplies needed:

1. Something for board
2. Glue sticks
3. Playdoh
4. Voting Dots
5. Crayons
6. Clear Tape
7. Scissors
8. Rubberbands
9. Any kinds of Arts Supplies

 

Rules of the game: 

In a flip chart write down the following simple rules for this game:

1. The game should be unlike Monopoly.  Monopoly is still one of the most sold board games. However, it has its own issues, long gameplay time, a winner in this game takes time etc.
2. The game should have a clear start and end.
3. Minimum game time should be 10 minutes at the end of three sprints.
4. There must movement in the game for the players. For e.g, they could be jumping, running, moving around the table etc.
5. Each team can come with its theme for the game. For eg. One version of a game they built Woofopoly – a game for dogs
6. Once we build the game,  people in the workshops including invited guests will play the game for at least 15 minutes.

There are three parts to this game:

Part 1 – Ideation– 1 Hour 10 minutes

Part 2 – Build And Ship – 1.5 hours  Three sprints to get the game ready to ship

Part 3 – Play the game

Part 1:  Ideation –  1  Hour 10 minutes

This part when I have skipped ended up in more mess in the actual sprinting process.

Step 1- Pick a theme – 10 minutes Tell the team that they should pick a theme that can compete on the shelves with Monopoly. Encourage them that first they collect all ideas on sticky notes, and then pick one concept from the list.

Step 2- Product backlog Refresher. – 15 minutes Explain What is a Product Backlog, That each item should be an increment of value ( for e.g.) if they write an item called to build a dice, that is not of value as by just building a dice. Introduce Epics, Theme.

Introduce what is a user story and concept of Acceptance Criteria

Step 3 –  Write backlog items and get some of them ready.  Let the team sit down and write product backlog items – 45 minutes

Given the team time to write some of the stories, have the Product owner in the team order the backlog, and they write acceptance criteria for at least 3 -4 items to start with. One template to use for acceptance criteria is –

• What does it look like
• How does it behave
• What should it not do?

Tell them to capture the discussion around these three questions as acceptance criteria.
Challenge the team if you see stories that do not add an increment of value or look more like tasks. I have them completely restart at times.

Part 2 – Build and Ship 

Setup – In this phase, the teams will build the product in three sprints. Each sprint has 27 minutes.

1. Sprint planning –   3 minutes
2. Day 1 – 8 minutes
3. Daily Scrum – 2 minutes
4. Day 2 – 8 minutes
5. Sprint Review – 3 Minutes
6. Sprint Retro – 3 Minutes

Keep a visual indicator for this.

Also generally playing some lively music during the sprints day 1 and day 2, will keep the energy high, ALso before starting sprints take a break. That way you can go all the way

Giving instructions: Tell them how the time would work. Identify a facilitator in each team and tell them to self-score and tell them to follow all the Scrum Practices they have learned so far. Show them how the big timer works. See timer eg below

Start a timer( google one is good)  for 27 minutes on a big screen

Let the teams start Scrumming. After the first sprint is over, I give a coaching report of what I observed about how the teams did as far as following the process goes. Not more than a minute per team.

 

Part 3 – Play –  Tell each team to pick a marketing person on the team and do a 30-sec pitch and answer one question – “Why should we play their game”. Once every team has pitched, asked everyone to move to some game and start the timer for 10 minutes. After 3 minutes ask those who played the game their instant feedback to those who built on what they liked about the game and any ideas they see for improvement.

That is it, the simulation ends.  As a coach observe for these things

1. Did the do their stand up? Did impediments emerge
2. Did Scrum Master remove impediments
3. Were they following the Scrum Process, sometimes in the fun they have they forget completely about the main reason for this simulation is to practice Scrum.
4. Did they create a working at the end of every sprint?

 

 

Meetings – From Hell – Part 1

If you take any average size company meetings are a given.

Be definItion ( dictionary.com )

a meeting is an assembly of people, especially the members of a society or committee, for discussion or entertainment
I wish here what it said was something like

• A meeting is a pointless gathering of employees in a room or phone, where we discuss reasons for why another meeting is to be created
• A meeting is a place where leaders try to force their agenda on employees so that it looks like they are forcing collaboration
• A meeting is a gathering of wandering minds who are not sure how to come to decisions and they need someone else in the company to take the risk so that the blame does not come on them

Here are some common dysfunctions of meeting that we all have seen

– Safety Shanker wants to decide if a certain decision is a right thing to do. He wants to make sure he does not get someone later blaming him for the decision he could have taken. So he calls a meeting of all the people he thinks to weigh in on this topic. His goal is simply to make sure that he tells this groups what he is about to do

– Panic Mike finds out that the project schedule has slipped. Instead of going to the team room where work is happening, he calls the entire team to a meeting to get status. His agenda is clear he wants to put pressure on the team so that when the project eventually fails for some reason, mikes boss Clara does not point fingers at him.

This problem of THE MEETING has now become an epidemic. I know people who feel their day was useless if they are not in back to back meetings.

In a typical meeting from hell, there is some sort of conference room, either physical or virtual and more than 8 to 10 people and one person who is  trying to get their agenda through.

Why have we created such organizations where we allow these dysfunctions. Do we really understand the cost we are incurring in meetings and not creating an organization where decisions can be taken without calling a meeting?

What if we create a culture of Collaboration without meetings.

Calling a one-hour meeting of 10 employees is an exceptionally expensive affair. If you were the owner of this company would you tolerate your employees sitting for hours together in meetings?

Collaboration is important but not committees and meetings. The last decade of me leading teams, coaching organizations shed light on some basics

Collaborations are often like a daily standup, huddle. These are more informal and done as needed only. They are also  not done in a conference room

Telling a bunch of people to decide on their own does not work, neither forcing them to decide.

What you need to create in teams is a sense of ownership. They need to own the problem and the solution. They may go wrong many times but they are making decisions quickly. A good measure of understanding an organizational agility is how quickly a new employee gets productive i.e

• gets a laptop, login credentials
• Starts to learn from his peers what he or she is supposed to do

Delegate Decisions down. Here is a way to start

1. Write down for one week all that you do. Write down all the meetings you went to and how you contributed to this meeting
2. Notice how much of the work you did that week is actually what you were hired to do. How much was a value-add?
3. Observe what may have happened if you did not to the meeting. I am guessing they may have gone ahead and done something about it.
4. Last step. Write down all the things you do
   1. Go to the Planning meeting
   2. Weekly Design session.
   3. Cross-team planning.
5. In the list above mark the ones that are customer facing vs just internal process.
6. Put a plan to simplify all the work that is an internal process.

Help remove the Meeting Epidemic. Be the change in your organization..

.

Agile Metrics

This article presents guidelines and examples of metrics you as a leader can help set for the group or team

It is really important that an organization does not measure only to demonstrate to others in the company that things are getting done. There is a false sense of comfort in these metrics. It is important to measureless.

“Remember – What you measure gets done”

–Attribute pending

5 rules when selecting metrics: ( VOIRS Rule)

• Make what you measure, is Visible.  Everyone should be able to see what is being measured. Customer satisfaction survey results -outcome metric, velocity – output metric. A good mix is always required.
• Outcome driven metrics always produce better results that output driven metrics.
• Make it Inclusive – let those who you want to measure have a say on how they want to be measured. Get input from teams. If you get buy-in from teams then metrics makes a lot of sense
• Make it Real-Time. – If metrics need translation by humans in an excel sheet there is something wrong with such metrics.
• System metrics are better than People metric. Measure more of how the system is doing and less of how people are doing.

Measuring Process Effectiveness

Measuring ability to reach Strategic goals at a regular cadence

Any product or service organization has business goals. These goals are often things like  ( in this case we have shown an airline example )

• One Integrated Airline Booking Experience
• Reduce customer complaints by 30 %
• The launch of 4 more cities for new flights.

When it comes down to the teams these goals are compounded with so many other little internal goals etc that somewhere along the lines, the big picture goal is lost. So leadership job is to regularly communicate these goals and make sure everyone in your organization is focused around these key goals. There will be other things but many times those other internal work items slow down the more important strategic priorities.

In the example above 9 different epics have to be done to get the three goals achieved. Each epic could be made of many many smaller epics or smaller user stories or backlog items.

So how do we measure things from here?

Metric – Lead Time – This is the time when the requirement was first identified in the organization and added as the core component of the strategic initiative to the time it was actually delivered to the customer.  Tools can do this easily. The difference of end and start is the lead time.

Monitor “Cycle time”.

Cycle time is the time taken at each step. in the doing column. Time from the time some work start till it is finished. The customer does not see it

Lead Time is = Sum of Wait Times + Sum of Cycle Time. In this case, we are taking Cycle Time to be the actual Value Add time. Really go and figure out where waits are in the process and help remove these waits. Waits are often seen

• when people are waiting for approvals,
• Only a few people in the organization can get some things done. Remove the silos.

All the work note ” All of the work” a team does should go from one list. 

Show a live report of where these epics are at any given moment

Measuring Agility.

How do we know how Agile we are. It’s surely not a gut feeling or some massive assessment. Assess systems, not people. Using Agile Principles as a measure of Agility.

http://agilemanifesto.org/principles.html

Shown here is an Agile Principles Card. Have each team sort through the 12 principles from “Yes to do it” green or no we don’t do it ” Red”. Collectively prioritize the red ones and then come up with action items as story cards to move items from Red to Green.

 

Measuring Product Effectiveness

Customer Satisfaction 

If you have a good product you should see higher customer satisfaction. Regular customer feedback collected real time from customers should be shared as is with teams that produced that feature. A much-debated technique is called Net Promoter Score. It is just one measure and should be used for what its worth. A point of reference.

Amount of features in the product that is actually used. 

80 % of the features we produce are hardly used. You could use the four categories in the Kano Model https://www.mindtools.com/pages/article/newCT_97.htm

Every product manager should know how many of the four categories of features they have from the Kano Model in their product

As per this model, every feature can be categorized into:

• Mandatory features – Must be present in order for users to be satisfied.
• Linear Features – The more of this is better
• Exciters or Delighters – These are not the reason we buy a product for. A feature she does not know exists until she uses it.

The image above is from http://foldingburritos.com

Mandatory Features – Customers are quite indifferent to must-be featured. For Eg Do you ever buy a phone because it makes a phone call?

Linear features – Customer satisfaction is more around linear or performance features

Exciters or Delighters – These are huge pluses to customer satisfaction. For eg the first time Gmail said, Hey you have forgotten to attach a document when your document says something is attached.

Collect data about all the features in the product broken down by the three categories in real time. This can be achieved when you tag epics as a Linear, Mandatory or Exciter in your Product Backlog tool.

 

 

Measuring Leadership Effectiveness

A #1 reason for Agile to not be as successful in the organization is due to lack of middle management support. See State of Agile Survey By Version One. 

 

– the picture above is from State of Agile Survey By Version One

As you look through the list, it is clear that effective leadership can actually help resolve a lot of these challenges listed. So how do we measure effective leadership?

• Are leaders solving daily the biggest impediments of the organization? Are they helping daily?
• Are they delegating decisions down where information exists and don’t punish people for making decisions?
• Are they setting clear boundaries for teams to operate in?
• Have they separated feedback from performance reviews?  Feedback should be routine not drama.

This can be collected from teams from regular automated surveys or 360 feedback. Leadership effectiveness is a much bigger topic that we will surely address in a later blog.

Conclusion:

This article presents very few metrics mainly around three categories Process Effectiveness,  Product Effectiveness, and Leadership Effectiveness.  Note that velocity is an output indicator and not good to measure effectiveness. It can simply be used to predict future dates that is all and it is a lagging indicator.  Also, note that it is important that all of this be automated and be touch-free leaving nothing to interpretation. Also, this is the main metrics that should measure and it’s really up to you as long as you pay attention to  VOIRS rule. 

Make it useful, measureless, get more done….