What I got back surprised me. I was told that making commitments to customers was the only measurement that matters. Commitments at the sprint level were not as important. While this is understandable, it is not useful at the team level.

I realized that there was some basic misunderstanding going on. It clearly involved the word commitment and this is what David and I are exploring.

A commitment is a kind of promise BY someone TO someone. Let’s use that definition as a template, and consider some definitions crafted with Scrum terminology.

The first commitment we consider is the outward facing commitment to the customer:

Customer Commitment: a promise by Product Owner to Customer to deliver known feature(s) in a product by a certain date or event, often termed a release

This definition seems pretty clear to me. The customer may use this promise to reliably schedule other commitments, so our organization must be sure we can meet this commitment. In Scrum the product features are the responsibility of the Product Owner, so only the Product Owner may make the Customer Commitment.

The Team Commitment, on the other hand is made by the Team to the Product Owner:

Team Commitment: a promise by Team to Product Owner to complete selected Stories (Sprint Backlog) in Sprint

The definition also seems pretty clear to me. In this case, the Team is telling the Product Owner what they expect to complete given their average velocity. In 50% of the cases, they will complete more Stories, and in 50% of the Sprints, they will need to negotiate to move some Stories out of this Sprint before the end of the Sprint.

Did the confusion in my conversion with the executives arise from the two distinct uses of the word "commitment"? How do these two uses of the word "commitment" relate?

We will explore this further in the next post.

Unfortunately Bill Ives is no longer able to add his expertize to our blogging efforts. His absence has been missed since he was a strong catalyst for me to write both through his interviews and regular pestering!

Recently an old friend of mine and past colleague David Socha and I have been collaborating on various topics related to software agility. David and worked together at Rational and also at QuickSilver during my time in Redmond, Washington. We have also collaborated in the past on the role of design in software. I am enthused about our working together again.

I have asked David to add some biographical information which I am sure he will do when he has a few moments. After all we all know how much time we all have!

Welcome, David!

You can see the Webcast yourself by visiting: http://w.on24.com/r.htm?e=155782&s=1&k=A98F0FB3D0AD7D354E60F0C65DB31BB7

Here are the questions and answers:

Question: What if the business process isn't defined how does Agile handle business reengineering?

Answer: When the business process is not defined, an agile approach provides an incremental model to explore and define it! Using Scrum for instance, you would work with your Product Owner (customer) to elaborate user stories that define some aspect of the business process. Don't boil the ocean. Pick a small "chunk" that can be easily described and understood. If the end goal is to have a system that is implemented using software, then you should strive to implement this process as well. To the extent possible, this should be accomplished in the same sprint. Avoid using the sprints to only document the process. Your goal should be to produce working software as early as often as possible.

Q: Thanks for this presentation. One issue we struggle with is using scrum teams that do all of the things you are describing but we have trouble bidding competitively on small professional services projects. There is some overhead with scrum when applied to smallish projects (lasting 2 - 6 weeks) that we struggle with. If you have any suggestions or examples for how to insulate the customer from our internal costs of using scrum on small projects I would love to hear it. We've been using scrum for about 4 years and it works great for our product team. Any thoughts you have would be appreciated.

A: When using Scrum on professional services engagements, we highly recommend giving your customers visibility (and getting their buy in!) to the process you use to deliver the requested features. If they've agreed to the approach, then this should minimize the impedance mismatch and associated overhead costs for spinning up the project. Also, try and keep your teams together. Remember, with Scrum, we focus on building and optimizing teams. If your building up and tearing down teams for each project, this will certainly introduce overhead and also decrease the predictability of teams velocity as it can take up to three sprints for a team's velocity to normalize.

Q: Which is more important between Individuals/Interaction and Processes/Tools? What I should do if my team members do not have cross-functional skills?

A: In agile we always favor direct communication. Whenever and where ever possible get people in a room together hashing through the problems and issues. The reality of "agile in the enterprise" is that teams are distributed by time and distance. This is where tools are essential in enabling team collaboration. When teams are first formed, its common that there is some specialization of skills. This moderates over time. Pairing, an extreme programming best practice, is an excellent tool to use to help cross train team members.

Q: How can you help a large, compliance-oriented, traditional development organization move to a more agile approach without jumping all the way into Scrum?

A: If you don't have expert help on staff, we recommend getting help with the organizational change management issues that you will deal with in adopting agile. That is why Serena partnered with Valtech, a leading provider of Agile transformational services, with our Serena On Demand product.
Also set it up for early success. Identify a few of your best teams that are starting up new projects. Plant an experienced agile coach on the team, get them norming and storming. You'll be able to use the experience from this team to seed (and motivate) others.
A tool like Serena Agile On Demand helps as well. It provides a prescriptive Scrum framework for the teams to follow.

Q: What tools to you offer to facilitate yearly budgeting and goal setting in a way that could feed into incremental deliveries while supporting financial accountability within key cost centers?

A: The "team" is the key unit for agile projects. We want to fund teams and keep them stable for as long as possible. This allows us to optimize predictability. So you want to fund as many teams as possible, keep them together for as long as possible, and bring the work (projects) to them. At the portfolio level, its also helpful to consider relative investment levels for key initiative requested from the business units. This will dictate the mix of projects that you direct to the teams.

Q: Can we implement these tools based on traditional methods and then seamlessly transition to agile?

A: No. Adopting agile has significant impacts on the people and processes within an organization.

Q: How does this approach handle complex systems integrations with third parties and systems involving end-to-end financial settlement processes such as GL posting.

A: This is hard regardless of whether your following a traditional or agile approach! When we scale agile, we typically have many teams collaborating on a single appliation/product/service. The integration of the work developed by these teams of course needs to be closely managed. From a program management perspective, we can use the "Scrum of Scrums" to manage the inter-dependencies between teams and other cross team issues. We can also use the "Super Scrum" as longer range product planning tool to make sure that work is appropriately sequenced so that cross team dependencies will be satisfied.

Q: What if the business perception is that small, incremental releases do not generate adequate business value to warrant business change, training, and communication required? Can this process handle small internal increments that culminate into large releases?

A: Absolutely. Agile (and Scrum) are based on incremental approaches that produce potentially shippable code. Whether or not the increment is shipped is a business decision based on product, market, and customer readiness.

Q: (Loaded question) What if the user stories to be delivered in a sprint get delayed, and the spring demo cannot be completed on time?

A: We love loaded questions! The duration of a sprint never changes. If a story is not completed, its not accepted and not delivered as part of the sprint. The story will either be returned to the product backlog or moved into the next sprint.

Q: How is Serena differentiated from competition (such as Rally)?

A: Serena Agile On Demand was built from the ground up to deal with agile at the enterprise scale. Multiple teams, multiple releases, multiple products. We offer unique capabilities in our ability to deal with enterprise complexity. Serena Agile On Demand comes fully loaded for prescriptive Scrum development. While complete in its ability to deal with Scrum, its hyper-configurable to meet your specific needs as well. Serena Agile On Demand not only delivers the product features as a service, but it also delivers on demand agile coaching through Coach Live in cooperation with Valtech.

Q: How can the tool support allocating planned resource capacity to specific initiatives while allowing freedom from scrum masters to manage specific task assignments for team members. Need to measure that actual utilization is not exceeding targeted resource allocations.

