Chris Sterling’s Blog

At the last Scrum Trainer’s Retreat in Boston, MA, Lowell Lindstrom presented a 30-minute exercise on Affinity Estimating. Kane Mar has written a short blog entry on this technique for sizing a large Product Backlog here. I would like to add some context for the exercise and a step-by-step that I have found useful since using this and other similar techniques. Although I do not suggest having Product Backlogs of enormous size, this exercise has been successfully run in my presence with over 300 items in 2 hours. I recommend that this exercise is used when you have more than 20 items to size. When less than 20 I find that Planning Poker or a more sequential approach may be more appropriate.

Prerequisites

In preparation for this exercise, the Product Owner must have a list items in their Product Backlog which are to be sized by the Team(s). I suggest that the Product Backlog items are each put onto their own index card, post-it note, or better yet perforated and printable Avery index cards. Also consider holding the exercise in a room with a large wall that you can stick Product Backlog items onto. If you are using paper print outs of your Product Backlog items then you may need to bring blue painter’s tape or some other sticky substance to adhere them to the wall. You may also wish to bring stickers, black sharpies, extra index cards or post-it notes, and multi-colored markers.

Step 1: Silent Relative Sizing

As shown above, place an X-Large post-it note or index card on the far left side of the wall with “Smaller” written on it. On the far right side of the wall place another which says “Larger”. Let the Teams know some simple guidelines which may help the relative sizing exercise, such as:

• Team members will be asked to come up to the wall with a subset of the Product Backlog items provided by the Product Owner
• Team members will be expected to size each item relative to other items on the wall considering the effort involved in implementing it based on our Definition of Done
• This is a silent part of the exercise so please refrain from speaking to others except for basic comments like “move out of my way”
• The Product Owner and any helpful stakeholders/supporters will be present towards the back of this room to provide clarity when needed, so please ask them for help when not sure about an item
• Team members may use a place in the room to capture questionable Product Backlog items such as items which are too ambiguous to size even after discussion with the Product Owner
• Think of the wall as a spectrum of size from Smaller to Larger; items stacked vertically on the wall are about the same relative size in effort

I have facilitated this exercise with teams of 5 to 45. When working with a larger number of team members it is important to use good facilitation techniques such as phased work in smaller groups at the wall. Please find resources on the Internet and with your HR department on facilitation for more specific tips when working with the large groups.

Run the silent relative sizing until all Product Backlog items are up on the wall or in the space reserved for questionable items. This can take anywhere from 5-20 minutes depending on the number of items and team members.

Step 2: Wikipedia-like Editing of Wall

Now it is time for Team(s) to edit the relative sizing on the wall. Ask team members to read the Product Backlog items on the wall and move them around as needed in either direction, smaller or larger. Explain to the Team(s) that we should be considerate of other team member’s estimates and therefore bring others into the conversation when appropriate before making extreme moves.

During this part of the exercise you may see some design discussions going on, thoughts about Product Backlog items which are missing, and increased clarifications needed from the Product Owner. Allow this to continue until the Team(s) begin to settle down and there seems to be little change happening on the wall. This may take 20-60 minutes to complete.

Step 3: Place Items into Relative Sizing Buckets

Once all of the Product Backlog items have been placed onto the wall and edited by the Team(s) our job is to get them placed in size buckets. Depending upon the nomenclature that the Team(s) decided to use place the sizes along the spectrum at the top of the wall between smaller and larger. For instance, if you are using Fibonacci sequence for your story point nomenclature, place the 5 further away from 3 than 3 is from 2 on the spectrum. If you are using T-Shirt sizing then may decide to use a doubling or just increasing spacing as sizes get larger. It should look something like the picture below after you put up the sizes:

Ask the Team(s) to decide which size the Product Backlog items fit under based upon the relative size location on the wall. Explain that we need to make the sizing clear so leave space between buckets of sized items. After this has completed the wall may look something like the following:

Step 4: Product Owner “Challenge”

Once the Team(s) have sized the Product Backlog items on the wall the Product Owner is probably anxious to discuss some of the sizes. I usually give the Product Owner and any of their supporters a colorful pen or stickers to mark items they would like to discuss with the Team(s). This is also a good time for the Team(s) to take a 15-minute break to recover from the estimating work they have done so far.

