As a Software Engineer, I normally think of Agile in terms of software development.  As someone who has rolled out Agile practices at several companies, I also think of it in terms of how Agile software development affects the rest of the company.  The last company I worked for (yes, I’m still looking for work!) implemented full Scrum, including pair programming, TDD (as in, insufficient code coverage had a direct effect on your bonus), retrospectives, standups, etc.

I came across an interesting blog post, The Smart Entrepreneur’s Guide to Finishing What You Started, on Scott Ginsberg‘s blog that suggests entrepreneurs learn lessons from Agile, too.  Scott bills himself as “The Authority on Approachability”, but most of his blog posts seem to be aimed at high-level business and marketing people.  He also claims to wear a nametag 24/7, with a tattoo of a nametag sufficing for certain occasions.  Everyone needs a shtick, though, and this is what us geeks call “mostly harmless“.

This post proposes favoring action over inaction, moving at a sustainable rate, making sure you’re focused on the customer’s needs, limiting scope to enable completion of a phase/project, and [post=”Done Means Done Done Done” text=”making sure done means done done done”].  Sound familiar?

I also liked his post 6 Ways to Rally without Being Ready, reminding us that you’re never 100% ready, but that’s not actually required to start.


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


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”.


Some think Agile is all seat-of-your-pants.  That’s not true at all.  Agile requires knowing where you are right now and what you need to do in the near future; it just doesn’t put a lot of faith in guesses where you’ll be 8 months from now.

The various forms of Agile all contain a set of practices to follow and others to stay away from, each with their strengths and weaknesses.  Successful implementation of Agile requires selecting and implementing practices that complement and support each other, covering all required needs without duplication (which is where a good deal of the efficiency comes in).  It’s bad enough if you pick a set of practices that don’t support each other, but it’s much worse to chose the right practices but not implement them right.  That’s because it can create a false sense of security.Continue reading