In Agile iterative software development, it is often the case that at the end of every iteration, the new features...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
created during the iteration 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.
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.