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.

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]

Self-Organization Isn’t The Point

By | Blog, Uncategorized | 2 Comments

Fast Company’s article this week about has brought the debate over Self-Organization back into focus. But I’m thinking that the debate is sort of missing the whole point about what we’re trying to do with our workforce.

self-organization group holding hands in a circle

Specifically, CEO Tony Hsieh’ s decision to remove all manager roles has elicited a very skeptical counter point from Alison Griswold at Business Insider. She says essentially that self-organizing teams don’t scale, and everyone organization who’s tried to make it the norm eventually gave up in frustration. I do have my own thoughts on WHAT Self-Organization is, and HOW to make it work. But I think everyone is focusing on methods, rather than on mission.

Before I launch into my tirade, let me say that “I’ve been there.” My career started to take off when I was promoted to Team Leader and then to Project Manager. Right about the same time, I became enamored with modern management techniques like Lean Thinking and Agile Product Development.  I was thrilled to be getting ahead, finally. But after a few colossal disasters, I realized that there is much more subtlety to the world of work. In the last several years I’ve lived in the tension between the traditional way and the modern way of leading teams to get work done. Here is where my thinking has taken me:


Self-Organization is a strategy, not a goal.

Book Cover: First, Break All The Rules

My favorite management book…ever

At the end of the day, a business needs to generate results. Sure, we like innovation, productivity, excellence, quality, and stuff like that. But for any of those things to happen, we need engagement. My all time favorite management book is First, Break All the Rules by Marcus Buckingham. (If you’ve never read the book, stop what you’re doing now and go buy a copy and come back to this post. It’s that important of a book.)

It was a ground-breaking piece that gives the recipe for real employee engagement. Interestingly, many of these questions go beyond the supervisor. Rather, many of them are basic “care and feeding” questions, like:

  • Do I have the materials and equipment that I need in order to do my work right?
  • Does the mission or purpose of my company make me feel that my job is important?
  • Do I have a best friend at work?

The book cites example after example of great managers who work very hard to address these employee satisfaction factors. In fact, Gallup has since discovered that, if you address this engagement thing right, people would work for you even after they win the lottery!


Self-Organization is only one way to get engagement

Okay, so all this management stuff is about driving results, and results come from the engagement of our people, then what management system should we employ to drive engagement? One curious example was Henry Ford. He was a notorious business autocrat, who invented many elements of micromanaging. However, he famously paid as much as double the going rate for his factory workers, just to keep them from leaving. His approach was the antithesis of self-organization, and all it did was make his company successful.

In Zappos’ case, the culture is driven by the belief that loyal customers come from loyal workers. In Ford’s case, the culture was driven by an economic equation overpaying and micromanaging workers. Both management systems are polar opposites with respect to culture, but both drive results.

Self-Organization can be used for both good or evil

With that being said, let’s say you want to give it a go. You charter a couple teams. You give them some training. You send them off to achieve new productive, innovative heights. But then, you eventually discover that…

  • without any facilitation skills in place, the team succumbs the most opinionated voice.
  • without standards in place, one team’s output simply won’t integrate with another team’s output.
  • without a clear vision, the team’s output will steer wide of organizational goals.

But when done well, you CAN get amazing results.

In their book, Software in 30 Days, management gurus Jeff Sutherland and Ken Schwaber tell the story how they used self-organizing teams to save the FBI’s half-billion dollar Sentinal program. Like hundreds of other business coaches out there, I’ve been teaching and implementing their method as a full-time job now for over 5 years. I can say that I have seen similar successes, even life-changing successes.

So the devil is in the details. I agree that simply removing managers from the equation does not guarantee a new culture, but maybe it might help. My contention is don’t mistake the method as the mission.

Now it’s your turn

Is Tony Hsieh right about removing managers to improve culture? Is it just a pipe dream? Share a thought or comment here.

Bad Requirements? Actually, that’s your fault

By | Blog, Uncategorized | No Comments

I’m growing weary of project managers whining about bad requirements. The truth is, no one can possibly be surprised. From research studies to high-profile disasters, we hear over and over that incorrect requirements and poor scope management are key reasons projects fail. If we know this is a recurring problem in project work, why do we mindlessly continue engaging in the rote repetition of what doesn’t work?

crumpled requirements document

I’d like to share some suggestions to keep us from stumbling over the same mistakes:

Surrender the pipe dream of complete requirements.

There’s always going to be one dependency missed, one person we didn’t interview, one nuance hidden, one more thing we wished we had known. Don’t fall into the trap that more is better or you’ll never get started.

Always assume the initial requirements are wrong.

Sometimes the scope is inappropriately slanted toward one executive or maybe hasn’t been properly vetted. Sometimes the bulk of the requirements are actually “nice-to-haves.” Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure that you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with your sponsor to refine it.

Accept that all requirements change.

Traditional project management culture portrays change as a necessary evil, like traffic laws: If drivers did everything right, we wouldn’t need them. To mitigate the “risk” of change, we install intimidating change-control boards and financial penalties. But what if the work you’ve been implementing for the last two years is no longer relevant to the market? Does it make sense to have your customer continue paying for what is now essentially a useless output? Not in my estimation.

If we accept that our requirements are incomplete and incorrect, then we need to edit them to reflect reality. Indeed, PMI’s Guide to the Project Management Body of Knowledge (PMBOK® Guide), warns:

“Due to the potential for change, the development of the project management plan is an iterative activity and is progressively elaborated throughout the project’s life cycle.”

Today’s project manager is expected to have the organizational savvy and facilitation skills to get to the root of these problems. To ensure you yield the right priorities at the right time, take the initial scope statement as a starting point, then work with the customer to refine it.

Simplify your change-management approach.

Agile project managers explicitly embrace the value of responding to change, and institute project policies accordingly. Start by implementing a contract that supports authorized change rather than penalizes it. At the start of each project phase, mandate a high-level yet thorough revision of priorities. If your sponsor has difficulty determining priorities, coach him or her through the tradeoffs. Once changes are accepted, update your metrics to match the latest details. And while you’re at it, be proactive in communicating the latest details to everyone involved in the project.

Now it’s your turn:

What patterns have you seen around bad requirements? What have you done to minimize the pain or ensure the right things get done? Leave a comment below and share your own experiences.

[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]