Adapting to Change in Your Agile Strategies

While researching information for this article, I found a number of strategies to implement agile software development practices and methods; however, when investigating actual agile-based strategies, I found little information.

In the ten years since the Agile Manifesto, the agile development domain evolved, as evidenced by such things as the six levels of planning: strategy, release, iteration, daily, and continuous, with strategy appearing to be the least evolved of the planning levels. This is due to multiple factors, including: strategy planning not being perceived as needed, with teams simply “diving in” to agile projects, or strategy still being done as it is in traditional development, with some “minor” adjustments.

While most project stakeholders focus on the vision and the business strategy, in reality, software projects usually involve an IT strategy. If a team says “We are using Scrum,” because agile software development practices serve as an embedded plan of action, the team chose the strategy of “agility” with the goal being “provide value in the completion of a given project.” Some teams may figure they have all the strategy needed when they choose an agile software practice for the project; however the IT strategy is used in conjunction with the business strategy, forming a general strategy. In using agile practices for the development of software, these agile methods adapt to changes in the general strategy as we develop incrementally and iteratively, address risk first, and understand and manage change.

Allow me to use a story to illustrate what happens when the strategy changes in the middle of an agile project. Please remember it is just a story and any resemblance to actual events is purely coincidental.

This story is about a well-known large enterprise (WKLE) that wanted to revitalize itself in the marketplace. The executives came up with a multi-year plan, which included hiring an interactive digital agency to help develop a business strategy to get the marketing message out. In part, this meant replacing the entire enterprise website, as just looking at the crazy color combinations was enough to give you a headache.

This enterprise had determined a vision without knowing how to get there, so the interactive digital agency went right to work formulating a strategy for the enterprise. This was unusual because the digital agency was helping with the enterprise’s business strategy, as opposed to a marketing campaign or something equal to that. Since strategy development was one of the services offered by this interactive digital agency, the WKLE was assigned a strategist—one of those quintessential geniuses in the dark corner, where they supposedly practice mystical arts.

Economic times were good when this engagement began, so the strategy geniuses came up with a strategy known as “get a greater percentage of your current customer's wallet” by building a website that displays different content depending on the visitor’s profile: title, role, company, etc. In phase two of the strategy, these profiles connect with the client relations management system.

The WKLE thought this was a grand idea and spent the next six months determining the best content management system for them, which they then purchased.

Everyone closely involved with this project knew it would take quite a bit of time to do this, as you don’t replace a website with tens of thousands of pages in a week. Due to the long development time, changes in the requirements were expected. So, another part of the general strategy was that the IT portion of the development team would use Scrum. Scrum was chosen because it reduces distractions while still allowing for regular feedback and submission of new suggestions to mitigate all the changes in requirements.

The Scrum team sprang into action. Even though most team members were new to Scrum, things went pretty well at first. The client attended the sprint reviews every two weeks; the new site was taking shape. However, after seven sprints, the client said, “Hold on here, this is not what we wanted.”

More than a year had passed since the engagement with the agency began. As the economy fell downhill, the original business strategy of getting a greater percentage of the customer’s wallet was no longer viable. After the eighth sprint, the WKLE shut down all development until it could figure out what it really wanted and come up with a new business strategy.

Several months later, the new business strategy was unveiled with great fanfare: Show the market that the WKLE is an information technology company that solves your business challenges. This was actually quite difficult to display on the web, as the WKLE wanted to show all of its capabilities on the home page. Somehow the creative geniuses at the agency did accomplish it: A home page that did what the WKLE wanted and more.

All of the previous development was abandoned. By now some members of the original Scrum team moved on to other adventures in IT. New members joined what was no longer a true Scrum team. As Greg Robinson (a member of the Agile Group) puts it: “Most Scrum adoptions are not proper Scrum—Water-Scrum-Fall (WSF) being the most popular form of it (analysis phase, scrum implementation, transition [SIT and UAT] phase at the end). WSF is usually adopted because of entrenched management practices, vested interests, and general mistrust of anything associated with the word ‘agile.’”

Next, the WSF team began again to develop the new WKLE website. Months went by and the new website continued to become what the client wanted. During this time, changes occurred as they always do, and the WKLE hired a new CEO. So with the WSF team closing in on the end of the project at around sprint twenty-six, change happened again. The new CEO wanted the website to reflect his new business strategy, which was that the WKLE would focus on four key areas: Security, transformation, outsourcing, and modernization.

