Recently, I was coaching a team that was relatively new to Agile. We were in a planning session and it was obvious to me that something was bothering one of the members of the team. During a break, I went up to this person, told her my observations and asked her if everything was ok . She responded simply by saying, "I can't wait to get back to my real work."

This is not the first time that I have heard this statement. I have actually heard this for years even before I had ever heard about Agile practices. No matter what activity was taking place - company meeting, team meeting, requirements gathering, design meetings, training - I would hear similar sentiments echoed from someone.

This statement used to not bother me, as I figured that the person making the statement just didn't want to participate in other meetings. However, since I have learned the Lean principles of providing business value and eliminating waste, these kinds of statements bother me much more. Clearly, the people making statements like these believe the activity is a waste of their time. As a coach (and former manager), I see at least some business value from these meetings. My reaction to this train of thought is to ask myself a few questions: What is the definition of "real" work to this person? How do I help this person have a new definition of "real" work that is based on providing business value?

I don't blame the individuals that feel this way. It's not their fault that they have been conditioned by their organizations (past and present) to think about their work in this way. As with many things I don't understand, I try to see things from their perspective. I have come to the conclusion that if they were doing everything possible to be successful with their work, then there are problems in the system (the system being the processes, flow and structure of the organization). Going back to my example, the woman from the team that I talked to was a developer. When asked, she felt her "real" work came down to two activities: coding and testing. She felt meetings were for other people, mostly managers, and that she rarely got anything from attending those meetings.

There are several reasons why she could feel this way:

• She is measured by her level of activity. Management tends to measure productivity by the amount of time spent working at your desk. For example, a standard metric is software is "the total lines of code produced." If you know that your next promotion or increase in pay is going to be based on lines of code, what will you emphasize? Cranking out lots of code, of course! Anything else - meetings, planning, requirements and design - will be considered as wasted time, taking you away from being "productive." In fact, you may even de-emphasize quality and sustainability in favor of producing more code. Activities such as automated tests, refactoring, continuous improvement, and continuous integration would be compromised or forsaken because it keeps you from writing more code.
  
  The maxim is always true: you get what you measure. If people are being measured by the wrong things, they will likely produce the wrong things.
  
• She is more comfortable doing some activities over others. In school, developers are taught programming languages and whatever else is necessary to start coding. They tend not to be taught estimating, planning, architecture, analysis, or design to the same level of detail. They may gain this other knowledge over time, but most training is concentrated on the coding aspects of the job. Therefore, individuals often shy away from activities that they don't fully understand or know how to do. And, if she's going to be held accountable by how much code she produces, why should take the time to learn these other areas? Even worse, she may fear that revealing that she does not know something may end up hurting her career. Comfort and fear keep many of us from progressing.  
  
• She likes these activities more than others. Most developers prefer coding more than any other activity. Testing may not be as fun, but it is known to be useful. Everything else comes in a distant third... they are just not as interesting and not seen as helpful in achieving the prime metric.
  
• She sees other activities as wasteful and pointless. This could be because there are too many meetings that seem to go on forever without focus or measurable results. If she sees her work by how much code is produced or how many test are written, then these meetings will be seen as very wasteful. 
  
• She may not understand how these meetings can help her and the team be more effective.  She may feel fully capable of receiving high-level requirements and going back to using them on her own. However, what does this do for the rest of the team? Even if she is able to accomplish this with good quality and minimal rework, she is hurting both herself and the team by not sharing the knowledge of how she got to the solution. By not sharing this knowledge, she may be missing some requirements and design approaches by looking at other perspectives. After all, four eyes will see more than two.

Based upon these thoughts, as a coach there are several things I can do to help this person see where the real work does exists:

• Measure and reward people based on value delivered rather than just on work accomplished.  With Agile teams, the focus needs to continually be on delivering value through the completion of stories. Using that as the goal, management needs to create new metrics to assess the value that is being provided to the business and reward performance accordingly. 
  
  • Many teams do this by looking at the team velocity: the total story points that the team was able to complete after each iteration. The higher the velocity, the more story points completed and the more value is delivered to the business. 
  • Another measure is to look at quality and waste by measuring the amount of time spent on rework and fixing bugs. Over time, this should trend down while velocity should increase or at least become consistent and sustainable.

Management can set goals for these measures and then reward the team for meeting or exceeding these goals. If this is done, individuals will begin to realize that they need to figure out how to better work within the team and the focus is then on the team's success in achieving their goals.

• Train and coach on other skills necessary to achieve value. Developers need to learn new skills - how to plan in iterations, how to create stories, how to estimate in story points, how to develop tests. Some may already know how to do this, but managers cannot make that assumption. Additional training and coaching can accelerate the knowledge and experience needed for each member of the team to be effective and a solid contributor to the team. Individuals then can gain the confidence and see positive results that will motivate them to want to participate in all activities without hesitation.
  
• Talk in terms of business value verses waste. Teams can fall into the trap of thinking that they know better than the customer or the business. This is very dangerous territory because it can lead to much rework if the assumptions made on behalf of the customer or business are incorrect. This is essentially gambling on the company's money. Let the business people understand the business and communicate the value to the business or customer to the team. Once that communication has been provided, the team needs to keep focus on that business value. There are many decisions the team has to make on a daily basis and, if they are to make some of these decisions themselves, they need to continually think about and understand business value. If there is doubt, the team should talk to those who would have a better understanding of the problem. Equally as important, everyone should look at activities that are not contributing to the value and find ways to reduce or eliminate those non-value activities or waste. This can include time fixing bugs, processes that are too heavy and cause the team to slow down, meetings with everybody invited (though only a few need to be there).
  
• Make sure that all activities that are producing value are not wasteful. Once there is an understanding of value versus waste, it is possible to look at the entire process flows of the organization. Through value stream maps you can determine how wasteful those processes may be. When first time organizations go through this exercise, they are very surprised how much waste is present as well as misunderstandings throughout the organization on how things work. Most of all, these value stream maps are now in the perspective of the customer and how responsive the organization is to the customer. Companies that can do this effectively will have a competitive advantage in the marketplace, a focused engaged group of employees, and very satisfied customers.

In the end, the most important work is that which provides the most value to the business at any particular time. Everybody in the organization needs to understand this concept and look to maximize business value while reducing waste. This requires an understanding of Lean principles that go beyond what many Agile teams learn.

Bood Recommendations 

To learn lean principles and how they apply to software, a good place to start is to read Mary and Tom Poppendieck's books:

• Lean Software Development: From Concept to Cash
• Lean Software Development: An Agile Toolkit