Today, companies are becoming a part of the massive technological leapfrogging through some of the popular agile methodologies. When we talk about Agile, people think of “Scrum” naturally. Scrum is the most widely used framework among the popular organizations. These organizations leverage Agile and Scrum methods for a disciplined project management practice, as Agile encourages continual feedback, iterative development, rapid and high-quality delivery and iterative development.
- Expecting transformation to Agile/Scrum to be easy.
All too often someone will pick up a book on Agile, start chopping up requirements into user stories, begin daily stand-up meetings, develop software in 2-3 week sprints, and then call themselves Agile. Easy, right? They will likely see some development in their ability to respond to change, and May even provide working software faster – for a while. It won’t be too long, though, until the promises of Agile become less evident, teams struggle to keep up the pace, software doesn’t always match user expectations, and then Agile is deemed a failure. Agile transformation takes time and almost always starts out messy. Real transformation exposes existing corporate and culture problems that must be dealt with – problems such as poor communication, distrust, lack of accountability, etc. Effective Agile transformation is often a total culture change. Give it time, and be ready to go through the pain and resistance to cultural changes.
- Doing the practices without the principles.
Doing the easy things like implementing Scrum meetings, filling the Scrum roles and using proper Scrum artifacts is good, but is only half of the battle. The Agile principles are what make the practices work well, and make them sustainable in the long run. Principles are much harder to incorporate than practices, which are why many companies fall short – they don’t to the hard parts. Performing techniques without understanding why they are doing those leads to frustration. Agile is about people, interactions and culture, not processes, tools and practices.
- Complicating the Agile/Scrum startup.
Do everything you can to keep agile startups simple. Agile projects can be successful without the latest, coolest collaboration tool. Stickier on a wall, tasks in a spreadsheet, and a manually generated burn-down chart will get the job done. Spending valuable time getting a tool up and running instead of getting people working together is focusing on the wrong thing. The Agile Manifesto places higher value on individuals and interactions than on processes and tools.
- Leading a Scrum team like a project manager.
A “command and control” mentality is counter to the agile framework. A leader assigning tasks and dictating effort is an agile anti-pattern. Great Agile teams are self-organized, the Scrum Master is a servant leader, and teams learn to become better at working together and delivering greater value more efficiently by regular inspection and adaption to overcome challenges. Often the lesson is learnt better by experience than by just being told what to do. Allow the Scrum team to figure things out themselves, to make mistakes and learn from them, and to attain the satisfaction of becoming a productive team on their own. Scrum Masters and Agile coaches guide more than they drive.
- An un-ready product backlog.
A product backlog that isn’t “ready” is one of the most common reasons for sprint failure and for unmotivated teams. It is also a root cause for low delivery velocity and not delivering high value. Most new Product Owners aren’t ready to be productive on their own. They need instruction, coaching and hand-holding the first few sprints as they learn to develop and maintain a product backlog that has enough valuable features estimated at a high level, and prioritized by business value. Preparing the backlog well ahead of the next sprint(s) is a must. You never want the team to run out of work to do, and that work must be of highest value at that point in time as prioritized by the Product Owner. Being a Product Owner can be time consuming. Set the right expectations and provide all the training and help the Product Owner needs to keep the flow of value coming.
- Do we need a Scrum Master?
As prescribed by Agile and Scrum Guide, the delivery team consists of a Product Owner, development team, and the Scrum Master. Each role has its own responsibilities and their own boundaries. This gets thinned when the role of a Scrum Master is not taken seriously. In some of the teams, we have observed, the team members play a dual role, for example, product owner plus a Scrum Master or Scrum Master plus developer. It is really critical to understand that if someone with another role plays a Scrum Master, then they are hindering the person’s ability to focus on helping the teams, following processes or removing impediments. It is a very crucial role which helps the ship to sail through along with shielding the team from outer distractions.
- A Product Owner who is not available or involved.
The Product Owner role can be very time consuming. Many new to the role are not ready for the commitment, or just don’t know that they need to be so involved. Collaboration is critical in the agile world. Business people and developers need to work together to produce software that the business wants. This happens by constant communication, collaboration and short feedback cycles to validate or make course corrections. A practice we love to see is the Product Owner so involved in the day-to-day activity of the project team that the Sprint Review is purely a formality, because the Product Owner has already seen several iterations of the features throughout the sprint and has guided the team to build exactly what the business wants. That’s a beautiful thing.
- You have to stand up.
Another myth is that the Daily Scrum has to be done standing up. This is a technique that is applied to avoid lengthening it for more than 15 minutes, the maximum recommended time. To do this, each Development Team has to self-organize and it is the Scrum Master who must teach them and help them achieve it. A good sign of this is that the day the Scrum Master is absent; the event develops successfully and works.
- Not raising obstacles early enough.
The daily stand-up provides the opportunity every day to communicate impediments to getting our work done. One of the primary functions of the Scrum Master is to remove obstacles so that the team can focus on delivering software; but if obstacles are not raised, the Scrum Master can’t help remove them. Waiting to raise an obstacle until it’s too late to recover from it is unacceptable. Until team members are accustomed to communicating obstacles in a timely manner, we remind the team at the beginning of every stand-up to bring up even potential obstacles, or if there’s any chance something might detain their work or cause them to not live up to their sprint commitment
- Not conducting retrospective meetings after every sprint.
One of the twelve principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. Unfortunately the Sprint Retrospective is often treated like an add-on or a luxury, and performed only “if there’s time”. The fact is, Agile is all about adjustments here and there, fine tuning and responding to change. It’s really hard to adjust and fine tune if we don’t pause to find out where adjustments are needed. The status quo is not agile; constant development is.
As a final note, we have been hearing that ‘Scrum is lightweight, easy to understand but hard to master’ and it is true. Here we have just talked about 10 mistakes that we do, but there are many and differs from case to case. It just requires someone to identify and help the teams walk on the right track. You might have come across some mentioned above. And we really appreciate that you identified it, we would be happy to hear from your experience, the mistakes you encountered.