« Six Tips for Finishing Projects
Planning and Budgeting in Scrum Projects »

Project Management in a Scrummy World

July 7, 2010 | Author: PM Hut | Filed under: SCRUM

Project Management in a Scrummy World (Wrapping a waterfall around an Agile development stream)
By Michael Gorman

I recently project managed a client’s outsourced development group, one which practiced Agile/Scrum methodology. The client had some less-than-satisfactory experiences with other Agile development groups in the past and was concerned about the success of the new project, so they decided to engage an independent certified project manager for the group. The client also was engaged in internal software development for its current and next generation software which was generally managed according to the Waterfall approach.

Although I had successfully managed Agile projects in the past, my experience as a documenter, planner and analyst makes me more of a Waterfall person. But I am well aware of Waterfall’s potential problems, particularly in a fast moving environment where change of direction is the only constant. In that situation, your advance planning, requirements gathering, and detail design tend to become obsolete before the implementation can even start!

When I was brought on as project manager, the client was just finalising a high level statement of work for the features and changes to be implemented, but no detailed requirements had yet been written. This feature list, was the only indication of the project objectives and deliverables, and was the only basis for the estimations the development group had provided. The scope was fixed, the timeline was fixed at six months. Oh… the budget was fixed as well! The icing on the cake: management wanted a Waterfall approach and wanted the project to move to execution within a week.

It sounded impossible (and it was). Scope, time and cost cannot each be fixed, that is just an immutable law of nature. Scope needed to be flexible — the detailed requirements were not well understood and the time estimates were based on too little information. Management reasonably conceded that cost might possibly bend a bit but, on the other hand, the world was in the grip of a global financial crisis… Say no more!

Fortunately, the development group had a solution architect, a senior developer and later included a junior developer working from the United States. All three were solid professionals and were good Agile practitioners. They were confident in their estimate and were diligent in helping the client’s business analysts and product owner understand where their decisions, or indecisions, could impact on their development progress or adversely affect the project outcome.

Normally Agile does not recognise the need for a project manager, and I was concerned that my role would be seen as superfluous by the developers. But I saw an opportunity here as well. Management had expressed that they wanted to know what they were going to get, and when they were going to get it. So I saw my role as shoring up a weak aspect of Agile; that is, getting the full (but as yet undetailed) scope by the required time.

I realised that the high level requirements and non-descript backlog stories would simply not be enough specification to get the desired outcome. The client’s BAs, who were happy with the Agile approach, were somewhat shocked to find out I was requiring them to develop the Statement of Work into detailed unambiguous use cases, a consistent set of business rules, and a collection of suggestive wireframes showing the way the implemented features might appear on screen. They wondered, ‘why should this be documented when it would all change anyway?’

As it turned out, my insistence on detailed use cases (a Waterfall *must*) was one of the key factors that lead to the successful on time delivery of the project. I drove the BAs (Business Analysts) to complete the use cases by the midpoint of project execution, which is pretty late for a Waterfall project! I then asked management to sign off on these details as the project acceptance criteria. Having now provided the details, as well as the assurance that management would be accountable for any changes to the detailed requirements, I then asked the external developers to provide a revised estimate based on much more complete information.

The news was not good (nor had my Agile experience caused me to expect it to be so). For the full scope, based on the detailed requirements, the developers now expected to be fully four months out beyond the required delivery date. However the exercise had been valuable because it was still not too late for the project to adjust to these facts. A substantial piece of the work could be done “in parallel” if only additional resources could be obtained. I found that the internal development group had the necessary expertise and capacity so we initiated change requests to move some of the scope to the client’s internal development team.

Yes, management did question what the trade off was — as the external developers were cutting scope in order to deliver on time and yet were not pro-rating their time-based costs! I explained that an increase in cost was the only (slight) flexibility that the project had been allowed — and in fact that increase was the internal cost for the additional resources needed to complete the fully articulated scope, as described by the approved use cases and the change request which management had just approved. I also explained to management that their alternative would be to notify the external developers of a potential breach if they could not finish the work (albeit incomplete and ambiguously defined) that they had committed to in the contracted statement of work.

Reasonable minds prevailed. Since the increased cost of the change would be incurred by the client anyway (as ongoing internal staff expense — the internal developers had recently completed small projects assisting other departments and had now become available for project work), requiring no real change in the companies internal operating budget, management took the news for what it really was: good news about how the project could be successfully delivered on time with minimal impact on actual cost.

The parallel track approach tactic worked well: both tracks of the project – internal development and the externally outsourced development – were completed by the required time. We had avoided an unfortunate scenario, too common in Agile development, where scope creep due to inadequate up-front detail leads to project timelines doubling or even tripling! The tactic paid off in other ways as well. The internal team was able to skill up some of the less experienced junior developers whilst the external team was able to further refine some of the details related to greater usability and fine tune some of the features provided by an upstream update.

Essentially, the insistence on “up front” requirements and use cases provided a Waterfall “wrapper” on the Agile project that allowed the project to predict — at its midpoint — what the project would actually deliver by its intended conclusion. The Waterfall wrapper allowed the project to communicate with management successfully along their preferred terms of reference, providing them reliable projections on how long the design and implementation phase would really take based on their approved requirement details. The testing phase, broken up to follow each of the iterative development sprints, informed the BAs of use cases gaps or problems with the business logic early on, and helped them to finish the detailed requirements and use cases early, providing a documented set of test cases that accelerated later acceptance.

So effective project management is still possible in an Agile/Scrum world. It’s about reigning in the scope and schedule earlier rather than later, projecting the completion date based on complete information, and keeping the lines of communication open and honest from top-to-bottom and from bottom-to-top. Doing this means telling the developers what is required early on, and telling the customer that they must clearly commit to the scope they are requiring. Two things that don’t typically happen in an Agile/Scrum project, but fortunately can still be made to happen around it.

Michael Gorman is currently a Project Management Consultant at Project Studio Consulting. He has Twenty one years experience consulting with project teams in the IT, Software Development, and Engineering/ Manufacturing industries. You can read more from Michael on his blog

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Wednesday, July 7th, 2010 and is filed under SCRUM. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

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>

All fields marked with " * " are required.

Project Management Categories