Managing an Agile Software Project

Everything right or wrong with a software project is management’s fault. Either management staffed the right people or the wrong people. Management was absent or involved. Management is hard, and there are numerous factors that can cause success or failure of a project. In the best situation you have great people who do great work. A software manager can even succeed despite themselves if they happen to staff a top-notch team even though the managers, themselves, might not be very competent. The success that a top-notch team achieves is still the manager’s fault. Failure, however, is harder to blame on the team because a manager must be able to solve problems as they come along. This article will focus on tips and knowledge to use when managing an agile software project.

Aiming for Agile

Lean, Extreme Programming (XP), and Scrum are probably the three most well-known agile frameworks. I don’t find any of these three to be sufficient on its own. Probably the most well-known at this point (at least in my region) is Scrum. I hear folks referring to iterations as “sprints” more and more. Managers are sending their folks to Scrum training left and right, and yet, Scrum is naked without XP. Scrum doesn’t offer much guidance on engineering practices, and as long as the project involves software, engineering practices are key. When managing your team, ensure you provide adequate engineering guidance. I’ve found that you can get great results when you manage according to Lean principles, run the project inside the Scrum framework, and create the software through Extreme Programming. They are quite complimentary.

Instead of going into an exhaustive explanation on each agile method, I’ll leave that research to you and talk specifically about what things to pay attention to while managing your project and striving for agility. Just think of agility as the ability to change course and adapt continuously to customer or product owner needs. The software should remain just as maintainable as the second day of its life and the pace of the project and subsequent releases should remain stable.

The Fallacy of Fixed Scope

One of the reasons “scope creep” is such a well-known term in our industry is because scope hardly ever stays the same. Even in fixed-scope projects, scope changes. This is because customers or users don’t understand 100% of the scope they need to solve their business problem. They might know 50% or 80%. In highly-regulated environments, that knowledge might even be in the 90s, but then there is the communication factor. How do you communicate scope? Do users or developers or managers attempt to write it down in prose? Do they have long verbal conversations? Even if the software customer theoretically understood 100% of the scope required to solve a problem, they cannot communicate 100% of that understanding up front.

Agile project management understands that scope is a moving target. The larger the scope, the more it will change. It’s not that the scope itself changes so much, but the understanding of that scope changes. Even with the theoretical 100% understanding, the information transition to the development team is a variable and not a perfect medium; therefore, to the team, scope will appear to have changed even if it has not.

Now, let’s move away from the theoretical 100% understanding to the more realistic 50% understanding. Imagine you have a common environment where a customer has a business problem that needs solving, and he thinks he has a pretty good idea what will solve it; hence, the 50% understanding. To manage this environment, both the team and the customer must understand the core of the business problem and be completely committed to solving it. The scope the customer has in mind might be relevant, or it may not. The software manager should foster an environment where questioning assumptions is welcome. In this environment, the software team will apply a critical eye to every story on the table and evaluate whether that story will contribute to the end goal. Every story must stand up to criticism in order to prove worthy of the team’s time. Working on the right thing is as important as making the thing worked on right. Work with the customer to determine together what scope will solve the customer’s problem the best, fastest, and cheapest. In most cases the team will be able to cut scope from the project.

The Unspoken Quality Variable

When managing a team, it’s important to understand who you have. You know how much you pay your people, and you should understand how much you are getting from them. All software engineers are not created equally, and there is no such thing as a project that will take “5 headcount”. Let’s take, for example, a team of six developers who you pay $10,000 each. Now, compare the output to a team of three more experienced developers who you pay $20,000 each. (I’m intentionally giving unrealistic salaries since salary numbers are not relevant here, just the relative size.) Studies referenced in Code Complete, by Steve McConnell, show that you can get developers who are roughly ten times as productive for only twice the price. The key is discerning each developer’s skill. It’s entirely possible that a smooth-talking developer on par with your team of six has negotiated a higher salary without the skill to back it up. That would be your mistake and his gain. Hopefully if you’ve made your way into management, you can discern people’s skills.

In an agile project, you tend to employ more generalists than specialists. With a team of generalists, you want folks who are skilled in a variety of areas. They will all work together to meet the commitment for each iteration. Staffing a team of specialists limits communication and creates bottlenecks, which then create queues. Refer to Lean software principles for information on queuing theory.

Key Performance Indicators (KPIs)

