Who’s accountable? Who’s responsible? Who’s leading? These are key questions to every organization’s basic design. In traditional, functional organizations, Engineering Managers are accountable, responsible and leading development activities. In Scrum-based organizations, the answers may be different than one might expect.
Traditional, Functional Organizations
In traditional, functional organizations, Engineering Managers are accountable, responsible and leading development activities. If there’s an issue or commitment needed, just engage the Engineering Manager to resolve it. Move up the organization as needed. Simple!
Or is it really? As we’ve discussed in the Affecting Change blog posting, traditional, functional organizations are highly complex due to their process, planning and functional specialization. Seldom are Engineering Managers solely the accountable, responsible leaders. One must consider who owns architecture, product requirements/priorities, process and personnel management to truly address who’s accountable.
Scrum-based Organizations
In Scrum-based organizations, the who’s accountable, responsible and leading questions exist and have different answers than one might expect. While this blog posting is focused on Engineering Managers’ role, let’s step back to Scrum, as defined by ScrumAlliance.Org.
At the core of Scrum is the Scrum team. In Scrum, the team has been provided everything that they need, as a self-organized team, to convert a Sprint Backlog into production quality increments of customer value. This includes the right talent/skills, tools/methods, architecture/design and product backlog. The Product Owner sets the sprint goals and product backlog. The Product Owner is responsible for the ‘what’ and the Scrum team is responsible for the ‘how’. The Scrum Master is responsible for making sure that the Scrum Team follows the Scrum process correctly, that would be: Sprint Planning, Daily Scrum Stand-ups, Impediment Management, Sprint Reviews and Sprint Retrospectives. Beyond these responsibilities, Scrum is silent because each organization will approach the specifics of team formation, tools/methods, architecture/design and product backlog construction appropriately for their business needs.
A key question from Engineering leadership has been, is that all there is to the Engineering Manager role? Just some talent management and technical advice? Fortunately, the answer is that there’s much, much more to the Engineering Manager role.
Taking a step back
We have been exploring the differences between large-batch, waterfall development and small-batch, Scrum development processes. Let’s review several of the differences before we jump back into the Engineering Management responsibilities discussion.
There are, at least, six major shifts in how work is done when going from large-batch, waterfall development to small-batch, Scrum development and these are: Batch Size, Scrum Management, Scrum Maturity, Teamwork, Architecture and Product Backlogs.
The Batch Size change from a multi-month or multi-year development effort to engineering effort measured in days, is major. A stepwise approach from large batches to small batches where the Definition of Done is Functional Complete, then to small batches where the Definition of Done is System Test Complete, and then to small batches where the Definition of Done is Customer Ready requires a coach and guide. The re-engineering of how engineers work to reach each of these steps is extremely large and complicated.
Organizations often create Scrum management guidelines to describe precisely and explicitly how Scrum is done at in their organizations at scale. Scrum management guidelines must build strictly on Scrum as defined by the ScrumAlliance.Org, that builds on Agile principles. Each of these layers adds constraints and agreements as to how Scrum Teams operate, especially across teams and organizations. Scrum management guidelines will refine over time as the Scrum capabilities mature and as teams reach new agreements on how to work. Scrum management guidelines must be understood and explained to all engineers and teams.
Scrum roles are complex and take time to master. Scrum management guidelines specify the Scrum Maturity Model for all roles, including the Scrum Team. The Scrum Maturity Model is used for teams and individuals to understand all aspects of their roles and to self-assess on how they are doing. The models are used in retrospectives as potential areas of improvement and development.
Teamwork often is not discussed widely within organizations and is important to Scrum. Briefly, there is a stepwise progression to teamwork: individuals, pairs, teams and team of teams. Most traditional organizations are focused on the individual and their individual performance. In Scrum organizations, frequently, they have individuals paired in all their development activities (often called pair programming or pair development). Pair programming has been demonstrated to deliver higher quality code, faster learning and more creativity. Pairs are formed into Scrum Teams who work together to achieve the Sprint Goals based upon the prioritized Sprint Backlog. Scrum Teams have demonstrated self-organizing, self-management, quick learning, high creativity and high productivity. Scrum holds the team accountable for their decisions and results during a Sprint Review. Scrum@Scale is based on the concept of Team of Teams (as popularized by McChrystal’s book, Team of Teams) and extends the basic Scrum models for scale.
Another major shift is how Architecture and Design principles are approached and developed. In Mary Poppendieck’s book, Lean Software Development, An Agile Toolkit, she describes Built-in Integrity (Chapter 6). Built-in Integrity has both perceived integrity and conceptual integrity with the ability to allow refactoring as knowledge/understanding builds. The key is to be clear on your core principles for how you are approaching architecture, then be clear on the customer-perceived integrity (or user model) and then specify the conceptional integrity (or offer/product/system model). Both integrities must allow for learning and refactoring. With this, comes the need to allow teams to operate correctly given the principles, perceived integrity/model and conceptual integrity/model at scale. Exactly how this should and will be done has to be guided by Engineering Managers and Architects.
The last major shift, is how product requirements are specified, prioritized and groomed. Organizations groom the product backlog in the following manner, starting with the Strategy, deriving strategic outcomes, that derive Themes, Epics and Stories. POs and their teams will groom Epics, Stories and Tasks.
Areas of influence and roles
A key aspect to all roles is how they interact and influence others. This needs to be considered as we look at four key roles: Engineering Manager, Product Owner, Architect and Engineering Services (tools, build, integration, validation and DevOps). While each own their specific area, they also each interact, collaborate and influence the others. For example, Engineering Managers will work with Product Owners to help with grooming, dependencies and team capabilities. Similarly, Architects will work with Product Owners and Engineering Managers. Everyone will collaborate with Engineering Services, as needed.
Scrum works because Scrum Teams are given everything that they need to convert Sprint Backlog Items into customer value within a two-week sprint. While this is simple to state, there is a tremendous amount of work done outside of the team to make this statement a possibility.
There are four key external-to-the Scrum Team critical inputs that ‘enable’ Scrum Teams to accomplish their mission. These inputs are a well-groomed Product Backlog, written agile architecture, engineering services and engineering management. When these four inputs are well done, Scrum Teams have the potential to function correctly as a Scrum Team. If any of these inputs are poorly done, Scrum Teams will struggle, if not outright fail. As you would expect, there’s tremendous influencing and collaboration happening between the Scrum Team, Engineering Manager, Product Owner, Architect and Engineering Services to ensure the inputs are exceptional.
Isn’t this about the Engineering Manager?
In addition to the importance of the Engineering Manager, let’s highlight other major areas of responsibility.
First, the Engineering Manager is ultimately responsible for ensuring the Scrum Team is correctly formed, skilled, self-organizing, functional and enabled. As noted above, the Engineering Manager must be fully aware of the six major shifts and where the team is on their journey to mastery with regards to each shift. While the Product Owner is responsible for the product backlog, and the Architect is responsible for architecture, the Engineering Manager must guide the team, the Product Owner and the Architect through their collective transitions, learning and mastery. No one else has this role and no one else has this perspective.
Second, the Engineering Manager is key to ensuring that the critical inputs to the team are of exceptional quality. If the quality of the team inputs is an issue, the Engineering Manager must identify and communicate root-causes, corrections and next-steps with leadership.
Third, the Engineering Managers are engaged directly with the Scrum Team only when they must act and are never engaged directly when the Scrum Team is successful. Let’s break this down. When Engineering Managers must intervene directly in the Scrum Team, they are doing so because the Scrum Team is not well formed, or not correctly skilled, or not self-organizing, or not functioning. Whenever the Engineering Manager is active directly within the team, the team is failing in some respect. Conversely, whenever the Scrum Team is creating customer value per their role with Product Owners and others, and the Engineering Manager is not active in the Scrum Team, the Engineering Manager has a well-formed Scrum Team.
To achieve this, an Engineering Manager must work ahead of the team in each of the six major shifts by working with their peer Engineering Managers, their Engineering Leaders, their partners (Product Owners, Architects and Engineering Services) ahead of the teams’ maturing. Hence, the Engineering Manager role is fulfilled by leading the change into each of the six major shifts, working with those responsible to move the organizational maturity forward.
Examples
As teams are finishing up the last of their big-batch WIP, an Engineering Manager must be working with the Product Owner to guide them to small-batches, work with the validation team on better system test, work with architects on better articulation of principles, etc.
An Engineering Manager may intervene with the Scrum team to explain how their retrospectives only concern external entities that are beyond the control of the team, and to focus the team on what they can control and where the team can improve.
An Engineering Manager should jump into a failing Sprint Planning meeting to explain what the Product Owner is struggling to explain, help the Scrum Master guide the meeting, and get the Scrum Team into the right planning behavior so that the Scrum Team takes over by the end of the Sprint Planning Meeting.
In short, the Engineering Manager must lead the change, the maturity, the mastery of all things Scrum while knowing when the time is right to let the team and individuals fly solo until the team is ready for their next step in their maturity journey.
No comments:
Post a Comment