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.
Put teams in time zone as far away from each other as possible
If teams work in close time zones, they can use their working time to collaborate. But that is exactly, what you like to avoid. Therefore, make sure that the difference in time between all your teams is as big as possible. The best is to have a twelve-hour time difference so that one team is going to bed, while the other teams are starting to work. That way it always takes a day to get an answer to your emails which slows down communication. Scheduling a meeting, that fits for all parties is nearly impossible. Isn’t that great?
Don’t allow modern communication tools
Give your team the worst communication tools. If possible, even prohibit emails (while telling your teams, that they should make use of face to face conversations). If you already have some tools in place, make sure to limit them to audio only. Video or screen sharing is only allowed for higher management (yourself) or needs a complicated application process (signed on real paper by managers around the world). You know, because of security. Somebody could walk by a meeting room and see some confidential information. Scary…
Don’t let them meet in person
The worst thing that can happen is that the whole team meets in person from time to time. This would lead to a better understanding between all the team members and eventual to a better (remote) team performance. You don’t have any budget for that, have you? That was exactly the reason, why you created that remote team: to save some money. So you cannot afford any travel expenses for those cheap workforces (That’s at least what you tell them).
Do you have any other ideas to sabotage remote teamwork? Put your ideas into your comments.