Management Is a Function, Not a Role

Management Used To Be a Role. We’re now DONE with that.

In the days of Frederick Taylor, management fit neatly in a role. A single skilled person directed the work of largely unskilled labor throughout the Industrial Revolution. Workers eventually became groomed through the education system to show up as cookie-cutter conformists who did what they were told. And they “checked out” and became unengaged “zombies” at work.


Fast-Forward to NOW:

Now we have “work/life balance”, a sanitized term for “unhappy, unengaged, split person” or “split personality”. (Dave Logan says if you love your work and your job, “Work/life balance is a crock“, and of course he is RIGHT.)

We still are dealing with a very broken and anachronistic education system that encourages conformity at a time when we need anything but. Innovators like Salman Khan have created self-managed learning spaces online, and are finally starting to get some traction.

Management is a function, not a role.

The World of Work Has Changed

In the new world, people do knowledge work. Even when they do not, they want to be respected. This respect is expected to show up as voice, choice and what we are coming to understand as self-management.

Ken Schwaber and Jeff Sutherland, in their book SOFTWARE IN 30DAYS OR LESS, say this:

“People are most productive when they manage themselves” (pg 29.)

Management is a function, not a role.


Management Is a Function, not a Role Occupied By a Single Person

The days of the management function being held by a person are surely numbered. If we look carefully at current examples like Scrum and the structure of MorningStar Company, we can see what is going on: management is more important than ever, and it is not embodied in a single person in a single (authoritative) role. Instead, employees execute mutual Client Letters of Understanding, which are essentially working agreements. Instead of a job description, these interpersonal agreements define the work.

Management is a function, not a role.

Inside product and software development, teams are self-managed. We call this “self organization” or “self organizing” teams. What we really mean is this: teams (in Scrum) and individuals (in organizations like MorningStar) are self managed.

We have entered the age of self-management. The old game is OVER.

Managers are becoming obsolete, even as management becomes more important than ever. The old Taylorist conformity is giving way to the rise of the self-managed worker. This has profound implications for just about everyone who works for a living.

Management is a function, not a role.

Time to get busy learning about what self-management means for your job, your department, your employer. Time to get some new beliefs about the world of work. Don’t wait.


NOTE: These and other ideas of mine appear in my latest book, THE CULTURE GAME. You can learn more about THE CULTURE GAME book here.


This month’s meeting is about creating and generating Personas to help gather and make sense of complex software requirements. Personas provide a named profile for a user type. This profile is useful for describing a user in detail, and generating and understanding user stories and the overall requirements.









“As a [user], I want to…”

If you’ve written requirements as stories, you are probably very familiar with this phrase, but who exactly is the user we are talking about?

Very often we resort to generic role titles.

You’ve likely found that many conversations still revolve around, “I think we should” rather than about what your target users would need.

In the absence of having real users give feedback on a regular basis, we often resort to abstractions such as market segments, but it is very difficult to make detailed design decisions based on broad segments.


Personas solve this problem by creating a realistic profile that represents a segment.

In this presentation, I’ll outline what personas are, why they are useful, and how to create them.

By the end, you will have techniques you can use immediately to create assumptive personas and start focusing your team.





About The Presenter:

Jeremy Kriegel has been designing great user experiences (UX) for 15 years. Just as we need to understand the needs and context of users to craft a design solution, Jeremy believes that success also requires us to look at the business context to craft an appropriate design process.

From start-ups to Fortune 100 companies, as a consultant or on an internal team, he has seen a lot of different scenarios that each required their own approach. He brings this diversity of experience to bear in adapting UX to agile methodologies, finding the balance appropriate for each business.

Currently, Jeremy leads the UX team at Cambridge Interactive Development Corp, the company behind Everest Poker and the Everest Gaming suite.


The AGILE FOR REAL event is a community event of Agile Connecticut.

WHEN: Wednesday, June 13, 1PM (see schedule below)

WHERE: CNC Software (“MASTERCAM”) Headquarters, 671 Old Post Road, Tolland CT (directions, map)







This is an AFTERNOON 1/2 day Agile conference and community event, designed for you to easily attend during your working day. You work the AM, go to lunch in your usual way, and then BOOK OFF the rest of the day to enjoy some of the best Agile sessions found anywhere!