It is important to tell the Product Owner and their supporters that the word “challenge” is not to disrespect the estimates of the Team(s). Be careful how you approach the challenge and make sure that you are communicating what about the item’s size was not inline with your thoughts of it’s size. I may even prepare them with some Planning Poker Tells that may be noticed by the Team(s) while they are challenging items.

When the Team(s) get back from break have them get comfortable and allow the Product Owner and supporters to ask about items they have marked on the wall. The Team(s) discuss their reasons for the size associated with each item. You can take multiple approaches in terms of changing sizes based on the Team(s) input:

1. When team members decide that an item should be resized put it onto a separate wall for resizing after challenge has completed.
2. Have team members decide on the spot with the Product Owner what the new size is.

Although the first of these choices seems best I have found the second to be sufficient in most circumstances. This step is completed once all of the challenged items have been discussed. This may take anywhere from 20-60 minutes.

Step 5: Get it into an Electronic Tool

Of course, we should make sure that the information is not lost once the estimating has been completed. Make sure to get the estimates into your tool of choice for Product Backlog management ASAP. I usually write the estimated size on each Product Backlog item before taking them off the wall and transferring into the tool.

What Else?

I found a few nuggets in running this exercise which I believe to be helpful:

• The Affinity Estimating exercise is best conducted on Product Backlogs larger than 20 items. It is best when you have at least 40 items which allows for groupings to easily become apparent.
• Some Product Backlog items may not be understood enough to estimate at all. Place these on a space separate from the estimating wall so the Product Owner can take them away and clarify them.
• Leaving the sizing nomenclature off the wall until the full sizing steps 1 & 2 are completed helps Team(s) use relative sizing.
• Ask the Team(s) to decide on a common sizing nomenclature such as T-shirt (XS, S, M, L, XL), Fibonacci (1, 2, 3, 5, 8, 13), or 2n (2, 4, 8, 16, 32) before starting step 3 if they haven’t already decided.
• Spacing of sizes relative to the gap between the numbers across the wall can help team members put items into size buckets.
• Be careful and work with the Product Owner and their supporters to understand how the “challenge” of sizes can be effective and still respect the Team(s) estimates.
• ScrumMaster must be ready to do heavy facilitation with a single team. If you are conducting the exercise with multiple teams it is imperative that each step is setup well. I have facilitated this exercise with 3, 4, and 5 product teams in the room. It works well in this situation with healthy facilitation.
• This exercise does not remove the need to conduct more in depth estimating sessions such as with Planning Poker as the Product Backlog evolves.

Try it out and let me know in the comments if there are any additions or modifications you would like to make. I believe the Affinity Estimating exercise will be helpful to those dealing with large Product Backlogs in getting initial estimates. Thank you Lowell and Kane for exposing this exercise to us.

3 Comments »

One of the most common questions in teaching and coaching agile processes to groups is:

“How do we design our software while delivering iterations of potentially shippable product increments?”

Scrum, an agile process that I teach about and coach organizations on implementation of, asks that each Sprint, analogous to an iteration, delivers a potentially shippable product increment. There is emphasis on potentially shippable since it is quite common to have releases that involve running multiple Sprints until there is enough value for your users. I usually describe potentially shippable product increment is that the software is of a quality that a releasable version would include. This means that each Product Backlog item that is implemented during the Sprint is tested, coded, integrated, documented, and verified. Scrum teams gain a better understanding of what deliverables are necessary to make this happen by creating a Definition of Done.

When I ask what design decisions are difficult in the Scrum process to deliver it usually revolves around high level architecture decisions or data modeling. There are other specific design areas that get brought up but lets focus on these for now. In order to help a Scrum team understand from a conceptual point of view how incremental design works across a release of their software product I use a diagram that I believe Mike Cohn created. Here is my interpretation of the diagram:

This diagram attempts to describe how in new software product development efforts more emphasis in early Sprints is put into implementation of architecture elements. As the architecture is more fully defined and implemented in later Sprints emphasis is increasingly put into feature development. In the final Sprint of a release there may be little to no architecture implementation left to do. This diagram demonstrates the expectations of early release deliverables in terms of technical architecture implementation to support feature delivery. It also shows that each Sprint in the release should deliver features that a user can review.

