Check it out, and let me know if it was useful to you!

Henrik

In popularity, “meetings” tend to be viewed as enjoyable as a dentist appointment. We have books like “death by meeting”, lean-gurus go on about meeting as waste, and yes, I have actually seen someone trying to schedule a dentist appointment just to get out of a sprint planning meeting

Fine, except that there are no “meetings” in Scrum…

Scrum is a team based approach to solving complex problems. One of the basic ideas is that people together, with a variety of skills and views, can better solve such problems than each individual alone. This I am sure you know from experience. Even just describing your thinking to others often help.

So, the idea in Scrum is that it is useful if people work together in various ways all day long. How this is done, is mostly left up to people doing the work to decide.

Scrum does have some suggestions on how to spend a small bit of all that time that your team spends working together. Like planning what to do and how to work together on something and then evaluating the results after.

These are not meetings though. These are working sessions where each individual is fully focused on the collective task, participates every minute by learning or contributing and leaves feeling energized from new insights and happy from all the progress that was made in such a short time.

A very different session compared to what we usually call meetings. From all the meetings we all have had to endure, the word “meeting” is probably beyond saving, so maybe we should just stop using it.

For complex work, it is useful for people to work together. That does not make it a meeting. It is just people getting the job done together in the best way they can.

By the way, if you are doing some Scrum activities and they feel like traditional “meetings”, this is something for you to think about and improve. It is not mandatory to get bored and waste your time in Scrum. Quite the opposite. Perhaps once someone told you there was going to be a “meeting”, so you did set up a traditional meeting. This is understandable.

Well, now you know better, so just get your people together and figure out how to do it in a better way. In a way that builds your spirit instead of kills it!

Don’t settle for less.

Henrik

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). Any surplus after that will be deposited at Kiva.org to be used for micro-loans. Trying to assist others to sort out their own problems rather to sort it out for them, just as Scrum!

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