When I started into the realm of Agile in 2006 by attending my first ever certificate training course in the field (Certified Scrum Master), the majority of key players in the industry had not even heard about Scrum (which was going to become the most popular Agile framework) and had zero interest in talking about it.
As it is still the case, the lean startups with much to discover and almost nothing to lose, were the first wave to brave this new way and test the waters with them.
The initial small (yet growing) number of success stories of using Scrum slowly triggered the curiosity of the larger players in the industry and their most innovative executives finally started carving out new team out of their current structure and try to form then up into Scrum production machines.
As is the case with human nature – and we can easily track and see what they did to Waterfall framework, customizing and changing and casting into their own perspective of it – same started to happen to Scrum as their front running Agile framework.
Some turned Agile and Scrum into an excuse to take on as much risk as they liked, under the cover of innovation and responding to change. This led to much financial losses and / or worsened the mounting technical debt within the enterprise.
Some others just had implemented Scrum in names: Roles and Ceremonies were in place, meetings were happening and nothing significant was being delivered.
Some didn’t even bother themselves that far and simply used Agile-Prefixing just to sound fancy and modernized: Agile Project Manager, Agile Project Team, Agile PMO, Agile Portfolio Management, Agile Director … this did not convey any true Agile value, nor did it help them actually embrace the benefits of Agile mindset in their process for delivery of their committed work (i.e. in the best case scenarios, it did absolutely nothing to improve their case).
The Rise of the Anti-Agile
Many teams actually tried to implement Scrum and yet never truly adopted the process to the core and the existing bad habits and new ones that emerged – aka Scrum Anti-Patterns – corrupted their efforts in raising the team to a functional state and the ever growing conflicts and confusion exacerbated the old grudges among the members and damaged teams’ perfectibility and ultimately turned them into just another dysfunctional Waterfall delivery group.
Anti-patterns such as:
- Forcing the Development to pick up the work, instead of trusting them and allowing them to tell the Product Owner what they can bring into the next Sprint.
- Turning the Daily Stand-up session into a Progress Report where the Scrum Master would go one by one and ask them to report on their status, instead of allowing them to volunteer and those with actual impediments speak first.
- Sacrificing Sprint Retrospectives whenever there is shortage of time – which is always the case – because nothing is ever achieved on the action items identified, or it is hosted in such a boring way no one wants to attend them.
- Allowing for the “better developer” to monopolize the entire Sprint Refinement session by being the only one who provides estimates or comments on the complexity of stories.
- Dictating the Development on how they should do their work and what they should pick first, instead of allowing them to own the “How” part and manage themselves throughout the Sprint.
- Not including QA into Development estimates and end up “not having time to test” at the end of the Sprint and as result transferring a barrage of incomplete stories to the next Sprint and repeating it.
And a whole array of other bad habit!
Naturally their perversion of Agile and Scrum core values, and Scrum’s abilities accelerate the reputational and financial damages to many enterprise which led to either their shutdown and revert back to Waterfall or to stop their growth and keeping their role at a minimum within the delivery group.
The key contributor to these examples of failure where the incomplete understanding of the Scrum framework, Agile values and how the team should collaborate to make it successful.
The first step sets the path for the next set of successful ones
Start by answering the key “WHAT” and “WHY” questions:
- WHAT is it that your team is supposed to achieve?
- WHY you have decided SCRUM is the best framework to do it?
Knowing WHAT your team is trying to achieve, fix, create, improve or deliver, helps you to select your solution, assess its fitness for your purpose and later to measure its success in getting you there.
The “WHAT” needs a consensus among your stakeholders, from your Scrum team members to your executive management.
It helps your Scrum team to maintain focus on their target and makes it easier for you to get executive support for your Scrum team (which would translate in funding for your team, location, equipment and more)
Knowing “WHAT” you want to achieve also helps you figure out if Scrum is the correct answer to the “WHY” question.
If you are being pushed by the executive management to setup a Scrum shop because all of the competitors are doing that and the executive wants to look ahead of the game and be able to toss the words Agile and Scrum around in the executives’ meeting, then you better have a good answer for the “WHY” part or it will soon turn into “WHY IN THE WORLD …???”
If your team is going to be allowed to choose what the can do and delivery – instead having the work dished out to them to do with a fixed delivery date – then Scrum may be a good framework for you.
If your team is going to be allowed to self-manage what they do and have autonomy on “HOW” they are going to do it, then Scrum may be a good framework for you. That needs “TRUST” in your team’s ability to do that. They would most certainly not ace their way through that on their first Sprint … not even their 10th Sprint, but they should be trusted to do their best and incrementally improve their best as they move forward.
If your team is the R&D and pioneering edge of your enterprise, responsible with coming up with ideas and prototypes and testing them in the market, the Scrum would be a good framework for you.
If the only real constant in your market is presence of “CHANGE”, then Scrum’s ability to quickly respond to changing market demands and re-alignment of production activities to the newly identified target zone in the market will come handy.
If your team members come from other failing Waterfall-run projects, always behind the commitment in time and budget and scope, then Scrum’s ability in early market delivery with minimum viable products and incremental deployment, would help their morale and set them up with a trail of small but consecutive victories.
If your executives are frustrated with missing the mark in delivery of what customers are looking for at the time of their deployment, then Scrum is the framework that help you incrementally improve and eventually fix that.
How much Scrum is enough Scrum?
Now that you and your executive management are in mutual agreement that Scrum is what you want to choose and implement as your product delivery process, you need to ensure that you are going to do a thorough job of establishing Scrum and bringing it to functionality.
A half-done Scrum is as good as a half-boat … it won’t float and most certainly it won’t take you anywhere but the bottom of the river.
As the Scrum Guide will tell you, each component of the Scrum framework is designed and put in place to serve a specific purpose, without which the process will be incomplete and dysfunctional.
This covers the Scrum Roles (Scrum Master, Product Owner and Development team [which essentially is everyone else on the team]), Scrum Ceremonies (Sprint Planning, Daily Stand-ups [aka Daily Sprints], Sprint Review/Demo, Sprint Retrospective … and I would like to toss in the Sprint Refinement [aka Grooming] even though it is not an official Scrum ceremony but as useful as any other!), and Scrum Artifacts (Product Backlog and Sprint Backlog).
But as important are these components in putting together your Scrum Team and process, they are not enough to turn it into a productive, agile team. Your Scrum Team need to learn the process, and their role and responsibility withing that process and to slowly build the experience and skills needed to perform well within that context.
You would also benefit from a variety of software tools in the market to create, update and maintain your Scrum artifacts and to be able to track the work as it proceeds through the Sprint [through the Sprint Board] and as well to be able to see the trail of work that has been completed.
There are many good choices in the market such as Jira (by Atlassian) or Azure DevOps (by Microsoft) and other ones.
Agile is the Spirit and Scrum is the embodiment of your practice
Agile is an concept in the form of a set of directives as mentioned in the Agile Manifesto.
Scrum is the most popular Agile framework and being so, should follow Agile in its values and competencies in putting the focus on delivering value to the customer through engaging them in the process to respond to ever changing market demands, while keeping it lean and to the point (i.e. create and maintain just-enough documentation that your team needs).
In order to dig deeper into the Scrum and its components, I would recommend you to go where the keepers of the flame are holding the lighthouse up and running at Scrum.org
In the meantime for information on best practices, esp. in Scrum Coaching, visit my blog here.
Cheers
Arman Kamran (The Agilitizer)