A: A major difference with agile approaches from traditional approaches with respect to resource management is that the team is the unit of planning, not an individual resource. We try and put cross functional teams together and keep them together. The team then establishes a velocity - basically the amount of work they can complete in a sprint. Once the teams velocity is established, the team commits to deliver the amount of work that matches their velocity. Agile teams are always looking for ways to optimize their throughput (increase their velocity). This is contrasted with traditional approaches where management attempts to maximize utlization.

Q: Can the Agile On Demand task board be customized to reflect custom statuses ("swim lanes")?"

A: Yes. The swim lanes in the Card Wall are completely configurable.

Q: Who selects scrum team

A: When making a transition from traditional methodologies to SCRUM we think it is a best practice to "invite" members of the team to join the SCRUM. It's important in the early stages to get enthusiastic members on the team who will actively engage and support adoption. Hard to get people like that if they are 'forced' to be on the team.

Q: Since agile / scrum utilizes an Empirical model for managing costs, How can management make an assessment of the total cost of the program in order to fund development.

A: Plan the work as far as the release horizon using coarse grain items. Have the team size the items using rough estimates. Use historical information from the team's activity or make an educated guess about how much work the team can do in a sprint. Determine the cost of a team for a sprint. Calculate how many sprints you need to finish the work in the release. This gives you the estimated cost to complete the work. You'll need to use scope negotiation skills to prevent "scope creep" and decrease the priority of low priority items. You'll also need to recognize that as the software is developed, changes will occur (which is a good thing -- you'll find that what you wanted at the beginning isn't what you need) and trade-offs will have to be made.

Q: I manage a small unit responsible for several projects. Some were started over a year ago and were designed to follow waterfall. Subsequent projects are now developed via Scrum Agile method. With at least a year left on the waterfal project, how or should we switch mid-stream to agile?

A: It is fairly simple to switch to Scrum to manage your work. If your waterfall planning resulted in a pretty gantt chart with tasks, you can use them as the work items in your product backlog. Read up on Scrum and get a certified scrum master if you can.

Q: Have you ever heard of ACTUAL customers (in addition to product owners and PMs) participating in a sprint review? Any ideas how this could be implemented? Thanks!

A: Absolutely. This is done quite frequently in fact. If possible invite the customer to attend in person. Otherwise their are many virtualized meeting tools that can be used quite effectively.

Q: Could you expand some on non-product stories, how they get prioritized since the product owner may not care, how you track those vs. product user stories in metrics, etc?"

A: Pay me now or pay me later. Sometimes the team has to go slow for a few sprints to go faster in future sprints. There are many examples of non-product stories where technical debt is addressed that may not result in direct value to the customer. This is where the team and the Scrum Master must lobby and compel the product owner to include these stories into a sprint. Without this balance, an insurmountable amount of technical debt will build up.

Q: Is Serena overkill for a team just looking for a requirements/project management?

A: No, not at all. Serena's Agile On Demand has the ability to manage many types of backlogs and is ideal for requirements/project management. Internally here, the Marketing department has several teams actively sprinting and using Agile On Demand to manage projects and requirements. Multiple product backlogs, about nine is our case, contain stories for different projects the team is working on, each managed by a separate 'product owner' (usually a Product Marketing Manager). Then there are separate TEAM backlogs that contain the sprints and cross functional teams of marketing types who all contribute to the completion of stories with the project backlogs. The benefits of have a team manage requirements this way include time management, capacity planning for the sprint and minimizing the randomizing effects of fire drills.

Q: How did you convince your managment to use XP?

A: XP is a collection of best practices that increase the likelihood a team will deliver running tested features that meet customer needs in a predictable and repeatable way. Surely management can see the value in that result? ;-) The book "Extreme Programming Applied" has a good discussion of this. Also see the discussion on the c2 wiki: http://c2.com/cgi/wiki?WhyItIsSoHardToSellExtremeProgramming

Q: So, Product Managers can equate to Business Analyst in a traditional organization and Scrum Master is played by Project Managers?

A: The Product Manager's roles and responsibilities align quite well with the Product Owner's. BUT, the approach they take to elaborating requirements and engaging with team varies significantly. A Project Manager can be a Scrum Master, but be cautious. Project Managers are typically in a top-down command and control roll where they plan and dictate to the team how to complete work. A Scrum Master is a passive leader that facilitates the team. The Scrum Master coordinates meetings, interfaces with external teams, and manages the impediments that the team can't resolve themselves.

Q: How do we handle Standup meetings for geographically distributed teams?"

A: Tools are essential. Use planning and collaborations tools like Serena Agile On Demand and Virtual Meeting tools.

Q: What estimation method do you use from sprint planning?

A: We use story points with "unit-less" value. Our teams use planning poker to estimate sizes. There is an interesting video of it's creator talking about it here: http://www.youtube.com/watch?v=1oIaz7aZsno&feature=channel_page and more info on this site: http://www.planningpoker.com/

Q: Would you recommend adding to the backlog a "regression testing" item?"

A: Using stories to manage work that is difficult to complete or track can work well. If the team is having trouble doing regression testing in a predictable way during the course of a sprint, using a story is recommended. If the team does a consistent amount of regression testing every sprint, you could instead consider it "overhead" and choose not to track it.

Q: is serena agile license per user based?

A: Yes. $35 per user per month.

Q: Where would a Business/System Analyst fit into the Scrum team/role

A: Often times we see Business/System Analysts as part of the Scrum team in primarily a Product Owner role.

Q: IS a user story different than a story board. Or is the story board where you post all the user stories for selection?

A: The card wall (story board) is a technique for showing stories and their current state in a single view. It is typically used to manage the state for stories in a sprint.

Q: Where is the current "high-bar" for portfolio management across an enterprise for full Scrum methodology used on across large teams of developers? Team size of 500 + developers? 800+ developers?

A: 1000s of resources.

All good training for agile methods include liberal amounts of experiential exercises. I was first seriously exposed to this approach when I studied with Jerry Weinberg. He called them simulations and from him I learned how precise in terms of teaching objectives they can be. Luke has taken this to even greater levels and he uses the more currently politically correct term, game, to refer to this type of exercise. These days when agile trainers gather together they often share games they are using and practice on each other.

In my view the power of games is that a well designed game will engage more of the our capabilities. Some games get the body involved - somatic involvement. We know that learning for most folks is enhanced when the body is more involved. Some games get both sides of the brain involved - right brain (random, intuitive, synthesis, subjective, wholes) as well as left brain (logical, rational analytic, objective, parts). We need both modes to solve complex problem in new ways. Some games encourage our emotions to play a more active role. Our passions can be expressed and utilized.

As we discussed in the workshop, a current constraint on successful agile projects is the difficulty of writing those stories that are the work to be done. Scrum books assume that they exist. They don't.

Surprise, surprise. For over 40 years from the engineering side I have heard 'If we could just get good requirements we could '. Typically blanks are 'Take less time', 'Have fewer bugs', 'Deliver what is needed', 'Cost less' or 'Get the design right'. This problem has not gone away. And agile has never promised that it could fix this problem. Well executed agile only promises that engineering can reliably deliver what is asked for at a known quality level at a known time.

The short time box aspects of agile allow more in-course correction to be made based on what I think of as reality based feedback. This behavior gives the impression that 'requirements' are better. That is not true. Agile projects can produce bad products faster and more reliably than more traditional techniques.

Innovation Games® as we learned them are a set of tools that can seriously help with the difficult problems of where the product is going. We experienced the ease and FUN that can be experienced as difficult problems are addressed relatively quickly and innovative potential solutions are discovered. High level plans such as roadmaps can be addressed with these techniques as well as prioritization of high level backlogs. Filtering the infinite world of the possible down to the practical world of the doable.

