Let me tell you about the grand plan behind it all:

My mission for the last four years has been to try to be of assistance to organizations that are moving forward, applying Scrum/lean/agile, creating new great places to work and producing amazing products. As much as I enjoy being part of this, it has its downs for sure. Changing organizations is not for the weak of heart. On the less great days I do get frustrated by the painful slowness of adoption and by the inevitable setbacks of it all.

So, let me run this thought by you: It is a common belief that it takes 10 000 hours to be an expert in something. A lot of the people I meet have put in this time, and more, and are experts in traditional software development, project management and line management. How many hours does it take for experts like these to change old habits and acquire new ones?

Wouldn’t it just be easier to work this issue at the root, starting with newly trained students? So much easier than trying to assist experts in questioning old habits. At least I think it would. We’ll soon see

So, this is what will bring me to Chalmers University for two days of unpaid work tomorrow. We will be doing a “Pay it Forward” two day “Professional Scrum Foundations” course. The course is highly focused on getting participants to experience self-organization and the soul of well-functioning Scrum/agile. After the course the students will be able to assess and demonstrate their understanding by taking the “Professional Scrum Master I”, PSMI, assessment created by Ken Schwaber, creator of Scrum.

When these people will hit the workplace they will have a different view on things and they will be another force working from within. Joining us in our mission of improving the profession of software development!

In this quest I’m joining my Scrum.org colleague Ralph Jocham. Ralph has already gotten started and we have set as a first goal to train 1000 students in Scrum(!). Read more about the “pay it forward” scrum training and “1000 student challenge” at his website!

Btw, arrangements were made by student Viktor Nyblom, facilities for the course are provided by Chalmers University, courseware is provided by Scrum.org and training is provided by myself/Cedur AB. Nobody charges anything for this. The reason we charge students $100 fee is mainly to get people signed up that will actually show up. The fees will be used to cover materials used and the cost of the PSM I assessment included. (full price of course is about $2000/person)

If your university is interested in doing something like this, get in touch! We still have have 942 students to go…

- Henrik

Actually I asked him a few questions about their situation and their goals first, and then I told him no. Not that it would be a bad idea, but for a company like theirs, starting out exploring agile it would not be my first recommendation.

A two day scrum/agile class for one or two persons per team is a strategy a lot of companies have tried for many years now. Thus, we know a lot about the type of results that this strategy gets you. It usually results in some improvements, and people are generally happy, but most things in these companies are exactly like they were before scrum/agile. Thus, results are also pretty much the same. More troubling perhaps, initial improvements in these companies often fade away with time as people driving the initial change move on.

The last years, a few companies have noticed this and have moved on to get better results with other strategies. Here are some ideas on tactics that could be included in a second generation agile improvement strategy:

The third generation change strategies recognize that a broader effort is needed to avoid having changes fade away after a few years. We need to deal with the whole company to make sure all its pieces are aligned. I’ll get back to that later. If you can’t wait, pick up “Leading Change” by John Kotter and/or “The Enterprise and Scrum” by Ken Schwaber.

So, to summarize, Don’t let me scare you away;-) I actually really appreciate the opportunity to work with motivated professionals in my Professional Scrum classes. Individuals that I had the opportunity to watch have also been doing very well at work after passing through our latest training and assessments. My point is that I’m also happy to see that more and more organizations are realizing that individual training for a single role is just one piece of the big puzzle that needs to come together to enable sustainable improvements by applying the ideas from Scrum and agile.

What type of strategy is your organization using? What are the results?

- Henrik

It wasn’t. Really bad idea actually. Huge failure!

Until one of the vendors figured out what the problem was, took action accordingly and left their competition behind in the dust, wondering what happened.

So what happened, and why should you as a software development professional care about that?

What they figured out was that the original mixes made it too easy. Housewives of that time took great pride in their occupation. Clearly, just adding water would simply just not qualify as baking a homemade cake.

The solution was to have the housewives add a fresh egg to the mix. Fiddling around with an egg was messy enough that the housewives now felt like they contributed to the baking. Now this was something that they could serve as homemade!

And it works the same way with ideas! If you have some great improvement idea you would like to promote, you need to make sure that everyone affected by your idea will have the chance to contribute something to the mix! Then it will be their idea also, not only yours.

So, if you have worked out a brilliant solution to some problem, don’t tell your co-workers! Instead, ask everyone involved to join you, working on solving the problem. Carefully facilitate the meeting so that everyone gets to contribute their thoughts, and see what the group comes up with. (I’ll be writing more about how to do that in another blog shortly.)

