27/03/2019
Agile was introduced to the world in 2001 after 17 men had met in Utah and devised the Agile Manifesto (agilemanifesto.org). It was created with a focus on software delivery projects and this is evident by its given title: Manifesto for Agile Software Development. However, in the intervening years, Agile has grown into something that is now used to change the way that hospitals are ran, the way churches perceive their 'customers', how teachers interact with their students or even the manner in which governments govern.
So, if Agile is not just a way to deliver software what is it? Most of the people who attend my training classes describe Agile afterwards as a cultural or mindset shift. In this sense, it suggests different ways of thinking and interacting to how they had previously worked. The result being a move towards a more customer-focused delivery ethos that works by empowering teams to be responsible decision makers rather than relying on a command and control structure.
This sounds like a nice idea, but most organisations rely on certainty. 'We must hit this date', 'The customer needs this by this date', 'The regulator of our industry says we must do this by this date.' Stop me, if any of this sounds familiar. If this is your situation, then you may well approach it with an understanding that you know what is needed to be achieved and therefore look to create a plan to hit that date.
Unfortunately these are shortened versions of the actual requirements for the delivery of work. You see, there is certainly a requirement for the work as described above but it is missing some absolutely critical details. First and foremost, 'this project must innovate and deliver something amazing to the customer'. Secondly, 'the project must deliver high quality so that no re-work is required otherwise all future plans will be impacted'. Thirdly, 'the project should be delivered to the customer prior to the end date so that they can confirm it meets their requirements'.
When we start to think like this, then the requirements can be seen as something more complicated and the role of management perhaps somewhat different. The requirement should read something more like this; 'To remain competitive and to satisfy all our customers (a regulator is one of these), we must deliver an innovative, new product where quality is built-in from day one and we will deliver the project early to ensure it meets the customers needs.'
This is a more truthful and honest requirement than simply saying we must hit a date. It will imbue into the project the understanding of everyone's responsibility. Additionally, it will allow the organisation to start thinking about ways to achieve this standard. This is sometimes the way that companies move towards delivering iteratively as it allows for constant quality checking and easy feedback from your customer to ensure that you are doing the right things for them, in the right way.
So how do we enable all of this to come to pass? There is a concern based on my experience with clients that some management might perceive this change in approach as a serious risk and that this fear means that they might be blind to the greater risk. As Rita Gunther McGrath of the Harvard Business Review puts it 'Managers still assume that stability is the normal state of affairs and change is the unusual state'. This is the opposite of reality - change is the only constant and so your ways of working need to enable it, not control it. After all we're not all using fax machines that much anymore, are we? That things will change is one of the very few things you can be certain of. If change is certain, then to remain competitive you must embrace this, as it leads to new ways of doing things. The term for this is 'innovation'.
If your work doesn't innovate, if your customers aren't excited by the outcome of your work...then why are you doing the work in the first place? And if you don't know whether your customer is going to be delighted by what you're doing, then you're not engaged with your customer and why are you spending money and time on something that you don't know your customer wants? Consider the actual risk.
Management, what is your role in Agile? To empower, to enable and not to direct. All of this change in approach is going to be hard for your people. They are going to need your help and support.
Perhaps the old definition of a manager is worth mentioning here, 'responsible for overseeing a department or group of employees within a specific organisation or company.' This heralds some odd but pervasive logic; put someone through a rigorous background check and interviewing process and then say, 'We hired the best so that we can tell them what to do'. (sound of my palm hitting my face)
Even Steve Jobs said 'We don't hire the best people and tell them what to do, we hire the best people and they tell us what to do.'
My experience in coaching organisations shows that management who focus on creating an empowered environment where people are trusted to do what they think is right, empowered to make decisions themselves and feel secure enough to take chances - will produce the highest quality and most innovative products.
If a manager works this way, they won't simply be managing, they'll be leading.
In the Agile world, managers become Leaders.
Simply put, in the Agile world, managers become those who empower change to enable greater success and inspire people to do amazing things.