Category: Management

Posted on

Coin Sorting with a Twist

pile_of_swedish_coins500x750I went to Budapest last week to do a workshop with the local management team of one of my customers. The goal was to talk to them about how they could move into the agile way of working. This was triggered by a move of some substantial product development from Sweden to Hungary. In Linköping, Sweden, I have been coaching a dozen teams in a transition to Agile, and I was asked to help the management to ensure that the transfer retain as much as possible of the Agile way of working that we have established.

I decided to select a few exercises, and add a set of scenarios that we could analyze together. I was hoping that the exercise would give them first hand expericene in the values of Agile and that this and the scenario analysis would spawn good discussions. And it did. Actually, I did only use one of the exercises I planned.

The exercise that I used was from Tasty Cupcakes and is about sorting coins. We use that exercise extensively in our Agile training, so I knew it would work, but I decided to add a few twists.

The exercise is to ask the group, preferably divided into teams, to estimate how long it would take them to sort a set of coins. The team with the lowest estimate actually get to do the sorting.  This raises the level of competitiveness in the group.

I decided to add a “Requirements Specification” to the game. Instead of telling the team what it was about I had prepared a document stating that they would get a number of coins of various value, how high piles could be, how far apart they where allowed or required to be placed and some other facts. (An unplanned complication was that I had stated distances in millimeters and a couple in the group where actually Irish…)

So after a “pre-study” period the bidding commenced. As often happens one group had a low bid and the others said “Let them do it!”

The team were actually done on time, which is kind of a bonus. Because the kicker is that almost always the coins are sorted according to value although that has never been specified.

I think adding the written “Requirements” shows how easy we are thrown of track by something written. It’s not just the fact that written communication is narrow-band, it is also very often misleading since if someone has spent so much time writing the document, specifically if it also has been reviewed and approved, the truth must actually be in there somewhere. And everything in it must be equally important, right?

Of course, the 10,000$ question that someone should ask is how you actually want them sorted. (Occasionally this question is actually put during the bidding and then you can either try to be undecisive, misleading, or you can just take it from there.)

But the billion dollar question that I really want to hear is “Why do you want them sorted?” I had prepared an answer: I want to be able to sell piles of coins as birthday presents so all the coins should be from their birthyear. I hope that I will someday do this exercise and have to use this answer.

By the way, at the end of the workshop one of the managers said “So I think we cannot wait for the transfer to be done and then start becoming Agile, we must do this now”.

Posted on

The Story on Velocity

Chances are that you are calculating your Velocity the wrong way! The Velocity is the speed with which a team can deliver new, valuable, finished and tested features to stakeholders. This blog is about why the common way to handle estimates and planning does not give you that. And how applying a Lean view on the matter can show your real Velocity.

Background

Agile Estimation and Planning relies heavily on Velocity and Relative Estimates. They are all based on the concept of Story Points, a relative estimate of the effort it takes to implement the functionality of Story.

The Velocity is the rate with which a development team delivers working, tested, finished functionality to stakeholders. In the best of worlds this is the customer or user directly, however, in many cases there are still some separate testing activities carried out before this actually happens.

To calculate Velocity we cannot estimate in hours or days, because that would make Velocity a unitless factor (hours divided by hours). It is common estimate in Story Points, where User Stories are compared to each other and some known story as the prototype story to compare to. The idea is to decouple effort from time and instead base future commitments on empirical measurements of past effort executed per time/iteration.

The Stories are found in the prioritized list of Stories to be implemented (what Scrum calls the Product Backlog). The Product Owner should prioritize in which order the wanted features should be implemented.

Signs of Debt

Technical Debt is a term, alluding to the financial world, describing a situation where shortcuts have previously been made in development. In some future situation this will cost more effort, like bug fixes, rewrites or implementation of automated test cases.  In situations where an existing organisation is transitioning to Agile there is usually a substantial Technical Debt that needs to be repaid. This is often signaled by

  • the team struggles to find ways to handle trouble reports
  • rewrites, often incorrectly labelled “refactorings”, are listed in the Product Backlog

