Richard from AgileCommons.org left an interesting comment to one of my Agile/Scrum/PM posts that I think is worth discussing. I agree with some of what he said, but of course, the interesting parts (IMHO) are where we don’t agree!
You can see the whole comment in the link above, but I’ll pick out the salient parts here. Richard starts:
Scrum’s key value is most definitely NOT in its definition of roles to support a development methodology.
Agreed on this point, the value is not specifically the roles, but for software companies trying to implement Scrum, implementing the roles, such as Scrum Master, Product Owner etc. and processes that make up Scrum are key.
And what I’ve focused on is the Scrum team’s interface role — Product Owner — and it’s relationship to Product Management. There is a lot of confusion in both the Development and Product Management communities about how best to enact this role.
Its genius is giving all of us business veterans a lighter, more realistic project management framework that recognizes results improve when you break large, long projects into short iterations that inspect and adapt along the way.
While I agree with this, the notion of breaking larger projects into smaller tasks is hardly new, nor unique to Scrum. I think my grade 3 teacher taught us this principle, but it is enforced much more strongly in Scrum through the concepts of stories and iterations. The other, and in my opinion, more important differentiators from other methodologies are:
- the daily tracking of both group and individual progress, issues and interactions so as to minimize lag time between when a problem is identified and when addressing it begins
- the tight-coupling of teams such as development and testing during iterations to keep the process moving forward
In fact, given the code and functional interdependencies that are a natural consequence of any software development project, for tightly-coupled teams to work hyper-efficiently, they MUST resort to daily tracking and conflict resolution.
This adaptive approach works equally well for planning a trade show, writing a whitepaper or burning down your backlog of sales tools.
Well, yes and no. Virtually all projects are broken down into smaller more manageable and measurable tasks. When writing a whitepaper, one might break it down into smaller steps such as initial research, initial draft, first edit review, updates, second edit review etc. But in this case, unless there are several people writing and editing the whitepaper simultaneously, there is no “scrum” to speak of and the benefits of Scrum don’t come into play.
I would argue that trade show planning would be similar. While again there is benefit to identifying smaller, more measurable tasks, a lot of the tasks are completely independent from one another — e.g. booth design, giveaways, demo and script preparation etc. — and all have to be done by certain dates but are not directly interdependent. i.e. these are loosely-coupled tasks. If there is no tight-coupling of teams, the value of Scrum is diminished though not eliminated.
Dean Leffingwell says it best in his “CIO Playbook:”
Know where you are every day with Scrum
– or –
Think you know where you are on your well-formed plan
and discover that you are very wrong, very much later
There is a bit of religiosity entering the discussion here. No project tracking mechanism is entirely accurate. And any process can be executed on well or poorly. I’ve seen many projects executed and tracked well via non-Agile/Scrum methods.
Scrum does — as I said in the first post on this topic — “provide potential for greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.” But there are no absolutes here.
Scrum is not a panacea. And while it can likely be applied to other domains than software development, the current focus of the Agile Alliance and certainly that of the Agile Manifesto is on Software Development. And for good reason.
Software projects are very complex. The final result — “the software” — must be flexible, scalable, secure, robust etc. It must work. There are a lot of dependencies and unknowns that must be resolved as part of the software development process. Those dependencies can be in the software code itself, interaction with 3rd party software or hardware, and under conditions that may be difficult to plan for and test. These dependencies and complexity can only be minimized with constant vigilance and communication. This is why Scrum is suited for software development.
Other tasks that don’t have the complexity, level of dependency, or unknowns that software development has, will not benefit as much, and sometimes not at all, from Scrum-like methodologies. Ask yourself, could HR go Agile? 🙂
Given adaptive management approaches are better than predictive methods whenever you have unknowns, the rest of the business absolutely needs to “bend and accommodate.” If development is finally able to deliver customer value faster, what is preventing your company from experiencing the revenue gains? Is it because Marketing can’t adapt to the new pace? Support? Sales? A lame install & update process?
Put it another way, if your #1 competitor is consistently delivering new features in half the time you are, how long do you think that is tenable?
So here’s where the crux of the problem lies. It’s an engineering centric view of the business. As I read the paragraph above, I can’t help but think a few things:
- Richard is an engineer given the snarky comment about Marketing and the comment about “lame install process” (no offense intended Richard if you are not an Engineer)
- The air of superiority I hear from many Agile advocates over other project tracking methods reminds me of certain political or religious campaigns. Lower the intensity level folks!
- Customer value is about more than just software features sooner. If Development can work faster than before, that doesn’t mean the market or customers are ready to accept product every 4 months vs. every 6 months. Engineers seem to often forget this unfortunately.
- As for competitors building software faster…that has little to do with methodology. My #1 competitor may be twice as big as me (or twice as small!), or their quality may be half of mine, or their feature set is built on a house of cards, while mine is built on a solid architecture. Velocity, to use a Scrum term, is important, but it is only one aspect of what the business needs from the development organization.
- I’ve never seen a Development team that can deliver product faster than a Marketing team can put together and execute a launch plan. Seriously, is this a problem that Scrum needs to address?
Agile may have started out as being about development, but it’s quickly becoming about the whole enterprise.
As I read this last line, I’d like to agree, but the following line comes to mind:
To a hammer, everything looks like a nail.
There are aspects of Agile that can be used or adapted to areas other than software development. And if other teams benefit, then more power to them. But there is little evidence that the “Agile Enterprise” will emerge in the coming decade any more than the “Real-time Enterprise” emerged in the previous one. I may be wrong, but those kinds of changes, if they happen, take a long time and a lot of effort to enact. To paraphrase myself:
Change is a process, not an iteration. 🙂
Saeed