When defining the strategy of a given project based on it's mission to deliver well-defined goals to meet the organization's vision, how do you employ the philosophy of agility as well as it's quality attributes such as speed, value, etc?
Another way of asking the question possibly would be is how does one use Agile to define a strategy of a given project?
Because Agile is a set of values and principles, there is not a set "Agile" way to approach strategy. If you're looking for a pure step-by-step, SAFe talks a lot about strategy or, if you don't want the whole framework, this article has some good stuff around using lean canvas for portfolio management.
Of course, those are just other people trying to address strategy in a way that fits with the Agile values and principles. We can also just look at the Agile Manifesto and let that guide us. For example, let's look at the values:
Individuals and Interactions over Processes and Tools
Too often, strategy discussions focus on a few people making decisions with charts and matrixes in a vacuum. This is appealing because it's fast, efficient, definitive, and it isn't hindered by the complexity of different users wanting different things. It's easy to decide what the right path is, "prove" it on paper, then tell the rest of the company. Somewhere, on paper, Microsoft's Zune was a sure thing.
We don't want to try to guess how users will behave. Agile approaches to strategy rather look at how the real users behave and adjust the strategy to match that. Eric Reis' Lean Startup shows one way that organizations can guide their strategy based on how its customers and stakeholders actually behave rather than on a set of tools and processes.
Working Software (Product) over Comprehensive Documentation
Some companies spend incredible amounts of time designing their enterprise architecture. The problem is, you can't test design. Big up-front strategy efforts are based on a lot of untested assumptions. It's important to find ways to put pressure on your strategy as quickly as possible in order to identify where the weak points are and correct them.
Customer Collaboration over Contract Negotiation
This may seem strange, but it makes perfect sense when you get to the underlying goal. When you write software, the customer's understanding of their needs evolves. The same thing happens with strategy. Your market will evolve as you show them what is possible. If you have a good strategy, you will actually turn your market into a moving target, which is good because you are driving the movement and your competitors are trying to follow. Make sure your strategy process is built to be able to move right along with it. There's a great book called Blue Ocean Strategy that talks a lot about this concept. It doesn't frame the idea around Agile, but if you read it from that mindset you'll find a lot of parallels.
Responding to Change over Following a Plan
This one doesn't need much explanation. Planning is critical, but most plans are worthless. It's no different with strategy than it is with anything else.
You could, of course, go through the principles in the same way. The goal of the Agile manifesto is to refocus on what's important and those things apply just as well at the strategy level.
I hope this helps. I wish there was an easy 1-2-3 answer. It would make my job a lot easier. There is good stuff out there though and a lot of information to dive into.
Some companies spend incredible amounts of time designing their enterprise architecture. How would you approach enterprise architecture if you are not addressing the larger landscape of people, processes and technology?
Commented
Dec 31, 2015 at 17:44
strategies?
Commented
Dec 31, 2015 at 17:45
Simply put: if the project strategy is to take an evolutionary approach, then you are agile. If you can show some initial features in a couple of weeks time, then go from there, then you are agile. If the project "customer" - whether they are internal or external - want to see a big upfront design effort, then it is usually not agile.
To employ agility in defining the project strategy, use an agile framework (like Scrum) for project's methodology, and also, set the review/stakeholder progress checkpoints to be iteratively defined. That means, that almost by definition, you won't be able to tell your sponsors today what they will be reviewing, 1, 2, 3, .. 6 months from today. You can tell them what they likely will be reviewing 1, 2, 3, ..., 6 months from today, but also tell them that all subsequent points are up for discussion and that the customer will be able to change directions after the first and after each checkpoint.
