A few years ago I attended a Sprint review of a product development team. All stakeholders were invited to this meeting and got an update on the product the team was developing. The central message of the review was that the team wouldn’t be able to deliver the full feature set as promised before. Instead, the team was far away from delivering anything sellable to product management. The whole product was a mess (for various reasons that are not important here). The message was quite clear for everyone in the room: we are not able to meet the defined release date. In spite of these facts, the head of product management got up at the end of the review, gave everyone a pat on their shoulders and said: „I’m sure, you’ll still make it.“ He just ignored the plain truth, that was shown to him. He believed in miracles.

Scrum (and any other agile framework) is based on empirical data. Of course, this applies to estimation and planning, too. Due to the continuous inspect and adapt cycle, you are always able to replan, if necessary. In agile we always plan to replan. If you find out, that you won’t be able to meet a certain date or deliver a defined feature set, you have to react. It doesn’t help if you ignore the truth, even if it hurts. It won’t get any better. Instead, you lose the chance to do something, that might save your product or project. If everybody accepts the facts, you can always:

* reduce the feature set (in most cases it is anyway too big)* move the release date* add more people to the team (if it is still early in the project)* Stop the development* …

Don’t believe in miracles; they happen only rarely. Instead, accept reality and adapt your planning accordingly. You should always plan to replan.

The problem with Scrum (or any other agile framework) is that it won’t solve any of your problems. It’s like your evil mother in law, pointing at all the things that are not working or look strange, e.g. not being able to deliver something valuable at the end of a sprint. Scrum will make all your dirty little secrets visible, and that’s it. Now it’s up to you to tidy them up. Nobody else will do it, but you. If you ignore it, nothing will change, and none of your problems will vanish. Sorry, but continuous improvement is at the core of agile.

Fortunately, Scrum will support you to experiment, by providing a safe to fail framework, where you can try new experiments and immediately check if they had the desired effect. Retrospectives are giving you the time and space to inspect and adapt. It is also, fortunately, that there are plenty of books and blog posts, where you can find millions of ideas about what you can try next. Also, the agile community is there to help. That’s excellent news, isn’t it?

But if you are still waiting for your manager, your organization, your colleague or the cleaning lady to do the first step, you’ll wait forever. Change starts with you. Be the change you’d like to see. Lead, by changing the way you work and inspire others. I know that it takes some courage to do so, but that’s why courage is one of the values of the Scrum framework, right? Don’t ask for approval! Just do it and apologize later (if needed). Thank you.

In my experience, the Daily Scrum is one of the most misunderstood Scrum meetings. Here are my favorite ideas, to improve your Daily Scrum

Get rid of the Scrum Master and Product Owner

One of the biggest issues with Daily Scrums is that they are executed like reporting meetings. People feel the need to prove, that they have been working the last 24 hours, especially if the Product Owner or Scrum Master is around. But that’s not the point of the Daily. The Daily Scrum is a meeting for the team to plan their day. It’s like a mini Planning meeting. So, kick the PO and SM out of the Daily and start focusing on what to accomplish on the new working day.

Forget about the past

Talking about the past for hours is easy. You don’t have to make things up, as they have already happened. But 90% of what you have experienced the day before is just boring stuff nobody is interested in. Try to get rid of the part in the Daily where you talk about the last working day. Instead, plan the day ahead. Who needs help? Who will pair with whom? What are today’s challenges? How can we make sure, that we finish some tasks by the end of the day? etc.

Walk the board

Use you task board aka Sprint Backlog during the Daily. Only talk about things that are on the board. Add something, if it is missing. Use the tasks on the board to guide the Daily, instead of taking turns. Whoever has to contribute something, chimes in. That way, you start planning your day. As already mentioned: Ignore tasks, that are in the “Done” column. Only talk about things in the past, if they are important to all team members.

Start with appreciations

We tend to forget to say “thank you” to our teammates. Why not begin the day with appreciating, what others have done for you or the team the day before? That’s an excellent way to start the day with a smile.

Show what you are working on

If you really cannot resist talking about what you have achieved the day before, why not showing it instead of just talking about it? This way, your work gets way more tangible. Maybe, you’ll even get some nice feedback, which helps you to improve your work even more. And yes, it’s possible within 15 minutes.

What other tips do you know to improve the Daily? Don’t hesitate to add a nice comment. Thank you 🙂

You are thinking about transforming your world of work and start using agile frameworks. But there may be a few thinks, nobody told you about agile before. Now is the time:

Agile won’t solve your problems

