www.frontiersin.org

We just brought live the new site of http://www.frontiersin.org, which was my biggest SCRUM project up to now. Here are my first learnings from this project:

SCRUM helped us (we were client on this project) to see much earlier were the development team was going, and had regular feedback points at the SCRUM demos.

However, there was a conflict between the SCRUM tenet of minimal documentation and our customer requirement to fully document the project – which was needed for support and knowledge retention purposes, but also to have an agreed baseline for customer acceptance.

The size of the project (1 year, a peak of 60+ people in 8 teams) was quite amazing, and being a “remote” customer in a different timezone did make communication difficult at times.

Splitting out some special teams was also not strictly in line with SCRUM, but it has worked for us – we have split out a functional analysis and screen design team, which worked always 1-2 sprints ahead of the development, and in the end we also split out a separate test team. Especially the separation of the test team was a violation of the SCRUM tenet of cross-functional teams, but again: it has worked for us in this specific environment.

Each of these points would be probably worth a separate article in the future – let’s see whether I find the time for it.

I would be interested to learn of any experience of other people on larger SCRUM projects.

SCRUM and PRINCE2 – again

I found a slideshow on integrating scrum with classical project management which is much more elaborate than my post a few weeks ago – looks interesting.

Although I must admit that I was fitting these two processses together to embed my project better in the surrounding culture, not so much because I believe that it is a fundamentally great thing. After all, adding two processes together will only make things more difficult at first. It is an interesting option mainly when you are constrained in your choice of processes like in my case, I had to manage it as a Prince2 project on the macro level whether I wanted or not.

Encapsulating SCRUM for the micro level allowed me at least to choose some agile practices for the devlopment team while the project manager could take care of the Prince2 representation of the project at the board level.

PRINCE2 and SCRUM – can they live in the same world?

Intro

In this article I would like to go into some experiences of applying SCRUM in a corporate environment which is dominated by PRINCE2. I assume some knowledge of  PRINCE2 and SCRUM, because it would be beyond the scope of this blog to give a primer on both. You can find some introductory material on PRINCE2 here: http://en.wikipedia.org/wiki/PRINCE2 and on SCRUM here: http://en.wikipedia.org/wiki/SCRUM

Technical aspects

There are a lot of points where PRINCE2 and SCRUM can be joined.

First, both put a high emphasis on making sure the project delivers business value – In Prince2 in the form of a business case, in SCRUM each Sprint planning meeting is going through the business value of each requirement / feature / story and thus aligns business benefits with the project costs.

Second, Prince2 mandates a certain structure for the project from a macro level, but leaves it optional that some teams within the project can operate under a different process. The only requirement is that for each “work package” the team manager agrees delivery plan, acceptance critertria and tolerances with the overall project manager. In most cases these tolerances are expressed in schedule or cost, but for a SCRUM team it is more logical to express the tolerance in terms of scope. Thus you could use the Sprint backlog from the Sprint planning meeting as a PRINCE2 work package.

In a big project it could well be that one subteam is using SCRUM for software development, while other subteams (e.g. server procurement,  network setup,  user training,  marketing) might not use SCRUM at all.

PRINCE2 is having a small part of adaptive planning in the idea of having project stages, and doing detailed planning only for the next stage. These stages could be mapped to either SCRUM sprints or to milestones. Typically a PRINCE2 project stage would be longer than a SCRUM sprint, but this depends on your setup.

I would see the best approach to work with an agile team in a PRINCE2 project is this approach of encapsulation: SCRUM is used on the development team level, PRINCE2 is used at the macro level, the adaptive planning of SCRUM is reflected in the stage plan of PRINCE2 and the tolerance for each work package. Each sprint backlog is seen as a workpackage for the PRINCE2 project. The Scrum Master is mapped to the PRINCE2 team  manager role, responsible for the outside communication from the development team to the project manager. The Business Owner for the Product backlog is either the senior user from the PRINCE2 project board or a delegate of the senior user.

Cultural aspects

