Over a million developers have joined DZone.

Agile thinking in action: A tale of two projects

· Agile Zone

Learn more about how DevOps teams must adopt a more agile development process, working in parallel instead of waiting on other teams to finish their components or for resources to become available, brought to you in partnership with CA Technologies.

These past few weeks at Lean Dog Software, there have been two project teams working on the main deck...er, that is, in the main room of the boat; the room that used to be the main seating area when the boat was a restaurant. It occurs to me that these two teams exemplify the right way to apply agile software development values and principles.

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.
For the bug-fix project, most of the standard iteration management overhead did not add value. Lacking participation by the product owner or any other responsible business stakeholder, there was no point in presenting demonstrations every two weeks. Without a defined scope other than an initial bug list, there was no need for "course corrections," one of the key value-add aspects of planning to multiple horizons. Since every work item was a bug fix, there was no value-add in going through any sort of estimation or sizing exercise. Since the goal was simply to squish bugs, there was no value-add in using velocity as a measure to project a completion date.


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 project was only two weeks in length and was aimed, in part, at helping the project sponsor understand what was possible and how best to realize his vision for the product. For those reasons, it would have made little sense to stick to a two-week iteration length just because the process framework suggests two-week iterations. Instead, the team demonstrated each feature as soon as it was done, or in some cases while they were working on it, so that they could give and receive immediate feedback. Since there were no external dependencies, legacy system interfaces, or backward compatibility issues, the team could place incremental results directly into the client's hands with no delay. With no legacy code to worry about, the team drove 100% of development with TDD techniques, using the BDD tools rspec for the Ruby code and Screw Unit for the jQuery code. The result was super-clean code that was very easy to modify as the client learned more about his needs and refined his product vision.

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."

Discover the warning signs of DevOps Dysfunction and learn how to get back on the right track, brought to you in partnership with CA Technologies.


Published at DZone with permission of Dave Nicolette. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}