Scrum. Easy in theory, difficult to master. Will it work for your project? Does it work at all? How to introduce Scrum in an organization. How to make customers follow the guidelines?
I can bet you have the same questions.
There is only one way to answer all those questions and concerns.
You need to understand how Scrum is intended to work. You must know the common problems that arise in Scrum teams. After that, you need to ensure you will be able to overcome fears and natural patterns of behavior of the clients.
How will you do that?
I have a story for you. It will help you to get inside the mind of a client.
If you are not familiar with the basics of Scrum methodology, I suggest you read Scrum Guides first
It was a usual project with an unusual client.
John came to our company looking for a new vendor for a software project. He travelled with only intent to tour the office and meet people working there. He brought no project details yet.
I was assigned as a project manager for his potential account.
John is an open-minded and innovative person. He focuses on productivity and new technologies. He is always on the lookout for effective means to facilitate the work.
John had years of experience as a project manager. However, he never participated in software development. He was ready to try out new approaches and face the challenge.
All in all, I can surely say that he is a customer out of a dream.
But there is a catch.
He is a customer to the full extent. In other words, he is only a product owner, not a sponsor. Therefore, John has a vision of a product. But he uses the money of other people.
That is important to keep in mind.
After the initial tour, we had a meeting where, besides other topics, we discussed Scrum.
John: When Does Scrum Work the Best?
To tell you the truth, it is always a sort of a problem to answer that question.
Why?
The marketing description of Scrum always comes first. You feel like you need to warn the customer about possible difficulties and pitfalls. Nevertheless, you don’t want to scare him off with too many details.
Here is what came out.
Small Team is a Must
Scrum works best when the team is four to ten persons. When there is less than four, it will often be constrained. If it is larger than ten, it is harder to manage and coordinate it.
However, it is only the surface, a simplified explanation.
What’s the real story?
I had to answer this question a bit later. Read on.
You Can’t Win Without Engaged Product Owner
What’s next? It is you, John. We need you to engage into the development process. You need to provide requirements and priorities.
And you must believe us.
You see, you pay for the team. The team delivers value. However, there is no way we can ensure that you have enough money to create a valuable product. And it is hard to predict if you will get a return on investment.
That is something Scrum omits. But no worries, we will sort this out for you. Well, actually, we will plan out the project at a high level the old way.
It is your responsibility to maximize the benefits for the team. Also, you must define what User Stories will create the most value for your product.
However, you can not influence the decisions of the development team. You need to believe that they are doing their best.
Choose a Vendor with Flat Organisation and Little Politics
You see, John, there is a myth about the Scrum Team. It consists of you as a Product Owner. Me as a Scrum Master. And our development team.
The problem is obvious. You have a boss and sponsors to report to. They have their own interest in your future product.
I also have a boss. In addition to that, we have several supporting departments. There are other projects around. Moreover, some of them share the same sponsors.
You and I must keep them all at bay.
Somehow…
You must ensure that sponsors and your clients do not conflict. So that we don’t receive conflicting requirements from you. And they will push. They will want more value for each dollar spent.
From my side, I have to ensure that the whole world around our project understands agile values. I must shield the team from their influence and distractions.
However, at the same time, I must behave well. You see, our team doesn’t work in a vacuum. We are fully dependent on their support.
Both Vendor and Customer Should be Agile
I can see from your face, John, that you already envision problems when two worlds collide.
In Scrum, there is only value. The team produces increments of the product. No tools to control the overall project progress. No metrics to report.
You only have the price of the team and product in its current state.
We will have to create a way to keep our reporting requirements in alignment. Because at some moment, we will feel pressure from sponsors.
Constant Shipping to Market
Continuous delivery might be a solution. Releasing almost every increment to the users is the intended approach. It increases perceived value. You can get early feedback from users.
New metrics will appear. You can measure satisfaction, you can collect analytics.
But what’s the catch?
It is hard. It is not really efficient by the standards of project management. You need to accept smaller increments.
It is a trade-off.