I came across this blog post on the Developer Art blog on preserving and sharing project knowledge.  I found both the articles and the comments insightful, offering several good suggestions for persisting and disseminating project knowledge.

This is a topic near and dear to my heart.  Anyone who has worked with me on a project knows I take endless notes, and I have been saved by them many times.  They can lead to information overload, but to me, it’s worth the risk.  You can’t go back in time and take notes at a meeting that already happened any more than you can reshoot your vacation pictures once you’re back home and notice that they all have your thumb in them.  I would rather record information and throw it away later if I don’t need it, than try to reconstruct an undocumented conversation after the fact.  The act of recording the information also helps me remember it.

Continue reading


I am a Team Leader in Agile Bazaar, a member of both the Agile Alliance and the ACM.  We have two events coming up in a few days.  Please go to Agile Bazaar for more information on either event.

Nanette Brown: Agile and Architecture: Crossing the Great Divide 

May 6, 2010 6:00 pm – 9:00 pm at the IBM Innovation Center, 404 Wyman Street, North Entrance, Waltham, MA

Agile development and software architecture are frequently seen as two divergent schools of thought or camps. Agile developers often refer to architecture as Big Design Upfront (BDUF) and may regard the architects major output as merely shelf-ware. Proponents of architecture-centric software development may see Agilists as undisciplined or short-sighted, engaged in endless rounds of refactoring which architectural foresight could have forestalled.

In reality, Agile development and software architecture practices are complementary. Focused attention on architectural concerns becomes critical as Agile development scales-up to handle larger and more complex systems. Agile developments focus on customer value, rapid feedback and response to change can provide practices that assist Architects in dealing with ever more volatile environments and increasingly compressed delivery cycles.

In this presentation, we will take a journey to each camp to dispel misconceptions and discuss how Agilists and Architects can learn from and benefit each other.

Deep Agile 2010: Empowering Teams with Agile Games

May 15-16, 2010 at Microsoft New England Research & Development Center, One Memorial Drive, Cambridge, MA 02142

Agile development teams are like emergency response teams – they need to be ready to act quickly to new challenges and changing competition.

At the Deep Agile 2010: Empowering Teams with Agile Games seminar, you will experience techniques that teach agile teams how to work together effectively and adapt to changing conditions.

I say “experience” because, rather than hearing lectures, you will be learning actively through observation and situational experiences, led by professional coaches and engaged facilitators.

The seminar includes structured sessions along three tracks: games to learn, games to change, and games to do work. You can move between tracks to select the blend of exercises that best suits your needs. Sessions range from introductory Agile concepts, to the theory of constraints (via the “bottleneck” game), to innovative topics such as using the art of improvisation to facilitate teamwork and exploring emergent design.

The second day will feature an “Open Space” meeting session, in which participants decide the agenda, then meet in breakout groups to explore the topics of greatest interest and share ideas for solutions. Open Space sessions are exceptionally stimulating and productive, because the discussions focus on the questions, problems and successes of you and your peers (See: the Agile Bazaar website for more information).

Of course the only way to gain all these advantages is to attend Deep Agile 2010: Empowering Teams with Agile Games in Cambridge, MA on May 15-16, so register today!

For more information and to register please go to http://games.agilebazaar.org/.


Today’s lesson for hardware people, software people, architects, and mad scientists is brought to you by Ray Bradbury in the form of a short story called There Will Come Soft Rains.  I recommend you follow this link and read a copy of the story, as it’s only a few pages long, and well done (but I already said it was Ray Bradbury, didn’t I?).  The story, written in 1950, takes place in 2026 in a very modern, fully automated house, with all sorts of computers keeping its occupants fed, cleaned, entertained, and on schedule for work, school, and play.

Only there are no more occupants.  Because there was a nuclear war, and they’re all ashes.  The house (the last house standing), in it’s quite-less-than-infinite wisdom, has not caught on to this.  So it prepares eggs and pancakes for breakfast, and provides entertainment in the nursery, and defends itself from the few birds and animals that may approach it, and fleets of mechanical robots diligently clean up any dirt that gets in the house and dispose of the uneaten food.  In short, this system has insufficient connection to the world it interfaces with, and too few checks on expected responses, to know that something is horribly wrong.

Continue reading


I have heard several talks and attended several presentations both comparing Scrum and Kanban and explaining how they can be used together.  I came across this article, which talks about this article (I list both because the commenting article brings up good points, too).  So why am I adding yet another level of indirection to this chain?  Because an awful lot of people understand past the surface and the buzzwords of the various flavors of Agile/Lean, and that leads to confusion, unmet expectations, and failed projects.  The most important  point of these articles is that Scrum and Kanban are not interchangeable techniques.  They differ greatly in scope and goal.  That’s why they bring up the metaphor of choosing between a knife and fork.

Continue reading


One of the frustrations of managing software development is that different people have a different idea of what “Done” means.  It can range from “It compiles and it’s checked in”, to “It compiles, and all the unit tests pass, and new unit tests were added for the new functionality, and the documentation was updated, as was the issue tracking system, and the QA guys signed off on it”.  This is especially a problem with Agile development, because so much rides on a common understanding of the state of the software.

Alixx Skevington recently posted an article in the Agilistas group on LinkedIn called My Manifesto of done.  It’s an interesting read, and a good start.  He’s flagged it as a draft, so I don’t say that as a criticism.  I know I’m going to follow that discussion (I’ve already contributed to it).  Hopefully it will turn into something that companies can point a finger at and say “Do this”.