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

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

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, 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

Basic Scrum, Scrum
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:
  1. 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.
  2. Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.
  3. Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?
  4. 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.
  5. Don’t attend the Sprint Review. You already know how your product looks like. keep reading
2

Basic Scrum, Scrum
Now that the team is armed with new weapons, it is time to help the Scrum Master to fight back. If you didn’t read my first post on this topic, have a look at the ten things, a Scrum Master can do to drive the team crazy blog post I wrote two years ago. Here we go:
  1. Get your own office, if possible in a different city or even country. Working at the same location as your team could be harmful.
  2. Count the number of finished tasks per team member and confront those lazy buggers with the obvious low performance.
  3. Try to restrict the communication with the team to Email only. You don’t want to hear their whiny voices.
  4. Don’t tell the team what you are working on. Transparency only applies to the rest of the team.
  5. Always cite the Scrum guide if members don’t stand to the Scrum rules. Continuous repetition will help to raise the team’s understanding of this process. keep reading
7

Agile, Basic Scrum

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.

7

PREVIOUS POSTSPage 1 of 2NO NEW POSTS