Sometime back at PM Power Consulting, we were talking about adoption of the Scrum framework for non-technical areas such as Sales, Marketing, Finance etc. Our predominant experience has been in consulting for Agile transformation in software organizations. So, we were naturally curious about how using Scrum would feel like in other domains. Of course, Scrum in non-technical areas has been talked about for a while but I am not sure how the adoption rate compares with software product development – not as much is my guess. There is a lot of material available on the topic with Jeff Sutherland championing the cause – his stance being that almost every human endeavour can benefit from Scrum adoption, the key benefit being getting done twice as much work as you previously did. Refer: http://labs.openviewpartners.com/scrum-for-non-technical-teams/#.WM4N0W997IV

Around the time of the above discussion, on the personal front, I was getting some much-needed improvements done for our home through service providers. The four service teams and their work were:

  • Team 1: minor building repairs (team of four)
  • Team 2: painting house – exterior & interior (team of 6-8)
  • Team 3: carpentry work for repairing doors and windows (team of two)
  • Team 4: electrical fixtures such as some new lamps & ceiling fans (team of two)

Each team had its own supervisors and I was, by default, not only the customer but the overall project manager to make sure integration of the work done by the four teams covering inter-dependencies etc. Many of you may have faced such a situation in personal life – a layman performing the integrator role not knowing much about any of the specialist domains! On top of it, I had to manage the expectations of another key stakeholder – my tenants: a young working couple with a small baby and elderly parents who wanted much of the work in their area done over weekends so that they could be there to shield their elders from undue stress.

With much dancing around, I was somehow able to manage the situation. But it got me thinking (albeit after the fact), whether using Scrum for the entire 4-week “release” could have resulted in reduced involvement / stress for me, better “user experience” etc. Here are some thoughts…

I believe the key benefits of using Scrum in this case would have been better user experience and less rework through better communication and collaboration especially between Team 2 (painting) and Team 3 (carpentry). I realize now that Team 2 did not really know what Team 3 was going to do. Team 3, while being broadly aware of the work of Team 2 (painting), had no idea of the sequence of Team 2’s work. This caused schedule glitches at times and some friction between the two teams. For example, Team 3 would want to do some repair work on a window only to find that Team 2 had just painted it. Team 3 would then have to wait or do something else till the paint dried. After Team 3 did the work, Team 2 any way had to again touch up the wooden surfaces. After the first few days of such mishaps, the painters and the carpenters sort of learnt to coordinate with each other by themselves and not look up to me for direction & resolving conflicts. In hindsight, I (as “Product Owner”) should have conducted a sort of release planning with the two teams so that the big picture was clear to both right up front.

Another aspect I found interesting was that although each team had one lead (supervisor), I did not find team members going often to him for doubts or instructions. Each team member seemed to know what he was supposed to do in various parts of the house and just got on with it. Occasionally, during the day, the supervisor would shout out the team member names and got the status shouted back by the team member wherever they were in the house. So, everyone knew what everyone else was doing! How is that for high visibility with no fancy tools?! Perhaps the team members had worked together on several engagements enabling a smooth operational flow.

With the “release” duration itself being just four weeks, it felt like every day was an iteration. Although every iteration did not deliver a usable deliverable for me, after a few iterations I could get something usable – such as a bedroom complete with interior painting and carpentry work done.

When the Team 2 (painting) team members went for lunch, I used to see them having a post-lunch huddle in the park in front of our house – sort of a Daily Scrum (not stand-up, though!) going over the day’s work so far and plan for the next day. I only wish they had included the Team 3 (Carpentry) team also in their huddle!

So, I wonder how things would have turned out differently if there was a Scrum Master (one of the supervisors could have played this role) for the release to enable communication and collaboration right from the start with release planning etc. But would Scrum have enabled getting twice the work done or getting the same work done in half the time? I do not think so and I certainly would not have wanted it faster. After all, the two teams were keen to finish as fast as possible and collect their fees while I would have preferred a gentler pace. So, in this situation, the case for Agile is for better customer / stakeholder experience and not for the usually touted benefit of getting things done faster! And of course, Scrum would have fostered a better overall working environment for the team contributing to less rework & better quality.

One more thing – including Team 1 (minor building repairs) and Team 4 (electrical fixtures) as part of Scrum would have not had much impact / benefit as their work was quite independent of other teams and they were the very first and the very last pieces of work on the “product”.

As always, we look forward to hearing your perspectives on Scrum in non-software contexts. Thank you!