Some of the games are now available online for distributed teams and we got a chance to play one of them. An impressive beginning to a difficult problem.

I was impressed.

It is good and it is not long. It is a very readable compendium of 86 patterns with a couple of ‘interludes’ to break things up. The patterns are in a short, fairly informal format of some two to six or seven pages. Each describes a way we operate or operate in organizations. There is some gentle discussion of details. And an even more gentle treatment of those patterns that are judged less than ideal.

The book supports achieving a goal of mine for all teams and individuals on those teams: Becoming more conscious of the work that we do and more conscious of the relationships that we are in as we do that work. The patterns are presented as a way to think and reflect on how we work together. Some are more technical, some are more relational, and some are individual.

The names give many of them away: Face Time – about talking together; It’s Always the Goddamned Interfaces – exploring the congruence of teams and components that they build; Sanctity of the Half-Baked Idea – notices that if only ‘good’ ideas are allowed the great ideas are more difficult to find.

I recommend this book. Enjoy it one small bite at a time.

P.S. As I was reading the book I found myself wanting to score myself and score my current job situation. How was I doing? How were we doing? What was our Zombie Score? Perhaps the authors can provide a simple spreadsheet and do some analysis. If the Zombie score of an organization is good, are they more successful?

Tobias Meyer writes the blog, Agile Thoughts. He is one of the most interesting trainers that I know. He is very opinionated. I know him personally and really enjoy being around him. I have learned a lot from him. Tobias is always very thoughtful and I really respect his opinion. He is particularly interested in the games we play to help people learn.

Mike Cohn writes the blog, Succeeding with Agile. Mike is a classic and was on the Board of Directors of the Scrum Alliance for a long time. He has written some of the best books on Agile. He is very strong in what he believes Scrum should be. I have trained with him. I enjoy being with Mike a lot and he is very knowledgeable. He has thought out a lot of things and is not afraid to make controversial statements.

Ken Schwaber writes the blog, Edge of Chaos: Edge of Chaos, Agile Development Blog. He is the man who put Scrum on the map. He went to conferences starting in the mid-90s and talked about Scrum and learned more about it. Ken co-wrote the first book defining Scrum and is the “father” of Scrum in a sense of getting the word out. He put together some of the first training programs. Ken is still active. I see him about twice a year at the Scrum gatherings.

John Scumniotales writes the blog, Agile Product Development. He was on the very first Scrum project, which I also had the pleasure of being on. John was, in essence, the very first Scrum Master. He is now a VP of Engineering at Serena Software. He is taking Agile up through the enterprise. He has been very concerned with how to bring Agile practices as you move up the management chain. We have disagreed at times but he has thoughtful articles about his experience, more on the management or executive side of Scrum. I read his blog fairly often.

Jeff Sutherland writes the blog, Scrum Log. He was the intellectual founder of Scrum. He did all the research with the Japanese. He was the CTO of the first Scrum project that John Scumniotales and I were on. Jeff is a very interesting fellow with two MDs. He was a fighter pilot in the Korean War. John is full of energy and goes around the world training people in Scrum. He is constantly pushing the boundaries of Scrum. You should read his articles about red and blue Scrum. He has said that if the project team does not have a velocity in place after two or three meetings you should disband the team and start over again. I think of what he does as tough love or “tough Scrum.” Jeff is a great guy who always listens carefully to what you have to say.

David Anderson writes the Agile Management Blog. David is from the Lean thinking approach and I find him very interesting to read. He has a lot of good ideas. He is very much into measurement and its effects on projects. Lately he has been chatting more about Enterprise Agile and more focus on Lean.

Corey Ladas writes the blog, Lean Software Engineering. I do not know him but I find his work in Lean very interesting as we bring the Lean practices more directly in front of the Agile process. Clearly Agile and Lean are closely tied together. Corey makes this very explicit.

The Agile Advice blog is subtitled Working with Agile Methods (Scrum, XP, Lean). I do not know this writer but it is a blog I saw that I liked. I thought it was interesting and wanted to include it.

Agile work management is about orienting people to make the right work at the right time. I sometimes think of it as the TIVOing of software development. We are timeshifting work. You wait and do things at the right time. Ward Cunningham, the inventor of the wiki, talks about only doing what you know. Don’t do what you don’t know. This is a critical quality in how we experience development in Agile.

A clear prerequisite to being able to do this is quality engineering practices. We have discovered that many organizations do not have a clear understanding of this. Now quality is a fairly broad term. It can be interpreted in many ways. People say, well, of course you need quality engineering. And I have a specific take on what I mean: a quality of correctness. It is correct.

It is little things like the code works and it continues to work. It does not have bugs in it. The code actually fulfills the purposes for which it is intended.

It is finished. Sometimes the code never seems to get done. There are always some bugs associated with it or the documentation did not quite get done.

And we have experience with this. It can be achieved. The project I mentioned in the post, Achieving Immediate and Continuous Bug Fixes in Agile Development, is an example. Because we wrote with sufficient unit tests, because we had good automated integration tests, because of a 100 regression test way of thinking, and because of continuous integration that ran these tests, when we finished a piece of code it was done and there were very few bugs, never more than 5 at one time for the entire project.

Now this does not mean that we had all the features you might ever think about. In my mind that is the trap we fall into. We say: ‘Oh, that feature should do X and Y should be done in a different way.’ That is not what I mean by done or quality. Quality means that the system does what you want it to do at that moment in time. We take small steps and make sure that each step is done in a quality manner.

Later, you might add some different features or change features to respond to market pressures, better ideas, customer input or other conditions. However, when the new stuff is put in, these additions also have the quality of correctness.

This requires good engineering practices. It is interesting to consider this because what happens is that the teams that achieve this way of thinking/acting with their code are very productive. They feel better. It is fun to be around them. They are always thinking about new things because they do not have to think about the old things any more.

The social side is that they are more willing to try new things. It means that there is more innovation in the products. They know that if something is done it will be quality or they will just take it out.

I see Agile being like the train running down a well laid set of tracks, constantly moving forward on a solid foundation. When the foundation is kept strong (the attitude and practice of quality) the train can easily move. As you go forward everything is working and you are just advancing. More alignment is naturally achieved.

In fact we use the term release train to refer to a particular way of deploying software on a regular basis. It is this feeling. You are on an engine that is running and you drop new requirements in as you go forward and working functionality comes out the other end.

This causes some other issues. At times, developers never feel they are done. So we need to address this human need for accomplishment and build in pauses, vision setting, and reflection to address this human need. You need to have the team take time to stop and look at their accomplishments.

This means that way down deep inside the team has good tools and a good sense of what testing is. The developers know what good design is and how to recognize it. They know how to change the design if the requirements change. Extreme programming really pointed the way to achieve this quality. If you do not do this then Agile becomes just another process that sort of works. The old ways come back: schedules slip, bugs proliferate, morale declines.

I wanted to discuss quality engineering because it is important for people to understand that Agile is not just about making short iterations. An attitude of quality is important. It is an old software adage to get the best people you can. Here we are suggesting that the best people as those who know quality engineering.

Bill: Is this problem because Agile was initially done for small projects and now it is being used for much more. Or is the problem that is especially acute because Agile focuses more on people issues than traditional software development methods.

Jeff: Both. I think the people issues are more acute in Agile. Before Agile, we tended over the years to do things like rank ordering all the people in the organization through an evaluation process. We have known companies that have literally fired the bottom ten percent of people once a year.

