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.
PO not empoweredMost 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 VisionIt’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 KnifeYou 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.
ConclusionYou 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.
Success is never because of the process but always about the people – Marc Löfflerkeep reading
Half a year ago I wrote a blog post about 7 Agile Sins. As I’m sure, that I’m not the only one who is guilty for one or more of these sins, I collected a list of possible ways to show penitence and to do it better next time 🙂 So here is my list of the sins and their appropriate penitence.
There are still a lot of people out there who believe, that agile methods are the silver bullet to all their problems. This leads us to the 7 agile sins, that I collected in this post. Let’s have a look at the 7 agile sins: 1. Stop learning
2. Don’t listen
3. Stop thinking
4. Be dogmatic
5. Ignore the agile values and principles
6. Misuse the agile toolkit
7. Ignore the transparency