Many IT organisations have faced a question whether or not to develop using Agile as part of their change management process. It has its own well documented merits – such as ability to empower and motivate teams and increase their throughput, as well as deliver a product that meets the customer’s needs very well. A highly motivated team is also more likely to display a greater ability to innovate – a winner all around!
As a project manager reasonably new to “Agile with Scrum” – we are keep to use it at PointBeyond and we tried that in my previous jobs, occasionally with somewhat mixed results – I wanted to share my own thoughts on the suitability of Agile to organisations’ project management processes.
It seems a good idea to carefully evaluate whether or not to adopt Agile, and to what degree to adopt it, on a case by case basis. There are places where a traditional Waterfall approach could still work. In others, Agile can be of huge benefit. It depends.
From my own experience, I can see two areas where Agile and Scrum might not work all that well. Both cases relate to organisations with cultures that are more regimented, and where trust can be an issue.
The first case is where a customer needs to fully understand the end deliverable before signing off on the dotted line to commence the project. So we are talking about a customer who is fairly inflexible in their approach. To receive a go-ahead to actually start building software, one would then need to put in place a comprehensive functional specification – which will be arrived at after a full-on analysis and design phase.
Of course, going Agile does not mean that the functional specification is necessarily dead – only that it might be short, focus on key architectural decisions which are the cornerstone of a deliverable, and focus on the critical success factors of a piece of functionality. But not all customers will grant such a degree of artistic license to the project team. And hence it can also be a question of trust in one’s professional ability, judgement and skill – is there enough of it between the customer and the vendor? Can the customer “let go” and empower the project team to work out the smaller details using a suitable Agile methodology as the project carries on, or will every question need answering in advance?
The second case is where an organisation’s senior management interferes with the Scrum process, perhaps wanting teams to achieve unrealistic targets and add to its list over and above what teams say they can do – or maybe insists on changes of priorities at short notice and still expect excellent results.
Such an approach can be destructive for any team trying to implement Scrum, as it will cancel the efforts made by the participants to work out their own capacity and commit to work on their own initiative and own understanding of their skillset. Senior management must fully buy into the Agile process and remain strictly at arm’s length. If it does not, the process will not work efficiently and result in lesser motivation and decreased productivity.
The Scrum process allows for priority calls to be made – but only at the start of each Sprint. If, half-way through a Sprint, serious external circumstances cause a massive shift in priorities rendering the current Sprint a total waste of time, the Sprint can be stopped – and this is the only time this is allowed. However if an organisation tries to change priorities half-way through a Sprint by introducing new key items into a committed iteration, whilst Scrum masters allow this to happen under pressure from management, the process can break down. Needless to say, this causes stress to all participants and often does not get the item done on time anyway.
Yet again, we are talking about trust. This time – in implementing Agile – it is between senior management of an organisation and its Product owner, the Project team, and the team’s Scrum Master. When an organisation fully empowers its employees to deliver (whichever change management method is preferred) and gives them all suitable tools to do so, it will have the greatest chance of success. And trust in it’s teams is a huge step towards such empowerment.
Ksenia Woodgate
On your second case, I would NOT say that adopting agile is not appropriate… just that it needs to be adopted top down and with a budget for coaching. When managers pay consultants to change their business, they tend to listen more than when it comes from within.
Crazy and scary, but true.
I would agree it is much harder and therefore less likely to succeed.
Kevin, Thank you for your comment. Your suggestion is sensible. If only external consultants managed to bring about positive change in organisations every time though! Often they come in and leave corporations with nothing but a huge bill for their services. But sound external advice is certainly beneficial to senior management.
Picking the correct vendor is key here… I would go for ObjectMentor, Thoughtworks, and companies of that sort. Well established, long reputation, and worth the higher price.