Tag Archives: self-organizing

Family Kanban for Cleaning

Two nights ago I had a great discussion with my son, Justice Berteig, about how we have been managing to do house cleaning every week.  We have been using a very basic Kanban system.  I have created about 100 stickies each of which has a basic cleaning task such as “tidy the kitchen counters” or “vacuum the office floor” or “clean the powder room toilet”.  If we do all of the tasks, it represents a fairly complete cleaning of the whole house.  Every Saturday morning, all six of us (myself, my wife and our four kids) choose one task at a time and put the sticky for that task in the “In Progress” column.  When we finish a task, we move it to the “Done” column.  When all the tasks are done, we all are finished.  We reuse the stickies each week.  Sometimes if we want to do a quick clean, we won’t put out all of the stickies.Cleaning Kanban - Task

It works well in one specific way: everything gets done!

But Justice was complaining about the system because he works a lot harder and one of my younger kids has admitted to doing less than she could… because she can get away with it with this system.

Last week we tried a modified system where each person has a task allocation.  For example, Justice had an allocation of 25 tasks.  Our younger daughter had an allocation of just 5 tasks.  We then took turns to choose one task at a time (although there were a lot of exceptions to this) until all the tasks are pre-allocated (similar to how teams used to do Sprint Planning).  But, although some people finished all their tasks, not everyone did and so there were a number of things left over that never got finished.

In other words, we stopped using a Kanban system, and we stopped reaching the overall goal of a clean house.

So Justice and I had a long conversation about this problem.  In the interests of continuous improvement and experimentation, I didn’t just force the issue back to the old Kanban system.  Instead we decided to try the following changes:

  1. Limit the tasks to only those in common areas.  Private areas such as bedrooms would be taken off the master list.
  2. Each task would get an estimate from a scale of 1 to 3 to represent their relative difficulty.  We will talk as a family about the estimates and maybe use a simplified “bucket system“.
  3. Now, instead of an allocation of a specific number of tasks, the allocation would be for a total amount of effort.  We agreed that our youngest would get a smaller allocation still, but she could take any number of tasks to fill it up.
  4. We also agreed to be more disciplined about taking turns to choose tasks.

I’m going to add one more thing which is to do a specific retrospective on how it worked to see if we can come up with further improvements.  I have to admit that I hope we go back to the Kanban approach!!!

Check out our new Kanban training offering: Kanban: Gentle Change currently available for public enrolment in the Toronto area and for in-house delivery wherever you might be!


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: No member of my team reports to me

Inside the Scrum Team, including the Product Owner and the ScrumMaster, no individual should report to any other individual.  The team reporting structure should be flat.  This does not necessarily mean that all Team Members are peers in the org chart.  For example, one team member could be quite senior, and another quite junior.  However, for the Scrum principle of self-organization to work effectively, individual Team Members should have no concern about what their “boss” wants them to do.  Instead, within the Scrum Team, there should be a completely safe environment for individuals to volunteer for tasks, raise obstacles, provide candid feedback to any other Team Member, and have a mutual sense of commitment to the work of the team.  If the Scrum Team is absent of reporting relationships then it has a much higher chance of becoming a high-performance team.  If there are reporting relationships within the Scrum Team there are often significant obstacles to full openness and self-organization and this, in turn, will significantly hamper the performance of the team.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I never tell any other individual team member which task to work on next

All tasks done by individuals on a Scrum Team must be chosen voluntarily.  If one Team Member, in any way, tells another Team Member what task to work on, this breaks the principle of self-organization that is essential to creating a high-performance Scrum team.  Team leads, project managers, functional managers and other people in roles of authority to assign tasks must give up that authority completely when it comes to the people on a Scrum team.  This self-organizing behavior allows individual team members to consider their own talents, capacity, interest, motivation etc., when choosing a task.  All of those inner conditions are not as well known by other people and so assigning tasks tends to be sub-optimal.  When a Team Member considers those inner conditions about him or her self, and also takes into consideration the needs of the team, an optimal task choice can be made.  If someone in a position of authority does assign tasks, it creates a habit of deferring to authority which quickly destroys any possibility of a high-performance team developing.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Rules of Scrum: I attend every Sprint Retrospective Meeting in-person

