Hello, my name is Maurice Sare. (my friends call me Mo). I am a first level tech lead/engineering manager at Gameonics, Inc, a multinational developer of distributed gaming for PCs and now, it seems, "smart phones." I've only been here a few weeks. Before that, I worked for a company that developed operating systems for smart phones, so I know something about the domain, but I've never worked at the applications layer, before. Before this, I hadn't had any formal training in agile development practices.
I run the graphics team here - a long way from that kernel stuff I had been working on. Gameonics has decided to adopt "agile methods across the enterprise" (whatever that is), which is predicted to affect all 1,000 developers over time (including testers, project managers, docs engineering support, etc.) over time. Because of the impact it has had on me, I have decided to share my experiences of a two-day "release planning event" that I just attended. Frankly, it has changed my view of Gameonics and its future, not to mention my understanding of agility.
At my prior company, we experimented with Scrum a bit and had a standup meeting every day and I understood it was just for small teams. Anyway, I've always considered myself to be an agile developer, so going into this meeting I'm about to describe, I wasn't so sure there was that much to learn.
With me at this meeting were my teammates, Lawrence, who was my "product owner" (whatever that is, remember, I am new) and my architect/lead developer Scott, (I know what that is). The meeting was held in our offices in Chicago, and I was told that key team members from our Chicago, London, Bangalore and Denver offices would be there. Forty-five people in total! I would have rather spent the money on software tools than travel budget, I thought, and anyway, this meeting is likely way too big to do anything useful.
Day One
9:00 - 10:00 Business Context
After some milling about outside the meeting room, and meeting some new people from the remote offices, including other managers that I just knew would be important over time, amazingly, the meeting started on time. There were a number of executives in the room, including Jan, my boss' boss. There was also some kind of an "agile coach" named Bill present; he and Jan introduced the agenda for the day. I didn't understand if Bill worked for us or was just some outside gun hired to help run a big meeting. No matter, but he seemed to have done this before.
The first session was a presentation by our Division VP (group VP, whatever, I don't remember his name and didn't catch his exact title). He brought us up to date on the most recent quarterly financial results, defined some key objectives for the upcoming quarters, and told us about his most recent meeting with our two key customer constituents, the device manufacturers and carriers. He emphasized the need for improved quality and improved productivity. (So what is new? - I know, let's just work smarter, not harder, yeah right....don't these guys get Dilbert?) He warned that the company's market share is being threatened by a few VC backed upstarts, plus we've heard rumors that Giggle, a major player in the industry, may be also entering the market. More importantly, he described his vision. In his view, what we used to consider a stand-alone, PC- based gaming business, where we are the de facto market leader, now looks like it will evolve into a combination social network/distributing gaming platform for mobile devices. Part MySpace-part SIMS2-part IM for young adults, but all in all a new kind of beast entirely.
Interesting
. Now that's a big vision and something I can personally get excited about.
10:00 - 11:30 Product Managers at the Helm
Like I said, we're a pretty big company and we had presentations by four, (yes, four!) senior product managers, each of whom was responsible for an individual line of games. Their time was short, so they had to be pretty concise. Each took us through a short deck with some context setting describing his gaming line, the current challenges in the market, and the big pain points our largest customers have been beating us up with. (So I dangled a participle here, I'm a software developer, after all.) It looked like the product managers had agreed to a presentation template in advance so it went pretty fast. Each went something like this:
- Competitive context for the product area - who's doing what to us and to others.
- Specific issues, opportunities, and challenges with customers.
- Our priorities for the upcoming releases.
But what I really remember were the last two slides from each product manager which highlighted the top five to seven specific initiatives in his area, in priority order! At the end, they distributed each of their presentations. There was no summarized, aggregated priority slide, but at least we knew what each of the four of them thought was important. All in all, we had all four decks in hand, and an aggregate of 20-some prioritized features.
A lot of these don't have any impact at all on me and my teams, I thought, but some do and some are pretty dang big, and some, I'm not so certain.This is getting a little more interesting, I wonder what happens next......
11:20-12:00 Engineering Management Speaks
Next, Jan got up and delivered a "state of the engineering union" speech, discussing the general engineering process and our move to agility. She also described a couple of major architectural initiatives underway, including driving increased componentization, better separation of concerns through APIs, and rototilling the multitasking kernel, which needed to be replaced to support the new distributed games on mobile devices.
Fortunately, none of this last part was new to me, as a number of system architects had visited our team off and on over the last few weeks, describing the new product requirements, and amazingly, listening, as well as talking. So while the architectural issues were almost as intimidating as the vision and customer priorities, at least they weren't new and we had a chance to put our imprint on how this all needed to happen technically. What was new to me was the release process model she and Bill presented (see Figure 1).
She said there weren't very many rules about how we developed software (thankfully) but the ones she did say were certainly eye opening!
- We'll build and integrate working software every two weeks.
- It will be integrated, unit tested, component tested, and system tested across all components every two weeks, too.
- We'll have a potentially shippable "internal" release available every 60 days. The iteration pattern will be three "development" iterations and one "hardening" iteration (whatever that is).
- The target for time to market for the first distributed game application (probably a port of two existing games) was in 120 days (around the second internal release). It might ship sooner, it might ship later based on outcomes, but in any case, that was the target. And, no matter when it was actually released to the market, the pattern of iterations and internal releases would not change!
Easy for her to say, I thought to myself, but how in the world are we possibly going to do that? I wondered.
She then stated the objective for this meeting:
"Today and tomorrow, we'll lay out a rough plan for the first internal release, work through interdependencies and issues, and come to a point where we can make a commitment to our company of approximately what we will have ready for evaluation by users in 60 days. Not a perfect commitment, but a prioritized one, and one where we have a high probability of accomplishing at least the highest priority features we agree to."
She then continued:
"If we cannot reach the point by today by 6 p.m. today, then we'll meet again tomorrow and cut the scope if necessary until we have a plan we can commit to. If that fails, we'll stay here until we get a plan that works.
Whoa, she may be bluffing, but she definitely has my attention now!
12:00 - 3:00 Team Breakout Release Planning
The next three hours were a whirlwind of activity. Pizza was brought in for lunch but I don't remember anyone relaxing and enjoying eating it. Since I was new, the product owner on my team, Lawrence, who had been a developer here for some time, led the next part of the discussion. He had met with product managers ahead of time and had a decent understanding of the features that had been described earlier. For an hour or so, we brainstormed all the "stories" (things we would need to do, with a focus on "value delivery" which means, I guess, things that users, rather than developers, actually care about) that we thought we would need to do in the first three iterations to accomplish the release objectives. As we thought of them, we wrote them down and put them on a wall on a 4x6 sticky note. Intermittently, a product owner, team lead, or system architect from another team would come to the meeting and ask about dependencies we might have on other teams, or highlight some of the major architectural development we needed to have underway as well. Sometimes this caused more stories to go on our wall; sometimes we got rid of stories when we discovered that another team would handle them.
After about two hours, we had identified all the stories we thought we needed and we went through a process of "building" the release plan. In this process, we first estimated each story in "story points" (a process I won't bother to describe here but suffice it to say that we generated a very rough idea as to how big each story was). Then, we placed the stories in one of the iterations in the release plan until we ran out of capacity on the team to do more stories. (We were told not to place any stories on the last iteration for some reason, but we felt we had to because otherwise they didn't all fit). We talked about sequencing and dependencies of the stuff our team would develop, moved things around a bit, and then put in a few stories for integrating code that we could expect from others. At the end of this time, we had visual picture of what we needed to do by when (see Figure 2).
It seemed pretty loaded, but not impossible. We couldn't say for sure that we could do it all, but we couldn't say for sure that we couldn't, either. We took a short break and then went back into the big meeting room where everybody was in the process of placing their release plan (i.e., stories packed in iterations) on the wall in the room.
15:00 - 17:00 Draft Release Plan Review
The next part of the meeting was simultaneously boring and fascinating. Each team was given 15 minutes to describe its release plan to others. A delegate from each team went to the board and described the actual plan, not story by story, but in summary form (thankfully!). If a team had an issue that was outside its control, or something it did not understand, the facilitator placed the item on the issues or "parking lot" list on the wall in full view of everybody (see Figure 3). This prevented each presentation from diving into problem solving, although a little of that happened anyway.
My team was second, so there was a lot that I didn't know about the other plans when I presented. As I presented, people listened, and yet many folks in the room walked to their release plans and moved some stories around during my presentation. Sometimes they added them, sometimes they trashed them, and sometimes they handed them to other teams. I got the idea that they were all making adjustments based upon the plans that I was presenting. I had one issue for the list, which was that my team had no one available to document and then teach the API that we were developing for the other dependant teams. Excluding that issue, the leader asked me if we could commit to the objectives for the release, I said that we were heavily loaded but we had fit most everything we could think of, so while we couldn't say for sure we could do it, but we would surely try. (I had some other ideas for responses, but this was the one I thought I could get by with!)
After the two hours had passed, everyone had presented their plans and some things were blindingly obvious:
- There was a longlist of unresolved issues on the parking lot.
- Some teams were way overloaded, (even more so than ours) and yet one team had almost no work to do.
Most importantly, it was obvious that, there was no way in heck that we were going to be able to deliver the release objectives on time!
There was a palpable sense of disappointment, and perhaps even a little fear, in the room. I saw many downcast and downright grumpy looks from product managers, engineering managers and some of the executives present.
17:00-18:00 The "What are We Going to do Now" Meeting
For the next hour, we reviewed the issues list as a group and discussed how to meet the objectives of the release. Some minor scope was cut. From the look on their faces, a number of people's sacred oxen apparently got gored and some resources were moved from team to team. (Fortunately, my team was largely unaffected as our scope seemed to fit in the time box, other than our documentation/training problem, which was still an issue). At the end of the hour, we still weren't there, so Jan took the helm again and said:
"Ok, this still doesn't fit. I'd like you to all go away this evening and work on a plan that does fit. Tomorrow, we'll go through this process again".
She continued:
"We'll meet here at 8:30 a.m. Product management will present first, rearranging some things and reducing scope if necessary, and then you'll all have two more hours to revise your plans. By 11:00, we'll present the work in process again to the entire team. By the end of the afternoon, we'll have a plan we can commit to, or we'll do it all again on Friday."
That Evening
Given that our graphics project was not in the worst shape, we were pretty confident as we started to head out to dinner. However, just before we left, the coach, Bill, asked if he could meet with us (Scott, Lawrence and me) for 15 minutes before we headed out. The dialogue went something as follows:
Bill: It looks like you guys are in pretty decent shape for the release? But the plan looks pretty heavily loaded?
Me: Yeah, we think it's doable.
Bill: I see you have some stories in the hardening iteration. Do you think you've identified every story that you will need to meet the release objectives in the earlier iterations?
Me: Well most of them.
And then the killer question sequence came in rapid fire...
Bill: What's the probability that no new and significant stories will be discovered in the next 60 days"?
Me: ummm, probably zero.
Bill: What's the probability that you have estimated all the stories you have identified accurately, or overestimated the time it would take for each?
Me: ummm, probably zero.
Bill: What's the probability that every dependency you have on other teams will be addressed exactly as planned?
Me: ummm, probably zero.
Bill: "What's the probability that no one on your team will be sick or take a currently unannounced vacation in the next 60 days?"
Me: ummm, probably zero.
Bill: "What's the probability that integrations with the other components will work as smoothly as you hope?"
Me: ummm, probably zero.
Bill: "So what's the probability that you will be able to deliver your component on time?"
Me: ummm, ummm, probably zero.
Bill: "I think you need to rethink your release plan and come in tomorrow with an answer way above zero"
Well so much for our evening off.Lawrence, Scott and I spent the rest of the evening working together and on the phone with developers who had not made the trip. We went through the release plan and revised the estimates with their input. They had a number of requisite infrastructure stories we hadn't envisioned. It became clear as we went that our plan was in deep trouble. Cripes, our plan was getting worse, not better! Later, Lawrence appealed to the senior product manager to see if it would be ok if we only ported Road Rage, the first of the two games, for the first internal release. He agreed somewhat reluctantly. Even then, it didn't look like we were going to be able to make it so a bit of a panic set in.
However, just when all was lost, Sergey, one of the sharpest junior developers on the team called Scott and told him that if he could program in Python, which had recently been released our on our mobile OS environment, he thought he could redo all the existing GUI way faster than recoding from scratch. That could save us three to four weeks of developer and testing time! Scott said he would talk to Sergey and assess the risk of the new technology. He said he and Sergey were going to download Python tonight and try.
Assuming Sergey would be successful was now our only hope. By applying his idea, we created a new plan that seemed to have some flexibility built into it (though admittedly, the backlog was bigger, not smaller, than we had hoped) and there was the new risk added "Python doesn't work" (see Figure 4). But Scott didn't seem very worried about Python, and if he wasn't worried, I wasn't worried. And, if it did work, we could free up a developer to document the API and to train the other teams in its use!
And our only remaining issue was the risk of the new technology, which we would address in the first iteration. Exhausted, we went to bed and slept. Not well, but slept. When I woke up the next morning, I had an email and a download from Sergey and Scott in my in basket. Sergey had stayed up most of the night. He had downloaded Python and implemented 10 of the 30 total screens that we were accountable to port! Not tested, and not fully implemented, have you, but close enough to prove feasibility! Scott validated the work and we went off to breakfast.
Day Two
8:30 - 9:00 Re-Scoping
Honestly, we eagerly anticipated Day 2 and I looked forward to my time to present. But first, the product managers gave a short presentation about the revised scope and objectives for the first internal release (IR1). They had revised priorities for a few teams (including my team) and agreed to start the port of two applications for the first internal release but that we would demo only the first to our customer at IR1. "Wait a minute," I said, "I didn't say we couldn't do both by then, I just said we couldn't commit to it." "Fine," she replied, "we'll commit the first to our customer, and we'll have an internal stretch goal of porting the second."
9:00-11:00 Refining our Plan
We felt pretty good about our plan and the next two hours weren't so busy for us. By the time of this meeting, Sergey's work had circulated around the team and three other developers were also testing Python and reporting good results. One agreed to do the API work as well. We made some additional mods to the plan, talked to some of the other teams about dependencies, went through the plan with Roger (the system architect from corporate that I had met only the day before), and finalized our results. We also started a more detailed iteration planning session for iteration 1, though we didn't complete that before the general session started. That's ok, we thought, we still have Monday to finalize the plan for the first iteration.
11:00-13:00 Release Plan Review 2
We didn't think the release plan meeting would take so long this time around, but it did as the teams were pretty tired and there was a little more problem solving this time around. Probably because no one wanted to spend another day at this, so we were really getting down to business. Most of the time was spent with team "Beemer," who was doing some longer term game development work on a new platform. When this team presented, Bill noted that it had no value delivery (nothing demonstrable) planned in IR1, he questioned why and what they were doing. There were some really awkward moments for a time there and some of us couldn't help but snicker at the fact that it was about time that that team stepped up to some delivery milestones. The net effect was that the Beemer team went off right then to figure out what it WOULD deliver in IR1.
By the end of this session, there were ten sets of plans in the room, all of which (including team Beemer) had the same profile as ours, i.e. heavily loaded in the first few iterations, and more lightly loaded at the back end.
It all looked sensible. We thought we were done, but Bill and Jan though differently.
13:00 - 14:00 The Issues Parking Lot
Bill and Jan turned their attention to the parking lot. Amazingly, as if by magic, many of the issues from the day before were crossed out (just like ours). And yet, some issues remained and some new ones had been added to the list. We spent most of the next hour going though the items one by one. It became clear to me that we weren't going to be able to leave this meeting until every issue on the parking lot was either:
a) Resolved by the team in that very meeting, orb) Had an "owner" who accepted responsibility to resolve the issue outside of the meeting and beforeit could impact the release schedule.
(I also noted with some satisfaction that a number of the issues on the list had evidently been big problems for some time and that the managers and directors present were assigned to most of these items). Any process that really tackles those issues, I thought, is a good process by me.
The Fist of Five Commitment
Finally, and thankfully, we approached the end of the meeting. Jan told us about the "visual fist of five" commitment metaphor. Simply, each of us was to vote in full view of all the others with confidence factor in a show of fingers ranging from zero (meaning that there was no way we were going to do this plan or anything like it) to five (meaning slam dunk, it shall be so).
I was guessing we'd get five fingers across the board after all that work -- and all the visibility with all those execs in the room, who had magically reappeared just for this part! But, dang the honesty of all those engineers in the room, we didn't. When the hands went up, Jan and Bill averaged them and reported an average result of 3.8. For a moment, I was depressed and thought we'd be doing it all over again, but amazingly enough, Jan said,
"I would have hoped for higher, but this is software, after all, and we've never worked on a mobile platform. That's good enough for now and we'll check again at the first iteration milestone. If necessary, we'll adjust the plans then. But before we go, the Product Managers have asked for 30 minutes."
The Roadmap
At that point the head of product management got up. It was clear that he wasn't thrilled with the first deliverable and what that implied for the release. It seems like those people always want more, more, and more I thought to myself. But then again, I'm not sure I'd want to work anywhere where they didn't! He said that they would be moving forward with the plans we had laid out, and would be committing the first game for customer evaluation at IR1. They would not commit the second game to the customer due to my team's critical bottleneck, but they hoped they would be able to surprise the customers with more, rather than less. But in any case, it was critical to the company that we deliver the first game at IR1 with requisite quality. They then presented the "roadmap" which they had developed, based on the outcome of the release planning session (see Figure 5).
This "plan" sure didn't have much detail and it still wasn't clear what they were going to release to the market and when, butit was clear to me and my team what we had better be doing and we wanted to get the heck back to the office and start now!
We Adjourn
But, before adjournment, Jan and Bill had a few parting comments.
Bill noted that he was asking each team lead to start attend a daily "integration Scrum" that would be held after the daily stand-ups. Since the time schedules varied, this conference call would be held every day at noon Central time. At this meeting, each team was to discuss the current status of its project and to note and resolve any impediments that would prevent the teams from landing the iteration. Since I was an agile team lead, I would be attending, and while this was news to me, it did make sense as I had a number of dependencies on other teams. He committed to the meeting only lasting from 15 to 30 minutes each day.
Jan noted that a release steering committee had been formed, consisting of herself, a number of other managers and directors, and the heads of QA and product management. The release steering committee was going to meet weekly, and would be monitoring the progress of the release and communicating status, any changes of scope, or other issues back to the teams through the integration Scrums and managers. Since the first major check point would be in the two weeks (at the end of the first iteration) she noted that we would have an objective measure of what we had accomplished (i.e., we either did or did not meet the objectives of the first one-third of the plan) and whether we were tracking to the overall IR1 objectives.
Jan thanked us for all our time and hard efforts going into the meeting and said that she appreciated our commitment to the release objectives.
Hmmm, I thought to myself - team empowerment, challenge, visibility, and shared commitment - I think I'm starting to get this agile thing now .................
About the Author
Dean Leffingwell is an entrepreneur, software executive, and technical author who provides product strategy, business advisory services and enterprise-level agility coaching to large software enterprises. Recently, Mr. Leffingwell was founder and CEO of a consumer marketing identity company. Mr. Leffingwell has also served as chief methodologist to Rally Software and formerly served as Vice President of Rational Software, now IBM's Rational Division. Mr. Leffingwell has been a student, coach, and author of contemporary software engineering and software development management practices throughout his career. His latest book, Scaling Software Agility: Best Practices for the Large Enterprises was published by Addison-Wesley in 2007. He is also the lead author of the text Managing Software Requirements, First and Second Editions, also from Addison-Wesley. Mr. Leffingwell holds a Masters Degree in Engineering from the University of Colorado.
