Golden rules for an agile reporting structure
Thursday, September 13, 2018
What do you do when implementing Scrum? Who does what and what about Scrum reporting? Here are five “golden” rules for ensuring that any model you deploy does not undermine the fundamentals of agility.
For the majority of organizations adopting Scrum, they are moving from a traditional team-based model to a Scrum-based approach. Traditional team models vary for every organization, but normally have the following elements:
- A project manager responsible for ensuring the project delivers
- A line manager who individuals in the team report to. That person does appraisal reviews and deals with any ‘people’ issues that come up. For many organizations, these people are functional managers for groups such as testing or aligned to particular applications areas such as customer service.
- Resource managers who are responsible for finding the right people and ensuring that those people are utilized
Of course, the titles, and job descriptions may change, but the majority of project-based organizations fill these responsibilities.
Scrum and roles
Scrum is a lightweight framework that enables teams to solve complex problems and deliver value. It is NOT either a process or organizational model. The roles in Scrum are NOT job titles. They also only describe what is needed to deliver value in an agile fashion, not how you develop people, deal with holidays schedules, do reviews, or even how you pay people. All of those things are necessary for running an organization but are not part of the framework.
What do you do when implementing Scrum? Who does what and what about reporting?
Unfortunately, there is no simple answer to this question because it depends on the context of the organization. For example, some organizations have strong unions making titles hard to change. Other organizations have very rigid performance review processes. Others have a strong historical structure for job families.
Instead of saying there is one model for reporting and structure, here are five “golden” rules for ensuring that any model you deploy does not undermine the fundamentals of agility.
1.) Ensure that work management is separate from people management.
Agility requires transparency, and there is no way to adapt if you do not have the correct information. If, however, transparency requires an individual to be ‘super honest’ to the person doing their review, paying their bonus and building their development plan, then it is possible that the facts will always be delivered with a certain ‘positive’ point of view. This will result in a lack of transparency which in turn will create waste and reduce effectiveness. It is easy to say, “be open and honest,” but hard to be that way when your next bonus is perceived to be at risk.
2.) One team and only one team
The mass production model of knowledge work that many project-based organizations follow, would encourage the idea that people can be on many projects. Each person comes with a special set of skills; thus, a project manager can optimize the work by using each individual and their skills as much or as little as possible. The plan glues all of these people together in pursuit of the outcome. The portfolio plan ensures that people are ‘utilized’ to their fullest. Unfortunately, the problems that agile teams face are complex. That means that we don’t know all the skills we will need up front, or how much effort each individual will expand. In fact, to deliver value the whole team may need to storm on the solution. Traditional work breakdowns will neither work or be an effective way to drive value. By keeping teams together and supporting them with shared support services you allow the team to do what it takes to deliver value.
3.) Ensure there is a place for technical leadership
When building a Scrum Team, we often break up existing functional departments. This is great in enabling a clearer focus on delivering customer value, but not always so great for technical skills development. Functional departments by their very nature provided a technical career path and a support organization. When moving to a Scrum based delivery model it is important to put in place a replacement for the functional department structure. For example, Spotify looks to Guilds to support particular skill or role clusters. Other organizations invest more in their community of practice funding community leaders and making them responsible for talent acquisition and development. By having a clear technical career path and an organization that supports it you provide practitioners with a path outside of the team.
4.) Make promotion process explicit and visible.
Adopting Scrum SHOULD NOT remove a person’s ability to get promoted and have a career. In fact, with professional Scrum, it should actually increase their ability to develop new skills and get closer to the customer which will result in promotions and a more enjoyable job. However, for many transformations, career development and promotions are secondary to delivering work. It is therefore important that there is at least a draft plan about development and promotion in the new structure.
5.) Scrum Masters are valuable, and they are much more than Agile Coaches.
Of course, I am biased, and their job title can be Agile Coach. But the role of a Scrum Master is pivotal for being agile. Having someone who, at the team level is responsible for ensuring that the principles of empirical process, self-organization, and continual improvement are being followed. Who makes sure that work is flowing, impediments are being resolved, and that everything is being done in a transparent manner is crucial.
Who you report to is often more than just reporting, but says a lot about the value the organization places in you, and in many cultures how a person measures their own self-worth. When adopting agility, it doesn’t matter if we say, “You are still valued,” if that requires title or reporting changes that people outside of the agile organization would perceive as a demotion. Titles and reporting structure do matter, not in terms of process and work, but in terms of motivation and safety. That means it is the responsibility of leadership to provide an environment that supports Scrum Teams both in terms of delivering business value and also talent development and growth.
This content is made possible by a guest author, or sponsor; it is not written by and does not necessarily reflect the views of App Developer Magazine's editorial staff.
Stay UpdatedSign up for our newsletter for the headlines delivered to you