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….

What does a Manager do in an Agile Organization?

This article covers the role of a people manager in the context of an Organization. There is a lot of data on what Product Owners do, Scrum Masters do etc. However, when someone takes over the important role of People Manager, there is confusion in teams from a refusal to listen to the manager, to a feeling that the manager is micromanaging.

If you have taken over the role of an Agile Manager or an Agile Engineering Manager this article is an attempt to help you with your new role.

First, let’s cover the list of things we should stop doing.

• Don’t feed work directly to the team. Instead, route it through the Product Owner. 
• Stop asking for Status Reports. Instead, go to the team room or virtual team room, listen to their standups etc.
• Stop calling meetings. I know this is an extreme claim but think about it. Do you really need this meeting?
• Change or add team members without the team’s explicit permission. 

Now take a minute to see this video about turning the ship around by David Marquet

 

Set up an Impediment Board in your office. Tell your teams that you commit to working on the impediments any team member brings to you. An impediment is anything that blocks your team from getting their work done. First, check with ScrumMaster of the team what impediments he/she is solving for the team. The ones they are not able to solve are yours to solve.

Protect Teams Time – By asking teams to practice the concept of “Core Hours”. Core hours is the time members of an Agile team commit to being together. Add a rule in the organization that no one except team members can disturb the team during core hours. The team when in core hours may not respond to emails, chats etc.

Spend Teams Time Judiciously – Most teams now ( 2016 ) get only two to three hours of productive time at work. What if we can help create a system where teams spend most of their time doing value-add work as a team.

Don’t optimize your group for capacity, optimize for value: 

Behaviors in an Agile Delivery Team

As a Team Member of an Agile Team, we are always looking to understand what behaviours we should encourage and see practised within a high-performance Agile Team. Here is a list of 14 behaviours that as a team member you should model. I once learned this from an Agile expert. Be the example you want others to be.

1. Instead of complaining always having a “Bias Towards Action”.
2. Watching out for team members who need help and pairing with them to get work done.
3. Not blaming others outside of the team for what the team has done.
4. Taking the time to understand users.
5. Letting go of control and Trusting the team to get things done.
6. Making sure no one works on things that do not fit a sprint goal.
7. Not working on one-off projects without others knowing about it.
8. Giving the team enough free time and not demanding overtime all the time.
9. Coaching each other on how to receive feedback
10. Saying No and saying “If it’s not in the backlog we don’t know”.
11. Not compromising on quality.
12. Being on time.
13. Following core hours as a practice to do work.
14. Making sure everyone in the team is giving open and constructive feedback

Looking Beyond Large Scale Agility

After being involved with a group that is probably the most Agile anywhere in the world, seeing hundreds of companies over the last decade trying to become Agile and so miserably at that, or after having taught Leadership, Kanban, Scrum and Agile Engineering workshops and finding that the same problems exist in organizations that existed a decade ago, I am really starting to wonder if its time for us all to really Look beyond Large Scale Agility.

If you are in an organization that is busy implementing Agile Change frameworks like SaFe, Less, Dad, Nexus etc you may be wondering

• How all of this is going to improve your life. ?
• What is going to happen to all the hard work you have put in this organization over the years. ?
• Is your company getting better or worse?
• How are you going to make more money and be happier?

You are not alone. The issue I have come to realize more so lately is one of Scale. Agile is heavily dependent on people, less in the process. Yet most companies we work for are heavily driven by the process and profit  Have the meeting madness. Leaders are incentivized to drive down cost. The pressure of shareholder satisfaction makes things tough to change.

Agility tends to work well in smaller groups. If your organizations are really small say 50 people, it’s really tough to implement Any kind of Framework. Pretty much the culture is one of “Get it done”. From 100 to 150 People scale All these things work beautifully. More than that you are in the “I am not sure this is working Zone”.  Dunbar’s Number posits that 150 is the number of individuals with whom any one person can maintain stable relationships.

What we need is

• Sess – Small Scale Scrum  NOT Less – Large Scale Scrum
• RaFe, Right Agile Framework NOT SaFe Scaled Agile Framework

