In the past, I have often talked about the importance of “business alignment”. I think sometimes it hasn’t necessarily been very clear what I meant by that, so I thought I would try to explain it a bit more clearly.
By business alignment, I mean the alignment between a development team and the business unit they do work for, and the alignment of their objectives, priorities, and the way that work is managed through the delivery process.
In small organisations, these things are often inherently in line, so it seems like an academic issue – almost a case of how can this possibly be a problem?! But in larger, more complex organisations, it can very definitely be a problem, particularly where organisations have historically been structured around the waterfall process and people are organised in teams by function, eg business analysts, project managers, developers, testers, etc.
In larger, more complex organisations like this, it can no doubt be very difficult to achieve complete alignment. This is why it’s often cited as a major concern for many CIO’s. How do they align the objectives and strategies of their IT departments with those of the business as a whole? It’s hard.
It may not always be possible, or practical, to do cost-effectively, however I believe that the ideal situation is one where certain things are perfectly aligned, in one to one relationships, rather than many to one. And this I would say is “the power of one”.
One Business Unit/One Product = One Product Owner = One Project = One Product Backlog = One Team = One Location = One Shared Goal.
Bliss! To assure success, this is arguably the perfect scenario!
Complete focus. Dedicated. One team with all the skills it needs to deliver from start to finish. One shared goal. All sitting together. One list of priorities.
Don’t get me wrong, I completely accept and understand that for many people, creating such perfect alignment is way beyond their control. They simply don’t have the authority to make this happen – certainly not across the entire organisation. And this is why I have said in the past that agile must be driven from the top. At least if you want to achieve the full transformational benefits that agile can bring.
Personally, I am lucky enough that in recent years I have always had the authority to do that, or at least something more like it. And I have no doubt that it’s been a major factor in achieving the successes that I have done. It’s really empowered the teams to be the best they can be.
When I think about some of the structures and processes in larger organisations, I see layers and layers of complexity. Most of which has been added over the years to compensate for organisational problems. For example, lack of alignment meaning we need to specify what’s required in writing up-front and have it signed off in advance. Formal change control processes. Formal reporting processes. Etc, etc. All sorts of necessary bureaucracy in order to control the problems caused by a lack of alignment.
If only we could turn the clock back twenty or thirty years. We might have solved the problems a different way. Let’s organise ourselves differently so these extra overheads aren’t necessary. Let’s change the structure and the way we’re organised to address the root of the problems, rather than adding overheads – often in disguise as good project management practices – that are really just there to alleviate the symptoms.
I think you can successfully adopt agile principles and practices in an organisation that isn’t structured in the ‘ideal’ way. And I think you will see some significant benefits. But I also think that if you structure the organisation so that development and business teams are aligned in the right way first, the benefits of agile can be truly transformational.
Kelly.