It seems that lately Agile (and Scrum in particular) have become the latest craze among the corporates in Bangladesh, especially those working in Digital or adjacent businesses. While Agile seems to be the go-to mantra of the C-suites for magically catering to the ever changing needs at a lightning pace, at the operational levels – it falls apart more often than not.
This is not to say that this reflects the weaknesses of the Agile principles or of a specific methodology — more often than not, they’re a reflection of a certain culture or work environment that itself is fighting against the fundamental tenets of Agile and Scrum.
If you’re one of those people for whom either Agile or Scrum doesn’t seem to be working, here are some hard questions to ask yourself and your organization — The fault…is not in our stars. It is ourselves.
Are you really Agile to begin with?
Agile is not just something that organizations just “do”, it’s something that they are…or that they aren’t. Being “agile” with a lower-case “a” or being Agile with an upper-case “A” are different levels of devotion to a very fundamental concept — we don’t know what the market will want in a year, so we’ll do the things that we know are important now and adjust our priorities as we learn more about our market needs.
That’s a pretty basic concept, but it has some serious implications not only for product development teams and Product Managers, but really at all levels of the organization. Additionally, being “Agile” with a capital “A” implies that we have accepted and internalized at least the core principles of the Agile Manifesto:
- Valuing Individuals and Interactions over Processes and Tools
- Valuing Working Software over Comprehensive Documentation
- Valuing Customer Collaboration over Contract Negotiation
- Valuing Responding to Change over Following a Plan
What does this mean?
If your company claims to be “Agile” but still requires specifications that are detailed “checklists” to execute against, they’re not “Agile.” If your company claims to be “Agile” but places heavy micromanagement reporting requirements, they’re not “Agile”. If your company claims to be “Agile” but the developers never actually show stakeholders or customers what’s done at the end of a sprint, they’re not Agile! If your company claims to be “Agile” but has a detailed, specific 24-month road map that commits to features both internally and externally, they’re not Agile!
When used merely as an industry buzzword, Agile is utterly useless — just as any other trendy label that people want to apply to their organization. When used only in an attempt to get “more product features” out the door “faster” but without buy-in from the rest of the organization, “Agile” is utterly useless.
There are a great many ways in which we can set ourselves up to fail when we’re looking at a transition to “agile” or “Agile” practices — and saying that we are something which we’re really not is absolutely the most sure way that such a change will fail. Every. Single. Time.
Do you really know what you’re doing? Why you’re doing it?
So very many teams start out implementing Agile practices — especially Scrum — without actually training up or doing their due diligence in understanding not only what the methodologies expect you to do, but why you do them. This inevitably leads to people either doing things the wrong way for the right reasons, or the right way for the wrong reasons — and both are utterly deadly to any successful implementation of Agile practices.
Scrum in particular is a project management methodology. It sets up practices and principles which allow teams to know what they’re working on, where they’re at in the progress on that work, and to deliver something on-time and within a budget. Project management is not always the biggest core competency of a t team — solving problems is usually their core competency, and more often than not, project management comes in second place (or third, or fourth).
The single biggest failure that I’ve seen in Scrum teams is simply a lack of real understanding about why Scrum says to do things the way that they do. And that this is a baseline set of practices that one should try out first, and then adjust as needed to fit the needs of the team and of the organization as a whole. Any team that is considering shifting to or implementing any set of Agile practices needs to be trained by a professional before they start mucking around. And they need to start out implementing the whole package, not just bits and pieces that they like or feel comfortable with.
Half-assing an Agile methodology is no better than half-assing a database architecture — if you don’t think it through from the beginning, you’ll get bit by some fault or failure shortly down the line. All of the “ceremonies” involved in Scrum have a purpose, and understanding the “why” helps us to understand the “what”:
- Backlog grooming creates the prioritized backlog off of which work will be pulled, so that both the team and the stakeholders know what’s likely to be worked on, and in what order.
- Sprint planning creates a commitment, so that both the team and the stakeholders know what is being worked on for the next interval.
- Daily standups create accountability within the teams to demonstrate that you’re making progress and a structured time for check-in and notice of blocking issues and questions.
- Sprint reviews allow an opportunity to hear directly from the stakeholders how their work is or isn’t meeting the needs intended through the user stories.
- Sprint retrospectives reinforce internal accountability within the teams, and allow them to identify things to change and try in order to continually improve their efforts.
We don’t just do these things to do them; we don’t hold meetings just to hold meetings; we look at these things through the lens of lean manufacturing — what’s the least amount of overhead that we need to impose in order to maintain visibility and accountability in the system and achieve the most with the limited resources that we have.
Development doesn’t exist in a vacuum; development teams and their results create the product that everything else in the organization depends upon. Stakeholders, managers, and executives have to have trust in the things the development team is doing and their reasons for doing so. Scrum attempts to put a minimal amount of managerial overhead in place to ensure that the teams remain self-organized and focused. When these practices are abused or twisted into micro-management controls, Scrum is destined to fail.
The Last Word
These are three of the most common ways in which Agile and Scrum teams wind up shooting themselves in the foot before they even start working within the frameworks — making the switch or implementing Agile principles just isn’t as easy as turning to your CEO one day and saying, We’re Agile now! — it takes preparation, perseverance, and understanding across the board.
I enjoy solving meaningful customer problems by utilizing the best practices of customer discovery, design thinking, and agile development methods.
- Why Agile Does NOT Necessarily Mean Fast & Cheap - February 1, 2020
- 5 Secret Hacks To Ace The Product Management Game with A Non Tech Background! - February 1, 2020
- Digital Products Are More Than Just Feature Development - February 1, 2020