The fundamental issue in scaling beyond 150 to 200 is a simple one of coordination and one of leadership mismatch. At a scale of 150, you often have a group leader of some sort. The culture of this unit really depends on this leader. See this HBR Video that talks about 8 kinds of company culture.

If you see the video you would see one of the top kind of culture is Results Driven.

I would expect every profit driven organization is results driven. See the video above.

Every kind of organization should be results driven. So that means leaders are incentivized to get results.

Shown below is a typical organization where leaders are incentivized to get outcomes. Most of our organizations look like this. Broken by some sort of functional groups. Here shown are two Blue could be Sales and Marketing and Red – Could be Products. L (A) who is the leader for both the groups has to make sure the L(B)’s are incentivized correctly in  order to extract maximum results from the six leaders who in turn, so on and so forth

The book Leadership BS from  Jeffrey Pfeffer, a well known Stanford professor calls our many of the issues with leadership today. He goes at why leaders are actually not honest, not authentic, and not modest, do not often tell the truth, doesn’t build trust, and do not take care of others. In organizations such as the one above where top-down leadership is practiced, there is more of order following rather than ownership. Even if leaders really want to be Agile, The system is set up against them.

People who actually do the work are so far away from the real customers that they don’t have a clear understanding of what problems they are trying to solve for customers, are not empowered to decide anything without explicit permission from the leaders. In such organizations meetings is the norm as the person above has to delegate the work down, coordinate across different groups. Hence the normal problems of excessive meetings are seen in these organizations.

See this amazing Ted talk about what happens when leaders create an epidemic of meetings in organizations.

So how can we be Agile? Really agile. Agility is really about
– profitability of the business,
– Engagement of employees where they are empowered to solve and innovate for customers

It starts with three simple practices
1) Small groups that are direct customer facing creating a startup like a mentality in these groups
2) With a heavy focus on good solid agile engineering practices and a culture of teamwork.
3) Where leaders are elected by those they serve and are now serving than leading.

It’s really about Product or Service Agility. Are we creating products or services that delight our customers? We really cannot change org culture esp if your organization in more than 1000 people.

But we can do a lot of magic in the 125 range.

You can make a huge service to your organization by creating worthy leaders who are trained to lead from the side. The leaders can create a culture where truly the time of the team is protected so that they do not waste even a minute of their time in meaningless meetings, instead of by working together to creatively solve customer problems.

Share your thoughts and experiences on success or failure trying to implement large scaled Agile.

Agile Defined

The manifesto is governed by 4 Values and 12 Principles. Being Agile sticks when companies focus ground up starting with building the value system followed by practicing the values, doing some of the practices and hence getting the benefits. This is often referred as Inside Out Agility.

Under the Agile Umbrella, there are many methods. Scrum is a method, Kanban is another. There are many others as well. Within each of these methods, there are many practices.   

In general Being Agile means, you are using one or more of the Agile frameworks but are surely following the four values and 12 principles as much as you can.

The recommended approach to go with imbibing Agility is something called Inside Out Agility. This focuses on making sustainable changes based on Culture, Structure, Agile Values and Principles and then following practices like Agile and Scrum. Most of the Agile transformation programs that follow an outside in Agility in order to gain the benefit of Agility. While the Inside out is not an easy path it has proven to be more successful than any other approach.

Practicing Scrum Well

Just like any sports team. there can be the winners like the ones who go to the super bowl, or those that get kicked out each year right before the playoffs even start. ( If you don’t know American Football you may not get this point. I live in Seattle where football is a big deal ).

Anyways, it is up to the team and the coach to work together to produce a great product.This simplicity of Scrum becomes the reason where teams feel Scrum is not working. 

There are some necessary conditions for doing Scrum Well.

Energized And Empowered Scrum Team – On top of the list is how energized and empowered team members are to ship quality products out of the door.

The entire goal of Scrum is to create a direct relationship between the stakeholders who seek value and the people to can create value.

There should be a Culture that Values Transparency – In Organizations that do not value truth and transparency, Scrum may not add much value.

