Always be learning - Teach yourself new techniques. Expose yourself to different ways of thinking. It doesn’t have to be about games either. An artist I know learned how to build Arduino electronics and started joining us programmers for lunch to ask great questions. He invited us to join the artist's weekly nude drawing class (but I’m not sure any of us took him up on it).
Pace yourself - Crunch is inevitable, but lots of research has shown that beyond several weeks, productivity can drop below that of normal hours. It can take courage to shut down the studio for a weekend after several weeks of crunch, but it is worth it.
Micromanage less - Coach and encourage your developers to solve problems on their own. When they come to you with a problem, ask “what have you tried” instead of providing the solution. When you see a problem they don’t, ask them if they see the problem instead of telling them what to fix.
Grow cross-discipline communication - Problem solve across disciplines instead of handing off design docs. Find ways to communicate more. Steve Jobs famously designed the Pixar building to “force more interactions” between disciplines. Look at ways of generating conversations through cross-discipline brown bag lunch sessions or even trying different seating arrangements.
Play your own games often and early - Many mechanics that make games great didn’t appear in the original design document, but emerged mid-development from the team. Many of my best memories of game development come from end of day sessions playing our game and talking about improvements over a beer. The earlier you can enjoy even a core mechanic or two, running with placeholder assets, the more engaged the team will be with the game.
Invest in people - Game development is craftsmanship, not mass production. Traditional craftsmanship requires years of apprenticeship before an effective level of skill is reached. Assume people are at different levels of skill and help them grow where they need to. Sure, they might take their new skills you invested in and go someplace else, but a studio that respects people enough to invest in them usually has great retention rates.
Enjoy each other - Do things outside of work. Don't let the schedule and stress kill relationships. Decades from now, when you are reflecting on your career, you’ll remember the people you worked with more than the games you made.
It’s that time of the year when we reflect on the past and plan for the future. An arbitrary time, which has always bothered me. We should really be doing this in a continual fashion. I try, with daily, monthly, and quarterly reflection, but I’ll admit that the end of the year is still a special time.
As is customary for us, my wife and I head off to a remote beach house for a couple weeks, which also lets us reconnect a bit. By the way, I’ve found that two solid weeks is really what’s required to appropriately decompress, relax, and reflect at the end of a year. Anything less and your mind is distracted by the logistics of travel, meal planning, and so forth. I need two weeks in a chair with a view, preferably with no people around. Ok, except my wife.
Overall it’s been a good year. I’ve gotten into the best shape I’ve been in in the past thirty years, we bought a house that we’re doing an extensive remodel on to turn into a “lean home,” I finally finished and published The Simple Leader, and I’ve been able to reinforce a more robust daily reflection practice.
I’ve also been successful at significantly reducing my travel, and for the first time in decades I will have no (zero!) status on any airline going into next year! Scary, but strangely liberating. The perks of United 1K and American Executive Platinum are simply not worth the intangible costs. Hello row 35!
Perhaps the goal I’m most satisfied with is reading – a lot more. Decades ago I used to devour books every couple days, but as the pressures of life and business took hold, the habit slipped. I still read a lot of blogs, online newspapers, the WSJ each morning, and so forth, but books are different. The length of books creates context and complexity, which leads to contemplation and personal growth. I believe it’s important to avoid becoming superficial in thought.
Last January I told you how my annual “do something different” goal for this year was to read a work of literature from a different culture each month. I’m happy to say I’ve been successful and it’s been a very rewarding experience. Here’s how it turned out:
- January: One Hundred Years of Solitude by Gabriel Garcia Marquez (Latin America)
- February: The Kite Runner by Khaled Hosseini (Afghanistan)
- March: Things Fall Apart by Chinua Achebe (Africa)
- April: One Day in the Life of Ivan Denisovich by Alexander Solzhenitsyn (Russia)
- May: Men in the Sun by Ghassan Kanafani (Palestine)
- June: The God of Small Things by Arundhati Roy (India)
- July: Life and Death Are Wearing Me Out by Mo Yan (China)
- August: The Wind-Up Bird Chronicle by Haruki Murakami (Japan)
- September: Ceremony by Leslie Marmon Silko (Native American)
- October: Breath, Eyes, Memory by Eldridge Dantikat (Haiti)
- November: Hunger by Knut Hamson (Scandinavia)
- December: Sightseeing by Rattawut Lapcharoensap (Thai)
The Kite Runner was easily my favorite, followed by Ivan Denisovich. Ceremony started out rather slow, but became an intriguing look at Native American society as well as the experiences of returning war veterans. Life and Death and Wind-Up Bird were interesting immersions into Chinese and Japanese life, although keeping track of the multiple reincarnations in Life and Death (some not as humans!) became a bit difficult.
While staring at the ocean the past couple weeks I’ve also cranked through several more books, but from a wider variety of genres.
I started off with a couple that my wife challenged me to read as they are definitely outside my normal spectrum: The Glass Castle by Jeannette Walls and Wonder by R.J. Palacio. I then dug into The Undoing Project by Michael Lewis, then When Breath Becomes Air by Paul Kalanithi, which lead to The Language of God by Francis Collins. That kicked me onto a more spiritual reading path with The Book of Joy by the Dalai Lama and Archbishop Desmond Tutu, which referenced Brother David Steindl-Rast so I devoured his The Way of Silence. I ended on a more superficial level with Tim Ferriss’ latest, Tools of Titans.
As usual, Tim is a bit over the top in many areas, but there were also some really interesting nuggets of wisdom. The Language of God, The Book of Joy, and The Way of Silence are phenomenal books and highly recommended, regardless of your spiritual persuasion.
Several concepts from those books were great reflection points, such as the eight pillars of joy as described by the Dalai Lama and Desmond Tutu: perspective, humility, humor, acceptance, forgiveness, gratitude, compassion, and generosity.
Based on that I’ve come up with a plan for the upcoming year, continuing to reinforce daily practice. And I’ve also determined my new “do something different” goal. But this time I’m keeping it private, at least for now. A hint: it could involve extreme endurance. And I spent a lot of time on my “stop doing” list.
Best wishes for a happy, healthy, and productive new year. Take the time to slow down and reflect. What will you improve next year?
Do you want to know how to create transformational experiences for others? I have recently discovered what I have been doing and am writing this post to share my understanding of it. My hope is that you find something valuable. Transformational Experiences To give you a taste of what I am talking about, here are some […]
The past couple of years I’ve been travelling back and forth to LEGO’s HQ in Billund Denmark, helping out with their agile journey. Super interesting! Learned more than we could ever fit in an article, but here’s an attempt to capture at least some of it, written together with LEGO colleague and co-instigator Eik Thyrsted Brandsgård. Enjoy!
So naturally the conversation went something like this:
Inquisitive person: "Hi David, what's an Agile Transition Guide? Is that like a coach?"
David: "Hi, glad you asked. What does a coach do in your experience?"
Inquisitive person: "They help people and teams improve their software practices."
David: "Yes, I do that also."
Inquisitive person: "Oh, well then why don't you call yourself a coach?"
David: "Great question: Let's see... well one of the foundational principles of coaching (ICF) is that the coached asks for and desires an interaction with the coach, there is no authority assigning the relationship, or the tasks of coaching. So do you see why I don't call myself a coach?"
Inquisitive person: "Well no, not really. That's just semantics. So you're not a coach... OK, but what's is a guide?"
David: "Have you ever been fishing with a guide, or been whitewater rafting with a guide, or been on a tour with a guide? What do they do differently than a coach? Did you get to choose your guide, or were they assigned to your group?"
Inquisitive person: "Oh, yeah. I've been trout fishing with a guide, they were very helpful, we caught a lot of fish, and had more fun than going on our own. They also had some great gear and lots of local knowledge of where to find the trout."
David: "Well, there you have it... that's a guide - an expert, a person that has years of experience, has techniques to share and increase your JOY with a new experience."
Inquisitive person: "Yes, I'm starting to see that difference, but can't a coach do this also?"
David: "No, not unless the coach is willing to switch to a different modality - to one of mentoring, teaching, consulting, or protecting. Some times a guide must take over for the participant and keep the person/group within the bounds of safety - think about a whitewater river guide. A coach - by strict interpretation of the ethics, is not allowed to protect the person from their own decisions (even if there are foreseen consequence of this action."
And now the conversation start to get very interesting, the Whys start to flow and we can go down the various paths to understanding. See Richard Feynman's dialogue about "Why questions"
So, I'm not a Coach
I've been hired as a coach (largely because the organization didn't truly understand the label, role, and the ethics of coaching). This relationship was typically dysfunctional from the standpoint of being a coach. So I decide to study the role of coaching. I've done a few classes, seminars, personal one of one coach, read a lot and drawn some conclusions from my study - I'm not good a coaching within the environment and situation that Agile Coaches are hired. I've learned that regardless of the title that an organization uses (Agile Coach, Scrum Master, etc.) it doesn't mean coaching. It intends the relationship to be vastly different. Since I'm very techie, I appreciate using the correct words, and phrase for a concept. (Paraphrasing Phil Karlton: In software there are two major challenges: cache invalidation and naming things. Two Hard Things)
So to stop the confusing and the absurd use of the terms, I quit referring to my role and skills as coaching. Then I needed a new term. And having lots of friends that have been Outward Bound instructors and understanding their roles, the concept of a river guide appeals to me in this Agile transformational role. Therefore I coin the term Agile Transformation Guide. But many organization do not wish to transform their organization, but they do wish for some type of transition, perhaps from tradition development to a more agile or lean mindset. So a transition guide is more generic, capable of the situational awareness of the desire of the organization.
What does a guide really do?
This question may best be answered by David Kelley in his TED talk, "How to build your creative confidence." In this talk David points out his desire to teach parents that there are not two types of children - the creative and the non-creative. There are, however, children that lost their desire to express their unique talents early in their lives. He helps people regain this capability.
It is much like how Dr Bandura has developed his treatment for phobias. David will tell you about this basic guided mastery technique that restores self efficacy.
This is what an Agile Transition Guide does... they guide you on a journey toward self efficacy via many techniques in mastery of your domain skills and capabilities.
Six Kinds of Agile Coaches by Ravi Verma Describes the HUGeB coach, the one to be.
Where Agile goes to Die - Dave Nicolette - about those companies that are late adopters or laggards in the innovation curve and the challenges that "coaches" have when engaging with them.
The Difference Between Coaching & Mentoring
Scrum Master vs Scrum Coach by Charles Bradley
Agile Coach -or- Transition Guide to Agility by David Koontz; the whitewater guide analogy to agile coaching.
Academic paper: Coaching in an Agile Context by David Koontz
What is the ROI of Agile Coaching - Payton Consulting
Interesting Twitter conversation about the nature of "coaching" with Agile42 group.
But not Agile2016 - so you can only see it in the Microsoft NERD center MIT.
I presented this workshop at Agile Camp - Dallas, Oct 19th.
DFW Scrum Meeting Aug. 18th 2015
It’s said that two heads are better than one, in reference to problem solving. We will use Tangram puzzles to simulate this experience, and via structured debriefs of these exercises, discover the powerful behaviors of awesome collaboration, and the negative warning signs of poor collaboration. We will jump right into simulation exercises, come prepared to have FUN and learn by doing. No lecture - if you want a lecture… go here: http://lmgtfy.com/?q=+collaboration+pair+programming+lectures
Here are some of the resources and exercise if you wish to reproduce this workshop or want to dig further into the science behind collaboration.Presentation Cultivation Collaboration (PDF) *UDATED 5/8/16* Spoiler Alert - don't look at the solutions!References on collaboration (PDF)Jim Tamm's TED TALK on defensiveness (PDF)
Retro process phases: Set the Stage, Gather Data, Generate Insight, Decide what to Do, Close the Retro
Set the Stage: give time to “arrive” and get into the right mood and focus upon the goal
Gather Data: reflect upon what happened, create a shared pool of information
Generate Insight: why did things happen this way? What patterns can we observe?
Decide What to Do: Pick what to work on, plan concrete steps of action
Close the Retro: reflect upon the retrospective, how could it improve? What shall we follow-up upon?
Activities for this Retro:
In ONE word – what do you need from the retro?
In ONE word – what is on your mind?
In ONE word – what is you current mindset in regards to your project: are you a:
Explorer – eager to dive in and research what worked
Shopper – Positive, happy if 1 good thing come out
Vacationer – Reluctant, but retros beat regular work
Prisoner – Only attend because they make you
The Four Ls
Regarding the last iteration, individually for each of these 4 questions (one item per sticky) write:
What I Loved
What I Learned
What I Lacked
What I Longed for
Everyone rates the last iteration on scale of 1 (poor) to 10 (perfect).
Next – make suggestion to raise your rating toward a 10, rate that suggestion using remaining 10 – x points
Circle of Influence & Concern
On a chart of concentric circles… inner to outter circle;
Team controls – direct action
Team influences – persuasive action
System – response action
Sort insight from Perfection Game into circle of influence & concern;
Write possible actions – annotate the item with actions
Dot vote on which action to attempt
The team created this info graphic of their Four Ls exercise using the Circle of Influence & Concern. Stepping back they realized - they are the master's of their domain.
We Control our own Destiny
Feedback Door – Smilies
Happy, OK, Sad
Mark your satisfaction with the retro session on the chart.
Introducing the Team Performance Model by Drexler and Sibbet
Orientation - Why am I here?
"Orientation is about understanding the purpose of a team and assessing what it will mean to be a member. you need to understand the reason the team exist, what will be expected of you and how you will benefit from membership. In a new team, these are individual concerns, because the group is only potentially a team. that is why these concerns are illustrated as occurring in your imagination at an intuitive level. As a team leader it is important to provide time and space for people to answer these internal questions themselves."
Keys to when Orientation challenges are resolved:
- Team Purpose
- Team Identity
Blocked teams at stage 1 Orientation may show...
Trust Building - Who are you?
"Trust is a measure of your willingness to work together with others for something important. Because team members have to depend on each other to be successful, trust is essential in direct relation to how much cooperation is needed to get the job done. In the beginning of a new team's live, trust involves some risk and uncertainty about dealing with strangers. This is why the key question is "Who are you?" An unstated aspect of this question is wondering, "What will you expect from me?" For a team to work well, you need to accept that you can depend on team members to work together to accomplish the team's purpose."
Keys to when trust challenges are resolved:
- Mutual regard
When a team is Blocked at stage 2, members may show...
Goal Clarification - What are we doing?
Sometimes teams have precise charters that specify what they are responsible for accomplishing. More often, they are given a broad mandate and nee to make choices about how they will pursue that mandate and translate it into goals. "What are we doing?" is a more specific question than the larger question of purpose asked during Orientation. During this stage of a new team's life, it will need to do research and develop clear understanding of the job that is required, as well as generate agreements about goals and specific deliverables."
Keys to when goal clarification challenges are resolved:
- Explicit Assumptions
- Clear integrated goals
- Shared vision
Blocked at stage 3, members may show....
- Apathy and skepticism
- Irrelevant competition
Commitment - How will we do it?
"When goals are clear and options are identified, your team is probably eager to act. Attention moves to the question, "How will we do it?" this stage occurs at the bottom of the "V" in the TPM, the point of the greatest constraint. This means committing to a specific course of action, making decisions about resources, and being clear about roles. These are also the indicators of having addressed the "turn". Remember that the initial stages of team performance involve a good bit of trial-and-error. Embracing these questions might require backtracking to goals, investing more in trust development, and revisiting initial purpose before you can fully resolve commitment issues."
Keys to when commitment challenges are resolved
- assigned roles
"As your team turns toward implementation everyone will want to be clear about roles and responsibilities. You may have considered these during stage three planning, but now need to commit to what your function, authority, and responsibilities will be in practice. Role definitions have to be complete enough to cover all the tasks that must be done to accomplish your team goals while minimizing overlaps and role conflicts. A big part of your job if you are the team leader is to help match goals to competencies, and help people step into roles that will develop their abilities and improve results for the team."
- allocated resources
"In addition to role clarity, your team must deal with another constraint - how to provide for and deploy its limited resources, including time, money, and so forth. These hard choices usually involve setting aside some useful tasks because the resources are not available to support them. Indecision in this area breeds confusion and stalls work. For virtual teams, decisions about tools and communication platforms are essential at this stage. Teams may have to negotiate with the larger organization to get the kind of tools and support they need. This is why the TPM intersects the organization "platform" at this stage."
- decision made
"Finally, a team needs to get clear about how members will handle decision making. Will authority be shared? How will you stay in touch with one another? Who can spend what funds? In a dynamic work environment where plans can change frequently, decision about course corrections are common. Thinking through in advance how these will be handled moves the team's focus more productively toward implementation and high performance."
Challenges at stage 4, members may show...
Implementation - Who does what, when, where?
"Implementation involves scheduling and sequencing work over time. The key question is "Who does what, when, and where?" A visible schedule, strategy, and / or process liberates the team to move into action confidently. Conflicts and confusion arise when there is commitment but no clear way forward."
Keys to when Implementation challenges are resolved:
- clear processes
- disciplined execution
Team's blocked at stage 5, member may show...
- missed deadlines
High Performance - WOW!
"High performance is a WOW state, as a team masters its processes and begins to experience the ability to change goals as well as achieve them. You can feel when it happens and observe its effects, buy not necessarily control it. Teams achieve a flow state when trust is high and people have mastered their roles. In a state of high performance, boundaries and individual limits soften, everything moves together, and everyone responds as if they are part of the whole. The indicators of that having happened are spontaneous interaction, synergy, and a team that is surpassing their expectation on results. WOW symbolizes how high performance teams transcend rational processes by working with all the human faculties - spirt, soul, mind, and body."
keys to when High Performance challenges are resolved:
- spontaneous Interaction
- surpassing results
When a team is blocked at stage 6, members may show...
Renewal - Why continue?
"Over time the conditions that initially set your team in motion will change. High Performances is demanding. Don't be surprised if people ask, "Why continue?" this key question reminds us that team performance is an ongoing process, and must be renewed by returning to Stage 1 and reassessing if the work is still needed, worthwhile, and has some personal value and meaning. Spending time on renewal puts your team back in touch with meaning and purpose and refreshes everyone's commitment to keep going. It also includes learning from what you have accomplished, and building a repertoire of best practices for the next journey on this or other teams. If your team's work is completed, Renewal is the time to wrap things up, freeing members to move on to new challenges."
Keys to when renewal challenges are resolved:
- recognition and celebration
- managing change
- staying power
When team's are blocked at stage 7, members may show...
This is just a taste of the awesomeness of Sibbet's book on visualizations and exercises to build great teams. Want to know more - read the book. You will learn lots about how team move forward and backward toward performance. And the exercises to work with teams to help them share their understand of where they are, where they are going and what might set them back are very well explained.
Reference: Visual Teams - Graphic tools for commitment, innovation, & high performance by David Sibbet.
Jay W. Vogt of Peoplesworth explains the Drexler Sibbet Model of team building and how it can result in a positive outcome. YouTube
Management 3.0 Workbook
7 levels of Delegation exercise
Sibbet discusses the origins of the TPM - SketchTalk
Description of charts:
Burndown chart - a daily count of the number of task units (aspirin is this teams selected units for task estimation) not done. This includes the task yet to be started, and task in process.
Tasks in Process - a daily count of the number of tasks in process.
Tasks Done - a daily count of the number of tasks that are done.
Stories Done - a daily count of the number of Stories that are done.
Velocity - the empirical measure of Stories that are considered done by the team and accepted as done by the Product Owner during the Sprint Review.
The Back Story on this team:
This team had been attempting to do some form of ad-hoc Scrum / Kanban with little guidance and understanding of the process. The Kanban aspect came from the company's tooling (RTC) template - not from any real practices the team was implementing. After some weeks of observations and workshops with the team - they decided to "hit the reset button" on doing Scrum. Sprint One in the info-graphic is the first sprint right after a week long workshop on learning Scrum practices and principles. Key to this team's adoption of Scrum is their adoption of a physical task board (see also Elements of an Effective Scrum Task Board).
Observations on Sprints:
Sprint One - Started with many stories from past sprint that were not yet done - as the team had no empirical data of velocity we guessed at how many stories we could complete in the 2 week sprint, and chose 15 stories. At this point we had 4 product silos where people we working within the silo to deliver the stories - very little cross team collaboration.
Rules siloSprint Two - Tear down the silo walls - the team decided that the original silos of working was harming a long term desire of cross-functional team members - so a removal of the silo walls (tape on the scrum task board) happened.
Sprint Three - Enforced the use of empirical data to constrain the team's selection of how many stories to bring into the sprint (team select top 5 stores and finished all of them).
Sprint Four - Team planed for 30 points of stories but finished early and pulled in additional stories and finished them within the sprint.
Objectives for the Team:
This teams objectives for hitting the reboot button on a scrum implementation was to achieve a consistent level of reliability to deliver value (stories) to the business. Also to maintain and supporting the existing 4 products line internal organizational clients, and transitioning tacit knowledge from several remote employees to the team and increasing cross-functional capabilities of the team members.
Commentary on Metric Charts:
Burndown - Sprint 1 and 2 task burndown charts show that the team started with around 100 aspirin and discovered between 50 and 100 aspirin more by doing the work - but didn't finish the 15 stories and left lots of stories started but incomplete at the end of the sprint. In sprint 3 and 4 the team had developed the ability to forecast the proper amount of work to pull into sprint planning and were able to deliver the completed stories.
Tasks in Process - this simple metric showed that the team of about 8 people were consistently task switching. There are many "reasons" (excuses) for this behavior, and it is a hard habit to correct in this era of high utilization rate driven management. Just tracking this metric had little effect on the teams behavior - however we had empirical data that other practices (avatars, re-estimating in process tasks, etc.) had a positive effect upon this metric over several sprints.
Tasks Done - this metric is redundant for a team using a traditional sticky note task board. In general this reflects the sprint burndown. It does point out for this team that tasks done stalls out when there support tasks flare up, as these support (maintenance and production, M&P) issues require task switching to the more urgent unplanned work. Reflecting upon this metric lead the team to start tracking the planned tasks separate from the urgent support tasks in our burndown chart for sprint 5.
Stories Done - an interesting trend shows up in this simple to trend metric. The team was capable of finishing 5 stories, regardless of how many they planned. In sprint 3 when the team constrained the planning to the empirical evidence (~28 points, 5 stories) they had there first successful sprint (on time, on budget, with planned scope).
Capabilities developed by the Team not shown in these Metrics:
Tasking - working toward tiny tasks. Within the first two sprints the focus was to develop the ability to task stories. Several synergic practices lead to this capability - re-estimating each time the task is touched in stand-up; recognizing that task that last for several days are way-too-large; learning to decompose tasks that are too large; realizing that doing work leads to discovery of new tasks that need to be recorded and added to the board. See Also: What belongs on the TASKS board?
Single Piece Flow - working on a task until it is done. Smaller task effect this behavior in a virtuous manner. Re-estimating each day makes the antithesis of this pattern apparent, and also offers the opportunity for team members to recognize when help is needed. The use of avatars on the story tasks reinforces the practice of lowering work in process and reducing task switching.
In Sprint 5 the team decided to move from a 2 week time box to a 3 week sprint. The charts also show the support (M&P) tasks tracking independently of the planned tasks and the new chart at the bottom (M&P task vs Planned task deltas per day) indicates the inverse relationship of the priority shifts the team has to deal with.
Develop the capabilities to deliver agile release plans and forecast feature release time frames for business coordination with other teams that depend upon the infrastructure product lines developed by this team.
At the team coaching level an objective is to measure cycle time of stories within scrum teams.
Metrics for a Scrum Team - 10 suggested metrics and examples
Measuring Process Improvements - Cycle Time by Mishkin Berteig, June 2008
7 Lean metrics to Improve Flow - LeanKit
An Exercise in Estimation: How many times can you fold a piece of paper in half & half again...
I do this exercise when beginning scrum teams start story estimation or task estimation. While this exercise has a unique twist that is very different than task estimation or story estimation - very few people foresee this aspect of the exercise, so it adds to the ah-ha moment.
Start by giving everyone a sheet of typical paper (8.5 x 11 in the USA - although the size just doesn't matter). Then tell them the exercise but ask that no one do any thing yet. First we will estimate. The task is to estimate how many times you could fold the paper in half and then again in half and repeat... without doing it what's your estimate of the number of folds?
Ask people to call out their estimate, write then on a board in no particular order or fashion.
Typical groups come up with estimate in the range of 5 - 20 folds.
If you want to do math... calculate an average estimate... or just circle the mean value.
Next have the group fold the paper in half and half again up to 4 times - then STOP and estimate again. Same as last time - call out the estimates and write them down on the board.
Next - fold the paper until you are done. How many folds did you get?
Now the debrief: What did you learn in this exercise? What happened to the estimates - why did this happen? What generalizations of estimating can we learn from this example? So when do we practice this re-estimation technique in Scrum?
For BONUS points - how many times do you need to fold paper to get to the Moon?
How Folding Paper Can Get You to the Moon
MythBusters episode: Folding a large piece of Paper in Half - What's the Limit
Moon Scoops - Buzz Aldrin on the things you do not know about the Moon Landings - Late Night
Introduction: What We Have Learned
Originally written in 1993, this edition written in 2003 has additional insights from 10 years of working with teams. The authors see more pragmatism on the subject, less thoughtless rushes to a fad movement. Top leaders are seeing that teams also apply to themselves, at the top of the business. They see the core aspect as discipline, not the management fad du jour. The discipline for team performance has 6 basics: team size, complementary skills, common purpose, performance goals, commonly working agreements, and mutual accountability. The desire to be a team is not sufficient - one must have performance centric outcomes as the objective. Leadership is more important at the beginning - but not the primary determinant of success. Most organizations have untapped potential in team performance. The organizations performance ethic makes the difference between one-off success and widespread organizational team performances.
The authors develop an explicit terminology, to distinguish commonly misunderstood phrases when discussing groups and teams. The Y-Chart (p. XXI) helps explain the taxonomy of groups (Effective Group vs Performance Units; Single-Leader Unit vs Real Team). They define an abstract Team Performance Curve, noting time as the major factor in achieving high (extra-ordinary) performance. The decision of which type of team; single-leader unit vs team is dependent upon 3 factors: need for collective work products integrated in real time by two or more people, shifting leadership roles for situational awareness, need for mutual accountability in addition to individual accountability. Setting outcome-based goals is essential to achieving high performance (as apposed to activity-based goals). Real teams require more time and leadership capacity than single-leader units. Process support for multiple team opportunities across broad programs is essential to scale the team success from one-to-many.
Prologue: A Note About What to Expect
The book notes the obvious concepts but also the subtle nature of language used to describe the concepts are required to be precise in defining the discipline. The authors find that it is difficult to apply common sense to teams. Expect failure when: building the team for its own sake is the goal (rather that demanding performance challenges), the discipline of “team basics” is overlooked, many areas for teams are left unexplored in organizations (teams: recommend things, do things, run things), teams at the top of organizations are the most difficult, individual accountability is the norm (as apposed to team/group accountability).
Uncommon-sense findings: strong performance standards seem to spawn more teams than teaming-for teaming sake; high-performance teams are extremely rare; hierarchy and teams go together well; teams naturally integrate performance and learning; “teams are the primary unit of performance for increasing numbers of organizations” (p. 5).
Part One: Understanding Teams
Focusing on Team Basics - figure 1-1 (p. 8)
Apex: Performance Results; Collective Work products; Personal GrowthSides: Skills (Performance results - Collective work products) Accountability ( Performance results - Personal growth) Commitment ( Collective work product - Personal growth)Internal: Skills - Problem solving, technical function, interpersonal Accountability - Mutual, team size, individual Commitment - Specific goals, common approach, meaningful purpose
Chapter 1: Why Teams?
The authors have learned that although many executives understood the argument for using teams many didn’t extract the real potential from the teams or the opportunities to use teams. Many times because of unwarranted assumptions and poor knowledge.Key lessons:
- “Significant performance challenges energize teams regardless of where they are in an organization.” Performance is the primary objective. A team is the means - not the end.
- “Organizational leaders can foster team performance best by building a strong performance ethic rather than by establishing a ream-promoting environment alone.” Focus on customer satisfaction performance rather than teamwork performance.
- “Biases toward individualism exist but need not get in the way of team performance.” Turn individualism, self-preservation, and self-centered objectives to the benefit of the team.
- “Discipline - both within the team and across the organization - creates the conditions for team performance.” “Groups become teams through disciplined action. They shape a common purpose, agree on performance goals, define a common working approach, develop high levels of complementary skills, and hold themselves mutually accountable for results.”
Teams are made up of individuals with complementary skills - build on strengths, not to cover weakness. Define clear goals, via team communication. Build real-time problem solving skills and initiative, allow adaptive behavior. Provide social dimension to enhance work - teams fundamental nature are people interactions. Fun is part and parcel of the process - encourage it.
Resistance to teams come from 3 primary concerns: ”lack of conviction”, “personal discomfort and risk”, and “weak organization performance ethics” (p 21-23).
Teams do not solve all problems, they are not the answer to every problem. They require discipline and practice. Organization culture may be opposed to teams if a strong individualistic performance is reward in spite of team performance.
Chapter 2: One Team: A Story of Performance
As a basic unit of performance a team blends the knowledges, skills and abilities of several people strengthening the overall performance of individuals. Many people having once experienced the power of a high performing team long for the experience again. Burlington Northern launched the Intermodal Rail era after deregulation in 1981. Largely the result of a core team of 7 individuals, with an extend group of 45 people. This team was largely self selective, all were interested in the new prospects of intermodal rail and saw the value even in face of large corporate resistance and hostility. The team started small and grew as needed, bringing in and fostering the required skills. A positive attitude that the goal was possible was shared by all. Hard work and long hours were the norm for the group. When the group’s proposal was approved but with the worst pilot project locations the group saw the opportunity to prove the concept and jumped right into it. The core group shared leadership roles and had strong affinity of tacit information on specific skill sets. They assumed a ask for forgiveness rather than permission attitude, and resolved impediments quickly. The results was a change in the business model for the industry, intermodal rail is now common place and well established business process for the rail industry.
Ch 3 Team Basics A Working Definition and Discipline
Teams are a “powerful vehicle for performance” (p. 43) many companies are embracing teams as a unit of performance. There are differences in understand of what a team is and what constitutes a performant team. Teams work well when they have specific results to achieve, and the performance ethic of the organization demans those results.
“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.” (p. 45)
Small number - in the Agile community we say 7 +/- 2 ( 5 - 9 members). Reasoning is the tacit knowledge of each other (the group) and the intercommunication of the team. The larger the number the lower the accountability for success. Large numbers have logistical problems not seen in smaller groups (space to meet, etc.). See Also: Choosing the Team Size in Scrum by Agile Pain Relief
Scrum (software development process) offers a way to scale teams to very large (hundreds) numbers.
Complementary skills - we call this a cross-functional team. A team must have a person with the required skills to solve the problem, and it will take many skills to solve most any complex problem. Many successful teams realize they lack certain skills, and become self reliant on learning or acquiring the skill set.
Committed to common purpose and performance goal. Teams must see the purpose for their existence, be motivated to achieve the goal. The best teams spend significant time discussing their purpose, reshaping it and refining that purpose over their lifetime.
Committed to a common approach. Agreement on the approach, process to solve the problems is a key, they may spend considerable time on this issue also.
Mutual accountability. Teams must hold each other accountable for the achievement of the goal, the quality of the products, and the process. They must be capable of defining their own standards for performance and encouraged to raise the bar.
Ch 5 The Team Performance Curve
A team does not start out at super high performance, it takes time to reach this goal. Many teams never reach their potential. Experts say that if a team does reach high-performance that it should not be disbanded but kept together, and given a new purpose. The performance curve describes this growth to high-performance.
Work groups are not teams, though they may develop into a team. One difference is the focus either on team performance or individual performance & accountabilities.
Pseudo-teams never agree on purpose, or accountability of the group, they get stuck in rituals and avoid rather than engage each other.
Ch 8 Teams, Obstacles and Endings: Getting Unstuck
Every team will encounter obstacles, high-performing teams develop tools for overcoming these obstacles. Teams lower of the performance curve may need help to over come obstacles of all natures. Teams may become stuck, and not develop the tools to resolve their obstacles, then it is time for serious help. Stuck teams: lack energy, or enthusiasm, have a sense of helplessness, lack identity, lack purpose, members are cynical, and have a high degree of mistrust.
A weak sense of direction - the team needs to create common goals, take joint responsibility.
Insufficient commitment to performance - team needs accountability for the problem and the solution, based in performance measures.
Critical skills gaps - team needs to hire experts or develop skills. They must be capable of admitting they need help - identify the type of help and go get it.
Getting unstuck: - 1) revisit the basic of teams, 2) build on small successes, 3) inject new information and techniques, 4) get facilitation skills & training, 5) change team membership or leader
Transitions and endings will also effect the team, may drop them back into lower stages of Tuckman model of development - allow for that, don’t expect no emotion for losses.
Have you heard of a MVP - Minimal Viable Pumpkin?
Minimal Viable Pumpkin (MVP)https://en.wikipedia.org/wiki/Lean_startup
Our first trap is trying to achieve change with tools of our status quo.One common example is "planning the change". We believe planning is "a professional attitude", when it's only utility is to reassure us. Farer we are of our comfort zone, more we need to be reassured. And here is the gap where the cost of fear sneaks in: the gap between the needs of the ecosystem (market, customers, teams, organisations) and the natural need of leaders to control their ecosystem.
Here are some of the sources that sum-up as important costs for organisations and that I call "the cost of fear" Continuous planning vs continuous delivery Planning as a reassuring activity that addresses fear of not controlling was already mentioned above. Over planning need stakeholders and teams to be involved and spend (sometimes) an impressive amount of time in planning meetings. While planning is happening, decision to deliver is deferred.While planning is on the agenda, value does not reach customers. The cost of fear is the cost of continous planning
Ongoing estimation and frozen development What about a team more that 10 people focused on estimating backlog's User Stories for 6 weeks in a row? Meanwhile PMOs, Project Directors, CxO people and other coordinators spend at leas half of their time taking decisions on how the future will look like when the estimation will be done. No development or delivery happens before leaders are reassured with a number (estimation).The value of an approach like NoEstimates, domain where Vasco Duarte and Woody Zulli have had major contributions), lies also in reducing the delay to deliver.While estimation is ongoing, no value reaches customers. The cost of fear is the cost of ongoing estimation.
Risk Management vs Emerging Architecture
Locking our options in early decisions about architecture of our future product is another way we address our need of reassurance that the future will behave as we decide it. Personally I still recover of IT architecture committees I've been in years and years ago ;). The protocol is the following : a lot of talented experts meet to analyse all the risk of the future and address them with a list of operational actions and or adequate design. Usually these Risk Management committees end-up with a deferred decision as a new risk revealed in the just closed committee has to be addressed and discussed over in the next one. The only decision is to defer decision£.While analysing risks, no solution is emerging and no value reaches the customer.The cost of fear is the cost of focusing on risk management.
The Cost of fear, a systemic description
System have self-regulating actions called feed-back loops. The feed-back loops are rather reinforcing : system behaviour is reinforced by the feed-back loop- The Cold War period is an example of a system within a a reinforcing loop - or balancing: system behaviour is regulated to stay in given boundaries.
I think the cost of fear is causing a reinforcing loop that leads to growing frustration of leaders and increasing organisation bureaucracy.
How to reduce the cost of fear?Well, my part of the answer is in the title of the paragraphs above, and to pit it in only one word it is : Experiment! Experiment has some magic powers for two reasons. One is that triggers a mindset where we know we are allowed: to try, to be wrong.The second is that it puts organisations on a learning path, that addresses the systemic nature of an organisation. And by the way, true learning is fun, true food that keeps our brain happy.
Principles that (may) reduce the cost of fear
- Deliver a prototype rather than plan,
- Define a team capacity rather than estimate tasks
- Drive by emerging design (helpful reference in Alexandru Bolboaca's work) rather than performing risk management.
The cost of Delay is included in the cost of fear, as we don't act until we are reassured.
Okay, this looks like reduce cost-of-fear just-to-try-principles cheat-sheet. It's not enough. An additional question to answer is "How to address the fear that generates these costs?". And this is the most tricky question. Fear is the strongest symptom that some basic needs are not met. Just telling leaders/managers/architects/teams/stakeholders/Decision makers/ that their action is not aligned with their intention ( of delivering true value to customers fast, collaboration, self-empowerment, test&learn) is simply not enough. Were you more brave when someone just told you "don't be afraid!"?Addressing the fear needs compassion, listening and observation.
Epilogue : The (mostly) hidden cost of fear
Peter Senge also says the 2most powerful motivation drivers are fear and aspirations. Aspiration leads to positive vision: "We want to achieve something" , fear to negative vision : "We want to avoid something".
Vision lead by fear trigger compliance behaviour : people do their job to be compliant to a vision issued by hierarchy its related rules and regulations. Vision lead by aspiration trigger commitment : people do their job because they want that vision, and they can empower themselves to change the rules and regulations accordingly. The 20th business "led-by-fear vision behaviour" was considered "professional". I believe that the only thriving organisation model is the "led-by-aspiration" one. I do hope the 21st century will consider "led-by-aspitration" behaviour to be nevertheless "professional".
Ultimately, what do you thing is the cost of a non thriving organisation?Related posts Manage like a PirateWhy I Am Not A Change AgentFrom Listening To Awareness
Usable Software Design
This is an excerpt from The Simple Leader: Personal and Professional Leadership at the Nexus of Lean and Zen
People don’t resist change, they resist being changed.
– Peter Senge
To survive, an organization must be continually improving and changing. This requires both leadership commitment and the support and input from all employees. It is important to be mindful and aware of the concerns of everyone involved, in order to leverage their support.
As Peter Scholtes, author of The Leader’s Handbook, noted, people don’t automatically resist change. But they do want to understand the change and be given the opportunity to provide input, which creates ownership. This is one of the key advantages of kaizen: the change process includes people from all levels of the organization, particularly those that are part of the production process. Additionally, involving people in the kaizen efforts and giving people the training and support they need to create change shows respect for them.
Employees want to understand the impact of change on their livelihoods. Leaders can forget what it is like to live from paycheck to paycheck, and when people are fearful of how they will support their families, they tend to have a very conservative perspective on change. This will slow down the improvement process, unless leaders give workers transparency, trust, and ownership.
To create security, some Lean organizations tell their employees that no one will lose their jobs as a result of improvement activities. This is powerful, but you also want to be careful. Be sure to link the security directly to the improvement activities and avoid giving the impression that it transcends issues outside of your control, such as sudden changes in the market. You want to create trust, and trust requires transparency and only making promises you can keep.
To optimize improvement efforts, respect your people by asking them to play a key role in the improvement process. Give them confidence they will not be harmed by potential side effects of the improvement effort, offer training and mentoring so they know how to create improvements, and provide them with the time to identify and execute improvement activities. If you do these things, you will find they are more likely to embrace the changes you want.
Last week I announced my intention to write a short ebook on solving specific problems with Node.js and Docker, called Docker Recipes for Node.js. I’ve had some time to plan, since then, and I want to share my thoughts on how the book might be organized, and the type of content that will go into it.
Thoughts on Recipes
The general idea behind the book will be to provide recipes that solve specific problems with Node.js and Docker development. And like a recipe book, I’ll group related recipes into sections – most likely organized around the type of problem they solve.
Instead of breakfast, sandwiches, soups, casseroles, deserts, etc., I’ll organize around containing Node.js apps, debugging containers, composing services, etc.
Chapters will be named “recipes”, and will include the recipe itself (with the “ingredients” comprised of code, configuration, command-line options, etc).
There will also be “cooking instructions” with each recipe, providing enough detail to know what each part of the recipe does and why.
While the cooking instructions may provide some additional detail on how to use the ingredients listed, the recipes will be short and focused. They won’t be tutorials that take you from nothing, with Docker. For that, I have the WatchMeCode Guide to Learning Docker and Guide to Node.js with Docker.Recipes Available at Pre-Sale
I plan to have at least 1 recipe completed, as a preview for how they will be presented – most likely debugging code running in a container. I’ve already written a first sample recipe around this idea, and will be reviewing it with a few people to see if this is going to be good for the pre-sale.
The final content of the book is still to be determined, even if this is a general direction that I want to move.
Changes will be made based on feedback from readers of the pre-sale, and additional research. I’ll be looking forthe most common problems and convenient solutions for Docker development with Node.js.Pre-Sale Details (Coming Soon)
I’ve covered a bit about how the content will be organized in this post, but haven’t talked about the pre-sale details yet.
That will come soon… very soon, in fact. The pre-sale will be happening within January, but I’m not yet ready to announce the exact dates.
Stay tuned to the blog or the mailing list (sign up, below) to get the pre-sale info as soon as it’s available.Tweet
The post Organizing the Upcoming Docker Recipes for Node.js ebook appeared first on DerickBailey.com.