Adapting to Change in Your Agile Strategies

[article]
Summary:
Len Whitmore writes on using agile practices for the development of software. 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.

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.

About the author

Len  Whitmore's picture Len Whitmore

Len Whitmore is currently on assignment as a project analyst at Siemens Healthcare. He is a business analyst and Certified ScrumMaster with a passion for agile software development. A veteran with more than ten years of teaching leadership, Len has more than twenty years’ experience covering the gamut of strategy, analysis, program development,QA, product management, operations, and technical documentation gained from developing and supporting projects and solutions incorporating a wide range of applications and technologies.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!