In a software product team that delivers more than one release may have less architecture emphasis in early Sprints of following releases. This is shown in a modified version of the diagram below:

After describing the above diagrams to a developer named David Wright he approached me to validate his understanding. Within 10 minutes of my description of incremental architecture he had developed a new diagram perspective which I thought was brilliant. His diagram involved two axis with the x-axis representing the surface visible to users and the y-axis representing depth of the architecture. In Sprint 1 of a multiple Sprint release a portion of both the surface and architecture depth are realized. The figure below is a visual representation of the portions implemented of a fully releasable product version. The dark blue areas of the grid show implementation of the surface and depth in Sprint 1 while the empty grid elements represent what has not been implemented yet.

As a release progresses the amount of surface visible features and architectural depth implemented is incrementally built upon towards a fully releasable product version. The following diagram shows the incremental architecture progress later in the release cycle.

The adoption of an incremental architecture approach comes with a couple of potential issues:

• Less up front design of the overall release architecture is known at the beginning and while the depth of the architecture is still being implemented
• New knowledge may impact existing implementation of architecture elements

In order to manage these types of issues we must implement disciplined practices to allow our architecture to accept change as we gain more knowledge. This is why the Extreme Programming practices such as Test-Driven Design (TDD), Continuous Integration (CI), Pair Programming (or continuous code review), and Refactoring have become so common on Scrum teams. TDD gives our design an executable way to prove we have not broken existing functionality at the component and functional level. This does not negate the need for exploratory testing by a person but it will keep manual testing to a manageable level. CI automatically runs builds, automated tests, and deployment of our application then provides feedback to the team about the current state of the integrated system. Pair Programming increases knowledge transfer across the team and provides coherent communication of the products domain into the tests, code, and support artifacts. And finally, refactoring is defined by the guy who wrote the book on it, Martin Fowler, as:

“a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior”

Refactoring is best support by a high automated test coverage that allows a team to know when the external behavior has not been changed in response to changes deep in the architecture. Here is a visual representation of architectural elements, in red, which could be refactored in response to a new feature.

Each of the refactorings may be small changes but lead to larger positive impact over the span of a release. Effective use of refactoring keeps our architecture flexible and therefore able to meet evolving business needs.

I have used David Wright’s model to describe incremental architecture to other clients in conjunction with the original diagram from Mike Cohn. It has helped provide a clearer picture of incremental design and how to incorporate it into their real world projects. With David’s permission I named it the “Wright Model” and will continue to use it in the future. Thank you, David.

Big design up front (BDUF) is based on the thought that we can lock down business requirements and design our software right the first time. The problem is that business needs change almost as soon as the requirement has been developed. Not only do they change but the functionality requested is better understood once a user touches the feature and provides their feedback. Incremental design of a system throughout a release allows us to incorporate this feedback and change our architecture to satisfy the user’s needs.

1 Comment »

While coaching teams I have found the creation of a Working Agreement as an essential step for a Team to initialize their adoption of an agile framework. I have also noticed that the ideas behind along with the process of creating a Working Agreement is not widely understood by coaches, ScrumMasters, and team members. Although there is no single reason or way to facilitate a Team in the creation of their Working Agreement, here is what I have found to be helfpul.

As a facilitator you can help the team understand the reason for creating a Working Agreement by discussing the need for understood team norms because agile frameworks involve increased collaboration. Becoming a Team involves commitment to working together and supporting each other in our common goals. This commitment is supported by writing what all team members believe are important protocols for the Team to comply with to maximize their capabilities to deliver faster and with higher quality.

With Scrum Teams I have found the following topics are a good starter list to start the creation of a Working Agreement:

• Time and location of Daily Scrum
• Testing strategy (unit, functional, integration, performance, stress, etc…)
• Build and infrastructure plans (shared responsbilities)
• Team norms (be on time, respect estimates, help when needed, etc…)
• How to address bugs/fires during Sprint
• Product Owner availability (phone, office hours, attendance in Daily Scrum)
• Capacity plan for initial Sprint(s)

