PROJECT RESCUE USING AGILE

The case study describes how agile practices were applied to turn around a failing waterfall project.

Specifically by living the agile principles of respecting the team, increasing visibility and effective prioritisation we combatted the classic trappings of waterfall and the team successfully delivered to a satisfied customer.

How the introduction of basic Agile and Scrum principles helped a failing waterfall project to succeed.

As the 14th project manager in two years to take on this task, I was recently seconded into a client’s troublesome project in an attempt to bring it back under control and to a successful conclusion.  The project had all the hallmarks of failure: spiralling costs, difficult relationship with the business customer, team moral at rock bottom with little visibility by the management of the challenges the project faced.  With an unrealistic go-live date fast approaching there was little belief that the project would deliver a viable solution in the demanding timescales.

Immediate actions:   To bring the project back under control the following 8 KEY ACTIONS were taken:

1. Baseline the requirements:   One of the biggest problems on the project was a very inexperienced user group, who were poorly led and had not defined the requirements properly at the beginning of the project, recall that this project set out to be waterfall.  To counter the lack of definitive requirements, the business customer was in daily communication with the two most experienced developers, who would convince the project manager of the importance of any new requests.  This was happening on an almost daily basis.   I escalated this to my client’s senior management team and their customer’s senior management team as the main issue the project was failing.  We worked together with the customer to agree a new base lined scope, plan and price.  Each subsequent change would now go through a formal change request process and have an associated cost and/or an impact on the new Go Live date. 

While baselining the requirements may not sound very agile, this approach served to make clear to the customer where a change was occurring and set for the effective prioritisation, as well as the option for outright replacement of requirements by feature.

This was successful in helping the customer understand the true priority of each potential change.  It was also necessary to reiterate to the customer’s business team and the development team that all new change requests, no matter how trivial, should come through the new change control process.  Not everyone on the customer’s team understood the problem that they were causing, but the developers really appreciated this new stance as they had sometimes felt bullied into taking changes forward, which ensured the new process was enforced.

2. Introduce product owner role:  The concept of the product owner was also introduced.  This role was taken on by the customer’s senior project manager who would become responsible for owning the product backlog and would act as the single point of contact for customer’s business team.   This was necessary to make certain that ad hoc requests would no longer come from the business customer direct to any developers.   It was agreed with all stakeholders that any future change would have its impact assessed properly and be introduced at a time appropriate to the developers.  The main benefit here was that clarity of scope was ensured, not just for the developers but also for the customer themselves.

3. Become a team member:   This may sound obvious, but it was not always the case on this project.  Previous PMs would sit away from the team, communicating to the team by phone and email, despite being in the same building.  The business analysts and developers did have the advantage of being in the same room, with the system testers also being close by, but they were completely cut off from any daily management presence.  One of the first things I did was to sit right in amongst the team.  This had an immediate positive impact on the team, who were previously feeling detached, leaderless and under too much direct pressure from the business customer.  Once in situ, I was on hand to answer or take away any of the teams problems and I was able to keep the team as informed and up to date as possible.  However, this wasn’t a free for all, conventional daily stand up meetings were introduced, where I took on the Scrum Master role.  It was also necessary to work the same hours as the team, as long anti-social hours were still required, ensuring I was available to progress any issues when they occurred. 

4. Introduce daily stand up meetings:   Daily 15 minute stand ups replaced a daily 2 hour long customer facing meeting, which had only been attended by the customer, the business analysts and the PM.  Initially this did not go down too well with everyone.  There was one particular BA who enjoyed the kudos and procrastination of a customer facing role and there were a couple of developers who were just averse to any type of meeting.  Introducing the three questions: ‘what have you done since the last stand up?’, ‘what will you be doing between now and the next meeting?’ and ‘what is getting in the way of doing your work?’  got everyone involved, enhanced communication and gave everyone better visibility of the outstanding tasks. 

5. Introduce the task board:  The daily stand up meetings took place in front of a large, previously unused white board, which was converted into the task board with basic ‘To Do’, ‘In Progress’ and ‘Complete’ columns, with the tasks information on post it notes.  The task board made a significant difference to the team, who had always heard of, but never seen, ‘a project plan’, so were not always aware of the overall project progress.   The task board gave the team a view of progress, which really helped moral, but when coupled with the daily stand up meeting, we were able to identify and deal with any impediments in a timely manner.

6. Empower the whole team:  I insisted that the whole team got to contribute to the prioritisation of tasks and the provision of new estimates.  Previously this type of responsibility was only deemed suitable for the team leader, which meant that estimates were not always accurate, tasks were not suitably delegated and priorities were always based on the business customer’s mandate.  This did not have a negative effect on the team leader, who previously owned this responsibility.  To the contrary getting input from the whole team helped relieve some of their burden and motivated the rest of the team who had not previously been involved.

7. Introduce retrospectives:  While we never had the opportunity to introduce true post sprint retrospectives, we did arrange a number of retrospectives, which occurred: (1) after a particular wave of change requests had been implemented, (2) after UAT and (3) after Go Live.  Despite there being a blame culture within the organisation, we were able to foster feedback to all teams which ensured that past mistakes were not repeated. 

8. Do food:  This project didn’t do the waste line much good, but it did help team bonding.  Tuesday was pizza day (usually my shout), however any other particularly fraught day also qualified to become a pizza day.  Quite often the client’s senior management team would also appear for free pizza, informally mixing with the team, which had never happened before.  The free plastic coffee was always by-passed for proper Italian coffee from the local deli around the corner, with everyone taking their turn to go, and a few late nights and weekends were aided by Wagamamas or Dominos. 

THE OUTCOME:  The project was successfully delivered 5 months after I joined. This was only three weeks later than had initially been agreed in the revised baseline of the project plan, but it was an acceptable delay, which had been agreed with the customer to allow the introduction of additional scope.   The final 5 months of the project was on budget, due to the quality of the estimates and the change control process.  This led to a renewed level of confidence from the customer in my client and further releases have been commissioned. 
 More importantly the project experience is now seen as a positive one for the team, who had the satisfaction of a successful delivery after such a long period of time.
 Personally, there was initial trepidation about becoming project manager number 14.  Number 14 had started out as a derogatory label, implying there would be a number 15 soon.  Later it became a positive motivation and a compliment of sorts.

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>