Agile Metrics 101

Many organizations rely on metrics: spreadsheets, data, numbers and measurements in order to monitor the health of projects.  In a traditional project where value isn’t delivered until the end, it’s probably pretty important to try to know where you are along the way.  In Scrum, the regular delivery of valuable  shipable, high-quality, working software negates the need for many traditional measurements.  Here are a few ideas to keep in mind when thinking about metrics in an agile project.

1. Measurement Paradox.  Albert Einstein said “not everything that can be counted counts, and not everything that counts can be counted.”  This is the heart of the measurement paradox.  Especially with modern technology and ALM systems we have access to so much data!  But just because the data exists does not automatically mean we should use it or that it’s valuable.  Additionally, as we start to use some of this data, we create all of these isolated measurements – and when we present these isolated measurements to management and stakeholders, they draw system wide conclusions.  Hey, that’s not fair!  Great examples of isolated measurements in software projects include lines of code, number of test cases, number of hours worked, etc.

2. Hawthorne Effect.  When you measure something, you influence it.  The Hawthorne effect describes this behavioral psychology concept where people unconsciously change the way they behave in response to being measured.  This is not necessarily a positive or negative thing, but it turns out that most traditional metrics have negative Hawthorne effects.  For example, measuring test pass/fail percentage almost always causes the percentage to go up.  As people think to themselves “higher is better,” they may start writing smaller test cases, passing tests and writing defects anyway, or a number of other things that will affect the passing percentage.  In an agile project, try measuring accepted features or cycle time for closing customer complaints – these types of things have positive Hawthorne effects.

3. Measure Up!  It turns out that not only do you influence what you measure, you also end up getting only what measure, and loose things that you cannot measure like collaboration, customer service, employee happiness, and creativity.  Woah! – those are the most important things, aren’t they?  The things that every business strives for, yes?  Robert Austin talks a lot about these concepts in his book “Measuring and Managing Performance in Organizations” and comes to a clever conclusion: Measure Up.  The idea is to measure one level above from where typical metrics are taken.  For example, in software project we often tie defects to the developer that wrote them.  Instead, try measuring a level up: perhaps defects per team, or better yet, customer reported defects.  These higher level measurements make it easier for individuals and teams to collaborate and work together to solve problems.  Besides, when it comes right down to it, your customer doesn’t really care about all the low level metrics.

When Scrum teams are delivering done software every few weeks, there is very little need for traditional predictive metrics.  Ensuring you have done potentially shipable software each sprint, looking at a release burndown, and perhaps some measurement of team happiness will provide your organization with more valuable information than any set of isolated metrics ever could.

Also cross-posted here:  http://www.centare.com/agile-metrics-101/

Advertisements

Freedom!!! (and feeding the system)

About a month ago, my engagement at a client ended.  This is a good thing.  Being a consultant before and working for some very traditional companies, this lead me to believe that the next thing on my desk would be another client engagement.

I mean, if I’m billing, I’m costing, right?

Well, it turns out this is a very narrow view of value.  Having freedom in your job and autonomy over your work can produce value also.

The upside:

Feeding the System.  If we take a wider look at value, a more holistic systems view of what value is, we can see that a healthy and productive system is valuable in and of itself.  We can even start to trace the health of the system to direct profits (maybe, we’ll leave this for another time).  In any case, if we want a healthy system, we have to work at that, we have to feed the system.  How?  In my context it’s run the gambit from discussing our companies benefit packages, to looking at speakers for an upcoming conference, to helping out a few colleagues with their work, to simply taking some time to talk with and listen to colleagues having work issues.

Another upside is that creativity is trending upwards.  Outside the walls of the 8-5 gig, I have so many reflections, new ideas, and energy to pursue them.  I’ve done some writing and researching that needed doing.  I’ve had the opportunity to learn from my colleagues and attend some workshops.

The downside:

This.  Is.  Hard.  It is mentally challenging to control your own destiny.  Exciting, sure, but also exhausting at times.  Creativity ebbs and flows, and there are more “good days” and “bad days” further out on the good/bad spectrum compared to clocking it in from 8-5.  And there is no denying that, largely due to my past work history, there is that voice in the back of my mind saying “this isn’t sustainable, watch for pink-slips.”  Freedom can be paralyzing.  Autonomy requires practice.

Final thoughts:

I’m not going to try to equate this type of value to profit.  I know I’m providing value, and I know I’m not providing profit.  Surely this isn’t a permanent configuration, and I’ll be back teaching and coaching soon.  But a “balanced approach” (thank goodness I’m not a politician, I may be actually able to do this) to work that splits time between direct-profit-producing-activities and feeding-the-system-value-producing-activities is, in my opinion, exactly what is necessary for a high performance organization.