A common way that I facilitate is to put these topics on a white board or piece of easel pad paper and then ask the Team(s) to create their working agreement with these as guidance. If they find other topics which are important please add them to the list. I highly recommend creating a Working Agreement for your Team. It helps all team members understand what are common protocols for the Team and an opportunity to work through conflicts in practices.

1 Comment »

At a recent Seattle Scrum users group meeting I presented on the topic of “Managing Software Debt”. Here is a link to a PDF of the presentation and the following is a description of the topic:

The Product Backlog in Scrum is used to prioritize implementation of features into software based on value. A Product Owner is charged with managing the Product Backlog to direct software implementation for the greatest possible Return on Investment (ROI). Entirely feature-based Product Backlogs do not consider the decay of software over time, and the resulting software debt can sink a project or company. This presentation will highlight ways Scrum Teams and Product Owners can work with stakeholders to manage software debt over the life cycle of the product.

1 Comment »

An article I wrote in the summer last year is now on the Scrum Alliance web site.  The article focuses on value when deriving user stories for your Product Backlogs and describes a step-by-step process for running the value-driven user stories exercise.  Here is a link to the article directly:

Focus on Value - How to Create Value-Driven User Stories

Please comment on this blog if you are using this exercise during Product Backlog “grooming” sessions and let me know how it is working for you.  Thanks.

No Comments »

Michael Krigsman provided an interesting variation of why blind dates so often fail and changed blind dates to project plans.

The interesting piece to me is the overlap area identified as “rare”.  I speak to many folks about their project expectations compared to plans and one phrase which comes up often is “well, it worked in [name of] project fairly close to plan”.  The somewhat rare success in planning up front seems to be a beacon for further use of particular project planning tactics.

I am not going to expand right now on this subject but I would like to leave this with something for us to ponder.  How many of your projects actually get even close to original plan expectations?  What methods in planning are actually adding to the success?  What types of projects are finding better success?  Let me know if you have any comments or wish to share your answers with the readers of this blog.

No Comments »

Many of you may have heard of Planning Poker for estimating your Product Backlog items. Each team member gets their own set of cards with sizes identified on them in either story points (1, 2, 3, 5, 8, 13…) or t-shirt sizes (XS, S, M, L, XL…). The Product Owner tells us about one of their Product Backlog items they wish us to size in effort and complexity. The team members then choose what size they believe the item to be and once each team member has chosen their card they flip them around. The team must come to an informed consensus on the size of the item in order for the estimate to be final.

As an Agile Coach, I have been working with many teams for some time now on using Planning Poker for their estimation of Product Backlog items. Over time we have identified some “tells” that the Product Owner gives to team members to influence the estimation activity. The three most prevalent in my experience are the Jazz Hands, But-But, and most often used of them all Its Just.

Jazz Hands seem to come out when a Product Owner is describing a Product Backlog item they are excited about and hope will be able to make it into the next iteration. In order to show their excitement about the item their hands raise up near their chest and wave quickly back and forth. This physical display alerts the team members that this item is important to the Product Owner and we may be asked to implement this one quickly. If a team is not comfortable in looking beyond the Product Owner’s physical display to honestly estimate the cost of the item they may be influenced to size it small enough to fit into an iteration and risk not meeting their iteration commitments.

Once a team has come up with either an initial or secondary estimate show of cards the Product Owner may be caught off guard by the size this team has come up with. A common response from the Product Owner may start with “But, but…” which alerts the team that the cost is too high for the item in the Product Owner’s eyes. Although we have coached the Product Owner to respect the estimates made by the team they are unable to sit quietly by when such an event occurs. If a team is pressured by the Product Owner’s response to decrease the size during another round of estimating then the Product Owner will not get an honest cost and this items inclusion into an iteration may be fraught with risk.

Sometimes prior to the initial estimate by the team or directly following a But-But you may hear the notorious words Its Just. These two words usually indicate that the Product Backlog item in question has tremendous value and plenty of hidden work underneath it’s simple facade. The team should be wary of such phrases and enter the Planning Poker rounds with extreme caution. If the team members do not express the hidden work to our anxious Product Owner then the entire team may underestimate the item and get caught later in the software delivery life cycle with a humongous Its Just item on their hands. The team should take the time necessary to fully understand this item and its implications in the Planning Poker estimating discussions.

