Did I, a passionate believer in all things Agile just commit the biggest,most unforgivable, cardinal sin – ever?
“Its not always people over process”.
Speaking out against the Agile Manifesto?
For all those who use the Agile approach, whether it be through SCRUM, XP, DSDM – the principles behind these Agile frameworks come from the Agile Manifesto. So this might seem like some blasphemous act disagreeing with a part of the holy grail that is the Agile Manifesto, but before you shun me & point to your screen shouting impostor! closet waterfallist ! Let me throw some context around my bold statement 🙂
It was last week that I rolled down to a rare & brilliant Q&A session with two of the most respected chaps in the Agile community. Dan North,the guy who created BDD & Ward Cunningham, he just happened to be one of the people back in 2001 putting the Agile Manifesto together.
10 minutes into the evening, a question from one audience member prompted this reply from Dan North:
“I find that sometimes we (Agile practitioners) can become a little dogmatic – remember the first principle of the Agile manifesto? People over process”.
As a ScrumMaster who helps organisations adopt SCRUM – I didn’t agree.
SCRUM is an empirical process.
Now what makes an empirical process work are the 2 pillars that help it stand up: Transparency & Adaptation.
If you negotiate the pillars of Transparency & adaption – SCRUM does not work.
Let me give you an example.
A new team is trying to take on SCRUM. The expert user from the business has been trained to become the new Product Owner (PO). “These every day stand up meetings are taking too much time, let’s just have a once a week meeting”. So the team place people over process, remove the daily stand up and meet every Friday for there update meeting. The SCRUM team now run through progress in their new once a week meeting.
Here’s the latest:
* 2 of the stories are stuck in a blocked status they require Ops to take action to move the story into QA
* 1 story is in progress but now requires the Front End developer to do his bit to complete the story
* 2 of the stories are in QA
The once a week meeting which has replaced the daily stand up does still provide information- but a significant amount of time has been lost. For example, those 2 stories which were blocked could have been in QA by now – Ops would have attended the stand up and taken the necessary action to move the story along. The story sitting in Progress? The daily stand up would have made it explicitly clear to the Front End dev to pick up the story.
So much can change in one day that it is vital to have the Daily Standup to create Transparency, for information to surface & dialogue to be exchanged between team members so that the SCRUM team is able to effectively respond and if necessary adapt.
We placed a person (the PO’s request) over the process(SCRUM) and it impacted the effectiveness of the team to deliver.
I should add that of course, team members should be communicating daily anyway: the de-fuzz when stories are picked up, pair programming, knowledge share and just proactively reaching out to one another.
I thought that Dan was applying the Agile Manifesto‘s “people over process” principle out of context.
I think the Agile Manifesto’s principal of “people and interactions over processes & tools” is a reference to engaging and collaborating with one another. Creating a more ‘human’ environment where developers are not isolated to a cubicle with their headphones on coding away, or Product Owners sending in new user stories through an email – but actually getting up & engaging the devs to understand what is required.
So no, I don’t think you can place people over process IF you are talking about doing SCRUM.
There are less prescriptive frameworks and approaches out there than SCRUM – but if you are doing SCRUM, you need stick to the empirical process if you want it to work.