Kanban Made Easy!

Kanban is a great way to organize work when a simple “To-Do” list just ins’t quite cutting it.  Those To-Do lists always seem to grow faster than tasks are completed, and we can quickly get overwhelmed and frustrated.  Kanban lends some relief to common To-Do list woes by focusing on these three things:

1. Visualizing your Work
2. Limiting Work in Progress (WIP)
3. Producing Flow

What’s more is that it’s simple to get started with.  Select a location for your Kanban Board in a nearby, public, high-traffic area where everyone who needs to can gather, see and have a discussion around the Board.  Make three columns: “TO DO” “DOING” and “DONE.”  Write down all the tasks on stickies or note-cards and place them in the “TO DO” column.  Try to give them some order or priority.  Congratulations, you’ve just visualized your work.

Now for the fun part.  Decide on a WIP limit for the “DOING” column.  Studies suggest that we’re really only good at doing 1 or 2 things at a time.  After that, we’re spending a lot of time switching between tasks and we loose efficiency.  As you have availability in the “DOING” column, pull in tasks from the “TO DO” column, but only as many as your WIP limit.  When the task is completely finished, pull it into the “DONE” column.

This pulling action along with the limited work in progress produces flow.  People and teams using Kanban will start to notice it appears things are getting done more quickly, and more things are getting done overall.  This sense of accomplishment creates built in positive feedback.  As we see more and more things in the “DONE” column, we’re excited to pull more and more tasks to “DOING” and “DONE,” creating more and more flow!

We’ve seen Kanban used successfully in a variety of situations.  Among the most popular places are support or help desks – very useful in handling high volumes of support tickets without overwhelming the people doing the work.  We’ve also seen Kanban be successful in other diverse areas such as sales backlog management and even wedding/event planning!

Also cross-posted here:  http://www.centare.com/kanban-made-easy/

Trust the Team!

One of the Agile Manifesto principles says we should “build projects around motivated individuals – give them the environment and support they need – and trust them to get the job done.”

Recently I was reminded of how powerful a Scrum team can be when we simply trust that they can solve a problem.  We were looking at using some new technology, something the business wasn’t familiar with at all and the team had only limited training on.  As is common in large companies we got stuck in an analysis loop for quite a while.  The business wasn’t really comfortable moving ahead with this new technology until a swath of questions were answered.  How will it work when it’s done?  How long will it take?  Are you sure the team can handle it?  We need to know what the plan is!  What if it doesn’t work, what are our contingency plans?

All of these types of questions make for good discussion, and team and business should talk about them, don’t get me wrong.  The problem comes in when these types of questions stifle exploration and creativity.  We have a whole team of highly skilled developers just waiting to tackle this cool new problem, and we’re holding them up!

The team decided to dig in and do some investigation while the business was still talking through their questions   After a few weeks we had something to show, something to demo, and something to have a real conversation about.  Concrete working software.  This is the game changer.  It’s much easier to have a conversation about all the risks and concerns of the business when talking about chunk of working software.  The team continued on this path for a few weeks and kept exploring this new technology, gets more and more pieces of the puzzle put together, and learning a ton along the way.

Too often we try to centralize decision making authority with management.  When in fact, the best way to develop a complex product in a complex environment is to distribute decision making authority to the lower responsible level – in the case of product development with Scrum, this is the Scrum team.  Trust your team, give them freedom to explore and learn.  Always trust that the smart people you’ve hired to build your product can do just that – build a product.

 ”Intelligent control appears as uncontrol or freedom and for that reason it is genuinely intelligent control”
~Loazi, 600BC.

 

Also cross-posted here: http://www.centare.com/trust-the-team/

The Role of Empowerment in Self-Organization

Intelligent control appears as uncontrol or freedom. And for that reason it is genuinely intelligent control. Unintelligent control appears as external domination. And for that reason it is really unintelligent control. Intelligent control exerts influence without appearing to do so. Unintelligent control tries to influence by making a show of force.
~Laozi, 600 BC

The industrial revolution brought about some great ideas on how to make people and machines incredibly efficient.  When we’re doing task work, repetitive work, or any type of work that is algorithmic (can be done by following a set of rules, even extremely complicated ones), then traditional management reigns.  When we’re doing knowledge work, creative work, or any type of work that is heuristic (cannot be done via algorithm, requires trial&error to produce learning and doing), then traditional management starts to break down.

Most of us do heuristic work.  Most of our managers use algorithmic management techniques.  This is incongruous.

