Agile thinking in action: A tale of two projects
Agile thinking in action: A tale of two projects
Join the DZone community and get the full member experience.Join For Free
You've been hearing a lot about agile software development, get started with the eBook: Agile Product Development from 321 Gang.
Most teams that are trying to work in the agile way have taken the approach of following a published methodology (or one taught them by a vendor or consultant) more-or-less by the book. When the standard process they are using doesn't happen to fit their circumstances, they struggle with following the particular practices, rituals, or ceremonies mandated by the formal methodology they are using. It is as if they believe they are not "allowed" to change anything.
To me, this illustrates a basic misunderstanding of agile development. The defining document of the agile movement, the Agile Manifesto, quite intentionally remains silent about specific process frameworks and methodologies. Instead, it states four basic values and twelve supporting principles. People interested in applying these ideas to their work are expected to craft a process that works in their circumstances, using the values and principles as a guide.
The very first of the agile values elevates individuals and their interactions over processes and tools. Yet, many agile practitioners behave as if they are slaves to a process.
That said, there are a number of "standard" process frameworks and methodologies that are based on the agile values and principles. Any of these can be very useful as a starting point for teams and organizations that want to move toward an agile style of work, but are uncertain how to get started.
Once they have gotten started, however, people should avoid the trap of following their initial agile process by rote. Once they begin to internalize the values and change their organizational culture, they will have diminishing need for the structure these process frameworks provide. Some of the rituals and ceremonies of the formal process will become overhead activities that no longer add value. The concept of continuous improvement is key to success in getting value from formal processes and methodologies without becoming enslaved by them.
Lean Dog is a software development consultancy that specializes in agile. The organizational culture is totally agile. They have a basic process framework they use in the initial stages of an engagement and that is comprehensible to prospects when they describe it. The basic process framework is one that will be familiar to most agile practitioners circa 2009: A ThoughtWorks-style combination of Scrum and Extreme Programming with an iteration length of two weeks. Once they understand a client's needs more fully, they adapt this process to maximize value delivered and minimize procedural overhead, with the agile values and principles as their main guide.
One of the two projects carried out in the main room had the following characteristics (of course, I have to keep the description general enough that the clients aren't identifiable):
- Defect resolution in a legacy Java code base
- The legacy code had no test suite at the outset of the project
- The legacy code gives no indication of conscious design intent or basic competency in software engineering
- The legacy code has many dependencies on network resources, including back-end mainframe systems; code is monolithic and difficult to isolate for testing
- The team has no access to the back-end portion of the applications or the mainframe-based data on which testing is dependent
- The project sponsor has no interest in collaboration and does not attend iteration demos, retrospectives, or planning meetings.
The team adapted their process appropriately in the face of these realities. They stripped out all the iteration management overhead with the exception of the retrospective. The retrospective added value since the client and consultant team members did identify issues and follow up on them. Because of the dependencies on external systems, the team deployed to production every two weeks rather than pushing every bug fix to production as it was completed. These two aspects of the basic process continued to add value, so the team continued to use them. Otherwise, for all practical purposes, they were running a sort of "kanban" process on this project, although they continued to use the terminology of iterative development.
They dispensed with sizing each work item and simply declared them all of size "one." They continued to have a brief discussion about sizing at the start of each iteration, but the purpose of the discussion was to give team members the opportunity to say whether they believed a given bug fix looked like it would be substantially larger than normal. The team spent less than a minute every two weeks talking about this topic.
IMO these were pragmatic and value-focused adaptations of the basic two-week iterative process framework. They were able to deliver the maximum possible value to the client.
The second project had quite different characteristics:
- Greenfield development in Ruby on Rails and jQuery
- Clear product vision but high uncertainty about details
- Highly engaged product owner / project sponsor; often present on the boat
- Relatively simple technical environment; a web application with no external dependencies or legacy system integration
This team did not hold any sort of formal iteration or release planning meetings. Since the product owner was on board most of the time, when they needed clarification of a requirement or they needed to inform the PO that a feature was turning out to be larger than anticipated, they just discussed it on the spot. I saw them collaboratively adjust backlog priorities many times as the work progressed. They didn't hold scheduled retrospectives because they constantly observed and discussed their own work practices. They retrospected just fine; they just didn't need the overhead of scheduled meetings.
The object lesson for the rest of us is that we can and should adapt the process we are using in whatever ways are appropriate to ensure we deliver the maximum possible value to stakeholders while incurring the minimum possible waste. To be able to do so, we must understand what the agile values and principles actually mean on a practical level, and which practices implement those values and principles effectively in a specific set of circumstances. Initially, this may mean we ask our teams to follow one of the published process frameworks by rote until they begin to internalize the values and principles. Once they do, we need to start letting them carry the values and principles forward on their own initiative. That, and not following an agile-branded process by rote, is what it means to "be agile."
Published at DZone with permission of Dave Nicolette . See the original article here.
Opinions expressed by DZone contributors are their own.