I have seen a common thread all through my career.  A problem experienced seemingly everywhere, at all levels, including with myself.  This problem causes all sorts of dysfunctions and symtoms, from frustration and poor quality to wasted effort and missed deadlines.  It’s a hard problem to solve because most of our cultures, individual to large corporations, are counter to the solution.

The problem is trying to do too much.  A solution is limiting work in progress.

Limiting WIP

Some rights reserved by Tim Green aka atoach on Flickr.com

This is a concept usually connected with Lean and Kanban.  The idea is that work in progress (WIP) is a liability, it is “inventory.” As such WIP represents costs expended without yet realizing value.  Therefore limiting the amount of WIP makes sense from a cost perspective.  And it is more than that.

Problems from unlimited WIP

I have a wife, children, work, hobbies, volunteer projects, church, community events, etc. that I like to participate with.  My ability to pay attention and build any one of these areas suffers if I try to do all of them at once.  For example, my wife dislikes my habit of checking my phone during our date night evenings.  And she is right!

Many companies and even clubs or other groups take on too many things.  For example, that $500,000 contract was too good to pass up, but now the $5,000,000 project is late.  Other effects include:

• Employee and personal burn out.
• Expectations of constant over-time by executives and developers.
• High levels of interruption and context-switching.
• Low quality by taking short cuts because there is so much other work to do.
• Stale features, half-developed that clutter code and minds.
• All the requirements are top priority and all must be in the release or product.
• More meetings to coordinate sharing of people between more projects.
• And many other bad things.

Scrum and unlimited WIP

Scrum teams also suffer from situations of unlimited work in progress.  There are, of course, the issues of interruptions from outside the team and Sprint which are an organizational symptom.  Even if such external issues are not present, unlimited WIP in the team can happen:

• Sprint Planning with stories written such that each team member has stories assigned specific to their individual skills.
• Defining stories that take the entire Sprint to complete.
• No one has time to help team mates with difficulties.
• At the end of the Sprint all or most of the stories are started but few are actually done.

Limit WIP

Simply creating limits on WIP, the number of items allowed to be in process at one time, helps to solve these issues. If I choose my personal projects carefully I can more deeply enjoy the things that really matter. Organizations that discipline themselves to limit work in progress create a culture of focus and urgency.  Teams that “swarm” on stories and make sure Sprint items get done before taking on more work find higher quality, better team cohesion and increased ability to get work done.

How do you sent limits?

Empower yourself and people who you work with to say no.  For example, the VP does not have the right view and information to know if his “little side job” is really as little as imagined nor the knowledge to know how such a diversion will effect the larger projects.  The developer should be allowed to decline and have that answer stick.

Teams need to decide how many stories in a Sprint can be started but not done.  And they need to stick to it, getting things done before starting something new.

Most important, you will find that setting WIP limits will reveal problems.  Stories will not get done and instead of just starting the next story the team will have to figure out and address why current stories in progress are not done.  Organizations will see opportunities go by and will have to figure out which are the most important and what is really needed to support more projects instead of just saying yes and delivering late.  This is all good!

WIP limits are a powerful tool for uncovering places of improvement and finding the correct focus.  Use them, apply them, learn and grow from them.  You really can do more by forcing yourself to do less all at once.

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!

Everyone “Does” Teamwork

Recently I have been participating in the interview process for a technical position.  The opening is on a customer engineering support team.  Another of the participants consistently asks the candidates that well known question:

Do you work well on a team?

If you have spent any time at all on either side of the hiring table, the “team player” or “teamwork” question seems to be a constant.  Every company I can think of talks of teams, creates teams, reorganizes teams and seeks out new employees who will be team players.  That’s because every company says they like teamwork and want more of it.

A Brief Definition

What is teamwork?  I suppose this should be a well known term since every company wants and has it.  Here are a few points that are part of teamwork to me:

• The members of the team works together for long periods of time every day.
• They are aware of what each one is doing from day-to-day and even hour-to-hour.
• Members have no fear of asking for help and many times don’t need to ask, it just comes.
• Members trust each other to do the right thing, feel able to honestly express problems and receive negative content in full assumption of positive intent.
• New work is discussed and planned with the whole team involved.
• If one member fails, the whole team takes responsibility.
• If one member succeeds, that member will praise the team for the work.

In other words, the team is a unit with members providing support and strength to achieve far more than expected.  2+2=∞.

Real Teamwork

There is a simple question to ask that can indicate if a company really promotes teamwork or not.  It’s not a litmus test but a good way to start thinking about true teamwork support:

http://twitter.com/DayleyAgile/status/27293555350

For example: A manager looks at work that needs to be done, decides the individual that should do that work and assigns that task to that specific person.  If that is the usual way of getting someone working on a task, it is questionable that the company really supports teamwork.  In contrast, a manager that looks at work and chooses between several teams for assignment is probably in a company that promotes real teamwork.

A companies actions are what creates culture and the values, not words in a slogan or questions in interviews.  The everyday actions while doing the work have to reflect the values.

True teamwork is powerful and fragile.  If teamwork is important, act in ways that re-enforces and champions them!

Slides

This presentation is the first I have posted to SlideShare, an interesting experiment of itself.  Please have a look:

Questions

At the end of the presentation and after the presentation time, two smart people had some interesting questions.

Question 1 – When the client is expecting to know when it will be done and how much it will cost, how does a provider using Agile respond?

Dallin Harris of Skyhook Internet Marketing brought up this difficult topic.  Agile practitioners everywhere work at the difficult balancing act of providing the information the customer wants and educating them to understand the benefits of Agile iterations or sprints.

We discussed the finer points of productivity, such as always working on the currently most important feature, delivering finished parts as they are done at each sprint end and the ability to stop before every possible feature is created if the current version is enough.  We also found a direction point to the Product Backlog and how it feeds a release plan for the client to interact through.  I pointed him toward Mike Cohn’s excellent material around estimating and planning.

Question 2 – How do we get team cohesion if the Program Managers are assigning tasks?

David asked this question about a common problem in an organization transitioning from a more traditional structure.

The short answer: In such an environment, cohesion on the team is not possible.  Or, at least, it’s very hard!  When people in authority direct individuals on the team, the team cannot self-organize.  And, it’s not Agile.

We discussed how David needs to help the Program Managers direct desired work per team instead of per individual.  This has many benefits to the team, the Program Managers and the company.

• The team has a chance to become self-organizing.
• The team members are not wondering what they will be doing next, as they have a full sprint to work the plan.
• The Program Managers will see completed work sooner.
• The Program Managers will drive the company to ensure it is working on the most valuable features and projects first, providing focus.

These are the things David and I discussed.  I wish him well in his quest to increase agility where he works.

Twitterings

After the event I finally had a chance to look at my phone.  The mentions on Twitter had exploded!  That was very gratifying and I thank you all for the attention.  In particular, Bold Avenue was in the audience and live tweeting many of my significant points.  (Thank you, Stephanie!)

A great experience.  I learned a great deal and hope the community enjoyed my small contribution.

This Wednesday, March 24th, I will be the featured speaker at the Brown Bag session. I’m very excited to give and get some education with the Phoenix creative and small business community! My presentation will be:

Business Benefits of Being Agile

Agile practices such as Scrum and Extreme Programming are touted as a way to improve software development teamwork and their results. There are benefits to the business in and out of the team that are not always obvious at first. I argue these benefits are large enough, any business should jump to apply Agile any way they can!

Please come participate in the discussion. I’m sure you will enjoy it!

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!