In the Clouds

Last week I attended the Federal Cloud Camp in Chantilly VA. This event had over 150 people attending. It is an un-conference with people from the audience able to propose a topic for discussion. Over the five hour conference there were 5-6 five minute lightning presentations from the sponsors and then three time slots with four rooms being used = 12 presentations from the participants. Yours truly lead a session on "Failure to Launch - lessons learned from early experiences in Cloud Computing". I will post a seperate blog on that in a few days. In addition to running my session, I attended a session on Hadoop / map reduce and one on applications for the cloud.

I heard some discussion over exactly what Cloud Computing is, comparing and contrasting with SaaS, Utility computing, Grid computing, and Autonomic computing. I believe most agree that Cloud Computing has aspects of all these plus the characteristic of server transparency to the application and user.

The Hadoop session had some users who were experimenting with the technology. For example, one individual from DOD had taken 23 Playstation3 and was running map/reduce between the systems and also on each of the cell co-processors. 

During the Cloud applications session there was a lot of discussion about how to improve applications. One speaker thought having stateless applications improved portability wihile another thought that middleware could manage state transparently to the application.

My general observation is that Cloud Computing is still embryonic with a need for standards developed to allow application transparency accross Clouds provisioned by different vendors.

The Pampered Pooch

Last night I joined a crowd of 18 at the Agile RTP group, which was not a bad turnout considering it was election night. We were there to participate in a "59 Minute SCRUM" facilitated by Bob Galen of RGalen Consulting Group. After a 20 minute levelset on what SCRUM is, we divided into three teams of six and elected a Product Owner and Scrum Master. The goal of the iteration release was to deliver a compelling brouchure of high quality for a Doggy Spa called the Pampered Pooch. We had a existing product backlog of approximately 20 user stories. The timeline of our iteration was as follows:

Iteration Planning - 10 Minutes
Sprint Day 1 - 10 Minutes
Daily SCRUM Meeting - 5 Minutes
Sprint Day 2 - 10 Minutes
Sprint Review - 14 Minutes
Debrief - 10 Minutes

Our team of six members had someone with a laptop and wireless access to the printer where we were meeting. While other teams were hand lettering, cutting, and pasting. We were able to produce a polished look feel. Unfortunately, the mechanics of going from several copies of rough draft to one editor caused us to log jam and not have all the content delivered on time.

So besides the fickle nature of modern technology what lessons did I learn about Agile?
1. Achieving the right tempo of working seperately and then coming together to coordinate is critical. On a real world 2-3 week sprint the daily standup may be the right tempo but I would not preclude adhoc meetings for bringing people together for a focused purpose.
2. Having a flexible Product Owner willing to change direction based on what is being discovered is very nice to have.
3. When the team gels and works well the feeling of accomplishment is terrific and exhausting.

All in all, an enjoyable evening at aRTP.

Innovation

I have been working with a client that is improving an existing innovation program. Based on my prior work at IBM (where innovation has been a mantra for several years) and in my work on the Web2.0 phenomena I suggested that adding an external focus to the program would be a good thing. 

Examples are:

Procter & Gamble Connect+Develop

Kraft Foods Innovate with Kraft

IBM Innovation Jam

All of these have some differences but the common philosophy is that customers, suppliers, and business partners can contribute significantly to new ideas.

PLUS depending on how one manages the program the participants can feel they are "partnering" and helping to change the direction your company is taking.

Some of the challenges that must be addressed include:

Intellectual Property - P&G and Kraft encourage patent protection for the participant so that a straight forward licensing agreement can be negotiated. IBM keeps the ideas very general and uses the input more to set marketing focus.

Competitive Advantage - How much early development of products can be exposed without losing something to a competitor? Because P&G deals with specific ideas it prefers to keep the interactions 1 on 1. A participant can only see the problems P&G needs solutions for and only the ideas that he/she has submitted. IBM allows everyone to see ideas submitted but keeps the conversation at a high level.  I believe that an effective program should have tiered levels of participation. A general public forum and then an invitation only small group to take an idea further. The small group would be covered by a joint venture agreement.

Searching for Diamonds - A lot of ideas have to be evaluated in order to find the few that will be worthwhile developing into a product. Either a dedicated team of evaluators must be set up OR the community can vote for the best ideas. 

The trend is towards using the Internet to open the kimono and share innovation with a broad community.

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.

Color me Certified

So I took this class that results in my being certified as a Scrum Master. The class was good. Joe Little and Jim York tagged team the instruction. They both bring a lot of experience from Lean Manufacturing, Scrum, XP, and Agile Development.
Even though Jim recommended a low tech approach towards tooling (he likes cards on a whiteboard), I am interested in exploring computer aided environments. We used to call them CASE but that is a term not used much anymore. Having developed some CASE tools in my day and wanting to see how Agile could be used by geo-distributed teams I want to see what can be done in that area.
As far as Scrum itself... I like the concept a lot. From commentary during the class it seemed that there are a lot of variations in how it is applied. Since I come from a background where a lot of model content is created before code is written I want to see how a best practice team goes from User Story to Code. The book says that during the sprint the Team does analysis/design/code/test on each User Story. Are model fragments created? If so do they persist in a repository? Are they reuseful by other team members? If so, it seems that a RUP like approach is being taken with a timebox on the cycle.

SES Rides Again

Back in 1990 CGI bought the company I was working for (Yourdon) and after about one year laid me off with some of the other company leadership. My wife and I decided to stay in Cary NC so I hung out my shingle as an independent consultant and called my company Software Engineering Strategies. I helped clients with methodology decisions, and worked on a number of emerging technologies such as object orientation. Eventually this led me to a job at IBM in 1994.
Well, now I am back in a similar situation having left IBM a few months back and have resurected the old SES name and even updated the old business cards.










So what has changed?
1. At IBM I became a subject matter expert on wireless technologies.
2. The Software Engineering process is changing to a more agile process with teams distributed around the globe.
3. The internet (specifically) Web2.0 is changing the way we interact as people.

I would like to explore how these three topics can potentially converge into a next generation software development process/tool.