Bill: Of course that encourages everyone to stab their neighbor in the back.

Jeff: Right. It has particularly bad consequences on Agile because Agile is a team sport. If you are always throwing out a person on the team there will be jockeying around this. So if Agile is a team sport how do we measure and help people with evaluation and growth?

To address this concern, we put together some guidelines on this for Agile that people have used. I do not claim to be an expert in this area. There are a lot of trials going on.

Here are the guidelines I recommend. For an individual I think about half of their evaluation should be based on how the team is doing. So we need some metrics on how the team is doing in terms of being an Agile team. We will talk about this in the another post but let’s assume that it is possible to implement.

Bill: So half of an individual’s performance measurement is based on the measurement of their team?

Jeff: Right. Now if you have lot of people in an organization that are not part of a team but just floating around, of course this does not work so well. We prefer when doing Agile to get people on teams and leave them there. The team dynamics are the difficult problem. The difficulty is not the coding, it is not the work people are doing. It is the team dynamics. In Agile we are suggesting that the team is the right unit to think about planning and execution, not the individual. Hence a team evaluation is an important component of an individual evaluation.

So let’s assume that you can evaluate teams. This leaves the other 50%. I think half of it (one quarter of the evaluation) should be on how that person is perceived by the team. So the team gets some say on how you are doing. Sometimes we see a situation where a team does not like working with a particular person. We have been in places where a team says we don’t want this person on our team. If we find a better place for that person a win-win situation occurs.

This indicates a level of team maturity that does not always exist. Teams need to know themselves and be able to talk openly to make such a conclusion. And, of course, it has to be handled well. But it is possible. Once, we took a team member off a team and its productivity instantly went up by 12% because this person was slowing the team down. His work was fine so I want to be clear that this was an issue of team dynamics not individual capacity. It does mean that you want to fire the person but they need to be on a different team.

The analogy I think you need to look at is the sports team and watching how people move around. Look at how some people work well in one team and not in another. This is a people issue.

Bill: I was about to mention sports earlier because in many sports situations, more so than business, the individual team member’s evaluation and their monetary rewards are based on team performance. Do they make the playoffs, etc. Someone is not considered a real MVP unless the team does well. We certainly experienced this in Boston when the Red Sox got rid of Manny Ramirez, one of the best hitters in baseball. The team did better because everyone on the team, except one, voted that he should go. Maybe they were being like a mature Agile team.

Jeff: Exactly. The team is trying to figure out how to be a better team. Team balance is very important. Sometimes the team needs a star to disrupt the balance and inspire them to do different things. Teams tend to know this more than we give them credit for. Managers think they know what is going on but the team often has better knowledge about this. Of course, good managers understand this.

So half of an individual’s evaluation is how the team does. A quarter of the evaluation is based on how the person is viewed by the team. 360˚ evaluations are a pretty classic way to do this.

This leaves the remaining 25 percent. Team member usually have an area of technical or functional focus. They might be in documentation or development. So we expect that this last 25 percent should be based on their growth in their functional areas. You can set goals for each person, such as learning a new computer language or a new technology. Some companies get pretty formal about this with classes and credit. Thus, the last 25 percent of an individual’s evaluation should be about their functional skills and if they get better.

Bill: I think one of the keys to success relates to something you said earlier. These measures cannot be comparative. You should not rank people based on the individual measures so it is not competitive. It takes out the competition. It has to be normative rather than competitive. Everyone can get an A if they deserve it.

Jeff: Exactly. Otherwise you cannot get a high performance team to engage in making the team succeed.

In looking at team dynamics, a lot of people have been exposed to Myers Briggs personality profiles. A lot of companies use this and many people know their ‘type’. Myers Briggs is very popular and the most widely known of these methods. Myers Briggs asks questions about how you are, how you function. If you are an introvert you tend to think before you speak. If you are an extrovert you tend to speak before you think. Teams that learn profiling such as Myers Briggs learn that different people function in different ways. Team members need to know this. As an example, if you have an introvert on a team you learn you must give them a chance to speak. If you make decisions at a team meeting too quickly it can inhibit the introverts from speaking.

Bill: There is the method of not letting any one speak twice until everyone speaks once.

Jeff: Yes, that does it.

In another method Kathy Kolbe is asking different questions. The main question she is asking is ‘what makes you want to do something?’ What motivates you to come to work? It refers to the will to act. Her classification includes things like starting new projects or being a follow through person. Do you like to complete things? Do like to be a fact finder? Do you like to have all the facts before you move on? Or do you like to make things beautiful?

Alaska Airlines uses the Kolbe method for their employees. On each employees badge there is a graph of their Kolbe metric. People use this. Kolbe suggests that better teams are balanced. We need some quick starts to ge going but if the team does not have any people who finish things the team will have difficulty completing anything. I have found Kolbe much more useful in making sure teams are balanced with the right mix of people to start and finish things.

The work Kathy Kolbe did came out of the skunk works projects from several years ago. The skunk works were a team concept that was developed at Lockheed as a better way to make planes. The U-2 and Sr-71 were both developed in this way. (They were very Agile!!!) Soon Skunk Works became very. In practice some worked and some did not. Kolbe looked at this. She discovered that a lot of these teams would get started quickly as they attracted a lot of quick starts but then no one on the team wanted to finish things. And they did not finish things. We would prefer our teams to finish things.

To summarize:
50% Team performance
25% Team evaluation
25% Individual growth in functional area
_________________________________________________
100% Individual evaluation

Bill: So what are the differences between these three approaches and why is this an issue for some people? What are some of the questions you are hearing?

Jeff: Well, for one, some people see these as contrasting flavors of Agile. They ask which one should we use, for example. These are different aspects of Agile but they do not operate at quite the same level. Asking which one to use is not the really right question.

My view is that these three all relate to Agile but represent different focus points. At the most granular level, Extreme Programming or XP is the one that caught attention first. It is targeted toward individual team practices. It is mostly about what individuals do to improve their development practices such as Test Driven Development, Refactoring, Small Releases, and Simple Design. XP also describes other practices that the team can use to improve its function such as the Planning Game, Daily Stand Ups and Collective Code Ownership.

Since Agile mostly started with individual teams, Extreme Programming was very valuable to them. It taught people a lot of things that are now not seen as radical as they were when they first appeared in the early 90s when XP became visible. So things like test driven development, continuous integration, and refactoring are not seen as very radical … now.

Many people use these three techniques whether they are doing Agile or not since they promote good engineering practice. One of the ways we have seen Agile fail is when it is implemented on top of poor engineering practice. This was not the only thing XP did but it was its major focus.

Scrum predated Extreme Programming in creation but not in terms of popularity. Scrum is agnostic about team development practices and assumes that you have good ones. It is more concerned with work management and team dynamics. XP does have things to say about team dynamics but Scrum is a little stronger on them.

Bill: How is Scrum stronger?

Jeff: It is stronger as it puts in place some behaviors that were not explicitly called out. For example, in retrospection, that we discussed before, the roles are more clearly defined in Scrum than XP.

Bill: Is Scrum a more articulated and defined Extreme Programming? Is it taking it in new directions?

Jeff: No. Scrum, as defined, actually doesn’t say anything about software. Scrum is about work management and team dynamics that can be used in non-software projects. Most people use it in software development and books refer to it in this way but Scrum does not call out any specific software practices. XP, in contrast, is very specifically for software development.

Scrum did not take any of the Extreme Programming practices except the daily standard meeting. It is targeted at a different place, for the management of work and team dynamics. Because of this it has things to say about scaling to larger teams while XP is quiet about this.

