The Complex Velocity of True Teams

Using velocity for long term planning of a project is a wonderful idea. With minimal effort we get fairly good estimates. At least this would be the case in ideal situations, meaning new team without maintenance or obsolete component replacement obligations etc. If you are a believer in true teams as I am, you do realize that all the urgent work and even absence due personal issues affect team dynamics. Just calculating velocity in terms of team member availability isn't realistic with true teams. The velocity, or team achievement, is not linear function of sum of available team member hours. If one person is for example pulled away from team activities for taking care of urgent manufacturing issue, this will affect the team dynamics. This has deeper impact than just missing those hours. To be honest, in some teams the impact can be positive as well. In that case I suppose they were non functioning work group, which now due the changed dynamics has a chance to become a team.

This said, no, we have not solved the issue of maintenance and other urgent work disrupting normal work. We are struggling with bouncing velocity. This is for several reasons, but it also woke me to think about true teams again. Anyway, I'd like to pay more attention to this and give true teams a chance to grow.

Islands of Expertise Can Get You Lost

You may be familiar with the following scenario. The embedded software development department has finally launched a large new system. The system obviously immediately gets new feature requests and other modification needs. During the initial development each developer has found a pet part in the overall system. When the improvements/modifications start it is intuitive to assign these smaller projects to a person whose area the change mostly concerns. In this approach we launch several, as many as there are developers, projects to run in parallel. This seems like a natural way to go.

While tempting at the first look, there are several problems in the above scenario. First is the customer’s role. It is difficult enough to get a functioning product owner for one project. Running multiple projects at the same time is ridiculously challenging. If we get one person to act as a customer proxy for all these small projects, this person soon becomes a bottleneck for all these projects. A project needs collaboration with the customer representative, and the sooner we get the feedback the better. The customer needs to be available at all times, and this is easier to achieve for one project at the time.

Second problem follows from the fact that it is rare that all these projects are completely independent. While we think that no one works on more than one project at the time, we actually have created a highly complex hidden multi-project environment. Typically one, or few, developers know something about everything. This means that people that are supposed to be working for their own project need to consult other projects continuously. These people become the bottlenecks for other projects, and their own project is impossible to estimate. As a net result we push all our projects to be more, and more, late without any control to what is going on.

Thirdly, assigning a developer to her previous pet part of the system further develops the specialization in a narrow part of the overall system, creating small islands of expertice. More and more closed silos of expertice emerge in the department. This is a high risk path as in an unfortunate case of loosing that person for one reason, or another we halt the development of that part for unpredictable period of time. Yes, I have heard that documentation should be there for allowing anyone to work on new part. Well, having been in the development game for nearly 15 years I kind of have lost faith to that approach. Maybe if the previous developers have focused their energy mainly on enabling future work –type of documentation. Never the less, safer path is to several developers to know the work.

The fourth problem is the lack of possibility to gain from the superior performance of true teams. Assigning each person to a single small project will at its best only accomplish the sum of each developer in development department. If we are successful in getting a true team to jell we can accomplish a lot higher performance that the sum of team members. This is important especially when the work we are engaged with gets more complex, and needs higher problem solving capability.

Changing to work in teams and in the same part of the system may feel difficult and weird at the beginning. Progress may also appear slow as most of the team members are unfamiliar with the parts of the system they need to work with. It may also take old school engineers by the surprise that they also need the softer skills, interaction and communication. It is crucial that collective ownership is still enforced. Teams have a remarkable capability in finding the ways to work. The practices supporting the work of team will merge rapidly. You don’t have to know everything to start working this way. Just follow the basics;

1. do fast paced iterative development,
2. have reflective retrospectives, and
3. create open, learning-driven culture.
   

Is There Any Value in Values?

Recently I was blessed with an opportunity to facilitate a project retrospective for globally distributed project at the end of their 9th Sprint. Project has development in Europe, China, and Mexico. It is an embedded system development project involving electronics, plastics, mechanics, and firmware development. For all the participants this is the first contact with Agile project management. As a starting exercise we had each participant try to describe the project so far with a single word. The words we got:

• "Chido" (This is something like "cool")


• "Good"


• "Good"


• "Skilled"


• "Challenging"


• "Spectacular"


