A Team in Conflict Can’t Be Agile

It’s tough to be agile when team members collide. Heck, it’s tough to just get anything done when you have members on the team that don’t get along.

It’s unfortunate but it happens — often. Why can’t we all just get along?

Hostilities develop for many reasons. At times, it seems that there is no reason at all. Regardless of the reasoning, you have to deal with the conflict or the entire team is in jeopardy.

The topic of conflict resolution is complex and extensive. I can’t do justice to it in a single blog post but here are a few thoughts to get you started:

• Confront the problem. How you approach the combatants depends on your relationship with each. If your relationship with them is strong, an informal discussion can work. A weaker relationship demands a more formal approach.
• Chat with each individual privately and informally to express your concern. Try to get each to acknowledge that a problem exists and that the problem is hurting each of them and the team.
• Meet with the parties together. Identify the underlying issue(s) for both. What is each unhappy about? What does each really want of the other? Ask lots of questions. Get them to talk openly.
• Brainstorm. Toss ideas around. Get the participants to present ideas and suggest solutions. Seek out a compromise that is genuinely acceptable to both sides.
• Agree to try out the compromise solution. Implement it and re-evaluate as needed.

You don’t have to be their administrative manager, tech lead, project manager, ScrumMaster, etc. You might just be a team member genuinely concerned about team dynamics.

This won’t be easy but it has to be done. You can’t be agile when your team is in conflict.

Be Agile to Innovate

Innovation is not a technical problem. Anyone can innovate. It’s a cultural problem. Big organizations block innovation by pulling every idea into the corporate mainstream.

It works something like this…

Employee: “I have great idea. There is an untapped market for X and we are in a unique position to capture it.”

Manager: “Yes, you’re right. We just need to make X compatible with Y and, of course, we can’t impact sales of product Z.”

Employee: “Okay, I think we can make that work. I can pull a team together and start right away.”

Manager: “Right. Make sure you speak to John Smith, Jane Doe, Gill Gold, Sally Silver, etc. We need to get everyone on board with this.”

You know what happens next. By the time the employee speaks with everyone that has a “need to know”, the idea is so watered down that it is no longer innovative. It’s conforming.

Such scenarios are played out daily in corporate America and are about as anti-agile as you can get. Often, the only fix is for the employee to quit and start his own company.

The alternative is to identify a senior manager that is known for innovation and win her over. She most likely works in either Business Development, Marketing or Research and Development. Find her!

There is a great blog post at the Harvard Business Review called “31 Innovation Questions (and Answers) To Kick Off the New Year” by Scott Anthony. I especially like point #18 — Why is innovation so hard? Most organizations are designed to execute, not to innovate.

Ready, Set, Stop. Energize!

The week between Christmas and New Year is historically focused on family, not business. Plenty of business gets done, but staffing and intensity levels are reduced.

We all need time to unwind, decompress, chill out or simply relax.

It seems that many of us make ourselves available 7 days a week, 16-24 hours a day. Our bosses, clients, business partners, employees, etc. expect us to be at their disposal all the time.

In many cases, we do it to ourselves. Mobile devices make it so easy to stay in touch and always be available.

Take advantage of the lull. Conduct a personal retrospective. Create a plan for 2011. You’ll enter the new year stronger, energized and confident.

Sports Lessons Learned for Agile Development Teams

There are some interesting similarities between professional sports teams and agile development teams. Think about it. Whether it’s baseball, basketball, hockey, (American) football or soccer, teams spend a lot of time training and conditioning. They prepare a game plan and create player match-ups.

As the game unfolds, they make adjustments. No game ever goes exactly as expected so changes need to be made and everyone needs to adjust.

Sound familiar? Software development teams also train and condition — mentally if not physically. They prepare project plans and match-up developers and testers to work together.

As the project unfolds, they make adjustments because no project ever goes exactly as expected.

So, what can we learn from professional sports teams that will help us do a better job as software developers?

• Focus. Develop mental toughness. Deal with the problem at hand. Don’t think too far ahead.

In any company, there are many distractions. The bigger the firm, the more distractions there are. No one can be 100% productive, 100% of the time, but teams need clear goals, clear tasks, clear expectations, and clear leadership.

Without clarity, a team will flounder and wander as it seeks definition. Is your team focused?

• Learn. Keep learning new things. Keep improving. Never take the current situation for granted.

The best sports players constantly improve. They never stop trying to better themselves — even during the off season. Technology changes much faster then sports. Are your team’s skills up to date? Do they have access to training materials and expert advice?

• Plan. Have a plan for each day. Know what the goal is. Don’t waste time on things that don’t matter.

Sports teams don’t plan out the whole season. They know what they want to accomplish during the season and have a high-level plan to get there. However, each game is unique and has a detailed plan.

This works just like agile planning whereby you have a high-level project plan and detailed sprint plans. What do your plans look like?

• Adapt. Be flexible. You will need to do something unexpected. Don’t fight it.

