PM Articles > Alan S. Koch > Agile Compromises: Being Agile in the Face of Reality

Agile Compromises: Being Agile in the Face of Reality

by Alan S. Koch, PMP

The Agile software development methods provide us with good practices that are based on a system of coherent Values and Principles. They are quite different from traditional software development approaches, but many organizations have found success with them. So how hard can it be to use them?

As many organizations have found, the challenges can be significant if they don't happen to be developing software in the Agile Sweet-Spot:

  • A single customer who is willing and able to collaborate with the Agile team
  • A project that consists of a single Agile team or a coordinated set of Agile teams
  • Requirements that can be worked out incrementally
  • A product that lends itself to incremental development and testing
  • Senior stakeholders and staff who are willing to deviate from the traditional ways of running software development projects
While the last item in that list can be addressed thru education, training, and a bit of process reengineering, the others can be more intractable.

A recent client found that this was their situation. As a software development team in a hardware manufacturer, they are one of two development teams on projects to develop new products that consist of both new hardware and new software. They recognized that a more agile approach could be beneficial to them. But they are about as far from the Agile Sweet-Spot as they can get!

  • The ultimate customers for their products are inaccessible to them. The best Product Owners they could hope to identify are the Product Managers who define the products or the Systems Engineers who specify them. But neither of these groups is willing to work with the Agile team.
  • The other team on the project is doing hardware development using a traditional waterfall-ish approach. I'm not sure if hardware can be developed using an Agile approach, but that is a moot question, since the hardware team is not going to change any time soon.
  • The System Engineers develop a traditional Requirements Specification that defines the requirements in great detail and allocates those requirements to software or hardware.
  • The product cannot be tested until the end of the project when both the hardware and the software are available.

Does that mean this software development team can't be agile? While there may be some agile practices they can't follow, and others that they will have to adapt, this team is most certainly being agile as they adapt their agile practices to the realities of their situation. Let's take a look at the adaptations (and compromises) they are making to be as agile as they possibly can.

Unwilling Product Owners

Scrum calls the Product Owner the "Single Wring-Able Neck" because this one role is the most important member of the Agile team. This is the person who tells the team what to build, and who evaluates what is built and provides critical feedback on it. An Agile team without an effective Product Owner is severely disadvantaged!

My client team has found that asking their target Product Owner (the Systems Engineers -- SEs) for broad cooperation did not work because the SEs are already overworked. So the Agile team is changing to a more targeted approach of asking specific questions that will help them to focus and validate their work. For example, instead of asking the SEs to review their Use Cases (hundreds of pages), the Agile team will ask specific questions about individual Use Cases about which they have concerns. (See "Traditional Requirements Specification," below)

You can't force an unwilling party to cooperate with you.

You can't force an unwilling party to cooperate with you. But by making your requests quick and easy to answer, you are more likely to get responses. And over time, the unwilling party will (hopefully) begin to see the value they can gain thru collaboration.

Non-Agile Parallel Team

The pace and cadence of work on an Agile team is unlike that of teams using any other approach. This makes any coordination or integration between an Agile team and a traditional team very difficult to work out. In most cases, the Agile team will need the collaboration or integration activities to happen long before the other team is ready to do them.

My client team was unable to integrate and test their software with the hardware the other team was developing until the end of the project. This testing was often delayed by late deliveries, and fixing defects found so late in the project presented significant problems.

They are addressing this problem in two ways. First, because the hardware requirements are available to them, they are able to build simulators that allow them to begin testing their software as early as they wish. And second, the hardware team delivers any prototypes they build to the software team after validating the prototypes' functionality. This allows the software team to replace their simulators with the prototypes to improve the validity of their testing.

There is no way for them to avoid end-of-project integration testing when the final hardware becomes available. (See "Big-Bang Integration Testing," below.) But by increasing their opportunities to do good testing earlier in the project, the software team will reduce the potential for unpleasant surprises at the end.

Look for the less obvious opportunities to collaborate.

When other parallel teams are using approaches that fail to mesh with your Agile team's timeline, look for the less obvious opportunities to collaborate with them. It may involve you giving early information or product iterations to the other team(s). Or it may be a matter of finding ways to get and capitalize on the other team's intermediate work products. Either way, over time, the other team(s) will (hopefully) begin to see the value they can gain thru earlier collaboration and integration.

Traditional Requirements Specification

Traditional Requirements Specifications are the opposite of the Agile approach of progressive requirements elaboration. In addition, (as we all know) even a thousand-page specification will still leave questions unanswered. How can you be Agile when your customer tosses a Requirements Spec over the wall to you?

My client team has dealt with this issue by distilling the specification into a more agile-friendly form. They start by reviewing the Requirements Spec to understand how customers will actually use the product, and then writing a complete set of Use Cases for the product. Then, based on those product Use Cases and the Requirements Spec, they write hundreds of more detailed Use Cases to describe the required software functionality. The team uses these software Use Cases (the moral equivalent of User Stories) to plan and do iterative development of the software.

As was noted above (in "Unwilling Product Owners"), they were not successful at getting their Product Owner (the Systems Engineers -- SEs) to review these Use Cases. So their new approach is to peer review the Use Cases within their own team. Then any confusion or questions that are identified in these reviews will be sent to the SEs for clarification.

There is no reason to artificially impose an incremental approach.

It is true that defining the requirements up-front is decidedly not Agile. But in cases like this where someone has already worked out the detailed requirements, there is no reason to artificially impose an incremental approach. Use what you are given to create User Story-like requirements so that at least the development can be done incrementally. And of course, you will discover requirements questions throughout the project, and you will have to get the answers to them as they arise.

Big-Bang Integration Testing

When your Agile team is working in parallel with other non-agile teams, there is almost never a way to avoid the end-of-project integration testing phase. You can't test what is not available, so if other teams have no product until the end of the project, integration testing must wait until that time.

My client team (as described in "Non-Agile Parallel Team," above) mitigated the risks associated with the necessary big-bang approach to integration by expanding the testing they are able to do during their iterations using simulators and prototypes. While there is no guarantee that the final hardware will operate as the simulators and prototypes do, this will allow the software team to fix most of their software defects prior to integration.

The team will also be using the precepts of Risk-Based testing to plan the integration testing approach. Their use of simulators and prototypes for testing within their iterations will allow them to identify potential integration issues (risks) ahead of time. They will then plan to test for those identified risks as early as possible during the final integration phase so there is as much time as possible to correct any problems associated with them.

Final testing just before release is not unheard of in Agile projects.

Final testing just before release is not unheard of in Agile projects. Scrum defines the idea of a "Stabilization Sprint" to ensure that the product is ready for release. But that is not the time to be doing any testing for the first time. When your context forces you to do this, you must take every step you can to mitigate the associated risks.

You Don't Get to Pick "Agile" or "Not Agile"

In his foreword to my book Agile Software Development: Evaluating the Methods For Your Organization, Kent Beck (the author of Extreme Programming Explained) wrote:

In the end, agility is simply a measure of software development. How agile is yours? Not very, taking years to respond to change? Very, responding in hours or days? Your software development lives somewhere on the continuum already. You don't get to pick "agile" or "not agile." The question is is your agility enough for your organization and if not, what are you going to do about it?

Not being in the Agile Sweet-Spot doesn't mean choosing "not agile." Rather, it means figuring out how agile you can be within your constraints, and moving in that direction.




Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Post a comment




(Not displayed with comment.)









©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.