Tuesday, September 25, 2007

APLN Seattle Special Event - Alistair Cockburn

Alistair Cockburn will be in Seattle this month. He has agreed to give a talk to the local APLN chapter. It will be more of an Open Space / Town Hall format. Attendance is strictly limited to 60 people. RSVP is required to dragosd at avanade.com.

The meeting will be held in the usual venue at Avanade, 2211 Elliott Avenue, Seattle 98121 at 5.30pm on Monday October 15th. Technorati tag: Alistair+Cockburn, APLN+Seattle, Avanade, Project+Management

In My Office

My boss Stephen Gillett snapped this candid shot of me slacking in my office last week. He tried to post it in a comment via Haloscan but it seems Haloscan screens out <img> tags in the content. So here it is… How many of books lying on my desk can you name?... Leave comments with your guesses. Corbis employees are not eligible for this competition :-p

 Technorati tag: Agile, David+Andeerson, Stephen+Gillett

Monday, September 24, 2007

10th Anniversary of Color Modeling

It’s been anniversary time in my personal micro-universe recently. September marks 10 years since we started to use color sticky notes with Peter Coad’s analysis technique.

September 1997 Mega-Pattern

The initial domain modeling on Singapore was scheduled for the whole month of September. Peter Coad was leading the effort with a core team of about 6 folks that included Stephen Palmer and me. We rotated others through the sessions every day to give the whole team exposure to the analysis and modeling technique and the domain knowledge. Each day we had different folks from the business analysis team present as subject matter experts. As the days went by we gradually filled up the wall space and the windows with model fragments. The art work was removed from the walls and stored in another room.

Peter had recently (Spring 2007) published the second edition of the “legos” book, Object Models: Strategies, Patterns and Applications. In this book, he presented a recurring pattern in domains using stereotypes. He called these <<role>>, <<moment-interval>>, <<person, place or thing>>, <<description>> this represented an evolution from the earlier first edition of the book from 1995. The mega-pattern as it was being called was also up on the wall as a reminder to us all of the pattern we wanted to achieve with our model fragments.

One morning during the coffee break, Peter and I were left in the room staring at some of the model drawn in yellow sticky notes that had emerged that day and comparing it with other pieces from earlier days. After some minutes of quietly staring with our own thoughts, we looked at each other and almost simultaneously said, “color would help here.” I left the room and found Steven Lo, the department admin, and asked him if the sticky notes were available in any other color than yellow? He nodded and disappeared, coming back moments later with a packet containing the now famous 4 pastel colors - yellow, pink, green and blue. I took them to Peter and left them with him. I went off to get coffee and check email.

When the team returned Peter had selected the four colors as displayed above with pink for <<moment-interval>>, green for <<person, place or thing>>, blue for <<description>> and I believe yellow remaining for role. We set about redrawing the models with the colors. It was obvious to us all very quickly how much more information was communicated with the color sticky notes indicating the stereotype of the class.

What we didn’t have in September 1997 was the Domain Neutral Component pattern. Nor were we using the term, archetype. Those didn’t emerge until Peter was writing the UML in Color book during 1998. Archetype replaced stereotype because Philip Bradley, the team lead on the data tier development, pushed Peter very hard on what he was really trying to communicate with the meta-class indicated by the color of the class. The outcome was that while we might use <<stereotype>> tags, the term stereotype was inadequate. Archetype was a better fit and hence color archetypes were born in December 1998.

The Domain Neutral Component emerged in January 1999 while the UML in Color book was being finished. Peter completely trashed the first chapter of the book and re-wrote overnight. He sent us all a new draft for review and in it was the Domain Neutral Component. I remember that at first we were skeptical. Some of us more than others. I vaguely remember Stephen Palmer taking some months before he bought in to the idea that this one pattern covered everything. Amazingly, 10 years later we all still believe that it does and we haven’t managed to improve on it, nor has a 5th archetype emerged.

Domain Neutral Component January 1999

The only modification to the DNC from 1999 that was made was to include the ability for pink <<moment-interval>> classes to have blue <<description>> classes. Peter actually knew he needed this edition but somehow didn’t have enough examples prior to sending the book to print. He made the correction very early afterwards and I believe some of the later print run featured the corrected DNC pattern. Technorati tag: Agile, Software+Engineering, David+Anderson, Peter+Coad, Stephen+Palmer, UML, Domain+Modeling, FDD

Sunday, September 23, 2007

Thoughts on Enterprise Agile Transition

While at Agile 2007, I attended a discovery session led by Pete Behrens, of Agile Executive Blog. Pete had assembled 3 of his clients who had all taken their teams through enterprise level transitions to an agile approach to software development and project management, along with a group of perhaps 60 conference attendees. We sat in small circles of 6 or so folks per group. The session was divided in to talks by each of Pete’s clients, some summarization from Pete himself, and group chats followed by some “show and tell” to the wider room.

