Ah, the Daily Build Revisited……

I just left the development team in Kyiv that I have been working with for the last six months. This is a new team, formed in only the last six months, building a large scale application (unfortunately, the project is in deep stealth mode, so the nature of the application will be “non-disclosed” for a bit longer). The agile master, (Alexander ,or Sasha ,to the team), was recruited specifically for his experience in agile development. None of the other members of the team had any prior agile experience but with Sasha in the lead and with some steady coaching from me, their agile prowess is pretty good (I’d give them four “bars” on the agile scale). Even though the application is fairly large in scope, the team runs weekly iterations. (Why, you might ask, given the steady recommendation in my book for a standard two-week length? The answer to that question will come in another posting).

Recently, we’ve been working hard on some of the “long poles in the agile tent”, most specifically completing functional testing within the iteration, splitting the team as it got to 14 members, etc, and I was fairly comfortable with their overall progress and we had settled into a fairly routine weekly cadence with Wednesday being demo day.

For entirely different purposes we had a consultant visit to look at some of the technical aspects of the application we were building. The consultant had 30 years of experience in building large scale systems, mostly by traditional process models. He understood a bit about agile and on the way in from the airport (Kyiv Borispol, Ukraine) he asked some basic questions about the team and their process. He immediately asked about the daily build process. Sasha noted that, while the team didn’t build daily, they could build on demand and would build once or twice per iteration and that was adequate. I didn’t say anything at all on the point. After a spirited defense of the ad hoc build by Sasha, the consultant seemed satisfied.  Sasha looked over at me and noted that I had pulled the hood on my parka down over my face. I suspect he understood the point.The next day Sasha I discussed some of the problems we had been having in testing certain modifications to essential algorithms that produced results that required review by the product owner (me, in the interim). Basically, we noted that we often had to put together a custom build at every point where we needed to test the new algorithms, and often that was a scramble and a delay of a few days to see results. (note to agilists of seniority: remember when seeing full results in 2-3 days was lightning fast?!) We also noted that we had spent significant time in reaching the demo state with Wednesday integration and demo preparation being a monumental weekly task, and that more than one iteration had failed to be successfully integrated in time for the weekly demo. After, a few more minutes of discussion, Sasha gave me the knowing look that said –it’s time–. So Sasha built a story in the next iteration to instigate the daily build 

When I think of the daily build, I’m reminded of the high bar that is set by the true agilists (See Chapter 14, Continuous Integration.) For example, Martin Fowler notes that he and other agilists have a pretty aggressive view about what makes a successful build:

l       All the latest source files are checked out of the configuration management system (including all scripts, config files, etc.).

l       Every file is compiled from scratch.

l       The resulting object files are linked and deployed for execution.

l       The development system is started, and a suite of tests (build verification tests) is run against the system.

l       If all these steps execute without error human intervention and every test passes, then we have a successful build. 

Reference: Fowler, Martin. 2006. http://www.martinfowler.com/articles/continuousIntegration.html. 

I promise to report back in a few weeks and let you know how it goes.

The Simple, Visual, Iteration Kanban

I remember so vividly one of my first impressions of an effective agile team. It was about 2001, and I walked into a development shop with a team of about 12 people seated at one large table (later abandoned for modest, semi-open cubicles, by the way.) On one side of the room was a large whiteboard with three vertical columns of sticky notes. I don’t remember for sure what the columns were labeled, or even if they were labeled, but they each contained a set of stories the team was working on, with the “state” of the story represented by the column. However, somehow it was clear to me immediately that the states represented were not started, in progress and done. (Over time, I’ve come to think in four basic “states” of a story, “defined”, “in progress”, “complete” and “accepted”.)

 

 

At that time, one of the companies I was working with, Pelion Systems Inc., was developing software to help manufactures “lean” their enterprise. Pioneered by the Japanese, lean flow manufacturing makes extensive use of the kanban card, which loosely translated, means “signal”. In lean manufacturing, each kanban card is a “simple visual signal” that indicates that a manufacturing work cell is ready for more work. On the floor, it pops up as a visual reminder to everyone in eyesight that a particular cell will soon need more raw material to keep it in production.

 

In the software development shop that day, I was struck by a number of insights, including some of the parallels to agile development and lean flow manufacturing (developed further in SSA Chapter 6 – Lean Software) and the power of the simple visual signal. In this particular development shop, any manager, developer, team member, and even the janitor could see immediately what the state of their project was at the point in time – what work was in process (on the floor), what work was completed (in finished goods) and what work had not been started (raw material). And, as that knowledge wasn’t enough for starters, if any stakeholder in the development effort knew the length of the iteration (easy in this case, two weeks standard) and which day of which week (week one or two) it was, it was possible to predict with some reasonable accuracy whether the project (two week iteration) was likely to be landed (completed on time). A manager’s dream; instant at-a-glance status.

I was hooked. Any software process that provided such a simple way for everyone on a project to know where they were, at a moments glance, was a process that needed much more serious investigation. And so my foray into agile and lean software development practices was further accelerated.

–Dean Leffingwell

Announcing Scaling Software Agility, the book

Over the last two years, I’ve been writing a book on achieving enterprise-level software agility. I did so in the hope that what I and others have learned in applying the principles and practices of software agility at enterprise scale would benefit the software industry as a whole. Even more importantly, I hope to help all software practitioners –developers, testers, team leads, project managers and executives alike– achieve higher productivity and greater personal satisfaction in their every day working lives as they struggle daily to deliver quality software much more rapidly to the marketplace.

I’m happy to announce that the finished product: Scaling Software Agility: Best Practices for Large Enterprises, is now available on line and in mainstream bookstores throughout the US.

Scaling Software Agility: Best Practices for Large Enterprises

Based on my experiences of the last few years in coaching larger teams in their adoption of agile methods, I’ve written a new book which has just been published (March 2007) by Addison-Wesley. The title is Scaling Software Agility: Best Practices for Large Enterprises and it is available on line and at technical bookstores nationwide. Here’s how the book is described:

Agile development practices, while still controversial in some circles, offer undeniable benefits: faster time to market, better responsiveness to changing customer requirements, and higher quality. However, agile practices have been defined and recommended primarily to small teams. In Scaling Software Agility, Dean Leffingwell describes how agile methods can be applied to enterprise-class development.

• Part I provides an overview of the most common and effective agile methods.
• Part II describes seven best practices of agility that natively scale to the enterprise level.
• Part III describes an additional set of seven organizational capabilities that companies can master to achieve the full benefits of software agility on an enterprise scale.
  

This book is invaluable to software developers, testers and QA personnel, managers and team leads, as well as to executives of software organizations whose objective is to increase the quality and productivity of the software development process but who are faced with all the challenges of developing software on an enterprise scale.

Click here to learn more about Scaling Software Agility.