Answers to your Scrum and Agile project management questions

Last week I presented a webinar The ‘edges’ of Scrum – Addressing project management concerns on Agile projects which focused on where Scrum fits in to a typical PRINCE2 and PMI project lifecycle and what project management concerns are addressed by Scrum.

During the webinar we received a number of questions, some of them I responded to as part of the webinar, but there was insufficient time for all of the questions. So in this blog post I answer all of the questions asked during the webinar.

What tools are available for managing product backlogs/advanced task boards?

Many projects use JIRA Software, which allows change, issue, risk and defect management. Lighter weight alternatives I’ve used with some success include Trello.

You can also use tools that plug straight in to your development toolset (i.e. LeanKit into TFS) and I have recently seen that GitHub has just brought management of Epics (large stories) into scope.

Personally I find physical boards most beneficial. They are easy to set up and change, and promote a much more tactile and “engaged” experience. They are also much more visible in the team space. Obviously software solutions are very beneficial for distributed teams.

Techniques such as User Story Mapping can help with both backlog management and release planning.

How can Scrum work when the client is geographically separated from the team?

I’m presuming from the question that the client is not on site, but the team and Scrum Master / project manager are together.

The key requirement in terms of Scrum or any empirical process are that you can create a high level of transparency, and that you inspect and adapt regularly.

Ideally you would have direct face-to-face interaction between the team and Product Owner as this is the most efficient communication mechanism, which generally translates into the highest transparency.

Day to day you can obviously use video and voice conferencing, and desktop sharing solutions to remotely demonstrate increments, but I’d also try and get some genuine face-to-face interaction with the investor as often as you can. What is communicated by words or voice alone is a small fraction of what you get in person.

There’s a wealth of information online if you look for things like “distributed Scrum”. Craig Larman and Bas Vodde also have an excellent book on this topic; Practices for Scaling Lean & Agile Development: Large, Multi-Site and Offshore Product Development with Large-Scale Scrum.

Does Scrum require more resources for testing because there should be more products to release, which means more regression testing is required?

Scrum projects do create fully tested software more often (i.e. system tested, integration tested, and user tested) which they may or may not release so, yes, there is a requirement to ensure regression is covered through each iteration.

This is typically handled by use of test automation, as otherwise your overall testing burden grows each sprint and would take up more and more resource. Test automation is also a key component of Agile quality and risk management in the sense that:

• practices like test-driven development and acceptance test driven development can lead to much more structured definition of requirements and more disciplined design. They are also required to pick up integration issues quickly when different developers commit code to the same trunk on a frequent basis
• test automation (units and acceptance tests) ensures that “done” functionality stays done.

Use of automation for the “grunt work” allows testers to focus more on exploratory testing. Good things to look at are the Agile Test Quadrant and the Agile Test Volcano. The definitive book in this area is Agile Testing by Lisa Crispin and Janet Gregory.

Do you think Agile is appropriate for software implementations (e.g .ERP system replacements) where a big bang go live is the most feasible delivery option?

While Agile projects create a “releasable” increment each iteration, they do not have to (and often don’t) release that increment into production at the end of every sprint.

Unless the project is completely “cookie cutter” (or “paint by numbers” using Obeng’s 4 project types), there are a range of Agile practices that are well worth the investment of time and effort:

• involve the investor in prioritisation calls and make time, cost, scope and quality decisions highly transparent
• shorten feedback loops as much as possible through demos and interactions with the users and client
• use proof of concepts, technical “deep dives” and piloting where possible to mitigate risks
• be OK with less formal, but content-rich, documentation (i.e. whiteboard photos of a design that may change once or twice are just as good as a Visio diagram, especially for internal project documents rather than handover documents)
• have the team think about how they can improve their processes on a regular basis.

A key concern is how you split up work to enable degrees of agility. Ray Cooke from Equinox IT covers this area in his post Agile backlog - The most badly implemented, yet most critical, technique on your project.

Is there still a place PMBOK and PRINCE2 in organisations primarily using Agile delivery methods?

Yes, as most organisations still require some form of “interface” between the Agile delivery and the rest of the organisation. This might be:

• lightweight (but sufficient) business cases and plans
• status reports in a more conventional way
• management of financials and contracts by the project, etc.
• assisting with stakeholder management
• finding internal team members a home after the project and/or contributing to performance appraisals

The key is to set the overall envelope at the right level of abstraction so that Scrum teams are able to be agile and aren’t breaching project tolerances every sprint. Having better tolerance setting and delegation is an issue that plagues waterfall style projects as well. I see weekly steering committees and “inch stones” instead of milestones on projects quite often.

Please also see the answer to the earlier question about ERP implementations as there can be a lot of benefit in adopting agile approaches on any project. You don’t have to switch fully over to Scrum to get some benefit.

What role do you see for Project Managers in helping their organisations adopt and get value from Agile practices?

Project Managers are ideally placed to be that “translator” between a Scrum team and the organisation. Scrum puts a lot of this in the hands of the Product Owner, but typically, if you’re senior enough to make investment calls by yourself, you’re also too senior to spend all your time as a Product Owner. In most NZ organisations the Product Owner has a day job, and delivering software via a project has to be balanced against a whole range of responsibilities.

A Project Manager could either work with a Scrum Master to manage the interface, or they could pick up some basic Scrum skills and cover the whole area. Likewise, a Scrum Master could learn budgeting and cost management, etc. and cover the whole space.

It’s better to think first about the work to be done and who has the skills, rather than focus on which role titles are there or missing. All projects have a few basic questions they have to answer in one form or another (i.e. what are we building, how will we do it, who’s building it, how will we know when we are done, how do we measure progress, what will it cost?).

How does the role of a programme office change under Agile?

It can change a little, or a lot. Obviously there are also a lot of different PMO structures, from centre of excellence and clearing house type models all the way through to accountable PMOs.

If your Agile project has a conventional “wrapper” (i.e. still provides a business case, still provides reporting in a close to standard sort of way) then the PMO may just act as a clearing house and provide consolidated reporting to senior teams.

At the other end of the spectrum, the PMO might work with a collection of Product Owners to prioritise several iterations of work for one or more development teams. Portfolio management can be a very quick activity once a month or quarter rather than something done once or twice a year. If you know you will get something delivered in 2 or 3 sprints, then you know you probably can live with waiting if you have to.

Big, monolithic projects with long delivery times have the effect of “clogging the pipes” and make cross-business unit priority setting harder. They also make resource management within an organisation extremely difficult as project plans and resource usage shifts from original forecasts.

Taking the middle ground, the PMO may provide coaching and advice on methods and tools, just as they do for PRINCE2 or PMBOK projects. It may even provide skilled Project Manager-cum-Scrum Master types that can handle any delivery framework.

What is ‘Definition of Done’?

The Definition of Done is the quality standard that all parties (Product Owner, Team and Scrum Master) understand must be met for something to be considered complete.

It can have both product (what PRINCE2 calls “criteria and tolerances”) and process (“quality methods” and “quality responsibilities”) aspects.

A User Story starts with “As a <role>. I want <thing> so that I can <do something>”, but the next level down is your typical acceptance criteria that form part of the definition of done for that story.

Your production process may also specify technical practices that must be covered in each domain for any story to be considered done (i.e. analyst has to have written natural language acceptance tests, developers must follow coding standards and all unit tests must pass, user documentation has to be updated before the end of the sprint, etc.).

Importantly:

• This is transparent to all so any quality shortcuts or trade-offs are understood and agreed to by the investor. They are more likely to have a whole of life view that includes how easy the system is to maintain!
• Work that doesn’t meet criteria is not considered done. You avoid that whole “95% complete for 3 weeks” issue by being very binary about done and not done.

Agile project management training

If you want to explore this topic further, Equinox IT has released a NEW course Agile Project Management - Adapting context to practice. This 1-day course provides a pragmatic approach to understanding how Agile frameworks differ from traditional project management approaches, how and why they work, and what ‘going Agile’ means for project management and project governance.

Find out more about the 'Agile project management' training course

Carl Weller is a Principal Consultant specialising in Project Management and Agile Leadership, based in our Wellington office.