The Trouble with Trouble Reports

Of course Trouble Reports need to be addressed as soon as possible. But in a legacy situation many Trouble Reports are found in the late stages of integration and verification, which can be months after that development was “finished”. The development team has moved on or even been replaced. So many of the Trouble Reports must first to be analysed before a correction can even be attempted. This makes them impossible to estimate. So putting them in the Product Backlog can only be done after the solution, and an estimate, is known.

A technique I recommend is to reserve a fixed amount of resources for this analysis. This limits the amount of work for Trouble Report analysis to a known amount. The method of reservation can vary from a number of named persons per week/day, a specific TR-day in the sprint or just the gut feeling of the team. The point is that the team now knows how much of their resources can go into working of the backlog. And adjustments can easily be made after a retrospective and based on empirical data.

 

This technique has a number of merits:

  • known and maximized decrease in resources
  • only estimatable items go in the backlog
  • all developers get to see where Troble Reports come from
  • team members are relieved from stress caused by split focus (“fix TR:s while really trying to get Stories done”)

 

Once a solution has been found the Trouble Report can be put in the backlog for estimation and sprint planning. (But the fix is often simple, once found, so a team might opt to not put the fix in the Product Backlog. Instead the fix itself can also be made as part of the reserved Trouble Report resource box. This avoids the extra administration and lead time.)

But, if the Trouble Reports are put on the Backlog and estimated as normal stories, we give Velocity points to non-value-adding work items!

Rewrites are Pointless

A system with high technical debt might need a rewrite of some parts. More often than not, these has been known for some time but always get low priority from project/product managers. And rightly so, they do not add any business value.

They still need to be done, though. The technical debt need to be repaid. So, what to do?

First I usually ask the developers if the suggested rewrite really is the smallest step to improving the situation? Often I find that if I push sufficiently hard, they can back down a bit and a smaller improvement presents themselves. This is good news since the smaller improvement is easier to get acceptance for. And once they are small enough, they can be kept below the radar of the PO.

If the rewrites are indeed put on the Backlog and estimated as normal stories, we give Velocity points to non-value-adding work items!

The Point of the Story

And this brings me to the core of this blog entry. Trouble reports and rewrites are things that need to be done, but a product owner should never need to see them. The team should be able to address these issues by themselves. They should be delivering working, tested, valuable software. The Product Owner should prioritize the new features.

This indicates that neither rewrites nor Trouble Reports should go into the Product Backlog.

How would a team know what to commit to then? Well, the (smaller) rewrites and the trouble reports (if put in the backlog) need to be estimated. We could do that the same way as previously. But there should be no points earned for these items.

What would this strategy mean then?

  • The Product Backlog should not contain Trouble Reports or rewrite “stories”
  • The Team should include a limited amount of necessary non-value-adding items in the iteration
  • The Team needs to estimate non-value-adding items
  • The Team commit to a number of points including non-value-adding items
  • The Team Speed is calculated from all Done Done items
  • The Velocity is calculated only from value-adding stories

With this technique you will probably see an increase in Velocity as your Technical Debt is repaid. Something which I find very Lean.

The Real Velocity

The only Velocity that is really worth measuring is the speed at which a team can add business value. Then we need to make a difference between value adding work and extra work disguised as such.

Posted on

Measuring Business Value

Measurements is a two edged sword. On one hand you cannot see and compare something that you have not measured. One the other hand there are evidence that it generates dysfunction. Conciuosly or unconciously we tweak our ways to get good numbers. We all know and love the story about the development organisation that was to be measured on the number of comment lines in production code. The tool to insert the correct number of comment lines was available just a few days later.

We need to measure, but most organizations seem to measure the wrong things. I think Systems Thinking and Lean can teach us a bit about how to measure in a meaningful manner. Systems Thinking (and Gödel for that matter) keep pointing “one level up”, i.e. don’t measure inside the system, instead measure the system.

Lean (and Scrum and XP) indicates in various ways that we should prioritize according to business value which seems like a good proposition. So I try to convince managers in my client organizations to measure flow of value through the development organization, and as Lean puts it, measure the whole. (Which in itself can be hard, but at least it is not only the development team!)

