Agile stories, architecture, and religious processes

In his article titled “Stop Telling Stories“, Jim Bird highlights many points that have always made me uncomfortable about agile user stories, as well as describing how their usage came about. For those who are not aware, user stories are intentionally short description of what a user needs out of a system and why it is needed. Instead of detailed requirements for a system’s feature, they are often a short sentence that is then used to elicit more detailed information from a user (or product owner, but there are some concerns about “product owners” as well).

The section about “Don’t Get Hung Up on User Stories – Do Whatever Works“, addresses a particular case of one my generic pet peeves: blindly following what some experts/process tells you is the right thing to do as part of your process (see my blog entry “Culture eats process for breakfast“). I especially liked the quote in the referenced blog entry:

“stories are not enough. They are just one tool, a usage view. There are so many more options”
(Scott Ambler, Agile 2013 conference)

A process is not a religion, you are allowed to adapt it to your own culture and environment, and it must be subject to constant validation, just like it is stated in the last agile principle (which I still think Wikipedia got slightly wrong…) – regardless of what your guru/consultant/spiritual adviser tells you!

The other undertone of that blog entry is about the completeness of the product requirement if one only looks at user stories. Users stories can help you elicit the users’ needs (although you still have to be careful to differentiate their needs from their wants…), but it is not the whole story. How do you address non-functional requirements in user stories? How do you address existing architectural constraints? Note that these are not limited to user stories, but many of the agile (or “Agile”) processes, except for the Scaled Agile Framework, sometimes seem to ignore this. I would also recommend you read Philippe Kruchten’s take on Agile Architecture for a very opinion on that topic!

It’s good to see that in these cases of quasi-religious adoption of processes, there are still some critical thinkers out there!

Advertisements

Culture eats process for breakfast

Éminence Grise has a great posting with the same subject line as this entry (in fact, he has a bunch of great posting…). I am taking the liberty to extend his discussion in my own forum.

This discussion relates to a keynote address  by Henrik Kniberg at the Paris Scrum Gathering (2013.09.23). I have not had the chance to see the keynote in person, but the presentation is very informative – I wished I could have been there in person.

Nevertheless, the content of the PDF presentation was very good and interesting. I would almost say that it should be required reading by process implementers, but they may not like the content (;-)!

My take on this is that people, especially process implementers (read: management) always forget that there is already a process in place, an undocumented (sometimes) one based on the culture of the organisation. Once you understand that, you also have to realise that there is a process to change the process, and forcing a process upon a cultured organisation is not the way to do it! What we need then is (dare I say it) measures and feedback (a.k.a., retrospectives).

I have been through a work situation where a decision to impose a development process led to a failed regulatory inspection – a failure that could have been avoided if we had started from what was there. Imposing a process into an existing culture (and there always is an existing culture) will only create problems,

The Agile Manifesto had it right, but even agilists have a tendency to push their formalised agile “process” (e.g., XP, Scrum) and you are not doing it right if you don’t follow the rules!

Many have a tendency to only look at the manifesto and to skip the underlying principles. But we especially can’t forget Agile principle #12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We must remember that this is the basis of any work going forward – that it is where we must start to document our culture (a.k.a., our process 😉 before any new process is considered.