All Posts By


Two Scaling Problems. One Solution

By | Uncategorized | No Comments

In latest of my Morning Fewell videos above, I share the latest news from the recent Scrum Gathering in Orlando. At the event there were several conversations about the underlying challenge of scaling organizational agility. It turns out there are two very different problems that people are trying to solve. The bad news is we try to solve each using the same tools and processes (something that I think has been discussed before).


Problem One: Going from Agile to Big

Here we usually dealing with a small startup that has a lot of charisma AND choas. Everyone pitches in to do whatever it takes to get work done. But now we need to grow, to scale the organization AND preserve our magic. We’re going from Awesome to Big.

So of course, we should start with a full implementation of Scrum-of-Scrums, a cadre of ScrumMasters, and project managmenet tools?!? Um…maybe not.  Maybe we need to explore what’s unique about this startup’s culture and talk about how we scale those special charataristics. Here, the problem is how to ADD structure and PRESERVE culture. 

Problem Two: Going from Big to Agile

Here we are starting an existing large organization that is struggling with delivery, with culture, with relevance. We’re trying to take THAT organization to become a higher-performing, more rewarding, more attractive version of itself. We’re going from Big to Awesome. 

So of course, we should start with weeks of top-down culture training and throw out all our management positions and   full implementation of Scrum-of-Scrums, a cadre of ScrumMasters, and project managmenet tools?!? Um…maybe not.  Maybe we need to define what success looks like, find the small inspiring teams in the organization already achieving those successes, and replicate how they did that. Here, the problem is how to ADD structure and PRESERVE culture.

The Solution: Leadership

The bad news is we try to apply the same textbook salves to these two very different types of wounds. The good news is there is a one-size fits-all leadership: Leadership. Here at the Scrum Gathering, the conversation is moving towards the idea that success is rare, because quality leadership is rare.

The conference opened with the announcement of the new Certified Agile Leadership program by the Scrum Alliance. Here the intent is to build leadership skills into your organization, either as you hire new managers into a startup, or retool them from within a large corporation. The were some other reinforcing elements around this message, such as the opening keynote and sidebar chats.

So the message is clear: The secret to achieving organization agility at any scale, according to thought leaders,  is building a leadership competency.

What do you think? Is this relevant? Is it even doable? 


Systems Approach to Scaling Agility

By | Uncategorized | No Comments


In this episode of Morning Fewell, Jesse sits down with Scaled Agile Framework (SAFe) expert Martin Olson. Martin shares

“Systems Coaching” in a Nutshell

Martin explains 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.

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. Therefore, we have some things to consider…

1. Change the Organization Where It Is

First, identify how big the change is. If the gap’s too far, the organization 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.

2. It’s More Than Training

During our chat, Martin gets animated saying, “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 understanding.  I do 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 still try to implement this, then 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.

3. Visible Leadership is NOT Optional

Martin’s top tip is simple: Leadership. Organizationally, we’re structured the way that we are through mergers and acquisitions and happenstance and tradition. We have these silos because they’re easy ways to organize and manage, but they’re terrible ways for work to flow.

Instead, you have to have a leadership that understands what they want, at an executive level. If your leaders can’t generate buy-in with any change initiative, it’s going to get to some level and die out. If I ask people to change, but they don’t understand WHAT I’m asking for, or the value, the reason WHY, then it’s going to be a challenge.

4. Customize Fit For Purpose

Martin’s next scaling secret is having an understanding of where you are and where you want to go.

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.

One of the critiques of SAFe is that people see this placemat and say, “Everyone needs to go to that solution,” but what Martin is saying, “No. Design the end state that fits your specific context.”

That principle is visualized best in this new 4.0 model where you collapse an entire an entire organizational layer-If you don’t need it, you don’t need it. You have to know where you’re going. You have to then support that.

Shameless Endorsement

In case it’s not obvious from the video, or the insights listed above, the class was a blast…thanks entirely in part to Martin’s energy and his holistic organizational perspective.

Yes, Virginia. Collaboration Can Solve Government

By | Blog | No Comments
Citizens seated at tables in city hall discussing

San Jose Citizens Collaborate on City Budget Tradeoffs. Courtesy

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=””]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

Since then, the Foundation has set its sights using games to solve wicked problems like the California Drought or Social Security. However, to do that, they need many more people involved. Therefore (drum roll)
I’m pleased to announce that I will be sponsoring the Every Voice Engaged Foundation’s presence at Agile2015.
The Foundation is using these sponsorship funds to show the power of collaboration in a very specific way. Staring earlier this month, they are hosting a series of massive online games to tackle the common problem of underfunded public schools. If you are curious about the options on the table, or would like to see how your opinion would influence the crowd, then you can sign up here to be a part of that effort. The results will be presented as part of Luke’s keynote at the conference, which I will of course be sharing later on.
Given the positive results we’ve seen so far, we know that getting people together at the same table can solve major differences of opinion. Now, all we have to do is scale that dynamic, and we could see very real progress on the things that divide us.

4 Painful Lessons From an Agile Entrepreneur

By | Blog | 2 Comments

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.

Read More
Who's Winning the Agile Certification Wars - August 2014

Who’s Winning the Agile Certification Wars

By | Blog | 5 Comments

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:

Who's Winning the Agile Certification Wars - August 2014

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. is the Fastest Growing Expert Community

In the span of 4 years, 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 RACI for Roles and Responsibilities

New Scrum RACI for Roles & Responsibilities

By | Blog, Uncategorized | One Comment


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.

5 Other Agile Manifestos You May Have Missed

By | Blog, Uncategorized | 3 Comments
agile manifesto word cloud

image courtesy Rob Hale

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:

  1. Validated learning over opinions and conventions
  2. Customer focused collaboration over silos and hierarchy
  3. Adaptive and iterative campaigns over Big-Bang campaigns
  4. The process of customer discovery over static prediction
  5. Flexible vs. rigid planning
  6. Responding to change over following a plan
  7. 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:


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:


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

Over on Google+, Alan Dayley shared with me Chris Conrey’s 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



Offshore Agile Isn’t the Problem. It’s the Solution.

By | Blog, Uncategorized | No Comments
offshore team working virtually

graphic courtesy

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:

Forced Collaboration

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]