This time, due to their previous experience, the developers included a more adaptable design in their IT strategy. So, while it took what some would call a great deal of rework, most of what had already been developed stayed. Of course, members of the team still gnashed their teeth and morale sank, but with the contract extended along with additional funding, the WSF team finished and the new website went live.

Because we embrace agility, we know changes are going to occur in projects. In practicing agile software development, we are most aware of changing requirements during the course of the project. Few teams are as astute about agile strategy. That was the point of the story; that the general strategy for software projects can and does change. As a matter of course, too few teams are involved in strategy or agile strategy planning, let alone the changes that can occur. Often, teams simply dive into agile projects, allowing for agility to guide the project. At times, this works. At other times, without an agile strategy, the teams are short sighted in their solution, which can diminish overall value. In these instances, the team actually generates greater risk for the project, and shows a lack of discipline and due diligence, which results in more rework, lesser-quality code, technical debt, or outright failure.

Agile developers are not the only ones dealing with change. In fact, at a recent presentation I attended called “Business Success in the New Economy, Critical Business Practices for the 21^st Century,” Kitty Haas, who is the principal consultant at Kathleen Hass and Associates, Inc.; director at large for the International Institute of Business Analysis; and an author and lecturer in strategic project management and business analysis disciplines, spoke about an IBM CEO study that shows how CEOs consistently identify change as their most pressing challenge.

In the “IBM 2010 Chief Executive Officer Study,” the CEOs said that the complexity of operating in an increasingly volatile and uncertain world is their primary challenge and, further, this complexity is only expected to rise. For this study, IBM conducted more than 1,500 face-to-face interviews—the largest known study of its kind—with CEOs from companies of all sizes across sixty countries, representing thirty-three industries.

One set of organizations that the CEO study calls “standouts” are looking to turn that complexity into their financial advantage and find new ways to deliver value. These CEOs from the standouts recognized creativity as the most important leadership quality, which is interesting, as these creative leaders invite disruptive innovation and attempt to build operating dexterity. This is part of the change needed by enterprises to become more agile.

Being in the IT domain, it is easy for us to see the increase in complexities. With security, virtualization, and the cloud, for example, things like incident response just became more complex, as new participants—possibly with competing priorities—join the game.

It appears we have entered a whole new age in software that may become known as the complex adaptive system (CAS) era. This is a term I first heard used by Alan Shalloway, the CEO of Net Objectives. Whether he coined it, I don’t know; however, it is a major trend in software arena. In the story about the WKLE, the enterprise content management system is an example of a CAS in that it employs the user’s profile to adapt the content that the user will see under certain conditions.

In her presentation, Kitty Hass indicated that agile software development practitioners need to realize that their agile strategies must embrace creativity and innovation. For instance, business analysis and project management folks should use the business case for measuring the value and wealth generated by the project, instead of just using it to obtain funding.

One strategy that agile software development already has in place to deal with complexity is to slice or break things into small enough pieces that they are understandable and easier to work with by the agile development team.

There are other innovative strategies in agile software projects when dealing with the increased complexity.

In the story, if you will recall, there was a strategist, the individual in the dark corner, where he might be practicing black magic and mystical arts. Rather than a single individual coming up with the “aha” moment, with the increase in complexity would it not be better to have a small group of diverse folks come together and collaborate to form the agile strategy? There are some advantages to this approach. The most important advantage is starting sooner in the project the needed communication between those who want the software and those who will create the software. Another advantage is that the pool of knowledge would be larger and much more likely to draw forth a better strategy. Also, as previously noted, there is not just one strategy but a general strategy, with a business strategy, an IT Strategy, and maybe more. When there is only one individual, then there is the likelihood he will form just the business strategy and have to do a hand off to IT for its strategy, taking more time in the creation of a general strategy. This will take time to accomplish, as it requires change management, but will be well worth the effort.

The need to set aside time for strategic thinking can be considered as being “innovative.”

This set aside time does not have to be long, but it should be uninterrupted time, because it is hard to develop the big picture when the members of the strategic group are bombarded with calls, emails, or other interruptions.

Another thing you might recall from the story was how often the state of the economy was mentioned. This is important for strategy formation, because those formulating strategy need to be aware of things like major trends in the IT domain and an economy that can impact the strategy and project.

It is a new era, the era of complexity, with new opportunities to grow and evolve the strategic planning level in agile software development.