Agile Management | NOOP.NL

Let's Measure Something Meaningless

Imagine that the government decided an intake of 2.500 calories per day should be the maximum for each person, regardless of age, gender, health, metabolism, dietary habits, etc. And imagine that the government also measured and enforced this every day, claiming it is “for your own health”, and handing out daily fines for each person who went over target. How would you feel about this practice?

Now imagine that the government decided that a speed of 130 km/hours should be the maximum for each driver, regardless of age, health, mental condition, road condition, traffic condition, weather condition, or the condition of their cars. And imagine that the government measured and enforced this, claiming it is “for your own safety”, and handing out fines to anyone who went over this “target”. How would you feel about that? Oh, wait… this is an actual practice in many countries!

I drove 14 hours from Bologna to Brussels yesterday, with a proper break every 2 hours, good nutrition, a healthy mind, a well-serviced car, and an excellent track record as a driver. During that trip I saw people not using their indicator lights when switching lanes, people overtaking others on the emergency lane, people using their mobile phones, and people driving vehicles that barely deserved the name “car”. And among those many thousands of drivers, I’m sure there were also some with mental problems, physical problems, mechanical problems, etc. However, the one who got picked out by the government was me. I got flashed twice because I drove “too fast”.

For every complex goal, there is a metric that is clear simple and wrong.

In organizations we see this all the time. Managers have a goal, such as faster time-to-market or higher productivity. But productivity is a very complex thing. It depends on motivation, creativity, innovation, collaboration, etc. And managers can’t measure all that stuff easily. So they reduce the metric to the simplest possible thing that can be measured with a computer: the number of hours people are physically at the office. And then they turn it into a target: the computer requires at least 8! Or else…

Measuring something meaningful is hard, so let’s measure something that is meaningless but easy.

Measuring real safety on the streets for everyone is next to impossible, so the government reduces it to the simplest possible metric that can be delegated to computers: speed.

I fear the day when governments find a way to have computers measure our daily intake of calories.

Management Dysfunction: Measuring Happiness

I recently had a group of employees from one company who said their management was trying to measure and improve people’s happiness. Management did that by sending feedback forms to everyone, once every three months, which people had to fill out and send back.

So I asked them, “How do you feel about that?”

Then somebody answered, “I hate those forms!”

Several people in the room nodded their heads in agreement.

I said, “OK, so the practice which is supposed to measure happiness is actually destroying happiness?”

Again, several people nodded their heads eagerly.

Measurement Dysfunction

It is a common dysfunction of management. The metrics that managers put in place have the opposite effect of what the managers are trying to achieve. There is a severe lack of complexity thinking.

Managers, and their practices, are not objective observers of the system. They are part of the system, and influencing it with everything they do.

Therefore, if your goal is to understand and improve happiness, you should introduce observation practices that have a built-in tendency to improve happiness. Such as the Happiness Door. Granted, the happiness door is far from perfect. But I'd rather have a flawed metric suggesting improved happiness, than a perfect measurement proving destroyed happiness.

If I was an employee confronted with annoying three-monthly feedback forms about happiness, I would collect all those forms and walk out of the building. I would then set those forms on fire, make a video of it, upload the video to YouTube, and then tweet about it. Then I would send a message to management saying, “You should introduce a happiness door right now, because I just made myself very happy.”

     

Eating Elephants

How do you eat an elephant?

One bite at a time.

My Big Projects

I started working on my third book. It requires a significant amount of research (and some writing). Every week I read, and every week I write. Sometimes a little, sometimes a lot. But no week goes by without at least some progress. I could even measure it, if I wanted. (But I know I’m moving forward, so I don’t bother.)

I am also cleaning up my contact lists on Gmail, Twitter, Facebook, and other websites. It’s a huge task. I have 4,000 “contacts” in Gmail alone. But every week I set aside 30 minutes, and I clean up a small portion. (You might have noticed, when you received a Twitter or LinkedIn notification from me. Count yourself lucky. It means you’re still in.)

I am also browsing for music by my favorite artists on Spotify. And I’m browsing for unknown artists within the same genres. I’m slowly but steadily turning my findings into big playlists. I do this while working, and every week I waste at least one hour of my precious time on it. But I like doing it. And it’s nice to delete Gmail contacts to the rhythm of a beat.

