Monday 15 October 2018

Agile Dictionary

I've seen a couple of talks recently where people have given some interesting alternative definitions of various Agile / Scrum concepts, roles, foibles etc. One that springs to mind is Scrumdamentalist which my colleague Julian Holmes mentioned in his excellent talk Agile Methods are Dangerous. I also saw a great lightning talk in our regular Friday lunchtime slot at ThoughtWorks from Tarang Baxi, entitled The Agile Contradictionary. All of this inspired me to throw in my tuppence worth of some Agile (anti) definitions. My intention is to add more as they come along...

Scope Creep

A person who sweet talks the development team into constantly adding new things into their backlog because the original MVP that was carefully specified after consultations and an inception isn't cool enough, doesn't include their pet feature or simply because they can. Because it makes them feel important and valuable probably.

Product Moaner

A person who has the job title of "product owner" and whose job involves shouting at the development team, constantly changing their priorities and generally moaning about that they never get what they ask for. Not surprising when you change your mind about what you want so often that you can't remember what it was that you asked for.

Backlog Groaning

A common ritual amongst teams who are "doing Agile". Every two weeks the the team gets together in a room. None of them knows the purpose of this meeting or the outcome that it is meant to drive because nobody has bothered telling them. They certainly have no understanding of how this meeting is intended to make their life easier. Surprisingly, therefore, nobody in the room is interested in the meeting and spends the whole time moaning things like "why are we doing this? Why can't I use this time to do some real work?"

Handover (the wall)

When the development work on a story is done and there is no QA person in the development team (the definition of cross functional not yet having stretched beyond "UI developer", "Back end developer" and "Scrum master") to hand the story over to. Of course, it is well known in these circles that QA is best carried out by a person who is far removed from the developers that created the code. This is to make sure that the developer can't help the tester to do the testing and the tester can't let slip to the developer beforehand exactly how they might do the testing. So the handover involves moving the story on a Jira board into "ready for QA", waiting for a tester to pick it up, having a 3 days long conversation via Slack, emails and comments in Jira to clarify the context then having several more conversations over a 4 day period, most of which end with the phrase "well it works on my machine".

Irritation Manager

In the days of (widespread and openly admitted) Waterfall deliveries, there were project managers and program managers. Lots of them. Sometimes they occupied a hierarchy so deep that there existed project managers who managed nothing but project managers. When Agile came along and Scrum became a thing many of these PMs realised that their Prince 2 certification wouldn't even get them a job managing managers anymore so they got Scrum certified and reapplied for a job as a Scrum Master. Eventually many people realised that there was no common understanding of what scrum masters do and no solid evidence that they add value to any project or product. So somebody invented the job title of iteration manager. Somebody who exists to solve all the irritating things that nobody sees as their job. And to moan about the burn up not being done. And generally ask people to do irritating stuff that nobody wants to do. But at least by irritating people over those things they might get done. Which is interesting because nobody cares about or reads those irritating reports.