In 6 attributes of a good ScrumMaster Mike Cohn repeats the common line that the ScrumMaster role does not always require a full-time, eight-hour-a-day commitment. Often the ‘orchestra conductor’ role of ScrumMaster is an unofficial one within your organisation even though it clearly has well defined functions and responsibilities. So many people do ask the question Is a ScrumMaster a full time position? As Boris points out, it is, and he explains why it is a 100% fulltime job.

The ScrumMaster has internal and external responsibilities. Even if the team is well disciplined with following the process, and they address most of their own impediments there is still the challenge of being a gatekeeper between the management and the team. This is being recognised in many organisations now and you can even see ScrumMaster as a recruitment position. It’s interesting to note that many of these positions have Project Manager / ScrumMaster as the title.

What does a Project Manager do that a ScrumMaster does not (or vice versa)? A project manager is the person who has the overall responsibility for the successful planning and execution of a project. This title is used in the construction industry, architecture, information technology and many different occupations that are based on production of a product or service. While strictly speaking, the team, rather than the ScrumMaster has responsibility for the success of the project, a ScrumMaster does assume responsibility for the team’s adoption of Scrum and practice of it. A ScrumMaster takes on this responsibility without assuming any of the power that might be useful in achieving in it.

To boil it all down to it’s essence, a ScrumMaster is a Project Manager who has realised that they don’t really have the power to successfully deliver a project, and has adopted a framework to take advantage of that humbling position.

After discussions with friends, family and work colleagues over the past few months it became apparent that we all have a different idea on what priorities are and how do we identify priorities. Here are my thoughts on the matter.
Why prioritise?
It’s very dangerous to ask staff and customers what they want to see in the next release. The result is a mixed wish list of the most amazing things. By the time you’re ready to start development, you’ve got enough ideas for improvement to occupy 500 programmers for a few decades.
Unfortunately, all you have is three, and we wanted to be shipping within 6 months, so there has to be some prioritisation. Time is an important resource, and we have a limited amount of it. With software, one does not have the luxury of a long development period to bring a product, or a new release of an existing product, to the market. Potential new customers will not be interested in a product that does not improve on a regular basis. Someone else may do it quicker. Your customers may migrate to a different solution that has the feature(s) they are looking for.

Capacity must be influencing our priorities. Because capacity is time based, our priorities are time based. Too many software development teams suffer from ‘inflation of time’; that is to say, they devalue future time by using it to solve present problems. The problems may not be the most important ones to solve today. Of course, the time spent on one thing means that some other activity remains undone. Each time we put off a portion of our work to do at a later date, becaue we haven’t time to do it today, we are devaluing future time in the sense that we now have less of it.

There can be a tendency for people to avoid the hard decisions and use capacity, or estimation of effort to set the priorities. For example, if the risk management feature takes more effort to implement we’ll go with the loan book profitability feature instead. While capacity is effective in determining what to do with activities of the same priority, it is not the only influencing factor in establishing a prioritised product backlog. There may be features that are must haves for the next release. They may be expensive to implement, but without them market share may not grow. This is where market research is really important. The product owner must be able to say: “To get the risk management feature we can sacrifice the loan book profitability feature because risk management addresses a need for a broader range of potential high value customers.” The product owner must also have the courage of their convictions and vision, based on their research and understanding of the market. Just because something is difficult does not mean it is not worth doing.

Prioritisation pitfalls

Sometimes certain features or activities can appear to be important and necessary in the next release. Here are some prioritisation pitfalls. If you find yourself condsidering this sort of features in your next release, spending some more time on research, verifying the importance.

Single customer requirements

