In Agile iterative software development, it is often the case that at the end of every iteration, the new features created during the iteration
Requires Free Membership to View
are released to production, for the
benefit of the users of the software. This is an excellent way to work, for many reasons.For one thing, the end of an iteration is the time for retrospectives. During the iteration, the team is busy doing the actual work of designing, coding, testing, and getting ready for deployment. But after the iteration's stories are "done done" and released to production, the team can take some time to reflect on the work of the last two weeks, analyze what went well and what did not, and make changes to their process to improve the situation for the upcoming iteration.
The end of an iteration also is a time to celebrate the accomplishments of the finished iteration. This celebration is an important part of the work, and does not get nearly the emphasis it deserves. An end-of-iteration celebration is not only good for team morale, but such activity can have an influence far beyond the team itself.
Bring in the audience
In many cases, a group of software users can behave in the same way as the audience for a performance. I once worked for a very high-performing Agile team. Like clockwork, we released new features every two
weeks, iteration after iteration, year after year. And over time, we discovered something
interesting about our users.
This was a hosted application. That is, the software itself lived on a big server farm, and most of
our users connected to it over the Web. It was an extremely flexible and configurable application,
so our users came from every sort of enterprise, from automobile manufacturing to record companies.
For many of our users, our application was a central feature of their own process management, so we
were important to the success of a wide range of businesses.
Our track record of releasing new features reliably every two weeks became interesting to a
significant fraction of our most important customers. We had people from all over the business
world tracking our release pipeline. Our maintenance window for the hosted application was every
other Saturday. So every other Monday morning, businesses all over the world would immediately
begin exploring the new features we had just created. We got feedback. We surely did get
feedback.
For one thing, many of our customers would immediately send email or call us directly with praise
(usually) or criticism of whatever we had just released. That kind of instant feedback was
instrumental in our decisions about what to include in the next few iterations. And it was a great
celebration, also. Every other Monday morning brought smiles and conversations as our audience
chose to share our own celebration of our work of the last few weeks.
For another thing, we were able to parse our server logs in real time, and actually see and
understand how our users were interacting with the new features. This was a critical feedback
channel. Unlike traditional usability studies where individuals are artificially isolated in a test
lab, these were real users in the wild, operating and reacting in the same way that an audience
interacts with a performance. When we saw lots of people invoking our new features, we knew we had
a hit on our hands. When that didn't happen, we knew that we had to change our approach. This sort
of observation worked in the same way that applause informs a performance.
Against lean/kanban
Some time ago I wrote three posts in my blog called "Against Kanban" that generated a significant amount of controversy. Here is a part of one of them:
The idea that at a certain time, we will release a predictable and well-known set of running, tested features to production, over and over again, reliably, puts the emphasis on actually shipping things for people to use. This emphasis on succeeding within a time box consistently (and the subsequent celebration by both the Agile team and by the customers!) is utterly critical to the success of Agile teams, and lean/kanban throws it out the window.
I had a number of lean advocates tell me that "you can still have iterations with kanban", but the radical de-emphasis of the time box and of the ceremony of releasing features to the customer at the end of every scheduled development cycle is a huge step backward. In other writing I have suggested that software development without a regular, public, scheduled, celebrated release of features to production cannot be Agile, regardless of what other processes are involved in such software development.
I have also worked on an Agile team who adopted a kanban-like approach. I found it both
depressing and oppressive.
Without the rhythm of regular iterations, retrospectives became haphazard and disjointed. We lost
important information about the function of the team as a whole. Lean/kanban, like Six Sigma and
ISO9000, is a methodology appropriated from the manufacturing sector, and such methodologies tend
to reduce the role of software development team members to merely stations on an
assembly line. Under these conditions, software development becomes soul-killing work, and software
development should not be like that.
Also, applying processes from manufacturing to software development eliminates the possibility of
celebration. There is no set time when the software creators and the audience for their software
get together to exchange information about the latest work. There is no performance, there is no
applause under these conditions.
Find a specific time and place to celebrate your work creating software. Enjoy that celebration
with your audience. This practice will improve morale, improve feedback, and improve the business
of creating software.
This was first published in December 2010
Join the conversationComment
Share
Comments
Results
Contribute to the conversation