Can consulting be Agile? – An interview with Prag and Brian
2 November 2015 |
Sandra Falque | About a 6 minute read
Prag Patel is the Practice Lead AND Relaxed Sports Fanatic and Brian Mulvihill a Product Analyst AND Tea Devotee at AND Digital. They have worked several months together at one of our key clients, helping the Digital team improve their ways of working. To do so, instead of working with a traditional project management approach, they decided to adopt Agile Ways of Working.
1. Hi Prag and Brian, can you please quickly describe what the context was at your client when you arrived and what was your role there?
Brian – When we started the project, our client was really eager to improve their delivery and ways of working of the existing scrum teams with the ultimate focus on delivering more features for their customers. There was a lot of opportunities for improvement as it was not very clear what the work they were doing was and what they were expected to deliver.
Prag – Our role was to try and understand and get clarity on the underlying problems which meant the teams were not delivering, and ultimately to improve the delivery of their Agile team in the long term.
2. Can you tell me a bit more about the Agile teams?
Prag – There was a number of scrum teams when we arrived, a combination of onshore and offshore. The offshore teams were mainly 3rd parties. The digital function was set-up about 2 years ago.
3. Can you please describe how you used the Agile methodology, not to create a product but to deliver your work?
Brian – We wanted to apply the approach and ways of working that we were promoting for the product teams.
We decided to use 2 week sprints, with the objective of delivering a set number of features for each sprint. Sprint 0 was used to confirm what we thought the issues were and to build relationships with the working group; a set of senior management representatives from our client. From that point we then planned 7 sprints in which we thought we could deliver the recommendations to address the key issues. We outlined our recommendations as user stories.
Prag – The steering group for the work acted as our product owners; they were invited to our Sprint Reviews. The Working Group (who were line managers or team leads) acted as our Scrum Team. They were involved in our Sprint Planning & Retrospectives. We had a visible Scrum Board to ensure complete transparency with all stakeholders involved throughout the project. The Product backlog containing our user stories (recommendations) was also available and visible to everyone in JIRA. Daily Scrums were run every day, and although not everyone could attend every one, it was a good opportunity for us to share our progress.
4. Why do you think you an Agile approach to a transformation project is more efficient than a traditional project management approach?
Brian – Well, I think that the benefits of the Agile approach were: we could quickly get feedback and use this to refine our priorities, we could really work as one team with the client, we could show incremental delivery and share our work. For instance, working in an Agile way helped us realise very quickly that the level of priority we gave at the beginning to some items changed during the course of the sprints.
Prag – I do not see the downside of working in this way. You are always refining ideas and recommendations based on new information and the impact of other changes; so being able to re-prioritise as you go-along works well. You also build much better interactions with your client as you are continuously communicating with them. Also, the visibility of work is quite different. In a traditional consulting project clients are only periodically involved and you tend to have less frequent opportunities to demo what you have delivered – normally it is a big reveal towards the end of the project. Thanks to the Scrum Board, the use of JIRA and our Daily Scrums, the visibility was very high. It gave confidence to our client that we were doing good work and it gave us confidence that we were focussing on the right areas. What’s more, we had something meaningful to share every two weeks.
I think that for people who are still learning about Agile it is a great way to work, it makes you learn by doing and practising. It also gives the client confidence that we are practicing what we are preaching.
Nonetheless, there are some challenges to be aware of. As we did not only rely on the team members but also on other stakeholders – we could not control their time. It was sometime difficult to do everything we had planned during each Sprint.
The other challenge is that you know you will be working on activities that will not be completed within one Sprint and will need to be carried over (due to the problem outlined above). We tried to mitigate this by breaking down the tasks for the current sprint.
5. Would you say that this method helped you deliver your work quicker than in a traditional way of working?
Brian – I would not say faster but definitely closer to what they needed.
6. What advice or best practices would you give to consultants or project managers willing to work in an agile way?
Prag – I think that you need to have a reasonable period of time, at least 3-4 sprints, or 2 months, as it is an evolving piece of work to make this approach worthwhile. Planning a budget for the work can be a little difficult as you cannot precisely predict at the beginning how many sprints you will need. However it doesn’t mean you can’t use this approach, keeping some flexibility from the beginning, 1 sprint contingency for instance, can be very useful. You can also classify recommendations into high, med & low priority and discuss with the client what the benefits of completing the low priority items are if you are getting close to using up the budget.
For this project, we managed to stick to the budget we planned.
7. What were the outputs and outcomes of your work?
Brian – The Scrum team we have been working with the longest has delivered on 100% of their commitments. The other ones did maybe a bit less but improved significantly their ways of working. What they are doing now is significantly clearer and teams are a lot more focused on what they are committing to. They have a defined set of Scrum Events which they know they need to attend which helps improving the predictably, visibility and performance of the team.
Prag – The Scrum Teams now have a different problem than when we arrived. Partly due to some of the key problems at the start now beginning to be resolved, this has highlighted other areas that are not working so well. We have made significant inroads into helping the teams to work more consistently and deliver to their commitments. We are also seeing early signs of improved velocity in some of the teams. The new problem which will impact the improvement in velocity is fixing the allocation of work to the teams – some teams are suffering from not having enough user stories ready for development allocated to them – we are now also trying to help with this!
Questions? Comments? Remarks? Willing to go further? Contact our Professionalising Digital team ([email protected]) to understand what is new with each of these recommendations, what are the pitfalls and level of priority and how to implement them in your company.Read More From This Author
React Native Engineer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.
Technologies you will be using
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested
DevOps Lead (Reading)
Bring your delivery expertise to the table, leading the pack as ambassador on operational requirements, influencing and continuous development.I'm Interested