AGILE FOR REAL is about real practitioners doing real Agile in Connecticut and Massachusetts. In addition to hearing genuine and unvarnished experience reports, you will also receive a GUIDED TOUR of the offices and Agile working groups of CNC Software. CNC Software started with Agile in 2011 and never looked back. Using a mix of Agile coaching and gut feel, CNC Software has emerged as a leading practitioner of Agile in Connecticut. By attending this event, you will gain access to a guided tour of how CNC Software is using Agile to build mission-critical software used by the likes of United Technologies, Harley Davidson and hundreds of smaller manufacturing organizations.

This event features the tour of CNC Software, so you can see how Agile looks and feels IN FACT and not just in books, seminars and web pages. Come and see how a real company based in Connecticut is using Agile to increase quality, deliver working software frequently, and delight customers.

The AGILE FOR REAL event includes:

  • In-depth, hard-hitting experience reports where you can ask hard questions of the presenters
  • A tour of the CNC Software facility and a walking narrative of their Agile story
  • Interactions with the now-Agile sponsors, developers and testers at CNC Software
  • Socializing with your Agile Connecticut peers over beverages and light food.




This event of the Agile Connecticut User Group starts at 1PM and ends promptly at 5PM. If you are implementing Agile in your organization in Connecticut, you do not want to miss this event!!


Take an early lunch and plan to arrive promptly at 1230PM. During each 45-minute session, up to 30 attendees can sign up for the tour of the CNC Software Agile software development implementation. You will:

  • Engage in a guided stand-up tour of CNC Software’s Agile teams and work spaces,
  • Meet the sponsors, Product Owners, Scrum Masters and Team members and Testers
  • Interact with Q&A, take pictures, and get a sense of what it is to enable REAL AGILE at your company.


0100PM Session 1 and Agile Tour Group 1


0200PM Session 2 and Agile Tour Group 2


0300PM Session 3 and Agile Tour Group 3


0400PM Session 4 and Agile Tour Group 4


0500PM DONE !!





These are the sessions planned for the AGILE FOR REAL event:


Brian Summers and Joe Tindal of CNC SOFTWARE on:


Brian Summers is CEO and Joe Tindal is Senior Project Manager at MASTERCAM. They started implementing Agile in the company in 2011. Come and here their story about the god, the bad and the ugly of adopting Agile “all the way”.




Richard Kasperowski of NOKIA on:


Richard Kasperowski spent several months in Finland and functioned as an in-house change agent. As a manager, he functioned as an in-house Agile coach and led a transformation at Nokia that was far from simple. He used a variety of techniques over a period of several months. Attend this session to find out how he did it.




Robin Thierfield, Curtis Yanko & Jean LaPorte of CIGNA on:


Agile Adoption at Cigna

Cigna has been using Agile practices since 2009 and has experienced varying levels of success throughout the organization. Our discussion with focus three components: 1) Agile practices, implementation and challenges, 2) Software engineering practices to support Agile, and 3) Enterprise Agile at Cigna.



Dan Mezick of New Technology Solutions on


Dan Mezick started with Agile in 2006 and started with Agile coaching in 2008 in Connecticut. Since then he has coached and consulted to dozens of organizations across America. In 2011 he coached at CIDC, a game developer in Cambridge MA. It was during this engagement that he learned about the power of Open Space to transform organizations. Come to this session to hear his story, and learn how to use the power of Open Space in your own Agile adoption planning.






The Daily Standup

I get lots of questions about the Daily Scrum, from software development Teams and other kinds of Teams, like sales & marketing teams, executive Teams and the like. This post is intended to provide some basic guidance on the Daily Scrum, and also to explain some of the ideas behind the design of the Daily Scrum. The Daily Scrum is a practical meeting, and a kind of ritual ceremony, and a kind of daily reassertion of Team authority…and more.


NOTE: These opinions are my own, and do not appear AT ALL in the official rule book of Scrum, the Scrum Guide. (Only Ken Schwaber and Jeff Sutherland, the co-creators of Scrum,  have authority to edit the Scrum Guide. This document is the official rule book for Scrum. The picture above is a picture of Ken and Jeff at the GIVE THANKS FOR SCRUM event held in Boston each year. )

Refer to the Scrum Guide for authoritative guidance on Scrum.

The Daily Scrum

The Daily Scrum is a generator of daily feedback. It is used to sample what is happening in the 24 hrs just past. In Scrum, the meeting goes like this:

1. The meeting is 15 minutes long and occurs in the same place at the same time each day.

2. The meeting is the TEAM’s meeting. This means the Team RUNS the meeting. There is no boss, or project manager, or any other kind of authority higher than the Team during this meeting.

