Learning some Agile lessons

Note: This post was actually written in 2012 but somehow was left in a draft mode and never got published. I think it still has some interesting points for people who are pursuing Agile.

I have just finished an engagement to help a client in their transformation to Agile practices. I will fill in some of the details below, but the punch line is that this company is doing a good job of it. The graph on the left is an assessment that I have done for the last four companies where I assessed Agile maturity. The horizontal axis is how many months the organization has been working at being Agile and the vertical axis is a measure of how well they are doing. This is based on forty-four Agile Practices that Dr Laurie Williams used to get the opinion of how important a practice was for their organization. I thought this represented a reasonable definition of what Agile was and have used it as a basis for assessment. A "perfect" score would be 220, meaning that the organization was performing at a high/sustainable level on all practices. If you are curious about these practices go here.

Anyway, back to my recent client.... After eight months they had achieved a score of 144 (Gold Star!)
How did they do it? I told them it was three things:

1. Engaged executive management - The CEO, the COO, the CTO and several lines of business executives would regularly go to demos. This showed the Teams that they were interested and expecting good work. The Teams were very motivated by this level of engagement.
2. A dedicated Agiile CoE - The Agile center of excellence had four full-time and three part-time members, who were training, coaching, marketing the Agile transformation. This level of support meant the Teams (15 teams with approximately 100 total headcount) were getting sustained assistance as they adopted the different practices.
3. External expertise - That's me! My experience in seeing practices applied at several companies, allowed me to offer suggestions for improvement.

One of the things I love about being a consultant is that I learn lots of new things when I am engaged with a client. Some of the really cool things that I learned while with this client are highlighted below.

Roadmap of Roadmaps

I had introduced the use of a Product Roadmap from Enthiosys. My client was developing software in a very tactical manner and the Roadmap helped force the planning out a few quarters. However another attribute of my client was an application architecture that created many dependencies between teams. They had already begun a Scrum of Scrums meeting for the Scrum Masters and had been tracking tactical dependencies. One day a Product Owner and I were chatting and he said it would be great if all the Product Owners could get together regularly and compare Roadmaps. I said "Sort of a Roadmap of Roadmaps" and from that idea the Center of Excellence developed and scheduled a meeting where all the Product Owners got together and did the follwing:

• Conveyed the major features in their roadmap over the next four quarters
• Listed questions, risks, dependencies and in that meeting and afterward worked that list.

Most places that I have worked the Product Owners are relatively independent from each other. At this client there were more dependencies. PLUS the company was in the process of a major investment in a next generation architecture and use of the Force.com platform. As new generation applications came on-line the old stuff needed to retire gracefully.

Sticky Point Burndown

The classic Scrum practice of tracking the sum of hours worked on for all tasks subtracted from the committed estimate (Burndown) was something that my client was unevenly practicing. Even for the burndown of our CoE Stories we had decided not to estimate task hours but measure burndown in Story Points as the user story was done. This resulted in a graph like that shown below

The problem with tracking done stories is that most of the time stories tend to have some lingering tasks until the last couple days of the Sprint. This resulted in a burndown that did not really tell us if we were off track.