There’s also my giant project of finding (and owning, and reading) copies of the best fantasy and science fiction books on the planet. I enjoy browsing for books as much as reading them. And I’ve made significant progress there. This project costs me about an hour per week. I think. I hope it never ends.

And I haven’t told you about the huge to-do list for my house. And the refactoring of my profile on dozens of social networks. And my secret plan to rule the world.

Needless to say, these are all Big Projects.

I do them all one small step at a time.

Your Big Projects

Sometimes people ask me, “How do I start test-driven development on a big legacy framework?” or “How do I convince our big management layer to become agile?” or “How do I finish this big nightmare of a project?”

Well, that’s easy.

You eat an elephant one bite at a time.

I’m busy eating a herd!

(photo by Matt MacGillivray)

     

8 Tips for Performance Metrics

Performance metrics are important. At school, in sports, and in the arts, people want to know how well they are doing. They get grades for their knowledge of math, languages, and geography, rankings for their performances in football, basketball, and tennis, and ratings for their books, plays, or TV shows. If you don’t know how you’re doing, you cannot verify if you’re doing better next time. That’s why people want to know their score on a Microsoft certification exam. It’s why they hook up their Nike shoes to their iPods, tracking their running achievements. And it’s why I’m looking forward to your Amazon ratings for my book. :-)

One responsibility of a manager is to make sure that employees get to know and understand how well they are doing their jobs. And whether you are producing metrics for individuals or groups, there are a number of tips you may want to keep in mind when measuring their performance:

1) Distinguish skill from discipline
In a previous blog post I discussed two rankings for maturity: skill and discipline. You may wish to evaluate people and teams separately for both. This helps skilled people (who may think that they’re too good to fail) not to forget about discipline. It also helps to avoid overconfidence in disciplined people (who may think they’re good just because they follow procedures). Some examples of measuring discipline: task board is up-to-date, meetings start on time, code coverage always > 95%. Some examples of measuring skill: no build failures, few bugs reported, and customer demos always accepted.

2) Do not rate knowledge or experience
I see knowledge and experience as prerequisites for skill and discipline, but I believe measuring people’s knowledge and experience doesn’t make much sense. Knowledge and experience are about being. Skill and discipline are about delivering. As a writer I don’t get ratings for being a writer. I get ratings for delivering a book. Nobody in your organization should be earning ratings for knowledge and experience, while wasting their time playing Tetris.

3) Rate multiple activities
Each of us has some things he is good at, and some things he is not. You can accept the humiliation of a bad rating for one activity when there is another one on which you’ve scored well. Similarly, employees can accept criticism more easily when it is compensated with compliments in other areas. Having multiple ratings also makes it easier to be honest and fair to a person. Rate people and teams for the quality of a software release and its timeliness, for customer satisfaction and cost effectiveness, for official standards adhered to and team flexibility.

4) Rate multiple performances
One of my high school teachers had a system where he organized at least ten test scores a year per person, and he promised not to count the lowest one, because “we all have a bad day sometimes.” People in general prefer to be rated multiple times for similar activities. They want a chance to do better next time. Rate them for each project that they do, and each new release that goes into production.

5) Use relative ratings where possible
Compare the performance of a team against their previous performances over time (“you’re now doing 15% better than last time”); against other teams in the organization (“you’re doing 20% worse than the guys in project X”); or against external businesses (“we’re doing 32% better than company B”). With relative metrics teams can strive to do better every time, instead of trying to meet one target and then staying there.

6) Keep the feedback loop as short as possible
There should be as little delay as possible between the time of an activity and feedback from the metrics. It is one of the reasons I started writing a blog before writing a book. I needed the immediate feedback from readers on my blog to know how to write better. Only one and a half year later I felt confident enough to start writing a book, which has a much longer feedback cycle.

7) Use both leading and lagging indicators
Leading indicators are metrics that, when they change, will indicate that you might be on the right track in achieving your goal. (Example: increased code coverage of unit tests might indicate higher quality in a product.) Lagging indicators are metrics that verify whether or not you have achieved a goal, after completing the work. (Example: reduced defects reported by customers verifies quality after the product’s release.) In general it is advised to use both leading and lagging indicators.

8) Never create the ratings yourself
The value of your opinion as a manager about the performance of a person or team is very, very, very small. Make sure that all ratings, whether qualitative or quantitative, are produced by the environment. Not by you. You may be the messenger sometimes, but not the assessor. Be the judge, not the prosecutor.

