Good Contents Are Everywhere, But Here, We Deliver The Best of The Best.Please Hold on!
Data is Loading...
Your address will show here +12 34 56 78
Agile, Basic Scrum, Scrum
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 🙂
1

Agile, Agile Coaching, Business, Scrum, tips & tricks
After many years of consulting large enterprises, building the right product I found, that there is one theme that keeps coming up again and again: Garbage in, garbage out. Those teams are trying to build the wrong thing righter, and the result is often disappointing. If the input of the team is crap, so will be the output. There are various reasons for that:

PO not empowered

Most companies implementing Scrum just grab their existing development teams and transform them into Scrum teams. The old project manager (PM) is now the Product Owner (PO), and some developer is playing the Scrum Master (SM) role additionally. The rest of the organization stays the same.  Usually, there is some marketing or product management department, that defines, what has to be built, which results in requirement documents that are handed over to the new PO. The newly appointed is then entering each of the requirements into Jira, VersionOne or any other “agile tool” and the Product Backlog is done. If he tries to order the backlog by asking what is the most important, he gets the answer that everything is important. In the end, this pseudo PO cuts the product backlog into Sprints and the only things that change for the team, are the bi-weekly Sprint Plannings. A few month later, everybody states, that Scrum didn’t bring any improvements. Does this sound familiar? Some companies call that “Proxy PO,” which isn’t simply more than an anti-pattern.

Stop doing this! Empower your PO! Get somebody in your Scrum teams, who can take product related decisions. Only then, you have a chance to build the right product.

No Vision

It’s still scary for me, how many development teams don’t have any vision. I just had a team building a product for the last 5(!) years without knowing why they were doing this. Even the Pseudo PO had no clue, what the purpose of the product is and what problem it solves for the future customer/user. They even build a second version completely from scratch. Millions of Euros have been burned, without earning a fair amount of money. How can you create something without knowing, what the problems are you are solving? How can you take decisions on a daily basis, if you don’t know where you are heading to?

Before you start developing your product, make sure that you know WHY you want to build it. There are various tools out there, that can help. Try to start with the Product Vision Board (Roman Pichler) or even simpler: a Lean Canvas.

Swiss Army Knife

You don’t know exactly, what are the most important use cases for your product? Ok, then let’s build a Swiss Army Knife! Not! It will just make you slower. You won’t benefit from a shorter TTM (Time To Market), even when using Scrum if you are trying to cover all possible use cases. This is a so-called CYA (Cover Your A**) tactic. Usually, this happens, if nobody in the company has a clue, what the most important use cases are. This leads to long development times, and when you hit the market, you only have a mediocre product.

Talk to your customer! If they are working on confidential products, where your product is only one part (e.g. a sensor for a new upcoming smartphone), sign an NDA. Convince your customers, that you can only build the perfect product if you know their future use cases. Stop being mediocre and start being outstanding solving your customer’s problems.

Conclusion

You can’t deliver excellent products if your team’s input is average. If you put garbage on the team, the outcome will be garbage, too. It’s not enough to transform your development teams into Scrum teams, you have to work on their environment, too. And you have to make sure, that you transform your input to your development teams into something meaningful.
0

Agile, Retrospective, Scrum

In the normal case, every retrospective starts with gathering the data from the last sprint. Often enough it happens, that the team discusses the same topics again and again and it feels like not moving anywhere. But still, we insist on starting every retrospective from scratch.

Instead, it could make sense to focus on one and only one topic for a predefined time frame and make this topic the central theme for the upcoming retrospectives. Just imagine, that the team has quality issues with their current product already for quite some time and everything they tried so far, was only a drop in the ocean. Now, the team decides to define the topic of improving the product quality as their main theme for the next three month. This means that every retrospective in the next month will explicitly care for getting rid of these issues.

It makes sense, to do a short rating of the theme at the beginning of such a timeframe to get a feeling where the team is currently at (e.g. between 1 and 10). Based on this rating, the team defines a goal they want to reach in the next month. Only after that goal has been reached, the team will focus on another topic. It’s a bit like a task force approach.

At the beginning of a themed retrospective, the experiments of the last one are validated. The team checks, if the defined experiments were successful and the initial hypothesis was true. If yes, they can focus on the next issues. If no, they can define the next experiments to tackle it, by considering the potential root causes for the fail (Generate Insights).

The advantages of such an approach are the clear focus on a certain topic and the prevention to talk about the same things again and again. At the same time, you get the purpose back into your retrospectives, because everybody knows, what goal you want to reach by doing them.

What do you think? Could this be a helpful approach for you and your team? Please, leave a comment.

2

Agile, Basic Scrum, Scrum
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
0

Agile, Basic Scrum, Scrum
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
1

Scrum
It’ about time to give the Product Owner a chance to fight back. With the help of Heiko Weltin I created a list as a base for the revenge. I hope you’ll like it:
  1. Create your product backlog without any prioritization. In the end you need all of the features before you can bring the product to the market.
  2. Only create the headline of your user stories and don’t add any additional content, even if the team asks. You can’t prepare everything for the team.
  3. Only use two types of priorities: “Urgent” and “Can be done later”. Anything else would be a waste of time.
  4. Always promise release dates and scope to your customer without talking to your development team upfront. You are a skilled estimator.
  5. Always add one task to a user story that keeps the team from finishing it. The Definition Of Ready (DOR) is for wimps. keep reading
5

PREVIOUS POSTSPage 1 of 3NO NEW POSTS