verything 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. Software managers can succeed despite themselves if they happen to staff a top-notch team—even though the managers, themselves, might not be very competent. Any successes that a top-notch team achieves are the manager's achievement. Failure, however, is harder to blame on the team because a manager must be able to solve problems as they come along. This article focuses on tips and knowledge you can 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, but in my opinion, none of the three is 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; the methodologies are quite complementary.
Instead of going into an exhaustive explanation about each agile method, I'll leave that research to you, and instead 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 on 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. That's because customers and users don't understand 100 percent of the scope they need to solve their business problem. They might know 50 or 80 percent. In highly-regulated environments, that knowledge might even be in the 90s, but then the communication factor comes into play. 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 percent of the scope required to solve a problem, they cannot communicate 100 percent 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 percent 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 percent 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 percent 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 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 in the best, fastest, and cheapest manner. 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 require exactly five developers. Let's take, for example, a team of six developers who each get $10,000, and compare their output to a team of three more experienced developers making $20,000 each. (I'm intentionally giving unrealistic salaries because 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 lies in 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. 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.
|Editor's Note: This article was first published in the May/June 2008 issue of CoDe Magazine, and is reprinted here by permission.|