Cogent Departure

With sadness and trepidation I need to tell everyone that I plan to leave Cogent Consulting. I appreciate that you're not supposed to leave your own company, but I've rarely let what you're "supposed" to do govern my career. My departure from Cogent will create a hole, but I'm perfectly comfortable that the hole will be quickly filled. Marty Andrews will take over my role as decision-maker-of-last-resort, and I expect that most people, both staff and customers, will notice little difference on how Cogent runs or the quality of the service that it provides.

The decision to leave Cogent isn't an easy one, but sometimes opportunities come up that you simply can't ignore. I'll leave out the details of this particular opportunity since it isn't finalised, but I believe it's in the "can't ignore" category. It's quite possible that it won't turn out as I hope and I'll be back, but I need to find that out for myself. As my lovely wife said, "If you'd never created Cogent, you would have regretted it for the rest of your life. If you don't try this, you'll regret it for the rest of your life." Or as she said to our son, "would you like to have a family adventure this year?".

I'm very proud of what Marty and I have accomplished to date. We're running a company using approaches we were told were unrealistic, that simply wouldn't work, and Cogent's existence is proof to me that they can work. All the books of the company are open to all the employees, we don't put people on gigs they wouldn't choose to do themselves, and we try to make as many decisions as we can as a group. We share our profits in a fairly egalitarian way, and we've done some product development. We don't do any of this perfectly, but our hearts are in the right place. I'm a little more balanced about the pros and cons of these approaches, a little less naive, but I suspect that Rupert would still call me a Trotskyite. I wish I'd started this ten years earlier.

In many senses, as an individual I'm not important to Cogent. It's the principles, values and quality of the staff that separate Cogent from other companies and help us deliver great solutions at great value-for-money. All of these things will survive my departure. Cogent has always been managed by a small group with contributions from throughout the company, and this will continue. The trepidation I mentioned earlier is for myself, rather than for Cogent.

I expect to finish up with Cogent at the end of March, and I'll pass on more details as they become available.

Waste that we watch for

• Partially Done Work
  
• Relearning
  
• Hand-offs
  
• Task Switching
  
• Delays
  
• Defects
  
• Extra Features
  

Cogent Principles

Just in case you're interested :-)

• Feedback over Technical Elegance
  
• Reliability over Feedback
  
• Relationships over Code
  
• Learning over Producing
  

Are we there (agile) yet?

I get asked this a lot, and let me say that I personally don't care very much. I do care whether or not the development process is effective or not, and mostly you know the answer to that before you ask me. But if I needed to form an independent opinion here are some questions that I'd ask you about feedback cycles. The underlying assumption is that a team will almost continually make mistakes (that vary dramatically in size) and that a lot of our practices and processes are about exposing those mistakes as quickly as possible. So how long is it between the these mistakes and the practice/process/activity that will expose that mistake, and how do you make that period smaller? These questions aren't presented in any particular order.

• A feature doesn't add any value


• Our code is unmaintainable


• We have duplicate code (or other quality problems)


• A developer introduces a new defect


• We've broken an existing feature


• What we're building doesn't match what was expected


• A feature is costing too much to be worth implementing


• A feature is unusable


• A feature works in isolation but not when integrated with other features


• The entire project is costing too much


• The project is going to cost too much

In addition, how long from a the time a feature is requested to the time that it hits production?

There are certainly other things that can go wrong with a project, but I think that reducing feedback cycle duration (time between event and feedback on the event) requires applying many agile principles and practices.