However, the notion of business value is a fluffy one. And it is usually very hard to get anyone to assign dollars and cents to a customer request in the general case. (Unless you’re a contract developer, when it’s kind of easy, but probably wrong!)

So what I am trying now is to use business value points. In the same way as Story Points work for effort estimation, Business Value Points can be used to let marketing people, business analysts etc. assign relative values to requirements or features.

One complexity still left to address is the fact that at early stages requirements etc. are fairly large and later broken down and re-prioritized. This means that a complete “requirement” is seldom delivered. So the Business Value Points needs somehow to be split when a requirement is split into Epics and Stories.

But if we could measure the flow of value we can also optimize the whole and avoid sub-optimization and measurement value tweaking.

Posted on

The Theory of X and Y (and Z)

I am sitting here at the Shiphol airport, Amsterdam, waiting for my flight to Toronto. (A 4,5 hour transit so I have not much else to do but to write a new blog post…) I had a quick look at the books in the bookstore and my eyes fell on a couple of small books with the titles 50 ideas you really need to know about. 50 concepts within a specific subject described in just a page or two. One of them was about management ideas, written by Edward Russell-Walling. I flipped through it, most of the concepts where of course know to me already, but there was one I hadn’t heard of before, or maybe forgotten, The Theory of X and Y. Douglas McGregor described these two theories in his 1960 book The Human Side of Enterprise, thinking that the management style of a leader reflects his/her view of human nature. The idea is that they are two contrasting ideas about how people act and should be treated.

Theory X says that people are lazy, self-centered and must be kept in control with hard rules and firm, and detailed management. These people can only be controlled and only work if their basic lower level needs (physiological and safety, according to Maslow) are at stake. And of course Theory Y then is the opposite, people take responsibility, are full of initiative and will find their own solutions to any problem if they are treated as mature adult persons. Of course drawing on the higher Maslow levels.

Theory Z is then a mix deviced by the Hawaiian-born William Ouchi aimed at mixing American and Japanese practices.

So is the management view of people, or at least developers in your organisation, shifting towards Theory Y? Maybe that is a trend in many areas, but it is interesting to see such an explicit correlation made between American (low level needs, threats, control) and Japanese (higher level needs, inspiration, self-direction) management styles.

Powered by Qumana

Posted on

Single-point, Multi-point

There are many things that are different in the “new world of development” as opposed to the way it was in “the old”. One of the more subtle, but perhaps fundamental is the way that decisions and communication has switched characteristics.

When a developer was developing code “in the old days” he or she had a task defined by some designer, project manager or architect. This was usually the only point of communication that was available to discuss the features. But frequently sales persons or other customer contacts would show up at the developers desk and ask about some features, estimates or changes that could be made “since doing them at the same time would not cost anything”. This single-point communication, multi-point control has been one of the primary sources for unpredictability in the “old” way. Although detailed plans was made and project managers tried everything possible to keep them, the urge from business to rush and push unplanned things into the workload of development ensured failure to meet the plans, no matter how strict control was applied.

In agile development one of the most important techniques is to enable developers to communicate with stakeholders of various kinds, users, customers, business people. This multi-point communication is essential to ensure that valuable features are developed. On the other hand decisions are focused around the product owner and his power of prioritization. This is exactly enough to work as a single point of decision. In conjuction with the multi-point communication it is “right-sized” decisions.

So removing the single-point communication, multi-point control and replacing it with single-point control, multi-point communication gives us controlled flow of tasks and predictability of development.

Posted on

Why can Agile only apply to Software Development?

Maybe it is just me, but it seems that it is difficult to get the notion across that Agile is not limited to development of software. In Agile communities people seem to be extremely focused on development of software, preferably a web application.

I have always worked in ways which are Agile in value, mechanisms and effect. But they are applicable to development of anything, from systems including hardware to businesses and enterprises as a whole.

When I met Ken Schwaber in September 2007 we talked about his new book, “Scrum and the Enterprise”. I immediately recognized some of the patterns he seemed to paint. Or maybe the patterns matched what I had been looking for.