One day I was staring at the Task board (we had lots of task moving daily from "To Do" to "In Progress" to "Done". The light bulb went off and I  summed up all the task cards (stickies) and each day subtracted those "Done". This resulted in a graph like that shown below.

So now we had a more granular burndown that we could check progress against. Still not as good as tracking hours but not so much overhead.

Story Capture Sessions

A couple of the architects I worked with had been exposed to XP and really liked the idea of a using a Story Capture session to meet directly with end-users and refine the requirements. During Sprint Planning or in a grooming session prior to Sprint Planning the team would review stories and select those that had good prospects for a successful session. A combination of how important the story was and the amount of unknown information related to the story were factors in deciding. In a couple of Sprints that I was observing the Team picked about five stories out of a two Sprint backlog of about 20 stories. The Story Capture Sessions were schedule to run for about two hours with 3-4 end-user types invited. Because this was an internal application being developed, access to the end-users was relatively easy. A lesson learned was to schedule well in advance so that delays did not occur during a Sprint. The Story Capture Sessions needed to be in the first 3-4 days of the Sprint (they were on a three week iteration) to leave enough time to complete the story.
During the Story Capture Session the Team would review the Story and Acceptance criteria, but mainly ask questions and draw on whiteboards.
Most companies I have worked with did not formalize the conversations to support a User Story. Most of the time, simple one-on-one meetings would be used between the BA and Product Owner or Developer and Product Owner. The danger of a Story Capture Session is that because the details are coming from end users they may not be what the Product Owner really wants based on several competing factors (e.g. functionality vs. cost). So the Product Owner and/or Business Analyst needs to attend each session and pay attention to the details. On the other hand, if the Product Owner is not sure of requirements, this JAD type session can quickly surface the needed information.

Agile Practitioner Lunch and Learn Event (APLLE)

At every client where I am engaged, I offer to run informal lunch and learn events where I will discuss just about any topic requested. This is usually after a standard training cycle and while the Teams are sprinting along. A very typical one is the role of the Business Analyst in Agile for those companies with a Business Analyst population.

So at my most recent client, the leader of the Agile CoE asked me if I would be willing to offer my expertise on a variety of topics in a lunch and learn format. No Problem. What was innovative was that we turned this into a regularly scheduled event, and began to use it to showcase some of our themes/initiatives of the Agile transformation.

We invited approximately 75 people and usually got 10 - 25 people to attend. We also recorded the event for streaming afterwards. I spoke on topics including:

• Agile Analysis
• Charting in Agile
• Common Pitfalls for new Agile Teams
• Estimation best practices in Agile
• Product Owners and the Stakeholder Network
• Self Governing Teams
• Technical Excellence
• The Agile Dance
• The Calibration Banner
• The Definition of Done
• The Role of Architecture in Agile

However, more recently we had presentations from other parts of the company that supported the Agile Teams, and from practitioners within the Agile Teams.

This form of community sharing of information was a strong way of both education and demonstrating to the organization as a whole that the Agile Transformation was being successfully executed.

Conclusion

We all learn from our experiences and I will take several of the things I learned at this client into my next Agile engagements.

Agile for Embedded Part I

I have used a number of development techniques in my career and, most recently, have taken up Agile Development as a means of rapidly building systems. However, Agile's heritage is in the development of web sites and I am currently interested in the development of embedded systems. The differences between these two require some modifications to the basic Agile techniques. I plan to publish a series of posts that describe the changes I would use.
This post is concerned with User Stories.
A User Story is a simple way of capturing the requirements of a system. It has many similarities to the Use Case as defined in UML. Both define requirements based on a consistent outside-in perspective from a User to the System.

The User Story is a single sentence in the form
As a [user role] , I can [feature] ,so that [benefit] .
Instead of the generic "user", the user role tries to identify different classes of users with different requirements. User is too generic. But Tom, Sally, Harry are too specific. When we see that Tom and Sally are customers and Harry is the administrator then the roles of Customer and Administrator emerge with separate interfaces, transactions, and requirements.
The feature  is what I want to accomplish with the system as the User Role.
And benefit; is why I want to use that feature. What value do I get from the story.

Suppose we are building Amazon.com. Then we might see user stories like:

As a Customer, I can search for something, so that I find the item I am looking for.
As a Customer, I can select an item from a results list to get more details, so I can decide if I want to buy it.
As a Merchant, I can register my business as an Amazon storefront, so I can sell my products.

So the catch with an embedded system is that the rich interaction with Users is not always present. In a "headless" system with no user interface, the embedded system depends on sensors to modify its behavior and will often send outputs to actuators. Let us imagine a thermostat as the system. I may have a simple user interface so that the homeowner can:

As a homeowner, I can change the mode of the HVAC between Off, Heat, and Cool, so that the house is maintained at the temperature I want.
As a homeowner, I can change the temperature limits, so that the house is maintained at the temperature I want.

A simple context diagram for the thermostat is shown below

The "Commands" shown on the diagram are for mode control and temp control, and map cleanly to the two user stories. But what about the "Display"? Unlike a web site where the user takes an explicit action of clicking on a link to see a new page, the display on a thermostat is always there. Or is it? That is what the Battery is doing on a diagram. Remember what the display looks like without the battery inserted? Blank. Insert the battery and the display comes on (usually showing default information) and stays on until the battery runs out of power. One could imagine a user story like

As the homeowner, I can insert a battery, so my thermostat will turn on and maintain my house temperature.

But what about the Thermocouple that provides the "Current Temp"? We use that to compare to the Mode and Set Point so that the Thermostat can tell the HVAC to turn on or turn off.

There is no natural user story involving the homeowner and the thermocouple.

My idea is to add event modeling as defined by Paul Ward and Stephen Mellor. An event is something that occurs at some point in time in the environment of a system and, for which the system should have a response.
This could also apply to the users but I think the user story format is fine for that. Below is a table that captures some of the events for this system

Battery inserted
Battery runs low
HVAC begins heating
HVAC begins cooling
HVAC stops heating
HVAC stops cooling
Temperature fluctuates

When the battery is inserted and when the battery runs low can both be determined by measuring the voltage.
We are not interested in the current voltage at anytime just these two events.

The diagram below shows the modes of the HVAC

This is a basic state diagram. If the behavior of our system will be different depending on what mode (i.e. state) it is in then using such a diagram helps separate the behavior and to better understand what would trigger the system to change states. For example the event of HVAC begins heating could occur when the system is Off. It should not occur when the HVAC is already cooling. Many events are important because they help us organize these modalities.

Finally, the Current Temperature that fluctuates is a special kind of event. The temperature always exists and has a value that the system wants to measure to determine if it should be heating or cooling and it wants to display the current temperature to the homeowner.

Events (like user stories) are intentionally abstract. As the response to the event is being analyzed one must answer how we will determine that the event has occurred. We must focus on the system boundary and look at the interfaces. Sometimes these interfaces are constrained. For example, suppose the HVAC manufacturers have gotten together and decided on a specific interface standard for status/controls. They might dictate the HVAC Status would be conveyed by a twisted pair wire with +5 volts indicating Heating, -5 volts indicating Cooling, and 0 volts indicating Off. So our thermostat could monitor the voltage and detect when the four events occurred.

So lets put this together in a user story / event table as shown below.

Conclusions
By adding events to user stories, I have introduced a means to capture requirements for embedded systems that do not have significant behavior at the human interface. This is consistent with the general approach of agile development because:

• The event/response/benefit complexity is similar to the user story and can be treated in a similar fashion in SCRUM
• The events have an outside-in perspective similar to the user story. This avoids "the system shall" type of requirement.

Stay tuned for Part II (Can Hardware be designed from User Stories / Events?)

Jeff Sutherland's Pearls

Last week I attend an Agile RTP meetup hosted at the offices of Relevance Software . I heard Jeff Sutherland speak about the "Five Problems solved for PatientKeeper". If you are into Agile then for me to repeat what he said would be redundant, and if you are new to Agile then you probably need some basic education before jumping into his talk.

However, I captured the following pithy quotations from Jeff:




1. "World domination always gets people excited". When the PatientKeeper management team was forming the company, they needed a vision of what PatientKeeper would be when grown-up. Jeff speculated that Bill Gates had a vision of owning the PC desktop. Sooo... the PatientKeeper team decided to own the mobile devices used by clinical professionals. They wanted to create a framework that would be considered the gold standard for third party medical application developers.

2. "If it is impossible show me the impediment list". Attributed to the CEO who took over PatientKeeper in 2003 and wanted the code deployed to hospitals after each Sprint. When told that the installation time was a bottleneck to this tempo, he formed the "Live by Five" program, which brought in PatientKeeper expert services to work with the hospital IT staff to make sure the installation took place by 5:00 the day of install.

3. "If Lean is all about removing waste, then SCRUM is all about removing impediments". Jeff likes to teach Lean Manufacturing to executives trying to adopt agile development because he believes that they can relate to the examples from the world of manufacturing.

4. "Is the Tango a methodology? Neither is agile". Someone in the audience asked Jeff to compare the light-weight "method" of agile with a bureaucratically heavy approach like CMMI. Using the analogy to the Tango, Jeff said that like that dance, the Agilista does not plan so much but responds to the circumstances of the project.

Agile Team Dynamics

Last night at the Agile RTP meeting we had Don Gray speak to us on Agile Team Dynamics.

The meeting was broken down to 5 teams with each team having approximately 10 people. One person was designated as the Product Owner. Each team was given a bag of supplies and an instruction sheet for the Product Owner to give requirements to the team. My team got a bag of colored paper, tape, and pipe cleaners.

We were told to construct something that was:

• Artistic
• Tall
• Sturdy

We were given 20 minutes for the exercise. The picture shows what we created.

Then Don asked each of use to take some post-its and write down what we had contributed to the exercise.

I think my set was:

• Contributed vision of "Eiffel Tower"
• Started rolling paper into tubes
• Worked in team of two specialists Roller + Taper to create legs
• Asked other team to give us balloons

Then Don told us about the Kantor Four Player Model.

During the exercise, each of the team members was contributing in one or more of the four interactions. Don asked us to classify each of our contributions. I had thought most of mine fell into the "move" category. In fact, among all the participants, the vast majority of actions were classified as either move or follow. A few Bystand and almost no Oppose.

Don mentioned that in an Agile team setup the Scrum Master should be a bystander, allowing a self managing team to do most of the Mover type activities. I made the observation that a classic problem with many agile teams is that the Scrum Master (often being an old project manager) can not help but try to take over and "move" the sprint along. Don agreed and gave some war stories from his own experience on how this can be a problem.

Other comments from the audience pointed out that the team dynamics in our 20 minute exercise did not realistically compare with a real project having team members familiar with each other and with the political / cultural context of the company surrounding them.

My main take away for the night was that in any healthy development teams these four players can each contribute something of value and that all team members should accept the presence of these roles in the team dynamics.

What is the perfect Agile Tool? - It Depends.

Within the Agile/Scrum/XP community there is a love/hate relationship with tools that support the development process. I used to call these Computer Aided Software Engineering (CASE) tools but that term has fallen out of favor. CASE is more associated with the waterfall wold the the Agile Manefesto revolted against.  There is one camp of Agilistas that will only use 3x5 index cards posted on a board in a war room. And even when considering tooling, the complexity of the tool is a major discussion point.
Last night, I attended an agile tools shootout hosted by the aRTP group. We looked at the following tools:
Zen
Cucumber
PivotalTracker
Rally
ScrumWorks Pro
Microsoft Team System
IBM Rational Team Concert
Jira/Greenhopper

Actually, the demos were given in two separate rooms and I was only able to personally see the Zen, PivotalTracker, ScrumWorks Pro, and Rational demos. From the demos and what I could see from their web sites I would broadly seperate the Microsoft and IBM tools from the rest and put them into the more complex category. However, this is because with both of these tools the vendors are attempting to cover the full development cycle and making sure at detailed design and coding they have things covered. For example, Team Concert was demoed as an Eclipse plugin with source code control, build management, real time notifications, project management features all enabled
Other tools, such as Zen and PivotalTracker tended to be more like electronic 3x5 cards with electronic boards. They did offer the advantage over a manual system of being able to automatically calculate burn down and other statistics.
In the middle of the complexity spectrum were Rally and ScrumWorks Pro because they added more project management features and the ability to integrate with other tools.

So which would I pick? Like any good consultant the answer is "Depends".

It depends on the size and complexity of the organization using the tool.
It depends on the target architecture and technologies used (e.g. one tool I did not classify above is JIRA/Grasshopper which is specifically used for Ruby development)
It depends on the level of contol over tool content needed (e.g. several tools were SaaS with concerns over security)
It depends on the sophistication of the developers.
It depends on the level of formality required of the process (e.g. if federal certification of the software is required then more traceability and reporting will be needed)
It depends on the risk accommodation of the users (Want to go with a small flexible rapidly changing tool/company OR stick with a slowly moving but more stable large vendor)

I did enjoy the exposure to the tools and we will be holding another shootout in the future.

Pampered Pooch 2

I am a sucker for a "59 Minute Scrum" hosted by Bob Galen. I had participated in one last November as documented in this Blog. Last night the IIBA hosted Bob and I was again a member of a six person team producing a brochure for the Pampered Pooch Day Care. I wanted to get another feel for the team dynamics during the sprints and to compare the results with the last session.

Here are my observations:

1. While the aRTP session was comprised mainly of programmers and the IIBA was comprised of business analysts (duh), there was little difference in the results of producing a brochure. I guess if Bob ran a session at the Pet Care Services Association the outcome might be different.

2. Before we started the Day 2 Sprint, Bob pulled the four Scrum Masters aside and told two of them to go back and emphasize the quality and completeness of the brochure, and told the remain two Scrum Masters to tell there teams to push for as much content as possible in the time remaining. The results were telling. The two teams pushing for Quantity delivered 13 and 8 user stories respectively, and the two focused on Quality delivered 6 and 4 user stories. So teams will listen to the direction of the Scrum Master. Ultimately to have a released product both the Quantity and Quality need to be good enough. So is it better to get lots of 60% quality content in early sprints and then tighten it up all at once towards the end of the iteration? OR do you push for 80% quality content and achieve less content per sprint. A real trade off that the team needs to decide based on coupling/cohesion of the user stories. If the stories have few dependencies then push for the higher quality per sprint. With lots of dependencies you need the total content present to debug and refactor.

Johnny goes to Harvard

Last weekend I attended the Deep Agile 2009 conference at Harvard University. This two day conference was put on by Agile Bazzaar, an ACM Chapter dedicated to the improvement of all things agile. Approximately 90 attendees participated in the conference and I thought that this was a very well run production. Kudos to the Agile Bazzaar volunteers and especially Nancy Van Schooenderwoert who chaired the program. 

The links above give the highlights from the events and I only want to add my own observations:

Jack Ganssle represented the non-agile development community and gave several presentations on his approach to embedded systems development. He favors object oriented development and follows Bertrand Meyer's Design by Contract process.

James Grenning was one of the original signers of the Agile Manefesto  He says he attended that event for the skiing but I suspect he had more involvement... He is a strong advocate of Test Driven Development, Pair Programming, and SCRUM. He showed all these elements to the audience but in some cases they were the regular versions without a significant embedded twist.

Russell Hill is a development manager at Key Technologies. He is an advocate of Test Driven Development for embedded and thoughout his presentations talked about his experiences at Key building a reusable set of boards for the various products Key manufactures. This system includes hard real-time behavior developed for an FPGA connected to a Motorolla micro processor handeling the UI and control logic. He brought a valuable perspective to the conference on what is achievable for embedded development using agile.

Here are my notes from a panel session:

In practice how can a HW based system be delivered incrementaly?

James - I don't do a lot of HW dev BUT "is it working?" is a good test.

Russel - Our HW is based on FPGA and has some flexibility. But boards would be developed incrementaly.

Jack - There is a lot of religion in agile.... HW tends to be late and broken.... and we don't anticipate that for SW

Do you expect to modify an embedded system on a 2-3 week sprint cycle?

James - would like visable progress without neccessarily being deliverable

Russel  - Key Technology can turn around a HW change very rapidly (2 days!)

When an embedded system is used for a consumer product who is the product owner?

Russel -  We have thousands of customers, Marketing dept, Field Serices represents the interests of the customer. Nancy - any problems with that. Russel - Sometimes. Only in last couple years has marketing been strong participant.

James - this is an organizational problem (of getting participation)

How to reconcile "HW requires long lead times" vs "Agile is incremental" ?

Russel - Board was not available for a couple years. SW was written to spec and was able to deliver 2 weeks after HW release.

Jack - Up front commitment to HW features and to the schedule is different for embedded.

James - At the beginning of an agile project one needs a vision of both HW and SW.

How do you handle scheule constraint.

James - in agile nothing is negotiable until it is late.

Russel - when we are late our internal customers now about it real soon. Visibility to decision makers is important.

Jack - This is not unique to agile. Quality, Schedule, Features pick any two. Jack thinks features should be unconstrained while keeping Quality and Schedule fixed.

Any experience including HW engineers in the SCRUM.

Russel - intersted but not active daily 

James - integrate early and often. Some teams use HW engineers as customer. One client in Finland does overnight board turns.

For an embedded system can a product backlog include User Stories that target either HW or SW? If so, what does a HW User Story look like.

Russel - We have not done that.

James - if you try it write a paper.

Jack - I think it would be very difficult.

I am concerned about the lack of upfront design. What if a User Story requires a big change?

Russel - we just experienced this with a project that required a substantial redesign. The requirement was given a year ago on an eight year project.

In classic agile the key to development is decomposition of the epic story into slices. How do you decompose in embedded?

Russel - Frankly we struggle getting our HW engineers to think agile but it is getting better. We had one example where a story to eliminate a spurious image required both sensor, hw platform, and sw.

What role if any does architecture have in agile?

James - we work on it every day. Every time a sprint is completed there is an architecture that supports SW completed to that date.

Russel - Some of our architecture is harder to change. 

Jack - Architecture and Design in embedded world is a lot less maliable. Up front design is very important.

Nancy - Some companies have a culture of detail which is driven by politics.

My question was the one about HW User Stories.... I am still looking for a way to weave the EE participation into a high tempo devlivery using agile approaches. I will take James up on his suggestion to write a paper when I have it all figured out.

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.

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.