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