I came across the following two websites recently:

http://www.halfarsedagilemanifesto.org/

http://antiagilemanifesto.com/

And as is so often the case, when you have to smile about it, it hits too close to home. So I wanted to provide my perspective on these.

Let’s start with the Anti Agile manifesto (http://antiagilemanifesto.com/) – this one is just plainly ignoring the fact that Agile operates in a different cadence and requires a different structure to achieve it’s outcome. However many organisations do follow some of the points mentioned in this manifesto, where stand-ups turn into status meetings and stories are full use cases. Clearly someone who had to suffer from a bad Agile project put pen to paper here – take this as a sniff test if your Agile project is really agile. It is not if this manifesto is true for you.

The Half-Arsed manifesto (http://www.halfarsedagilemanifesto.org/) is different as it provides the challenges that many project teams are exposed to. It’s the tension between local optimisation of teams and organisation wide requirements. Let’s explore this a bit more in detail.

We have heard about new ways of developing software by
paying consultants and reading Gartner reports. Through
this we have been told to value:

Point taken – the Agile space is full of consultants, but hey so is every other space in IT. Let’s move to the next:

Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact

It is important to acknowledge that unfortunately in large organisations you do have mandatory tools and processes. Some of this you should challenge as an Agile team to get a better outcome (e.g. being allowed to use walls to post things even though it might not be “pretty”). Others are required for the sake of the organisation and should be respected. Imagine you are a senior product owner and each team is using a different tool to manage their sprints. You get pictures, excel sheets, links, etc. from your teams to understand their progress, remember this stakeholder is actually paying for your team and is making decisions about the direction of the company, don’t you want him to spend time doing that rather than digging through lots of different data sources? The term resources is terrible, I don’t think we should call people resource – full stop.

Working software over comprehensive documentation
as long as that software is comprehensively documented

I think this is nitpicking. it really comes down to what comprehensively means. In my view Agile teams need to create all the documentation that is required to use and maintain the software. Documentation that is not required in Agile projects is transition documentation that is required to get someone else to do work (e.g. detailed technical designs), they don’t provide value if the team sits together and/or talks every day.

Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control

Oh dear – this one clearly speaks to me. As someone working for a systems integrator I do depend on contracts and change control. I always aim to find a better solution, but there are commercial realities and this point is just try. Let’s find the most creative way to solve our problem while still having the required commercial framework in place.

Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely

Honestly, I am struggling with this one. Isn’t all of SCRUM based on a plan for how to manage change? And isn’t SCRUM about rigorously following the few mandatory ceremonies (at least until your are experienced enough to know why you are breaking the rules).

That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.

Yes – I am working in the enterprise world. And while everything here is a bit harder, I enjoy the challenge and bit by bit we can hopefully change the environment together. If we only accept the purest of Agile forms, we are making the perfect the enemy of the better. Don’t tell people that they are not Agile, help them get a bit better and a bit more agile.