However, Ken seems to have had the same problem that I seem to face, when I talk to agilists about a broader perspective of Agile. Or maybe that is “out of scope” of Agile…

Posted on

“I need a pen!”

“Do you have a pen?” … After a few minutes the answer is “Sorry, no.” What if the question would have been “Do you have something to draw with?”. Maybe a pencil, or chalk could have been found. And better yet, “I need to draw. Do you have a pen?” This signals not only the need, but also a prefered set of properties on the solution. These properties are not requirements, but can still be used as input.

Does your requirements process work like this? Or do you have “Must Have”, “Could Have” and “Nice to Have”? It is the need, and the implied and fuzzy priorities, that is the essential part of agile requirements management work. These are seldom articulated in standard requirements mangement processes.

Posted on

Project Models Overview

On the mailing list of Agile Sweden there was recently a long thread on models for life cycle approach to software development and the Agile community received some critique for maybe not having tackled this view, and of course the favourite topic of “project” was raised. The rest of this post is a translation, with some minor edits, of a post that I did to that mailing list, where I tried to summarize my views on “projects”. This was among other things inspired by a blog by James Shore where he described his way of managing the incorrect use of the term by the rest of the world.

I think the rigid command and control mentality evident in many of models and thinking of the last few decades stems from an increasing suspicion towards larger and larger projects with continuously increasing complexity. And rightly so. As we (the engineering and technology community) have become masters of the current technology, we have tackled even more complicated and challenging projects, and of course the amount of “failures” has grown, or at least the economic impact of the failures. The natural reaction is to try to control everything down to every little detail, thinking that detailed control leads to overall control. The problem is of course that this has been the wrong solution to the problem.
Continue reading “Project Models Overview”

Posted on

Hosting Open Space sessions at Scrum Gathering

All of us at Responsive attended the Scrum Gathering 2007 in London. As usual it is most interesting, pleaseant and informative to attend these international conferences. Although the organisers was very explicit in making the Gathering more of a social even, it was still very much of a conference, at least for the two first days (not counting the course days). They where so filled with tutorials and other interesting presentations that it was almost possible to choose, let alone make time to talk to people in the short breaks. I would really like the next conference I attend to actually force people to talk to each other during the conference.

Fortunately the third day (Friday) was totally devoted to Open Space, a form that I enjoy very much. This time I hosted two sessions, “How to find Product Owners” and “Enterprise Scrum and Large-Scale Systems Development”. The latter I co-hosted with Henrik Kniberg, who was confused about what Ken Schwaber actually ment in his new book (“Scrum and the Enterprise”).

My take was really not a response or defence to Ken’s Enterprise thoughts, but rather a presentation of some thoughts that I have carried for a long time on how to scale Agile, Iterative and Incremental development to the large scale systems of systems domain. It turned out that these two topics was not exactly compatible so a part of the session broke out to create a concrete example, while the other part continued with more theoretical discussions and comparisons.

My biggest insight from that session was, again, that there are more flavours to development than any single person can really have concrete experience with. Many agile people I meet at conferences seem to have extensive experience with lightweight web or application development, but those with the most questions are usually from the “harder” part of the spectrum, like military, safety, financial or security development. So, I will have to remember to present the concrete problem that “my model” is trying to solve, before engaging in a discussion.

Posted on

Software as a Corporate Asset

I just came across a video recording of “The Canary in the Coalmine” from Agile 2006 where Ken Schwaber discusses the factors involved in getting companies to realize that software is a Corporate Asset. My conclusion, having seen many of the same effects in a number of companies, is that most of the decisions about projects status, schedules, delivery dates, features suffer from the same problem; they are not based on facts, or at least not on all the facts. For example, which is one of the main points in Ken’s presentation, the future cost of not having software that is well-kept, which in turn is a direct effect of pushing deadlines and increasing feature sets.
As a case in point, Ken’s anecdote from the “$14M, but just some features more” situation, is an example of how easy it is to make enterprise level decisions without hard facts, and what it might lead to.