Top 2 Reasons Your Agile Sucks

For approximately the last twenty years, most software development teams have tried to become "Agile teams", have touted being Agile teams, and have recruited based on needing SCRUM and Agile experienced developers.

Feedback I have received from many software developers (brought into focus at the Michigan Technology Conference (MITechCon)) is that not only are many Agile implementations equally struggling but that they suffer from two main components that could use improvement.

#1. BUY-IN
As almost a non-issue or throwaway mention, every Agile training I have attended mentions briefly that Agile is a methodology that requires buy-in at all levels of the organization. It is mentioned every time because it is absolutely crucial to success that every member of the team know what the goal is and how to get there. Everyone in the organization needs an agreed upon definition of what Agile development means and how to achieve the best outcomes.

Ask these questions:

Are we implementing structures that make sense for our team? Do Daily Stand-ups make sense? Are retrospectives and refinement meetings productive?
Does middle management have the same definition of what Agile means as the developers do? Is a story point definition agreed upon? Are Sprint goals reasonable, achievable, and enviable?
Is the current Agile structure more focused on the measurement of story points than on our work outcomes?
Are we just running mini-waterfalls?

With the introduction of the PI Planning process from SAFe Agile - it seems the needle has moved back to a rigid waterfall process that is AINO (Agile In Name Only). The software development process and decisions are being even further abstracted from the customer.

So, how do we solve this?
As previously mentioned, it begins with agreement on what Agile means for your organization and how that is implemented. One of the key components of this implementation is that it shouldn't be from a cookie cutter presentation or in a vacuum. Your organization has unique individuals, unique principals, and unique goals. Leadership needs to evaluate the capabilities, competencies, and targets and set up every team for success based on those metrics which will likely vary by team and leader.

#2. Synchronous Work

For the majority of Agile teams I have encountered, the focus of the Agile methodology is on having meetings. SAFe Agile highlights the Agile principle that the most effective communication happens face-to-face. SAFe then makes the supposition that more face-to-face communication is necessary for success. Meetings are the death of productivity in a software development team. Checking boxes to say you're "doing Agile" is not as important as your product or your customer.

Meetings require synchronous "work" which is, by its very nature, less efficient. "This meeting could have been email" is a mantra that should be adopted by every team to increase the amount of cycles that software developers have developing software.

Example Agile meeting schedule:

Daily Stand-up (targeted to be 15 mins)
Sprint Review (2 hours)
Sprint Planning (4 hours)
Sprint Retrospective (2 hours)
Backlog Refinement (3 hours)

Even if those time boxes are kept, 13.5 hours of meeting for a team for every Sprint. Put another way, that is almost 35% of your available development time being spent talking about development, talking about planning development, and talking about having done development.

That math only holds true if the following assumptions are true:

Daily Stand-ups are kept to fifteen minutes
No other meeting runs beyond the allotted time
No prep or post-mortems are needed for these meetings
Context switching doesn't have a cost

Any software developer can tell you that none of these assumptions are valid.

So, how do we solve this?

No team should allow a SCRUM Master decide how to develop software and obtain the best outcomes. Your team should back into the best cadence for meetings and the most effective communication style from how your team can develop the best software.

Leaders need to answer the following questions:

Is your whole team participating and gaining value from every ceremony?
Is every ceremony enhancing the software development process or are there specific meetings that are standing in the way of success?
Has the team become a servant to a prescribed process or are they driving a process toward better outcomes?

In conclusion, hopefully this article can help to guide and drive a better process inside of your organization by highlighting some of the popular pitfalls of today's Agile implementation.