• "Fun"


• "Speed"


• "Improvement"


• "Interesting"


• "To Be Finished..."

This was interesting in itself.

An article "Manage Your Embedded Projects" in Embedded Systems Design described developer motivators:

• "Achievement"


• "Growth"


• "Work itself"


• "Personal Life"


• "Technical supervision"


• "Advancement"


• "Relationship with peers"


• "Recognition"


• "Salary"


• "Responsibility"

This data is adapted from Boehm, Software Engineering Economics (1981) and Herzberg, "One more time: how do you motivate employees?" Harvard Business Review (1987). So it is a bit outdated. The data in the article is used to demonstrate the difference in motivators between developers and managers. Similar findings are presented in Motivators of Software Process Improvement: an analysis of practitioners' views (2002) and De-motivators for software process improvement: an analysis of practitioners' views (2003), both by Nathan Baddoo and Tracy Hall.

We can go on to generalize this further, and think about differences of people and organizations. Value system of people has been recorded and studied for a long time. Von Rosenstiel and Koch (1) reported that the values have changed towards respecting the uniqueness of people, individualism, enjoyment and discipline,self-development and also material values. That is not enjoyment, it is enjoyment AND discipline among other things. To me the "just words" exercise showed that agile work actually builds on these values; the project was challenging and needed lot of skill, but that just made it interesting and fun - chido. In many cases this however is not following the values of the company, which often are still drawn from old school thinking, like punctuality, hard work, modesty and other values related to duty and acceptance. This discrepancy between values of employee and employer affects the commitment level. Lack of commitment, in turn, reduces employee motivation and effort.

Of course in large organizations values are mostly just lip service, but nevertheless above should lead organizations to rethink the value in their values.

(1) von Rosenstiel, Lutz and Koch, Stefan, Change in Socioeconomic Values as a Trigger of organizational Learning, Published in (Dierkes, Meinolf, Berthoin Antal, Ariane, Child, John, and Nonaka, Ikujiro, Handbook of Organizational Learning & Knowledge, Oxford University Press Inc., New York, 2001).

Edward Bear Does Not Have Time to Improve.

In many companies the software assets and practices are left to rot. This indifference to fundamental quality issues is justified with phrases like "we are in a hurry", "we need to create new stuff", and other nonsense. Software is going to require maintenance and further development for its whole life. If you neglect to keep it fit it is going to haunt you back for sure. And it gets worse. If you leave your code base and practices to rot, you will eventually paralyse your whole productiveness. See Ken Schwaber explain it in this InfoQ video.

I have used the story about timber jack being so late at his logging site, that he does not have time to sharpen his saw. Some time ago I bumped into another quote that makes the same point.

“HERE is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.”

It really gets painful sometimes.

Scrum Simulation Rocks

Last week I gave an introduction to agile development and Scrum for a global project organization in Shanghai, China. After the lunch on first day it was time for 59min Scrum simulation. I have written about bad experiences when trying to achieve too much, so it was back to the basics.

There were participants from Finland, China, and Mexico. We used the product backlog for Family Cookbook. Only addition to original Scrum simulation was the use of relative complexity estimations on product backlog items. This time it worked. Estimating the tasks in numbers gave birth to discussion on whether something is simple, or not, not just dividing an item into tasks. Some items were also soon identified to be too large to fit in one 14 minutes Sprint. Team was immediately forced to seek for collaboration with Product Owner.

On retrospective the main thing experienced was the time pressure. I do not see this as a bad thing, it is just the beginning of understanding the discipline needed for time-boxed development. Time pressure will decrease when the team builds trust and improves estimating.

Everyone valued the exercise and though that it was a good lesson. I might consider adding a separate exercise for planning and estimating before the final Scrum Simulation. With this early experience I do not think that I will ever try meaningful work inside the simulation again. The difference was so clear.

Book: The Tipping Point

I finally read The Tipping Point, by Malcolm Gladwell. The Tipping Point tells us how little things can make a huge difference whether an idea will success or not. Will it tip or not. Examples and cases presented by Mr. Gladwell range from young men's high suicide rate in Micronesia, via fashion trends, cigarettes, children's tv shows, all the way to warning mechanism in surroundings of Boston about the upcoming attack of Brittish in 1775.

