Captain obvious: I didn’t capitalise “agile”. Several reasons for that, but mostly because I’m one of those people that loudly agree with Dave Thomas. Agile is dead. Dead and buried. A couple of years ago I gathered some colleagues, lit a few symbolic candles and uttered a prayer for Agile.
Both Agile and Scrum have grown from a few simple principles into a whole market that sells certifications and memorabilia which eventually ended up into something akin to a Church. Speak “Agile” and you’ll have a thousand zealots at your doorstep, each having understood something slightly different but each entrenched enough in their belief to wield the appropriate torch and pitchfork. This is why, in my humble opinion, Agile is dead.
Instead, however, I am fully confident in a “spirit of agility” of sorts that can be achieved and which may help bridge the great divide between development and product while keeping the fun in all of product design, development and delivery while putting a smile on a customer’s face in a way that even plastic surgery couldn’t.
Before we move further, brief disclaimer: I’ve worked as a Scrum Master for a little over 5 years, adhering to the teachings of Ken Schwaber’s Scrum.org and having been coached by Jerónimo Palacios as well as Leonard Greene (who falls under ScrumAlliance teachings). Of the two, I greatly prefer the light touch and human approach of Scrum.org
Instead of succumbing to the pitfalls of preaching what’s agility, where’s the great promise of Scrum, does Kanban really help and so on, let’s touch a more practical subject. Since just about everyone is doing either Scrum or Kanban these days, is there a way to tell whether they are doing it right and whether they are close to the outlines of the Agile Manifesto.
To give a simple example, Scrum is an Agile framework. As such it is simply giving a practical form to the principles outlined in the manifesto. Since it’s a framework, its implementation mirrors any other framework in software. You set it up, implement its requirements and build on it. You don’t change the framework itself unless you’re doing the loop of forwarding your changes to the community, getting them approved and published.
- If you’re buying into a system then changing it — you’re not agile.
This is pretty straightforward. If you’re skipping anything from Scrum or Kanban, if you’re attaching other responsibilities to the roles defined, if you’re not building the team to cover its requirements, if you’re not following the Nexus for more complex needs and so on, you’re not doing Scrum and likely you’re not close to agility.
2. Ask yourself how the practices used in the company fit with any of the principles of agility
As a refresher, we are thinking about these:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
For example, in my current company most managers refer to their team members as “resources”. Words are important because they reveal the mindset and this mindset has a set of problems. One of them is that resources is impersonal. We may talk about desks, laptops, markers … and apparently people fall into the same category. Two markers are interchangeable but two people aren’t. If your process talks about resources (referring to people) then you’re violating the first principle. Your company doesn’t practice agility.
Also violating the first principle is any imposition of tools to define the process. Tools must serve the process, not define it. If you’re not doing something that would benefit the team or the product because a tool doesn’t support it, you’re not practicing agility. You’re placing the tool above interactions and people.
If you need a Definition of Ready, it’s very likely your team isn’t fully agile. There’s discussion on Definition of Ready that benefits from an input from Jeff Sutherland. Jeff says that he’d like to see Definition of Read as part of the Scrum Guide due to some obvious benefits. Coming from Jeff’s side of Scrum, the respected Mark Cohn details some pitfalls. When you’re following people and interactions, the team works as a whole. Backlog items would get defined according to what the team needs and expects. If you need a Definition of Ready, that shows that the team isn’t working as such and it asks for safeguards in the process. Adding safeguards encumbers the process and tries to make up for something that the people are lacking. We need to develop the people and improve their communication!
As the definition of ready is often quoted as protecting the needs of the team agains the Representative of the Customer in the Team, this helps us coming to my next point. If you see the Product Owner as a representative of the customer, then you’re most definitely not practicing agility! The PO doesn’t represent other interests. Everyone involved in the project has only one interest, which is to create a quality product that end users love. The Scrum Team is only one team and the product owner (as well as the scrum master) are part of it. Both the SM and the PO are enablers, with the distinction that one enables the process (and the team to follow it) while the other enables the actual work (with their product knowledge). There aren’t any opposite camps or opposite interests. Sure, at times you may hit the classical conundrums of “do it fast” vs “we need some extra refactoring to enhance maintainability”. Much like the above, what we have here is failure to communicate. Both are part of what makes a product delightful for users. Users want something now but they also want 100 other things, all of them fast, so in order to make good on both issues then we need to balance things out. This can be achieved by cultivating the idea of a team, not by creating divisions across imaginary opposing interests or other arbitrary criteria.
If the team is ever in a position to refuse adjustments requested by customer due to having a sprint in progress or motivating it on discussed terms, you’re not practicing agility. The main drive behind agility (and Scrum, for that matter) is the ability to adapt. If you have that ability, then use it. If you have contractual or legal issues, by all means, respect them. But when it comes to delivering software, we need to collaborate rather than enforce contracts. If the customer asks for X and while we’re working on it they ask for Y, we should deliver Y, not X. Same applies for any change, big or small. Our attitude, process, mindset must allow for it in the spirit of the 3rd agile principle. We don’t say “no, we won’t do it”, at most we can say “we’ll deliver it later so that we can ensure quality”.