Talking about judges… Yes, I plead guilty (again). Like many other naïve managers in the world I have personally ranked and rated employees, once per year, using one single value on a 5-level scale. But I regret that now. I believe that people should be rated with multiple ratings, multiple times, as soon as possible. And not by me. Let the world know I’m sorry. It won’t happen again.

(Image by Bludgeoner86)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: No Maturity Models, But Individual Competence Discipline * Skill = Craftsmanship Managing Leaky Organizations

One At a Time (guest post)

This is a guest post by Stephen Bailey. Stephen lives in South Africa, and he has been a C++ Developer for 10 years, and a team leader of 25 people for a year. His main interests are with function programming and Erlang, and he has his own blog at www.blog.stackingit.com.

I have had the opportunity to do some Team Lead mentoring and this has pushed me to reflect back on my time as a Team Lead, and try to extract some lessons that I learned, and some of the things that I just plainly got wrong (isn’t hindsight a beautiful thing?).

One of the things I have reflected on is the concept of concentrating on only a small number of goals, where small should be as close to 1 as humanly possible, and dedicating all your non day-to-day time to this.

Reality Check

Okay before you panic and tell me that that is insanity, the very nature of Team Leading is that you are pulled in many directions because there are multiple different activities your team is working on – so by definition you are already working on N things concurrently.

That is not what I am talking about... I am talking about the work that you do that is not part of the production line work.

Let’s face it, you do not do the work, your job is to facilitate the people who are actually doing the work.

Now, if all you are doing is steeping yourself in the work that they are doing, you are missing a huge opportunity to add value outside of the production line. As a team lead you are one of these people who have been placed in the unique position to be able to operate in the white space on the organogram  - but that is a whole blog article of its own – I digress.

What I am talking about, is looking at your team, and choosing only 1 thing you want to improve. There is always a host of them (tools, salaries, processes, people, feedback, free time, mentoring, knowledge sharing, skills matrix, training... etc. etc., the list is endless, and for each of these items there a host of things that you can do about them.) And my point is this: typically you try to do a small bit of each of these each day - if you get the chance. Well stop it - pick just one and then do that until it is done, and adds value.

But what about all the other things I could be doing ?

Let’s pretend for a second that you never did anything except watch the production line... Would the work really stop ? So don’t get so stressed. If you don’t start X, Y and Z people will still keep working. Instead of giving people bits and promises of X, Y and Z rather give them, a single complete A, which is ready to add value - now. Otherwise, really all you are doing is just distracting them with promises of things that might help someday.. if you ever get the time to complete them that is.

The benefits

Those who are not team leads will not understand this, and those who are new to it are shocked by the reality of this, but typically when you get home from a very hard and busy day at work, you sit back and panic a bit because you are not sure if you really did anything that day.

So apart of the warm fuzzy feeling you will get when you get home, having actually made some progress on an actual task, you get the more important benefit that your team is seeing that you are doing something to make things better for them... And that is the goal. Remember: They do the work, not you.

Beyond that, they also have an idea of where you would like to see improvements. So when they get some free time, they will likely push in the same direction. It almost sounds like organically growing vision to me... nice!

This was nicely expressed in a blog post by Jason Cohen.

There's always an infinite amount of work. Remind yourself that no matter how hard you work, there's way too much to do. Take a break and take care of yourself. Do a few concrete things every day. Realize that procrastination is healthy and useful. Success doesn't come because you did everything, it's because you did the important things.

Enjoy. You have a great job – go make people’s lives better !

(images by mshades and Ben Sutherland and Peter Kaminski)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Leader vs. Ruler: Which One Are You?
Managing != Coaching
You Weren't Meant to Have a Boss, But It Helps...

About Project Success and Failure

Last week I got a number of interesting questions from Vassili Kurman, who is researching project success and failure. Vassili agreed that I would try and answer his questions in a blog post, so that it might also be of some value to me and the readers of this blog.

Here we go...

