Still, in a fully agile environment this poses some difficult challenges. The agile culture has emphasized team co-location and face-to-face interactions heavily as a best practice, but obviously in this scenario that’s not likely to be possible. This disrupts team interaction, project visibility, and a variety of other positive aspects of the agile methodology.

There is a never-ending plethora of tips for distributed agile teams, but obviously there is no one-size-fits-all solution. I’ve been brainstorming for a while, and over the next couple of weeks I’m going to try and prepare some solution proposals for the executives here. I’ll let you know what I discover.

If you have any suggestions of your own, feel free to share them.

In reality, most teams that I’ve seen fail at Scrum aren’t actually failing because of Scrum, they’re failing because they don’t understand what agile really means. Agile project management and processes are designed to be adapted and modified to respond to the particular environment in which they’re used. People who try “Scrum by the book” rarely find that it works, because they’re too focused on following the process and not focused enough on improving/adapting it for their particular needs.

On the flip side, there are also all those who practice ScrumBut¹. I.e., they’re practicing Scrum but they left out some important pieces or deviated so far from Scrum as to break some of the basics. Maybe they aren’t doing daily status meetings or they’re not estimating and committing as a team. Either way, by leaving out or modifying some of the very important core principles, they’ve done themselves a disservice… but they’ll still blame Scrum.²

So obviously, the way to succeed at Scrum then is to modify and adapt it to our needs, but don’t change it?

It is a small conundrum, but easily explained: as with all things, moderation is the key. Also, if you’re going to practice Scrum, it’s important to adhere to some of the core principles. Do have a daily stand-up meeting. Do have planning sessions and retrospectives as a team. Do have fixed-length, consistent iterations. Do have a Product Owner and a Scrum Master. Beyond that, feel free to tweak things. Change up the questions asked in the daily meetings. Play with different styles of planning and estimating. Have one week iterations instead of thirty days. The possibilities are endless and completely mutable, so stick to the Scrum guns as it were, but don’t stifle your ability to adapt by refusing to make changes.

How do we know when an aspect of Scrum is succeeding? That part is actually pretty easy: watch what people do in the absence of controlled direction. If the daily stand-up meeting is succeeding, people will continue to participate in the absence of direction from the Scrum Master. If planning methodologies are succeeding, velocity will increase and estimates will become more reliable, and the team will be committed of their own volition. Good habits will be copied from person to person and team to team.³

Lastly, remember that Scrum is not a “magic potion that heals leprosy and cures blindness.”⁴ Keep your expectations, and remember that moving from waterfall or other rigid, top-down methodologies to agile methodologies Scrum is a learning experience and a culture shift. Successful implementations come from the ability to react and adapt to the organization, not enforcement of strict policies.

In the world of business software, I would say a good analogy to this concept is “usability over features.” In other words, focus on adding that things that increase the customer’s productivity and satisfaction on core features rather than adding all the cool stuff that your competition doesn’t have. While there are sometimes provable competitive advantages to having a feature that your competitors don’t, more often than not it is the software that does the core things better that wins the race. If your word processor makes it difficult for the users to actually compose documents, they’re going to spend more time complaining about the pain of using the product rather than using all the other “cool” stuff that you added. Or, more likely, they’re just going to use a competitor’s product that edits documents better than yours.

The user experience is paramount. If you can’t focus on that aspect of the software and make it pleasurable (or at least efficient) to use your product, then you’re dead in the water before you ever even get to sell the customer on everything else that it can do. When developing a new product or even maintaining a mature one, I would consider it best to prioritize your backlog in a way that promotes the core set of features. First get the engine and the wheels on your car right before you worry about the color of the paint.

True success requires an ongoing conversation between business and IT at the very least. In an ideal scenario, we can break down the traditional barriers between business and IT that have been erected in most organizations and quash the “us versus them” attitude. This typically means having a full-time product owner on the team who can provide direction and timely decisions regarding the product. It’s actually quite disheartening to see how many teams try to plow through a project without this crucial guidance. Is it any wonder that the customers are often disappointed with the end result?

What demoralizes the team even more at this point is that they are often blamed for not fulfilling or understanding the requirements they were given, and the stakeholders are seen as inculpable for the failure since they are certain that they provided all that was needed. This is simply not true; no matter how good your requirements, design documents, and project plans are, nothing is a substitute for ongoing, active participation with the people who are actually delivering the software.