It is generally cheaper to get new business from existing customers than it is to get new customers. Having customers can cause it’s own headaches, particularly if your sales person has sold the customer a product you don’t sell. This happens a lot more than it should, and opens the door to legal hassles that are just not worth the effort. Even when this doesn’t happen, there can often be enhancements suggested by your customers. Many of these will make sense, others may be bespoke features that no one else is interested in. Building features into your software based on single customer requirements implies that you are actually building consultant-ware, not shrinkwrap software. Shrinkwrap software is better than consultant-ware. That’s because shrinkwrap has no marginal costs for each additional customer, so you can essentially sell the same thing over and over again and make a lot more profit. Not only that, but you can lower the price, because you can spread your development costs out over a lot more customers, and lowering the price gets you more customers because more people will suddenly find your now-cheaper software worthwhile, and life is good and all is sweet. If you have customers that are requesting unique features not no other customer is requesting, then perhaps the real priority feature is a plug-in architecture, rather than the business feature.

Perceived inevitable requirements

Good software developers often think in the abstract so that the real implementations are more reusable in concrete scenarios. However, just because something is the next logical thing to do, does not mean it is the most important thing to do next. For example, a system may have a notification module with SMTP and SMS interfaces. A logical next step would be a XMPP interface for instant messaging. Such a feature may be interesting for the developer to work on, and may even give the marketing department something cool and trendy to draw attention to, but is it a deal clinching feature? Are more customers looking for this feature than some other feature, such as not notifying people who are on leave, but they’re deputies instead?

Prioritise interface that the user sees

There is one category of features that software developers may subconsciously discount. I’m referring to what the end user interacts with as a tool to for their job. The interface with your software may not be the GUI, but also a web service or a device. These deserve our attention because they increase the awareness of the value of what we can do with technology. Nobody sees a shared library or a driver, and no one cares about them, unless they’re broken. Yet that’s where software developers can tend to focus much of their time and resources. Doesn’t this contradict an earlier point about building a plug-in architecture? No. The motivation, in that case, to build something that the user does not see, is to provide a sustainable and cost effective solution so that the customer gets what they want (a business feature) without you having to provide it or maintain it.

A prioritised list, reflecting the capacity of the team, and what the business value of the new features are makes for a more sustainable (if no one pays for it, who pays the team) development effort down through the years.

Clearly the use of scrum with distributed teams is something a lot of people are talking about right now. After last months article on scrum and offshoring, focusing mostly on communication challenges, I have noticed a number of blog postings on the subject. David Myers (a consultant at London based Charteris), in his article on Scrum and Outsourcing, goes into great detail about the challenges with distributed teams. For me, the key points are that basic agile practices of communication, meaningful documentation and continuous integration removes some of the hurdles. However, the manner that the standards / approaches applied have to suit the team.

I’ll leave the last word to David…

For me the most important consideration when employing Scrum with offshore resources is that it should not be employed without modifying and/or tuning some of the practices to be more suited to working with geographically split teams. This tweaking (or lack thereof) can have a fundamental effect on the end result.

A question posed a few months back on stackoverflow on scrum and offshoring got a number of mixed responses. Many state that scrum does not work with remote teams. There may be a number of factors to scrum not working, which has very little to do with scrum in the first place. Some teams are not suitable to scrum, or rather, the individuals on the team are not suitable. Scrum requires a change in mindset, to be proactive, not be willing to fail, and be willing to be honest.

The time difference does appear to be the biggest obstacle. Many of the other issues, such as cultural differences, can be resolved, or at least mitigated, with direct communication. Direct communication is hampered when remote teams work in different time zones.

Flexibility is required from the team members in all locations. It may suit some members of the team to start early and leave early so that their working hours overlap with some of the others. This has to be sustainable. The team members that come in early should not be the ones who regularly leave late. If this occurs, there is a problem with resource bottlenecking. What would happen to the team when this member goes on holidays? A meeting that involves the whole team is often not required if the team members take the responsibility to communicate to each other. I have found instant messaging to be quite useful in this regard. When having a discussion with some team members in a chat room, the messages can be saved and posted to a wiki or emailed to the rest of the team. This also helps to clear up confusion over what was said during a telephone conversation.

Note that I only refer to one team. Referring to a group of team members by their location may reinforce the differences between the groups. For example, rather that referring to team members as the ‘San Jose Team’ or the ‘Palo Alto Team’, try ‘The team members in San Jose’ or ‘The team members in Palo Alto’. This suitable change emphasises that the team is one unit, just distributed.