The Sprint Retrospective meeting supports the Scrum value of Openness and the principle of inspect and adapt.  This rule of Scrum also aligns with the Agile Manifesto principles “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”  In-person attendance of all Scrum Team members allows for the fullest level of openness among Team Members which in turn is necessary to use the Retrospective to find improvements in how the team functions.  If even one team member attempts to attend this meeting by any other means, either by phone or even video conferencing, efficiency and effectiveness of the openness and inspect and adapt becomes compromised. Compromise on these principles yields compromised collective ownership of improvement efforts. Lack of in-person participation increases the likelihood that the team will fail to implement improvements because the openness and inspect and adapt will lack effectiveness.  This, in turn, hinders the team from reaching a high-performance state.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The BIG Difference Between Agile Teams and Project Teams

Last week I ran an Agile Coach Training session in-house for a large Canadian organization. It was just myself and five other participants. We were discussing possible things to do if there is a person on an agile team who is not able to work effectively in that sort of environment. One “intervention” we discussed was to “Assign Work”…

Pause

Now hopefully everyone who just read that phrase “Assign Work” had all sorts of alarm bells go off in their head!!!!

As an Agile coach, I would only do this under extreme circumstances. And I would always be fully aware of the consequence of assigning work. I would be removing that person from the team by Assigning Work. A person is not in an Agile (self-organizing) team if they need to be assigned work.

Guess what?!? THAT is the BIG difference between Agile Teams and Project (or Functional) Teams.

On a project, the Project Manager gets someone onto the team by assigning them work!!!!

On an Agile Team, a person is removed from the team by assigning them work.

Have you seen this happen? How did the assignee feel?


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Gathering – Orlando Florida – Mike Cohn – Leading Self-Organizing Teams

Something wrong with starting late at a Scrum Gathering!

Did this talk before at SD conference at Santa Clara

Think self-organizing teams are fundamental to all agile methods
– people claim: Unified Process is an agile process – but doesn’t rely on self-organizing teams
– Wicked problems: get the right people together, throw them at the problem

TOPICS:

Self Organization and subtle Control – not all forms of control are evil

Containers, Differences and Exchanges Model

Influencing how the team evolves

Premise: self-organization isn’t just locking a team in a room and saying “just do it” – we influence

What is a Self Organizing Team?
– does not mean:
– – the team gets to decide what goal they pursue
– – or even necessarily who is on the team
– – – some self-org teams are given this responsibility

Complex Adaptive Systems
– a dynamic network of many agents
– – acting in parallel
– – acting and reacting to what other agents are doing
– control is highly dispersed and decentralized
– overall system behavior is the result of a huge number of decisions made constantly by many agents
– e.g. QA group
– in a project:
– – sounds like a software project!

Some Examples
– ant colony
– flock of geese
– us right now – self-organized into room, some at front, some near power outlets
– a crowd batched up to get into a concert or sporting event
– – Jimmy Buffet concert – queueing, at the bar, at the beach etc.
– a family preparing, eating, and cleaning up after a meal
– cars and drivers on the heighway
– a software team

Control is not Evil
– was command and control leader before scrum!
– Simple rules or incentives are used to guide or direct behavior
– – “Drive this direction and on this side on the highway.”
– for bioteams, these are provided by nature
– for our teams rules and incentives can be added by managers or leaders… or in some cases by team members
– Generative rules – rules that generate behavior
– Some control is okay

Quote from Philip Anderson, The Biology of Business about Self-organization

Popular to criticize Taylorism – don’t specify exact steps, instead put in place things that guide behavior

