Manifesto for Greatness

On May 1, 2015, a group of 16 people gathered at Crystal Lake near Seattle, Washington. We announced to the world that we feel. That we suffer and that we are responsible. That we want a world filled with abundant love and greatness. That we have been "booted" running a new operating system, the code for abundant love and greatness.  That we want to infect the world with love and greatness at epidemic speed and force. That we are in. That we want your help.

We announced to the world what we want and who we are. We want abundant love and greatness in the world. We are the Greatness Guild.

This is our manifesto, a Manifesto for Greatness. We ask for help. Will you join us?

Manifesto for Greatness

We feel GLAD, SAD, MAD and AFRAID.

We have suffered mediocrity, broken promises, drama, selfishness and separation for too long. We are responsible for this mediocrity.


We have the tools – the CORE COMMITMENTS and CORE PROTOCOLS – that encode and deliver these virtues and ignite people to greatness.

We want the world to live in love and greatness.


Will you join us?

Algimantas Stancelis, Alice Ivashina, Andrea Chiou, Axel Reed Dyksterhuis, Christian Délez, Christophe Thibaut, Dana Dyksterhuis, David Papini, Fazeel Gareeboo, Harold Shinsato, Josh Grob, Julia Ivashina, Richard Kasperowski, Sergej Koščejev, Stephen Hardy, Tolga Yazar

Read more about our efforts at greatnessguild.org.


Scaling Scrum: How To

Here’s a great Scrum scaling pattern based on the pattern that one of my clients uses. They use this pattern to scale their 500 people into a very successfully business unit of a huge technology company.

For each Product Backlog, there is one Product Owner (PO), one Scrum Master (SM), and up to four Development Teams. Each Development Team, plus the PO and SM, are a proper Scrum Team. The four Scrum Teams collaborate together on the single Product Backlog, ensuring that they are working on a single cohesive value stream.

Step 1: Form teams

The goal is to form teams that can get Increments of new product Done. To get things Done, each team must have all of the skills necessary—each team must be cross-functional.

The group’s manager creates a roster template on the wall. The roster template includes a column for each team and empty slots for team members. Rows indicate the desired mix of skills on each team: programmers, testers, UX specialists, DBAs, Op’s, etc.

Everyone in the group writes their name on a Post-It.

The manager explains the goal to the team. Group members fill the empty roster slots with their names. Talking and collaborating are encouraged! When all roster spots are filled, teams formation is complete.

Though not officially part of the scaling pattern, for great teams in just a few days, send them to a Core Protocols one-day workshop or five-day BootCamp.

Step 2: Scrum!

Here are recipes for your scaled Scrum events:

Sprint: All teams’ Sprints are synchronized, starting and ending at the same time.

Sprint Planning

