First of a three part series...
Introducing Scrum can be fun, but can also be quite a challenge. There are numerous hurdles to overcome, new practices to master and problems to solve. In this article, we will present some of the mistakes we have seen made, or made ourselves when introducing Scrum at various companies. The pitfalls discussed here are valid within the context of a company in the process of adopting Scrum. Stepping into any of these pitfalls will make your implementation more challenging and difficult, but never impossible! Hopefully, you can learn from our experiences.
In this first article, we will discuss organizational learning, creating an environment of trust, and why Scrim should not be used as a quick fix.
#1 No organizational learning
We see that broken feedback cycles play a major part in not being able to create a learning organization. A very important thing in iterative and incremental development is the information you gather during sprints and the feedback you get from a sprint result. Even more important is what you eventually do with it! There are various feedback loops providing information on e.g. project execution, customer satisfaction, technical feasibility, usability and meeting the business goals. What we frequently see in projects is that the information coming from these loops is often not properly handled. This reduces the effectiveness of the feedback loop; thereby limiting the team and the organization in their ability to adapt and improve on their work. Without solid feedback loops, the iteration, demo and retrospective results do not usually improve planning, estimation, velocity or related practices - or even more important, team spirit!
The retrospective should be a very important practice to improve the team. It is not just the developers that should do retrospectives, it's everybody - including PO, stakeholders, management, etc. The results of a retrospective should be clear S.M.A.R.T. actions the team will pick up and organizational actions for the meta-scrum master to pick up. Try to get the organization to accept the result of your sprints. You can start with the acceptance of multiple iterations first because it's easier to get the acceptance team to accept a complete feature set of functionality instead of a partial feature set. Make sure that the end result includes approved requirements and any other required artifacts that can go to up for acceptance i.e. installation scripts, training materials etc.
Install the iteration results on a system where the customer and stakeholders can actually use it. Show it around, let them play with it, help them using it and encourage them to test some specific cases they think are important. This generates lots of feedback and is relatively easy to implement. Once people start actively using the demo systems and try it out with some of their own test cases, you can start thinking about asking them to write their acceptance tests before the iteration.
# 2 Environment of trust
An organization adopting Scrum is learning. And you can only learn be making mistakes. If the organization does not provide an environment of trust however, people will act using a CYA (cover yourself) strategy, hiding mistakes, delaying the decision making process. An environment of trust should make it possible for people to make mistakes and learn from them. It should alleviate the fear of embarrassment and should support a culture of inspect and adapt.
A big aspect of developing trust has to do with transparency and honesty. In Scrum, there are various practices that support this e.g. the daily, demo, the retrospective and the use of information radiators. People will need to learn that these moments are about giving positive, constructive feedback and for teambuilding! Another big aspect of developing trust is that it can only be built over time. We found that the most important thing to do as early as possible is delivering what was promised. This is fundamental! If you repeatedly deliver what you committed to and show it again and again to the stakeholders, you build a track record and show you are capable of delivering what was promised. Trust is now developing and you can take the next steps. It is very important, therefore, not to over-commit to what will be delivered next sprint!
#3 Using Scrum as a fix, without knowing the problem
Although we as Agilists are always glad to welcome any new members to the family, we're not glad to see people or entire companies joining for all of the wrong reasons. When implementing any method, you will have to make very sure you know what your goal is! In order to successfully implement Scrum, you will have to realise that just implementing the mechanics of the Scrum process is not just going to make life better. Implementing Scrum cannot be your goal!
We often see that we are asked to come in and help a company move to the ‘next level'. "We are doing Scrum, but we still have all our usual problems, just like we did before ...". When in return we ask what expectations were and how they measured progress and what their biggest problem with achieving expected results is, people often don't know what to reply ...
Before starting to implement any organizational change, you should have a clear vision of what you are trying to solve and where the most pain is at the moment. Answering these questions might not always be as easy as you would think. Let's see if we can define some steps to help you out.
Before even being able to think of any existing problems, let alone their solutions, we will need to be able to recognize the symptoms of possible problems. Here are a few we came across;
- Management is just unable to steer projects ;
- Lots of rework after we thought the project was finished;
- Deadlines are not met;
- Budget overrun is the standard;
- Employees are unhappy with their jobs;
- Clients are unhappy with products or services delivered to them;
- Unable to align work with other departments in the company
Where does it hurt?
The above is just an example of possible symptoms one might encounter when critically looking inwards to one's own organisation. Please note that these are just symptoms. And although Scrum can strongly reduce them, you still don't really know whether the problems causing these symptoms will disappear! So let's move over to the next questions to answer.
What causes the hurting?
When you're coming down with a fever, it can be very dangerous to take some fever suppression medication. Although this might make you feel better in the short term, it could be that you overlook the actual problem entirely. It might be that you have an infection which will become worse without you knowing it (because you suppressed the symptoms!). Better to go to the doctor and find out what the real problem is so you can get the right treatment and really fix the problem!
So, why didn't we meet our deadlines? Is it because of deadlines being imposed upon us, knowing full well that they are just not doable? Are deadlines not communicated clearly over all layers of the organisation? Are we too dependant on subcontractors to deliver? Etc ...
What would we be able to do when the hurting has stopped?
Such an envisioning will actually help you to see what the outcome would be of solving your problems. If the world doesn't look much better after solving a problem, are we solving the right one? This will help you to prioritize and choose what is the best thing to work on next.
In our daily work, we observe that these steps are skipped all too often. We see entire departments, companies trying to implement Scrum without having a clear goal. Expecting Scrum to fix your problems (without actually knowing the problems) will leave people thinking: "Scrum is just not for us" or even worse: "Scrum just doesn't work". While they should be thinking: "We didn't do our homework! Let's go back to the starting point and learn from our mistakes"!
About the Authors
Cesário Ramos is a Senior Consultant in Agile methodologies and Enterprise Java. Since the late nineties he has worked in various roles ranging from developer to agile coach. He has coached various projects at telecoms, financial and governmental institutions using popular methods including Scrum, XP, FDD and UP.
Eelco Gravendeel has started out his career as a software developer. Later moved on to become a team leader and then became the manager of a Software Development department. During this period he implemented Scrum the first time. Having tasted the Agile fruits he then moved on to become a Consultant and Project Manager. In this position he coaches departments and organizations to implement Scrum and Agile practices or manages Agile projects.
