I recently watched a Pluralsight course on Project Management for the Software Engineer. My role has changed recently and I’m finding myself far more involved in planning the team’s big picture. I hoped with a few more ideas and skills under my belt I’d stand more chance of rising to the challenge when things get tough.

Having watched the video (very good by the way, I’d highly recommend it) I came away with an uneasy feeling that this “Project Management” stuff was simply Waterfall under another guise. As developers we’ve been so bombarded over the last few years with the message that Waterfall is antiquated and Agile is the new methodology and that all notion of long term planning and detailed requirement documents must be stamped out.

Needless to say that when I watched the video explaining the importance of a proper project plan and detailed specifications I was rather taken aback.

https://twitter.com/ArdLiath/status/716650488867856388

Surely we’re not preaching a return to the old days of strict deadlines and work planned out months and months in advance?

It is at this point that I have to raise my major frustration with Agile and Scrum in particular. Everything I’ve read and every speaker I’ve listened to advocates a prioritised backlog of work which the team will work through to deliver maximum benefit to the business.  This is great for a startup, or a team developing a solution where they are continuously refining a project to deliver more and more value.

In my experience however the business process is rarely so clear cut. For example, I have a deadline looming, several customers have paid for dozens of new features to be included in our application and the sales team have committed to a UAT delivery date of the end of June. Suddenly I’m not working to a prioritised backlog, I’m working to a project deadline and failure to meet it could have serious repercussions!

So how do we combine these two approaches? How can I maintain the ownership and agile nature of a scrum team while carrying out the long term project plan necessary to ensure a successful delivery? Is it possible or are the two mutually exclusive?

Let’s look for a moment at what the Project Management approach promises us

• A clear set of deliverables agreed by the client
• A clear list of delivery dates for stakeholders and other teams in the business
• Easier control by planning work up front allowing us to track progress and spot issues arising

Is there a way we can keep these benefits without sacrificing the agile nature of scrum?

A Clear Set of Deliverable agreed by the Client

Let’s take this one one first, Agile does not mean wishy-washy requirements, it means breaking down big visions into manageable and deliverable chunks. While a client may envisage a huge monolithic project it is the job of the project team to break this down into small, simple user stories which can be delivered in manageable pieces.

Where an analyst may claim that a multi-document specification contains every use case and scenario they system may encounter I’d be willing to bet significant money that they’re wrong. Furthermore, by the time you deliver this enormous project the business value for it may have waned dramatically (I’ve seen this happen myself). It is undeniably better to break your huge requirements down into components which can be delivered for continuous feedback as you go.

A Clear List of Delivery Dates

Assuming you are working in a scrum team the agile process does not obscure delivery dates, in fact it embraces them. Rather than setting an arbitrary deadline months and months in advance and gearing the resource and financial plans towards it continuous and iterative releases increase the reliability of hitting deadlines, after all – it’s less likely you fall significantly behind over a two week period than a two month one!

Use your sprint end dates as your deadlines, deliver frequently into a sandpit environment so the client can see your progress and begin testing as early as possible. Big deadlines are a lot less stressful when you’re on the nth iteration!

Upfront Planning for Clear Progress Tracking

As a Project Manager you are going to be continuous asked whether a project is on track to meet the business deadlines, I’ve not tried it myself but I’m willing to bet turning around to your client and saying “We don’t have deadlines, we’re agile…” Probably isn’t the best approach.

When we create our backlog we break our features into User Stories, each is estimated and prioritised. At the beginning of each sprint the highest priority items are selected to be worked on. From a project management perspective is that other, “more important” stories may be moved into the sprint in place of your items.

However in a business environment we need to plan releases and deliverables several sprints in advance. as a Project Manager we need to ensure that our work is completed on schedule and not simply pushed back until the 11th hour.

My suggestion here would be create a project plan which covers which sprint each User Story should be completed in, these should be negotiated ahead of time with the Product Owner. At the beginning of the sprint the work which was planned in is moved up to a high priority. On a quiet week the team may have capacity to complete your planned work as well as some of the other tasks, on a busy week your work may not be the most pressing (there may be customer support requests which take precedence for example). However, as with all things it is the Product Owner’s prerogative to decide which tasks will give the most business value yours, or the other challengers.

What this process allows is for you to plan out your control points well ahead of time. If you’re expecting certain tasks to be delivered at the end of sprints 2, 4, 5 and 6 then you can begin monitor these and verify that these targets are being hit. If they’re not then you can explain very clearly why they fell behind whether this was because a task took longer than expected or because a more pressing task came in.

This is the same process we already work in, resources can be reassigned at any time in a normal project. The advantage here is that the Product Owner formally balances the priorities of the business and gives reasons why the project must be allowed to fall behind.

Handling Scope Creep

As developers we’re constantly aware of the pressures of scope creep. A piece of work is designed, estimated and scheduled in. Then, as soon as the client sees it they have another idea and want a further feature to be added. In an agile environment we want to encourage this feedback, ultimately it helps us build software which better suits our customers’ needs.

From a business perspective this feature creep can be deadly. Budgets are drawn up and quotes delivered based on the original feature, if these prove to be inaccurate or underscoped then you are effectively delivering your service for free.

In order to avoid this it’s vital that a formal process for Change Requests is given ahead of time. If a customer feels that this is their one and only chance to refine the product to make it valuable to them then they will push and push everything into the same delivery. If however a formal CR process exists they know they can continue to work with the team and refine as they go. There’s a theme here, the emphasis needs to move away from a single monolithic and towards small, iterative and manageable releases.

In Conclusion

I believe that the two approaches of Project Management and Scrum are not mutually exclusive. In fact I believe both aspects are vital if you want to achieve anything other than a constant aimless meandering of features.

For the two approaches to work well together I feel there are few steps which must be carried out:

• Break your project into manageable tasks and tentatively assign them to sprints with the agreement of your Product Owner.
• Measure the progress of your project through it’s lifetime, ensure that if a task is not completed in the given sprint you understand why and stress the urgency to the PO that the ground is made up.
• Embrace change and allow your customers to refine as the project is developed. Formalise the process and be clear that any change will be re-scoped and budgets will be updated.

I’m going to be attempting this approach in a few weeks for a release to our biggest customer. Hopefully this balanced approach will see us through.