Skip to Content

Closing the Loop for BPXSlam09 Phoenix

Lessons We Should Learn from in First Iteration of #BPXSlam09


Thinking back to the BPX Process Design Slam event at SAP TechEd 2009 in Phoenix, I immediately start envisioning overused clichés for high tech projects.  (Maybe there should be similar visuals for conducting one’s own project post-mortem as well, but I digress…)  Let me add to the list of clichés by suggesting:  just like a golf swing, the follow through for a scrum is as important as the rest of the project.


As a team lead and one of the event organizers working with Marilyn Pratt, here are my own observations about how we should improve the next iteration of BPXSlam09 at SAP TechEd 2009 in Vienna.


1.      Lack of methodology pre-planning led to project uncertainty and lower productivity

The organizing team for Design Slam spent a fair amount of time considering tools for this project, but not much time on exactly how the project should be run.  Marilyn and I hastily put together a plan the week before for that consisted of separate groups working in parallel covering the following topics:  . 

·        Vision & use cases (two separate topics actually)

·        Methodologies

·        Collaborative process modeling

·        User experience development

·        Business rules consideration

·        Service Implementation


The order listed above is intentional.  Marilyn and I recognized that there was an inherent workflow in the above, but that is as far as had been planned before the evening commenced.


 plan 1


Instead of the flow above, we ended up trying to run all the phases in parallel.


Most of us were not exactly sure where this project would end up, and it took us a while to gain some momentum.  We, the project organizers, need to give some careful thought about what additional preparation should be completed ahead of time for the Vienna iteration. 


2.      Vision & use case development were dependencies for everything

You don’t have to be Nostradamus to guess this ahead of time – the lack of story and use cases caused significant inertia for all teams.  Our teams were left milling around unsure where to start since we hadn’t thought out enough of the background of the scenario, goals, roles of players, or activities.  The organizing group for BPXSlam09 really should have fleshed this out ahead of time.


3.      It took simultanteous contribution from all teams to identify the deliverables for the first scrum

Once the story/vision team had managed to develop some background about the power plant entity, it took a conversation between Jim Davis (subject matter expert), James Taylor (business rules leader) and myself to identify a potential process that had elements of inter-role workflow, opportunity for automation, need for rules, and a consumer-oriented user experience.  This potential project was confirmed after conferring with David Herrema (collaborative modeling), and Owen Pettiford (user experience).  If the John Harrickey (model implementation) had been included in the discussion, it is likely their deliverable would have progressed further as well, and his teams’ feedback would have provided additional color to the use cases.


Ideally our methodology for the night should have dictated that vision and use case be developed before hand, and that an interdisciplinary meeting occur at the very beginning of the evening.




4.      Information Architecture is missing

As identified by James Taylor and echoed by Sandy Kemsley, there was no team considering the definition of the information artifacts of the project.  This is a huge gaping hole in the methodology.


For Vienna, an additional team should be convened to look after this portion of the project.  It will be interesting to see the collaboration required by this team in the methodology


5.  Project deliverable assessment phase is missing

Although the evening allowed for feedback from our judge, Sandy, we did not set up a means for assessing the state of the scrum deliverables.  Are they complete enough for purposes of the BPXSlam09, or does work need to continue?


Of course, the criteria for assessing this are totally different for this event than would be for a true business case. Our participants are doing this for fun and their own personal education.  Questions to assess this include:

  • Is there more work that participants think need to be done on their deliverables?
  • Are they willing to continue this work, or would they rather work on something else?

The interest and availability of project members will be the determining factors for which parts get refined in the Vienna scrum and which get left behind.


Nevertheless, we did not build this assessment phase into our project methodology, and will have to somehow accomplish this in the next 1.5 weeks before the Vienna BPXSlam09.


5.      Methodology feedback phase is missing


In addition to assessing the status of the project deliverables, there needs to be a clear feedback loop to assess and improve how the project is run.  This blog is my attempt to help bring in this feedback loop.


This is a lot to accomplish in the remaining week and a half before TechEd Vienna, but if we want to be true to an iterative scrum methodology, we need to be sure to follow through with the ending-cycle phases before starting again.

You must be Logged on to comment or reply to a post.
  • Nicely summarized, Greg.
    I blogged on this couple of days back Day 2 and Day 3 at teched - diversity is great, unity in diversity is greater, though nowhere as comprehensive as you did here.

    Let me add a couple of points here

    1. The largest amount of time was spent on "general" talk about the utilities industry - This was great for me personally since I learned a lot about the industry. However, there was no solution focus here - instead of quickly cutting down to bare minimum needed to get started, we kept going on "grand vision".

    2. Most of us were new to each other, and this had a great impact on productivity. I realized that despite being the best in the field, we cannot bring together a bunch of people just like that and have them all pull in one direction to deliver in 4 hours. I wonder if this would have been better accomplished with a traditional PM role. Or if we are more serious about Agile ways - then we need to define a better way than how we attempted it.

  • I think it would have helped a lot if we limited the scope.

    Also a gap I noticed - we worked on methodologies a lot.  What about the actual power plant?  I don't think any of our teams worked on that part of the project.   What happens when the power plant is overloaded?  When there isn't enough power generated?  What kinds of emergency measures are in place?  What data is needed to run the power plant with the customer generating the power?  We focused on the customer side of the project.

    I know I just increased the scope with that last paragraph.  I guess that's my point.  What were we supposed to accomplish? 

    I second Vijay's opinion.  Why are design slam, Incite, and developer's slam on the same night at the same time?

    It was a good exercise.  I met a lot of people in the community.  We interacted well.  We did have some cross group meetings.  It was fun! 

    • My heart's wish for the last few years quite frankly, as I mentioned in my intro to the evening.  Question would be how to integrate elements of the 3 respective evenings and have interactions without "poaching" participants.  You have no idea how deeply loyal hackers can be to their brotherhood or bpxers to their community project teammates....and yet, I am sure we can find the right formula to interact.  I am very open to suggestions for such a format.