Interview with Michael Nygard
A few months ago I sat down with Michael Nygard (http://www.michaelnygard.com ), author of the Jolt Award winning book Release It!. We discussed what developers should be aware of in the next year and the number one career tip he's like to pass onto you.Don’t Stop for Gas… We’re Already Late!
This is a Neal Ford quote that sums up so many software shops. We know we should be writing automated tests. We know that continuous integration is something we should run and keep clean. Peer code reviews? Uninterrupted work time? Check and check.
We know many, many practices we should use everyday. But we get caught up in the urgency of the moment. We fall into crisis management. Bug driven development. "Shut up and code!" becomes the unwritten rule of the shop. No one says that writing automated tests is bad, but everyone is constantly driven to add new features instead.
We confuse activity with progress.
Just because you're working hard doesn't mean you're heading in the right direction. It only means you're sweating. It takes a bit of time to step back and ensure you're headed in the right direction.
It's like driving to a meeting. It's an important meeting and you don't want to be late, so you drive as fast as you can without getting a ticket. You're running questionable yellow lights. Then at some point your spouse points out that the car is nearly out of gas and you've still got a long way to drive. Your response?
"We can't stop for gas. We're already running late."
It sounds dumb when we say it that way, doesn't it? Running out of gas takes far more time than re-fueling ever would. But that's how we develop software. We continue our mad dash and long hours until the team or project runs out of gas... and that's one of the big reasons 75% of all software projects fail.
Take the time to stop for gas. And even directions... (when's the last time you read a software book?). Call it stopping for gas or sharpening the axe... but do it! Tools like 6th Sense can be used to pick out practices for your team. So can a process coach, or a good talk at a conference.
If you focus too much on driving, you might not make it to your destination at all. Pull over and recharge.
Defusing Big Brother Fears: Putting Developers Back in Control
6th Sense tooling is in a sensitive space. Allowing others to see what you're doing during the day can make you feel vulnerable. Especially if you don't trust your management. (If that's the case, why are you still there? But that's another post about co-dependency and enabling personalities....)
We've worked very hard to train our customers on the proper use of metrics. Measuring not monitoring. Tracking progress. Burnup charts. Estimation accuracy numbers. Moving past developer optimism ("I know I can make this work!") and to a measure of what's actually done.
How Risky Is Agile?
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?
How Manual is Your Project Management?
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
Is Your Team Welded Shut?
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.
We’re Late! Don’t Stop for Gas
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
Avoid Estimate Insanity
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
Video Interview: Brian Sletten
Brian Sletten is one of the more popular No Fluff Just Stuff speakers and a partner at Zepheira. He's very well known in the semantic web space and works all over the world. I was lucky enough to corner him for a few minutes at a conference a few weeks ago to pick his brain on career moves and the movement of the tech arena. Read More
- Page 1 of 3
- >