Management does not micromanage – Top down command & control and the Scrum culture of openness and honesty often contradict each other. In fact, more than 50 percent of Agile Transformations today fail because of the middle management’s inability to let go.

Have a Sense of Urgency: Scrum works well when the organizations feel the urgency to do things faster, and of higher quality. In places where there is no pressure to ship anything and where quality is not important, Scrum does not work well.

Jeff Sutherland, one of the co-creators of Scrum Suggests the following steps

1. Get Started with Stable Teams.
2. Look at Yesterday’s weather to successfully pull backlog items into a Sprint.
3. Swarm with One-Piece Continuous Flow.
4. Allot time for interrupts and do not allow the time to be exceeded during the Sprint. See Illegitimus non-Interruptus Pattern.
5. Write Daily Clean code by following XP Practices.
6. When things go wrong do something about it immediately (See Emergency Procedure).
7. Find out what one improvement will increase the happiness of the team the most, and implement that improvement in the next Sprint.
8. How do you get teams to have fun? (Happiness Metric).
9. Teams that finish early accelerate faster. Take less work into a Sprint.

Ref: http://www.scrumplop.org

Sometimes the teams give up on Scrum too soon saying “Scrum is not working, let’s try the other new framework”. You should try Scrum for at least one release cycle or a few sprints before changing anything. 

In this early stage do not change anything. Scrum is really good at exposing the mess in an organization. If your organization is afraid to fix the mess Scrum exposes, then it may be tough to use.

Remember the 10 things in Scrum are the simple rules of Scrum. Don’t change them.

Also, there are many other techniques e.g., Kanban. Feel free to evolve your process and use other Agile Practices as well.

Scrumtuphobia!  Fear of doing Scrum Wrong.  HENRIK KNIBERG

As a general guideline, as you master Scrum, you can always subscribe to practices from any of the Agile frameworks to become Agile. 

How Does Scrum Feel?

Let’s get some keywords out of the way first.  

Scrum  – A framework to deliver value to the customer iteratively.

Sprint – A time box where an increment of value is delivered. Mostly 1, 2, 3 or 4 weeks.

Roles-  Scrum has Three Roles.

• 1. Scrum Master – Remover of impediments. Team motivator, Servant leader
  2. Product Owner – Voice of the customer. Works with team and stakeholder to create value.
  3. Development Team – A self-organized cross-functional team that delivers value.
  4. Scrum Team – Collectively the Scrum Master, Product Owner, and Development team are called this.

Events– The Scrum Framework has four productive events. ( meetings )

• 1. Sprint Planning – Plan the work of sprint so that we can deliver value at the end of Sprint.
  2. Daily Scrum – A 15-minute daily plan.
  3. Sprint Review –  A product feedback, inspect and adapt cycle.
  4. Sprint Retrospective – A process improvement Inspect, Adapt Cycle

Artifacts – Things of value produced in a time-box.

1. Product Backlog – A backlog is a term for a list of things to do, also called Requirements. This is owned by the Product Owner
2. Sprint Backlog –  Also called As Task Board or Scrum Board.A tool used by the development team to be transparent about the work they are doing in the sprint.
3. Product Increment – This is the reason we do Scrum. To build something of value in Short iterations of time.

An easy way to remember the core Scrum Framework is with the 3-4-3 rule. Yes, there are only 10 things to the Scrum Framework.

In Scrum, 3 Roles, the Scrum Master, Product Owner, and Development team go to 4 Events – Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective in which the produce 3 core Artifacts. The Product Backlog, Sprint Backlog and the Product Increment Itself.

Let us look at what goes on in one sprint for a Scrum Team which is doing two-week sprints.

Day 1: Sprint Plan -The Development Team, Product Owner, and Scrum Master meet in a sprint planning event. This is normally 4 hours max for a two-week sprint. In this event, the team “Pulls” items that are ordered as high priority and breaks them into what done means for each item.  The team defines a Sprint Goal that they can march towards.

As the team finishes the sprint planning the Scrum Master is cleaning up the task board and getting it ready for the current sprint. The team members help prepare the board too.

Day 2:

The team starts with a Daily Scrum in the morning. The Daily Scrum is done in front of the task board.

It is a good practice to update the task board before the daily scrum to keep the daily scrum going smooth.

Day 5:

This team works on something called one-piece workflow. Which means they really like to finish one story completely before pulling another.

The task board on Day 5 looks like this. ( This is just an example)

The team has finished story A and is working on B on Day 5.

What else do you notice that is different from the task board today?

The team has also updated the burndown chart. Their burndown chart has the number of tasks on the Y-Axis and the number of days on X-Axis.

They also demo the  Backlog item A to the Product owner and get acceptance from him.

Day 9:

 

The team has finished two stories and decides not to pull the third story as planned as they have no more time. They get acceptance on the second story too. Way to go team.  You Rock!.

They meet in the evening for half an hour to “Get Ready for the Sprint Review”.

Day 10:

The team is delighted to have finished two of three stories. This is called the Say Do Ratio.

Sprint Review:  The Development Team, Product Owner, Scrum Master meet for an hour and a half to talk about what was delivered in the sprint. 

The product owner talks about the two stories completed and then the team members take turn to show the two stories to the stakeholders in the room. 

They get feedback back about a small change that was requested in the Story B. The product owner says he will get it changed.

The sprint review ends with a small celebration.

Sprint Retrospective:

The Development team, Product Owner, and Scrum Master meet to discuss improvements they can do to the process so that they can do better. They plan to meet for an hour and a half.

The entire Scrum team talks about the two impediments that came in between the sprint, that slowed them down due to which the second story took a bit longer than they thought. One of them being story B turned out to be much bigger than they thought.

They take an action item to break stories smaller so that this problem does not happen again. The Scrum Master erases all content in the room except the one action item that they took. 

This sprint ends.

Leadership Models and Books

As an Agile leader I find it useful to be reading books on leadership and models I can learn from.

Here are recommended reading if you are a leader working with people.

• 7 Habits of Effective People
• Primal Leadership or Emotional Intelligence ( Goleman)
• The Fifth Discipline  ( Senge)
• Fierce Conversations (Scott)
• Good To Great ( Collins)
• Difficult Conversations ( Harvard Negotiation Project )
• Drive (Pink)
• The Servant (Hunter)
• The Power of TED ( Emerald)
• The 5 Dysfunctions of a team ( Lencioni)
• Focusing In Clinical Practice – The Essence to Change
• Reinventing Organizations ( Frederic Laloux)
• The 3rd Alternative (Steven Covey)
• Leadership And Self Deception 
• Quality Software Management, Vol. 1: Systems Thinking ­ Gerald Weinberg
• Quality Software Management, Vol. 3: Congruent Action ­ Gerald Weinberg
• First Break All the Rules

 

New ScrumMaster Checklist

This list is a place for new ScrumMasters for their very first ScrumMaster Job.

Welcome to your new ScrumMaster task. It is a tough one and sure is confusing. No Organization actually has a role like this. So where do you start.

Set up a meeting with  your manager and the manager of the team that you will be ScrumMaster of.

This meeting is important so you can expect what kinds of things they are expecting you to do. You should talk to them about things you are expecting to do

1. Make impediments Visible.
2. Facilitate the 4 core Scrum Meetings
3. Remove Impediments

That is it. Make sure they are okay with these three things. If you hear no for all three of them, don’t take this job.There are many other things you can do but the above three are core to your job.

Make impediments Visible.

Next create a impediment board and make sure the managers know that you will put something here and if you cannot figure out how to solve it in a day or two, you will ask for their help. Also if possible make this a physical board.

Facilitate 4 Core Meetings.

Find out when the sprints are starting. If the team is not yet sprinting, just add the work they are each doing into one list and call that the product backlog for now.

Find our who the product owner. You have to make sure you have a Product Owner for Scrum to work.

In general all Scrum Meetings should follow the following principles

1) They need to be high energy

2) They need to start in time

3) Only the Team and PO are needed. Don’t invite anyone yet

4) They always end before time

A general agenda for all meeting