Part 1—What: The whole group gathers in their shared work area. The PO re-acquaints the group with the contents of the Product Backlog. Each Development Team selects the subset of Product Backlog Items (PBIs) that they think they can get Done during the sprint.
Part 2—How: Each Development Team creates their individual Sprint Backlog. They carefully note dependencies and other collaboration needs with their cousin Dev Teams.
Part 3—Align: The whole group gathers again. Each Dev Team shares their Sprint Backlog with the group. Dev Teams share collaboration needs. They inspect and adapt, adjusting as needed. They agree on their Sprint Goal.
(Did you notice the Diverge-Converge pattern? You'll see it again in the Daily Scrum and Sprint Retrospective.)

Daily Scrum: Each team holds its own Daily Scrum. Daily Scrums are staggered so the SM and PO can attend all of them.
Daily Scrum of Scrums: Representatives of each Dev Team meet to share their progress toward their individual and joint Sprint Goal. They inspect and adapt and adjust their plans.

Sprint Review

The group meets all together, along with stakeholders invited by the PO, for their Sprint Review.

Sprint Retrospective

Part 1—Teams: Each team holds their own Sprint Retrospective. They create a concrete plan to improve their team during the next sprint. They also identify ideas for improving the whole group. This meeting lasts about one hour.
Part 2—Group: The whole group meets to inspect and adapt as a team-of-teams. They create a concrete plan to improve the whole group during the next sprint.

Product Backlog Refinement

Refinement with volunteer leaders: The PO and volunteer leaders from the group meet to refine the Product Backlog regularly, usually 1-2 times per sprint. The purpose of this meeting is to get the backlog more Ready for the whole group, so we don’t waste people’s time with PBIs that aren’t Ready enough for the group to estimate together. For great collaboration, the size of this volunteer group is around 8 people. (“More than eight, no collaborate.” -Luke Hohmann) This subgroup may provide *initial* estimates for backlog items, to help the PO with initial forecasting. These estimates are not final, though, because estimating is the Development Team’s responsibility. Consider not sharing these estimates with the members of the Dev Team to prevent anchoring. Consider using this Product Backlog Refinement Workshop xxx .
Refinement with whole group: The whole group convenes to refine the Product Backlog. The purpose of this meeting is to get the Product Backlog ready, with 1-2 sprints worth of PBIs totally Ready, and up to 6 months of backlog estimated—with the whole Development Team estimating backlog items together.

Scaling to 500 people

Each group is around 40 people. The pattern scales horizontally, up to 10 Product Backlogs and 40 Scrum Teams. For every five POs, there is a PO Manager. When there are two PO Managers, there is a PO Director above them.

Scrum Masters form a community of practice, perhaps with a manager handling there career development and HR needs. Programmers, testers, and other specialists do the same.

All together there are around 500 people in the business unit, including managers and support staff.


How to: A Great Product Backlog Refinement Workshop

Are your Sprint Planning meetings painful? Are your Sprint outcomes always as great as you want?

Have you ever held a Sprint Retrospective and decided to get your Product Backlog truly Ready?

Here’s an outline of a Product Backlog Refinement Workshop I use with teams I manage and coach:

The goals of the workshop are:
  • Get the Product Backlog Ready for the next Sprint Planning meeting
  • Get 6 months of Product Backlog Items estimated so the Product Owner (PO) can forecast well
Who: whole Scrum team
The whole Scrum team is invited. The Product Owner is present—he is responsible for the Product Backlog, and he wants the backlog to be great. The Scrum Master is present—he is a good facilitator and can help the team succeed. The Development Team members are present—they are responsible for estimating the size of the Product Backlog Items (PBIs), and they want to be familiar with the PBIs before Sprint Planning.

When & where
  • Same time and place, every week: so everyone knows and everyone can participate
  • 2-hour time box
  • Preferred place is the team’s everyday workspace.
  • Input: The input to the workshop is the Product Backlog in its current state.
  • Output: The output is a Product Backlog that is more Ready
To conduct the workshop, follow these steps:
  • In 30-minute cycles,
    •   The PO presents the next PBIs that aren’t Ready to the team. (up to 5 minutes)
    •   The Development Team decomposes into sub-teams of 3-4 people.
    •   Each sub-team selects one of the next PBIs and gets it Ready. (15-20 minutes)
      • Use User Stories, 3 Cs, INVEST, your Definition of Ready, etc. to guide you.
      • If Readiness is blocked by an impediment outside the Scrum team, the sub-team makes a concrete plan for what they will do to get the PBI Ready before the next Sprint Planning or Backlog Refinement meeting.
    •  Merge back into whole group, the full Scrum team.
    •  Sub-teams present their work to the whole group. (5-10 minutes)
    •  Take a break (5 minutes)
    •  Repeat
  • Celebrate!

This workshop is inspired by “Try… Requirements workshops for Product Backlog refinement" in Practices for Scaling Lean & Agile Development, Craig Larman and Bas Vodde, 2010. Thank you, Craig and Bas! 


Great Games for Scrum and Agile Learning

I love using games and interactive activities when I share Scrum and Agile with people. Here's a list of some of the games I use.

Name games
These games are from Stanley Pollack's excellent book, Moving Beyond Icebreakers.
  • Name shout, name wave, name race, name and motion, name and secret skill, name and adjective
  • Bag Toss 
Class start-up
These ways of collaborating are some of the Core Protocols.
Scrum and Agile fundamentals
  • Line Up
  • 60 Paces
  • Triangles
  • Human Knot
  • Human Sculpture
  • Alphabet and numbers: How fast can you go at simple tasks? What if you multitask? Round one: in 10 seconds, write the letters, e.g. A B C D. Round two: in 20 seconds, write letters and numbers, e.g. A1 B2 C3 D4. Round three: in 30 seconds, write letters, numbers, and the letters of your name, e.g. A1R B2I C3C D4H. Round four: in 40 seconds, write letters, numbers, the letters of your name, and the letters of the alphabet backward, e.g. A1RZ B2IX C3CY. Michael de la Maza taught me this game. Here’s a timer you can use.
Batch size

What are you favorite Agile and Scrum learning games?


How to Facilitate a Great Daily Scrum (Scrum Master skills series)

Welcome back to the Scrum Master Skills Series! In part 1, I shared my notes on how to facilitate a great Sprint Planning session. Here, in part 2, I share my notes on ho to facilitate a great Daily Scrum. Enjoy!


  • Facilitate: to make facile, to make easy. That’s your job as facilitator.
  • Create an experience. Design the experience. Want the team to feel positive? Design a positive experience.
  • Begin with, “The purpose of this meeting is …”
  • Make it a Visual Meeting. Use a kanban board, Post-Its or Stattys or EcoStatics, paper, and pens. 
  • Make it a human meeting. Use your bodies and your voices, and make eye contact.
  • Use a Time Timer.
  • Read the Scrum Guide. As Scrum Master, you’re expected to know Scrum. The Scrum Guide is your guide.

Daily Scrum

  • Set a recurring appointment series--the same time and place every day. Make it easy for people to attend.
  • Get it done in 15 minutes--or less! The time box is 15 minutes. That's 1 minute per person, followed by 5-10 minutes for the team to adapt. 
  • Read the Scrum Guide. Do what it says. Use the three questions in it.
  • Make it a physical meeting. Use a kanban board. Ask Development Team members to touch the Post-It Note for each activity they discuss, and to physically move their Post-It Note to its new column on the kanban board.
  • The first question, "What did I do yesterday that helped the Development Team meet the Sprint Goal?", helps with Student Syndrome: there’s peer pressure to get stuff done every day, not just every sprint.
  • The third question, "Do I see an impediment that prevents me or the team from meeting the Sprint Goal", is a form of Ask For Help. Encourage team members to ask each other for help--ask them, “Do you need help from anyone on that?” You might even think of the first two questions as warm-ups for this one, the most important question.
  • Try: Really facilitate! Keep the team focused. 
  • Try: If some team members are remote, attending by voice, call on people by name 
  • Try: Scrum Masters observe each other and play Perfection Game  
  • Practice every day!
  • Try: Use a burndown chart that you drew in Excel or by hand. Tape it to the wall. 
  • Avoid: Electronic tools during the Daily Scrum. VersionOne and Rally slow you down. You can only go as fast as the tool, which isn’t fast enough for people-speed.
  • Try: Don't call on people. They aren't reporting to you. They are reporting to each other. Honor the principle that they are self organized.  
  • Try: Don’t say anything. There’s limited conversation bandwidth. The more of it you use, the less information shared amongst team members.
  • Try: A talking stick. Or at least, “Hang on, one conversation at a time.”
  • Avoid: Free form discussions. 
  • Avoid: “We can take it offline.” Oftentimes, that’s a euphemism for, this conversation has no value, and we’ll drop it now, and we won’t remember to get back to it later.
  • Try: Use a Parking Lot to log important conversation topics to discuss after the Daily Scrum, with whomever is interested in those topics. 
  • Try: Track impediments on a kanban board 
  • Try: Let the team do it--only prompt them if they need it. It’s the team’s meeting, not yours. Let them report to each other
  • Try: Show up late, see whether they started the meeting without you. Remind them that it’s their meeting and they should start without you--we start on time, every time.
  • Try: Invite your Product Owner. It’s a great way to make sure your PO isn’t surprised at the end of the Sprint.
  • Avoid: Dismissing people early because they said their piece. Don’t optimize for the individual’s time. Optimize for the team’s overall success.
  • Avoid: “We’ll skip you.” My NVC reaction: Anger! Your skipped me! Try: Let me take a turn; being respectful of the team’s time, I’ll probably say, “Pass”.


  • Practice a Daily Scrum: answer the 3 questions
  • Update the task board on the wall
  • Update the burndown chart on the wall


How to Facilitate a Great Sprint Planning Session (Scrum Master skills series)

Welcome to the Scrum Masters Skills Series! In part 1, I share my notes on how to facilitate a great Sprint Planning session. Enjoy!


  • Facilitate: to make facile, to make easy. That’s your job as facilitator.
  • Create an experience. Design the experience. Want the team to feel positive? Design a positive experience.
  • Make it a visual meeting. Try a kanban board with 4 items To Do: what, how, sprint goal, enthusiastically agree. Use a Time Timer.
  • Read the Scrum Guide. As Scrum Master, you’re expected to know Scrum. The Scrum Guide is your guide.
  • Set a recurring appointment series--the same time and place every sprint-start. Not a day earlier, not a day later.
  • Take the full 4 hours (for a 2 week sprint).
  • Get it done in one day.
  • Don’t like 4 hours? Do a shorter sprint! It really does take 4 hours to plan 2 weeks of work. Don’t skimp!
  • Do it as the very first event of your sprint.
  • Sprint Planning goal: produce a credible plan for how to implement the next most important PBIs in the Product Backlog

Part 1: What

  • All Scrum Team members are present, including the Product Owner. Ask the PO for help to clarify the intent of Product Backlog Items.
  • Given: A Ready Product Backlog. If you don't have a Product Backlog in a Ready state, you're in trouble!
  • Pull the highest-order items off the Product Backlog.
  • Try: Do it on a wall, with Post-Its. Your Scrum kanban board can have these columns: Product Backlog, Sprint To Do, Sprint Doing, and Sprint Done.
  • Try: Use your last-10-sprints average velocity (and best-3-max and best-3-min) in story points to guide you as you forecast What might fit into your Sprint.

Part 2: How

  • Development Team and Scrum Master are present. PO is available to answer subsequent questions about PBIs.
  • Self organization: Dev Team plans HOW to get the PBIs done.
  • Try: Decompose each PBI, one at a time, into tasks.
  • Try: Each task can get done in 1 day. Helps team gauge progress every day during the Daily Scrum.
  • Try: Use the PBI’s acceptance criteria to guide your task breakdown.
  • Try: Use your Definition of Done, let it guide your task breakdown.
  • Try: How will you demonstrate that you got the PBI done? Make sure you have tasks for the elements of the demo.
  • Try: Focus on the value you’ll deliver to your stakeholders. E.g., if you don’t need documentation, don’t do documentation!
  • Try: Think about risks and dependencies
  • Try: Think of it as a mini-project plan, for a 2-week-long project. What are the elements of a “credible plan” for your mini-project? Did you include them all?
  • Try: Estimate tasks in person-hours. Try: use last sprint’s capacity as forecast for this sprint. Try Use person-by-person availability to forecast this sprint’s capacity in person-hours.
  • Try: Don’t estimate tasks in person-hours; try every task is 1 day long

Sprint Goal

  • Simply state your sprint goal. Write it down. Post it on the wall with your kanban board and burndown chart.

Enthusiastic Agreement

  • Try: Look each other in the eye. Put your hands in. Really agree with each other that you can do it.
  • Try: Decider Protocol, Passionometer
  • Draw a burndown chart, put it on the wall.


  • Set up a simple kanban board for sprint planning. Play a quick sprint planning game.
  • Draw a burndown chart for your sprint plan.


The Manager’s Role in Agile

An Agile manager
What is the manager’s role in an Agile team? In the typical Agile training class, we learn about Scrum’s three roles: Product Owner, Development Team member, and Scrum Master. Where do managers fit in? Should managers be afraid that their job title isn’t part of Scrum?

What is a manager, anyway? In industrial management theory, a manager is a person who efficiently transforms inputs into outputs. Inputs are limited resources, like people, time, machines, money, and other capital. Outputs are things like cars, washing machines, paper cups, and software products. A successful manager transforms inputs into outputs efficiently, minimizing cost and maximizing profit. Throw in a bit of Theory of Constraints, and we’ll say a successful manager does all of that both now and in the future.

To be able to do that, managers have a Fancy Formal Job Title: Manager, or Director, or Vice President. They have formal authority and power. They hire and fire people, they review their direct reports, they set salaries and bonuses. They have budgets to spend. They are accountable for their team’s results.

They feel pressure to get results, because there’s a manager above them, who can them a bad review, cut their bonus, or even fire them and hire a replacement.

Throw people, complex adaptive systems, and innovation in the mix, and it’s a wonder they survive day to day.

And then one of their bosses decides Agile is the right way to do things. So the boss hires a trainer or coach and tells the team to play Scrum. And the word manager isn’t part of Scrum, and the manager feels anxious. There’s a Product Owner who sort of acts like the business manager. There’s a Scrum Master who facilitates the Scrum team’s activities. What is the manager supposed to do? Will Scrum damage his career?

Agile is your secret weapon. If you want to win, organize your team as a Scrum team. You are the boss of the Scrum team.

If you want your team to go slow, teach them that they can’t succeed without you. Be the bottleneck to their success. Don’t let them make decisions without your approval.

If you want them to go fast, invent awesome things, and be successful, teach them to self organize. Use Scrum. Be the Product Owner, or give the PO authority to make decisions on your behalf. Let the team do their thing without asking you for permission. Hire the best, fire the worst. Insulate them from big company BS. Be their champion. Present them as the model of the best team in your BigCo. They can be, and they probably are.

Your job is still to optimize the efficient performance of your team, to transform inputs into valuable outputs. Scrum is a great tool for that, so let your team use Scrum, by the book.

Your other tools for being a great manager in an Agile team include:
  • Remover of impediments: With your formal job title, formal authority, power, and influence, you help your team succeed by removing obstacles. You are the person who can obtain the tools they need, get dependent teams to deliver the things your team needs, and block people from disrupting your team.
  • Technical team lead: You probably rose from developer to manager. You know what it takes to be a great Development Team member. When the dev team asks you for help, offer it, drawing from your great experience.
  • Mentor: You pull younger or less experienced team members along, teach them things, show them the ropes. You ensure that they grow to their full potential, even when that means they end up leaving your team.
What is your experience as a manager of an Agile team?


Related Posts with Thumbnails