Scrum And Non-Scrum Interfaces
According to the short and sweet Schwaber/Sutherland Scrum Guide, a Scrum team is comprised of three, and only three, simple roles: the Product Owner, the Scrum Master, and the Developers. One way of “interfacing” a flat and collaborative Scrum team to the rest of a traditional hierarchical organization is shown below. The fewer and thinner the connections, the less impedance mismatch and the greater the chances of efficient success.
Regarding an ensemble of Scrum Developers, the guide states:
Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule.
I think (but am not sure) that the unambiguous “no exceptions” clause is intended to facilitate consensus-based decision-making and preclude traditional “titled” roles from making all of the important decisions.
So, what if your conservative org is willing to give Scrum an honest, spirited, try but it requires the traditional role of “lead(s)” on teams? If so, then from a pedantic point of view, the model below violates the “no exceptions” rule, no? But does it really matter? Should Scrum be rigidly followed to the letter of the law? If so, doesn”t that demand go against the grain of the agile philosophy? When does Scrum become “Scrum-but“, and who decides?
Related articles
- The Scrum Sprint Planning Meeting (bulldozer00.com)
- Bring Back The Old (bulldozer00.com)
- Ultimately And Unsurprisingly (bulldozer00.com)
- From Complexity To Simplicity (bulldozer00.com)
- Why I’m done with Scrum (lostechies.com)
Leave a Reply to charliealfred Cancel reply
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 
“All animals are equal, but some are more equal than others” – George Orwell
IMHO, SCRUM is pretty much like Animal Farm.
On a related note, one of my colleagues worked on one of the first (if not the first) SCRUM projects with Ken Schwaber and Jeff Sutherland. I’ll have to hook you two up. He has some very interesting stories to tell. The inside stories are always more interesting than the PR-scrubbed versions.
Thanks for stopping by Charlie. I’d love to somehow connect up with your friend and ask him about his experiences.
I have a fundamental issue with any methodology that ignores basic facts. The rather rigid definition of “the team” is an excellent example. Placing QA, CM, Program Management, Operations, etc. outside the circle is an arrogant fiction. Just as the Marines are tied to the Navy until they learn how to walk on water, development is tied to operations until they learn to run code without hardware. The implication that there are no specialists within the team is likewise wrongheaded. Once you have a system of any real size, it’s highly unlikely that any one person (much less the entire team) is familiar with the entire depth and breadth of that system.
Hi Gene,
Thanks for stopping by. I agree that crystallized rigidity in any system where people are involved is not so good. Nevertheless, some sort of bounding of what’s in and what’s out is necessary to some extent for order/coordination, no? As long as the interface bridges between the “ins” and the “outs” are flexible, fluid and changeable due to learning, the system as a whole can operate effectively, no?
Hi Tony,
Bounding is necessary, but needs to be appropriate. What I see above (and it seems to be a pretty accurate depiction of common attitudes) is a subsystem attempting to define itself as the system, or at least the driver of the system. Any process attempting to drive what is ultimately a multi-disciplinary endeavor via the viewpoint of a single discipline, is the tail trying to wag the dog. It only works when the dog goes along. A more comprehensive, inclusive process (with internal boundaries & interfaces) would seem to be more realistic.
Interesting interpretation Gene. I see it as an attempt (good or bad) to try and interface two radically different peer systems (in terms of culture) together into one overall encompassing whole with the least amount of friction.
The official Scrum guide doesn’t give much direction on “external interfacing” other than implying that the Scrum Master does all of it and he/she shelters the rest of the team from the “outside” world: “The Scrum Master helps those outside the Scrum team understand which of their interactions with the Scrum team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum team”.
It also says: The Scrum Master serves the organization in several ways, including:
• Leading and coaching the organization in its Scrum adoption;
• Planning Scrum implementations within the organization;
• Helping employees and stakeholders understand and enact Scrum and empirical product development;
• Causing change that increases the productivity of the Scrum Team; and,
• Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
To be honest, it reminds me of your earlier post re: problem spaces and solutions – it’s a subset of the larger problem space. That can be fine when taking incremental bites, but you can’t declare “done” at that point. The lack of flexibility disappoints as well – no one prescription will fit all circumstances and refusing to allow for tailoring is a weakness.
Regarding the Scrum Master, given the vast range of disciplines that fall outside the team, I really doubt that the role can be an effective interface. IMHO it would be better to adopt a more porous and flexible definition of the team rather than try to segregate them.
Thanks again for your thoughts. If you were tasked with kicking off a Scrum project in an org that is accustomed to traditional roles and processes and (most importantly) behaviors, what guidelines/advice would you propose for smoothing the interactions? Would they be abstractly general like the Scrum Master bullets above, or would they be more specific and directed at the roles identified in both cultural worlds (program manager, functional manager, technical lead, QA specialist, CM specialist, Product Owner, Developer, Scrum Master, etc)? Not acknowledging that different mindsets are at work doesn’t mean they don’t exist. But maybe it’s OK to not do anything different and hope for the best with platitudes like “let’s all work together”, “we’re all one team”, “it’s not us & them, it’s just us”?
I absolutely agree that throwing “New and Improved” on the label without changing the formula is a recipe for disaster. By the same token, I’m something of a rabid pragmatist and much prefer to know that what I’m doing is tailored to my particular situation. A good example is my initial reaction to your question: “the fact that it’s a Scrum project as opposed to a project to develop X is a red flag because customers pay for X, not the process by which X was developed”. For that matter, I prefer to think in terms of products/system rather than projects, as any given project is merely a fraction of a given product’s lifecycle.
That being said, the question of how to optimize an organization’s process is a huge one (I’m collaborating with someone right now on a post on that very subject). I would suggest engineering the process in the same manner as engineering an app. Identify what (not how) needs to be done, who does what, what things can/do get in the way, etc. Then, design the practices to achieve the goals and/or mitigate the obstacles. Lots of different factors play into this, from the type of app a team works on to the type of industry the team works for. What suits the Angry Birds team probably won’t work for Wall Street (just ask Knight Capital).
Many of the problems I’ve seen with traditional processes come down to “pinching the balloon”. A problem occurs and an isolated fix is identified without analyzing how it affects the rest of the process. Lather, rinse, repeat enough and you have the human equivalent of a big ball of mud. Treating process as a system is key, IMHO.
Lastly, I want to call out your comment about different mindsets, because I think that what you said is hugely important. Any process should be built around that fact and use that tension rather than trying to do away with it. Shielding a team from other groups priorities can backfire, horribly. Having them understand what the priorities are and what the options (with attendant costs) to meet those priorities are should lead to more satisfaction on all sides.
Good stuff Gene. Thanks again.