There are Good Agile teams and there are Bad Agile teams.
Building great software depends on a commitment to excellence and continued improvement. Therefore, it is critical to closely examine what separates the good from the bad so we can identify gap for improvement in our own teams and organizations.
Good Agile teams put their primary focus on outcomes.
Simon Sinek has a fantastic book that I believe sums this up called Start With Why. At its simplest form, start with a purpose, understand how to achieve that purpose, and lastly define the tasks needed to accomplish those things. Why > How > What. Great teams and organizations think and act in this order. This approach removes process for the sake of process. It provides a valuable mechanism for decision making by allowing all tasks and approaches to be accountable the question: Does what I’m doing achieve the vision and purpose of what I must accomplish?
This is very clearly spelled out if you read through the Agile Manifesto or the Agile principles. There’s no mention of process or meetings or user stories. Instead there’s mention of valuing people, communication, and shipping products that are of value. There’s a vision, and guidance on how to achieve the vision. The task-level process that was inspired by the manifesto and its guiding principles was meant to provide a framework for achieving this vision of creating better software. This resulted in frameworks such as Scrum, XP, and the more recent additions of using Lean principles such as Kanban, or hybrid approaches like Scrumban. Good teams use these tangible process frameworks to fulfill the less tangible goals articulated in the Agile Manifesto and its guiding principles. As a result we’re seeing better products in greater volume and faster output than ever before in history.
The switch from good to bad occurs when the process shifts teams towards blind orthodoxy, which allows us to define the bad agile teams which plague software organizations:
Bad Agile teams focus on orthodoxy to process rather than commitment to outcomes.
Bad agile teams put their primary focus on what they do at a task level and don’t understand how it relates to outcomes they wish to achieve.
If we focus on product delivery from a perspective of checking a series of meetings off a list we’re not actually accomplishing anything other than saying our team attended a series of meetings. Meetings such as Sprint Planning, Daily Standups, or Retrospectives are not worthwhile when they become separated from the outcome of achieving the guiding principles of agile development.
When process is not guided by a higher value that is outcome-driven then process quickly becomes corrupted with subjective approaches to each team.
Process for the sake of process is nothing more than management theater, in the same way that project management certifications for the sake of job compliance does not encourage deeper learning.
From startups to the Fortune 500, here are just a handful of examples I’ve seen in the past few years of subjective implementations to agile that have had catastrophic results:
- Keeping the DSU to a strict prescribed 15 minutes, but failing have enough communication to achieve a Sprint goal because more clarity is needed to be defined between the product owner and the development team
- Running Agile meetings, but keeping team disciplines such as UX, QA, and Engineers silo’d rather than cross-functional
- Great sprint planning discipline for the short-term, but with longer-term release planning discipline
- Not respecting the burndown of the team and forcing scope creep
- Including all team roles with the exception of dedicated QA resources in favor of saving money and hoping the business stakeholders can do effective QA
- Leaving out continuous integration
- Skipping Retrospectives to reduce time in meetings and hoping that email recommendations from management vs the team will force incremental improvements
All of these examples happened in organizations that wanted to be Agile. They really did have some vague goals of seeking to improve how they build software. However, all of these organizations had one thing in common. They were forcing agile to be adopted as a set of tasks to be done rather than a set of goals and principles to be achieved. These tasks quickly shift to mirror the strengths and weaknesses of the organization and its people, and great outcomes are still out of reach.
What are some examples of how you would define Good Agile teams vs Bad Agile teams?