When you get even larger in the enterprise then Lean starts to come into play. Lean is a lot like some of the Six Sigma work in that Lean is looking at reducing waste and looking at ways to eliminate unnecessary work, value chain analysis. Scrum teams often use Lean thinking to improve the management their work and that has some interesting implications.

Bill: So if I understand you, it is really a layered situation.

Jeff: That is how I think about it and yet there are things that cross continuously. Lean concepts are useful on any Agile project. So, in fact, I see Agile projects which use all three.

Bill: Extreme Programming started down in the trenches. Scrum is there at the next level at the team leader or supervisor level. Then Lean goes up another level. It goes at the cross team, enterprise level. So all of the higher levels ones can flow back down to the layers underneath.

Jeff: Yes, but the thing I want to emphasize is that those are not cut and dry levels. There is lots of overlap. When XP talks about the practice of pair programming, which is one of the more radical concepts, there is no counterpart in Lean. But the Lean concept of taking smaller bits flows down to XP.

Bill: So it seems clear to me as to why they operate at different levels but you say there is confusion. What is the cause of this confusion? Why do they think they are mutually exclusive?

Jeff: When people hear there are different flavors of Agile, they think they are distinct and one has to choose one or the other. Some of the advocates for the different approaches present their way as the better way over the other approaches. This is what I see going on and it creates unnecessary confusion.

Now everyone agrees that we should talk more but there is more to it in my experience. Kent Beck in Extreme Programming Explained talks about values. He talks about communication, honesty, and feedback. These are things that you have to do in interactions with people. Let’s take honesty. Honesty is not, in my opinion, that there is some absolute truth for all to know. Honesty is about saying what is true for you in the specific moment.

Feedback is being able to say to someone when they have done great work and also being able to say when it isn’t working so well. There are always both of these sides to it. It is not all one way. I sometimes see executives talk about communication and they simply sit and talk to you about communication. But communication is a two way street and it requires a level of trust and safety in the group.

Now there are some mechanics in communication theory. For example, Virginia Satir’s communication model makes the mechanics very clear. But if you are not comfortable with saying something to someone then it is not going to happen no matter how good your model of communication. If you do not feel safe in saying something in the team, it will not happen. Good friends build up trust, a sense of safety, with each other over a long period of time. Over time they can say things to each other with a deeper sense of honesty.

I am not suggesting that members of teams should immediately turn into truth-telling machines that are always telling everyone when they are ticked off. I am not talking about that kind of response. But I am talking about teams getting to the point where unpleasant things can be talked about openly.

We discuss in the retrospective process about talking about things that did not go so well. This is one reason why I suggest that retrospectives be kept within the team. The team itself conducts retrospectives and managers and others not on the team should not attend. This gives the team a chance to build a level of trust to gain a deeper level of honesty.

Bill: To pick up on this point. I think that truth and honesty are relative things. For what you are saying I feel you would agree with this. For example, I know this one guy who feels he always needs to say the “truth.” In the process he alienates and hurts a lot of people. He will say things that are his opinion but are also destructive in the context in which they are said. He defends this by saying he just speaks the truth. I think instead, you need to speak an intelligent truth to say things that are constructive and move people forward.

Jeff: I agree. Truth is a subtle thing. It has to do with appropriateness and context. One way to talk about it is to consider the two people talking and include the context so there are three entities involved. In the case of this blog there is you, me, and the context. The context is a blogging mechanism and our readers.

Bill: There is also the issue of establishing the right, credibility, or authority to speak the truth. You need to establish you have been there to really have people accept what you are saying. It is much easier for a member of a group to express concerns about the group than someone from the outside. This gives you some legitimacy and reduces the chance that you will seem simply offensive.

Jeff: Right. So all these things matter in communication. Better teams have higher levels of trust. This enables more profound conversations. They tend to be more efficient. High performance teams know each other better. They trust each other and they need fewer words to communicate. When I work with a team these are the kinds of things I am listening for. I look at the interactions. If you have manager who does not listen, people will not speak. The Meyers Briggs introvert and extrovert aspects come into play here. The high performing team will always give the introvert space to talk. Sometimes with introverts you have to be comfortable not saying anything for a while to give them space.

I wanted to talk about this because we discuss the importance of people in the Agile Manifesto. But often when we think of people we say: did we provide enough food at the right time; are they paid enough; how do they like their office. But there is also the people aspect of team dynamics. These things involve softer values. We know that co-location can be good but you can have a co-located team and still not have trust in that team.

Bill: I am a big believer in this also, both being trained as a psychologist and being part of a lot of IT implementations. I was on a panel at the 2007 Enterprise 2.0 conference that we called, “90% People and 10% Technology. We did this because people always say, well of course it is really 90% people and 10% technology in implementations but in fact they invest funding and focus in the exact opposite direction. At the same time it has been my experience that there is a very positive correlation between the amount of time spent on people issues and the success of the project. But people not get this 90 percent of the time. Why do you think this is?

Jeff: There are several reasons. In the computer software many people got into the field because they were not comfortable with people issues. In some ways software development was an escape for them from interactions with people. I also think it is much harder to measure and show results when you are dealing with the people issues.

Bill: I think this measurement thing is a critical point, especially in the US. We are a measurement culture. We look at wines in terms of Robert Parker’s numbering system that many Europeans laugh at. The numbers can be meaningless but they give us comfort. The people side is hard to measure. In think that what you said about people involved with computers can be true but it also applies to many people involved in business management. They get an MBA and learn to run the numbers. But they not learn how to deal with people. In many situations, it is the business manager who is less oriented to people issues than the IT people.

Jeff: I agree with this. I remember years ago I knew people in the economics program at Berkeley and it was all about the measurement. But perhaps they were not measuring the right things.

Bill: Yes, the balanced scorecard is an attempt to look at a broader range of issues.

Jeff; We have used the balanced score card and 360 reviews with success in Agile teams. Perhaps this measurement should be the topic for another conversation.

The oldest one is the Certified Scrum Master that was started by Ken Schwaber a number of years ago. I first got mine in 2003 and he had been doing them for a little while before then. It basically indicated that you had taken a two day class where the principles and practices of Scrum were taught. It was actually a bit of a joke in the community because it did not really certify anything. It just said you took the class.

But it did work and it got things off the ground. It got people’s attention. I believe the next one to come into existance was the Certified Scrum Trainer. These were people who could give the CSM class – they could certify people. The CST has more meat behind it. You must really ‘prove’ that you know your stuff.

Certified Scrum Practitioner was put together to indicate the step beyond just taking the class. Are you actually practicing Scrum? Successful applicants must be able to document their experience.

More recently, I worked to help put together the Certified Scrum Coach designation. That one was the first certification that was serious about whether you knew what you were doing. Some people have said that it has taken as long as 30 hours to complete the application. You had to have 1500 hours coaching experience and it is pretty serious. Not everyone gets through it.

The bar for these certifications has been going up. At the recent Scrum Gathering the Scrum Alliance announced that they will be giving a test for CSM to determine if they are certified. It appears that this test will be in place in the third quarter of this year (2009). True certifications can only last a certain amount of time before they need to be renewed, usually through a test. Over 65,000 people have become CSMs and they will have two years to take the test or lose their certification.

This is quite a change. All the certifications have gotten more serious. I think this is a good thing. It is part of the maturing of Agile. People are starting to request these certifications and the certifications are starting to have value. It is interesting to watch how this has changed over the years.

