This month’s theme at ProjectManagement.com is “Strategy Alignment/IT Strategy.” This can seem at odds for agile teams who organically grow solutions towards evolving requirements. Where’s the strategy in that, and how do we promote empowered teams while preventing chaos? Most organizations spend considerable time and effort developing strategic roadmaps and they don’t want this work undermined by unordered development.
Fortunately, hope is at hand with some well proven models. While the common kernel of agile practices make little mention of strategy or architecture, many of the supporting guides and scaling approaches handle the topic well. So, when faced with a criticism of no place for IT strategy or struggling to link an existing strategy to an autonomous team we can turn to these agile “wrappers” for inspiration and guidance.
You do not have to be using these approaches as standards at your organization to make use of the integration points and approaches they recommend. Instead see how strategy and architecture are handled and then apply a similar approach in your project and organization.
Dynamic Systems Development Method (DSDM) is an agile approach that started in Europe and covers a broader project lifecycle timeline than most agile methods. It starts early with Feasibility and Business Study phases goes beyond deployment to handle Post Project work. Unlike most agile methods that don’t mention architecture DSDM has an architectural deliverable called the System Architecture Definition (SAD) that is created early on in the Business Study phase.
Agile projects struggling to appease architecture groups and facing criticisms of lacking strategic alignment, could look to the DSDM System Architecture Definition as a template for an early project, light-weight solution. DSDM also fits well with The Open Group Architecture Framework (TOGAF) standard and there is a White Paper on DSDM and TOGAF Integration White Paper here.
The Scaled Agile Framework (SAFe) is a knowledge base for implementing agile practices at enterprise scale. It presents this information through a Big Picture View that shows how the work of agile project teams can be rolled up into programs with their own program backlogs. Then explains how programs fit into larger portfolios that implement product investment and strategic themes.
At the SAFe Portfolio level there are Business Epics that are far reaching business objectives that may require multiple programs of projects to achieve. There are also Architectural Epics that are far reaching IS Strategies that are then manifested through programs and project teams. Within SAFe the role of the Enterprise Architect is defined as a “responsible authority with the requisite knowledge to work across programs and help provide strategic direction that can optimize enterprise outcomes”. More details can be found here.
Disciplined Agile Delivery (DAD) is a hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle that is goal-driven, enterprise aware and scalable. It extends popular agile approaches such as Scrum both “left and right” to include pre-project work and post-project work as DSDM does. It also expands “upwards” to provide enterprise adoption and scaling guidance similar to SAFe (that may recommend using some components from SAFe).
One of the early activities when using a DAD approach is “Identifying the Initial Technical Strategy”.
The technical strategy is likely to evolve over time as the team learns throughout the project, but at the beginning of the project the team needs an initial direction in which to go. This is important for several reasons including to:
- Get going in the right direction
- Secure funding
- Leverage organizational assets
Large Scale Scrum (LeSS), as the name suggests, is a scaling framework for Scrum. Like SAFe and DAD it provides help and information for people trying to use agile beyond just small teams often in large enterprise environments. It provides lots of good advice on Architecture in LeSS and like DSDM uses the concept of System Architecture Documentation (SAD).
There is less of an acknowledgement of value in strategy documents, but instead good strategies for getting technical leaders involved in code reviews and creating a Design/Architecture community of practice. Other recommendations like not letting architects hand off to coders and not waiting for approval reviews by experts might seem counter strategic, but highlight some real concerns seen on projects and are worth considering.
Agile methods may seem to lack strategic alignment but there is no shortage of good public domain guidance to supplement them. Also because they originate from agile sources they do not recommend impractical solutions or use incompatible terms and wording. When next faced with an opportunity to tie an agile project to strategy examine these models to see how they can help.
(Note this article was first published at ProjectManagement.com here)