I've heard from managers and developers all over the country that they're afraid to try Agile because they can't handle the risk that an Agile project brings. This type of attitude is a complete misunderstanding of Agile, but it's very simply addressed.
Here's a simple example. You've got five teams and a two year project. At what point, using Waterfall, do you realize which teams are in trouble? You don't know. You might catch it early, or you might get the disastrous "Can Do!" attitude from a manager or team lead who's sure their team will catch up, so they tell you they're doing great. But you're depending on status reports from someone who's got a strong vested interest in appearing to succeed. Their bonuses and raises depend on that perception. By the time we realize there's a problem, it's often too late to recover and get the project back on track, so our projects either fail or ships disastrously late.
On the other hand, what about an Agile project? Let's assume four week iterations. (Iterations vary from one week to six weeks. There are other Agile techniques, like continuous integration and test automation that make this possible.) So every four weeks each team has a smaller set of deliverables. This forces your teams to tackle smaller units of work, resulting in smaller, more manageable time estimates. (We all know that smaller estimates are more accurate.) Instead of trying to estimate six months worth of work, they tackle four weeks worth. It's easier to understand the problem and potential pitfalls of a smaller task.
So you're focusing on smaller amounts of work that you can more easily understand. You'll catch more problems because you're forcing the teams to think through the problems at a more granular level.
But when do you catch off track projects? At the end of the iterations... every four weeks. Say at the end of the first iteration, four teams meet their commitments, and the fifth team only finishes 10% of their tasks. Maybe that team just had a slow start, so we overlook their failure to deliver in iteration one.
But in the second iteration, the same team fails to deliver. Then again in the third iteration. Are you seeing a trend? How long do let a failing team continue to fail? In the waterfall world, you depend on regular status reports, not incremental deliverables. But a status report can easily be falsified, or just be overly optimistic. And there's also the well-known tendency of status reports to green shift as they bubble up through the management chain. But how do you green shift a failure to deliver? Especially if you use a product like 6th Sense that reports on completion rates automatically. There's no whitewashing a chart you don't get to edit.
If a team has problems delivering product, there can be an incredible variety of reasons. Bad requirements, new technology, developer incompetence.... who knows what the exact problem is? We don't... but once you realize the problem exists, you can get involved with the team and try to understand and fix it. That's a manager's job. Find problems and fix them. The first step is discovering the problems exist, and this is a time boxed iteration methodology shines.
Agile gives you this understanding in just a few iterations. Waterfall gives you this much later in the product cycle. Sometimes months or years into a large project.
So tell me again... which is the riskier development methodology?
Every development organization I've talked to thinks this is exciting. This is a longstanding problem. Managers want metrics, managers' managers want metrics, but no one wants to slow the project down to gather information. There were solutions like this in the past that made it a little easier but no one makes it quite this easy.
~ Carey Schwaber, senior analyst with Forrester Research
Neil Ford has a great quote about test automation.
We're running too late to stop for gas.
Read More
Noted RedMonk industry analyst Michael Cote did a webcast interview with me about the 6th Sense Analytics product suite and how we integrate with the JIRA feature/issue tracker software. We’re a very nice addition to your Jira install. We easily pull data out of JIRA and then provide additional reporting and trending features.
Read More
What's the best way to use tools like continuous integration or 6th Sensor Analytics? Should we see a problem and hit developers over the head? Scream and run around? Or force developers to follow a rigid set of steps to "guarantee" success? (Herd those cats!)
Much of Agile is about being flexible. It's about getting feedback and adjusting your daily practices to match. This is why so many people have rejected the idea of universal best practices completely.
Read More
Real developers write code — not status reports.
I Need It
There are typically 2 reasons for needing status reports: 1) collaboration and 2) monitoring.
Agile shops recommend status reports for the first reason. Software development is a team sport. Rarely do individuals work in a vacuum, so regular status is important to address dependencies, remove blocks, and ensure folks don’t step on each other’s toes. The manager may collect reports for logistical reasons, but the reports aren’t for managers — they are for the team.
Monitoring is more common in consulting arrangements. Work is being done on someone else’s behalf and that person wants to monitor the activities. Very simply they want to ensure they getting what they are paying for. Every once in a while you read about dysfunctional uses of status reports. This “use case” is commonly the scenario where that’s found. The reason is that people often don’t care until there is a problem. Then the reports are reviewed to help understand where things went wrong.
Read More
Introducing change to an organization can be difficult and there are dozens of things that can go wrong. John Maxwell's great book 21 Irrefutable Laws of Leadership has a set of steps that I've found very helpful.
Read More
David Starr had a good post this week on planning future work cycles. Do you use a team's commitment to the next iteration or the team's historical performance?
Read More
You’ve installed the 6th Sense Analytics toolset and discovered that your most senior developers are spending less than an hour a day writing code. This concerns you since you know these guys love coding and left their last job when they got pushed out of code.
Read More
J. B. Rainsberger has a great blog entry titled Should We Measure Velocity on the importance of knowing where your team spends their time. He says knowing your history is more important than estimating new features.
It’s difficult to know where your development team is headed. Even with a perfect knowledge of how the team members work and how long it takes them to complete a feature, the specification often changes in the middle of a project. I’ve never finished a project with the original set of requirements.
Read More
Jared Richardson to Work with Customers on Integration of the 6th Sense Analytics Solution
MORRISVILLE, N.C. -- 6th Sense Analytics Inc., provider of unbiased data and metrics into the status of outsourced software development projects, today announced the addition of Jared Richardson as an agile coach and software development technology evangelist.
In his new role, Jared will be responsible for working closely with 6th Sense Analytics customers on integrating the company’s solution into their processes as well as their culture. Jared will also be responsible for evangelizing the use of software development metrics to the developer community, with a special focus on agile shops.
Read More
