On an agile team, there are differences and dynamics at work that can help either make the team more successful or less successful. A good coach and/or scrum master should be able to see signs and patterns on the team where differences exist, and use dynamics as leverage to get the team moving in the right direction.

Differences
There are differences on all teams. Difference shows up in many forms and factors in an agile team. There are differences of opinion, differences in roles, even differences in genders. There are differences in seniority levels, differences in skill levels, and differences of understanding how best to serve the customer. Each of these and other differences can either drive a wedge between team members, or be used as a lever to help guide the focus.

Once we recognize that there are always inherent differences from many perspectives, we can choose to either amplify or dampen the effects of these differences. When teams have both introverts and extroverts, the behaviors of these team members can be quite different. These differences in behaviors for these two types of personalities can be quite disruptive. This is a difference we need to dampen. We can dampen this difference by choosing consciously to recognize the traits of these personality types as a team, understand how they operate and recognize behaviors. When the team understands what behaviors to expect, the behaviors become normal or expected, and people on the team can deal with them effectively. Dealing effectively with the behaviors can dampen the effect of this difference, and help guide the team towards better synergy.

There are other differences that also might be dampened. Level or seniority differences can be a big part of behaviors on a team. Because a person is a higher level in the organization than others, some people may tend to behave differently either consciously or subconsciously towards these people. These differences can and should be dampened by discussing the issue as a team, and everyone knowing what the role is and why they are there, in the context of that team. A working agreement can be struck such that within the team, everyone knows what to expect of everyone else there. The expectations and roles being agreed upon in advance can help dampen this difference.

There are other differences that perhaps should be amplified instead of dampened. Differences of opinion can be a hot topic in a team, but these differences in the end make a product and a team better. Differences of opinion should not be dampened, but encouraged. Not everyone should think alike. Different perspectives generate new ideas, and that drives innovation and discovery. Differences of opinion sometimes generate heated discussions, however the passion can be partly diffused or at least deferred. Team members may be passionate about a particular opinion, but if differences are encouraged, team members will grow to respect others with a different opinion, as they see these differences at times paying off with higher quality software. The difference in opinion can be not only healthy, but essential to the growth and well-being of a high-performance team.

Differences can be used as a tool to help guide a team, or can be its undoing as well, if left to chance. Great team leaders, coaches, and scrum masters can recognize where there are differences and use them as a lever to guide the team in the right direction.

Here is an article in the Agile Developer series, about Continuous Integration or CI. Why is Continuous Integration is important? Here is some of the philosophy of how we think of CI and some discussion of practical applications. It is a short slide deck presentation in both PowerPoint and PDF formats.

http://testdrivendeveloper.com/2009/02/10/AgileDeveloperSeriesContinuousIntegration.aspx

Here is an article I posted a while back on what makes a successful agile developer. What makes a successful Agile developer? How are Agile developers different from regular developers? Here is the article with a short presentation and video on the topic.

http://testdrivendeveloper.com/2009/02/01/WhatMakesASuccessfulAgileDeveloper.aspx

One of the large benefits of agile teams should be the transparency to see how things are going at any given time. A team typically has a burn-down chart that shows daily (or more frequent) updates to tasks and stories. This chart is a key to seeing if the team is on-target for delivering what it committed to at the beginning of the sprint. Sometimes the estimated time remaining actually goes up, indicating that delivery will be delayed. This information is critical in trying to manage a project. Problems with delivery are part of the software development game, and should be visible so they can be mitigated.

