Documents Say…

The Agile and Scrum literature, including training classes, recommend a team size of “seven, plus or minus two.”  This means a Scrum team should have 5-9 members as the ideal size.  In Scrum this number includes the Product Owner and ScrumMaster.  There are many reasons for this recommendation:

• A team smaller than five decreases diversity of skills, opinion and background too much, which hurts creative capacity.
• Imagine a retrospective on a team of three people. There is a strong tendency toward either a regular complaint session or mutual admiration society.  Neither of these would lead to productive improvements very often.
• A large team requires too many relationships at once.  For example, every member of a 10-person team has nine relationships to maintain, with a total of 90 relationships in the team.  Add an 11th member and the number of relationships goes up to 110!
• The overhead of coordination grows with team size along with the difficulty in maintaining relevance between the members.

Experience Says…

I was once the ScrumMaster of a seven person team.  We were starting the creation of the base technology for a the company’s next generation of products.  Exciting stuff!  We hired or pulled people from other projects to grow the team as the work progressed.  At around twelve members I began asking about splitting the team, to keep the size reasonable.  We decided against it, that we wanted everyone to be aware of what was happening in this complex work.

And the team continued to grow.  Software engineers, hardware engineers, VHDL (embedded stuff) designers and so on were added.  Soon we had 26 on the team.  Yes, it was big, way too big.  We still held our daily stand-up meetings and kept them to 15 minutes or less most of the time.  We worked hard to keep meetings tight and relevant.  And we failed at keeping the energy up.

Splitting Is Good To Do

After several sprints we finally had consensus to split the team into three.  Let me paraphrase some things people said about their new team size after the first sprint:

• Retrospectives are better because it is easier to write items for “well” and “improve” because didn’t have to worry about boring other members with things they don’t care about.
• Daily meetings were not an interruption of hearing about things I wasn’t working on.  I could work, go to the meeting and go back to work with the same thread of thought.
• My team members are helping me more often now. I guess they didn’t really see when help was needed when we had such a large team.

Large or Small, Watch

Whether your team or teams are large or small, watch what is happening.  Pay attention to the information flowing in meetings and during the work.  Especially give a strong look at what is happening in the retrospectives.  Are things discussed shallow or repetitive?  Is there confusion when clarity was expected?  So some members feel alone in the team?  The size of the team may be something you can change to remove such doldrums and re-energize the communication!

Projects need teams?

It is a very common practice for companies to manage work into projects.  Customers understand this and portfolio management, even management of larger projects, tends to naturally fall into divisions of projects.  The difficulty is that companies naturally extend this into creating a project centric view of all process.  What equipment does the project need?  Which lab facilities are available for the project?  Who are the resources with the right skills?

That last question is about people.  When we think of people as “resources” and “skill sets” we start to see them as interchangeable parts of a machine that will work on a project.  So we take a group of people, many who have never worked together, and assign them to a project and call them a team.  Because, if you are on the same project, you must be a team, right?

Preventing a team

Teams need time to learn how to work together, to figure out likes, dislikes and strengths of each member and time to develop an identity and trust.  These things don’t happen by declaration and don’t happen in one week or even one month.  When these deep interaction attributes solidify, the group of individuals becomes a team.  Great teams can take on whatever you throw at them!

The habit of swapping people in and out of teams is destructive to building these connections and high-bandwidth communication channels.  Ester Derby points out some of these bad effects:

Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.

It is surprising to me that we fail to see the cost of breaking apart a team.  In the project-centric managing view, a project ends so the team gets split apart on new projects.  And we throw away the investment we made over months of work, choosing instead to pay the cost of re-building a high-performing team.

Teams need projects!

If creating teams around projects is the bad for true teamwork, what do we do with teams and projects?  The Agile Manifesto has an answer in it’s fifth principle:

Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.

Once you have a high-performing team, define projects that they can do.  Work with your customers to create a project that your teams have already proven that they can build and impress people doing.  The costs of dividing people and rebuilding trust, communication and capabilities is very high.  And your teams who have learned how to act as one will be happier to know their joint contribution is valued.

