It’s people that build products. Its’ people that write software. It’s still people that have to collaborate and iterate to create something of value. The agile manifesto highlights the fact by stating "Individuals and interactions over processes and tools". This is a reminder. We should lay the emphasis on individuals and interactions not on process and tools.
We have seen different ideas, methodologies and frameworks come up around Agile and we have learned a couple of things along the way. Agile is the mainstream way to create software nowadays. But there has also been a lot of criticism and negative attitudes towards it, to be exact, mostly against Scrum. Scrum is the mainstream Agile framework, so obviously there will be a lot of opinions, just like with every widespread tool, framework, programming language etc. Still, there seems to be a disconnect between theory and reality.
In theory Scrum is a framework that comes lightweight with a couple of role definitions, meeting formats and high level ideas on how to manage your product. In theory.
Reality seems to be different, very different actually even inside a team or company. Product owners, scrum masters, developers, managers, everyone seems to have a different experience or opinion about Scrum. Developers seem to have the biggest issues with Scrum, read this or this for example. All posts have valid arguments plus these are real world experiences. From this perspective Scrum has failed to deliver or — to be more accurate — the people implementing Scrum have failed. Agile implemented in a fashion that lays emphasis on rituals, artifacts, burn down charts and reporting is missing the point in "being agile". This is all about process. But remember, it’s about "people over process", so what role do people play in this equation? The problem is not only Scrum obviously, it’s people. People implement Scrum. The other problem I see is that we need better answers to those problems. Somebody had or is having a very negative experience with Agile/Scrum/XP/…. What advice can we give? More often than not, it’s mostly one of the following reactions:
a. "Scrum is the only way to build Software. You’re not doing enough Scrum. You need to do it by the book."
b. "Agile or Scrum is terrible."
c. "Agile or XP or Scrum have a couple of good ideas, let’s create a new methodology that combines all the good ideas and add new ideas and rules while we’re at it."
With a. or b. being the common answers. This is exaggerated obviously.
There seems to be a lot of misconception of what Agile, agile, Scrum or XP mean. Which book is everybody referring to, actually? There are a number of excellent books on the topic and an even larger number of books full of "one-size-fits-all" approaches. Has anybody read Extreme Programming Explained lately? Still some great ideas in there. So when somebody throws in the "do it by the book" argument, maybe it would be better to say read the scrum guide or read an XP book. A lot of those experiences with Scrum, XP etc. come from external consultants or some coach or maybe somebody internally introducing an Agile framework. So we hear arguments that XP or Scrum says do this or do that, while obviously the same people making the claims haven’t read any books, the manifesto or otherwise dug deeper into the underlying fundamentals.
Is it a developers fault that she or he thinks being agile means you have to switch teams every 8 weeks or that you have to report to the scrum master during a standup? Same goes for story points, blame game retrospectives and a long list of other common Scrum problems. When a company values claiming to be "doing agile" over fostering an agile mindset than you can’t blame developers for losing motivation. And motivated individuals it is all about, remember?
... Build projects around motivated individuals. ... http://www.agilemanifesto.org/principles.html
Maybe we should point back to the agile manifesto more often. It’s sensible, it’s all about values and very non-dogmatic. It’s still valid.
We need to remember that it’s all about people at the end of the day. An experienced team of developers will deliver, given any methodology. The “Agile will solve all your problems” claim is marketing, but I guess most will agree on the fact that Scrum can be a very useful introductory for transitioning into agile territory. On the other hand cargo-cult Scrum is also something real.
Here are some points I have written down that might need more thinking about. Please feel free to criticize or extend in case you see something missing or let me know wether I might be wrong on one or the other aspect.
Which book should people refer to, when being asked to do it "by the book"?
Either stop claiming that it has to be done "by the book", or give the team a chance to understand the underlying fundamentals. Does everyone involved even know what "by the book" actually means?
What role does technical excellence play?
XP has a strong focus on this aspect, while Scrum has a very strong focus on business. Scrum without the technical excellence aspect can be less effective for example.
More focus on Developers. A lot of "Agile" books speak to management.
I have seen this in a couple of posts and books. Developers are as much a target audience, as are managers, scrum masters and product owners.
No wonder, no ones interested in understanding the underlying fundamentals. Speak and write to developers, onboard everyone.
What does the team need?
Again, same point as above. People over process.
Every developer is different, every team is different. You will need the right scrum master, consultant for the right team. More often than not, somebody is selected to become a scrum master, lacking skills but having a certificate. We can do better than this.
Too much focus on the easy parts
Artifacts and meetings are the easy parts. Organizing a daily standup is the easy part. But this is where most of the focus is on. Did we timebox this? Do we have the post its? etc.
The hard parts are people collaboration, understanding how the craft works, how to ensure that everyone can excel technically, bringing in users early on etc. It’s all about people. People building products for people. You can’t learn this in a 2 day workshop and you can’t understand this without having worked with or have been part of performing teams for some time.
Stop using the "This worked for X — so it has to work for Y" argument
This is a classic. Goes hand in hand with the two previous points.
Confusing arguments. Contradicting advice.
"We’re not estimating time. But if the story has 13 points we need to break it up as it would take more than a sprint to implement it." Add measuring velocity based on those story points. What now? are we estimating time, features or complexity?
Working Software is a metric.
Why the step back to introducing reporting-like metrics, see burn-down charts for example? Working Software is a metric.
Originally published here on Jul 19, 2016.
There is a lot more that can be written on the topic. This is just a starting point. If you have any feedback or questions please connect on twitter.
Top comments (0)