I believe that most of this stems from the misguided notion of running IT as a business—in other words, an internal vendor completely separate from the rest of the organization. This furthers the disconnect between the stakeholders and the product team and reinforces the artificial barriers I mentioned earlier. Also, the notion of “chargebacks” pushes the stakeholders to treat IT as they would an external vendor: with little trust and without direct participation. To fix this, IT must be integrated with the rest of the business in such a way as to be part of the team rather than a separate entity unto itself. Likewise, they must be given a healthy budget to do both maintenance and growth, just as if they were any other division of the company, rather than relying on chargebacks to fuel projects.

One of the aims of traditional methodologies is to develop a process where the people involved are replaceable parts. With such a process you can treat people as resources who are available in various types. You have an analyst, some coders, some testers, a manager. The individuals aren’t so important, only the roles are important. That way if you plan a project it doesn’t matter which analyst and which testers you get, just that you know how many you have so you know how the number of resources affects your plan.

But this raises a key question: are the people involved in software development replaceable parts? One of the key features of agile methods is that they reject this assumption.

One of my biggest pet peeves is when managers and planners refer to people as “resources.” I get this visual of a bunch of managers sitting around a table and trading little chits that represent people until everyone is happy with what they have, but all the chits are the same… just commodities to be pushed around from project to project.

When you treat people as interchangeable cogs in a machine, you miss several important factors about your team members:

• People are not equivalent pieces. I refer you of course to the ever-popular book The Mythical Man-Month by Frederick Brooks. If I have estimated¹ that two people can do the work in six months, increasing that to four people does not mean that we will get it done in three months. Team members all have differing levels of expertise and productivity, differing skills and motivations; you must know how to leverage these individual talents rather than lumping them together as a whole.
• People bring the greatest benefits and the biggest hindrances to the project. When you reduce them to a column on a spreadsheet, you are naïvely discounting their individual personalities and quirks. People can have breakthroughs that cut development time in half. They can also have a family emergency and lose you a week of production.²
• People are perceptive. They know when they’re being treated as faceless automatons rather than real human beings, and they will resent you for it. Don’t ever believe that your team members aren’t keenly aware of how you talk about them behind closed doors.
• People have preferences and motivations. Assigning people to tasks that they may be good at but hate is counter-intuitive. Yes, Bob may be a database whiz, but if he hates the reporting engine, assigning him to fixing the reports isn’t going to be the best utilization. Assign people to tasks that they enjoy, even if it’s not their strong suit; they’ll be more productive and learn a broader range of skills. Conversely, don’t let people pigeon hole themselves—ask them to branch out every once in a while and leave their comfort zones.
• People have lives beyond work. Don’t plan for people to have 100% attendance. Don’t even plan for them to work 40 hours per week. As I mentioned above, people are perceptive, and if they feel you are treating their personal lives as secondary to work, they will resent you for it, and morale and productivity will plummet.

This is the brand new blog of a great colleague of mine, Harry Long, one of the best Scrum Masters and Project Managers I’ve ever worked with. The blog is presented in both Spanish and English, so any of you out there that prefer Spanish as a primary language will be pleased to see agile discussion in your native tongue.

In my experience, the one largest source of waste that can be eliminated or reduced to add immediate benefit to a project is rework¹. Rework falls into two major categories:

• Technical debt
• Defects

Technical debt refers to those shortcomings in the design of the software that we accept that we will have to address at a later date. This often comes as a result of running out of time in any given iteration; as we cut corners, quality suffers, and technical debt mounts². Defects, on the other hand, are unintended consequences or misunderstood requirements; that is, they are unforeseen problems with the software that must be addressed immediately. The ratio of the two varies from project to project, but since defects often require immediate consideration, they tend to have a disproportionate effect on the deliverable date.

Of course, the obvious solution is to write bug-free code. That’s what we want to do anyways, right? Admirable, yes, but not practical in the least. It is impossible to write code that is free of defects, as it would at its very base require a product owner and development team that are somehow psychically linked as well as infallible. However, it is possible to reduce the number of defects by following some very simple principles. This list is by no means comprehensive, but it should give you a starting point.

Limit work in progress. Each developer should really not be working on more than one or two tasks simultaneously in most situations. Focus increases reliability.