Bill: Let me get some more context here. Who administers these certifications?

Jeff: Up until this point for the CSM whenever a Certified Scrum Trainer gave a class he would submit the names of the people who were there to the Scrum Alliance who would issue the certification. The Scrum Alliance administers the certification and they will now administer the test. So as things go forward the certifications will expire and you will have to take another test and demonstrate that you have been practicing Scrum.

Bill: What is the Scrum Alliance? Who are they? Who supports them financially? How is it run?

Jeff: The Scrum Alliance is group of people who are practicing and interested in Scrum. You are invited to join when you become a CSM. It‘s mission to help promote Scrum, handle certifications, and do publicity. They hold the Scrum Gatherings twice a year, one in Europe and one in the North America. This year there is an additional Scrum Gathering in Brazil. They are typically three-day events where people interested in Scrum get together and talk about their experiences.

They have a great web site, http://www.ScrumAlliance.org. You can go there and see a lot of papers and other useful information.

Bill: Is it run as an academic or professional organization? I am curious because in my experience with knowledge management, there were a number of certification efforts that were really designed to be money making efforts for the person running them and very self-promoting. They were trying to create a business for themselves out of this movement or approach. Now this is not necessarily a bad thing if it is appropriate. In the case of knowledge management some times it was not or it was a gray area. So is this a volunteer organization or a business in itself? How does all this come to play?

Jeff: Well, originally it was just a group of people and then there were some money making aspects. The actual formation of the Scrum Alliance as a legal entity only occurred about three years ago even though certifications have been given out by Ken Schwaber for quite a while. It is now a legal non-profit organization. It is not designed to make money. It is not designed to support particular people. It has an independent Board of Directors from various companies. It does have a director and some staff to manage the web site, the events, and the certification process.

Ken Schwaber was the main early advocate of Scrum. He wrote some books and kept pushing it while the rest of us went off and did things. He was involved with Jeff Sutherland very early in the process.

These recent moves have made the Scrum certifications more substantial. There was talk before that it only meant you attended a class. Now the requirements are more involved. The Alliance made a decision not to change the name of the certification (CSM) because of all the people who already had it. They just added the testing requirement.

Bill: Is the Scrum Alliance sponsored by a software firm or firms, or is it independent?

Jeff: There are a number of firms who help sponsor the events but it is independent.

Bill: So it is an organization run by the evangelists rather than sponsored by several software firms.

Jeff: Yes. The Agile Alliance is a similar type of organization. It was formed later. They put on the biggest Agile conference.

Bill: The state of the nation of the Agile Alliance sounds like a good topic for another post.

When we go back to the roots of Agile, which I consider to be extreme programming, we see the issue of quality elevated to the highest level of importance. Quality is very important and low quality can affect new feature development, team morale, and drown an organization in bug triage, reporting, fixing, regressing, documenting and forward fixing.

We know that unit testing and even better, test driven development, can drive the quality higher. But what does that have to do with UML?

The best way to have much better software is to have better design. Having a better design is the product of communication with your other team members about design choices. A great language for that communication is UML.

Text or just word-based communication about design is slow and subject to interpretation errors. Most folks find communication about patterns, which are really just examples of good designs for common problems, much easier with UML. (This is why we use UML in my Emergent Design Class.)

When I talk about UML, I do not mean UML models that are so specified that code can be
generated directly from them. I mean 'blackboard UML'. Usually this is the class diagram, the sequence diagram and the interaction diagram - just three of the possible diagrams in UML. Other diagrams can be used in specific situations. State and component diagrams are seen as well. I would say that if you only use class diagrams, you have achieved a significant percentage of the value. For a simple introduction to the class diagram go here. The book on UML I like best is UML Distilled by Martin Fowler.

High performing Agile teams tend to have visual things around their work areas or on their wikis. In particular I see UML on white boards or on wiki pages to show high-level designs of areas of their work. People have good discussions around these. And make changes as the project unfolds. Product Owners use UML to capture Domain Models.

I believe that every person (or at least every developer) on an agile team should be able to use simple (blackboard) UML to talk about their work. And everyone should be able to diagram the high level abstractions in the team’s code - the architecture as it were. What do you think?

Jeff McKenna (see above) came on to the sound of cow bells to deal with these myths. He introduced the Agilistas from Valtech and Serena. Myth one: Agile means you never have to write documentation. Both sides were briefly covered. The audience was asked and 79% said it is false. This is also the position of Serena and Valtech. However, documentation can be produced at the right time when the system is ready. There is less editing and revisions.

Myth Two: Agile is more disciplined than other methods. Again, both sides were briefly covered. The audience was asked. 43% - false and€“ 41% true. The panel believes that Agile is more disciplined but it is bottom up discipline rather than imposed discipline. There is more feedback and engagement. This is a common, and counter intuitive, aspect of enterprise 2.0. With transparency you get accountability and more discipline. It results in greater productivity. I have seen many examples of the switch to more transparent project management leading to significant increases in productivity. Below is a panel debate.

Myth Three: Agile means I can change my mind whenever I want to. Both sides were briefly covered by the panel. The audience was asked and 79% said it is false. This is also the position of Serena and Valtech. There needs to be some stability. Within the sprints in development, change needs to be on hold. Then there can be times for change.

Myth Four: Agile works on all sizes of projects. Both sides were briefly covered. The audience was asked and 59% said true. This is the position Serena and Valtech but you need to recognize that there are greater needs for large projects for them to succeed. The key differential is that you can keep Agile teams small and link together these teams to handle size. One large project had 27 teams successfully linked together.

Myth Five: Agile means teams cannot be controlled by management. Both sides were briefly covered. The audience was asked and 72% said false. Serena and Valtech agrees with this. Agile is about control through planning, monitoring, and adapting. Management is about getting more done by removing obstacles. There is a different style of management.

Myth Six: Agile requires detailed architecture and design. Again, both sides were briefly covered by the panel. The audience was asked. 55% said true but Serena and Valtech disagree with this. There is less architecture and design. You need architecture but it is not the driver. Architecture comes out in dealing with the problem and should not be a guiding factor. Let architecture emerge and be open to change.

Myth Seven: Agile is just the latest hype. Both sides were briefly covered. The audience was asked. 62% said false and Serena and Valtech agrees with this. It has been around for a while. There are demonstrated successes. Most employees like it and there are productivity improvements.

Myth Eight: Agile works on complex projects. Both sides were briefly covered. The audience was asked and 71% said true. Serena and Valtech agree with this. However, it does require more management.

Myth Nine: Agile teams do not work hard, they just play foosball. Both sides were briefly covered. The audience was asked and 75% said false. Serena and Valtech agree with this. There is a balance of work and fun required. Focus is key.

Myth Ten: Agile is only used for mission critical projects. Both sides were briefly covered. The audience was asked and 95% said false. Serena and Valtech agree with this.

I like it. It brings together a wide range of agile practices and gives good analysis of each. As with good pattern books, it shows why, how, why not, and such for each pattern. Since there are 38 (!) practices, finding the one that matters for you is important. They have been clustered a bit and are still hard to find.

I personally find patterns a useful way to capture and present what is needed and at the same time difficult to understand. Since I already understand these patterns I found them useful and occasionally found a new way to think about a particular one. If I did not already know the pattern, I am not so sure how useful the book would be. I will defer on this to others in that position.

And one comment early in the patterns did catch my attention and has, I hope, influenced my thinking: Amr comments on the importance of learning. Much of the agile feedback mechanisms can be viewed as opportunities for the team to learn.

