I'm pleased to announce we recently posted the newest version of our solution. This release is "special" because we also released a new version of our Desktop (v 4.0.2) and new installer. We are very careful about performing Desktop releases and tend to update it infrequently to limit disruptions for our users.
Instead of simply listing out features in the release, I'm going to introduce them periodically through the blog and screencasts. The first video highlighting the biggest feature, data submission controls, is complete and available below. More information about the thinking behind the feature is on its way as well. Enjoy!
Click to Watch (.swf)
Teach? Coach? Consult? Speak?
A few days ago some of our development team were working hard to keep our automated tests passing. We've been doing some serious development, and it's been real work to get and keep our tests passing. One of team members joked: "it's much easier to just tell someone to test?"
We've all been to the presentations at conferences. We've all read the books on things you "must" do -- the practices you "must" follow. The great thing about being a speaker or author is that it requires no follow-up. They don't write the tests. They don't stay late when the tests fail.
They are not even responsible for their recommendations. What if the practices don't improve the organization? Typically, I've heard pundits blame poor adoption for failures. This was very common in the XP community. I've heard XP consultants say, "you didn't follow all the steps." Of course this is an easy thing to say to a team trying to make a huge change.
It reminds me of the excuses astrologists make when they make poor predictions. An astrologist once told me, "you didn't give me the exact time of birth."
The bottom line is that it's easy to make recommendations -- it's hard to execute them.
Back it up!
We'd encourage teams to require consultants and speakers to back up their recommendations with data. Collect metrics. Demonstrate quantitatively that their ideas and philosophies work.
Our coach, Jared Richardson, isn't afraid to measure his recommendations. As a matter of fact, he requires it. Why spend time ( and money ) enacting change if the downstream effects cannot be proven?
I'd encourage any team that's enacting change to take a baseline and measure the results. Of course using a product like 6th Sense will make the task must easier, but regardless measure the results. This will not only benefit the organization as it strives for improvement, it will keep the consultants/coaches in check.
Once upon a time, a prospect mentioned that his development team would "pass around a hat" if we could automate their timesheets.
Get your hats ready
We recently announced a partnership with Austin-based Journyx. I just posted a video demonstrating the ease in which data from 6th Sense can auto-populate a timesheet.
This integration is perfect for any organization mired with timesheets. It adds no overhead and completely removes the burden from individuals. Please contact us if you'd like to learn more about this exciting integration.
Video
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?
For those of you who wanted to make history yesterday by downloading Firefox 3, congratulations. 8 million of you helped make history and put Firefox 3 into the Guinness Book of World Records.
We are excited about Firefox 3, especially the performance improvements. Firefox is one of the top tools used in our community, so we are committed to keeping current on versions. Recently we updated our Firefox sensor -- now on version 7 -- to officially support Firefox 3, so our user community use the latest and greatest technology. Users are welcome to point their web browsers to http://localhost:60006, or go to http://docs.6sa.com for more information.
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
New functionality provides an enhanced user experience.
Morrisville, NC -- 6th Sense Analytics, Inc., a provider of unbiased data and metrics into the status of outsourced software development projects, today announced numerous enhancements to its flagship solution. 6th Sense Analytics offers critical insight and metrics by automatically and unobtrusively collecting unbiased activity-based data throughout the entire software development lifecycle.
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
