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.
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.
4 Comments