Malcolm explains, in a very understandable way, the law of the few; Mavens, Connectors and Salesmen. These are the three different personalities needed for a new idea to become epidemical. He talks about social epidemics. He then further explains the concept of stickiness factor, and the power of context.

What has this to do with things we are interested in? Graig Larman calls introduction of agile development methods a paradigm shift. When you introduce an idea of this magnitude, what you are doing, is asking people to unlearn much of their current knowledge. We of course know that the old knowledge is by no means useless, we just need to update it with some new knowledge. Never the less, introduction of agile methods and lean thinking is a novel idea in most organizations. The theories and concepts presented in The Tipping Point help us to understand the process of making this change and getting it to last. I have learned a long time ago, that it is not enough that you understand, you need to get others to get it as well.

Let's see what these theories in my opinion tell about agile intervention. In many cases, especially early in the decade, agile methods were introduced to organizations by younger champion developer, usually from position of no power. They just happened to be interested in learning and continuous improvement. They read a lot, they go to conferences, and they talk to fellow craftsmen. Furthermore they like to analyse the new things, and then tell these ideas to others. They are the Mavens. If things go nicely they will meet a Connector at some point. Connector knows everyone inside the organization, and knows who to talk to in order to get the change started. After the initial start, to make the idea of agile development really tip, we need extra ordinary people called Salesmen. They are the ones that can translate the ideas and experience reports so that we can communicate with lots of different people in order to get real structural changes to happen in an organization. Agile coaches and consultants are a good bet at this if you can not find someone in your organization fast enough. On top of that agile is a nice sounding word, and it can help to increase the Stickiness Factor. The first agile pilot project should have importance and wide enough commitment, creating the right Context for the intervention to tip.

Other literature (for example Pinchot, Intrapreneuring: Why You Don't Have to Leave Corporation to Become an Entrapreneuer, 1985) documents the same kind of process. Terms used elsewhere include 'Brain workers' who have the intellectual ability to think in novel ways and are able to argue their decisions. 'Intrapreneuers' are daring in using their vision of innovation regardless of for example political resistance. 'Gate keepers' have strong contacts to the organization's environment and have communicational competencies for making initiatives 'digestible' for the organization. Further a top management mentors, godfathers, or corporate angles are terms used for expressing the need for management commitment in such a venture.

Look at the world around you. It may seem like an immovable, implacable place. It is not. With the slightest push - in just the right place - it can be tipped.

Skunk Work Is Not A Longterm Solution

In her "The Agile/Waterfall Cooperative (pdf)" presentation Michele Sliger summaries three modes in which agile team can work in a waterfall organization; SWAT team, Skunk Work, and stealth agile. I agree that applying just some agile practices can benefit your work. This is pretty much what we are doing at the moment, but I do not see this as sufficient long term solution - if it is only in team's sphere or just above. All three forms of team work can of course be used. SWAT teams can go parallel even in more wide spread agile organization. Skunk work probably, and hopefully, always exists in large organization - it's fun. If you are working as stealth agile, and avoiding radars by not communicating to the top management, you are not going to be able to fully harness the power. You need to inform top management that you are doing things differently and communicate your need for changes. They probably will not get it, but what they do get - is success. So it is fine and in most cases necessary to fly low at first, but after certain point it is not satisfying anymore to work as a shadow system, because you know you are constrained by the legitimacy structures, and these structures are holding back you and your learning.

The rest of the presentation has also good ideas, and based on my experience these ideas hold in reality as well.

SWAT team – outside the domain of the process police, brought in on projects that are in trouble. Agility is prized in this situation. They take over however – they don’t work in a cooperative mode.

Skunk Works - “a small group of experts who drop out of the mainstream company operations in order to develop some experimental technology or new application in secrecy or at speed, unhampered by bureaucracy or the strict application of regulations.” Sanctioned and protected by management, these teams are rare. This formation however, prevents the headaches involved in org structure, project approval hoops, portfolio metrics and management, budget calls, and other bureaucratic nightmares.

Stealth Agile – As Jim Highsmith once said in response to a question about how to sell agile to upper management – don’t. “They don’t know what you’re doing anyway.” Do as much agile as you can where you can. Some benefit is better than none at all.