PMI and Agilests?

Cats and dogs, living together...

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.

Using SCRUM with ASAP

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.

1. 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.
2. 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).
3. 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.
4. Sprints need to synch with the various ASAP configuration/testing cycles (e.g., unit test, string test, etc) for the overall solution.
5. It is critical to ensure that custom development sprints are scheduled so that the sprint output delivers to the relevant testing cycle.
6. 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.

New Strategy & Projects Blog

I’m a regular presenter at the Strategy & Projects conferences, so it was good to see that the folks behind this have joined the blogosphere.  The PM Solutions Strategy & Projects blog is here.

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).

PM Quote of the Day — Tacitus

All enterprises that are entered into with indiscreet zeal may be pursued with great vigor at first, but are sure to collapse in the end.

Keep this quote in mind when trying agile or iterative development for the first time. There’s a great temptation to be all “gung-ho” during the first sprints of one’s first projects. But agile puts more of a premium on consistent, repeatable execution than one might first imagine.

Because the idea is to go through repeated iterations, agile approaches can burn out teams if a team starts with and tries to sustain a “heroic” pace. Select and work your sprint backlog judiciously!

Good testers = crap code?

Fascinating phenomenon noted by Kevin Rutherford at Silk and Spinach (post here).  As he notes in his original post (here), a good tester (or testing team) can tempt developers to outsource all quality management to the testers.

However, because this is described as an “agile” project, I’m curious: What flavor of agile was used?   It sounds like that the “bad code” developers were throwing code over the wall to their tester, which seems like a parody of a waterfall life-cycle. 

The lack of details leads me to wonder how well the poorer-performing team was organized and led.  Per Kevin Schlabach’s comment, I’d expect that testers would be in the sprint team already.  That sounds like pretty standard practice.  I wonder about the team dynamics as well.  Lots of questions on that point:

1. Where there interpersonal issues?
2. How short were the effective iterations?  In other words, did the poorer-performing team behave more like a waterfall team, waiting until the last possible moment to turn over code (or did the tester only accept code at that last possible moment)?
3. Implied in Kevin S’s comment are questions about the relative strengths of the sprint/iteration teams.  If the business team was working closely w/ developers, how did the tester end up testing so much crap code?