When managing an agile software project, you’ll be interested in tracking some metrics to help you gauge how the project is going. Just remember, whatever metrics you track will improve. Make sure you don’t track the wrong things. For instance, if you track number of lines of code as a productivity measure, you will see productivity soar, at least according to your metric. It’s natural to improve the measure, or game the system, as you might say; therefore, track what you really want: software delivered and customer satisfaction. Start with the following metrics and hone your tracking over time:

• Defect-free stories delivered. Each story represents a unique behavior in the software from which the customer benefits. Stories delivered with defects aren’t as valuable, so don’t count those.
• Customer satisfaction. Ultimately, you are creating software for a customer. Without the customer, you wouldn’t be creating the software. Keeping them happy is a great metric. It’s simple. Just ask their satisfaction level on a scale from one to ten.
• Consistent velocity. Iteration over iteration, velocity should remain constant. If it continues to change, something is wrong. After about the sixth iteration, treat any significant change in velocity as a cause for alarm. If the team make-up is consistent, the velocity should remain constant. A slowing of velocity could be a sign of a codebase that is less than maintainable.

Managing the Customer

Part of your job is managing the development team, but you must also manage the customer. Customer satisfaction depends so much on managing expectations. Customers don’t like surprises. You shouldn’t provide surprises. The customer should know what to expect in the iteration demo, and if you deliver less than your team committed to, the customer is presented with an unpleasant surprise. If, for example, a team member must be out for paternity leave, inform the customer that it will affect the velocity of the next iteration.

A great way to keep the customer informed and to avoid surprises is by inviting them to the daily stand-up meeting. Every morning at 9:00 am, have the team go over three items:

1. What I accomplished yesterday.
2. What I hope to accomplish today.
3. What barriers are impeding progress.

Armed with this daily knowledge, the customer will start to feel like part of the team instead of an outsider. The customer will have up-to-date knowledge and won’t be greeted with any surprises. The daily stand-up meeting, weekly iteration demos, and constant communication will keep the customer happy and involved. It’s important to pull the customer into the process. If the customer isn’t engaged properly, there will be an us vs. them environment, and that is dysfunctional. When your team is in competition with the customer, neither will win.

Bugs vs. Defects

Defects are gaps between what your team committed to and what they delivered. If the team commits to a story and they find a problem with the functionality of the story, you have a defect on your hands, and the story isn’t finished. You should only count stories as “done” when your customer accepts them without defects. It does no one any good if you merely log a defect and take credit for the story anyhow.

A bug is anything that bugs the user. I’m not sure we’ll ever get away from bugs, but constant communication sure helps. In managing the software process, it’s important to understand the difference between a bug and a defect. Bugs are not negotiable. If the behavior of the software bugs a user, you have a bug, end of story. If your team and your customer agreed upon the behavior beforehand, then you have a defect, not a bug, and your team should correct defects immediately.

A defect is a gap in the story contract and acceptance criteria. A bug is not a defect since it’s an annoyance that has yet to be discussed. Bugs pop up all the time, and if the customer is motivated enough, he’ll craft a story to get rid of the bug and put that story on the backlog. A customer shouldn’t have to think about defects, however. When someone finds a defect, the team should drop everything and fix the defect right away. A defect signifies that a story which the team has already labeled “done” is, in fact, not finished. Finish the story and move on. Institute a zero-defect policy. Don’t count a story as done until it meets all acceptance criteria. You can’t get away from bugs, but you sure can eliminate defects.

Retrospectives

At the end of every iteration, have a short time where the team can reflect and craft ways to improve even more. A fun way to do this is to list feedback under three headings:

1. Good (what you would like to continue).
2. Bad (what you would like to stop).
3. Ugly (a fun category if an issue was particularly messy).

Consider all items action items. Your team should continue and enhance “good” items. Your team should stop, change, or overhaul bad and ugly items. A good manager will try to remedy the items listed under “bad” and “ugly”. Most of the time, you are the only one who can change these items. The team will remedy the items under their control, and the items that remain are more organizational problems. Don’t just ignore these organizational problems. It may be difficult, but as management, it’s your job to handle issues like poor facilities, equipment, software licenses, etc. Who said management was easy?

Keep retrospectives short. Thirty minutes is a good cap on a retrospective meeting. You don’t want it to linger on into a discussion on agile theory. All-in-all, you are in charge, so if your team starts a long discussion on how to move forward, you may have to make the call.

By: Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. His company specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is a MCSD.NET , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate.

Headspring Systems is available for consulting. We can coach your software team or deliver custom software quickly to match your needs. We specialize in software architecture and design, technical coaching, software management coaching, software business analysis, business leadership, technical recruiting, C#, .NET, agile, lean, extreme programming, and scrum.

code@palermo.cc