1. Opening
2. Purpose of the event
3. Task-board for each event
4.  Close with Action Items
5.  Do a mini retro about the event itself.

Here is the  five items for each of the meetings.

{Work in Progress}

Are you failing with Agile, Here is a checklist to help you fail?

I had a very interesting coffee discussion yesterday with a senior product engineer at a very large cloud computing team. It was centered around the fact that in Scrum when we put the pressure of velocity and show the demo, teams start shipping crap to customers.

Many teams working in Scrum and Agile techniques take Agile as a way to do fast paced development. When you look at the net output after a few years, the product is a bunch of messed up code that is worth throwing out.

The agile manifesto is centered around – Working Software over comprehensive documentation –

I wish this was instead written as  – Delighting customer over comprehensive documentation. Writing a well done product takes a significant amount of discipline from a product team. The teams that focus on output of showing something fast end up in rotten software over time.

Here is a checklist that will tell you if you are going to failing with your product. These are in no priority order

1) More Velocity Syndrome – Your customer or management is focused on more velocity every sprint. Soon coaches are trying to optimize for waste removal , fast paced demos and a each day feels like a 100 meter race.

2) Agile or Scrum Become more important that the product itself .  Think  of any place that has ever succeded by putting focus on the techniques. No agile technique will help you if your organization cannot focus on less things and get them done in a systematic way

When you are doing agile well, you should not heard the word agile or Scrum in a organization.

3) Agile coaches rule the roost: There is a new wave of  people who were not there 10 years ago . These are called Agile coaches. Many are self proclaimed gurus with no actual complex product creating background. Choose your coaches wisely and don’t listen to them managers. Good teams choose coaches well. If your coach comes in and starts telling you do that everything you do is wrong, show them the way. Ask them to stay for a release cycle and show you how to do it all the way.

4) Managers addicted to keeping people busy: Many managers are busy trying to keep people busy . Writing a good product requires focus, patience and a bit of love. If the manager is always trying to keep team members busy where is the time to innovate. When you hear someone saying i want 80 percent utilization, start looking for a new job. They clearly don’t know what they are doing.

 5) Product Backlog fiasco – Your backlog looks like a so messed that you feel like throwing up. A good backlog should be around 50 to 100 items and should be visual. The team should have a clear idea of what they are building.

6) Estimation Accuracy Epidemic ( Often called as Fibonacci Fever) – You will see teams trying to size work as 2 points, 3 points, 50 points. Management disagrees saying they want more accuracy of estimation.

Software is a empirical system the only way you know your product is right is when someone uses it. Follow a simple rule ship a few items to production every month or as needed.

7) The myth of the self organizing team – Putting five people together does not make anyone a team. A team needs a clear purpose, goal and a good coach to win. Some kinds of work may not need a team.

8) Bugs rate is going north – IF  you do Agile well you should see 0 defects. To do this you need to do a few simple things 

1. Work in pairs in small teams
2. Test your product well and don’t check-in code that does not have unit test
3. When you find a bug, write a test first, check it in, and then fix it. This way you never have to see the same bug again.
4. Keep Design simple but not Stupid. Many agile teams have gone to the extreme with Kiss principle. KISS – Keep it simple stupid does not mean – Do stupid things in code”.  Agile does not mean no design. Agile means you take the time to do necessary design.
5. Always demo work only when completely done.Done means done . There is no half done fully done.

9) You feel like moving from Scrum to Kanban or vice versa. Note that the process is not the problem, people are. When you switch to scrum, if you dont follow the values of Scrum, Openness, honesty, transparency you will fail. No questions asked.

10) Feedback and failure  is not appreciated here.  – If you are worried about giving feeback to any one in the group or  your manager for lack of fear of losing job or being humiliated, you are already in the wrong kind of team. if your organization i not appreciating failure or feedback, they do not appreciate you.

Of all the things the difference in great product companies is the ability to listen to customer and employee feedack

Do let me know if you check at least more than five in the list above yes. If you checked none of these items above you are working for a fake organization.

Have a great time building awesome products. Focus less on Agile focus more on your customer experience.