By the way, that team who was afraid of breaking up had a happy ending.  We figured out with management and company needs how they could stay together and continue impressing customers. It was a nice beginning to that ending!

Context

If Agile is about people, it’s surely about communication.  Let’s start by looking at a few things we know about communication:

• Some say human communication is only 7% words while the remaining 93% is verbal and visual (http://en.wikipedia.org/wiki/Albert_Mehrabian).  While some might argue the exact ratio, I agree that face-to-face communication is by far the best way to share information and create.
• The ability to grasp abstract subjects and invent is severely damaged by context switches and distractions.
• Understanding the history and context of a subject increases the ability to be productive in that subject.
• Any change in the membership of a group (team) will disrupt the relationships and communication paths of the group.  It will take time to reestablish the previous levels of efficiency.
• Any person highly experienced in a general skill area will need to learn the basics of any specific situation before they can be fully productive in that specific situation.

Almost anyone would find the above statements as reasonable, even intuitive.  And yet, point by point, common real life situations continue every day:

• Work environments are designed such that the use of anything more than email, instant messaging and documents very difficult, if not impossible.  IT policies and work requirements force dependency on only words and eliminate the rich audio and visual channels we naturally know.
• Day after day we are required to change projects, product focus and attention.  Some engineers I know have as many as 12 or more projects to keep in the air.  Details are lost in the context switches.
• Developers and other workers are thrown into projects with no information about the purpose of the work, the roles of the people involved or the value of the product.  Instead of listening and building the confusion of purpose reigns.
• Individuals are “resources” to be plugged in and out of “teams” at will and whim.  Long term relationships with shared experiences building high communication connections never happen.
• Questions about basic information are met with chastisements from peers and managers.  For some reason people are expected to know already without any training or orientation.  People learn to not ask questions.

Innovation Sabotage

Pushing people into situations of poor communication, severing communication paths and obfuscating information will not produce real innovation.  Working harder and longer will not make up for the damage.

I’ve attended meetings where top executives tout technology and projects that will propel the company to new heights of profitability.  They point out the places in the plan where differentiating innovation will be created.  Difficult problems will be solved to create the products and success that will come.

And, the company does not allow the use of internet video conferencing.  And defines projects based on “resource” skills without regard to geographic location.  And has key projects running with no defined structure or governance models.  And considers “fire fighting” just the way the industry works.  And requires heavy sign off processes by people who don’t know what they are approving.

Many times the disconnect is both huge and invisible to the executives and even the people working under fog and confusion.

Agile Means Transparency

To be Agile means communication about everything.  Finding ways to easily share everything such that when data is needed, it is readily discovered.

• Don’t eliminate up to 93% of human communication capability, enhance it.  Put teams in their own rooms, not cubes or offices.  Design product development structures to support co-location instead of distribution of people.
• Give teams goals that don’t change all the time and members that are dedicated to the team, not split multiple ways.
• Explicitly define and publish team structures.  Allow new people to be trained on products and processes before they are required to be fully productive.  Organize the information in radiators that passively keep people in the know. Give people time to learn them.
• Projects and products come and go.  Teams should not.  Allow deep relationships to form and cultivate over time from project to project.  Soon you’ll have teams that can do anything you throw at them.
• Basic questions should be welcomed and the answers immediately available.

People Problem, People Solution

Every problem is a people problem.  Every single one.  Ask people to solve the problems.  If you are a manager, business owner, vice president, you are the creator of the work environment.  Don’t forget the people and people attributes.  The power of people allowed to communicate fully is far beyond any technology or process.  ”Individuals and interactions over processes and tools” is not just some feel-good mantra.  It is what we need to solve our problems and innovate!

My Mentors

• Don Dayley, my father – Taught me all the foundational things in life, including how to mow the lawn when I did not want to, sometimes through uncomfortable methods.  He also gave me an unsurpased example of attention to craftsmanship.  Everything he builds or repairs is better than new when he is done.
• Mrs. Fedler, 4th grade teacher – I found most of my first three years of public school boring.  Mrs. Fedler found ways to show me that learning itself was fascinating.  And she showed me that exploring the boundaries beyond expectations was praise worthy.
• Mr. Douglas, 11th grade chemistry – THE hardest teacher I ever had, including college.  The scientific method, analysis, reporting, supporting conclusions based on facts and failing with good humor are among the things he taught me.  Ask me why he sometimes called me “Beaker.”
• Pedro Brassinini – Taught me to love strangers more than I ever dreamed possible and to feel compassion deeper than I had known.  And how self-sacrifice brings inner rewards.
• Bill Sheppard – My first engineering boss was hard and understanding with me, a green engineering student.  He showed me that trust is part of doing my work well.
• Kevin Kilzer – A brilliant engineer of software and hardware.  He harnesses passion for the work like no other coworker in my experience.  Creativity fueled by inner fire is awesome.
• Mike Vizdos – A guide over the years of my journey into the Agile and Scrum world.  Quiet thought is a powerful tool, which he knows and shows how to use in all his work.
• The Ignite Phoenix Team have shown me Agile collaboration skills and community building prowess that I hope rubs off on me.  (Don’t tell them they are Agile, they’d get too self-conscious.)

I could go on with more mentors, some who don’t even know the little, important things they have taught me.  You should take some time to make your own list, even just mentally.  You have had some great mentors too, or you would not be where you are.

Gangplank Mentor

Before I knew January was Mentor Month, I was invited to be a member of the mentor team at Gangplank.  I’m one of the mentors on business operations.  Once a month, more often when I can, I’ll have office hours at Gangplank.  You can book a 45 minute session with me to ask questions about Agile and Agile frameworks like Scrum and Kanban.

My first mentor day is in the afternoon of Tuesday, January 25th.  No fee, just set your appointment with the Gangplank Director of Operations and let’s talk about taking your operations to the next level.

I can’t necessarily give back to all the mentors in my life.  But I can give to someone, who can build something great and give to someone else!

Gangplank is a place and movement that redirects us to see the people. Where we see the value of tapping the full human, not just functional skills for a corporate machine. My work to bring agile concepts into corporate environments is a similar effort. Gangplank strengthens me in my quests.

Please step over and give the post a read.  If you don’t know about Gangplank, I hope this will provide your first taste of that community.  Lot’s of people there live and breathe the principles of Agile!

A Holistic Enterprise View

The whole enterprise can be thought of as a circle.  This circle is divided into three areas of focus.  These three areas are almost never equal and will vary based on size, age and needs of the enterprise.  Yet all three are present, if sometimes neglected in turn.  The picture is like this:

Work

This is what the enterprise does, what it is paid for.  Work is the product and all the production performed to create the product, tangible or digital.  Work is the sum of the actions, the designing, writing, testing, coding, speaking, drawing, etc. that create what the customers buy.  This is the highest focus of the enterprise and rightfully so, for without this, the enterprise cannot sustain itself.

Information

This segment of the circle represents the data or artifacts either produced or needed to do the Work.  This is be source code, documentation of all types, emails, invoices, meetings, logs, procedures, accounts payable or receivable, etc.  All enterprises large or small have and produce this data which must flow efficiently for the enterprise to do well.

People

This third segment represents the people and their interactions as they do the Work.  This is management, hierarchy, social behavior, teamwork, conflict, collaboration, politics, disagreement, personality, etc.  In order to accomplish the Work, people must communicate and interact.  It is a huge, yet intangible, component of the enterprise.

Focus Areas

Each of these three areas, Work, Information and People, must function together.  Work is always there, it is the reason for existing.  When a company first starts it may be only one person or perhaps a few more.  In such a situation the Work dominates all thought and effort.  This is OK because a small group can usually move Information quickly and get along well as People.  As an enterprise grows, difficulties within the Information and People areas more significantly impact the Work.  From cultural habit, the enterprise will want to continue to focus on the Work but there must be people designated to prevent neglect in the other two areas.

• How long does it take for a developer to learn about a field problem in a product?  The answer to this question is one measure of how will the Information area is doing.
• Does a person on the low end of the hierarchy feel safe to tell his supervisor or even division manager about a problem?  This is a check on the People part of the enterprise.
• When the lab needs new equipment, how hard is it to get?  This can touch on both Information (purchasing procedures and documents, etc.) and People (asking the manger to change the budget).

Keeping these three areas balanced according to the current needs of the enterprise is the primary function of mangers.  They have the authority, position and mandate to ensure that the Work does not suffer because of neglect with the Information and the People.  A great enterprise, dare I say an Agile enterprise, makes sure the Information moves quickly to the right place at the right time and that the People are interacting in high performance!

A Holistic Team View

This discussion started with a view to the enterprise but let us conclude by boiling it down to the Agile team.  What do these three areas of focus look like when we use them to view a small working group?

• The Product Owner pushes Information flow about what the Work should be.  Features, progress, vision and direction are controlled by Information in and out of the team.
• The ScrumMaster focuses largely on the People part of the team.  He helps them resolve conflicts to create constructive outcomes.  He creates environments in and out of the team that allows for trust and truth to be visible.
• The Team of developers focus on the Work, the product and the components that make it.  With the Product Owner providing Information direction and the ScrumMaster maintaining a People friendly environment, the Work gets all the attention it needs for high quality and speedy production!

Note that each of the Agile team roles must keep the whole circle in mind and overlap, for all three areas are important.  But each role as the area on which they focus the most.

For me the point of this view is simply another way to look at enterprises and teams.  For me it brings more clarity to my roles as ScrumMaster and Agile Coach.  Us it as a tool help you think about where you are and where you can create more value for your enterprise and team!  Let me know what you think about it.  I’d love to learn more!

It’s Work

When I contemplate why I do all this extra work in my spare time, I sometimes conclude I must be cazy.  Extra meetings, lots of email and phone calls, sometimes dealing with difficult situations or people, giving up evenings, days and weekends for the priviledge of working in the hot sun or wrangling a meeting.  Whew!  Am I nuts?

What I get out of such work is valuable to me as a person.  The thrill of helping others, enjoyment of a back-stage pass to a special event, working with great people and learning about myself make all the extra work a small price to pay.

It’s Beneficial

Think about the last time you volunteered to do some work for a community group.  Might have been small, like ushering for one evening event or maybe large like months of planning for an all day festival.  Why did you do it?  How did the leaders of the group “rope you in” to giving up that much time in your life?  You might answer similarly to me.  Here are some other possible reasons:

• You want to help achieve a great goal.
• You enjoy recognition and feedback about your work.
• You seek an avenue for personal growth.
• You wish to give something back to the community.
• You want to bring about social change on a larger scale by working with others.
• Your family needs help and support.
• You are seeking friendship, support, bonding and a feeling of belonging.

When we volunteer based on any one or more of these reasons we are motivated, energetic and worth our weight in gold to the communities we serve.

Agile Connection

You might ask what volunteering has to do with agile practices.  The more I work with agile, the more connections I see.  Some examples:

• Introducing Agile Practices – When introducing agile practices to a traditional environment grass-roots and top down support must both be present.  The agile evangelist must gain the support of many at both the developer and management levels in the organization.  In other words, people at multiple levels of the organization must volunteer to participate.
• Planning – Frameworks like Planning Poker help draw all participants into the planning process.  The Product Backlog, estimating, etc. rely on input from stakeholders and developers alike.  They are expected to volunteer this information into the process.
• Daily Meeting – A fully performing team does not wait for the Scrum Master or other person to direct the meeting.  Each participant volunteers to report what is done, what will be done and any impediments.
• Retrospective – Ever been in a retrospective where the participants don’t offer any input or feedback?  Doesn’t work unless people volunteer information and honest evaluation.
• Self Organizing – Teams used to being told what to do have a hard time volunteering for self control.  And that is what it takes to self organize.

Command and control is the antithesis of volunteering.  A leader that uses command and control will never get the high energy, power and creativity that a dedicated team of volunteers can produce.

Getting Agile Volunteers

I have found that participating as a volunteer worker or leader in community projects is a valuable experience.  I watch myself and others to learn why we volunteer.  I watch the leaders to learn how they nurture the volunteers and the organization.  Look at the list of reasons one might volunteer for a community organization.  It’s probable the developers and managers in your work place are looking for many of those same things!  Volunteering experiences can be reapplied to transform reluctant agile participants into powerful volunteers!

Do you volunteer or lead community volunteer organizations?  What have you learned about creating “volunteers” for your business and team’s success?

We had a long chat over pancakes about teams, change, Scrum and how things are going in our transition to agile.  There was lots of good and some areas where improvement is needed. (It’s great to have “C-level” support for our efforts.)

A few weeks prior to this chat, a new VHDL engineer was hired and joined a Scrum team on a critical company project.  The executive pointed out this engineer’s experience as an example of a benefit of Scrum.  Paraphrasing, he said:

Off and Running! (Photo by Gio JL on Flickr. Used under CC License)

He came on and integrated right into the Scrum team.  I think he became productive faster than any engineer in the history of the company.  He spent no time thrashing because the team just pulled him into the sprints.  I love Scrum because it provides a place to plug new people in.

His statement struck a cord as I realized he was right.  After less than a month, I no longer thought of this engineer as the “New Guy.”  It is the traditional title of the newly hired engineer, bewildered while trying to learn the ropes, culture and products.  The title wore off so fast, I didn’t even notice it was gone!

Of course, having great engineers on a functioning Scrum team also helped tremendously.  And, the Scrum framework was there to allow the new engineer to actually hit the ground running.

I love it when the benefits of Scrum are so obvious!

A common “resource” on a traditional development team is the Team Lead.  This is one of the positions that change or disappear after the transition to Scrum.  Naturally, introducing Scrum into a company seems to bring many questions about the Team Lead.  “Who do we go to with questions?”  “Who owns the technology?”  “You mean the Team Lead goes away!?  How can that work?”

The primary focus of value in Scrum is on the team, not individuals.  So how does the value of a Team Lead get provided by a Scrum team?

In one company there were several discussions with project managers and management about the Team Lead position.  Mostly, they thought it was necessary for a Scrum team to have one person as Team Lead.  A definition of the Team Lead’s Roles, Responsibilities, Accountability and Authority was created.  We had some difficulty communicating how the value of the Team Lead is not lost in Scrum.  Here is the definition of the Team Lead after mapping it to the team:

A read straight down through the Traditional column is interesting.  Imagine one person required to do that. One person. I would not want to be that person! Can one person do all those things effectively?

Team Value

Lets check each of the traditional values as provided by Scrum:

• Technical point of contact: Because everyone on the team collaborates consistently, the entire team ends up cross trained on the entire product.  When technical questions or discussions arise it’s likely that anyone on the team is aware of the status, technology and progress.  Your “bus number” goes up!
• Team management: Scrum banishes command and control by placing management with the team.  Peer pressure of a good kind is created during the daily meeting and planning meetings.  Commitment to peers in an environment of trust is a powerful motivator.
• Assuring cost goal: The return on investment (ROI) of a product is the focus of the Product Owner.  Scrum defines the schedule and costs as fixed.  The Product Owner assures the cost goal by guiding the team to build the highest business value parts first.
• Assuring technical requirements goal: With the help of the developers on the team, the Product Owner maintains the Product Backlog.  This focuses the teams efforts on the customer value and steers the team to technical solutions that meet the value.  The Product Owner may not be technically knowledgeable.  But with good story definitions and Sprint Reviews (or Demos) he knows when the story is complete.
• Assuring schedules met: Time spent adjusting Gnatt charts and project road maps that change every other day is no longer needed.  With sprint length defined, the dates for a potential release are already decided.  The Release Plan is adjusted every sprint to match current progress.  Schedules are nearly automatic.
• Voice of sanity to company: Transparency and visibility of a project are hallmarks of a good Scrum team.  All the indicators on the team board, story point velocity, estimates, team planning sessions and retrospectives provide a clear view of reasonableness or insanity to the entire company.  The power of retrospectives to uncover unrealistic expectations or company impediments cannot be over-stated.
• Personnel scheduling and time management: This is completely automatic in a Scrum team.  People know what they are working on because they are on a team, focused and motivated to complete a Sprint Backlog.  Enforcing the rule of protecting the Sprint means time management is easy.  If it’s not in the Sprint Backlog, don’t spend time on it.
• Discover and escalate impediments: Scrum defines specific moments where all members of the team are expected to bring up impediments.  The daily meeting format includes discussion of impediments by each member.  Sprint Retrospectives create a safe environment for larger and deeper difficulties to come up.  The Scrum Master and Product Owner are expected to have difficult conversations with management and others when needed.
• Escalate negotiation if original goals not achievable: If a failure of the project is coming, it tends to become visible very early in a Scrum team.  All the indicators already discussed above with “Voice of sanity” reveal unrealistic expectations right away.  The Product Owner is in the point position to bring this up to the company and knows by daily interaction with the team that it is coming.
• Manage engineering problems: The daily meeting is the place where process or infrastructure problems usually surface.  The team talks about them, asks about them and watches for them every day.
• Direct team member activities: In Scrum the Sprint Backlog, as derived from the Product Backlog, directs what the team needs to accomplish.  The team then designs the activities or tasks needed to accomplish their committed work.

A well functioning Scrum team has the best leader it can get: The Team!  Leadership made more powerful by investing it in the whole team.

My Certified Scrum Trainer, Micheal Vizdos (@mvizdos, http://implementingscrum.com), taught in my certification workshop that Scrum Masters spend lots of time starting difficult conversations.  He was so very correct.  By this time I had already started many difficult conversations with leaders and managers about agile and Scrum.  I had faced the CTO and come away with support.  But I worried about talking to this collegue.  I had fear of this engineer because:

• He was very skilled in the craft, with knowledge and the ability to create great software.
• He had a strong personality, able to decide what he wanted and work for it.
• He pulled no punches, stating his opinion with conviction.
• I admired his abilities and work ethic.
• I didn’t know him, personally, very well.

In other words, to face him I had to know what I was talking about and put my beliefs in the line of fire.

One day, with my training ringing in my ears, I asked him why he objected so strongly.  A difficult and rewarding conversation followed.  It was the beginning of understanding, of many more conversations and of working better together. (I’ll write about the content of that conversation another time.)

Shortly after that first conversation, I started reading “Fearless Change: Patterns for Introducing New Ideas.”  The book describes a pattern or method for helping your change efforts by enrolling a “Champion Skeptic” to help.  In a private moment with the objecting engineer I informed him that he was my “Champion Skeptic.”

Surprise: He was skeptical.

Months have passed and our discussions were more helpful than he knows.  He suggested task card improvements, important impediment removal and improved build processes, among other things.  He also blocked some progress in different ways, but that was the skeptic part.  Most important to me, he helped me improve myself.  I was able to present ideas better and improve my arguments for Scrum and agile practices.  He helped me understand deeper his points, and my own.  And we became more friends than just coworkers.

This week he announced that he is leaving the company for other adventures.  The technical loss of his skills to the team and company will be felt for a while.  The loss to me as Scrum and agile evangelist is also significant.  I now need to find another “Champion Skeptic” against which I can hone my skills as change agent.  I’ll need to find someone to talk straight and cut me down to size when my thoughts and ideas fall short.  Oh, I can find people who don’t “believe” in agile, but one who also provides open, truthful conversation is not easy to find.

Who helps you break the echo chamber once in a while, to see what others see?  Who makes you a better agile advocate and practitioner?