I’d like to address some of the top challenges that I see people face with implementing a culture of agile philosophy in our industry. I am an Operations person. I call it Operations because of the huge amount of grief associated with the various guises of project management (project manager, program manager, ScrumMaster, Agile Coach and many more), largely due to the behaviours exhibited when this role goes wrong.
I never thought too much of the titles, but I’ve come to believe that the Project Management “brand”, and more recently the Scrum Master “brand”, are becoming so damaged that a re-branding may be in order. But that’s a topic for another article. Here are the top six misconceptions that I see organisations face when implementing agile.
Misconception 1: Transitioning to “Agile” will solve our problems.
The agile manifesto was born out of a frustration with traditionally managed projects. But I don't think it solved the problem. It actually created another one. I've seen teams and organisations go from waterfall, which reduces their ability to compete in the market and deliver value, to dysfunction and paralysis when implementing agile.
That's largely due to the various interpretations of the manifesto borne of misunderstanding. Bottom-up as well as top-down support is needed in order for a successful agile transformation to take place in any organisation.
The way I’ve always understood the agile manifesto is that it prioritises decisions made with people in mind over processes and tools; working software over comprehensive documentation; client collaboration over contract negotiation, and responding to change over following a strict plan. That does not undermine the importance of contracts, plans, processes and tools. It’s a balance that’s often about making the right trade-offs for the right situation because you don’t want to go out of business once you’ve implemented “Agile”.
Misconception 2: Seen as operational and tactical, rather than strategic.
This is largely due to the misunderstanding that agile is just a set of process frameworks and tactics. That's not the way I have experienced it. To me agile is about being effective over being efficient. It's about creating sustainable solutions that are aligned with business vision and strategy. It's about bridging the gap between the long term and the short term by aligning them together.
Misconception 3: The role of the Scrum Master as a Servant leader.
I want to be very clear with this, servant leader doesn't mean a secretary or a team administrator who does the chores for the team. It also doesn't mean agreeing with everyone at all times. Servant leaders lead in ways that “create a life that feels good on the inside, not just one that looks good on the outside”. And that’s really what I see to be at the heart of coaching as a core skill of the Scrum Master / Agile Coach.
Misconception 4: The framework encourages adapting our processes, so the team should be able to change the framework as often as they please.
Often teams understand that because it’s agile and we have an opportunity to inspect and adapt our processes each sprint, it means we can change the framework altogether. But the framework (eg. Scrum, XP, BDD) is the foundation on which process are built.
Changing the framework can sometimes be very beneficial to a team, but that is usually in cases where the teams move from one type of work to another. It’s the equivalent of being half way through a project delivery when someone insists you should change from Angular.js to React.js in the name of experimentation. Decisions like this can have a disproportionately disruptive effect on the team flow and results, especially when applied in the wrong context and at the wrong time.
Misconception 5: We can be "agile" in delivery, but it doesn't apply to discovery.
The biggest flaw of the old Waterfall process has always been, and remains, that all the risk is at the end. This means that customer validation happens way too late.
You’ve hopefully heard of Lean Startup methods, which are very much at the heart of the alternative. They are also fundamentally embedded in agile methodologies like Scrum and Kanban. The key principle is to reduce waste, and one of the biggest forms of waste is to design, build, test and deploy a feature or product only to find out it is not what was needed. The irony is that many teams believe they’re applying agile and lean principles, yet they follow the same old waterfall process by separating out discovery from delivery. That is falling into the trap of upfront design followed by incremental (sprint-based) delivery, and it’s one of the most expensive, slowest ways possible to try out ideas.
Teams that truly understand how to leverage the benefits of agile, understand that discovery and delivery are continuous and the increments of work (aka Sprints) are only useful if you aim for a specific goal or an outcome at the end. Each iteration should deliver value on it’s own and should be ready to be deployed to a production, pre-production or any other customer facing environment, such as Invision or Balsamiq, for example. It doesn’t have to be code-ready, but it has to be customer-ready.
Misconception 6: Agile is all about uncovering learnings as we go along, so we don’t need to focus our efforts on planning.
No, just no...There is a difference between failing fast and learning from it versus becoming a liability to the business. Planning is paramount to the success of a product initiative or project. It’s what differentiates successful teams from unsuccessful ones and sustainable businesses from failing ones.
That’s it for now. It’s a slightly depressing topic, but I’m positive that businesses can benefit from more awareness with some of those misconceptions in order to build the ability to recover quickly. And that would be a big positive.
I will address some of these misconceptions in more detail in following articles. Stay tuned.