It is a fact that SCRUM and PRINCE2 come from different angles and traditionally PRINCE2 is definitely not an agile method. The different mindsets of forward planning vs. adaptive planning will clash at some points, even if technically the two approaches can be integrated.

With some level of understanding on both sides this can be turned into a workable solution, the PRINCE2 framework is flexible enough for integrating an agile development team, but most PRINCE2 project managers may not be adaptive enough to deal with this situation.

Summary

Whether it is a desirable setup or not, if you are working for a client who has adopted PRINCE 2 or your own company runs projects according to PRINCE 2, it is still possible to create an agile environment for the development team and reap the benefits of SCRUM by encapsulating SCRUM within PRINCE 2.

Introducing SCRUM – ideas for a process backlog

In a recent project, I had to bootstrap a SCRUM environment – so the question is where do you start? One way of course is to get everybody on a SCRUM training, then setting up some infrastructure, and then start. I had this luxury at a previous company in pre-SCRUM era, but not this time a more agile approach was needed. We had a project pipeline which was more than full and had to deliver while in transition towards SCRUM. So the idea was to introduce SCRUM  incrementally – after all this is what SCRUM is about.

So, what can you actually achieve in terms of implementing SCRUM in your first sprint if the situation is not in your favour? You have a  distributed team? Command and Control culture? Not one product manager but a board of 15 with no single shared view? And maybe more…

Well, it is not realistic to do everything at the start. And also, you will need some success stories along the way to sell the idea both internally in the team and outside to management and other stakeholders. One way is to look at short term benefits with each single change. Starts to sound like the devlopment of the product itself. So why not  build your “process backlog” to prioritize and schedule.

The process backlog

On this “process backlog” you could put all SCRUM practices like creating a product backlog, using timeboxed sprints, having daily scrum meetings, etc. And you could also add supporting practices like setting up a continuous integration environment, among others. Some of these may be from the XP world, but it really depends on your situation.

Then you pick items from this list for implementation in the upcoming sprint. As soon as the sprint retrospective is implemented (may be at the end of sprint 1) this is a natural place to look at process items to pick and implement.

Story 1: timeboxed sprints

The easiest sell in my experience was the concept of a timeboxed sprint  – it gives the customer the assurance of a timeline and the price (possible de-scoping) is not so visible at first. There will be fights about this later towards end of the sprint, but it is still reasonably easy to sell the idea.  If you must, you just implement monthly project reviews and go through the agenda for the end of Sprint demo without telling oo much theory. Once they start to like this idea you tell them what SCRUM says about it. (Actually this is another great idea I got from Henrik Knibergs great book “Scrum and XP from the Trenches” and I wish I had known this earlier)

Story 2: daily scrum

Also, the daily scrum meeting was a point at the start. In the beginning it did not feel like a “self organizing team”, more like traditional top-down micromanagement. Still better than no communication at all, but geographical distribution and cultural gaps in the team have made it difficult to get to a more collaborative approach quickly. So the meeting had to be done on the phone actually because we wanted to keep the ceremony low. Just thinking of getting everybody into a video conferencing room (and booking this rooms in both facilities in advance) was not something I wanted to tackle in the first sprint.

Story 3: sprint backlog

Then there was the sprint backlog – in its almost simplest form of an excel spreadsheet. A real task board was not the right start for us because the team was in different continents. It would be great to have a better tool support for this but this was out of sope for the first sprint. I am toying around with Sharepoint wiki’s because it was available, and this could be a next step. The goal would be to build more a visual and collaborative experience for all team members to get them “hooked”.

Outlook

This was about as much as we achieved in the first sprint – after all we basically have put this into a team used to less agile ways of working and we couldn’t invest too much time in process changes, tools or training.  All of the process investment has to be incremental over time. The plan would be to address the product owner problem next and make sure we have one product owner to be a single point of contact, and this one would need the authority to prioritize and the acessibility that the team can actually use her as a knowledge source. Once we have someone to own the product backlog, this needs to be implemented next.

This was the experience from the start, I will later write a followup to keep you up to date.

Thanks for reading, and I do hope that these ideas are useful.