Reduce “crunch.” It should be obvious at this point to both developers and managers that there is a diminishing return on hours worked. Try to take on realistic commitments for each development iteration and avoid working large amounts of overtime if at all possible.

Pair programming. This is a highly useful tool not only for developers to check each other but also a developer and a quality/business analyst to check each other. Your team will think you’re weird at first for asking for such an odd pairing, but I’ve done this before, and it can be highly valuable to have someone who understands the business and requirements working with the developer up front. This also increases utilization of QA resources that often sit idle until the end of an iteration.

Engage QA earlier. Frequently in agile environments we fall into the trap of doing “mini-waterfall.”³ That is, we do a design and specification phase during sprint planning, then the coders spend a bunch of time doing heads-down work to meet sprint objectives, and then they finally throw their deliverables over the wall to the QA team at the very last minute. If you find this to be a frequent problem, then break your tasks down into even smaller chunks that can be completed and delivered without utilizing the entire sprint for each one.

Inclusive design. Always strive to include the entire team in design and specification meetings. It’s a simple fact that if more people are involved, more problems are likely to be uncovered before development even starts. The team as a whole should have a keen understanding of the entire project, even parts they may not be responsible for. If you find that this inclusiveness is eating up too much time, it’s most likely because your team is too large or your meetings are not staying focused.

Daily updates. The daily status or “stand up” meeting is one of the core principles of Scrum. Even if you’re not practicing Scrum (or any agile methodology for that matter), I highly recommend daily updates. A focused, repeated meeting to keep everyone up-to-date on the team’s progress can help the team be aware of its progress as a whole as well as help identify and address problems mid-stream rather than at the end.

Visibility. Another principle of Scrum, task boards and burn-down charts can also help the team with understanding where it is. Whatever the actual implementation, it should be a highly visible cue into everyone’s projects and the overall health of the project. Increased visibility reduces one of the most frustrating defects—items that we just plain forgot about.

How does [an emergency] apply to software development? Well, consider the poor overworked software developer. They’ve had this bloody Scrum process thrust upon them meaning they have to deliver more, deliver it faster … Near the end of the sprint, this poor developer is running out of time and still has work to complete – they are facing an emergency! So what do they do? They revert to their original training.

What was that training? … They hacked something together that met the requirements for the assignment, and could afford to make it throwaway. Automated tests? BAH!! Simplest thing that could possibly work? … In the end, the attitude is to get something – anything – done in order to get the marks.

This was espoused in a previous workplace of mine as the concept of “get ‘er done.” What upper management was trying to address was an apparent lack of progress and too much time wasted on best practices. What this generated was an urgency of get as much done as fast as possible, and the result is catastrophic. People burn out, product quality takes a nose dive, and in the end, you’re in a worse place than when you started. “Get ‘er done” is almost as ineffective as “get nothing done,” simply because in the end the result you get is so poor that you don’t want it anyways.

This is such a flawed mentality to begin with that it’s difficult to address it; you pretty much have to change the attitude from the top down. Management must be understanding of the time it takes to produce quality over quantity, while developers must be willing to eliminate wasteful activities (that they may not agree are wasteful), and the Product Owners and Scrum Masters must assist the teams with committing to a reasonable amount of workload. This is partially a training issue and partially a culture issue. Training can be used to instruct change, but the participants must be willing to enact change.

So I was happy to step in with an alternative solution: a Scrum-like daily status meeting. I don’t make people stand-up, and we’re time-boxed to 30 minutes instead of 15, but otherwise the principles are the same. At each meeting the attendees are required to come prepared to answer the usual triumvirate of questions:

• What did you accomplish yesterday?
• What are your goals for today?
• What issues are affecting your ability to meet those goals?

I’m pleased to say that even after only one week, the system has proven effective. People don’t mind attending since it’s short and focused. We stick to the agenda above; we’re not quite used to the format yet, so some side discussions occur in the middle of the meeting, but we’re getting better. Now everyone knows what everyone else is doing, and communication is improving. We’re catching issues much faster since the team is aware of what is going on before it happens.

I won’t claim daily status is a panacea, but it’s working for us with remarkable results.

Shameless plug for the new Fort Worth chapter of the APLN. It will be 6:30 – 8:30 p.m. on April 16, 2009. The speaker will be Ash Tengshe from Capital One Auto Finanace. Attendance is free. If you’d like more details, please contact Charles Seaman at fortworthapln@gmail.com.