My big take-away from the session was that several of the folks in my small group and at least one of the main presenters, gave a summary of their transition to agile that went something like this…

One of our execs met some guy sitting in First Class, who persuaded him that if we weren’t agile we were being left behind. So when he got back from his trip, he sought me out as a known change agent and asked me to lead a transition to agile development. So I assembled a small team and we learned all their was to know about agile. [Perhaps we hired a consultant to help us.] Then we made a plan of how to take our teams from the traditional waterfall style development method we’d been using to an agile/Scrum approach. Over the next 9 months we executed on that plan, and gradually we saw all the agile practices adopted across all of our teams. We completed that process 3 months ago and now we are agile!

Does anything strike you as ironic about this?

The way to enterprise agility was to make a big plan up front, based on a top-down, management led initiative, and to command and control the team to change to an agile style of working. Then to execute against the plan, and when every task on the plan was completed to declare that the change was done!

As I stated in my previous post, I’d been there before and struggled to achieve both scale and longevity with the changes. My fear with many of the enterprise scale transitions now taking place is that they will suffer the same fate. When the management that led the change is gone, the teams will gradually atrophy back to a traditional way of working. Unless a fundamental change in the organizational culture is achieved and the new culture is institutionalized from top to bottom in the organization, then I fear that the benefits of agility - even they are recognized as hyper-productivity in some teams - will be short-lived. An agile may get labeled as just another management fad. [Check out Sanjiv Augustine answering the 5Qs at PM Boulevard and his scenario #2 that Agile may indeed be just the management “fad of the year.”] Technorati tag: Agile, Software+Engineering, David+Anderson, Pete+Behrens, Sanjiv+Augustine

Institutionalization of Culture versus Prescribed-Change of Process

While success stories are all very well, in the agile community we know that we learn more from our mistakes and challenges than from our successes. Hence, I thought it might be more useful for my readers to hear some of my frustrations from my first year leading the software engineering team at Corbis than simply to read my self-congratulations from last week.

I blogged before that I took a different approach on joining Corbis. I went after the culture rather than leading change to a specific prescriptive method, such as Feature Driven Development. I did this because I wanted to achieve organization level change and institutionalization of the results. Previously, I had enjoyed localized success with my immediate development team or project but had not managed an enterprise level adoption, nor had the changed survived my departure by more than a year - at both Sprint PCS and Motorola. As I also stated I was afraid of the J-curve effect that driving home a specific prescribed process change might have at Corbis. So I opted for the long game of cultural change.

While I’m delighted with the results and the cultural change, while hard to measure objectively, appears to be widely recognized anecdotally, I am frustrated by some of the results. I’ve seen a lot of code released and a lot of successful releases. I’ve seen some very high quality and very few defects escaping in to our production environments, but I haven’t yet seen hyper-productivity.

Jeff Sutherland has been talking a lot about how difficult it is to achieve hyper-productivity. He talks about how few Scrum teams have ever achieved it. [He defines this as performance at least four times higher than might be normal.] He holds up the team that created Borland Quattro Pro as one of the highest performing teams of all time. A team that produced at least a 10x productivity gain. At Agile 2007, I spent some time with Jeff and shared with him the data from the Device Management project that Daniel Vacanti and I led at Motorola in 2004. The data compares favorably with the Borland Quattro Pro project. Even data from lesser performing FDD projects (the Singapore project - though it was a much larger project) and others from my team at Sprint and some others from FDD teams I’ve met along the way, tends to indicate hyper-productive results, and often with incredibly high quality data. Hence, over the years I’ve been used to achieving hyper-productivity with my teams.

So what’s up at 710 2nd Ave in Seattle? Why no hyper-productivity?

My guess on this is that cultural change and institutionalization and what goes with it - a high degree of autonomy, delegation, empowerment and self-organization - takes a lot longer to achieve hyper-productive results. The advantage is that change is achieved with a much lower degree of resistance, with very low attrition and change-driven churn and the change will stick and survive management changes and the general churn of projects and personnel over the coming years.

In the past, I’ve been an aggressive change agent. The CMO at Sprint PCS described me as “hard driving.” That approach achieved some localized results but equally it made me unpopular with some and probably left a residue of resentment towards management led change amongst the skeptical individual contributors. Folks acquiesced and played along with the rules of FDD and they enjoyed the success of projects delivered, but when the management wasn’t there to enforce the rules any more, they fell back in to the same old ways of working. The right way is to let the team make change its own. Through ownership the seeds of long term support and advocacy are born.

So while I wait for hyper-productivity to emerge or evolve through a series of kaizen events, I’m not unhappy. I set out to change a culture and to achieve an institutionalization of those changes that will eventually survive me and the rest of the management team. I’ve delivered on that goal, but darn it I miss the kick out of seeing some hyper-productivity. Technorati tag: Agile, Software+Engineering, David+Anderson,