But, what if the group discussion results in a solution that is not as good as one you have already worked out? Well, one advantage is that the group solution may actually get implemented. And that’s a start! In contrast, the chance that a prepackaged solution, offered by you, is sustainably implemented is very close to 0.

Also, often when I do this, I’m surprised to see that the solution crafted by the group is actually better than mine…but maybe that’s just me

Wait! Someone says, maybe it was that adding the egg to the mix actually did make the cake taste better? Well, I have further proof for you skeptics, and I might do another blog on that later. But the only way to truly learn something is to try it out yourself, so next time your about to sell some new solution to your team, just consider that this may be true:

People do not like other people’s ideas, they like their own ideas!

Change your tactics accordingly and just see what happens…

-Henrik

Credit to Gerald Weinberg, in whose fine book “The Secrets of Consulting” I first learnt about this idea.

Right after that a reporter confronted an analyst: How could you be so wrong to predict +20% for the stock market? It is now -20%!

Predictability makes us feel all safe and warm, but it is also an illusion that makes us badly equipped to deal with the complexity and chaos of reality.

Groups, organizations, countries, development projects and the weather are complex/chaotic systems. Minimal changes in any of a vast number of factors can cause huge and completely unexpected, unpredictable change. It takes courage to get out of your comfort zone and accept this. When you do, you can start really applying Scrum/agile.

Step one is to get transparency in place. When working in complex/chaotic environments, we cannot accurately predict the future. What we can do is to make sure we can assess the reality of today. What is the current true situation? Sunny? Raining? If you don’t have any windows, you may need to fix this first to enable transparency. When we have accurate information, we can make optimal decisions. Lets go to the beach! Lets do that picnic in the living room instead!

For software development, transparency means starting to do one thing at a time and getting transparent about how many features have we really finished. I mean really finished, with no work remaining. Ready to deliver, approved by customers, no work (“bugfixes”) postponed for the future. How many features, and at what rate are we completing them? Why focus on finished features? We do that to get better accuracy. Before we start developing a feature, its status is 0% done. When it is finished it is 100% done. In between those states, our guesses about work remaining is not that accurate.

When you get transparency in place you can start optimizing your results based on reality instead of giving in to your basic needs of feeling that the world is predictable. Product managers will actually have useful data to base their strategies on. Teams will be able to focus on stepwise implementations of continuously optimized and evolving product visions and roadmaps. Ironically, giving up the wish for predictability will give you greater control and produce results that exceed everyone’s expectations!

It is well known how to do this for software based development efforts by applying Scrum and other agile methods. That does not mean it is easy. And it takes courage. 85% of all organizations report that they are using elements of agile techniques, but very few have actually done what I talked about above. That means they have not addressed the main issue. It takes courage…

- Henrik

No, the idea with the paper’s is to share collection of techniques that I have found to work well. If you find them interesting, you can try them out while you are experimenting to get to a way of working that best fits your current situation.

The format of the papers has been choosen to be somewhere inbetween a blog-post and a book. I will try to make them small enough so that many people will find time to read them, yet long enough to contain some useful information.

So, lets see how it works out! Today I posted the first paper: “Retrospectives, Part I – Getting Started”

I hope the paper will be useful both for newly started teams and for existing teams that are interested in improving their retrospectives.

If enough people are interested, I have a series of papers planned out covering various aspects of starting up Scrum teams and how to keep finding improvements.

The paper can be downloaded from here

So, let me know what you think!

With people in nothern Europe returning from their vacations I have two questions for all of you that are using daily standup meetings in your teams:

1. How long were you driving this vacation before admitting being lost and asking someone for directions?

2. Did anybody report an impediment being in their way at your daily Scrum this morning? (This is question 3 in a standard daily Scrum meeting)

I recently read an article by Yves Hanoulle where he comments on how hard it is for most of us to ask for help. Either we don’t want to bother others or we want to be able to work things out by ourselves. And it may take a while before we realize that we might need help.

Yves’ advice is to change the third question in the standup meeting to “where do you need help?”. This sounds like a great idea.

I think I would like to try a variation and change it to “With what could someone best assist you?”. If you do that everyone has to think of something, and you cannot routinely just say “all is fine, no help is needed”

Try it! I know I will!

I have worked in agile teams for more than ten years now and as a full time agile coach for several years, so why did I bother to take this exam?

For one thing, I thought it would be a nice challenge! I find that trying to figure out the answer to tough questions always deepens my understanding. In fact a lot of what I learn, is from people asking me questions. So, I thought it would be interesting to work through some questions considered important by the co-founder of Scrum, Ken Schwaber.

