My current, favourite question for Executives and Architects is “How do you see Architecture operating in an Agile environment.” This question usually elicits a wry smile and a response along the lines of “I will need to get back to you on that!” Many people are wondering how Architecture will fair in the world of Agile. My answer is I believe very well!
Originally developed to deliver improved outcomes in software development, Agile was the hot management trend for 2017. There are a number of drivers behind this trend, but fundamentally executive teams are looking at new ways to deliver business outcomes and to create value in an environment of increasing complexity and disruption. They see Agile as a way of shaking up old paradigms by empowering their people to be more accountable for delivering outcomes and less constrained by traditional management frameworks and practices.
The principles of Agile are very straightforward. Agile methodologies focus on the following:
- Individuals and Interactions rather than processes and tools
- Working Solutions rather than comprehensive documentation and project plans
- Customer collaboration rather than contract negotiation; and
- Responding to change rather than following a plan.
For executives who are operating traditional bricks and mortar business and are seeing their core markets being picked off by smaller and more nimble competitors this is heady stuff. Agile promises a way to breakdown intractable bureaucracies and take on the new-comers at their own game. However, many organisations have learnt Agile won’t deliver the outcomes that executives want on its own. There needs to be something that focuses all of the creativity and energy engendered by the Agile way of working so that demonstrable business outcomes can be achieved. That something is Business Architecture.
For organisations there are three key questions that need to be answered. Why do we exist, What do we need to achieve and How will we do it! Most organisations are clear on the Why question which is usually articulated in their Mission and Vision statements. Most often this is determined by the board and/ or executive teams and communicated to management who then have to figure what they need to achieve to deliver and how are they going to do it.
I see Agile and Business Architecture as the perfect combination to answer these questions. Business Architecture answers the What needs to be done question while Agile provides an approach as to How outcomes will be delivered.
Business Architecture defines the business model, value streams, capabilities and initiatives (projects) required to deliver strategic outcomes, while Agile leverages the creativity of staff, and the ecosystem in which the organisation operates to find more innovative and efficient ways to deliver strategic outcomes.
Business Architecture takes an organisations strategic intent and defines not only what goals/ objectives need to be achieved but what needs to be done to achieve them. It provides a reference framework in which Agile approaches can operate and ensures that the outputs from the Agile processes are contributing to the organisations strategic goals.
So as Business Architects why do we need to care about, and understand, Agile. The reason is that no matter what our functional expertise, our core purpose is to deliver outcomes for the organisation. In the current environment Agile is fast becoming the preferred methodology to deliver outcomes.
In a recent CIO article on IT project success rates the author Sharon Florentine cited research from the Project Management Institute (PMI) that showed that success rates for IT projects are finally on the rise. The interesting insight as to why success rates are increasing is that organisations are measuring project success in what the author describes as a more mature manner. That is rather than looking at measures such as was the project delivered on time and on budget, they are measuring whether the project delivered the benefits that were required by the organisation. To put it succinctly ‘there is less focus on the means by which a project is deemed successful and more on the end: does the project deliver the business benefits promised?” This has been driven quite significantly by the blurring of the lines between IT and the business with many projects becoming more cross functional and multi-disciplined in their approach, which is fundamentally the Agile way of working.
This is not to say that business benefits weren’t considered as part of the traditional measure of project success but they were usually assessed once the project had closed. If the business environment and/ or needs had changed during the project lifecycle this measure may have become less relevant or in some extreme cases irrelevant. With Agile, organisations are looking at benefits (value in Agile terminology) right from the beginning of the project and they are constantly benchmarking their project outcomes against the required benefits. It all makes intuitive sense, which is why Agile is being embraced by so many organisations, but it does beg the question what are these benefits and where are they defined. In my opinion, this is the core role of the Business Architect.
I mentioned earlier that the reason that executives are embracing Agile is that they want to drive change within organisations so that they can compete and thrive in increasingly fast paced environments. They are committed to this course of action as their professional wellbeing is contingent on achieving this change. This is a golden opportunity for Business Architects to be key drivers of this change by filling the crucial role between strategic intent and Agile execution. It will require Business Architects to question and modify some practices but I see Business Architecture (the What) and Agile (the How) as a valuable combination to drive organisational performance.
To find out more about the EA Learning Business Architecture or Agile training courses please fill out the below form or click here to view our course range.
