The Rise of The Anti Agile

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.

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 teams out of their current structure and try to form them 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 teams have abused Agile Frameworks (e.g., Scrum and Kanban) 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 organizations have implemented Agile Frameworks in names: Roles and Ceremonies were in place; meetings were happening and nothing significant was being delivered.

Some organizations haven’t even bothered 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).

Many teams have actually tried to implement Agile Frameworks and yet never truly adopted the process to the core and the existing bad habits and new ones that emerged – aka Agile 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’ predictability and ultimately turned them into just another dysfunctional Waterfall delivery group.

Anti-patterns such as:

• Forcing the Development Team to pick up the work, instead of trusting them and allowing them to tell the Product Owner / Product Manager, what they can bring into the next Sprint.
• Turning the Daily Stand-up session into a Progress Report where the Scrum Master / Kanban Flowmaster 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 Retrospective sessions 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 Backlog Refinement session by being the only one who provides estimates or comments on the complexity of stories.
• Dictating the Development Team 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 iteration and repeating it.

And a whole array of other bad habit!

Naturally, their perversion of Agile core values, and Agile Frameworks’ abilities accelerate the reputational and financial damages to many enterprise, led to either their shutdown and reverting back to Waterfall or to stop their growth and keeping their role at a minimum function within the delivery group.

The key contributors to these examples of failure were the incomplete understanding of the Scrum framework, Agile values and how the team should collaborate to make it successful.

The correct first step sets the path for the next set of successful ones

Start by answering the key “WHAT” and “WHY” questions:

1. WHAT is it that your team is supposed to achieve?
2. WHY have you 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 Agile team members to your executive management.

It helps your Agile teams 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 they can do and deliver – instead having the work dished out to them to do - usually - with a fixed delivery date – then Agile Frameworks may be a good approach 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 and raise the bar on 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 Agile Frameworks’ 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 will help you incrementally improve and eventually fix that.

How much Agile is enough Agile?

Now that you and your executive management are in mutual agreement that Agile is what you want to choose and implement as your framework of choice for your product delivery process, you need to ensure that you are going to do a thorough job of establishing Agile Frameworks and bringing it to functionality.

A half-done Agile 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.

There are guidelines for Agile Frameworks that can shed light on many areas of question. For example, 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 Agile teams need to learn the process, and their roles and responsibilities 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. Some of the tools allow you to integrate the outcome of your teams' development work into your release management process and streamline your delivery machine.

Agile is the Spirit and Agile Frameworks are the embodiment of your practice.

Agile is a concept in the form of a set of directives as mentioned in the Agile Manifesto.

Today, 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 production process to respond to the ever changing market demands, while keeping it lean and to the point (i.e. create and maintain just-enough documentation that your team needs).