Adventures in Software Engineering : Agile

An old metaphor for project management

clemmend — Sat, 05 Jan 2008 11:11:02 GMT

Our culture owes a lot to the influence of Newtonian mechanics in shaping the thinking in other areas, such as in Psychology with the notion of "energy". Even though this usage is obsolete within professional circles, the expression is still an active part of the popular culture.

The fabric of our thinking also has another Newtonian concept as a background: the mechanical "static equilibrium". We usually see stability in a way that is contradictory to what happens in life, where equilibrium is a delicate balancing of multiple forces woven in a dynamic exchange.

This cultural influence extends to ideas on project management. We tend to see projects as a collection of static endeavors where everything is predictable, punctuated in between with checkpoints at which some change might be added, in a predictable way, into the system.

I would rather refer to Heraclitus "everything changes" idea when thinking about project management. And that implies continuous adaptation, not just at staggered checkpoints or milestones.

Juggling has always been a great metaphor for project management, for although we don't think about it while watching their mesmerizing performance, jugglers are constantly adapting to where the balls go. Even though they kind of have an idea of a ball's trajectory through their experience, their greatest skill is going after it in the nick of time.

The following video by Fatboy Slim is a homage to adaptive project managers of all times, from Heraclitus to Agilistas today, with eyes on the ball and ears on the rhythm. Enjoy...

Agile Austin inauguration was a huge success

clemmend — Fri, 07 Sep 2007 03:19:00 GMT

The first meeting happened last 4th of September, and you can get more details at the Agile Austin website.

In the first talk, Jim Van Riper, VP of Product Planning and Development from Troux Technologies, shared the inside story of adopting Agile in a fast changing environment.

Jim's thinking about Product Management is also interesting: they should always be "Pigs" (in Scrum parlance), not "Chickens". In my experience with MSF in general, and MSF Agile in particular, is that it solves this lack of Product Management involvement by having the Product Manager as someone from the customer side, and as an integral part of the team at all times, not just when interfacing with project managers.

One of his quotes ("turn over is good for you") called my attention when he explained that most of those who could not adapt to Agile chose to leave - and that the company was better after that. Jeffrey Palermo's blog has more on the meeting.

I don't think that even the organizers were expecting to see such a full house with people standing inside and outside of the conference room. This tells a lot about the need for such a community in Austin.

Congratulations to all who put this together, among them Scott Killen and Jeffrey Palermo.

TechEd 2007: Presentation on Agile Software Development for small teams was a hit

clemmend — Wed, 06 Jun 2007 01:19:11 GMT

There was a session I forgot to mention from my post yesterday, but that was one of the best. Here is the complete summary so you have an idea of what was covered:

DEV02-TLC - Microsoft Visual Studio Team System for Small Agile Teams

Monday, June 4 4:45 PM - 6:00 PM, Blue Theater 13

Speaker(s): Will Stott

Everyone says that Agile approaches like Extreme Programming only work when you’ve got a small team of highly talented developers. I agree that Agile works best for small teams, but it’s not talent that really matters, it’s a willingness to adopt certain practices and values. Over the next forty minutes I want to explain how Visual Studio Team System (VSTS) supports the Agile practices and values that allow everyone in this room to create a top performing small team. Topics to be covered include: • The case for creating small Agile teams – how Agile provides a middle-way between having too much process and too little • Adapting the Team Foundation Process Framework – how to create a light weight process for a small Agile team doing Extreme Programming. • Setting-up Team Foundation Build – why frequent integration is important and how to implement practices like ‘Continuous Integration’ and the ‘Ten Minute Build’ with TFB. • Test-driven Development – demonstration of the new VSTS Tools in a Pair-programming session (James Newkirk / Will Stott) with particular emphasis on Refactoring and writing good programmer tests. • Customer Testing using Generic Tests and FIT – how functional tests written by Customers in a Word document can be run as part of an automated build process to verify that your code satisfies its business requirements. James Newkirk and Will Stott have written a book entitled ‘Visual Studio Team System – Better Software Development for Agile Teams’ (700 pages) which Addison-Wesley will launch at Tech·Ed 2007. This book is targeted at people who want to know how VSTS might be used by a small team transitioning to Extreme Programming and includes a series of exercises which take readers through the entire software development lifecycle from inception to deployment.

I arrived there on time, and there were already as many people outside as inside the presentation space.

You could actually see people standing on top of chairs to see and hear what he was presenting. Some people watched the whole presentation while standing up, which is quite a compliment.

Doug Seven replaced Jim Newkirk as a co-presenter, as his flight was late.

Will and Jim had just launched their new book (as mentioned in the summary "‘Visual Studio Team System – Better Software Development for Agile Teams". The companion site (where you can get a link to buy it from Amazon.com) is here.

As part of this work, Will and Jim released a new software process template for Visual Studio Team System, MSF for XP.

I will blog again at length about this book later. Right now I can tell you though that this is one of the best books that you could buy at this moment if you are planning to adopt an Agile method with Visual Studio Team System.

The 90% rule

clemmend — Sat, 02 Jun 2007 07:47:00 GMT

Once again a few friends (in this case, Fabio Camara, and Andrew Delin, both in the same week :-) ) ask me why I haven't been blogging. It seems that every time we have a conversation, they point out it could easily have been made into a blog entry.

