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.