The importance of the learning cannot be dismissed. Getting better in every aspect of creation - planning, design, measuring, coding, testing, communication, delivery - is critical to create a high performance team. Such teams look at every change, comment, bug, and hick-up as an opportunity to improve.

I use the repetition of activities as an easy way to identify an area for improvement. If the team is spending time on activity over and over again then an opportunity exists for improvement. In particular these opportunities often are automated to eliminate the human time/errors that are present.
So, Amr, thanks for the stimulation.

Bill: You mentioned how you turned a software development retrospective on its head and discussed what went right rather than what went wrong. This is a nice twist on lessons learned and should encourage participation and engagement. After all what you want to repeat is what went right. So let’s have the details.

Jeff: This project had been going for six months. I talked with management about having a release retrospective. Most people are familiar with having a retrospective after each iteration or spread. This usually occurs about every four weeks for an hour or two with each team doing this independently. But we also recommend that after longer periods, say after a major milestone is reached, two practices. First, the teams take a week off and stop the sprinting and breathe for a bit. And second, the teams have a more relaxed release retrospective.

In the book Agile Retrospective, Esther Derby and Diana Larsen talk about the need for the shorter sprint retrospectives while you are still in the fray. These typically last one hour or so and involve one team. In contrast, the release retrospective involves the whole group of teams and takes a longer look.

Bill: What was the problem that set up this release retrospective? Why did you do it?

Jeff: The problem is a generic one. People need time if they are going to learn. One of the Agile tenets is that teams need to be able to learn and reflect. The release retrospective is looking at it from a longer time perspective and from the perspective of all the teams on the project. Typically problems are solved at the individual team level. So as we move to the multiple team level I am a little less concerned with specific problems and more concerned with attitude and making sure that people feel they are on a larger project where teams are working together.

The heads down sprint-to-sprint activity in a team can be very focused and sometimes isolating. It can be harder to come up and breathe. So in the release retrospective there are discussions at a higher level about such things as the vision for the next six months or big changes that are being considered. People can reestablish the larger context that they are working in.

There is a type of inquiry called appreciative inquiry that is a technique for exploring issues that allows people to focus on solutions and positive aspects of their experiences. It is referred to as the discipline of positive change. There is some data in research that indicates that larger groups of people who focus on things that work and spend less time on problems such as we typically do in our industry, people feel better, are more productive, and their customers are happier. I was exposed to this research and I thought it might be interesting to bring this approach into the retrospective.

Here is what we did.

First we had everyone introduce themselves and provide a fact about themselves that they felt no one else knew. This activity helped establish a relaxed atmosphere.

We we used a time line. We had put a 20 foot roll of brown paper on the wall and listed key events during the six months (e.g., the big snow storm, the hiring of key people). Then in the retrospective individuals put on the key events that mattered to them. We ended up with this long time line with all these sticky notes that documented the things that mattered to individuals.

As each person put up a note they told the group about the event. This generated lots of laughing and feeling that they were together on this thing. It was fun, interesting and informative.

Next we added a temperature reading. People went along and added below the time line their memory of their general feeling at that time.. This is a technique where people say things like I was feeling really good about things here and not so good here and all that. All thirty five people did this. In this particular time line case was only one situation were there was an alignment of feelings. Everyone felt bad when we slipped a date by three weeks. Other than that some people were up and others were down at any particular time. People began to realize to that people were different. People enjoyed this.

Next, we had people tell stories about when they worked on teams that went really well and they loved the experience. This is appreciative inquiry technique.

Bill: Do you mean they told stories about events not just on this project but in general?

Jeff: Yes, in general. Some people called out things on the project. Some people called out things from the other parts of their life. This was fascinating as well. We told stories in small groups of five. Each group picked the best story to present to the larger group. As the stories were told we abstracted out the commonalties. We recorded what were the things that mattered.

A this point in time we were at five hours since we had had breaks and lunch. People were feeling jazzed. They felt they had heard what was important from each other and had expressed what was important to them. So we quit early which always makes people feel good. Hopefully, I will have a chance to go back to the same group after another major cycle and continue this.

People came up to me afterwards and said they had been very worried that we were going to spend six hours talking about what went wrong in the prior six months. There was even one guy who did not come into work that day and started the session on the phone. He got so interested that he drove in to participate live and be more involved. The most senior person there was excited as he valued building a cohesive team. Everyone was pleased with the reverse in expectations.

Jim Cundiff has been running the Scrum Alliance for a bit over a year now and I am glad to report that I am seeing considerable improvement in the professionalism, focus and activity level of the Alliance. The program for this meeting has brought in a number of folks from outside the immediate Scrum community. Ron Jeffries and Chet Hendrickson from XP, Dr. Alistair Cockburn of Crystal, Dr. Mark Paulk of CMM, and Gregory Balestrero from PMI and Jim Coplien of Patterns are all here and adding to a more inclusive feel of the gathering. In particular Mark is beginning some academic research on Scrum and the PMI is 'embracing' Scrum with a large number of PMP folks attending.

The Alliance is showing off the redesigned Scrum Alliance website. I suggest you take a look. It appears to be much more comprehensive and there is a lot of content now easily accessible.

Last night I met with 8 other Certified Scrum Coaches as we considering our next moves. I was involved with the initial definition, construction and roll-out of the Scrum Coach certification program. It is a rigorous certification with a non-trivial application and thoughtful evaluation. One really has to be a Scrum Coach to get certified. Initially there were six of us certified. Now the number is up to 12 and increasing each month. The coaches I met with last night were from Australia, Germany, Denmark, South Africa and the US. I am proud of the work we have done on this program and we are hoping that it grows and becomes recognized as a guide level certification.

With Alliance support we are seeing more and more Scrum User Groups getting started. Now over 50 world wide. And also growing. Some folks have wondered if at over 50,000 certified Scrum Masters if the 'market' was becoming saturated. It appears not to be so. Altho training rates have slowed somewhat, the demand is still reasonably strong. The requests for coaching are increasing as well.

In short, Scrum is alive and well and in fact, thriving.

Bill and I had a conversation going into more depth on how this might work.

Bill: How do you get the bug reporting time down to minutes? I am used to seeing many bugs getting all the way out to users as an accepted byproduct of software development. Some vendors are famous for this.

Jeff: The first thing you need to do is to establish the practice of continuous build, or better continuous integration. Most successful Agile development
shops have this practice in place. This means that every time a developer turns in their code, the application is rebuilt and tested with the new code. So you are able to quickly see if the new code brings in any unwanted behavior, aka bugs. This integration often takes a few minutes to build a typical change. The book Continuous Integration by Paul Duvall, Steve Matyas, and Andrew Glover is a good resource on this topic.

So the first part is having the ability to quickly turnover the integration of new and old code. The second step is to have good unit tests. These tests should be part of the automatic build. If a unit test fails, the ‘build’ fails. If you have unit tests in the area being changed, the effects of the bad code will show up right away.

Bill: I have often heard of unit tests but usually just assume I know what they are. I think I need to make sure I know what you mean here.

Jeff: Unit test are the lowest level of tests. They test classes and methods and small assemblies. They look at code function to see if it does what the developer wants it to. Functional tests on the other hand look at code to see if it performs what the customer or end-user wants. Unit test are designed to run very fast and look at all the code on a specific section of the application. Test coverage measurements should be made on unit tests.