This is one of the biggest problems with big-company, waterfall development — too much time is expended fighting change in order to protect the plan. It’s not about the plan. It’s about customer needs.

Just like players on a sports team, your team members need to be ready to do whatever is needed to make the team successful. Do your team members have that attitude?

Many of us enjoy watching sports. Let’s try applying some of the techniques athletes use to our software development teams.

Distributed Agile Works Better

Let’s be honest — managing geographically distributed teams is tough. Here’s a simple breakdown of how teams might be distributed from least distributed to most:

1. Shared space: This is the simplest. Everyone is in close proximity in a shared office area.
2. Separated shared space: Everyone is in the same building but in different areas/floors.
3. Different buildings: The team is housed in different buildings not within walking distance.
4. Long Distance: The team is separated by many miles but in the same time zone.
5. Time Difference: The team is in different time zones but only a few hours apart.
6. Day Difference: The team is many hours apart and normal work hours barely overlap if at all.

As you go down this list, managing the team becomes more complex. Can agile software development work even at #6? If so, will agile techniques make the process better?

I think the answer to both questions is yes, with a few qualifications. Agile works best when teams can collaborate constantly. Questions should be asked and answered immediately. Issues should be resolved or backlogged right away. Being widely distributed adds complexity.

Teams often fall back on waterfall in these situations. The feeling is that if you write everything down in excruciating detail you minimize the need for collaboration. That is so wrong!

Bulky documents are hard to understand under the best of circumstances. Add in language barriers, just to make things interesting, and you have a failure waiting to happen. Do not try this at work!

Instead, adopt some or all of the following agile measures:

• Automate. A physical status board (e.g. Scrum or Kanban board) will not work. It must be electronic and shared by everyone.
• Settle on good collaboration tools. Email is not enough. You’ll need some form of instant messaging for conversations and a private Twitter-like tool such as Salesforce.com’s Chatter will also help. Invest in video conferencing if you can.
• Keep your iterations or sprints short. 4 weeks is an absolute upper limit. 1-2 weeks is better. You’ll want frequent checkpoints to validate that everyone is in sync.
• Daily meetings are tough when many hours separate the team. Be creative. If the meeting is truly inconvenient for some, can you offer something in exchange for making the effort to attend? Can the meeting time change periodically to spread the inconvenience? Would meeting 1, 2 or 3 times per week be adequate? (If your sprints are only 1 week long, maybe you don’t need a daily meeting.)

Distributed software development is an area where agile techniques shine. Agile reduces risk and improves team dynamics.

Agile Development Is Not All Or Nothing

The transition from chaotic software development to agile has got to be easier than the transition from waterfall to agile. If a team is not following any process — just winging it — adopting a structure, any structure, can only help.

In my experience, people don’t like chaos — complete lack of any process — nor do they like a rigid, tightly-controlled process. Agile software development presents a comfortable middle ground to teams in chaos.

On the other hand, teams that are using the waterfall approach already have some structure. The process may have holes and weak points but at least it offers rules and guidance.

Waterfall teams turn to agile development for one of two reasons:

1. Too many projects are late, over-budget, and/or buggy. The company needs better results.
2. The competition is getting products and services to market faster. The software development team needs to pick up the pace.

Often, out of frustration, management decides to try something new and agile is a hot buzzword. The team is likely to feel stressed and likely to be resistant to any new approach.

A better way to go about this might be to introduce agile techniques while still using waterfall. Consider the following approach as an example:

• Use planning poker to prepare your development estimates. Forget points. When estimating features, modules, tasks, etc., get the team together and compare estimates. Discuss and arrive at consensus. Use the basic concepts of planning poker to get the team used to the idea of generating estimates together.
• Hold daily 15-minute meetings. Get the team into the habit of making daily commitments and sharing information.
• Hold retrospectives at the end of each project phase and after major deliverables are achieved. Seek continuous improvement.
• Have some developers try pair programming and report back to the group on their experiences.

By adopting some agile techniques and getting the team used to the concepts, full-scale agile adoption will be easier and more likely to succeed.

Oh, and please go through with full-scale agile adoption. Things may improve by simply doing what I describe above but you need to commit to following through to get all the benfits agile software development offers.

Business and Technology Worlds Collide

Dealing with the business users of a software application can be a real challenge. It’s rare that you find a user group that embraces agile software development and wants to actively participate in the process.

There are two predominant types of business groups that you’ll encounter in agile development. The first is a business group that just wants you to go off and build the software. They’ll be happy to answer questions but are too busy to participate in the development process in a meaningful way.

Try negotiating for a business representative. This should be someone who can commit to attending daily meetings and will make the effort to test sprint deliverables. It could be anyone as long as the business owners trust their representative’s judgment in making software decisions. That’s probably the best you can achieve.

Another type of business group is one that is constantly changing features, functions, goals, process and anything else they can. It’s a major challenge to get such a group to settle down. This behavior is likely to be a reflection of how they operate in general. They won’t change.