(NOTE: slides on website)

Takeuchi & Nonaka “Although project teams are largely on their own, they are not uncontrolled… ”

What this is not
– we’re not talking about
– – being deceptive or sneaky
– – manipulating people
– – IS subtle rules and guidelines
– nothing I’m going to advocate needs to be secret
– – but there may be reasons why you don’t broadcast your reasons
– – e.g. if you have to fire someone

Containers Differences and Exchanges

Glenda Eoyang: Conditions for Self-Organizing in Human Systems
– Container
– – a boundary within which self-organization occurs e.g. project, team, role, nationality
– Differences
– – there must be differences among the agents acting in our system
– – e.g. technical knowledge, domain knowledge, education, experience, power, gender
– – e.g. individual sub-goals
– Transforming Exchanges
– – agents in the system interact and exchange resources
– – information, money, energy (vision)
– how can we use these to influence the way the team behaves?
– – amplify or dampen the differences
– – re-frame the problem
– – change the communication environment

Comment from audience about “Wisdom of Crowds”
– groupthink!

Using the CDE model
– Adjusting the Containers:
– – formal teams, informal teams, clarify (or not) expectations
– – e.g. the AI programmers thought they could not talk with each other, only the people on their teams
– – introduced a Community of Practices
– Differences:
– – dampen or amplify them within or between containers
– – e.g. if people are having a hard time making decisions because they are all too different, maybe adding people to increase similarity
– Exchanges:
– – insert new exchanges, new people, new techniques or tools
– – e.g. team that needed to get outside help re: architecture
– – cross-training

Containers
– enlarge or shrink team

Differences
– don’t require consensus
– – creativity comes from tension
– – quiet disagreement is not as good as fierce debate that leads to behavior change
– _do_ require consensus
– – e.g. if one person is dominating the discussion
– ask hard questions
– – then expect teams to find solutions

Transforming Exchanges:
– remove a document
– create a document!
– encourage communication between teams and groups
– – who isn’t talking
– add or remove people
– – change reporting relationships
– encourage learning

Exercise:

You are the ScrumMaster or PM:
– situations
– ID one thing to change
– use CDE model

Good Group Discussion around Scenarios

Mike Cohn is really good at creating discussion exercises.  I’ve always been impressed.  The discussion excercise asked us to apply the CDE model to the various scenarios.  In our group we only looked at two out of the five scenarios.  Each time the discussion was great – lots of good ideas from people about how to solve the problem in the scenario.  What wasn’t so good at first was using the CDE model.  It’s easy to just look at the scenario and come up with solutions.  What isn’t so easy is to use the model to generate solutions or to map solutions into the model.  At a personal level, I also found that folks in my group were emphasizing imposing solutions rather than using the Scrum model to have solutions emerge from the team’s own efforts.  For example, the retrospective is a Scrum practice that really should be the first line of defense.

Aother Philip Anderson quote:

“Self-organization proceeds from the premise that effective organization is evolved, not designed.  It aims to create an environment in which successful divisions of labour…”

Variation, selection and retention
– evolution is result of these three elements
– consider a giraffe:
– – variation: longer neck
– – selection: helps it reach food
– – retention: more food means more progeny

Seven levers for influencing team evolution:
1.  Select the external environment
– more than the physical environment
– business, industry
– approach to innovation
– approach to mistakes
– types of projects
– expectations about multi-tasking and focus
2. Define performance
– selection – traits that help us survive
– short vs. long-term performance
– providing training
– support sustainable pace
– explore wild ideas
– not exchanging deadlines for unmaintainable code
– e.g “Up or Out” culture – burn out or be promoted!
3. Manage meaning
– stories from leaders
– keeping messages out
– “we will become profitable this quarter”
– rituals
– Story about Mike’s background (1994)
– – valley of death
– – product did not have a long life
– – no new features
– – decided to create new product
– – “valley” in decline of revenue from old product, vs. increase in revenue for new product
– – as part of this, replaced two-ply with one-ply toilet paper to remind everyone of the need to save costs!
– Another story
– – “our GM counts the cars in the lot every day at 5pm” – not a good culture for Scrum!

