Too often engineers forget about the content of the “Agile Manifesto”. This was a well thought, methodological and professional statement. In the Manifesto, Kent and his fellows came up with the following statements:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
While there is value in the items on the right, we value the items on the left more.
I could not agree more with those recommendations. We should all read them every day before starting our workday. While I have seen few companies correctly and very successfully applying the new approach, what really shocks me is to see how many teams, not a small percentage, claim to work following Agile methodology, most of them Scrum, and are applying those principle wrong. And when I say wrong I don’t mean lightly wrong, I mean completely missing the point.
The mistake is simple; many teams are using Agile to have a justification to just stop doing any activity on the right, even though the manifesto clearly says that those activities have value, and, indeed, they don’t care too much neither for the left side (the ones they should be really focusing on). So basically they use agile to:
- Stop following processes
- Stop generating any document
- Avoid any kind of specs generation
- Almost not planning their work
When reviewing those teams, I hardly never find a well-built product backlog with its acceptance criteria, the daily scrum tends to be the daily or weekly let’s chat at the corner, sprint releases (that is working software) are a fuzzy concept, the done is done is just a fallacy, continuous testing does not exist, the customer collaboration is close to none and, last, team is rarely ready to respond to specs change.
In my opinion, Agile is the way to go, but only if we remember the main statement:
While there is value in the items on the right, We value the items on the left more.
And we do not apply the anonymous wrongly widely used:
There is no value in the items on the right (let’s just skip them), Don’t bother too much with the items on the left.
Please, ask your team what rule they are honestly applying, if they are failing on the Agile adoption, don’t blame on them, most likely they haven’t had the chances and resources to correctly adopt it. In this case Increase your support and sponsorship to the methodology transformation. Engage all the company, Executives, Marketing, Sales and Customers and try it again… it is worth the effort.
Put and empower a product owner to work hand in hand with the engineering team. If you don’t create a detailed specification, at least create a thorough product backlog. Details can be given later on, but the team needs to know the overall picture before starting. Focus mainly on the working software, make sure that you have something to test and evaluate at the end of every iteration. Don’t lie to yourself, it is better to acknowledge that you have almost nothing done than pretend to have a lot done but hardly working at all and nobody looking at it. Even thought you should, don’t write the acceptance criteria if you wish, but have somebody from the business side validating every piece of software as soon as it is ready, don’t pile up validations.
If you have an internal or external client, you need to write a contract or agreement. Expectations need to be clear from the beginning. Plan for changes and agree on how those will be handled.
In summary, follow the Agile Manifesto; It works.