Jesse sits down with Martin Olson for this episode of Morning Fewell. Grab a cup of coffee and spend a few minutes with Morning Fewell, it’s sure to charge you right up for the day!
Jesse: Hi, everybody. Jesse Fewell here with a special edition of Morning Fewell, here with Martin Olson at the Scaled Agile Framework SPC Class. I’ve got to tell you, I’m having a blast. For the last few days we’ve been talking about how to take these Agile ideas and deploy them in a large organization. We’re actually here in the classroom, so you guys are getting the first glimpse of things. You brought a refreshingly unexpected additional perspective on this, that we have the SAFe model, and it’s on its fourth iteration here in early 2016, which is excellent. It shows inspecting and adapting, but you’re bringing an additional perspective on this with systems coaching. What is systems coaching?
Martin: The notion of systems coaching is that when you have a group of people that are working together, they’re dependent on each other for whatever that delivery is. A baseball team is a system. Your Scrum team is a system. An organization is a system. That system has its own intelligence, its own energy, its own needs, so that when you’re bringing SAFe into an organization, you’re altering the system. You’re bringing practices. You’re bringing new learning. You’re bringing new information into the system, and as such, you need to be aware that you’re changing the system.
It’s not just the application of a bunch of practices and principles. It’s the application of a bunch of practices and principles in an existing system that will impact the system and you have to understand what that impact is, and you also have to make sure that that impact sustains the system because if it doesn’t, the system’s smart, it’s going to reject it.
Jesse: How do we guide the system to accept these strange new practices, these strange new philosophies and mindsets?
Martin: That’s it. How strange are they? If the gap’s too far, they can’t do it. You have to meet the system where it’s at, and you have to say, “Hey, at the end of the day, this is really good stuff. We’ve got teams and we’ve got this program guidance and everything.” We can do teams, and we can do program guidance, and that’s not going to be the full implementation of SAFe. That might be to the point of we can’t maybe do budgeting yet.
Jesse: That group who’s not ready for the full Monty…
Jesse: If they’re not ready for the full Monty…
Martin: You’ve got a journey. It’s not, “Hey, go do the training and now walk away and do this.” That is a model that can work if it fits culturally. There’s a couple of things here I want to be very clear about. One, doing the class is awesome. I enjoy it, and again, I would say that over the last four days, you’ve gotten a pretty good, pretty good understanding, and maybe a new learning on the model. It’s not a flawed model, it works, but again, I think large-scale Scrum will work. That will work. I’m not adverse to those models. I think the model’s good.
Secondly, you can’t just go do this training … if you don’t understand facilitation, if you don’t understand the challenges of change management, and you try to implement this, you’re going to have a long day because in its essence, you’re changing the system, and inherently in that, you’re changing the way people behave. You’re changing something that’s very near and dear to people, their work, their environment. We’re wired that way. Our satisfaction, our identity is often tied to work.
Jesse: Okay. With that being said, what would you say would be the top one or two hacks or the top one or two recommendations as a coach that you would recommend to someone who wants to implement a Scaled Agile Framework SAFe? One or two or three hacks.
Martin: They’re not even hacks. They’re called out, leadership. You’ve got to get leadership that understands what they’re asking. Over managed and under lead is the mantra, and it is. Organizationally, we’re structured the way that we are through mergers and acquisitions and happenstance and tradition. We have to have these silos because they’re easy ways to organize and manage, but they’re terrible ways for work to flow.
You have to have a leadership that understands that, an executive leadership. If you don’t have buy-in with any change initiative, it’s going to get to some level and die out because the people that I have asked to change, if they don’t understand what I’m asking to do, number one, and number two, the value, the reason why, it’s going to be a challenge.
Jesse: Number one is leadership. Number two would be…
Martin: Number two is having an understanding of where you are and where you want to go.
Jesse: Right. Your as is, your to be.
Jesse: All of that.
Martin: Exactly. Where you want to go is probably going to involve some level of SAFe, if you’re using that model, or whatever the framework is. You have to understand how you’re organized today, where the system’s at, you have to meet the system where it is at, and then you can stretch that, and you want this change to be sustainable. Everybody wants to set themselves up for success, so you have to know where the system’s at, you have to meet the system where it’s at, and then you move towards where you want it to be eventually.
Jesse: This has been one of the critiques that SAFe has suffered, which is that you see this placemat and you say, “Everyone needs to go to that solution,” but what you’re saying is, “No. Design the end state that fits your specific context.”
Martin: Again, yeah, and the framework calls out. It’s got 9 principles based on Agile and Lean. Folks that want to poke at it say … I think it’s a misunderstanding, and again, I would ask you. You came into the class with that belief that it might be too prescriptive. Do you still hold that?
Jesse: No. No. It’s been really eye opening, especially hearing your voice as a systems coach talking about it, that number one, meet the system where it’s at because they might not be ready to make the big jump all the way over to a certain kind of Scaled Agile model.
Martin: They may be. Maybe they want to.
Jesse: Maybe they are. Right.
Martin: If that’s the case, wow! That’s big.
Jesse: Number two, tailor the end state to the context you’re in.
Jesse: It’s visualized best in this new 4.0 model where you collapse an entire an entire layer-
Martin: Yeah. If you don’t need it. If you don’t need it. You have to know where you’re going. You have to then support that. Hack number three, don’t assume your people, so the world, don’t assume you send people to a class and they’re immediately a systems coach or process coach, and they can do that on top of their job. You have to decide if they’re working in the system or they’re working on the system when you’re doing change management, and you can have people that do both, right?
Martin: It’s a full-time gig working on the system, and-
Jesse: It is. It really is.
Martin: At scale and at enterprise, and when you’re changing the lives and the process that involves hundreds of people, each individual has to change. Each individual needs some level of support. There’s a lot of coaching that’s needed there.
Jesse: That’s a lot of work.
Jesse: That’s the other lesson I’m getting, is that this is a lot of work.
Martin: Any change is a lot of work. It’s not the framework. Again, there’s the notion that, “Hey, we can just go implement it,” and you might. Absolutely. There are case studies out there where organizations did that. I would propose that the reasons why that worked is it fit the organizational culture. The model met the organization where it was at and it was timing and it was ready to go.
Jesse: Others might be more evolutionary, might be step by step. Martin, thank you so much-
Martin: Hey, my pleasure.
Jesse: It’s been a blast and I’m glad that we got a chance to share it to some people. Thank you, guys, for listening in. Tune in next time, and hopefully we’ll talk to a couple more people from class.
Martin: I’ll see.
Jesse: All right.
Americans often complain about their broken government’s inability to get anything done. Partisan politics separates us into us-versus-them camps, and people dig in their heels. Yet when we finally get action, as with the recent Supreme Court decisions and resumed talks with Cuba and Iran, it serves only to divide us further. It’s an ironic cycle:
Our divisions prevent political progress. Yet political progress furthers our divisions.
A Glimmer of Hope
Yet one hopeful idealist hopes to change all that with a technique borrowed from the business world. Luke Hohmann is the founder of consulting company Conteneo, and also the inventor of Innovation Games. If you know me, then you’ve probably heard me talk about Innovation Games. But as a quick summary, these “games” are structured facilitation agendas designed to gather insights as to what is truly important to people. Unlike those bland and dry customer surveys, these activities are intended to engage users, consumers, and customers directly. From quietly observing how people use actually products (The Apprentice Game) to brainstorming a categorized set of desired features and benefits (Prune the Product Tree), product managers get deeper information than ever before. Both Luke and his company have had impressive success, installing this approach at Fortune 500 innovators from HP to Adobe.
However, in 2011 Luke had a unique idea: what if the most important product we build, is our government? He formed a non-profit to explore that idea, the Every Voice Engaged Foundation.[tweetthis url=”http://wp.me/pv0z1-rb”]What if the most important product we build, is our government? Here’s the story of business #collaboration applied to politics [/tweetthis]
Here’s what happened.
San Jose and Missoula are on board
In August of 2011, his Foundation teamed up with the city of San Jose to host the first ever “Budget Games”. The event featured citizens seated in table groups, discussing some hard choices around the tight city budget. To help that conversation, they were handed equal amounts of monopoly money, and each proposed line item was given a sticker price….oh, and the amount allocated was about half the amount needed, which now forced some serious conversation about tradeoffs. This is very close cousin of the same “Buy A Feature” activity Luke has popularized for the prioritization of product features that product managers debate vigorously.
Here’s the fascinating part: it worked. When the event was over, everyone had agreed to some specific cuts (run the city’s fire trucks with one less fireman) and increases (half the groups were willing to accept a sales tax boost of 0.25 percentage points). They were highlighted in Bloomberg and Financial Times and when they repeated the event in 2012, and have continued the tradition since.
Lest you think this is only for west coast hippies, let’s talk about cowboy country in Missoula, Montana. In 2014, a City Councilwoman asked Luke to host the same buy-a-feature game at a town hall meeting, as a way to gain ideas for tackling the municipal budget crunch. One idea that popped up: offering urban deer bow-hunting permits, a practice already allowed in other districts. These city-dwelling Montanans were definitely curious, but not quite sold..yet.
Now for Going Big
I’m pleased to announce that I will be sponsoring the Every Voice Engaged Foundation’s presence at Agile2015.
Many of you know that a little over a year ago I launched out as in independent Agile entrepreneur, trainer, and coach. Well, there’s good news and there’s bad news. The bad news is that I suffered some pain and mistakes in this first year. The good news is that I was able navigate through those issues, but only when I took a moment to pause, and then practice what I preach about Agile methods. Here are some of those lessons I learned the hard way.
Here’s an infographic that shows the agile certification landscape as it stands today (August, 2014). There are three key observations emerge from the data:
An Agile Practitioner’s First Certification Will Be From the Scrum Alliance
Within the field of entry-level programs, it’s no surprise that the Certified ScrumMaster program from the Scrum Alliance is the most popular. However, what is surprising is that the Scrum Alliance’s Product Owner program clocks in at #2.
PMI Attracts the Most Practitioners
Although the Scrum Alliance has attracted the most agile beginners, the PMI-ACP is the most popular next step for practitioners. To some degree, that makes sense. The Scrum Alliance is focused on promoting one agile technique: Scrum, but the PMI-ACP formally promotes over 100 agile techniques, including Scrum. The Scaled Agile Academy certifications promote a set of agile techniques that sit on top of Scrum, and therefore has grown to be very popular over the last 2 years. Exact numbers are not available on their website, but so far Scaled Agile Academy seems to be little threat to PMI, who themselves plan to have their 6,000th PMI-ACP this month.
Scrum.org is the Fastest Growing Expert Community
In the span of 4 years, Scrum.org has ammassed 123 trainers, whereas the Scrum Alliance has had a full 10 years to acquire their 200+ experts. The Scrum Alliance is aware of its need to attract more experts, and has recently revised its expert certification programs to fix what was a restrictively difficult application process. Meanwhile, newcomers ICAgile and Scaled Agile Academy are formalizing their expert programs, and will merit more attention in the coming year.
Scrum is by far and away the most popular of all the agile methods in use today. A key feature of Scrum is the distribution of responsibilities across three roles: a business representative (Product Owner), a group of skilled professionals building a product (Development Team), and a facilitator who removes obstacles (ScrumMaster). These roles have become ubiquitous in Agile projects across the world.
Several people have tried to answer this question with a good old fashioned RACI chart (responsible, accountable, consulted, informed). Whether a this downloadable PDF, or detailed treatise, or even an article published by the Scrum Alliance itself. Unfortunately, each of these “Scrum RACI” examples to try to do too much, offering up way too much detail that leaves many of my clients wondering about how it works on their project instead. I think the RACI format itself is to fault. What if we answered a more basic question instead? More to the point,
“What does the textbook say about who-owns-what, regardless of what kind of project I work on?
Instead, I’m going to use a different approach, by emphasizing who owns a given responsibility versus who helps that owner. I find “Owns-Helps” is much easier to articulate than the conventional RACI format. First, I’ll share the infographic you can download, followed by a description.
The Product Backlog, and its related Refinement, are absolutely owned by the Product Owner. She decides which workshops, meetings, plannings, or updates need to happen to create and update the backlog. However, a good Product Owner will ask for help from the Development on dependencies, estimates, tradeoffs, and event test criteria. She will also ask the ScrumMaster to help resolve any issues. A ScrumMaster can help facilitate alignment across stakeholders. The Product Owner can even ask for help organizing the backlog in a way that is understandable by various parties.
The Sprint Planning and its resulting Sprint Backlog are jointly owned by the Product Owner and the Development Team. The Product Owner decides what is most important to work on right now, in the upcoming Sprint. Meanwhile, the Development Team decides how much of the Product Owner’s priorities are feasible in the Sprint’s timeframe. If they’re good their job, they’ll ask the ScrumMaster to facilitate some good dialog about this difference of perspective. Granted, the Development Team can spend some time in the meeting to craft a tactical plan for how the backlog items will get built. That may help them gain confidence as to what’s feasible for the Sprint. But whatever goal, whatever agreement, whatever forecast comes out of Sprint Planning is jointly owned by the Product Owner and the Development Team.
The Daily Scrum and the Product Increment are absolutely owned by the Development Team. Nobody touches the Product Increment during the Sprint, except the Development Team. Also, they use the Daily Scrum meeting as a tool to help them coordinate the steps and actions needed to build the Product Increment. If they are wise, they will ask the Product Owner for help to clarify business details, or even to shield them from other stakeholders. Furthermore, they can ask the ScrumMaster for help facilitating the Daily Scrum and removing impediments. The newer the team, at the more help they will need. A common rule is that “anyone can come to the Daily Scrum, but only the Scrum Team is allowed to talk at the meeting”. This is to emphasize that the ceremony is owned by the Development Team, for their own internal benefit.
The Sprint Review is owned by the Product Owner. This is where the Product Owner gets to see what she invested the last few weeks of budget to get. She decides whether the product is in good enough shape to invite stakeholders. She decides how best to capture feedback during the meeting, and have it incorporated into the backlog. If she’s smart, she’ll ask the Development Team for help to demo the product and , since they just worked on it. She can also ask the ScrumMaster for help in establishing an effective meeting.
The Sprint Retrospective is jointly owned by all three roles. The Product Owner’s neck is on the line for how well the Sprint went; she will have strong opinions about improving. The Development Team is expected to take ownership over their work; they will have ideas about how to make that happen. The ScrumMaster is held accountable for whether the whole team is effective and reliable; he will have strong opinions about moving in that direction.
This “Owns-Helps” chart shows us that Scrum itself is a very simple framework. Granted, the devils is in the details. But Scrum leaves you to answer the question of HOW those details are attacked in your specific context. There is an the ebb and flow of responsibilities across the three roles of a Scrum Team. This yin and yang fluctuates during the course of the Sprint. It fosters more collective ownership, and allows for each of the roles to have greater focus on their specific areas.
Many of you have heard the Agile movement was formalized by the creation and promotion of the Agile Manifesto, back in 2001. However, the inevitable result of any successful movement is “embrace and extend”. A number of variants of the manifesto have popped up over the years to make a particular point. In spirit of this upcoming lucky 13th anniversary of the manifesto, here are five of the most popular, plus a dry humorous BONUS manifesto at the end.
1. Agile Marketing Manifesto
This is one of what might soon become a set of industry-specific agile manifestos. The promotions and advertising space is gathering a lot of momentum with applying agile mindset:
- Validated learning over opinions and conventions
- Customer focused collaboration over silos and hierarchy
- Adaptive and iterative campaigns over Big-Bang campaigns
- The process of customer discovery over static prediction
- Flexible vs. rigid planning
- Responding to change over following a plan
- Many small experiments over a few large bets
Granted, some of the tenets are copied word-for-word. But each of these has a dedicated page to deeper thoughts on applying it to the world of marketing.
2. ScrumMaster Manifesto
A group of people at the 2011 Scrum Gathering London chartered this document to clarify the responsibilities and duties of the most unconventional role on Agile projects, the ScrumMaster. It starts off with a declaration:
“WE BELIEVE THE SCRUMMASTER IS A FULL-TIME POSITION FOR ONE PERSON ON ONE SCRUM TEAM”
It also features:
- 12 ScrumMaster Pocket Principles.
- A ScrumMaster defined in 15 words or less…
- Top 10 things a ScrumMaster usually forgets to focus on (but is not SOLELY responsible for) …
This is a great very handy discussion tool for coaches and trainers.
3. Offshore Agile Manifesto
Udayan Banerjee gives us this variant for distributed outsourced projects. In particular, he’s going for a balanced perspective. Namely
- YES, we value Individuals and Interactions, “but setup right processes and tools for ubiquitous long distance interaction”
- YES, we value Working Software, “but create enough documentation to help posterity”
- YES, we value Customer Collaboration, “but have a win-win contract in place”
- YES, we value Responding to Change, “but ensure that implications are clearly understood by all.”
His post goes into these points a little more deeply, so it’s worth the 3 minute read.
4. More Agile Manifesto
This one caught my attention a couple years ago with its wry poke at old school versus new school perspective:
- Teamwork & responsibility over Individuals and Interaction – You need great individuals and the better they interact the better it is.
- Business Value over Working software – Software in itself has no value. It’s what you do with it.
- Partnership elaboration over Customer collaboration – Collaborating with your customer is important, but working on a partnership is better.
- Prepare for change over Respond to Change – It’s even stronger to create a setting where change is normal.
“That is while there is value to being agile, we value being more agile more.”
The author, Geert Bossuyt, has since taken the page down, but AgileScout did a great journalistic job of preserving the moment for us here:
Link via AgileScout: http://agilescout.com/agile-manifesto-2-1-moreagile-manifesto/
5. Agile Business Manifesto
Okay, I know it’s actually called the Declaration of Interdependence. But the DOI is arguably the among the most influential post-manifesto document. Where the original manifesto emphasized the concepts associated with successful software, the “DOI” articulates agile concepts from a business perspective:
- We increase return on investment by making continuous flow of value our focus.
- We deliver reliable results by engaging customers in frequent interactions and shared ownership.
- We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
- We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
- We boost performance through group accountability for results and shared responsibility for team effectiveness.
- We improve effectiveness and reliability through situationally specific strategies, processes and practices.
It’s a critical tool in any agile practitioner’s vocabulary.
BONUS: The Half Arsed Agile Manifesto
If you’ve ever been annoyed or frustrated by people compromising on the values and principles related to success, Kerry Buckley offers this sarcastic take on the real world:
- Individuals and interactions…and we have mandatory processes and tools to control how those individuals (we prefer the term ‘resources’) interact
- Working software…as long as that software is comprehensively documented
- Customer collaboration…within the boundaries of strict contracts, of course, and subject to rigorous change control
- Responding to change…provided a detailed plan is in place to respond to the change, and it is followed precisely
I’ve left a little out, so you can enjoy more at the source.
SUPER DOUBLE BONUS: The Post-Modern Sales Manifesto
- Relationships and interactions over transactions
- Establishing value over lowering price and rate
- Customer collaboration over haggling and negotiation
- Long term partnerships over rigidly defined roles
I’ve left a little out, so you can enjoy more at the source.
Now it’s Your Turn…Which is your favorite? Did I miss any? Leave a comment here
The honeymoon is over. Looking to deliver more while spending less, just about every large company has engaged in distributed offshore projects over the last several years. But organizations are discovering that outsourcing carries more pain than was promised. More projects are suffering from quality issues, language gaps and woefully unmet expectations. So what can we do? Here are some ways that Offshore Agile projects are overcoming some of these side effects:
Agile project management places a strong emphasis on collaborative communication. Using written English can sometimes mitigate language issues, but email takes too long, and large documents can be stale the moment they’re sent. Instead, we augment project communications with standard processes like a daily call, team chartering, and working agreements. To make that more feasible, teams are using modern online collaboration tools such as Google Docs, instant messaging, discussion boards, and Skype. Some teams have always-on webcams so each side can see what’s happening on the other. You can’t have successful projects without some kind of interaction. If time zones make that inconvenient, share the pain, with each worksite taking a turn after-hours. In short, agile methods expect you to work hard to communicate in real time. You’ll develop stronger collaboration, which will yield greater understanding and more innovative results.
Get bad news early
A mentor once told me, “Never surprise your boss.” Similarly, a good project manager wants bad news as early as possible. One of the greatest pain points for distributed projects is unmet expectations. Sponsors can spend significant time and money generating rigorous requirements, wait a year to see any output and then receive a single large deliverable that simply misses the mark. If iterative-incremental delivery is a good risk-management practice for local projects, then it’s absolutely vital for distributed projects. A monthly demo using a virtual meeting platform can reveal problems and opportunities earlier in the game. If it reveals a slew of defects, the sponsor can reprioritize debugging over adding new features. If an incremental deliverable is built to off-target specs, the sponsor still has the opportunity to swap some of the pending features for the needed refinements.
Formalize Problem Fixing
Conventional offshore projects rely heavily on up front planning, to minimize the pain associated with distance, silos, and time-zones. However, no amount of planning can account for surprises and mistakes. This is why Agile methods formalize policies around fixing problems and changing course. Demos give a chance refine the scope for optimum value. Retrospectives give voice to issues that need escalating. Transparent metrics reveal issues that need to be analyzed further. In short, agile processes require you to pay attention to the issues that crop up on virtual projects.
Now It’s Your Turn
As it turns out, I’ve written a whole minibük on this topic, which you can download for FREE here. It goes into more detail on both insights and tips. Check it out and then post a comment or send me a line: What has worked for you in making the most of offshore, distributed, virtual project situations.
[NOTE: This post was originally published as part of my recurring column, “The Agile Project Manager”, printed in PM Network magazine. Other installments and more info can be found here]