The company
Our company, Qualogy, is based in The Netherlands. It is a consultancy company specialised in Java and Oracle technologies that has been using Scrum and Agile both internally and for customers for a while, now. Our company has a daughter company based in Suriname, a former Dutch colony where Dutch is a national language, and where Software Development project are still a relatively rare event. This daughter company is primarily meant to serve the local Suriname market, using local talent, at local prices. Next to that we also do small-scale outsourcing, where the lack of a language barrier (and mostly of a culture barrier) with The Netherlands is a major advantage.
We’ve been using Scrum in Suriname with the development teams there, with good success. A combination of local and remote coaching has worked well to get the teams familiar with the process working on location at Suriname customers, and internally for both Dutch and Suriname customers. This was successful enough that when we found the management team not working in the same close step with the central management team, we quickly had the idea of trying to Scrum with the Management team as well!
Situation in the management team
While visiting the Suriname office, a number of issues had been raised, both by the local management team as well as by the visiting central management team. Some of the problems encountered were:
- lack of transparency, both within the local team as towards the central office
- lack of progress in certain areas
- problem resolution was difficult and often required interventions
Apart from specific issues at the outset, there are also differences between your average development team adopting Scrum and a (distributed) management team. When researching this, I came across some discussions. Some are new versions of familiar issues when starting a new Scrum implementation. Some were entirely new for me.
- The management team has very diverse skills and areas of responsibility
- The operational management has to deal with a lot of interruptions
- Managers may be even more averse than developers of having their progress ‘checked’ (visible)
- Explicit priorities are much more likely to be interpreted as ‘micro-managing’
Creating a backlog
To get started with our Management Scrum, we started by formulating a backlog. The backlog was, at least on a higher level, quite clear. This was actually an interesting learning point for me: the translation from high level business goals to specific actions is much more direct on the management level, and the number of stakeholder is much more limited (in this case: one). The Product Owner for the team was the manager responsible for the Suriname division.
The backlog immediately revealed one of the issues mentioned above, where in a large number of cases the backlog item/story was in effect already assigned to a particular team member (sales manager, operations manager, …). Team members had specific skills (or networks) that enabled them to pick-up a story. We took this as a given, understanding that it would be an issue to overcome as far as team work is concerned, and allowed the pre-assignment of stories.
Then, since the product owner would only occasionally be present in Suriname, the product backlog had to be available on-line. For this, we used pivitol tracker. I always try to avoid using electronic planning boards, but for this situation it was appropriate. Pivitol is a very nice tool, with purposefully limited customisation options.
With the initial backlog ready, we moved on to estimation. I had explained the concept of Story Points before, but the team wasn’t quite comfortable to use those. Additionally, the problem of ‘unsharable stories’ due to the different areas of work mentioned above, meant that it would probably also be hard to come to a good velocity figure in Story Points. This resulted in us adopting ‘ideal days’ and focus factor as a way of managing reality based planning. The team estimated the backlog items, and split some up into more manageable chunks in their first planning meeting.
And then the first Sprint could start. Almost. There still was some discussion on the length of the Sprint. The PO initially wanted sprints of four weeks, or one month. After sizing the backlog, it became clear that there was an advantage to keeping the items on the backlog small, and together with feedback from some of the development teams in the company he was convinced that a shorter Sprint length would be beneficial. So we arrived at two weeks.
First Sprint
The work started well, with items getting picked-up by all team members. We started with weekly ‘stand-up’ (which was done through Skype) meeting, because a daily schedule was considered too intensive, and also feared to be too invasive: there was some fear of micro-management from within the team.
The first couple of meetings surfaced a few issues. Though some stories had been finished, quite a few were stuck in ‘in-progress’. A sure sign something was up! We discussed those stories, and the reasons for the delays. One reason was simply that other things had to be done first. The team was assured that they could always add items to the backlog themselves, as long as the PO was notified so he could prioritise. And it was normal that the day-to-day business would take time, and we’d have to take that into account in determining our velocity.
Another reason for slow progress on stories was that for some of the stories we found that the story was not clearly enough defined. For the PO the large size attributed to these stories by the team had been a surprise during the backlog sizing. He hadn’t wanted to push for a lower estimate, though, since that should be team choice. This issue was solved by the PO pairing-up with the team member to formulate an outline together (of the document this story was about), which automatically lead to a good way to split-up the user story, after which the team could continue autonomously.
As you can see from the above, we encountered a number of (fairly familiar) issues while working on the first sprint. So when we held our first retrospective meeting, we already had some improvements made.
The major points that came out of the retro were a wish of more mutual transparency: the members of the team wanted to have more information on what the others were doing, and how far items had progressed. To accommodate this, we resolved to start with a daily stand-up, to make sure items were actually moved on the pivitol board as soon as they were finished, and to split-up work in smaller increments.
With the second sprint in progress, and some good results already, we are quite happy with the way Scrum is turning out for the team. We are having mostly good results, with more progress being made on strategic projects, and more visibility (and appreciation) for local issues. The team was particularly struck with the fact that with the new levels of transparency and communication, even given their the different areas of expertise, it has become easy and normal for them to pick up parts of each other’s work regularly.