The manager’s role in a complex, creative, heuristic environment is to foster self-organization.  One way to jump-start this is through serious empowerment.  From the start the word “empowerment” is bothersome, implying that by default we aren’t empowered.  I think the key to empowering your people is to realize that you have to do almost nothing.  They are empowered.  More than you know.  All you really have to do is get out of their way.  Let them make 98% of the decisions.*

*A well researched statistic I made up for the purposes of this blog post.

By letting go and getting out of their way, the heuristic work being done will flourish.  More ideas will be generated, more creative solutions will be sought after, more results will flow in.  Your bottom line will improve.  As a manager all you need to do is present the vision for your team.  What problem are you trying to solve, and how do you see it affecting your customers?  Let everyone around you take care of the rest.

Isn’t it funny that we had this figured out in 600BC?  Becoming agile is as much about unlearning the ways of the industrial revolution as it is about learning the ways of agile management.

The quote above and most of the ideas in this post can be credited to Chapter 6 of Management 3.0, by Jurgen Appelo.  http://www.management30.com/

Verbiage

Agile is a mindset, a state of being.

Scrum is a framework.

Neither are methodologies.

Methodology.  [meth-uh-dol-uh-jee]. noun.  A set or system of methods, principles, and rules for regulating a given discipline.

Product Owner: Beyond the Scrum Guide

The Scrum Guide is like the google map to Scrum, but it’s not a detailed roles and responsibilities document.  If we want to “zoom in” on “What specifically does the Product Owner  do?”, we aren’t going to get many results.  There is purposefully no prescription on “how”  a developer works, how a tester works, or how the Product Owner (PO) works, etc.; however, the PO is critical to the success of the product and the business.  As organizations adopt Scrum, the PO role is often overlooked and can cause frustrations unless the whole Scrum team (including the PO) and the organization have a more in-depth understanding of Product Ownership.

Here are my top three  activities that Product Owners commonly do, and how, that can either shape the success or failure of a product:

Top 3 PO Activities

1. Grow the Vision.  Self-organizing Scrum teams will build high quality, working products.  The vision laid out by the PO determines whether or not they are building anything of value.  This involves many different tasks and can be done in many different ways.  To be successful at these vision-related tasks, a PO has to both “grow” it and “show” it:

  • Grow it:  The PO has to be comfortable starting a project with only the big picture.  Then work to iteratively define and grow the vision by adding more and more concrete concepts, artifacts, and details.  All the while knowing that feedback from stakeholders and the market will shape their understanding of the product over time.  This takes an incredible amount of foresight and market understanding to get started in the right general direction, as well as the courage to simply start product development knowing parts of the vision may turn out to be incorrect.
  • Show it:  The PO has to over-communicate what the Product Vision is. When you think you’ve communicated the vision, communicate more: to your team, to the stakeholders. Don’t underestimate the power of using all available tools to do this, such as big visible walls with notes and graphics – this is showing.  A wall cannot replace a conversation – taking the time to make sure everyone involved in the product – and that means everyone – is included in the conversation and understands the vision is critical to your success.  Use hallway conversations, formal meetings and happy hours (most teams’ preferred method).  The more all stakeholders and the project team knows WHY  they are building what they are building, the better the results.  This has been proven over and over.  Simply stated: Vision + Self-Organization = Value.

2. Manage the Backlog.  Beyond the basics of creating a backlog full of product desirements and iteratively clarifying them during grooming sessions, a PO is responsible for the more nuanced activity of ordering.  The PO orders the backlog with many different criteria in mind: value, risk, priority, necessity, learning objectives, ROI,  dependency and many others. It’s the method by which the PO optimizes the value of the product for the stakeholders.  This is not a trivial task, nor is it completely objective.  Knowledge of the market, the vision of the product and short/long term opportunities all need to be taken into account.  Owning the backlog is the only activity of these three I’m discussing that is touched on in the Scrum Guide (sans specifics of course).  It’s also probably the most common PO dysfunction: POs are NOT simply backlog secretaries, or backlog item creator/maintainers.  A PO can rely on their team to do much of this work.  An efficient, functional PO spends less than 25% of his time dealing with tactical things like managing the backlog and the majority of his or her time on strategic activities like #1 and #3.

3. Steer the Product.  I struggle on what to call this part of the job.  “Plan Releases” is what I started with, and an important part of Product Ownership is creating MVP’s and selecting the right content for each release, but this is only the first step.  The real job here is learning from each release, testing the hypothesis you’ve delivered to the market and validating your vision of the product in its natural habitat (the market).  If it turns out many of your assumptions and hypothesis are wrong, you have to Steer the Product.  Depending on the magnitude of steering needed, the PO makes big changes to the Product Vision (pivot), or just small changes to the Product Backlog (persevere).  A PO is responsible for the current state of the product and the direction it is headed – and they accomplish this by Steering the Product.