4) Choose People
– who is on the team
– adjust:
– – team size, decision making style, location, gender, background, motivation

5) Self-selecting members?
– should a delivery team be allowed full control over who is on the team?
– under all circumstances or only some?  which?
– what are the advantages and disadvantages?
– – people often will choose to work with similar people
– doing this is giving up some control
– “you can self-organize unless I disagree” is not a good message!
6) Evolve vicarious selection systems
– variation-selection-retention
– – selection was determining which variations will be retained – can take a long time
– so we often use vicarious selection systems
– – this is an animal that can smell that a food is poisonous, rather than eating it
– using only the marketplace as our selection mechanism takes too long
– Organizations can have vicarious selection systems:
– – retrospectives, Google’s 20% policy which attracts people to projects, compensation
7) Energize the system
– unless energy is pumped into the system, entropy will set in
– make sure the group has a “clear, elevating goal” or an “igniting purpose”
– motivation
– opportunity
– information
– Teamwork by Larson and LaFasco or Hot Spots by Lynda Gratton
– example: Bill Gates and “Internet Tidal Wave” memo

New book by Mike Cohn:

“Succeeding With Agile”


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

The Seven Core Practices of Agile Work

Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.

Self-Organizing Team

Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term “team” really applies quite broadly to any size group of people that are working together towards a common goal.

Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.

If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization’s leadership is responsible for determining the “why?”, some constraints on “how?”, and then letting the team respond to the need as best as it can.

Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).

Deliver Frequently

Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.

The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.

There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one’s retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.

Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).

Plan to Learn

Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.

First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.

One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.

Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).

Communicate Powerfully

A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.

The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.

The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.

Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.

Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).

Test Everything

Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.

In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.

A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.

Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).

Measure Value

Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.

A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.

There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual… etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.

Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).

Clear the Path

Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn’t just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.

In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.

Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.

Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).


Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.


Affiliated Promotions:

Try our automated online Scrum coach: Scrum Insight - free scores and basic advice, upgrade to get in-depth insight for your team. It takes between 8 and 11 minutes for each team member to fill in the survey, and your results are available immediately. Try it in your next retrospective.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail
Berteig
Upcoming Courses
View Full Course Schedule
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
Apr 24
2019
Details
Kanban System Design® (KMP I)
Ottawa
C$1695.00
Apr 24
2019
Details
Facilitation Skills for the Agile Workplace®
Toronto
C$1350.00
May 6
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1695.00
May 7
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$1095.00
May 8
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1395.00
May 14
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1695.00
May 15
2019
Details
BERTEIG Real Agility Series: Kanban Maturity Model and Business Agility
Online
C$0.00
May 23
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jun 4
2019
Details
Certified Agile Leadership® (CAL 1)
Toronto
C$2200.00
Jun 10
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jun 11
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Jun 11
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jun 19
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jun 20
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 4
2019
Details
Kanban System Design® (KMP I)
Toronto
C$1440.75
Jul 4
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Jul 11
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 16
2019
Details
Team Kanban Practitioner® (TKP)
Toronto
C$930.75
Jul 31
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Jul 31
2019
Details
Kanban Management Professional® (KMP II)
Toronto
C$1355.75
Aug 1
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Aug 13
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Aug 21
2019
Details
Certified ScrumMaster® (CSM)
Toronto
C$1185.75
Sep 11
2019
Details
Coach Skills for the Agile Workplace®
Toronto
C$2018.00
Sep 16
2019
Details
Leading SAFe® with SA Certification (+FREE Scaling Workshop)
Toronto
C$1185.75
Sep 17
2019
Details
Certified Scrum Product Owner® (CSPO)
Toronto
C$1440.75
Sep 17
2019
Details