If we see a trend either flat or upward in the burn-down chart (burn-up as it's called), we should be able to react to this information by talking with team members about what is preventing progress from being made. We can take a variety of actions to address impediments - cut stories, re-focus other team members to swarm on tasks, and other things to try to get back on track making progress toward delivery. However, if we don't have the rapid feedback of the burn-down chart, it's hard to see what the current status of the project is. This chart is the heartbeat of the project.

Team members should do their best to estimate stories and tasks, but as we all know, estimation is usually less accurate at the beginning of a task. When we know more, we should be updating the task estimates for time remaining. Using tools like Rally, Scrumworks, or other products, the work and time it takes each team member to add new tasks and change the time remaining estimates should be minimal and manageable. Make sure to remind team members how important it is to keep the tasks up to date on at least a daily basis.

As an agile team, we should be able to see where we are at all times. This information ideally should even be radiated real-time in the team space so everyone can see how things are going - even the casual passer-by. Problems should never be hidden. Problems always come up, and they get solved not by secrecy, but by publicity. The more minds we have on solution, the faster problems can be resolved. We should never look at problems or impediments as either personal or team failures, quite the opposite in fact.

The team should always be able to see how it is doing, and a good self-directing team will notice its own burn-down impediments and re-focus itself on solving the issue without outside help. Newer teams may need the assistance of a scrum master to call out impediments, but the team should still be responsible for addressing its own issues. Only in personnel or political issues should "management" be brought in to assist with solution. If there are roadblocks, the team should be able to call on the scrum master to assist in bringing in anything needed from outside the team.

Once a team really understands the real power of task breakdown and continuous update of time remaining, they can gauge themselves on their own progress and what needs to be done to address anomalies, avert crisis, and succeed at delivering their commitments.

After some training in the estimation technique of Wideband Delphi, I have tried it out in a real project/team environment. I think it was an interesting result, but as a single data point so far, I would hesitate to assess the tool as a success or failure. I will be curious to see how the estimate tracks to actuals for the feature... The use of Wideband Delphi in the initial stages of a project may be a good tool for rough sizing of features or whole feature areas. I am a bit leery of assigning "hours" [ideal hours] to estimates at this very high level of granularity though. Sometimes hours find their way to get turned in to schedules... and ideal hours are even more dangerous as they aren't fully loaded.

The cone of uncertainty is a nice principle that I think might perhaps need more airtime. (Not being a project manager, its a new one on me...) It states that at the beginning of a project, when the least is known, the estimation error can vary from .25X to 4X (not sure where these numbers came from). And as we move toward project completion, the estimation curve shrinks on both sides exponentially to approach 1 at project completion. For more information see the cone of uncertainty link.

However, as the "cone" narrows and we are a bit more certain of what it is we need to deliver, I still think the planning poker type of consensus estimation is more appropriate. It seems a bit lighter weight and much quicker for estimation. Granted, however that planning poker is a tool to be used at the story level (and estimates in points NOT hours), it might not do as well as the WD estimation at earlier stages. It is a similar process, but seems to be a faster implementation.

WD could be a useful tool for backlog prioritization and even perhaps story generation. I am not sure how valuable estimates from WD might be other than to help prioritize (in size and cost) less-well-known things in the product backlog. I still think that the planning poker is appropriate at the sprint and story level though, rather than WD. Another thing that strikes me as different is that WD doesn't necessarily engage the whole team doing the work - only "experts." I like to have the entire team exposed to the information and the planning, even if team members don't have much value to add to estimation at that phase. In my opinion, it helps with information sharing, project background, and overall depth of understanding.

Use the right tool for the right job I always say. I carry four screwdrivers in my toolbelt, two sizes of flat blades, and two sizes of phillips... Use a tool for its intended purpose. Watch out for trying to get too much out of estimation at an early phase, and definitely involve the team - they are going to be the ones who help the project actually come to fruition.

Don't be a Scrumbut.

But is it really OK to be a Scrumbut? Can the scrum process work if every one of the pieces of the methodology is not followed exactly?

Perhaps...

Scrum works best when all of its pieces are used in the process. It is unlikely that the full benefit of the agile methodology will benefit from an incomplete process. However, in the real world it is sometimes very difficult to get an organization to adopt each and every piece. I think however, that even the teams using incomplete scrum might still be able to get some value out of the pieces that are adopted. Sometimes being a Scrumbut is still better than floating in the barrel as it goes over the waterfall...

It's not a perfect world.
If you happen to be on a scrum team that really gets the idea of scrum and is able to make each of the pieces of scrum work for you, then I say you are a very lucky person indeed. Personally I have been on several teams this way in my career and I can say that there is no better way I've ever seen to develop software. But while the world is round, it isn't a perfect sphere. Sometimes things are a little bit off. Yet, I believe that things can still spin around and everything can still work, if there is a clear plan.

Why?
As a consultant, my first instinct is to look at the process being used and question everything. I ask people why things are the way they are. Especially when I see something that doesn't seem right to me, coming from a perfect scrum background. Sometimes it takes time for an organization to be able to trust a new process. Some organizations have to bite into something new in pieces rather than adopting a completely new process all at once. I don't like it... it's not the best way... but sometimes it's the ONLY way. Something is better than nothing - as long as it is adding value. That is the real test I think: does it enhance the value of the software delivery process?

Yellow Light
Caution. That is the word I use when I see Scrumbut in action. I am looking for signs of devolving process rather than evolving process. If a team has adopted scrum's tenet of documenting what is actually delivered rather than big documentation up front, but then really isn't getting the concept or delivering the documentation as required by the stakeholders, the it really isn't working and someone is going to be dissapointed. Dissapointed stakeholders can then poison the entire organizations' view of the scrum process, and that can be the last nail in the coffin. Caution I say - we don't want to let this happen.

Perfection vs. Good Enough
I strive for perfection in the process but it's really a very lofty goal. As a consultant though I have to realize that I am there to help improve the process, not get it to perfection. I need to look for the warning signs that might dissapoint stakeholders, and advise course corrections for these things when they come up. Practiality is essential in software delivery, even if imperfect in process. The iterative model should give value, even if each of the pieces of the process isn't followed completely.

So, don't be a Scrumbut. Unless you have to. then if you have to - make it work, and watch for the warning signs...

There are times on a scrum team when things don't go quite as planned in a sprint. Sometimes things get in the way of accomplishing tasks and the estimated time remaining on tasks either stays the same or rises. It's not an uncommon circumstance on most teams. However, when burn-up happens, we need to understand what's going on with the team and how we can address it to make better forward progress.

Burn-up is usually an indication that task estimation is not as accurate as is desired. There are other issues that can cause it as well, but estimation is usually the biggest. The whole reason we do the Scrum process is so we can get feedback on a short interval and we can learn from our small mistakes. We then can get better at what we do, increasing our velocity and reducing the estimation errors as quickly as we can.

Here are some of the things to watch out for which I have found cause burn-up to occur - and what can be done about it.

• Poor estimation - this is a big one. After all, estimation is one of the big reasons we do Scrum...
• Estimates are too low, because tasks were not broken down into small enough pieces.
• When sprint planning is cut short or not enough emphasis is put on analyzing the story by the team, some things can get missed. Encourage the team to take the time to think carefully through the story and do a bit of design and a bit of architecture for the story so it will be clear what needs to be done to complete the whole thing. Estimates for tasks should be in hours, and ALWAYS be SINGLE-DIGIT. If your team is taking a different approach - this could be a warning sign.
• Unclear/Misunderstood story
• If a story is vague or too complicated, it will be difficult to break down, and estimation will typically miss lots of things that will expand the estimates as they are discovered. I have seen the teams gloss over some complications just because they are scared to deal with it in sprint planning - fearing it will eat lots of planning time. Avoid the complicated stories - think in thinner "slices" of functionality. Make sure that everyone is clear on the terminology used, and that it's the customers vernacular. Everybody should be speaking the same language and one term should mean the same thing to each team member and customer alike.
• Poor acceptance criteria
• Acceptance criteria are critical to successful estimation. Spend at least 1/4 of the sprint planning time on discovering and documenting the acceptance criteria for stories - up to half the time if really needed. The acceptance criteria are really THAT important.
• Leaving things out
• Teams tend at first to see and estimate only the mainline development tasks. If a team is constantly missing estimates for stories, emphasize having a DONE list that enumerates what it takes to complete a story. Include tasks from the DONE criteria in the story tasks if they are being forgotten. There are those who might disagree, but I think there is nothing wrong with having lots of repeated sets of tasks for each story, if it accomplishes the goal of better estimation. Add test/qa tasks too if they seem to be getting left out of the estimates/
• Work on items not in the sprint backlog. This is a big one also.
• People are being randomized with tasks not on the backlog. This kind of thing is not supposed to happen, but it does. The world is not a perfect place - so be it. When these tasks happen, get them on the backlog! Don't slip them in under the covers. Even (and especially) if the tasks are not related to delivering the software - get them and their hours in the sprint backlog. At the very least they can be covered in the retrospective and they will be brought out into the light instead of being hidden.
• Production problems. This is a tough one. It can't always be estimated or guessed at. But, most teams budget a bit of time each sprint for production support. Call it a spike, or time-box the estimate at a certain percentage of the sprint's total hours. This may not be accurate, but at least we can account for it with a place holder. Production problems are usually a process smell anyway, but that discussion will occur elsewhere...
• Extra management-added tasks. A Scrum master should be insulating the team from these kinds of changes. Scrum master needs to better negotiate with the management that is adding tasks and explain to them why issues like this can derail a team.
• unforeseen meetings. Sometimes meetings are important and required, and aren't known at sprint planning time. A Scrum master can negotiate for these not to be attended by the team or at least part of the team. The Scrum master can at least explain how these meetings stall progress on delivering software, and make the case for comparing the software delivery value for that time to the benefit of attending the meeting. In most cases software delivery wins...
• Out of the office or illnesses. These can't be predicted. If they occur on a regular basis, a Scrum master can take an educated guess at what these absences might be and enter an actual story for it. While I don't particularly like this approach, when it is on the sprint backlog, it does get visibility for the issue.
• Work items that weren't estimated in planning. Are things like extra features or enhancements being added to existing tasks? If it wasn't asked for specifically, it shouldn't be written. Good acceptance criteria here would be a great yard stick to determine if these work items are really relevant. Make sure as a Scrum master that you are keeping the team focused specifically on the exact functionality to be delivered.
• Team members not updating the remaining hours
• This is a relatively common but easy fix. I like to remind people just before stand-up to make sure to update the sprint backlog with today's estimates on time remaining for tasks that are in-progress or not yet started. Every day we know more, so we should be able to fine-tune estimates as we go along. We depend on these changes to make our sprint backlog burn-down as we work.

Scrum specifically states that we should not be working on anything that isn't specifically mentioned in this sprint's backlog. There are however, practical issues that come about which will almost certainly require us to be flexible on this point.

If we use these points as indicators and even as alarms, we may well be able to keep our teams on track and deliver more software functionality to our customers.

Why is your team doing Scrum? Check the appropriate box below.

Somebody's boss someplace said we have to do Agile now.
Agile sounded like a good thing to have on my resume.
Our software has problems and Agile is the magic bullet solution.
Our team wants to get better at quality software delivery and estimation.

Those of you who chose the last option, keep reading. Everyone else, please click HERE.

We do Scrum because the process yields better results. We do it because we want people to think and be empowered as a team, rather than just being told what to do. We want our software to please our customers. We want to please our customers regularly and often. We want to be able to respond to changes in direction, changes in requirements, or just change in general - in a positive way and continue to deliver useful software. We like the notion of teamwork and collective ownership. We like collaboration. We like to get feedback often, and integrate it into our process so we get better, faster. We measure our success and progress only in terms of delivered, working software.

Scrum is more than a process for managing projects, it is a change in mindset. Just deciding to do mini-waterfalls in 4-week cycles isn't Scrum. And it isn't very useful or productive either. [BTW just so we're clear: A mini-waterfall looks like a 4-week "sprint" where the first week is design and specification generation, two weeks are coding, and the last week is testing and bug fixing.]

It takes a mind shift to a willingness to be a TEAM rather than just a bunch of people working on the same project. There IS a difference. Without an attitude of cooperation and collaboration, Scrum will not succeed (nor will any approach really), and Scrum will just seem to be an additional burden to those forced into it.

Don't mandate that your team adopt Scrum. Explain to them why it's better. (At this point I should probably mention that YOU should understand why it's better...) Convince them. If they aren't convinced, keep at it until they are. If they are skeptical, that's OK but they need to be open-minded enough to actually try it for a while. If they aren't truly open-minded, or can't be convinced - DON'T DO SCRUM. This kind of a process needs to have WILLING participants that are cooperative. It's not for everyone. Be prepared for the fact that some people just don't get it, or WON'T get it. They really need to find a different team to work on. Don't burden those on a Scrum team with members who don't want to be there.

Scrum is not a silver bullet. It's not always the answer, but it is ONE answer. Educate your team. Be supportive, and explain why the tenets of the Agile Manifesto and the twelve principles behind it are a good idea and that they can really work in your organization.

More advice. Have a Scrum master. This person should be trained in the role and understand it. Have a true Product Owner (NOT the Scrum master by the way) who represents [ALL] of the stakeholders. Make sure they really do identify and represent the real stakeholders, and have the authority to prioritize. Hire a Scrum consultant, or bring in an experienced person who has helped teams get up to speed on Scrum - and LISTEN TO THEM. Don't pick and choose which pieces of Scrum you like at first, just do them all "by the book." You can fine-tune your process in response to sprint retrospectives later.

Scrum can be a great way to develop software, or it can feel like a horrible burden. It all depends on the attitude and openness of the team doing the process. Make sure you make your experience the former instead of the latter.

Here is a kind of step-by-step guide to doing pair programming. If your team doesn’t adopt any other principles of XP or lean, this is the one thing that will give the greatest benefit for adoption. This is a good recipe for ROI++.

 

Attitudes

In my experience, programmers are the least willing of all professionals in the software development industry to be paired up on tasks. For some reason, we developers seem to have attitudes and fears about this mode of work. I have heard attitudes expressed like "I don't want someone to be nitpicking every character I type," "I dont want to share my keyboard." There are also un-spoken fears that I have heard told: "They might find out that I'm not as smart as they think I am," "the other guy might make me look stupid," and "I don't want them to know how I really write code." These attitudes and fears are the number one barrier to doing pair programming.

 

C4 Requirements Checklist

For people to be able to do pair programming, I suggest the following readiness checklist to determine if someone is ready. Not everyone is at a point where pairing makes sense for them. When creating a team to do pairing, it is important that everyone have an open mind to trying the process. Give the list to the people and let them do it on their own, and decide for themselves. Don't collect their lists, just their yes or no answer.

 

1. Am I willing to Cooperate – do I really want to do this or is someone just telling me I have to do it? Am I bought-in to the idea or is it being forced on me?
2. Am I willing to Collaborate – can I work together with others in a team environment where we all pitch in together to accomplish a task, or do I need to do things only by myself to be successful?
3. Am I willing to Communicate – can I tell my team mates what I am thinking? Can I get a point across verbally? Can I take a spontaneous thought and talk it through verbally and get someone else to understand me? Am I willing to work toward these goals if I’m not quite there yet?
4. Am I willing to Create – can I be of a mind-set that I am creating something of value regardless of the process, and am I willing to try something new to accomplish this?

 

Implementing It

If your team is on-board with the C4 checklist, congratulations! You now are able to start off on a wonderful process of building some great software. My suggestion now is to get some resources together. Here’s a starting recommendation.

 

1. Pair Working Space

1. The team should ideally have a smallish space to do their pair programming work. This should be separate from offices or cubicles. While this is not always possible, I have seen some great creativity used to put the team together in their own space. Sometimes this means just adopting a round meeting table in the middle of a cube farm. Whatever it means for your team, do establish the pair working space. Use the guideline of 6-8 square feet per person, and keep the team size under 10.
1. Desks, chairs
1. One desk for every two people, and one chair per person, with one extra chair is just about perfect. Don’t have the desks more than a few feet apart. Keep the team together in a smallish space. This will greatly aid cross-communication between pairs while development is happening.
2. Machines
1. One development machine per desk. Two team members will be sharing one machine.
3. Monitors, Keyboards, Mice
1. Two of each per desk. Space them two feet apart so that people can have a little personal space. Connect both monitors to the dual-head video card, and clone the display so both have the same image. Use USB keyboards and mice, and place one each in front of each monitor.

 

Orienting the Team to Pairing

Be sure to orient your team to this kind of thing first. Let them know that they will be expected to work together on one machine sharing control, but that each will have their own keyboard, monitor, and mouse. Remind them that cooperation and verbal communication is essential when working with a partner.

 

Hours and Etiquette

When working closely with other people in this way, we need to be polite, focused, and productive. There are times for all of us when we just aren’t all three of these, and that’s OK – it’s just human nature. We need to be able to “check out” and go elsewhere if that’s the case for anyone at a given time. [Assuming a standard 8AM-5PM day…] Start pairing at 10am, take lunch at noon, and stop by 3PM. This gives everyone some time to work on other things or take meetings outside of pairing. Adjust times accordingly for your team, but this is a good starting point. Don’t make the mistake of thinking your team can pair for 8 hours a day. A 5 or 6 hour pairing day is a lot, even for an experienced team.

 

Challenges

At first, there may be personality challenges. Some people are more easily able to communicate and share control. Don’t worry if the first few days are a bit rocky, this actually can be a good learning experience (as long as nobody blows up). Keep an eye on tempers to make sure that hot situations can be defused before they cause problems. One technique that works well is to switch pairing partners at the middle of the day, or at least every day. This gets people new learning experiences and moves knowledge around the team (another great benefit).

 

There is one specific challenge that I want to bring up, because on a pairing team it can be a real issue. Everyone should wash their hands. A lot. We shouldn’t have to remind people to wash after visiting the bathroom, but DO it anyway. I encourage and ask people to use hand sanitizer before touching the keyboard at my workstation. Bugs have really gotten nasty out there, if you haven’t noticed. If there is an illness, be sure to make the people stay at home, or a single cold or flu can wipe out all development pretty fast. I recommend spending $2 for a small bottle of hand sanitizer for every workstation and placing it in plain sight.

 

Benefits

• Team knowledge share
1. Knowledge will naturally migrate through the team, since people working together will share knowledge about a task. Rotating people through tasks is a fantastic way to raise product knowledge and awareness for a low cost.
• Better code
1. Two pair of eyes on a piece of code are always better than one pair. We sometimes call this process “real-time code review.” Mistakes are simply caught far, far sooner. Code mistakes and poor design decisions simply just evaporate as two people think about the code as it’s being written.
• Quicker code
1. Not that it executes faster, but it probably will do that too. A pair can produce a solution to a feature request far faster than a single developer in almost all cases I have seen, and every study I have ever read. It’s not half the time, but it’s probably more like 2/3 (a 33% speed improvement for you percentage folks…)
• Tight-knit team
1. The team will be more integrated, stick together, be more cohesive, and more social together. People on a pairing team will be united for the delivery of a product, and it the experience will form bonds between team members.
• High-performance team
1. Pair programming teams will almost always outperform teams that don’t use this technique. The more experience teams get to have with pairing will yield even higher performance results.
• Higher morale
1. Teams that use pair programming are almost always happier, and more positive about their working experience.

Summary

When we find the people who have an open mind, and are committed to success as a team, we have a great asset to leverage to write good software. Using the technique of pair programming in a shared workspace, we have many benefits for all - the company, the team, and most importantly, the customer. It takes a little work to get to a high-performance team, but it really isn’t much, and in my opinion, easier than finding a way to coax performance from a non-paired team.

 

If you have any input or feedback on this article, I welcome it – please post a comment below.