A response to “Agility is not enough: Beyond the manifesto”

I recently came across this article by Steve Denning and within reading a few paragraphs I was disagreeing with the majority of what he was saying and I heard echo’s of management from years past, before I become a software developer, when I worked in sales and customer service.

My main point of disagreement, and possibly what Steve got push back on in his session, is around “delighting” the customer. Don’t get me wrong I want to be able to make my “customers” happy but as a software dev/team lead I have multiple customers to satisfy ranging from immediate and upper management through external clients to actual users of the software/website who may (or may not) be customers of the business.

I’ve not gone through Steve’s points in the order that he wrote them more in the order that I was most annoyed about what he had said, I will warn you now that is an extremely long post but hopefully worth the read, if you don’t have the time you could skip to the conclusion at the bottom and my rant .

Delighting the customer should be added to definition of done

Lets start with my biggest bone of contention in Steve’s post that “delighting the customer should be added to definition of done”, I’m sorry but what complete and utter nonsense. The definition of done is a concept introduced to enable business and developers to be happy that the work has been completed which means the team can move onto another story to keep adding value to the business and should ultimately “delight” the customer.

If you added this new dimension how would you be able to work out if its been met? Steve mentions Net Promoter but just who is filling this in? if you have a web site with 100, 1000 or 10000 customers a hour/day who do you ask if they are delighted with a change? do you survey a random number asking them? do you just rely on the product owner (PO), the business stakeholder, the external client? what if there’s no visible evidence of the change at all? who decides that they are delighted over merely happy? and is being happy actually wrong?

In practice you simply cannot include something that isn’t quantifiable and measurable, there is a reason that the user stories have acceptance criteria its so that the people developing the software know they have completed the job and if in Scrum are able to complete the sprint, the side effect of doing this is most likely the team “failing” every sprint and demoralising the team, plus if you have to ask your PO or customer to fill in an online form about how they feel the story/sprint went they you have bigger problems since agile is all about communication and they should be talking to you about the story/sprint so you can have a discussion around it and work out how best to move forward, which leads me onto my next point….

Shift from customer satisfaction to customer delight

Steve says that satisfying the customer is not enough that the customer must be positively surprised and excited.

Whilst a great thing for a manager to say or a CEO to desire, it is unlikely to be something that the developers alone are going to be able to deliver.  Perhaps they are aware of some new technology that could help or if working in an enterprise environment have sufficient domain knowledge to be able to suggest some real improvement, but if working in a smaller boutique software development environment on 4-10 week projects it is very unlikely that the developers will have a sufficient level of domain knowledge to make a very meaningful contribution.

In the following articles Steve responds to comments made by KevinRoss one in particular is: “developers may suggest but the product owner decides” we seem to be back in the world of hierarchy, where decisions are based on position, rather than in the world of Toyota and lean startups where the whole thrust is not on a manager deciding on the basis of authority” and I think that Steve has completely missed the point here. The PO is ultimately responsible for prioritizing/ordering the work to be done by the team and deciding what is of the most value to the business in helping delight customers but its a collaborative process that should involve the whole team and where appropriate also include the customer, but somebody does have to make a decision and that responsibility lies with the PO or PO team (more on that later).

Steve also states that we can gain customer delight by delivering faster or delivering more value, Kevin picks Steve up on this and I wholeheartedly agree the other point about delivering more value makes no sense either, how do we determine what the customer values without talking to them? by the developers attempting to “add value” (read Gold Plating?) they could just be creating waste i.e. feature will simply be removed stopping them from delivering something of actual value.

Shift from an implicit goal to an explicit goal

The way Steve describes this sounds to me like the age old management dictation of ideals frequently pushed into employees objectives but often impossible to actually accomplish by an individual alone.

In my experience this is a very difficult thing to try and achieve and links in with another of Steve’s sections It’s the bottom line for the whole organization; what you really want is to change the culture of the company which often will necessitate a lot of pain for the business which translates into time & money hence why so few actually manage to achieve it.  The easiest way to do this is by the business taking an evolutionary approach to changing, like Kanban advocates, which will allow it to change this takes time but can save on the pain & cost.

Steve mentions Jeff Sutherlands talk in his 2nd follow up: “As Jeff Sutherland was patiently explaining in his session at the Agile 2011 conference on Thursday afternoon (as he has done for a number of years), anyone who is walking around with the infamous iron triangle in his or her head (the supposedly inexorable tradeoffs among cost, quality, speed) is going to have a problem implementing Agile and Scrum successfully” which may be the case for enterprise based development but I can tell you here and now that if you are a small software house the iron triangle is still very much an issue as clients tend to want to know a) what they’re going to get b) how much it will cost and c) when do they get it.

Contracts for development of software using an agile methodology with a 3rd party are usually fairly difficult to agree, they are not impossible and there have been a few articles about how you can go about this but unless the client is happy with and fully understands agile you are very likely to end up having discussions around the iron triangle and all the issues that entails.

Shift from an output to an outcome

I can see what Steve is saying here but can’t really agree.  The user stories that most agile teams already incorporate have this idea in relation to “As a … I want … so that…” and it is the so that which is key here, it is the outcome that Steve is on about, it is the reason for the story in the first place, it is often what is going to delight the “customer”.

The “product owner” in Scrum offers merely contingent value

I think Steve has again missed the point here, the PO is supposed to reflect the customers voice in the 2nd follow up Steve says “The idea that the challenge of figuring out what will delight the customer is the role of a genius product owner, who then gives clear instructions to make it happen, can on occasion result in customer delight, if you happen to have a resident genius as a product owner, perhaps like Steve Jobs at Apple”, I believe it is part of a PO’s job to understand what it is that users do and what they want/need to do they don’t need to be a genius to do this they simply need to interact with the users get feedback, ask for suggestions, etc. This is why the role is a full time job and why in larger organisations you may have a team of Product Owners collaborating to work out what needs to be done and on larger projects coordinating multiple teams to achieve the goals of the business.

Customer delight is measured. e.g. Net Promoter Score

I touched on this in my reply to Delighting the customer should be added to definition of done and whilst I don’t agree on it in relation to definition of done nowadays companies need to ensure that they are actively asking for feedback from their customers in regard to how they feel the business is doing but this is exactly what I was just saying about what the PO role is for and should be doing whether its customers through a website or an external client using a software development company.

Conclusion

Looking at Steve’s profile,where his blog is published and the books he has written I can see that perhaps his intended audience was not me but:

<Rant>
It is articles like this that can cause agile adoption to fail in an organisation as instead of management working collaboratively with the people producing the product/software/website they end up trying to control/dictate to the team and we are then back into Command & Control territory.

Throughout Steve’s article I have a picture in my head of a manager wanting ‘more’ from the development team – deliver faster, deliver more value, cost me less, etc not believing the "workers" care about what they do and that is not what agile is about, that is old school management & waterfall projects.

Agile was not created by managers it was effectively created by the workers, not in an attempt to do less work or deliver less value but to help their organisations to reliably deliver value and delight their customers, it even has inbuilt mechanisms to improve not only the process they follow but what they are delivering and to try and then start telling the team what they should be doing is plain and simple wrong!
</Rant>

To go back to Steve’s original topic does the agile manifesto need evolving? perhaps, anything that stays the same and never changes smacks of dogma and leads to stagnation.

Agile is, and always has been, about feedback loops and making changes in a iterative fashion; the manifesto should not be immune to change this but at the same time the changes need to be constructive and deliver value to all who practice agile development.