It is important for teams to own their estimates and take responsibility for their implications. It will not always be easy to give your estimate to the Product Owner. The Product Owner is looking for ways to maximize their ROI for the system under development. The team’s estimates are used as a check and balance to the Product Owner’s pursuits. There are times when the team hears one of the “tells” described above and then may engage the Product Owner in finding out a simpler acceptance criteria for the Product Backlog item in order to better meet their needs. Be careful not to ignore such “tells” though. It may lead to discontent for the Product Owner and the team later down the road.

2 Comments »

In a recent Certified ScrumMaster course that I taught in Seattle we conducted an exercise where a group drew a series of pictagrams describing what a ScrumMaster should not do. One of the groups drew the following picture:

While debriefing the exercise with the entire class a comment caught my attention:

“What is that supposed to be? A ScrumMaster should not go fly fishing for cattle?”

The entire room broke into laughter. The group that drew the picture informed us that this was describing how the ScrumMaster should not use a whip to get things done. I immediately wrote down the comment and it became a theme throughout the rest of the course.

That night I actually spent about 30 minutes trying to figure out how this comment was relevant to the ScrumMaster role. Here is a short list that I have come up with so far:

• Instead of “A dead ScrumMaster is a useless ScrumMaster”, this phrase could be used to describe how trying to tackle issues fully before those involved are ready can be dangerous, may get results you are not looking for, and will not help the team improve.
• It could also be an example of fixing impediments without understanding what the actual root cause is.
• Or pushing practices onto the team without considering the highest priority impediments or when the team is not ready for the changes involved.

Some of these may be a stretch but I have found the exercise to be beneficial overall. It has allowed me to think deeper about Scrum and the role of the ScrumMaster. On top of that it was fun!

If anybody is reading this blog entry out there, I would like to hear your ideas about what the phrase “ScrumMasters should not go fly fishing for cattle” could be relevant to Scrum. Please add comments to this blog entry and I will look at and accept comments soon after they come in.

5 Comments »

One of the aspects of Agile software development methods that I believe is not well understood is the discipline it takes to implement and continue the use of good practices. Writing the test first, managing your build scripts effectively, and communicating impediments in the Daily Standup are all examples of areas which can slide as difficulty arises. This slow decay of our development processes I would like to coin as “Emergent Misbehavior”.

In the Principles behind the Agile Manifesto the last principle declared is:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As a reader of this principle I may be initially believe this to mean look at your problems and find ways to fix them. In this interpretation “problems” could be processes which are not working well. One issue with this interpretation is that it does not take into consideration what the team is doing well and could make improvements to. As teams continue to reflect only on their problem areas rather than how their entire process of software development can be improved they may slip backwards on their current capabilities and discipline. Below are some real world examples of “Emergent Misbehavior” that I have witnessed.

Daily Standup Now Every Two Days

A few teams I have worked with were having trouble understanding the value of a Daily Standup. As an Agile Coach I found it my duty to find out what in their processes and environment was causing the Daily Standup to be of little value to the team. Here are a few of the issues which emerged during reflections with the teams:

• a project manager who was questioning each team member about how they used their time yesterday
• Product Backlog contained disconnected items which were divided up to team members with specific capabilities and therefore team members were not interested in what others on the team were doing
• focus on updating the Sprint Backlog in a tool and questioning estimates of the team members
• managers attending Daily Standup and then “managing” team member based on impediments or discussion points they raised

In many instances a “smell” which was observed around Daily Standup value was team members feeling like they are being micro-managed. The teams interpreted their issues as their providing status every day was more of a distraction than valuable use of their time. Most of these teams initially dealt with these issues by conducting the Daily Standup every two days or twice a week in some instances.

Mini-Waterfalls Inside an Iteration

The incremental nature of Agile development methods are extremely difficult to master for teams used to Waterfall. As a team progresses from Sprint to Sprint and begin to “commit and deliver” on a regular basis they may be finding new processes for their software development. Some new processes that they may enact are:

• Finish each Product Backlog item including design, code, and test before moving onto the next item brought into an iteration plan
• Cross-functional team members working together on the initial functional test scripts before implementing the code and regression test suite
• Build and Integrate all system components on at least a daily basis
• Write failing unit tests before writing the code that fixing the failing test (Test-Driven Development)

As the codebase becomes more complex and potentially incorporates more integration with other platforms a team may slowly digress to what they knew before implementing an Agile development methodology. Some teams find that ambiguity in platform design means they must document the full design of all Sprint functionality before implementing any code. This reaction may be due to found rework, a failed design, or platform change issues such as database modifications or versioning. Rather than better understand where the ambiguity and problems in changeability are manifesting themselves the team is moving to a method which causes other potentially damaging effects.

Other teams may be having trouble getting a potentially shippable product increment completed each iteration. The team finds that time for QA is inadequate and therefore they institute a code complete date a few days before the end of the iteration. Problems created by this small process change may not show themselves for many iterations when the team is again having issues delivering on the iteration commitments. They may ask why QA team members are taking so long to do their testing or the team may decide to move back the code complete date an extra 1/2 or full day. This has now impacted the amount of business value the team is able to deliver each iteration since they have fewer days to code functionality.

Pressing a Team for Productivity

“Better, faster, cheaper” is a reasonable montra for many businesses. Emphasis on “faster” and “cheaper” without the “better” tends to cause decay in team productivity and product delivery. Product Owners may start out excited about their newly found control of directing product delivery but they can evolve as Mike Cohn points out in this article. This evolution may involve the question “How can we make the team more productive?”. The emergent misbehavior in this case may be falling back on traditional methods to get “productivity” in software environments. These include:

• Pressing the team to take on more work each iteration
• Incentives for working harder/longer
• Questioning team estimates on Product Backlog
• Introducing “stretch goals”

Any one of these may “work” at first and therefore act as confirmation to the Product Owner and/or managers involved in implementing the tool for gaining “productivity”. More iterations go by and quality issues start to arise which are now affecting the team’s ability to deliver even equal to iterations just before instituting the “productivity” gaining tool. The team have been meeting the expectations and incentives by giving more features but with less quality therefore accruing technical debt. Using these traditional methods for increasing a team’s productivity has backfired and now we must pay up the debt which is more costly than it would have been dealt with over each iteration.

Team Leaders Taking Over Team Responsibilites

Agile development methods tend to profess incorporating the thoughts of all team members in decisions based on informed consent. For anybody who has worked with people discussing a divisive issue and looking for common ground it is well understood how difficult consensus can be to achieve. Many issues do not cause the divisions on a team which could break down consensus building.

When an issue does arrive that is not so easily discussed and worked through then a team could jump back to traditional methods of decision making such as seniority or team leader wins. This decision making may not initially or ever cause negative effects if it happens on an infrequent basis. But if this type of decision making continues on a more regular basis it could cause some of the following issues:

• team members who will not speak up about their ideas
• task mastering by team lead or development lead
• lack of responsibility from team members for software delivery
• team members waiting for team lead or development lead to approve all work

These team problems could decrease or cap team productivity, demoralize team members, and make delivery on team commitments less predictable.

Tackling Emergent Misbehavior

In my experience, most of these and other emergent misbehaviors are the result of not fully understanding the causes of process challenges and taking the most easily available fix. The root cause of a challenge is not always easily apparent and may involve asking questions such as:

• When did this process challenge start?
• What variables could have been involved besides those that are obvious?
• Could our environment be changed to support a better result?

The answers to these questions may drive better insights into the actual root cause thus giving the team better information upon which to derive solutions from. Look out for Emergent Misbehaviors in your Agile software development process and use the retrospective not only to look for problems but also slippage in current process discipline.

1 Comment »

On many occasions as a trainer, consultant, and coach I am asked “if in Scrum the team is self-organizing how do we handle team and individual performance problems as a manager?”. From my point of view this question has multiple components that must be treated separately.

What is a “Team”