Can one person do this role?  Yes, absolutely.  Does this mean that the Product Owner role replaces all manner of  marketing, strategic sales, and business analysis roles in an organization?  Absolutely not.  If the product is big enough, there may be a need for a PO to work along side all types of professionals providing things like: market analysis, sizing, trends,  strategy, competitive analysis, business process analysis, relationship building, user personas, business cases, pricing strategies, legal work, vendor sourcing, contracts, etc.  The PO can have people on the team or outside the team that understand (and even do the work for) these other items.  The PO remains responsible for the overall state of the product and its future.

Active Management vs. Self-Organization

I often have arguments in my head about where to draw the line between taking action and allowing self-organization.  As a manager, when is it OK to intervene or over-rule or otherwise take an active role in the team?

I think there are some no brainers we can get out of the way quickly such as situations involving obvious legal or ethical issues.  Yes, you should intervene.  Period.

For day-to-day issues, I tend to philosophically tend toward self organization.  Let the team figure it out themselves.  This helps everything from learning to morale to competency.

In practice however, my first instinct is to act.  Yup, I admit it.  It’s actually very, very difficult to take a hands-off approach.  I’m sure it has something to do with our culture, the big companies I worked for in the past, and just my type A personality.  There has been so many years of people working in environments where pit bull performance is praised, the loudest voice is singularly heard, and promotions are given on the basis of being the perceived as the smartest person with the best ideas.  So many managers of this old regime have this system built up around them and have perpetuated its construction that many companies now exist with the expectation the manager is the smartest person in the room and responsible for making most decisions.  To make matters worse, we’ve come to call much of this behavior “leadership.”  There are not enough quotations around that word to show my sense of disdain…

OK, so how did I snap out of that mindset?  And how do you get other managers to do the same?

For me, it clicked while reading about the Conant-Ashby Theorem.  Read more here: http://www.management30.com/ashby/

The basic idea is that if you accept that you are doing complex creative work within a complex system, then the best way to actually control that system is to distribute decision making to the lowest responsible/competent level possible.  Hear that?  Self-Organization and delegation of decision making authority is about control.  It isn’t about just letting people be or giving up power or becoming a laissez-faire manager.  As a manager, fostering self organization and leaving most decisions to the team is your only hope of controlling the complex system in which you exist.  This, my manager friends, is what switched the lightbulb on.

Constantly remind yourself each time you prepare to snap into action that usurping that decision, taking control in the moment, telling the team what to do, etc, is actually stripping the control of the system away from you – the exact consequence you thought you were avoiding.  You are limiting the health of the entire system to only your train of thought and decision.  Delegating decision making authority to a self-organizing team allows you to expand and grow the health of the system.

Don’t believe or don’t think this works in the real world?  Fine.  Try an experiment.  Take a common situation that presents itself often and has typically required your intervention or your decision as a manager.  Tell the team that from now on, they are solely responsible for these decisions.  Tell them they have all the skills and knowledge needed to make these decisions, and although you’d like to be informed on an ex-post-facto basis, you will not be involved in the decision making process in any way.  Try this for a while.  I’ll bet you won’t even miss that responsibility.  And I’ll bet you’re teams will surprise you with the outcome.

Take No Dependencies!

As a product owner and coach, one common question I often get is “how do you deal with cross team dependencies, like when Team A has to complete some work before Team B can begin theirs?”

If the room is silent after that question is asked, before too long somebody will likely suggest a “dependency matrix” or “tracker” or “gantt chart in MS Project” or the like.  Do not let the room be silent for too long.

There are many possible solutions to this problem, all of them more effective that inserting an antiquated project management tool like any of the above.

1) Team A and Team B work together to complete the work starting with the prerequisite work (originally ‘assigned’ to Team A) and then moving on the post-requisite work (originally ‘assigned’ to team B)

2) Team B goes and works on something else, and Team A communicates to Team B when the dependency has been met.  No need to “track” anything – Team A is full of smart people who will communicate their status to Team B.

3) Team B waits patiently  for Team A to finish.   They paint the office.   Stock the beer fridge.  Help on sales calls, research a new technology, put together a presentation, read a book, go to a conference, etc.   And all the managers GASP at the underutilized capacity, but you as a smart agile manager know that you may indeed be optimizing the system by not trying to optimize individual teams.