Well…boy did I get what I asked for! Almost needed to use to full two hours to complete the test and some of the questions were really tough! I passed with a 95% score though. I misread one of the questions and I’m not sure that I agree in a few cases where my answer was rejected, so I’m quite happy with that!

Besides the challenge, I took the test just to check it out, and I was very pleased with what I saw. Until now ScrumMaster certifications in the Scrum community have been handed out without the person being certified having to do anything except to stay in a room for two days. I think the new written ScrumMaster assessments from Scrum.org are a welcome change to that! A lot of people, like me, will get more motivated to grasp the subject a bit more thoroughly before taking the test and that will be a good thing! Especially in the case of the level II assessment, where a lot of questions are in essay style, I also think that the assessment result can be an indicator of knowledge.

Another thing that Scrum.org is doing is widening the spectrum of training offered. In addition to ScrumMaster skills, you can now also get training in skills needed as a developer on agile teams. Other types of skills like facilitation and team skills are also mentioned as possible candidates for Scrum.org offerings if I remember correctly. This addresses a main problem in real life Scrum implementations today. People may have a basic understanding of Scrum, but they have not yet experienced what types of issues that can be resolved by adding technical practices for example from eXtreme Programming, XP.

Nothing has affected the spreadin of agile so much as the strength of the Scrum brand. As unfair this may seem to the other fine ideas in agile this is a fact. Hopefully the new Scrum.org organization with its fresh ideas will now contribute to getting the level of agile actually practiced in real developments teams to a higher level.

Well…probably not! Not if you picked a reasonably motivated individual anyway…

According to team building expert Christopher Avery, the most powerful member of a team is the least motivated person!

Really? How can that be?

Easy…low motivation is more contagious than high motivation. Nobody likes to carry the weight of a slacker! Thus, slackers tend to drag their complete teams down to a similar low level of performance!

Interesting, but if we have an attractive bonus system and decent salaries, that will make sure everyone is motivated, right?

Well…take a look at this story, slightly modified from the version told by Alfie Kohn in his book “Punished by rewards”:

“An old man had some problems with the local kids. Every day they used to stop by and taunt him, throwing stuff at his house and calling him names. Luckily, the man used to be developer on an agile software development team in his youth. Using what he learnt about the human psyche in the old days, he came up with a plan:

The next day when the kids stopped by to taunt him, the man offered them each a dollar for coming back the next day to taunt him some more. The kids accepted his offer and came back the next day. When they did, the man offered them 50 cents each to come back again the next day. The kids grumbled a bit, but came back the next day to deliver some more abuse. When they did, the man again offered them some money to keep coming back, but now he only offered them ten cents each. The kids were really dissatisfied with this offer and never came back.”

By introducing a reward for something the kids enjoyed doing for free, he was able to take away their intrinsic motivation and make them stop.

Wow…we probably should take some care so that we don’t accidentally do that! But what does work then?

In his article “One more time: How do you motivate employees?”, Frederick Herzberg reveals some related research results: The factors that cause job dissatisfaction are not the same factors that cause job satisfaction. E.g. salaries can cause dissatisfaction, but never extreme satisfaction. On the other hand “achievement”, “work itself”, “growth”, and “recognition” are all factors, “Motivators”, that can cause extreme job satisfaction.

This sounds familiar…pride in work, right to do quality work, focus on learning and personal growth are some of the “Motivators” that are right there at the core of agile development. And according to surveys like the annual VersionOne, “The State of Agile Development”, agile teams really do enjoy work more than other teams. But still, everyone is different. How can we make sure that each and every member in our teams is motivated?

Christopher Avery again has some insights. In his book “Teamwork is an individual skill”, he proposes that each team should have 5 conversations to enable high performance teamwork. One of these conversations is “aligning interests”, i.e. figure out what motivation each individual has to contribute his full potential to the team. Keep finding ways to rearrange work until everybody has similar motivation. He also offers a breakthrough technique to figure out what motivates each individual: Just ask!

So, who’s got the power on your team? How about just asking?

- Henrik

Why does this keep happening? The answer is that through the years, business people have learned that developers are lazy. When developers whine about impossible deadlines it is just a matter of telling them that it needs to get done, or else… and then they will do it.

Developers, on the other hand, have learned many powerful ways to “speed up” the development when presented with impossible deadlines that “have to” be met. They can skip making the code readable, skip the unit testing, skip refactoring, skip the load and security testing, skip the code review, skip the documentation, … In this way they can easily double the speed at which they produce crap.

Of course the drawback of these techniques is that they do not really produce usable software. So a lot of time will have to be spent on fixing trouble reports. Typically 15-60 times as much as it would have taken to build quality in from the start. Also, over time, the code base gets more and more messed up and harder to modify. Thus, development will get slower and slower.

