Agile vs Scrum - another nonsensical battle
As an Agile Coach, my role is to help my organisation in their Agile journey. To do this, I use a whole manner of approaches, methods, frameworks, principles and tools.
Having worked with amazing Scrum teams in my time, I am a huge Scrum advocate. But - please - do not confuse advocacy with dogmatism. At the end of the day, I am method agnostic. Through learning and experience, I continually strive to increase the size of my utility belt, and I pick the right tool [sic] for the job. I just happen to think that Scrum is a bloody great tool, when used as intended*.
It follows that I am frequently baffled by passionate Agile folk roasting the hell out of Scrum. A colleague at work shared a link to a critique of Scrum, citing it as "controversial".
I assured him that criticising Scrum is not controversial. I see people demonising Scrum all the time.
Many teams feel like Scrum is meeting-heavy and slows them down. Luckily, Scrum has convenient mechanisms built in to address that. A team doing Scrum can inspect and adapt its process every sprint. If the team is feeling slowed down by their process then they can adapt their process to be nimble again, and have more fun along the way.
Truth is, Scrum, like any other method, will only work if the entire team (and, arguably, organisation, but that's a post for another day) has bought into its benefits. Scrum isn't prescriptive. No one is forcing a team to do Scrum (one would hope).
Scrum isn't your process. Scrum is a framework. Your process is... your process. It's how your team works in those 2-4 weeks to deliver working software (as per the Agile manifesto), not the Scrum ceremonies and artefacts.
My question to "agile" teams that want to ditch or not do Scrum (which, let's not forget, is deeply steeped in Lean and Agile principles), are:
- Are you having retrospectives? If not, what is your approach to continuous improvement (as per the Agile manifesto)?
- Are you having regular planning and/or review meetings? If not, what is your approach to the continuous planning and reviewing of your product? How are you monitoring progress toward your goals? How are you making all this transparent to your stakeholders? Do they know where to input into the process without a review cadence?
- Do you have time-boxed iterations/sprints? If not, what is your approach to limiting work-in-progress and reducing batch size? Where are the feedback loops?
- Do you have an ordered product backlog? If not, how do you know you are working on the most valuable thing for the customer (as per the Agile manifesto)?
- Are the next most valuable things to work on clearly defined from a customer's point of view? If not, how do you address that? How do you know when you're done?
- Are you discussing blockages and impediments to progress with your team every day? If not, what is your approach to addressing impediments to ensure free flow of delivery?
I could go on. Hopefully I've made my point :) The path to agility, particularly in large, complex organisations, is to use methods and frameworks mindfully to help all the folks synchronise around the most valuable things for their customers at any given time.
Scrum can help greatly with that, as can Kanban, Lean, Theory of Constraints, XP and other modern management approaches.
Demonising any particular method will get us nowhere. Particularly one which is consistent with Agile principles and is actually an extremely effective way of delivering value to customers while improving how this is done.
Go forth and be Agile - and don't make the mistake of thinking that Scrum cannot help you do that :)
* As the great Ron Jeffries would remind us - if you don't like the rules of baseball, it doesn't mean baseball isn't a great game. It also isn't baseball if you don't play by the rules. And no one is forcing you to play baseball.
Thanks for reading! If you are looking for help with your software or product delivery, I provide agile coaching, public training (both theory and practical) up to executive management level, and more. As well as public events, I can also run training internally in your organisation for a massively reduced cost, so please ? get in touch.
Agile Project, Product Delivery Specialist, Changemaker, Coach & Inclusive Transformational Leader
8 年Nice :) "The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge." - SH
Associate Director - L & D at SourceFuse
9 年"It is fun. You make my life miserable; I make yours. ...only yours is miserable already." - Dr Cuddy, House MD :D
Technical Development Lead - Business Analyst
9 年Brilliant article Neil! Simple to follow and straight to the point. Personally the Agile/Scrum projects I’ve had the pleasure of working on in the past 10 years have all been very positive experiences. In the cases when they did not deliver what was expected in the allocated budget and schedule, often came down to 3 things that had nothing to do with Scrum and more about project management and product development: - 1) Lack of clarity on the deliverables thus guaranteed project scope creep. - 2) A significant lack of retrospective reviews at all levels. - 3) The people skills of the Agile and Scrum teams specifically in the area of collaboration could be improved.
Customer Architect at Honeycomb
9 年I absolutely love that quote by Ron indeed.. And the latest trend is indeed to ditch Scrum for Kanban... a Kanban with columns per functional specialisation, but without any measurement of cycle or lead times in sight or even WIP limits. Or as I like to call it: "Stickies on a Wall"
Neil, thanks for the interesting article. I agree Agile vs. Scrum is a non-sensical question, especially given Scrum was one of frameworks that inspired the agile manifesto. The too many meetings mantra is a common complaint. My feedback is usually that if your ceremonies feel like “meetings” then you’ve just identified an area ripe for improvement. That being said, there’s lots of mechanical Scrum being practiced. All you have to do is go to any Scrum (or Agile) forum and see question after question like, “what does the SCRUM methodology proscribe for assigning story point to bugs?” It almost always followed by a litany of answers telling the OP about the one true way to handle the situation. To some degree this a predictable result when something becomes popular, as the percentage of people stuck (without realizing it) in Shu increases and becomes the perceived norm. It’s even more likely when the people rushing into the next big thing come from an environment where context-free recipe driven process was their modus operandi. This is not completely dissimilar to what happen when eXtreme Programming become the new hotness early in the last decade. In that environment I certainly have empathy for people who went looking for individuals and interactions and instead found themselves in a dogmatic scrum sub-culture that values process and tools. And don’t get me started about how often the often-misunderstood sprint commitment becomes adherence to a plan. All of this is routinely reinforced by an army of people straight from the 2-day CSM certification who believe (and have organizational support for) this certification is more than what it really is, i.e. a certification that you have been exposed to Scrum in a structured form. Adding to the concern is that the percentage of people in the active Scrum community that have no experience (or no recent experience) with software development seems to be growing. One of the things that attracted me to XP was the contrast with dominant project management community of the time. That PM community had a distinct feeling that a bunch of people who knew little about actually writing software felt it was their mission to tell people writing software how to do it. There are times where I get the very same feeling about the Scrum community (at least a significant faction of it). I could write an entire post just on that topic alone, in fact I did several months back https://medium.com/@LudditeTechie/let-s-get-back-to-making-the-world-safer-for-programmers-e2c6b7b30924#.g04vp5623 None of these concerns are really due to Scrum per se. I’ve had the great fortune to have been involved with those who understood (or came to understand) the ideals behind the Scrum guide and the 12 agile principles. Those teams have had, without exception, fantastic results. But if a common experience is with misapplied SCRUM (it’s usually all caps in that form), which is often very rigid, I can certainly understand where much of the “Scrum is too rigid” sentiment is coming from.