It takes more to form a team than slapping a group of individuals together and calling them a “team”. Teamwork can grow within a group of individuals who have a common goal and personalities which lend themselves to team building. As a manager we cannot make a team productive, we can only setup an environment to enable productive teams. So how do we setup such an environment?

Shared “Resources”

To start off with, people are not “resources” and the use of this word has been problematic for many organizations. Discussing people as resources gives management the idea that people in their organizations are interchangeable cogs that can be swapped around to meet needs in a reactive fashion. For instance, “we need Joe, who is knowledgeable on that particular application, so we can put Jennifer in his place on that project”. This assumes that Jennifer has the domain knowledge, context, background experience, same competency levels, and personality as Joe. Of course this is not true and therefore we may need to do some mental gymnastics to rationalize this transition but such a transition always has unplanned effects. To be fair, at times it may end up a net positive for the team and product delivery. The assumptions made do not support a predictable result.

In software organizations there may be a need to share “specialists” until their knowledge is shared to enough people or the specialized tool in question is minimized or eliminated. This situation has developed over time in many cases. We may have incorporated specialized technology platforms, maximized individual productivity, or minimized integration conflicts through individual code ownership. The risk associated with too much specialization is apparent in many organizations with mainframe environments using COBOL and individuals developing on these systems who may be close to retirement. An individual contributor may be the only person who knows the code for 1 or more systems. If that person were to leave development on those systems would be crippled tremendously.One way to combat the risks associated with shared people is to setup an environment which supports learning and knowledge transfer. Some techniques that I have seen to be helpful are pair programming, mentor programs, and brown bag sessions. We cannot remove the need for shared people but as managers we can work to make the organization more resilient to specialization risks.

Context Switching

While working with some organizations I have come across many instances of excessive context switching by people across projects. One day I was presenting the use of StoryTestIQ as an acceptance testing tool to a group. During the presentation one of the group members asked how hard it would be for them to use this along with all of the other tools they were currently using on their other projects. My “spidey-senses” started tingling and I asked this person how many projects were they currently on? They answered “seven”. I asked how they could possibly deliver on the commitments of all those projects. There answer is that they haven’t been able to and it has been a real pain.

We can help people do a more effective job by minimizing the amount of context switching they are responsible to manage. This problem sometimes manifests itself with particular specialization but I have also seen this become a cultural norm in organizations. Some potential areas of improvement that can be made in the organization for context switching are enabling sharing of knowledge, restructuring from project focus to product focus for software delivery, and ask the teams associated with a heavily context switching person how they can alleviate this issue over time.

Removing Impediments

As a team starts to commit to an amount of work and deliver that amount of work at the end of each iteration, the team’s velocity begins to stabilize. Velocity is the amount of work the team can do from a particular Product Backlog that the whole team estimated over a specified iteration length. Jeff Sutherland, co-creator of the Scrum framework, once told me that “you cannot expect team acceleration without removing their impediments”. Acceleration in terms of velocity would be an increasing velocity over multiple iterations.

Management can help teams accelerate their velocity by removing barriers to team focus on software delivery. These impediments may be items such as missing hardware, unavailable people, and technology platform issues. As these impediments are removed the team’s focus on software delivery should increase thus accelerating their velocity.

Wrap Up for Tonight

I have mentioned a few organizational environment issues which could be improved and could help your team(s) become more productive. We can help real teams develop by keeping good teams together. If we start to minimize the amount of shared people across projects we can begin to alleviate risks associated with individual specialization within the organization. Working towards more focus for people in the organization who are currently context switching between multiple projects can increase their productivity and projects they are associated with. Also, management can help teams accelerate their velocity by removing impediments raised by the team. All of these I have found have been more fruitful than telling teams to work harder or more hours. Those alternatives usually just lead to software which is more costly to maintain and slowly decelerates the team’s productivity.

Additional material of interest on this topic:

Pete Deemer message to Scrumdevelopment mailing list on IT managers and Scrum:  http://groups.yahoo.com/group/scrumdevelopment/message/22323

Gerald M. Weinberg on Evidence that Teams are More Productive: http://secretsofconsulting.blogspot.com/2007/10/evidence-that-teams-are-more-productive.html 

1 Comment »