Adapting to Change in Your Agile Strategies

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.

User Comments

1 comment
Doug Shelton's picture


This article is "right on".  I see altogether too much "purist" responses from very senior aglists who tend toward the "small", more XP-thinking side of things which tend to totally ignore the strategic needs.  

Yes, I believe we all know that often - no matter what is planned - code will **still** need to be rewritten.  That is the philosophy that espouses "just go ahead and write the code and get out market value as fast as you can".  But - as you aptly presented in your article - the reality is that one cannot "jam out" code in weeks that a company can use - they need the "whole shebang".  

So I see another conclusion that one can find in the company example you gave - i.e., apart from the conclusion of having a small "group" of stratagists as opposed to just one "magic person":  i.e., **always** write code that is as modular as possible and is always Loosely coupled - even if doing so takes longer than writing code which ostensibly "gets out the door sooner". Why?  Obviously - as in the case of the company you referred to, so that one does not necessarily **have to** throw all the original code away, but has a **foundation** which can still be reused for the new code that has to be written to meet those new strategic needs.

As such, this is where I think Enterprise Architecture still has a viable role - a top-notch architect should be included in this "small group" of strategists - hopefully one who has "hands-on" experience with coding as well, so they don't simply dictate architecture based on "white papers" instead of "real" knowledge.

November 9, 2014 - 1:49pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.