Naturally a project like this will overrun its initial schedule & budget. After a few years it will no longer be possible to maintain the system and the company will be in serious trouble.

The way to make this madness stop is to shift to iterative, value-driven development. I.e. each release is split into a number of iterations. Each iteration a number of features of value to the users will be completely developed. The most important thing with this is to establish a “definition of done”, a detailed specification of what it takes for a specific feature to be considered as “done”. If the definition of done states that quality shall be built in from the start, it will no longer be possible to “speed up” development by reverting to produce crap instead of working software. Business people will not be able to tell developers to work faster anymore, so instead they will need to start selecting the features for each iteration/release that give the maximum return on the investment.

One interesting thing about that is that an average requirements specification contains 64% features of little or no use to customers. These features will never be selected for implementation when doing value-driven development and thus the project time may be cut in half.

Here are a few ideas on what to put into your definition of done:

• Code shall be covered by automatic units tests with at least 90% branch/condition coverage
• The design shall have been refactored to integrate the new features in the cleanest possible way
• There shall be no duplicate code
• Coding standards shall have been met
• The code shall be easy to read and understand
• Documentation required for future maintenance shall be done
• Cycliomatic complexity of the code shall be < 10
• Maximum levels of nested code (if statements etc) shall be 3
• The code passes some lint-type tool at some specified warning level
• All automatic tests have been run with a dynamic checking tool such as Purify
• The new feature shall be covered by automatic customer acceptance tests
• All non-functional requirements applicable to this feature shall be covered by automatic tests
• User documentation shall be done
• Release documentation shall be done
• The feature shall have been accepted by the customer
• The feature shall have been installed at the customer site

Pair programming is very useful to make it possible to maintain extreme dicipline like this under pressure. For the same reason, whenever possible, try to cover your definition of done with automatic tests. Some useful tools for this are BullsEye, Lint, Purify, CloneDetective, …

The list above is just a quick example. You will be able to add a lot more to your list, and yet most teams will not be able to meet the example list initially. But just get started with whatever you can manage today and keep working on it. With time you will be able to expand your definition of done so that there is really nothing left to do when the code is marked as done.

When you get to that point, you will always be operating at maximum speed since there will be no old baggage slowing you down. At this point, few of your competitors will be able to keep up with you. That is a good place to be…

- Henrik

How can such a large improvement be possible? Being co-located makes very high bandwidth communication possible, enhances learning and supports creating teams that really jell together. Remember, the bottleneck in software development is learning and the best work is carried out by small self organizing teams.

In the research on co-locating there are also some really interesting findings on what happens when people are not “at hand”. Communication drops of significantly it seems, right when people are first out of sight. Being 30 meters apart is essentially the same as being truly remote. One would think that use of email, phone calls, and video conferences would make up for distance in today’s high tech workspace, but in practice this is not so. Professor Thomas J. Allen puts explains it like this: “We do not keep separate sets of people, some of which we communicate in one medium and some by another. The more often we see someone face-to-face, the more likely it is that we will telephone the person or communicate in some other medium.”

So, if you feel up to trying out some co-located teams, here are a few tips:

• Provide facilities for teams to work in, but don’t co-locate a team until they request this. Remember, the basic rule for all change is that it does not happen unless everyone involved individually takes the decision that the new way working is of direct personal benefit to them.
• People may feel that giving up a private office for co-located space is a loss of status. To handle this, a co-located space must be made an attractive option. Working in a well designed space like this should be made feel like a privilege, not as a cheap alternative to offices. So use your best spaces and don’t crowd them. Provide windows, air, plants and lots of first class work equipment like whiteboards and computers.
• Have just one team (i.e. ideally < 10 people) in each room. Agile teams get noisy and that is the way it should be. Provide noise isolation to prevent disturbing other teams/persons.
• Supply adjectant conference rooms for meetings and hotelling cubicles for work away from team, making private calls etc.
• Make sure desks support pair programming by having space for two people working side by side, shifting keyboard back and forth.
• Encourage each team to write down and maintain its own set of rules on how to work together. This could include work hours, handling phone calls outside of war-room, no speaker phones, phones on vibrator mode, which type of discussions to hold in the war room and which should be taken to conference rooms, signals for indicating that a person wants some privacy etc
• When co-locating and shifting focus from individual work to teamwork, remember to also update your performance evaluation systems. Bonus goals and other performance metrics need to be measured at team level (or in general, one organizational level up) to prevent sub-optimisation.

So, get right to it and tear down those office walls now…for people working in solitude refining the latest statistics on the wheat production in the EU, offices may be great. For software development it is simply not good enough anymore…

- Henrik