The comic strip at XKCD today is brilliant. It takes a bit of effort to follow it, but the punchline is brilliant. Communication is tough. How does this apply to agile teams? You be the judge! (PS. XKCD is a great comic for geeks, but sometimes nsfw.)
Mike Caspar has another great post, this time about being truthful about the challenges of working in a high performance team environment.
We have an upcoming three-day agile training seminar in Waterloo on November 9-11, 2011.
In this unique seminar, we will be offering a practical view of three important Agile methods: OpenAgile – used for general agile project management and agile teamwork including projects and organizations doing any kind of work. Scrum – used for software new product development and IT project management. Kanban – used for teams doing operational work.
This seminar contributes towards three certification programs: the Scrum Alliance’s Certified ScrumMaster program, the OpenAgile Team Member level and the IPMA/PMAC Agile Project Management certification.
For more information and http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars register: http://www.berteigconsulting.com/UpcomingAgileScrumOpenAgileSeminars
Proudly delivered by Berteig Consulting, a Canadian organization since 2004.
I have worked with a lot of people, teams and organizations over the last 8 years helping them to adopt Scrum and I have seen some interesting patterns about where Scrum works well and where it doesn’t work so well. I wanted to share my observations to see if they correlate with what other people are experiencing.
So first off, I want to describe what I mean by Scrum working well:
- Teams using Scrum are obviously high-performance teams whose business results are at least 4x that of normal teams.
- The organization in which Scrum is being used experiences a change in culture to become more team oriented, more value oriented, and more customer oriented.
So now I can describe where I have observed Scrum to work really well:
- When an organization (or team) is in deep trouble and willing to admit it adopting Scrum seems to be a catalyst for creating a new culture, process and team environment where getting out of trouble is possible. This is Scrum for Crisis. The “willing to admit it” part is extremely important as I have worked with two organizations where the “deep trouble” part was obvious to me as an external person, but in both cases management and staff did not seem willing to admit the depth of their crisis and in both cases Scrum failed to act as a catalyst to get them out of trouble. In this use of Scrum, sometimes resolving the crisis then leads back to complacency and Scrum fades away.
- Small growing organizations that have no existing formal processes for development can use Scrum as an effective way to maintain their high-performance without getting burdened in bureaucracy. In this case, it is important to note that they are _already_ in a high performance state and their struggle is to maintain that while at the same time growing. I’ve worked with quite a number of small organizations where all they need is the CSM (plus maybe one or two days of coaching) to adopt and maintain Scrum. I have also worked with small organizations that were _not_ already high performance and Scrum has not typically worked to bump them up to a high-performance state.
- Pure new product development where a single strong Product Owner can be identified who has the authority to make product decisions independently of anyone else (including product budget decisions). By “pure new product development” I mean that neither the individual team members nor the team as a whole have any responsibilities outside of the product work – there is no “fractional allocation” or “resource levelling” across projects or products. The strong Product Owner is critical to success with Scrum and must understand the principles of Scrum as well as the mechanics of being a Product Owner.
I have also seen Scrum be inappropriate and not lead to the results I mentioned above:
- Management teams. It seems like Scrum could or should work for management teams, but it appears that managers have too much of the following problems to be able to use Scrum:
- operational responsibilities (non-creative, non-problem-solving work)
- urgent, legitimate interruptions (e.g. an escalated customer issue)
- real commitments to events or projects that are calendar based (e.g. a management off-site)
- ego: they don’t want to follow an apparently rigid process or they are always happy to make exceptions for themselves
Again, one might imagine that Scrum _should_ work to help resolve these issues, but unfortunately I have never seen it able to do so in this context.
- Small teams/projects. Scrum is too heavy for teams less than 5 people or for projects shorter than 2 months in total duration. Those numbers aren’t meant to be hard and fast, but when I’ve seen small teams/projects attempt to do Scrum they _always_ end up breaking lots of the rules partly because they can and partly because they must. That said, some folks have created “Personal Scrum” and other variants. I’m not sure if we as the Scrum Alliance officially recognize/endorse those variants.
- Purely operational work. There just isn’t enough creativity/problem-solving to make the Sprint an appropriate process element, nor the Product Backlog an appropriate organizing mechanism. I have seen some operational environments get some benefit from doing regular retrospectives, but just doing retrospectives is not Scrum in my book. My experience with Kanban is still a little limited, but it seems to be an appropriate approach for these environments.
- Organizations where there is very little need to change. I’ve spent some time working with big profitable banks to adopt agile and without exception, they just can’t wrap their minds around the need for Scrum… because they are already so successful as a business. The general attitude is that Scrum is popular therefore we will call what we are doing “Scrum”, but it really isn’t. It’s Scrummerfall and Scrum-Butt wrapped up in the terminology of Scrum. They will adopt some Agile practices and get very modest benefits. I have seen minor improvements in team morale and minor improvements in quality and productivity, but certainly not anything near to what is possible for improvements. When we do assessments in this type of environment, we see Value Stream maps with waste at the 80-90% level so there is huge room for improvement… but it just doesn’t happen.
Scrum can definitely transform the world of product development. It can definitely act as a catalyst to get teams and organizations out of crisis. But that isn’t the whole world of work. I’m also concerned about the idea of using Scrum for general project management. There might be some good practices that are part of Scrum that would also be valuable in general project management (e.g. regular retrospectives, daily team meetings) but that doesn’t make Scrum a general project management framework.
I don’t claim that any of the above observations are “correct”. That’s partly why I am sharing – I would love to have a good discussion here about this because I think it is critical for us as Agilists to be able to answer this question well when we are asked: “what is Scrum good for?” – particularly since Scrum is by far the most popular Agile method.
I would love to hear other people’s observations about where Scrum works well (as I have defined “well” above) vs. where it either is only a modest improvement to existing approaches or where it might even not work at all.
The manifesto for agile software development (http://agilemanifesto.org) consists of 4 basic values:
1. Individuals and interactions over processes and tools?
2. Working software over comprehensive documentation?
3. Customer collaboration over contract negotiation?
4. Responding to change over following a plan
I’ve been thinking about how this manifesto applies outside of the world of software, for which it was originally created. These concepts are so engrained into various agile methodologies, which these days don’t explicitly refer to software any longer, that it begs the question: how does a team apply these four values to their work outside of software development; specifically, what would replace delivering ‘working software’? The other three values translate more fluidly to differing spheres of work. For example, whether in the field of business, sales, medicine, etc. placing greater value on all the items on the left over those on the right will produce a transformed culture and working environment. But what does ‘working software’ translate into in these various realms? Particularly relevant for non-profit organizations, the next possible question would be: what if we are not creating a ‘product’ or something that is ‘shippable’? What I’ve found to be the methodology which most aptly addresses this question is OpenAgile.
On its website: www.openagile.com it is noted that: OpenAgile is a learning system designed to help individuals, teams, and organizations build capacity for rapidly delivering value to their stakeholders. Rather than the focus being on a product, the aim shifts to learning and value. Yes, the ‘product’, if there is one (software or other), is important, but now there are even greater possibilities for the use of agile outside of software.
Though almost deceivingly simple, the principles animating OpenAgile are extremely profound. Through practicing the core foundational principles of truthfulness, consultative decision making, and systematic learning (through reflection, learning, planning, and action – all in light of guidance) the potential ability to ‘deliver’ something valuable is extraordinarily enhanced. Indeed, the greatest value could even be the learning that has taken place from the team or individuals themselves, the changed culture now animated by consultation engendering collaboration rather than competition, the regular and ongoing practice of truthfulness in a team resulting in accelerated transformation (potentially also allowing for that team to be more committed and driven to delivering a ‘product’) and the creation of a space where continual learning is the hallmark.
In an Agile culture, it is considered rude to refer to people as “resources”. People are not fungible – you cannot just take any old developer and plug them into any old project. Skills, personalities, likes, talents, potential all are so dynamic and unique for each individual person. So any management theory (including traditional project management) that treats people as “resources” like oil, gold or computers, is making an unjust simplification at the expense of the people working in the organization.
Yet organizations need to be able to plan where to spend money, and certainly the people working in an organization are often one of the largest costs. From a financial perspective, from a business perspective, it makes sense to somehow treat people costs in the same way as other operational costs… and this often leads to dehumanizing people to the point of treating them like resources.
So how can these legitimate organizational needs for budgeting mesh with the equally legitimate approach of Agile to treating people as unique actors be merged? It is actually quite simple, but the ramifications are deep: treat TEAMS as resources. Teams become the fundamental building blocks of an organization. Teams move from project to project or program to program or operation to operation. There is still a need to support the individuals in an organization, but it is done in the context of teams.
An Agile team is cross-functional, but also constantly learning. Individuals on the team learn skills based on their own interest, but also based on the needs of the team for redundancy, parallelism, and expansion of capacity to take on new, more challenging work. Cross-functional teams can more easily (and more sanely) be compared for their value to the organization by looking at things such as their ability to produce finished product/services, their flexibility in serving the needs of the organization, and the quality/consistency of the work they produce. Teams can compete in a healthy way by striving for excellence in delivering value to the organization, whereas often competition between individuals can be quite unhealthy.
From a budget perspective, teams are easy to manage: each team has a fully loaded cost based on salaries, space, equipment, etc. The cost is (or can be) relatively stable or grow predictably, and can still be handled operationally. As well, unlike individuals, it is much easier to treat a whole team as a fungible unit: you feed work to teams based on their availability rather than based on a detailed analysis of their skills/capacities/allocations.
In Agile organizations, teams are resources, people are not.
Cross-posted from the personal blog of David D. Parker: A Changemaker in the Making
I. Agile Volunteer Team Process
- The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
- Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
- Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
- The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
- Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
- When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
- When a volunteer completes a task, they move the task into the “done” column.
- There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
- What did I do last week?
- What will I do this week?
- What did I learn/observe?
- What obstacles, if any, are affecting my ability to do work?
- New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
II. Communication Tools
- Login and read new messages
- Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
- Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
- Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
- Get work done:
- Move the task on the wall to in progress
- If the task came from an email, label the task with your name
- When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
- ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
- By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
- FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
- Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
- Task Written & Posted – apply this label after you write up the task and post it on the wall
- Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
- Website – these emails are relevant to website updates
III. What is 60/40 Time?
- Belief in the mission of the charity
- Desire to “give back”
- Meet new people
- Make new business contacts
- Invited or inspired by another volunteer or staff member
- Improve resume
- Learn new skills
- Benefits such as free events
I have started composing a series of articles on my blog A Changemaker in the Making that are intended to briefly explain how to apply different agile practices to the work of social innovators, non-profits, charities and volunteer organizations.
The first article covers Self-Organizing Teams an important consideration for organizations that want to use their people resources more efficiently and to create a culture of empowerment.
The second article explores The Agile Workspace and ways to create an environment that is conducive to fruitful interaction.
OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up.
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment.
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five.
Improved role definitions based on extensive experience.
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
- is not responsible for team development
- is not necessarily a single person, nor is it a required role
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
- is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
- is not necessarily a single person, nor is it a required role
Integration of principles and practices from other methods. Two examples suffice:
From Crystal: creating a safe work/learning environment.
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management.
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal.
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.
Comparative Glossary between OpenAgile and Scrum
|Cycle Planning||Sprint Planning and Sprint Review|
|Team Member||Team Member or “Pigs”|
|Growth Facilitator||Product Owner|
|Work Queue||Product Backlog|
|Work Queue Item||Product Backlog Item|
|Cycle Plan||Sprint Backlog|
|Progress Meeting||Daily Scrum|
|Learning Circle w/ steps||“Inspect and Adapt”|
|Delivered Value||Potentially Shippable Software|
|Five Types of Work:
New, Repetitive, Obstacles, Calendar,
|- no equivalents -
User Stories, N/A, Impediments, N/A, N/A
|Consultative Decision Making||- no equivalents -|
|Sector / Community||- no equivalents -|
References on OpenAgile:
References on Scrum:
“Agile Software Development with Scrum” - Schwaber and Beedle
“Agile Project Management with Scrum” - Schwaber
“Scrum and the Enterprise” – Schwaber
I’ve been researching teamwork lately. I just finished reading “The Discipline of Teams” by Katzenbach and Smith which is an HBR summary of their much more substantial book “The Wisdom of Teams”. I decided that it would be good to be able to describe the essential skills an individual needs to acquire in order to work effectively in a team. First stop, Google and a search of “list of teamwork skills”.
Strangely, not much turned up on the first page. The best result is found at “7 Essential Skills for Teamwork” which is a page on a public elementary school web site. So, here’s my adaptation of their list:
Active listening is a skill that allows a person to completely focus on the communication of another person including both verbal and non-verbal aspects. Active listening requires the ability to not think of your own responses until after a person has finished speaking. One simple way of doing this is to echo what a person is saying in your silent internal voice. When someone says “I think we should build a new gimbal on the widget”, you are saying exactly the same thing in your own mind. Active listening also requires that you request clarification, often by rephrasing what a person has said and asking if you have understood correctly.
Being able to frame and express questions effectively helps us understand and integrate knowledge into our own mental model of the world, or even to modify our mental model. Asking questions is easy. Asking good questions is much harder. We need to use an appropriate set of words and tone of voice so that we do not alienate or offend the recipient of the question. For example, asking “why did you do that?” will often put people on the defensive since they will assume that you mean you disagree with their actions. Instead, saying “I do not understand the reason you did that. Could you please explain it to me?” can be a much more gentle way of getting to the same information.
When presenting an idea or position, being able to logically support it is important to exploring the truth of it. This includes being able to share your assumptions or axioms, the data you are basing your argument upon, and the logical sequence of reasoning to reach your conclusion. Being able to avoid fallacious logical methods is also important.
Showing respect includes acknowledging the fundamental human value of the existence of your teammates, and being able to step back from your own understanding of the world to acknowledge the legitimate nature of the perspective that other people have. This does not mean that you have to let teammates get away with inappropriate behavior. In fact, respect for your teammates will allow you to support them in behaving in ways that are in alignment with their fundamental nobility as human beings.
Offering help and actually following through with real assistance are aspects of helping. When you suspect that a team member is struggling with something, you offer to help both verbally and with your actions. This can take the form of offering information, offering emotional support, offering to assist with problem-solving, or actually taking action to do an activity together. When we help someone, we share their burden.
Sharing our knowledge, time, skills or physical resources are all aspects of sharing. Sharing among team members is focused on those things which will help a team reach its goals. This is similar to helping except that it tends to be more of a transaction than an ongoing activity. The transaction is that you give a gift and then the other person uses that gift to meet their needs. Sharing does not require reciprocity. If you share something with another person, you should not expect that that person will return the gift at any time in the future.
It’s probably obvious, but in order to effectively be on a team, you need to participate! Participation itself is mostly obvious: do work with the other team members. However, there are also some less obvious aspects of it. You are not participating when the team is having a discussion, you find it boring, so you check your email. You are not participating when the team makes a decision and you abstain from helping to execute the decision because you disagree. You are not participating in a work team when you are mentally checked out because of a crisis at home.
All of these skills are critical teamwork skills… but there may be others. Do you think there are other skills missing from this list that are critical for effective teamwork?
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
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!
- 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
- – a boundary within which self-organization occurs e.g. project, team, role, nationality
- – 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”
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
- – 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
- – insert new exchanges, new people, new techniques or tools
- – e.g. team that needed to get outside help re: architecture
- – cross-training
- enlarge or shrink team
- 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
- 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
You are the ScrumMaster or PM:
- 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”
- 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
- – 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
- – 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”
- Teamwork by Larson and LaFasco or Hot Spots by Lynda Gratton
- example: Bill Gates and “Internet Tidal Wave” memo
New book by Mike Cohn:
Two very interesting videos. The first, a presentation by Rod Jeffries, goes through a treatment of “Lateral Violence”. The second is three role-play scenarios to demonstrate the concepts. Both of these videos are in the context of nursing in hospitals… however, it takes little imagination to see how they apply in other environments. I would actually assert that the problems described in these videos are endemic to most organizations.
Alistair Cockburn has also written about safety in a team context.
Scrum and other agile methods all have some mechanisms for dealing with this sort of challenge, but they can start failing quickly if the sponsors of the agile effort do not overcome the habitual and cultural challengs.
I have just started reading Crystal Clear: A Human-Powered Methodology for Small Teams by Alistair Cockburn. I was not too sure what this book would provide for me in the way of relevant learning.
I am intrigued that this work came out of years of experience by Alistair. This quote from the book “Crystal Clear does not aspire to be a “best” methodology; it aspires to be “sufficient,” in order that your team will shape it to itself and then actually use it.” gave me hope. I work on a small team and I wonder about which practices will best suit our situation. I also wonder how our team can use tools and processes then reflect on their usefulness to decide if we will continue their implementation.
I am interested in reading the whole book, but a little concerned that there will be too much techno-words used throughout. I have a background in business, marketing, and the web but not to the degree of the some of the other books that I have read.
What learning have you gained from working on small teams? Have any of you read this book? If so, did you gain any insights that would help my team to develop?
So far, we’ve discussed learning and value as benefits of agile. Now we turn to a more human side: satisfied stakeholders. Agile methods provide multiple roads to satisfaction for customers, users, business people, bureaucrats (okay, maybe not _all_ bureaucrats), team members, managers, shareholders, and interested passer-by. There are three primary mechanisms by which this occurs: engagement, trust-building and feedback-control. [UPDATED: added link to explanation of Commitment Velocity]
Recently I’ve talked with a number of people who have a simple question: what do we do with teams that are constantly interrupted by urgent support requests for their time?