The only thing the development team can do is anticipate change. You can’t predict what will change next but you can take some extra time to make the system flexible — not easy to do, but you can minimize the effort needed to make software changes.

Getting business participation on an agile project can be tough. Take what you can get and make the best of it.

Scrum in Trouble? No, It’s the Engineering.

There seems to be a small but loud group of agilists proclaiming that Scrum is dead or dying. I’d guess that many of them declared that waterfall is dead at an earlier time. They were wrong then and they are wrong now.

I think many of the Scrum critics have an agenda. They either have a vested interest in another approach like RUP or Kanban, or they are “experts” looking for media attention.

Let’s start with waterfall software development. It is alive and well, particularly within major corporations. I say ‘well’ in the sense that waterfall is widely used and even succeeds often enough to remain viable.

Sadly, one of the primary reasons for its ‘success’ is low expectations. Many have come to accept that software development is slow, late, defective and expensive. With expectations so low, it is relatively easy to succeed.

But I digress. The point is that waterfall lives on and even prospers in a sense.

As for Scrum, it has met with considerable success. It is relatively simple to understand and adopt. It is also easy to customize and that’s where the problems begin.

Many teams using what they call Scrum have modified waterfall to make it Scrum-like. They may call their software development approach, Scrum, but it’s not. The inevitable clash between agile and waterfall occurs and Scrum gets the blame for being hard to do well.

The truth is that software development is difficult regardless of the methodology used. Scrum is not in trouble. Software engineering is in trouble.

In the end, people make the difference. People succeed or fail — not projects and not processes.

Be Agile: Build a House Iteratively

People often struggle with how to apply agile techniques, particularly iterations or sprints, to their situation. They are so entrenched in the ways of waterfall that they cannot envision another way.

Let’s consider a simple example — building a house. The traditional approach looks something like this (simplified):

1. Design the house.
2. Dig a big hole.
3. Pour the foundation.
4. Frame the structure, walls, floors, ceilings, and roof.
5. Run the plumbing, heating and electrical systems.
6. Seal up the structure with the appropriate materials, wallboard, flooring, roofing, etc.
7. Install cabinets, appliances, fixtures, etc.
8. Paint, wallpaper, carpet, etc. to make it feel like a home.

Many people have a hard time looking at the design of a house and envisioning what it will look and feel like. They often end up disappointed in some respects.

What if you hate disappointment and want to build the house in sections so that you can try it out before completing the project? It’s hard to envision how this could be done using agile techniques. How do you break this down into “stories” where you can build vertical slices?

Think in terms of modular construction. To start, you have must a kitchen, bathroom and bedroom. The rest can be added. You build components and tie them together something like this:

1. Design the first components.
2. Dig a small hole.
3. Pour a foundation for the kitchen, bathroom and bedroom (one story).
4. Frame the structure.
5. Run plumbing, etc.
6. Seal it up.
7. Install cabinets, etc.
8. Paint, etc.

You can move in and try it out. Want more space? You have two options, add a second floor or enlarge the foundation.

To add a second floor, repeat the above skipping steps 2 and 3. (Of course, you’ll need to remove the roof!) To enlarge the foundation, do not skip steps 2 and 3. (Of course, you’ll need to remove a wall or make a doorway!)

If you used pre-built modular housing sections, this approach would be simpler and faster though your options would be more limited.

Of course, it’s unlikely you’d build a house this way simply due to the inconvenience. But, it could be done and the final result is much more likely to be exactly what you want.

There is some re-work involved but be honest — every project contains re-work. The amount of re-work varies but it is inevitable on all but the simplest of projects. Admit that it happens and plan for it.

Software is easier to “enlarge” than a house so the approach is more practical in the software business. Agile software development really works — you just need to wrap your head around the concepts.

The Scrum/Kanban Board: Physical or Electronic?

There are two kinds of agile teams — those that use a physical Scrum/Kanban Board and those that use an electronic one. Which is better?

Without a doubt, the answer is … whichever one works for your team! Neither approach is fundamentally better than the other though the electronic approach has a major downside that you must work around.

Have you ever been in a meeting where the organizer is using a projector to show a document or spreadsheet? She makes updates as you watch and is in total control of the whole process. At times, you just want to grab the keyboard and change something yourself!

The danger of using an electronic Scrum/Kanban Board is that the person holding the keyboard will dominate the daily stand-up meetings and control the outcomes.

The nice thing about a physical Board is that anyone can walk up to it and make a change. It is fully visible at all times and presents the project as an “open book”.

I think an electronic solution can still work. You could use a specialized solution like Jira/GreenHopper or simply use a spreadsheet. If you go the electronic route, here are a few guidelines:

• Provide software licenses to everyone on the team (chickens and pigs)
• Allow anyone to update the Board (it has to be network accessible)
• During meetings, setup a team computer and allow everyone to make changes

Remember, the team’s goals are building good software and managing risk. The Board is simply a tool.