If you use a technique call “test first,” then no line of code is written except in response to a failing test. That means that there is not a lot of code in the system that was produced without a test informing the code’s development. This gets interesting because what this means that every line of code has a test associated with it. So if something changes the code later the unit test can see if anything breaks.

Because the unit tests are so fine grained you will know right away what the problem is without having to debug. Debugging is figuring out what is wrong and with unit tests you know what is wrong. So if you make a code change and it breaks right away you know right away the cause. You still need to understand it but you do not need to spend time finding it.

So the combination of continuous build and unit test allow you to get to the condition of bugs being found right away. In the particular case I was thinking of we did not need a bug tracking system. In this effort we had twelve developers over eighteen months and only had about five bugs at any one time. There was no need to prioritize bugs. We said all bugs are important and need to be fixed right away.

Bill: So this makes total sense to me. Why doesn’t everyone do it?

Jeff: There are a couple of reasons. One reason is that historically we have considered testing not part of development. We have considered testing as something done by QA, often by a different department. Code got thrown over the wall for someone else to deal with and quite a bit of development was done before testing occurred. Responsibility was passed on and not shared.

The other reason is that we do not tend to measure debugging effort so the cost is not apparent. It is almost always much more than people think. When we do not measure fixing bugs there is not any drive to improve the process. Also, folks just assume there will be lots of bugs. ‘That is just how software is.’ Well, it does not have to be that way and I think it is time to change our attitude.

Bill: So is the concept of immediate fix one of the cores of Agile development?

Jeff: Let’s say that most successful Agile teams just do it. One of the practices in extreme programming (XP) is the concept of collective code ownership. In this case an individual does not have ownership of code. So no one can say, “well I cannot fix this code because it is someone else’s code.” So when in Agile we all own the code so if I see a bug, I just fix it.

I had the pleasure of working with Ward in the late 1980's at Tektronix in Oregon. We were working on Smalltalk and working on Patterns and the beginnings of the development style now known as Agile. Other interesting folks were at Tektronix at that time including Kent Beck, Rebecca Wirfs-Brock and Norm Kerth. It was a heady time and place with lots of passion and lots of great software.

Ward and I have kept in touch and this interview was an early one in his lightning series.

While I will reflect on the tools a bit, tool technology is not my main focus. I am more interested in the team and process issues since it is people, in the end, that have to get these tools to work. I have studied family and team dynamics and like to apply principles of complex adaptive systems. I feel that when things break down, or even better before breakdown occurs, we need to move beyond managing symptoms and treat root causes.

Let me offer an example, in most development shops noticeable time is spent prioritizing and dealing with bugs. That effort only manages the symptoms. It can be more useful in the long run to look at the operational side of development. An interesting issue is the time that elapses from when a bug, an unwanted change, enters the system and when it is detected. I have been in situations were that time was measured in minutes. Then developers could quickly learn from their mistakes, make immediate corrections, and move on. They learned and produced fewer and fewer bugs. Then we did not have to spend time prioritizing and dealing with long lists of bugs.

I will get into much more detail on many stories such as this one in the blog.

Sometimes it helps to turn things on their head. I was once asked to faciltate a release retrospective for a group of teams. I asked for six hours of their time. In these sessions in the past they would engage in examining what went wrong. The groans were loud and some team members decided to only dial in. Instead of looking at the mistakes, we talked about the times when they were most thrilled with a team’s performance. We never once discussed what went wrong, the positive energy level rose, and some of those on dial in came into the office for the remainder of the session. The team got back on a more positive track. Of course, I do not always get it right and I will share these stories also.

This blog is sponsored by Serena Software, a provider of application development and business software for companies of all shapes and sizes. I work for Serena. Some Serena’s tools and services support Agile development. We might talk about Serena on occasion, but this conversation is not about Serena, it is about the issues that everyone faces in Agile development.

Bill, David and I encourage you to browse our categories and not just look at our latest content. The categories contain the archives of our past posts. Many of these posts should remain useful as we will discuss issues in depth and not simply provide current news. Also use our search field. Often good blog content gets buried as it moves off the front page.

If you like what you find here please join the conversation through our comment fields. Our blog will allow us to learn of your comments regardless of when the original post was published. We look forward to hearing from your perspectives. We want to learn from you and we look forward to your participation.

a

Here is a bit about my background. I have been involved in software development for over 45 years and have been actively participating in the creation and delivery of agile software development since 1987. I have been involved in all areas of software product development from programming, system design and architecture to project management, testing, sales and marketing. Since the late 1980s I have focused on the people/process side of development. Jeff Sutherland, John Scumniotales, and I created the Scrum methodology of agile software development in 1993 at Easel Corporation and started the very first Scrum team. (Little did we know what we were creating!)

I have worked extensively with object-oriented programming systems, languages and applications and was the Chair of OOPSLA in 1994 that helped to incubate and increase adoption of several related disciplines including agile software development. Working with IBM, Cigna, ObjectShare, Easel Corp, Millennium Pharmaceutical and the US Air Force, I provided expertise in architecture, design and implementation for their first Smalltalk based object-oriented projects. 

As an Architect at Rational Software (now IBM), I made various contributions to Rational’s industry leading Rose product. These included extensions to the Unified Modeling Language (UML) to support a UML model of testing.

I also worked with industry pioneers, including Grady Booch, to extend the Rational Rose product to natively support Design Patterns.
I am a Certified Scrum Coach, Certified Scrum Trainer and Scrum Master, I have taught, coached and mentored agile teams using Scrum and Extreme Programming practices for many companies, including Oracle, PayPal, Borland, Vanguard, Microsoft, Google, Lockheed Martin, Tumbleweed Communications, V-Mark and Net Objectives.

Philosophically I am a Buddhist and I love good food and race cars. My wife of more than 27 years is Cory.

Bill Ives

Bill has served for over 25 years in leadership positions as a consultant in knowledge management, community building, and other business applications of emerging technologies. He has worked with large and small companies in a variety of industries, and is currently focused, as a consultant and writer, on what the new Web brings to business. Bill also participates in several search-based start-ups including iQuest, and Wikigazette. Prior to his present roles, Bill led the Knowledge Management - Portals Practice at a major consulting firm. Bill has a Ph.D. in educational psychology from the University of Toronto and conducted post-doc research on how media affects cognition at Harvard.

Bill’s oldest daughter spent two years in a Buddhist country, Mongolia, and he also likes their views, especially respect for women. He is a painter when not blogging.

Bill is engaged to provide a partner and outside perspective to the discussions. Since this blog is about conversations, we will be starting many of these conversations between ourselves. Operating under the model of two heads being better than one, at times Bill may interview me, challenge what I present, or act as a sounding board on discussions. In some cases he may contribute posts to offer another perspective. However, we will be clear on the authorship on all posts and list whether it is post by myself, Bill, or a combined effort. You see the author or authors as a category at the bottom of each post and browse the blogs in each category in our right side bar. We also do conversations between the two of us and they are categorized as Interviews. We see this as an opportunity to experiment with different models of conversation and blog collaboration in a transparent manner. We plan to have fun and hope it is contagious. We welcome your input.

David Socha

I introduced David to agile practices back in 1999 when we both worked at Rational. As David recalls it, one day I said to him "Let's go to the bookstore. There is an interesting new book that I want to look at." That was Kent Beck's book Extreme Programming Explained: Embrace Change. According to David, software development has not been the same since for him. It made software development much more engaging. Ever since, he has been using agile practices and his people skills to help organizations improve their practices. He is a Certified ScrumMaster and Certified Product Owner, and has a particular fondness for biomimicry.