What does project success and failure mean for a development team?
In Scrum (the process I'm most familiar with) success is a happy Product Owner at the end of a sprint. Failure is an unhappy Product Owner. Note that this may not be the same as delivering what has been agreed upon at the start of the sprint. Team members may be unable to deliver what they had committed to, but with good communication the Product Owner might still be happy. And vice versa, despite delivering what was initially agreed upon, bad communication during a sprint may still lead to an unhappy Product Owner. Whatever the original plans were, the ultimate goal for the team should be to please the Product Owner at demo time. And when some sprint items aren't complete, a nice cup of coffee, a slice of cake, and a little dance might help.

What does project success and failure mean for management?
From a management perspective I see software projects as complex systems. For a complex system "success" could simply be defined as "continued existence". An organism is successful as long as it lives. A brain is successful when it is thinking. An economy is successful as long as there are people in it making a living. For software development this viewpoint means that projects are successful as long as they exist. They are successful from the day they are initiated (and financed) until the day the customer pulls the plug (and financing stops). The longer this inevitable death can be postponed, the more successful the project is.

What does project success and failure mean for other stakeholders, like the customer?
For a customer a project is a success from the moment the return on investment is positive, by which I mean that the project has paid back for its own costs. The higher the return on investment of a project, the bigger its success. This means that a project can be successful for management (it has been financed for a while), but not for the customer (when a return on investment was not achieved). But it can also be the other way around, with unhappy management and happy customers, for several reasons. But if you want to hear some examples of that, you'd have to buy me a drink first. :)

How is project progress monitored and who does it?
In Scrum the Scrum Master (together with the team) should be monitoring progress. It could be done in the form of burn charts, which plot the amount of work done against the number of sprints finished and the number of sprints still to go. But it depends on the situation. Some projects have no clear backlog to start with, and user stories simply materialize while the project is running. This makes it hard to draw burn-down charts (though burn-up charts would still be possible). It doesn't really matter, as long as the Product Owner is happy after each sprint, and management is happy that the project is financed, and the customer is happy and expecting a return on investment.

What metrics are kept to monitor the software development process?
The simplest useful metric is the number of user stories completed, and number of stories still to do. There are plenty of refinements (like using story points), and plenty of other metrics (like code analysis), but it depends on the project how useful it is to spend time collecting them. Metrics also need a return on investment.

What data is collected and how it is collected?
See the previous answer. I'm not an expert on metrics, so I have no preferences myself. I think it is up to the teams to decide. The costs of some metrics will be low, so return on investment can be achieved quickly.

What factors are monitored to identify project failure or success?
Happy product owners, happy managers, and happy customers. Happy team members would be nice too, but I've noticed that the correlation between project success and team happiness is quite blurry. Developers can be very happy making things that nobody in the world with a healthy mind would want or need. And vice versa, the things that are most valuable to a customer are often not the things that developers find most challenging. Finding the right balance between project success and team motivation is something that managers and Scrum Masters should concern themselves with. They are definitely not the same.

A lot (or a majority) of projects fail due to poor communication between stakeholders. How is this monitored, and are there any factors that can say that a project is slipping out of its track?
I'm not in favor of monitoring communication between stakeholders. They should learn to monitor that themselves. Experience tells me that (in our organization) team members, Scrum Masters and Product Owners are not afraid to warn management when a project is deviating from planning. It might be the first requirement for any agile organization: nobody should be afraid to tell management and colleagues when things are running out of control. When this is part of the organization's culture, you don't need to monitor projects as a manager.

Every team member is a project monitor.

(images: mpov and ogimogi)

 Twitter -  Subscribe - Newsletter - Bookmarks

Latest, greatest and favoritest posts:
Your Project Will Suffer from Power Laws
You Are a Gardener (Oh, and Me Too)
Great Managers Have No Secrets

Burn Your Burn-down Charts

In many articles on Scrum, the traditional burn-down chart is still depicted as the preferred method for displaying progress in a sprint or project. However, since the introduction of burn-down charts, several improvements have been suggested by leading authors and experts. I agree with each one of them, and my suggestion to you is to try these ideas, and turn your charting practices completely upside-down!

Scope Change
In "Earned-value and Burn Charts" Alistair Cockburn has described that burn-down charts can be inconvenient when trying to depict a change in scope. This may not be a problem for burn charts in sprints (as the scope is not allowed to change during a sprint) but it is quite relevant for charts depicting the total project. Burn-up charts (the mirror image of burn-down charts) are better suited for charting progress for an entire project, because any changes in the top line clearly indicate changes to the total scope.

Bottlenecks
In "Managing with Cumulative Flow Diagrams" David J. Anderson described how these burn-up charts can be further improved by depicting different stages in development. For example: by drawing different lines for work items that have passed the stages of In Progress, Reviewed, Tested and Deployed it is much easier to identify any bottlenecks in your development pipeline. (Bottlenecks manifest themselves as diverging lines in the burn-up chart.)

 

In this chart, taken from a real project, you can see that our Beta OK and Live OK statuses were falling behind, as compared to the In Progress and Team Review/OK statuses. In this project this meant that, for a short while, work was being reviewed but not being deployed to the beta test environment, possibly for technical reasons. Apparently, this was suddenly corrected around the 10th of June.

Budgets
In "Agile Charts" John Rusk has shown us that burn charts are missing another key ingredient for many project managers. Burn charts tell you whether the project is on schedule, but not whether it is on budget. This is particularly relevant for development shops (including ours) where teams are doing fixed-price projects. John proposed another enhancement, by adding a burned budget line to the charts.

 

In this chart, taken from the same real project, you can see that spending of the budget followed a traditional S-Curve. The project actually finished just below the original estimate (the red line). (Smart people would be able to merge this chart with the burn-up chart. I'm not that smart, so I keep them separate.)

These ideas, and many more, are also described at length in my own paper called "Progress in Three Dimensions" (PDF, 280KB). And if you are convinced that the improved versions are better than the original burn-down charts, then I suggest that you burn your burn-down charts and chart some new territories for measuring progress in your projects!

Subscribe to this blog with a reader or by email!

Latest, greatest and favoritest posts:
10 Principles of Agile Project Time Management
The Single Best Source Control Model
MoSCoW Priorities

Getting Square with the Iron Triangle

Here's a little quiz for those who aspire to be a project manager. (Probably 95% of my readers will stop reading here right now. But no matter, I will finish this post for the other 5% of you...)

Question 1: Which constraints do customers impose on projects?

Of course, almost everyone knows this. The three constraints are Scope, Time and Cost. The customer wants to know what he's going to get, when he's going to get it, and how much he's going to pay for it.

This is called the Project Management Triangle, or the Iron Triangle. So far so good. You get 1 point if you knew this. Here's the next question...

Question 2: Why is this triangle useless for project managers?

Well, let's see. What if new features are added to the scope? In that case, as a project manager, you must decide whether to add more time or more resources (or both). But the triangle doesn't show that! It only shows cost. But cost = time * resources. For you, as a project manager, the triangle is defective because it shows the constraints from the customer's viewpoint. The customer doesn't care about your resources, he just cares about the cost! Project managers have another viewpoint on the project, and therefore another triangle:

This version (copied from Scott Ambler) is slightly better for us project managers. It properly reflects that when scope is increased, we need either more time or more resources. This version may not work for your customer, but it does for you! You never realized that, did you? If you did, good for you! You get 3 points! Next question...

Question 3: Why is this triangle useless for quality managers?

OK, let's see. What happens when we add new features without changing any of the two other sides? In that case the quality of the product will inevitably be the victim. But why is quality printed in the middle? That's silly. Quality is a constraint, just like the others. In fact, scope is often defined as scope = functionality + quality. So, it seems we can simply split scope into two different contraints, and it turns out that we are changing the triangle into a square.

The Iron Square is a much better representation of the constraints in your project! When functionality is added, either resources or time must increase, or else quality goes down. When time is decreased, then either functionality must go down too, or the resources must go up. If neither is done, then quality goes down again. And similarly, when resources are taken away from you, then either the functionality must go down as well, or the time must go up. Or else quality goes down again.

The Iron Square is like a real sturdy piece of metal. You cannot bend or break it. If you tip one corner of the square, then either one or both of the adjacent corners have to tilt in the same direction, or else the constraint that is placed diagonally across goes the other way, whichever way you look at it. Did you already know that? 5 points if you did!

I must admit that there are other variants of the four contraints, like the star and the tetrahedron versions. (2 bonus points if you knew that.) But personally, I don't think they are as powerful as the simple square.

Question 4: Why is this triangle useless for process managers?

It's because, even with all four contraints fixed, it is still possible to optimize a project by improving the process. Process is an extra dimension on the project, but it's not a constraint. You get 1 point if you knew this.

So, how many points did you score?