3. Each Team member answers three questions: a)What did I do yesterday, b) What am I doing today, c) What obstacles am I facing that need to be addressed

4. When everyone is done answering the questions, or the 15 minutes is up, the meeting is over.

5. There are 3 roles in this meeting: Team member, facilitator/Scrum Master, and Observer.

The meeting follows a protocol:

Team Members: Answer the 3 questions and do not stray from the 3 questions. Attendance: mandatory.

facilitator/Scrum Master: Observe, and speak only if the Team starts to stray from the protocol (3 questions, 15 minutes) of the meeting. Speak only to bring the Team back on track. Attendance: optional

Observer(s): Team can allow observers. Observers arrive on time and do not speak during the meeting. Attendance: optional.

That is all there is to the Daily Standup meeting, AKA the “Daily Scrum”. If you want to understand the nuances of this meeting read on, otherwise, you are done.


Deeper Analysis of the Daily Scrum

The following is my opinion of what the story is behind the Daily Scrum…

The Daily Scrum is intended to provoke dialogue and discussion AFTER the meeting.  Since software teams are usually populated by left-brained, problem-solving introverts, often these folks value “flow time” over “blending with others”. This meeting is therefore short and to the point.

Developers often refrain from asking for help since asking for help may mean they do not understand a problem, do not know what they are doing, etc. “Alpha geeks” rarely if ever ask for help for these very reasons. Developers after all get paid for “right” answers.

Providing wrong answers or “no answers” (aka “asking for help”) is considered “career suicide” by many software developers.

A common pattern for a developer is for the developer to keep pounding on the problem (ALONE) until they “beat it into submission”. This heroic pattern is more common than asking for help.

This pattern of behavior is usually far less productive than asking for help.

The Daily Scrum’s 3 questions are intended to reveal when someone needs help. The design is clever: “What obstacles are you facing today?”. This amounts to disclosure of problems and an indirect request for help. When a Team member answera that question, listen carefully to figure out if you can help me, assuming a) you want to help and b) you have the ways and means to help.

The Daily Scrum is designed to get Team members to reveal where they need help.

Think of the Daily Scrum as a place to discover where you can offer some help.

Authority and the Daily Scrum

When I facilitate Daily Scrum (“standup”) meetings, I rarely if ever look people in the eye. The reason for this is that Team members often take eye contact for a cue to “go next”. Team members may also recite to the facilitator or Scrum Master instead of reciting answers to the other members of the Team. This in effect is drafting the Scrum Master into a ‘boss” or “manager” or “authority” position.

The Scrum Master is never “the boss” and occupies none of these roles!

Team members must learn to recite to other Team members, and to do so when they feel ready, not when some illegitimate authority prompts them to do so! The authority in the Daily Scrum is the Team.

I prefer each person who wants to recite, to recite when they are ready, instead of being prompted by “authority”. This is after all THE TEAM’S MEETING, and does not belong to the facilitator/Scrum Master or anyone else. If the Team member reciting is looking at me, I encourage them  to “say it to the Team”. As facilitator, sometimes I say nothing, and instead literally move to a place where the Team member reciting cannot look at me in the eye.

In this way, Team members learn that they OWN this meeting and the meeting belongs to the Team.

The following behaviors are non-verbal signals of authority:

1. Pointing at someone

2. Standing when others are sitting

3. Positioning deep in the room, facing the door

4. Overdressing

The facilitator needs to avoid issuing these signals. Why? Because Team members will pick up these signals and start looking to the facilitator/Scrum Master as “the authority in the room.” As Facilitator, you need to avoid this trap.

Team members often “want to be told what to do”. They will attempt to draft the facilitator into an authoritative role. I try to stay aware of this and avoid taking up any authority beyond making sure the 15 minutes and 3 questions are honored.

When in the role of facilitator, I signal as follows:

0. I arrive early and endeavor to never be late

1. I avoid looking at anyone in the eye when the current Team member is close to completing their recitations. Looking at someone in that spot amounts to a prompt to go next, especially when punctuated by lifting the chin when looking at them.

2. I never point at anyone.

3. I position myself close to the door with my back to the door, to signal that I have low (or NO) authority in this meeting.

4. I am careful to keep the meeting on track: 3 questions, 15 minutes, no status reporting, problem-solving, or the like.

5. I open the door when the 15 minutes are up or everyone has recited the 3 questions.


In general, the Daily Scrum is a meeting designed to help people reveal where they are struggling. This is a huge step forward for most Teams, who often hide where they are struggling. Asking for help is a huge leap forward and the Daily Scrum provides a way to reveal where you are struggling without directly asking for help.

