Agile is considered a mainstream approach for software development these days. In my frequent conversations with software engineers and business analysts from various parts of the world, the majority of people report that they are working in an “agile environment.” When I look at the process these teams use, though, it becomes clear that they aren’t using the term “agile” in the same context that true agilists use it. They may be working in iterations, using a ranked backlog, and adopting Scrum as their “agile project management framework,” but they aren’t embracing the principles of the Agile Manifesto. There’s a clear disconnect between what these teams are doing and what is considered “agile software development” by the people who started the agile movement.
PMP Training – Resources (Intense)
Take, for example, the following process, used by many organizations that claim they’re “going agile”:
- A business analyst talks to the customer and prepares detailed requirements for the solution as a whole;
- The customer signs off on the requirements, which are then delivered to the development team;
- The development team splits the requirements into user stories, estimates and prioritizes them, and starts to produce the code using an incremental/iterative model, but keeping it behind walls until the entire solution is ready to go through user acceptance testing.
The process is far from compatible with the agile principles:
- It doesn’t satisfy the customer through “early and continuous delivery of valuable software,” since the solution is only accessible to end users when the whole set of requirements has been implemented;
- It doesn’t allow developers to adjust the next iterations based on early feedback received from end users, or to reflect changes in requirements resulting from new developments in the customer’s business or competitive landscape.
More and more software teams are doing work based on a prioritized backlog of user stories, and relying on a Scrum framework or Kanban board to manage projects. It’s tempting to say that these teams are “agile.” Yet, if your team can’t make updates in the course of projects when discoveries invalidate some of the requirements, or your projects are still subject to budget and schedule controls typical of waterfall projects, or end users are only engaged at the very end of the project rather than asked to provide feedback early and often, it’s simply not correct to call these teams and projects “agile.”
Agile Is All About Embracing Change
An important condition for agile adoption is the ability to change fast. And we’re not talking about superficial changes here: The change must be capable of creating value for a customer (which could be a buyer, end user, project sponsor, etc.) If the only change that’s possible in your projects is relative to how requirements are split into user stories, and in which order you’ll build the features already planned for a release, you’re not doing agile development. These examples of changes only represent an internal convenience for the project manager and/or technical team; real agility is focused on the actual value delivered to customers, such as fixing a feature that turned out not to be as useful as expected, or removing a capability from scope when it becomes clear it’s no longer a value-adding feature.
Not All Software Projects Are Suitable for Agile Development
So far, what I have described is an inadequate model of iterative software development in which all the requirements work is still done up front, and the only things that are subject to iterations are the implementation and unit testing aspects of the work. This approach eliminates the benefits of “going agile,” since there’s no opportunity to get feedback from users after each development cycle so the team can learn from it to improve the quality of the solution.
On the other hand, there are many legitimate reasons for a team not to adopt agile development that aren’t related to an incorrect or narrow interpretation of what “going agile” means. Some types of projects require an amount of coordination, planning, and synchronization of work that drastically reduces the benefits of using an agile approach. Large legacy systems, systems with multiple interfaces with other applications, and data-intensive solutions, are examples of applications for which embracing change throughout the development cycles may not be a valuable or feasible idea. These kinds of projects are more likely to succeed using some type of hybrid software development model in which portions of the solution (such as the user interface) are allowed to change more frequently based on user feedback, while others (such as the architecture or data model) are subject to more rigid controls.
Imagine a monitoring tool used to immediately alert operations when a problem occurs with a key server process or queue to prevent technical issues from creating serious financial impact for the business. If changes are made to the source systems without proper communication and coordination with the team responsible for the monitoring tool, the alert solution could stop working, exposing the organization to unacceptable risks. In a situation like that, it shouldn’t be possible for the team responsible for a monitored application to unilaterally decide to “go agile,” and start making changes to their solution based on customer feedback. Unless the changes are communicated in advance, and the effort is coordinated with the monitoring team, the consequences could be disastrous for the business. Under these circumstances, the ability to “immediately add value to end users” becomes less important than ensuring the monitoring and alerting system remains effective. It’s normal to see, in these cases, an interval between planning and delivery of solutions that is much longer than what you would find in a pure agile approach.
If your organization is still transitioning into an agile model, or has decided to adopt a hybrid model that incorporates some agile principles but preserves elements of a planned approach, it’s better to avoid stating that you work in an agile environment—even if you’re using a Kanban board or delivering working software every two weeks. Your credibility with peers and hiring managers will grow if you can talk about your software development experience in more specific terms than using the generic name “agile.”
When discussing your experience with agile software development, you should be able to articulate the limitations associated with your team’s use of agile methods and principles. For example, you could mention that your team has moved toward a more iterative, customer-centric approach for the user interface aspect of your projects, presenting end users with wireframes and prototypes to get early feedback and adapt. And then describe how you’re maintaining a plan-driven method of delivery of the overall solution, with longer periods between releases due to interdependencies with other systems. As previously mentioned, this is an entirely valid approach in certain environments where the frequent delivery of working software would be counterproductive due to technical dependencies and compliance issues. Familiarizing yourself with the principles behind the Agile Manifesto helps, enabling you to describe the aspects of your team’s software development methodology that are and aren’t aligned with the agile approach.
The end goal is not to “go agile,” but to create business value
Keep in mind that agile methods aren’t the only approach capable of delivering superior results in software projects, and that many of the positive elements of agile (such as iterative and incremental development) have been around for much longer than the Agile Manifesto. There are plenty of companies that do not follow the agile principles, but use an iterative process that’s far superior to the traditional waterfall method, and deliver results that are as good or better than agile approaches. Smart iterative models, whether they’re part of the agile umbrella or not, allow risks to be mitigated earlier, make change more manageable, and enable the project team to learn along the way, leading to better overall quality of software.
More important than being able to say that you’re in an “agile team” is to strive to be in a team that creates business value. This is achieved by avoiding overwhelming procedural control and mammoth documentation, using the right amount of agility to cope with changing business requirements, and bringing good practices, phases, and deliverables from a variety of approaches to increase customer satisfaction and remain responsive to changing business environments. Below is a checklist you can use to determine whether your team is set up for success, regardless of the software development method it uses:
1. You have a process in place to validate the solution throughout the project. Without constant validation that the solution under construction will indeed address the problem to be solved or opportunity to be exploited, no amount of good software development practices is going to help a software project succeed. In practice, this means involving end users and other stakeholders throughout the development cycle to provide feedback as early as possible. Prototypes, demos of working code, storyboards, and other methods can be used throughout the project lifecycle to validate that the solution will indeed satisfy business and user needs, and course-correct if it turns out it won’t.
2. Your team has the power to change its deliverables when new information becomes available that changes the original assumptions. Few things are more wasteful in a software initiative than realizing, mid-project, that the solution will not generate the expected impact, and being unable to adapt. If new information (such as a change in business goals, or the realization that the existing design overlooked a critical feature necessary to ensure user adoption) surfaces during the project, the team should have the power to accommodate the necessary changes: modify system behavior, include or exclude features, make technical changes to improve performance, and so forth.
3. Your team has the power to change the processes and practices that aren’t working for them. For example, in an agile environment, the team should be able to decide that user stories are not applicable to an integration project whose objective is to make legacy information available online, and choose a different approach to capturing solution requirements for that project. Conversely, if in a plan-driven organization, long requirements documents are making it difficult for business stakeholders to understand and sign-off on a proposed solution, the team should be capable of deciding to adopt user stories and acceptance criteria as the means to communicate the capabilities to be delivered, if they prove to be a more efficient way of achieving consensus among different groups.
If the three statements above are true for your organization, you’re embracing business agility in your software projects, which is way more important than following any agile or plan-driven approach to the dot. If they are not true yet, these are things to focus on improving, rather than attempting to blindly follow a “flavor” of agile just because it’s popular, or a different team reports being successful with it.