The top five organizational impacts due to Scrum
Image by Mzelle Biscotte: http://www.flickr.com/photos/biscotte/
- Timesheets. Scrum teams don’t “do” timesheets. This is in interesting contrast to many, many organizations where it’s a weekly ritual to fill out a timesheet and have it signed off.
Why don’t Scrum teams do timesheets? Simply because there is no correlation between developer time and the production of high quality software.Measuring timesheets not only serves no purpose for the measurement of progress or quality, but it also provides management with poor data upon which they make decisions. Even from just a practical point of view of eliminating unnecessary work, filling in timesheet does not make sense.
The only justification for timesheets (that I can see) is the tax implications of different types of work. In some countries, new software development is taxed as capital expenditure while fixing defects is taxed as an expense. This is absurd because the distinction between “defect” and “feature” is arbitrary. … it’s a defect until the software ships, and then it’s a feature!
In fact, Microsoft developers deliberately brought forward “defects” found in Windows 95 and 98 so that Windows XP would not break existing software. Do timesheets really account for the nature of the work, or are we simply providing numbers to satisfy overly complex accounting?
- Compensation. Compensation is a very tricky subject at the best of times, partly because people are very private about their salaries and bonus packages. This has been brought about, due to employees being compensated as individuals.
People are much more open to discussing compensation when they are compensated either collectively or if their compensation is a matter of public record. I worked with a group from the US Treasure who were more than happy to discuss salary because, in their words “… everyone knows what we get paid.”
But Scrum advocates that the success of a project be attributed to the whole team, in contrast to individuals. Attributing the success [of a project] to a particular individual, will discourage collaboration and result in unhealthy individual competition. While attributing success to the whole team increases collaboration and trust.
So, Scrum teams often have a team performance component to their compensation, in addition to a base salary.
In order to encourage collaboration, Nucor makes sure that its profit-sharing formula rewards relatively large teams, not just the individuals or small groups who have direct responsibility for an area.
- Mary Poppendieck. - Career paths. Scrum defines three roles: the ScrumMaster; the Product Owner, and; the Team. How do the roles in your current organization map to these roles? What does it mean, for example, to be a Business Analyst on a Scrum Team? Or, a Senior Architect? Should and how does one progress, if there is no distinction within a Scrum Team?
There are no easy answers to these questions because every organization has their own definition for each of the different roles, and their own different considerations. I’ve made some suggestions in the past which may provide a starting point, or at the very least can start the conversation.
- Budgets and Funding. Scrum deliberately and actively supports the Product Owner owning the budget. This can be expressed as: The goal donor should also be the gold owner (with apologies to Kent Beck). More explicitly, Scrum supports the funding of software projects from the business. This is in contrast to many organizations where funding for software development is obtained via the CTO or VP of Engineering.
If your organization provides funds to the IT department for software projects, rather than the business then the change to Scrum may be very political and confrontational. Obviously any discussion about shifting a budget from a VP of Engineering to his business counterpart is going to be met with resistance. In order to make this happen the VP of Engineering will need to be convinced and well educated of the benefits.
If your organization already funds software projects via the business (an increasingly common occurrence in small to medium size businesses) it’s business as usual.
- Management Responsibilities. As mentioned about, Scrum explicitly calls out three different Roles: The Product Owner; The Scrum Master, and; The Team. Scrum makes no mention of managers or management roles. That doesn’t mean that Scrum organizations don’t have managers … they do. However, any change in culture will impact peoples roles and responsibilities, and when introducing Scrum, this is true for all parts of the organization including management.
Line managers [such as Dev managers, QA managers etc] often feel particularly vulnerable in a Scrum environment. If, for example, a managers direct report’s are now reporting to their Scrum teams, then it is possible for the manager to feel like he has “lost control.” In reality he never had “control” but the feeling of chaos and uncertainty is very real and unsettling.
Scrum does not provide an answer to the question “What is a managers role in Scrum?” simply because the answer is different for every organization. Every company will have to struggle to define what works within their environment, and find their own solution. Jeff Sutherland wrote an interesting article which may help in trying to find some answers to the question.
