[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at www.c6s.co.uk]
With Agile becoming so popular a lot of companies are jumping in to adopt it. With any new great idea, often people hear the benefits and want it without fully investigating the requirements to achieve the desired goal.
The Way It Used to Be
Those moving from a traditional project structure are used to assigning project managers who ultimately are responsible for a products success. Such roles take on a long list of responsibilities which are filtered to them via stakeholders, customers, product managers via individuals or committees and so on. The project manager then proceeds to create a long list of features to satisfy their demands, then gets the stakeholders and/or customers to sign their name in blood in absolution for everything they want and specifically ask for. Prior to this of course, the project manager may have estimated the length of the project and broke it down into a lovely gantt chart which may as well be etched in stone.
In the above scenario, where does the power actually sit? The production teams who develop the product are told exactly what to do and how long it should take them, the stakeholders have stated and signed off their demands and then may sit back, also the customer has predicted the future and signed this in absolution until it’s completion, and the project manager administers the flow of the work from beginning to end and is answerable to the deadline. So what happens if change is required and who identifies it? With often little involvement by the customers and stakeholders during the project, is it easy to make change?
Change is the one major factor that needs to be recognised early and implemented as soon as possible. It’s change that builds opportunities or destroys competition. Although this may sound obvious enough, why then are so many traditional structures built around rigid organisation or project structures?
Change = Empowerment
One of the key aspects to change is empowerment. Change can only be recognised if people are empowered, not only to make the change itself, but to also motivate them and and give them the responsibility and opportunity to recognise it. People who are not empowered won’t feel part of the product and businesses will get much less for it. This is particularly apparent in complex and creative teams which rely on valuable input and great ideas to progress. If these people are not empowered it’s safe to assume creativity and solutions will be redundant or minimal.
There are countless sources which prove the above in social and complex working environments, yet why do so many people ignore it. Well the truth is, moving micromanaged or rigidly structured working practices into a trusting and empowered frameworks such as Agile, require not just a change in the team structures, but also to the phycological practices of the whole business not just software teams. This is not an easy task by any means and is often not seen necessary when integrating Agile! After all one of the most empowering roles in Scrum is the Product Owner; often solely responsible for the value of change. They chop and change the product backlog on a regular basis to respond to and discover value and empowered to do so. These people need to access all the relevant information from the business as decisions and ideas are derived from knowledge. The team responsible for doing the work are also empowered. They set their own velocity and, take on only user stories which can be delivered and identify problems and things went well via a personal retrospective exercise. Most of all the team self organise and answer the “How” question to the Product Owners “What”.
But It’s Not Always Possible…
Unfortunately there are still companies who fail to empower and trust people. Even worse these people take the responsibility and subsequently blame for failure which is not in their control. In situations such as these, morale is low, staff retention is low and most of all companies get less output; all because people are not empowered or trusted, not because they failed from any course of their own doing.
If you can’t trust people and give them the opportunity to succeed, maybe Agile isn’t the right path to follow. To be truly Agile, people need to be trusted and empowered. This is an organisational change not to it’s structure, but to its phycology on how individuals are involved with the business. Getting this right will increase the potency of the business without investing, getting it wrong will be expensive and dangerous to business development.