The Perils of Prototyping

I just finished a first version of a presentation/paper on the trade offs between light weight methods and heavy methods. The light weight method is based on using an object oriented language, CRC card type discover process, and a large number of iterations between discover, build, validate. The heavy method is based on my experience with Clean room. I have not monitored enough Agile/Scrum/XP projects to capture the metrics specifically for those but it will likely fall fairly close to the OO experiences. In my Scrum Master training one of the jobs the Scrum Master performed was to insulate the smallish (4-7 developers) team from the customers. The Product Owner is the only regular contact the team has with the rest of the organization. As you can see in the paper (Go to my website and look in the papers section) my assertion is that prototypic development (and i will bet Agile as well) fails because of too many customers and developers participating in the release.

Business Inteligence

Tonight, I attended my local chapter of the Association of IT Professionals. This is a swell bunch of men and women who meet once a month to network and attend a dinner talk. This month's topic was Business Intelligence presented by Rick Styll from SAS. He is the product manager for the SAS BI portfolio. Rick covered a broad introduction to BI, the parts that struck me were the market convergence and some of his thoughts on what is coming over the horizon. As far as the convergence, he mentioned that Gartner had warned SAS a while back that there was going to be a consolidation in the market but that he had been surprised by how rapidly it had occurred. He stratified the players into four tiers:
Mega players - SAP, Oracle, Microsoft, IBM
Pure plays - SAS
Niche plays - Actuate



Some of the future trends.
Web2.0 - SAS is building a release that uses Ajax and they think a flash inerface is coming over the horizon for them.
Mobile BI - Rick says customers like the idea of a dashboard on thier Blackberry, but he does not see the use cases. In his experience, most people using SAS BI are operations types using desktops.
Visualization GUIs - new graphical formats and use of motion to present BI results.

An Agile Exercise

I am a member of the Agile-RTP group which meets monthly to share knowledge on agile development. This month we had a "fishbowl" event where Ken Auer of Role Model Software would grab some members of the audience to be a development team and hold a compressed planning session to capture and estimate a project to develop an application. I played the role of the customer and provided the problem. I asked another member of the audience (Glenn Watson) to join me and also play the role of customer.
I used a real project that the team I managed at IBM had completed for Kraft Foods. Kraft was building a kitchen of the future at their Chicago headquarters to showcase concepts of how meals would be prepared someday. They had a concept video of some of the functionality that they wanted. I showed part of this video to the group at the meeting and then Ken grabbed some index cards and asked Glenn and I what functionality we wanted in the system. We used the classic User Story format (As a I want the system to , so ). Here are some examples:

As a family member, I want the system to capture my food preferences so it can assist with meal planning.
As a family member, I want the system to capture my weekly meal plan, so it can provide a meal suggestion.
As a family member, I want the system to alert me when the meal plan violates my nutritional goals.
As a cook, I want the system to provide a recipe adjusted by my nutritional goals that I can follow, so I will be able to prepare meals more effectively.

We ended up with a dozen cards or so.
Then Ken asked the developers for each card if they thought that card could be implemented within one month. This filter was used to find epic stories that might need to be re factored.
I think that a couple cards were separated into a basic and refined version. And one card (getting recipe info from an XML source) was set aside as possibly not requiring a separate development effort. Ken also suggested that we might want to develop a basic screen navigation flow.
So I think that this left us with thirteen cards.
Now Ken asked each of the developers to vote on if a particular card would take 1,2,3,or4 weeks to complete. If there were a wide discrepancy in opinion, discussion was encouraged and then a consensus was captured on the card.
Now came the magic...

Ken said that in his experience with different team sizes he had determined a rule of thumb for productivity. He had different ranges for different team sizes up to a max of twelve members. For this project the team size was four and the range was 8-12 points per month. Since this team had never worked together before he recommended we stay closer to 8.
Glenn and I then were asked to group cards together into sets of functions we wanted developed in one month sprints with the sum of values on the cards to be approximately 8.
My logic in grouping the cards was to get functionality associated with initial setup, weekly planning, and meal preparation into separate piles and implemented in that order. Turned out with the budget we had resulted in five columns of cards. So this was a five month x four person release plan.
At this point in the meeting we had a lot of Q&A. A lot of discussion over how arbitrary the points process was. Glenn pointed out from his experience at Siemens where they had a dozen teams working agile they let teams calibrate points within the team so that trying to compare velocities between teams was impossible.
I pointed out that this had been a real project and when the dust had settled it had taken a team of 3 developers four months to get the system ready for the Kraft Kitchen of the Future. The team used Java and had some pre-existing frameworks that used the OSGi architecture to implement the embedded aspects of the solution.