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?
A truly brilliant engineer is lazy. Anything that can be automated will be automated. We try to never do anything twice. That’s why it pains me to see people still using by-hand techniques to gather data and generate reports. The inspiration behind 6th Sense Analytics was the automatic gathering and reporting of various data points.
Read More
A few months ago at a conference I heard something like "The only thing true measure of a software project is working code." While I cannot recall the exact quote, this was the basic gist and is very inline with "Agilist" thinking.
Principle 5 of the Agile Manifesto [ Note: I don't think they are in any specific order ] is:
"Working software is the primary measure of progress."
I heard it again at a conference this week: "We measure working software."
Read More
A common question in the open source arena is “Would you buy a car with the hood welded shut?”. The answer is always an emotional “No!” But most teams have crawled into a box and welded the lid closed behind themselves. And it’s tolerated.
Bob Young, RedHat’s former CEO, published an article in 2000 (Open Source is Here to Stay ). Much of the article applies directly to the team-wide metrics 6th Sense gathers. And I think, just like RedHat and Linux really moved open source into the business mainstream, 6th Sense will have just as large an impact on the software industry.
Let me quote Bob’s article:
The best analogy that illustrates this benefit is with the way we buy cars. Just ask the question, “Would you buy a car with the hood welded shut?” and we all answer an emphatic “No.” So ask the follow-up question, “What do you know about modern internal-combustion engines?” and the answer for most of us is, “Not much.”
We demand the ability to open the hood of our cars because it gives us, the consumer, control over the product we’ve bought and takes it away from the vendor. We can take the car back to the dealer; if he does a good job, doesn’t overcharge us and adds the features we need, we may keep taking it back to that dealer. But if he overcharges us, won’t fix the problem we are having or refuses to install that musical horn we always wanted—well, there are 10,000 other car-repair companies that would be happy to have our business.
Today the consumer is the management chain and the engine builders are the teams that lock out their managers. Maybe they don’t trust their managers. Maybe they think that withholding information makes them more powerful. All it really does is breed mistrust and make it much harder for managers and technical leads to do their jobs.
When we hide information from the management chain who signs our paychecks, why are we surprised that they outsource our jobs?
Are our managers software gurus? Usually not. Just like the internal combustion engine experts example… managers with software expertise are uncommon. Does that give us the right to deny them access? No more than it would give Ford the right to weld our car hoods closed because we don’t know to build an engine.
Will your manager abuse this information? Not unless they want to their team to quit. To put it another way, when’s the last time you popped the hood of your car and started pulling wires? Hopefully never. It would be a stupid thing to do. How many stupid managers are going to start messing with a teams’ internals? If Dilbert is to believed, all managers are dumb. But I suspect the truth is that there a lot of smart people out there doing the best job they can. Let’s make sure they have access to everything they need to do their jobs.
6th Sense gathers information from both the desktop and the server (see our list of sensors). Does that make it a “big brother” tool? No more than having a hood latch makes you a car vandal. It’s just a tool.
Is it a tool that makes you comfortable? Maybe. Maybe not. Is it a tool that makes more information available? Absolutely. Is this information we’ve traditionally made available? No, it’s a new way of thinking about productivity and product management.
Make the information available. Open the hood of the car and let everyone see what you’re doing all day. Pretend our software is a pair programming partner. Then stand proudly on what you’ve done. Sign your work. Don’t hide it and hope for the best.
Subversion ( SVN ), the popular source-code control system, has a command to see the changes to a file by user. It shows a file annotated line-by-line with the user responsible for authoring it. This command has two names: blame and praise. Whenever I jokingly suggest using "blame", developers will often respond, "you mean praise?"
Read More
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
We all know that developers can't estimate time, don't we? But why not? Developers are very smart. We deal with abstract concepts every day. You'd think we'd be able to learn this skill over time. But somehow we never get better at work estimation. Some people attribute it to a developer's innate optimism, and that's part of it. But there's a more important factor here.
Read More
This is a serious question... take a moment and think about what happened to your last unsuccessful project. The list is usually contains the same 'usual suspects'.
Bad requirements. Moving targets. Crazy estimates. Unrealistic deadlines.
On Monday I spoke at this year's Academy for Software Engineering Educators and Trainers and got to spend some time talking with Watts Humphrey. He asked me this question.
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
