Nice collection of agile “objection” answers, though I’d be a bit kinder to the resisters. Turn the right ones and they’re your strongest, most effective advocates. (RT @bobsarni, HT @brown_note) Agile Doesn’t Work For…: Ever run across these guys? People whose lack of experience or fear of change cause th… http://t.co/5CrFyFAn
Last week I got a chance to tour the Mead Johnson manufacturing facilities here in Evansville, and I was struck by how firmly kaizen is embedded in the culture of our supply chain. The plants are clean and tidy, with performance and safety metrics prominently displayed. Improvement ideas are posted, the author(s) credited, and the results are made available to all.
I’ve always thought that PMs could better leverage kaizen thinking, especially when they’re IT PMs in a business that values continuous improvement. Many methodologies are out there for kaizen-inspired product or project management. These concepts are at the heart of agile, Six Sigma, lean, etc. In fact, I’m using some principles now, like using 5S to organize the project portfolio. I’m also planning to get key performance reporting visible to all.
What other approaches have you seen to introduce “project management with kaizen characteristics”? In particular, I’d like to see what has worked to promote better IT/business understanding and alignment.
Greg Balestrero — CEO of the Project Management Institute — recently posted (here) on his experiences at the Scrum Gathering in Orlando. In my experience, Greg and the PMI staff have been very eager to foster a better relationship among the various methodology camps. Per Greg’s post,
[t]he intent of the visit was to bridge the gap between the Scrum Alliance and PMI. But I guess the real reason we attended was to dispel the myths that surround the PMBOK® Guide and Agile practice. There is a widely held opinion that the PMBOK® Guide and Agile don’t mix… they can’t be “shaken, nor stirred” together.
Please read the post…it gives an interesting perspective on how to build alliances among disparate points of view and how to overcome misconceptions.
Ron Stanton sent me a mail asking how SCRUM works with our implementation methodology — ASAP for Implementation. While SAP does have a SCRUM methodology that we use — SAPScrum — it is an internal approach used for solution development. SAPScrum is pretty straight SCRUM, so there’s no mystery to it.
We just started a project to make ASAP more agile-friendly, we’re a little ways from publishing it. For now, below are a few general guidelines in using SCRUM in an ASAP environment.
- The first principle is to remember that the SAP solution(s) serves as the development platform or environment. It isn’t simply an application to which you’re integrating.
- Of course, a product backlog should be one of the outputs of the Blueprint phase. The product backlog should be mapped to the processes here (as part of identifying testing scenarios).
- Appropriate prioritization of the backlog is critical in an SAP environment. In particular, non-technical product owners often forget to include integration dependencies as one of the prioritization criteria.
- Sprints need to synch with the various ASAP configuration/testing cycles (e.g., unit test, string test, etc) for the overall solution.
- It is critical to ensure that custom development sprints are scheduled so that the sprint output delivers to the relevant testing cycle.
- Most ASAP config/testing cycles are typically 2-4 weeks long, so one sprint:one config/test cycle is reasonable. If the project is especially large — with longer config/test cycles — then consider nesting sprints within those longer cycles.
Thought-provoking post by Jurgen Appelo on the teleology of software projects (post here, check the perceptive comments too). More properly, he points out that projects do not have a goal in and of themselves. In his words, they don’t have intrinsic goals (other than self-preservation).
For me, this insight points to the limits of self-organization in initiatives. IMO, without some degree of design — or extrinsic goals — a self-organized system (or pieces of that system) can get off the rails. There is a tremendous amount of power in emergent-friendly systems — that’s what social media is all about. For example, what emerges from Wikipedia is clearly emergent, but it has a explicit goal and with an extrinsic design model:
Finding the proper balance between design and emergence is a fascinating topic. In fact, my take is that this topic is the subtext of many of the arguments among methodology adherents — waterfall vs. agile.
I’m always a bit leery of purist arguments. In fact, I have a syncretist’s instinct to “square the circle”. Perhaps what I’m looking for is something like Deng Xiaoping’s modifications to traditional Marxist dogma… How about “Waterfall with Agile Characteristics”?
Or maybe I should say “Methodology Scaling/Selection Graphic”… Glen Alleman’s recent post on PM and Agile (here) reminded me to post this picture (click to enlarge) of a slide we use when discussing which methodologies to use for which project. Note that we do not directly oppose “Agile” vs. “Waterfall” in our continuum. Sure, SAPScrum is pretty pure agile, but that doesn’t mean that ASAP doesn’t contain agile concepts (e.g., emphasis on iteration short cycles during the Realization phase).
Also, we’re emphasizing that initiative leaders must be comfortable combining philosophies when implementing solutions, which is why we’re driving program management knowledge out to our general PM community (as implied in the bottom box).
I don’t know why I think of Glen’s efforts to reconcile agilests and PMs in religious terms. Maybe it’s because many in both camps see topics as either/or — either you’re with us or against us. Or maybe I worry that it’s a hopeless cause (which is why St. Jude graces this post).
There’s not much I can add to Glen’s latest: If I’m Doing Project Management Right am I Agile? To me, this question is not either/or, it’s both. The worst misconceptions are around planning (especially the schedule), per Glen’s comments on the Agile Manifesto tenet”Responding to change over following the plan”:
The notion that plans (schedules actually) are developed and then fixed is nonsense on any practical project. There are no doubt projects where this is the case. But it’s still nonsense. Anyone suggesting this is good project management practice is either selling you a bridge or seriously misinformed about how projects are managed.
Plans – the strategy for the successful completion of the project, and the schedule – the sequence of work needed to fulfill the strategy are subject to change for every imaginable reason.
I wasn’t quite sure what to make of this post by David Schmaltz (here). I got to the post via a post by Glen Alleman on earned value, but David’s post ended up having little to do w/ earned value.
In particular, he used developments at SEI and in Agile to lament the perversion by the “suits” of what “trailblazers” and “pioneers”. A common enough complaint by pathfinders — e.g., Martin Luther wasn’t looking to create the “Lutherans” when he tacked up the 95 Theses and Karl Marx wouldn’t have been too happy about the various mutations of “Marxist” thought (Hoxhaism and Juche are my favorite deviations).
However, a couple of David’s examples don’t ring true:
- The creation of the Agile Manifesto (and Agile Alliance) seems more like a “suit” activity than a “trailblazer” or “pioneer” activity. After all, agile methods had been around for a while already. To my eye, the Snowbird meeting looked more like the First Council of Nicaea, where the early Christian Church came together and came up with an agreed upon creed.
- David mentions SEI has two factions — one of which he considers trailblazers and pioneers. These are SEI founders and principals who believe that their original intent had been compromised by the “suits” who showed up. Fair enough. But if they’re truly still trailblazers and pioneers, why are they still w/ SEI? Wouldn’t they have moved on to the next adventure?
They’re picking up on a couple of themes we’re into at SAP. Jeannette Cabanis-Brewin notes the increased use of social media in the project environment (here), which we already use in large parts of SAP and are expanding into new areas this year.
We also use Scrum to shorten the cycle time of our strategy management processes, so it was interesting to see that Karen White has started blogging on agility (post here). In particular, she has been looking at using agile principles outside of the software development environment. Karen has a new book out on the topic (press release here).
Filed under: Leadership, Organizational Change Management, PMO, Program Management, Project Management, SAP, Strategy Management | Tagged: agile, Jeannette Cabanis-Brewin, Karen White, PM Solutions, SCRUM, Strategy & Projects | Leave a comment »
Glen Alleman shoots down some of the common misconceptions about the relationship between the PMBOK Guide and agile principles (here). As regular readers know, I’m sympathetic to agile approaches, I’ve found them very powerful in the right project context, and I push to incorporate agile principles further into our own content.
Of course, if I commented on Glen’s post itself, I’d be writing “ditto” or “I agree” a lot, so I’m just going to add on a bit:
- While many agile advocates over-read the PMBOK Guide, the guide did imply a waterfall approach, especially in earlier editions (Chapter 2). I can understand the confusion or over-reading.
- The pending 4th edition does have a more sophisticated treatment of project life cycles and explicitly addresses iterative relationships among project phases. It is hardly sufficient, but it is heading the right direction.
- PMI itself is quite eager to engage agile advocates for future editions (or extensions) of the PMBOK Guide. Several Global Corporate Council members were approached about how and whom to engage in the agile (or agile-savvy) community.
- My take is that creating an Agile extension to the PMBOK Guide would be the best initial approach. If nothing else, integrating agile-oriented PMs into the standard-setting process should be easier in an extension project.