Some people believe, that agile processes are some kind of silver bullet (mostly the same people, that believed the same about CMMI, RUP or the V-Model). But agile processes like e.g. Scrum are nothing more than your nasty mother in law. They make all the problems and impediments transparent, but you have to solve them on your own. Yes, they’ll support you to start experiments and by reducing the risks by using short inspect & adapt cycles, but the hard work is up to you.

Only by following the process, agile offers no benefits

I saw teams, that did Scrum exactly by the book. They had daily stand-ups, sprint planning meetings, sprint reviews, retrospectives and some even had backlog refinement meetings. But they only had minor advantages in doing so. But why? Agile is not about doing but about being. It is a mindset change and not exclusively a process change. Only if you embrace things like the twelve principles behind the Agile manifesto, Lean thinking or the PASSION model, Scrum will unfold its full potential.

There is no “agile switch.”

No, it is not enough to send all you employees on a two-day Scrum Master certification training, and you’re done. There is no such thing, like an “agile button” you can just push and it will work like magic. When you look at descriptions of the Scrum process, it seems like an easy thing, but the exact opposite is the case. You have to learn things like increasing the number of things not done (sounds crazy, right?), delivering production ready products every iteration (which is really hard especially, if you used to have platform or component teams), tackle tough organizational issues (which is one of the major impediments for successful agile transitions) and more. Yes, you can “switch” to agile, but it will take months or even years to get there.

Transforming to Agile means transforming your organization

Still, most of the agile transformation initiatives start in product development. But if the rest of your organization ignores this initiative, it is like planting a flower in the desert; it will slowly die. There is no way to transform to agile without transforming the whole organization. If you are not ready for that, you are not ready for agile.

Agile is NOT faster

Even if the term “Sprint” implies, that agile is fast, the contrary is the case; at least at first sight. If you want to have production ready releases at the end of every iteration (which includes development, testing, integration and yes, even documentation), you are not able to deliver more in the same amount of time. What is true is, that agile will help you to decrease your TTM (Time To Market). Sounds like a contradiction, right? This is true for various reasons:

Agile is about simplicity and increasing the number of things NOT done. This means you focus on what the customer really needs instead of building a cluttered product nobody can use with features nobody needs. This, of course, leads to fewer things in your backlog and ultimately to a better TTM.

As agile builds in quality right from the beginning (you remember: a tested and integrated release at the end of EVERY iteration), there won’t be everlasting bug fixing phases at the end of your project. Also, the time you need for maintenance will decrease tremendously.

At the core of agile, there is a continuous improvement process. This means that the way you work is improving throughout your project. Better process = better TTM.

Once I had the pleasure to work in a company, that decided to introduce a global development process. This global process was introduced at each subsidiary, that took part in the development of new products. It didn’t matter if it was a pure software product or simply a piece of hardware without a single piece of electronics. One size fits all. Of course, it was possible to tailor the process to your needs, but in the end, you had to follow about 90% of the process elements. This lead to insanely long product development cycles. Even quite small products ran at least six months, because of the overhead the process introduced. Additionally, the higher complexity of software projects was completely ignored. As you may have guessed, after reading these lines, I believe this is a very bad idea. Every process that ignores its context is foredoomed.
keep reading

There thousands of teams out there, that are using Scrum. But I assert that only a small fraction of them is really “living” Scrum and therefore successful. You can spot great Scrum teams based on the following list:

1 – Continuous Learning

A lot of agile teams become lazy over time. Especially, if it seems that everything is running fine. They are laying back and the continuous improvement process gets stuck. They stay in there cosy and warm comfort zone and nobody wants to take the next step. This leads to a decreasing quality of the team’s results and the advantages of an agile process vanishes. If a Sprint Planning looks the same after practicing it for half a year, the teams is NOT agile. In an ideal case, the Scrum process completely changes during the course of a year.
keep reading

It’s about time to nag the product owner, isn’t it. Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:

Five minutes before the Sprint Review is the right time to tell your Product Owner that your team wasn’t able to finish anything. It is even more fun, if this was a planned release. Transparency is for milquetoasts.

Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.

Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?

Assign all tasks that were created during your retrospective to your Product Owner. He is the root of all evil and responsible for all the problems in the project.

Have you ever been sitting in a sprint planning and heard the following sentences:

“Can we split this user story and at least start with the GUI?”
“I’m not sure if the hardware will be available on time to integrate this story but we could use an emulator instead.”
“There are no wire frames yet, but we could start with the back-end.”
“The acceptance criteria are still quite vague, but I think I know what the customer needs.”
etc.

Does some of these sentences sound familiar? I observed these conversations several times in the past. All of these quotes are based on the same problem: The user story is simply not ready for the next sprint.