Share this
Scrum everywhere with Joe Justice - Adopting Scrum outside of technology teams
by Ray Cooke on 03 March 2016
In this recorded Blab, Joe Justice, founder of Team WIKISPEED and a consultant at Scrum Inc. describes how Scrum and Agile is increasingly being used outside of software development and technology teams, and is even being mandated in law in examples such as the New Aquisition Bill of the US Department of Defense. Also on the Blab is Simon Bennett of LASTing Benefits and myself (Ray Cooke of Equinox IT).
Questions asked during the blab
- Why should business teams, government policy teams and non-software technology teams adopt Scrum? (Covered in this post)
- Scrum everywhere - How do technology-based Scrum teams benefit when the whole company ‘gets’ Scrum? (Covered in this Post)
- Can ‘Scrum everywhere’ be taken too far? (Next post with Ray and Simon)
- What are the barriers to adopting Scrum in the business and how do you overcome these? (Future Post with Ray and Simon)
The recorded Blab is ~ 18 minutes long and there is also a transcript of the discussion below.
Blab presenters
Our presenters during the Blab presentation were:
- Top left-hand corner: Simon Bennett of LASTing Benefits, Certified Scrum Trainer
- Bottom Left-hand corner: Joe Justice of Team WIKISPEED, a consultant at Scrum Inc., and Certified Scrum Trainer
- Top right-hand corner: Ray Cooke, Lean and Agile business transformation coach, Equinox IT Wellington office.
Transcript of conversation
Joe: ...that candidates run for a backlog, and not a specific implementation, and they are then beholden to present weekly demos to the constituency of what they have done to actually make that measure come true - which isn't part of the existing Scrum bill. So as we work on how to make the rest of Scrum; the demos, the retrospectives, the.. part of the mandatory legal process, we'll then be moving that to the entire legislature.
But in Czech, that has already happened. Then, at the federal government level, we've already seen, in the United States, the Department of Defense write the Agile Manifesto into the procurement law. It is illegal now to have a delivery to the Department of Defense that's not iterative. Peoples and interactions over processes and tools... All 4 values and 12 principles of the Agile Manifesto are part of the signed Department of Defense Procurement Law. Then, at the international level, one of the EU countries wrote their constitution using Scrum in one week's time. It was the fastest they had ever re-deployed their constitution. I don't remember which. It may have been Estonia, and I'm currently talking with the president of one of the European parties, and one of the EU delegates from Norway where all of the financial planning of the EU, and the business bailout structures.
So what's being seen currently in Agile methods, and particularly Scrum, globally in government, looks to be completely transformative. And Gosh, as a citizen, it looks like my closest bet to actually be voting on an issue and not an implementation. It's not, yes, I'd like a bridge here or a train here. It's, as a person living in this city, I'd like to get to this city in less than 45 minutes. The candidate then demos how they ...
Ray: So that all sounds great from the perspective of those people that understand Scrum and know Scrum, and Agile, and the rest of it.
So for the purposes of those general people that aren't particularly familiar with Scrum, which seems to be the case outside of the tech world. What are the advantages that brings to sort of creating new constitutions, financial planning, that sort of thing?
I mean, why bother with Scrum in that scenario? What are the advantages of doing that, and why has it gone into law?
Joe: What seems to becoming more visible is, Scrum is a method for collaboration, allows a group of people from one to N... It seems to be going up to tens of thousands of people, to participate very efficiently. It looks to be a scaling method for communication to have a single focused output with a balanced review of the measures required to make this pass legally in a really fast way. The collaborative aspects of Scrum and scaling Scrum through meta Scrum and Scrum of Scrums seems to allow, in less than a week, tens of thousands of individuals to be able to weigh in on the areas that are most important, and then have a passable solution at the end that everyone can sign up for and see.
Which, it looks like forms of organising people had difficulty getting that many folks getting their vision statement endorsed and ratified by a large group
Ray: So from a practical standpoint, Scrum, as I know it from the software development world, requires breaking work down into relatively small pieces of work. Is that practical, then, do you think? Well, clearly it's being done. But how does that happen with law, and with various other government policy areas that you're talking about?
Joe: Luckily, it seems easier that I've been learning as I'm diving into this myself seems easier for large groups of people to agree on the value statements. It's the implementations that seem to get people stuck. So if they say, a person living in this city, "I'd like to get to this city in less than 45 minutes," it seems that it's relatively easy for the groups using an affinity estimation to rank that, versus other concerns, as they are talking about budgeting in the government level.
So is this worth X, is this worth Y? The values seem to be easy to do, easier, and the facilitation methods many of us are using for Agile projects seem to fit well.
When it comes to the implementation, just like we see in software projects using Agile methods, you might have two architects with very different opinions, and they might argue for three hours and drag the whole rest of the team in. But by focusing on the value, it seems most people can agree on the value they want very quickly.
Then, with the implementation, using personas to say for which person are we solving next, and we'll solve for another persona, just in the next [inaudible 00:04:55], it allows people to say, "Oh, it doesn't have to be perfect the first time. We can actually have delivery in this week that will meet these personas in the room. These other personas, here's where they are in the product backlog, and they will be served in priority order."
That makes people say, "I don't have to block this bill because it doesn't serve me or my business." It's, it will serve me and my business in this order, and the visible backlog seems to allow people...
Ray: So it's not breaking the work down further, per se. It's just reducing the amount of argument that happens, because, actually, you can just try out different options.
So it's more about enabling innovation in that space, as opposed to changing the efficiency, say?
Joe: Well, Ray, I would agree with you that the breakdown of the value statements is also not common in the government level. Often it's a package of particular implementations. So splitting by value and ranking the values independently does seem to be valuable on its own. Then the collaborative tools to allow a mass of people to interact with that, that the Agile community has been doing over the years, like affinity estimation and like planning poker using the Delphi method, seem to fit here just as well as they do in multi..
Ray: Cool. Yeah. Quite.
I'm going to move us swiftly on, since we started slightly late, to the next question we've got, which will expand on this a bit further
So next question is Scrum everywhere - Why do technology based Scrum teams benefit when a whole company gets Scrum?
So I guess another interpretation of that might be, what are the limitations imposed upon tech teams implementing Scrum when the company doesn't get it?
So, Simon, do you want to kick-off on that one a little bit?
Simon: To me, a lot of it has got to do with just empathy, because it's an interesting thing. So the Scrum alliance, as an example, has the tagline, Transforming The World Of Work. I think a lot of people think that's empty rhetoric.
It's not really until a certain way into the Scrum adoption that teams really begin to get... Not a tweak. It's a fundamental paradigm shift, and a change.
People that are outside of that change bubble often have no empathy for what's going on in side of it, and can't relate to it. Because they can't relate to it, it's a clash of cultures, and they don't know how to interface with that. They don't know how to interpret the information coming out of it, and they have different relationships to some of the things Joe was talking about, like priority and value, and all that sort of stuff like that.
Ray: Yeah. So you end up with... If you don't have that feedback loop, I guess, for the wider organisation that, from a technology standpoint, were working for, then there's a disconnect. We end up delivering the wrong thing. I guess that's where you're heading with that?
Simon: It's more than just delivering the wrong thing.
It's seeing things as completely alien, and going back to trying to observe the old behaviours. So going in and... A classic example is traditional managers reaching into a JIRA and looking up for sprint backlog tasks and running after people and going, "That's estimated at three hours. You get it done by 11:00 o'clock, and that sort of stuff."
Ray: Right.
Simon: And completely focusing on the wrong things.
Ray: From a process and methodology standpoint?
Simon: Yes.
Ray: Yeah. I guess the outcome of that is, you don't end up with the cultural changes that you want as a result of the Scrum adoption. You don't end up with the behaviours that you want overall in the organisation, and I guess it's very easy to then derail the teams that are trying to use Scrum in a local context with if the wider organisation is still effectively micromanaging issues in Scrum.
Simon: Oh, absolutely. I call that organisational antibodies. It's fundamentally why a lot of Agile adoptions collapse after the coaches leave, because they are, effectively, the immunosuppressants in that scenario.
Ray: Right.
Simon: They are holding back the organisational thing, and then eventually you stop taking them, and then the larger organisation rejects the Scrum transfusion.
Ray: I might steal that analogy myself.
I've come across the same problem in a number of clients I've worked with where you end up with a lot of ground up Scrum adoptions without the manager support to back it up. There are some organisations where sometimes you've got the CEO on board, and then your senior management team, and then actually it's just the middle management layer that are problematic, and you end up with the same problem, in effect. Kind of making it impossible from both ends of the stack.
But, yes. It's certainly something common I've come across.
Is it something you've seen, Joe, in your interactions?
Joe: I'd absolutely agree with what you, Ray, and Simon have been saying. It seems to take a coach, and as Simon pointed out, when the coaches leave, sometimes the agility leaves, which is why I'd say the coach needs to be internal and employed.
Scrum Inc., when we engage with companies now, we ask for a coach for every five teams to be provided by the client full time, where their only job is to shadow the Scrum Inc. coaches and trainers when we're on site, so that they have full time coaches, at least one for every five teams.
Yahoo indexed the financial value of this. They recorded, of their trained Scrum teams, if they weren't given a Scrum coach, their acceleration was 35%. Now, that's a whole lot, and for teams that measured velocity, that was exciting enough. But for their teams that had a full time Scrum coach, and by that, again, it was a coach for five teams or less, teams that had a coach for 20 teams that had no measurable effect.
But coaches for one per every five teams, their acceleration was 300% to 500%, 400% on average. Quad velocity. Higher quality as well. The teams also reported they had more fun doing it and they had higher engagement at work. That's the type of win everybody would wish.
Write Scrum, the art of doing twice the work in half the time. But that took persistent internal coaches. So when we come in to coach and train a company now, we ask on the statement of work, please provide your internal coaches full time people who already know your business to pair with us, and our job is essentially to train the coaches, not to coach the organisation.
That seems to be the model that persists. But I'd like to share another model as well.
Bosch. Bosch is a 370,000 person company, and they are in the middle of an Agile transformation. In fact, they are quite far along across the entire company. hardware, software, management, finance, HR, procurement, every aspect. For them, it comes directly from the Chairman of the Board, Volkmar Denner. He called my call phone last November, and that's not usual for me.
I'll have division CEOs call me, but this was the CEO of the entire company. He called my cell phone and said, "Joe, I've just retired all personal performance bonuses as of January 2016, and I want to fly you out to Stuttgart to tell all my 500 division CEOs why I just did that."
So we talked more on the phone, and it turns out those bonuses were all replaced with team incentives that were tied to total company profitability in order to disincentive silos, to actually destroy them financially. It looked like it worked, so it was an easy sell for me to say to his top 500...
...Let's bonus ourselves based on total company performance, and with that, agility appears to be..
Ray: I mean, that's fundamentally about optimizing the company as a whole, rather than as individual divisions, then. So that's one example of the discentivisation in that area.
Joe: In that case, Scrum also attached Scrum coaches across every division. They have an internal coaching practice of full time Bosch employees, and when they have an organisation like Scrum Inc. come in, it's to train and coach their internal coaches and trainers.
So they are not outsourcing their agility. They bring in experts from the industry to help scale up their internal folks, but their Agile practice, their coaches and trainers, that's a core part of...
Ray: And that's across the board, or just..? I mean, Bosch is primarily a technology company, but that is across all the business areas?
Joe: That's the manufacturing, the machines that make the machines. That's business strategy, the board of directors, the board of advisors. I was talking to them about meta Scrum, and having the CEO's office prioritize the backlog for the entire company, and it looks like that's happening.
Ray: Is that on a kinda on a day to day, fine grain level. What might appear on that backlog, for example?
Joe: Oh. At the top level, it's missions and goals for the company. We'd like to grow ourselves, and the autonomous vehicle space might be an example, or we'd like to acquire other key providers to become more vertically integrated in power tools for the European market, would be an example. Those would be single backlogged items. As Bosch, we'd like to become the default provider of autonomous vehicle controls for the coming autonomous vehicle renaissance, for all OEMs.
That would be a user story potentially that could be...
Ray: So that's, presumably they are not actually using Scrum at that level. They are using some of the techniques. They are creating a backlog, they are prioritizing and defining individual, achievable tasks. But, presumably, they are not achieving that within a short period of time. And they're not.. that's not the entire company as a whole feeding into the subdivision beyond that, of those tasks.
Joe: It appears to be exactly Scrum, with a daily standup at the top level, a retrospect at the end of one week to say, "How are we going to make the company faster and happier?" A demo of the current state of those major epics, and those epics, just like a release burn down in an individual team ... are then updated in ... looks like the model with which to go. So it looks pure play Scrum. Three rolls, five meetings, three outputs. Exactly the Scrum guide's definition.
Ray: Okay.
So then, focusing back on the question, clearly they are getting that at the top level. How does that then effect the technology based Scrum teams on the ground?
Joe: It looks like the ability to escalate impediments up to top management allows each individual team to actually respond to retrospectives that involve a maturation of company structure.
So while teams themselves are able to work on impediments that have to do with, should we try pair development? Should we try a different definition of ready for our user stories, whether it's hardware or software. But when they have impediments, like, why am I getting support requests for project B when I'm told project A is the right priority, why am I being told to multitask and not swarm?
Those types of impediments can now be escalated, it looks like, to top management, and actually removed.
Or impediments like, how come we have siloing, and Power Tools North America is asking me to design and build tools this way, whereas power tools this way is asking me to design and build tools this other conflicting way.
How do I optimize power tools when I am getting business cases that are conflicting, because they have silos that are independent bonused from the previous world, right?
Ray: Mm-hmm.
Joe: Well, it looks like those impediments are able to be handed directly up to the board that actually makes structural decisions for the company, and acted on. ... retiring individual incentives that are based on a silo, and that being removed, appears to be an actual effective use of Scrum of Scrums at the team level, bubbling up that impediments to actually change the structure of the company to...
Ray: Okay.
What's interesting in that, though, is it sounds to me like, despite using Scrum and escalating impediments, and using all of the techniques there, it doesn't sound like they are actually decentralizing control much. It still requires those impediments to go all the way out to the boards to make a call on 'are they going to use Power Tools A or B?
Joe: No, they have a coaching practice, of course. It looks like for financial decisions, they do want a single ringable neck, an ultimate product owner. For them, it looks like that product owner is the chairman of the board, the CEO.
Now, that person is fed by a meta Scrum, the product owners, and then product owners of product owners, all the way down, for teams at every level. Many impediments are moved by their coaching office, it sure looks like, but it looks like some impediments having to do with the structure of the company, they actually have a single decision maker. That said, it looks like that single decision maker can make decisions within one week.
Gentlemen, absolutely my apologies. It looks like I have an early quoted time box where I am... It's only 6:29 p.m., but it looks like I actually have to pull the shoot. Luckily, for this for this Blab it looks like Simon and Ray get to continue discussing Scrum and its future of work all around the world, and I look forward to people sending emails to info@Scruminc.com with follow on questions, if that's helpful.
Share this
- Agile Development (153)
- Software Development (126)
- Agile (76)
- Scrum (66)
- Application Lifecycle Management (50)
- Capability Development (47)
- Business Analysis (46)
- DevOps (43)
- IT Professional (42)
- Equinox IT News (41)
- Agile Transformation (38)
- IT Consulting (38)
- Knowledge Sharing (36)
- Lean Software Development (35)
- Requirements (35)
- Strategic Planning (35)
- Solution Architecture (34)
- Digital Disruption (32)
- IT Project (31)
- International Leaders (31)
- Digital Transformation (26)
- Project Management (26)
- Cloud (25)
- Azure DevOps (23)
- Coaching (23)
- IT Governance (23)
- System Performance (23)
- Change Management (20)
- Innovation (20)
- MIT Sloan CISR (15)
- Client Briefing Events (13)
- Architecture (12)
- Working from Home (12)
- IT Services (10)
- Data Visualisation (9)
- Kanban (9)
- People (9)
- Business Architecture (8)
- Communities of Practice (8)
- Continuous Integration (7)
- Business Case (4)
- Enterprise Analysis (4)
- Angular UIs (3)
- Business Rules (3)
- GitHub (3)
- Java Development (3)
- Lean Startup (3)
- Satir Change Model (3)
- API (2)
- Automation (2)
- Scaling (2)
- Security (2)
- Toggles (2)
- .Net Core (1)
- AI (1)
- Diversity (1)
- Testing (1)
- ✨ (1)
- August 2024 (1)
- February 2024 (3)
- January 2024 (1)
- September 2023 (2)
- July 2023 (3)
- August 2022 (4)
- August 2021 (1)
- July 2021 (1)
- June 2021 (1)
- May 2021 (1)
- March 2021 (1)
- February 2021 (2)
- November 2020 (2)
- September 2020 (1)
- July 2020 (1)
- June 2020 (3)
- May 2020 (3)
- April 2020 (2)
- March 2020 (8)
- February 2020 (1)
- November 2019 (1)
- August 2019 (1)
- July 2019 (2)
- June 2019 (2)
- April 2019 (3)
- March 2019 (2)
- February 2019 (1)
- December 2018 (3)
- November 2018 (3)
- October 2018 (3)
- September 2018 (1)
- August 2018 (4)
- July 2018 (5)
- June 2018 (1)
- May 2018 (1)
- April 2018 (5)
- March 2018 (3)
- February 2018 (2)
- January 2018 (2)
- December 2017 (2)
- November 2017 (3)
- October 2017 (4)
- September 2017 (5)
- August 2017 (3)
- July 2017 (3)
- June 2017 (1)
- May 2017 (1)
- March 2017 (1)
- February 2017 (3)
- January 2017 (1)
- November 2016 (1)
- October 2016 (6)
- September 2016 (1)
- August 2016 (5)
- July 2016 (3)
- June 2016 (4)
- May 2016 (7)
- April 2016 (13)
- March 2016 (8)
- February 2016 (8)
- January 2016 (7)
- December 2015 (9)
- November 2015 (12)
- October 2015 (4)
- September 2015 (2)
- August 2015 (3)
- July 2015 (8)
- June 2015 (7)
- April 2015 (2)
- March 2015 (3)
- February 2015 (2)
- December 2014 (4)
- September 2014 (2)
- July 2014 (1)
- June 2014 (2)
- May 2014 (9)
- April 2014 (1)
- March 2014 (2)
- February 2014 (2)
- December 2013 (1)
- November 2013 (2)
- October 2013 (3)
- September 2013 (2)
- August 2013 (6)
- July 2013 (2)
- June 2013 (1)
- May 2013 (4)
- April 2013 (5)
- March 2013 (2)
- February 2013 (2)
- January 2013 (2)
- December 2012 (1)
- November 2012 (1)
- October 2012 (2)
- September 2012 (3)
- August 2012 (3)
- July 2012 (3)
- June 2012 (1)
- May 2012 (1)
- April 2012 (1)
- February 2012 (1)
- December 2011 (4)
- November 2011 (2)
- October 2011 (2)
- September 2011 (4)
- August 2011 (2)
- July 2011 (3)
- June 2011 (4)
- May 2011 (2)
- April 2011 (2)
- March 2011 (3)
- February 2011 (1)
- January 2011 (4)
- December 2010 (2)
- November 2010 (3)
- October 2010 (1)
- September 2010 (1)
- May 2010 (1)
- February 2010 (1)
- July 2009 (1)
- April 2009 (1)
- October 2008 (1)