It is essential for facilitators and Scrum Masters to avoid even the appearance of being in control of the meeting. My #1 tip to Facilitators and Scrum Masters is to NOT look at anyone directly during transitions. (That is in effect “sequencing” the meeting.) Instead, look elsewhere, wait, and see who goes. If no one goes next, after a painful silence, ask:  “who wants to go next?” and see what they do.

The results may surprise you.


Dan Mezick has 5 years experience consulting to teams, executives and organizations who are actively implementing authentic Scrum. His coaching clients include Orpheus Orchestra, Zappos Insights and dozens of smaller organizations. Dan’s latest book is THE CULTURE GAME, providing “ABC” guidance for managers who want more agility for their teams and departments.

You can view Dan’s recent video interview with Zappos Insights leader Rob Richman here.

You can contact Dan here.


Mandated Collaboration: The Recipe for Botched Agile Adoptions

Here is a sure-fire way to virtually guarantee a failed adoption of agile or Scrum:

Simply have an authority figure, preferably the CEO, announce with great fanfare to the entire organization  that we are “going agile”.

To really make sure you definitely create a colossal train wreck of truly epic proportions, be sure to specify a hard date, the date when the entire organization is “going agile”.

The folks may start rolling their eyes, making sarcastic and sour faces, crossing their arms, shifting their feet…in other words, disengaging.

Why would mandating FORCED COLLABORATION be a bad idea? Why is it a bad idea to CHANGE EVERYTHING on people without asking them what they think? Why is mandated collaboration a very bad idea?

1. IT KILLS OPENNESS. It signals that whatever people actually think, feel, believe and want is NOT valued. (If we value what you want, think and feel, we’ll signal that by asking you what you want, what you think, etc.)

2. IT KILLS INITIATIVE. The very people who can help spread good agile in your organization are not getting a hearing. By this I mean the people who are capable of thinking for themselves, and have an independent streak in them. By announcing the “agile adoption” without checking in on what people might think, you send a signal that is OPPOSITE the Scrum value of Openness and OPPOSITE the Agile Manifesto value of [Individuals and Interactions]. Good job !

3. IT KILLS ENGAGEMENT. By announcing like that, you signal that AUTHORITY remains where it currently resides: with the command-and-control higher ups. Good luck getting people to self-organize themselves in that scenario. You just told them it is OK to check out and DISENGAGE, since authority is not about to be getting shared.

4. IT KILLS ANY SENSE OF CONTROL PEOPLE HAVE. By announcing like that, you make enemies of the people who might be allies. The people who CARE actually complain a lot, usually 1-to-1 … to colleagues and friends. Do you really think you are going to score points with people when you reduce their happiness? Do you really think you make people happier at work by making all of the decisions that affect them… at work? When you announce change like that, you botch the agile adoption by reducing the perceived sense of control people have. Good job !

5. IT KILLS ANY SENSE OF PROGRESS. By announcing like that, you kill any sense of progress. You make agile look, feel, and smell just like every other FAILED change initiative such as Six Sigma, CMMI, re-engineering, et al. Announcing authoritatively sends the clear signal that ABSOLUTELY NOTHING HAS CHANGED.


You cannot get people on the bus by barking the agenda and signaling that feedback is not valued.

That is the very antithesis of agile!

You get them on the bus by asking them what they think. Agile is getting a huge black eye as it “goes mainstream”. The same old patterns of command-control are being played out as new ‘agile’ terminology is being used as a cover story for disrespecting the people who do the work.

Add to this the fact there is always an ‘Agile coach’ to help well-meaning but misguided or misinformed “leadership” do whatever it wants with ‘agile’ (provided the price is high enough) and we have a train wreck of epic proportions being played out in enterprises around the world– especially in the USA.

Especially in Boston!

You might be asking: what is the solution? It is really very simple: Create a space where the folks get HEARD. The folks know the work. Why not ask them what they THINK about AGILE before rolling it out? Since this almost NEVER happens, 99% of ‘agile adoptions’ are train wrecks that associate with diminished feelings of control, diminished feeling of progress and diminished feelings of teamwork with “leadership” and authority. Did I mention diminished feelings of being respected?


The Culture Game book has an entire chapter devoted to the idea of opening the conversational space as a requirement for a successful agile adoption. The folks that do the work are going to get a hearing one way or the other. The only real question is how leadership chooses to manage the inevitable expression of what people want, what people think and what people feel.