After some reflection on the issue, I realized that it is because I have not been applying the "90% rule" to blog publishing: 90% of the ideal quality is good enough for most readers. In fact, I have seen so many spelling errors in some blogs that even so continue to be taken as a good reference that the bar seems to be to be at 60% or maybe 50%.

The same analogy applies to requirements capturing, coding, or for that matter, any knowledge transformation activity. If it takes too long to produce some information to be consumed, when it is finally done in perfection it might no longer be relevant (although it is always possible to recycle an episode if we can extract its intrinsic timeless value - another way of saying that all experiences teach us).

Being stuck in such an endless loop situation in software development prompted the infamous "analysis paralysis". Agile teams have a way to deal with it in the formula YAGNI ("Ya Ain't Gonna Need It"), which helps you cut the cycle by focusing on why you are doing something. Which reminds me, I would better post this now, or I might never publish it once the never ending editing cycle starts.

I guess I have to apply the 90% rule more. However, my bar for spelling will continue to be 100%, or else I will put the blame on Word's spellchecker if something wrong passes through.

If only we could blame compilers for our business logic defects :-) ...

McCarthy's video on "23 and a half Rules of Thumb for Software Development"

clemmend — Fri, 27 Oct 2006 04:53:00 GMT

"23 and a half Rules of Thumb for Software Development" is a classic video of a speech that Jim McCarthy made to Microsoft Consulting Services. It has been shown worldwide to anyone taking MSF training, as part of the "Principles of Application Development" course.

McCarthy also recently released it as podcasts at http://www.mccarthyshow.com/McCarthyShow/TwentyThreeandaHalfRulesofThumb/tabid/808/Default.aspx

This video is a great companion to McCarthy's "Dynamics of Software Development" book, one of the cornerstones of MSF 2.0, software engineering classic (note that the book has 54 rules, not just 23), and that the video is included with the latest edition.

Agile 2006

clemmend — Fri, 04 Aug 2006 01:22:00 GMT

The weather in Minneapolis was warm this year, and so was figuratively speaking the Agile 2006 Conference, which had all sorts of interesting discussions going on anywhere - lobbies, dining rooms, sessions. I felt at home for its informality, and definitely will come back next year.

While being a newbie to the gathering, I have been working with agile software development since 1999 when I was first introduced to the topic by Bill Addington, whose last job at Compaq was as a software development quality and methodologies guru.

Aside from MSF (which to me was inexplicably absent from the manifesto meeting in 2000), my first book on agile was Adaptive Software Development by Jim Highsmith, then Xtreme Programming Explained (first edition) by Kent Beck, followed by Java Modelling in Color, a beautiful book by Coad, Lefebvre and DeLuca, which introduced FDD.

So while at the conference it was a pleasure to meet in person several luminaries who have been the backbone of the Agile movement.

The first one was Alistair Cockburn [pronounced 'co-burn']. We had a chance of chatting for a few minutes after his introductory presention on Agile Software Development in general, and Crystal Clear in detail. My favorite book of his though is Writing Effective Use Cases.

We talked about the origin of the name "Agile" for the manifesto, with a few interesting points I will bring back later.

Alistair Cockburn in a display of positive agile energy while talking to a conference attendee

Comparative study on RUP vs MSF

clemmend — Thu, 27 Jul 2006 17:30:00 GMT

Johan Traa has just published a comparative study on RUP vs MSF for Agile Software Development: "MSF Documentation: RUP vs. MSF - A comparative study". Check the post at the MSF Forum.

It is really worth the reading. He adds new material to help you understand MSF for Agile Software Development, specially a nice graphical representation on page 132.

MSF oldies

clemmend — Thu, 19 Jan 2006 01:09:00 GMT

I was talking to my good friend Andrew Delin about how the original MSF 1.0 had several concepts which today are associated with Agile methodologies. One such concept was the polemic "Why No Requirements Document?" one. The main point in this doc is:

· Users/customers generally don't know what they want or need until they gain some familiarity with what they can have;

The solution presented at the time resonates with what has become common today:

The SDD process model does not ignore customer requirements. They are accommodated through:

· early identification of driving requirements and constraints as a part of defining the project scope [i.e, Vision Scope document];

· establishing traceability through analysis techniques like activity-based analysis, in which all features specified in the Functional Specification are traceable to specific user activities or tasks identified in the analysis activities [i.e. Personas and a list of Scenarios];

· controlled revision of project scope and Functional Specification documents to reflect changing or better-understood requirements [i.e. Functional Spec as a collection of Scenarios which can be modified or postponed to a later iteration ("versioned releases" at the time)].

These and other gold nuggets are in MSF 1.0 RC1.