Quality - I wish we'd be a little more precise

Many years ago I worked at Bankers Trust Australia, building derivative product applications with VMS Cobol for the user interface and Fortran for the numerically intensive parts. I mention the technology so that you can understand that this was the early days of the derivatives markets when there were only a few players in Australia, using relatively unsophisticated technology. I remember how proud we were of the first release, particularly of the way we validated all the user input and provided field-by-field feedback to the traders. Then I was lead into a trap.

"Wow, that validation is really impressive. It must have taken you quite a while to do that", said a trader.

"Yeah, it probably took a few weeks to get it all right", we replied.

"So you could have delivered it a few weeks earlier if you hadn't done that?"

"Yes, but the application would have crashed each time you made a mistake and you'd have had to start again", we said.

"We're pretty smart, and we can learnt to deal with that. Next time we'd rather have the features two weeks earlier so we can make some money from them thanks".

The underlying problem was that we hadn't talked to them about what was important (my excuse is that it was a long time ago and I was young and naive), but the lesson has stuck with me. In that situation, an input function vomiting it's guts on the screen was a scope issue, not a quality issue. In the years since I've regularly heard people say "we cut quality to go faster" or "we cut quality to finish earlier", but when I dig deeper I invariably hear that they altered the behaviour from the end-user perspective, and to me, a developer on a software project, that's cutting scope. I appreciate that other people with different perspectives might consider these features to be the difference between a high-quality or low-quality application, so when we start talking about "quality" we probably need to clearly understand which perspective we're talking about.

I was reminded of that by a recent post by Uncle Bob that starts with "People often make the argument that time to market is more important that quality. I’m not sure just what they mean by that. Do they mean that it’s ok if 20% of the features don’t work so long as they deliver quickly? If so, that’s just stupid.". I think that would be stupid, but what I think people mean is that the internal quality of the code has been sacrificed to reduce initial time to market, which is a very different proposition.

The end of passion

I'm supposed to be doing my US tax return right now, but I got distracted (what a surprise) and read this post from March 2009 by James Shore. At the end of the post James says two things that resonated strongly with me:

"If the point is to Be Agile, there's no need for Agile to actually work."

and

"Starting now, I'm reorienting my business to focus on people who want to be great."

Last night I said goodbye to me colleagues at Cogent Consulting, and one of the things that I meant to say but forgot was that for me interesting agile consulting work in Melbourne is now rare. I would have struggled to say why until I read James' post - I think it's that once-upon-a-time my consulting work was mostly with people who really wanted to be great, regardless of their current performance. It might not have been everyone in an organisation, but in each organisation it was enough people that greatness was the dominant theme. At some point those gigs dwindled - on the new gigs some people may have wanted to be great, but the team/division/company as a whole wasn't really interested. They pay lip-service to greatness, but it's the "we want to be great so long as we don't need to change too much of what we do" variety. My drive is to help people be great, and as that work has withered so has my passion. I may be willing to do work I'm passionate about for peanuts, but I think there's a thread in my mind which says if you can't give me work I'm passionate about then show me the money (and I think that makes me, well, human).

Now my soon-to-be-colleagues in Goldman Sachs may read this and shake their heads, so I need to be clear. I've always felt that enough of the people at GS wanted to be great to make working there worthwhile. It would be naive to think that it's everyone, everyday, but in my experience it's definitely enough. So I hope to have the pleasure of having my passion rekindle there as well.

I think this reinforces Cogent's recent decision on medium-term focus as well. The future of Cogent Consulting isn't to help other people with their agile transitions. The future is to blend Cogent's passion for software development with the needs of people who are passionate about their own domain, outside of software development. The result will be delivering excellent solutions that change people's lives - sometimes because no one else could do it economically, sometimes because no one else could build the partnerships that Cogent could build, and sometimes because no one else could do it at all.

Helping people transition to agile development - 10 years

Forming my own consulting company - 2.5 years

Finding outlets for my passion - a lifetime

Who Am I?

** Updated 26/3/2010 **

If you read this blog regularly then you will know that I'm about to embark on a career change. Part of this will be moving from a relatively safe environment where I have a reputation (Melbourne) to a challenging environment where I'm a relative unknown (London). When I meet new people in London (professionally) I'd like to have something I can point people to that gives them some background and helps to set their expectations. I'm personally expecting to be meeting quite a few new people, and I hope that this can accelerate the familiarisation step a bit.

First, I'm incredibly introverted. I've learned to be vocal in some situations, but sometimes that confuses things because people don't notice just how introverted I really am. How does that manifest?

• I'm pretty quiet in meetings
  
  
  Particularly if I don't know all the participants I tend to listen more than I speak. That doesn't mean that I'm not thinking about the matter, or that I'm not interested, it just means that I'm not talking :-)



• I think slowly
  
  
  Sometimes experience gives me intuitive leaps, but I'm often the person who comes back the next day and says "that thing we talked about yesterday isn't going to work, and here's why". Even when my intuition gives me the right answer quickly it can still take me a while to come up with an explanation. When this happens it's not that I'm being uncooperative and trying to work outside the meeting/collaboration, it just means it look me a while to get to where I was going



• I understand pairing gives better development results, but it doesn't come naturally to me



• I'm unlikely to join you at the pub for a beer
  
  
  It doesn't mean I don't like you, but it's not an environment that suits me.



• I'm not into public celebrations
  
  
  This can get me into trouble, especially when I'm meant to be "leading". It's not that I'm opposed to celebration, it's that it's not something that I volunteer for. If you happen to suggest my team needs one I'm likely to agree and ask you to arrange it!



• I don't deal well with conflict, particularly if it happens quickly


I'm pretty analytical, but emotions can be a bit tricky for me. I need to gear myself up for situations where there might be conflict, and if one springs upon me unexpectedly I'll usually disengage. It's nothing clinical (empathising comes fairly easily to me), but it is something I've learned about myself.

I've managed to add a few layers to this introverted foundation. I'm a reasonable public speaker, I generally enjoy it, and I'm happy to talk about software development to any group that's interested.

I've been referred to as a "code quality freak". My attitude is that you should work on the micro-level details of programming until they've become muscle memory, so that you can free your brain up to work on the complicated stuff. This covers all the stuff you'd find in coding style guides and books like Bob Martin's Clean Code (though I have to fess up that I haven't read that yet). Even at the micro-level I like to use tools to tell me where I've let me standards slip, so I'm keen on tools like Simian, Checkstyle, Complexian and their equivalents in other languages. These days I'm also interested in visualisation of the output of these tools, though I don't have as much experience in that area.

Another metaphor I use around code quality is that it's like hygiene in a hospital - we shouldn't need to talk about it, we should just do it. If we can't maintain hygiene then everything else is going to get a lot, lot harder. Some people suggest that you can clean up your technical debt by having dedicated iterations - to me this is like suggested we let crap pile up around a hospital and clean up every couple of weeks. It doesn't work for me.

I love automation. I have a very small brain and I'd rather use it for processing than storage. Manual processes are slow, tedious and error prone - I want to get rid of them.

I don't think that software development is predominantly a technical problem, I think that in most cases it's a social problem - how to we organise the people and technology we have to delivery an effective solution as cheaply as possible. Commercial constraints demand creativity and make software development challenging.

I like agile practices and processes, but they are means to ends. I think that as humans we are all imperfect - we should accept that we make mistakes, but try to reduce the consequences of our mistakes and try not to make the same ones over and over again. We can continually improve, but to do that we need to continually reflect and continually learn. I'm very keen on the ideas emerging around expertise and deliberate practice.

I'm sure I'll think of more and extend this post, but there's a start :-)

Seven Norms of Highly Powerful Software Teams

I found this, a handwritten copy no less, while cleaning out a filing cabinet tonight. At the bottom I've written "Charlie Alfred, Education Services Manager, Object Design Inc, Object Magazine, May 1994". Apparently I've been carrying this around for almost 16 years. Since Google didn't find the article, I reproduce here for your pleasure (and so I can find it again myself).

Affinity for win/win

We strive to create an environment where the personal aspirations of each team member contribute to the goals of the team. We each are personally committed to achieving the goals of the team without sacrificing our lives outside work. We firmly believe that on the strongest teams the goals of the team agree with the goals of its members, rather than supersede them.

Common Mission

We share a common mission that is challenging, worthwhile, and clearly understood by all. This mission may be perceived by others as impossible or not worth the sacrifice. In this way, the mission helps us to identify our partners. Also, the more impossible the mission seems, the more we are forced to work together if we hope to succeed.

Quality

Quality is at the core of everything we do. If something is worth doing at all, it is worth doing right the first time.

Understanding Requirements

We strive to fully understand the requirements of the systems we plan to construct, including being acutely aware of how those requirements evolve over time. Furthermore, we actively validate our understanding of these requirements with the system's intended beneficiaries.

Interdependence

Individually, we each contribute strengths that counterbalance each other's weaknesses. Collectively we possess all of the skills, attitudes, and habits necessary for team success. Wherever an essential skill, attitude or habit is missing (or lacking), one or more of us makes it a priority to develop it, or we seek to add a new member who possesses it.

Receptivity

We are open to sources of new ideas and new ways of doing things, and use the norm to resolve conflict. We listen to each other's points of views, aware that our commitment to the same mission means that differences of opinion identify alternate paths to the same goal rather than competing paths to different goals. Also, we continually learn about and apply the latest paradigms, processes, and products in our technical, organisational and interpersonal activities.

Efficiency

Around here we work smarter, not necessarily harder. We sprint all out toward our goals when it is necessary to do so, but also know how to relax and rejuvenate. We make the 80/20 rule work for us. We take no shortcuts and cut no corners on the 20% of our tasks that produce 80% of our results. If any sacrifices must be made (in the interest of time), they always fall in the 80% of our activities that produce 20% of our results.

Thanks Charlie!

Netflix Culture

Many of you may have seen this already, but if you haven't I think it's an essential read. "Freedom and Responsibility Culture" describes how Netflix resolves the challenges involved in growing rapidly while maintaining a culture that supports rapid innovation and excellent execution. It's a good explanation of why they don't adopt the process-bound, complex-compensation approach that I see at many organisations. Some of what they do is consistent with what we do at Cogent, but some of it is radical even for me (for example, there is no vacation policy!). I wish I had read it earlier.

Cogent Departure, Part 2

In an earlier post I mentioned that I'd pass on more details of my Cogent departure as they became available. I'm at that point now, but before I can tell you that story, I have to tell you this story (a tribute to my 6y.o. son's Captain Underpants fandom, which is another story altogether).

Twenty years ago, come March, I moved to London. It was the height of Thatcherism, and shortly after I arrived I went to a matinee at the theatre. At the end of the performance someone came on stage to say there had been "a bit of bother" and we should avoid Trafalgar Square. As an ignorant new arrival I didn't know how to do that, so I ended up walking through the debris of the Trafalgar Square Riot. Welcome to London, Mr Hayes! London is an amazing place, with deep history and so many things to see, but the next year is tagged in my mind with impressions of tension and antagonism. I've visited since and found London to be far more pleasant than it was in 1990.

Ten years ago I was working at Goldman Sachs in New York. I was leading one of the best development teams I have ever had and we were implementing XP on a full project - a first for me and a first for Goldman. Early the next year I did something very un-Goldman - I resigned. I used my bonus to pay off my last debt (the mortgage on my house in Sydney), Amanda and I travelled around America (20,000 miles in just over 100 days), then we moved to Melbourne and did as little as we needed to to cover the rent. There were about 6 people in Thoughtworks Australia doing "agile", but they were working remotely on the Caterpillar project, and that was it. I spoke to as many groups as possible about XP, and things grew from there. Essentially this was the beginning of the path that lead to Cogent Consulting.

This year I'm going to complete some decade long cycles. The current plan is to return to both London and Goldman Sachs, as EMEA Controllers CTO (EMEA is "Europe, Middle East, Africa", but from a technology perspective that's Europe). Before anyone gets excited, there are lots of CTOs in Goldman Sachs - I think I'll be responsible for technical direction for about 0.5% of the banks IT staff, and I'll be in a matrix with many other architects. Regardless of scope, I think this is a great opportunity for me and will be a great experience for my family. We're tentatively scheduling a move in April, but plans are on hold pending the tabling of financial services legislation in London that may impact GS staffing. I still plan to finish up with Cogent at the end of March and to take some leave if there is time.

On the other hand, my infrequent blogging and twittering will probably become almost non-existent. GS holds things very close to its chest, now more than ever I expect, and is very careful that random technical comments don't get associated with the GS brand (for either better or worse). Since I'm an expert in random comments I'll need to watch my mouth fairly closely. :-)

If you're in London and you'd like to catch up later in the year please let me know - part of this opportunity is the chance to renew (and create) relationships in the northern hemisphere!

PS. Some people have read this and wondered why I would move to a job in management. At GS architects at all levels code 80% of the time, so if anything I'll be doing less management than I do at Cogent and in my current consulting roles. I suspect a lot of it will be up to me. I still expect to have plenty of opportunities to influence behaviour.

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.

Roles in a self-organising team

One of the things that I'm asked to do fairly regularly is define the roles for an agile team, be it for Scrum, XP or some other flavour of agile. I usually end up doing this based on required skills, but my first impulse is to refuse, because I don't believe that a self-organising team actually has roles and I think that defined roles limit both the individual and the team. Let me examine that point before I explain how I do go about defining roles and why.

There is one role on a self-organising team - team member. The responsibility of that role is to bring all their skills to bear on the team's problems and organise their contributions to maximise the team's effectiveness.

When something needs to be done on an agile team everyone on the team should be able to see it, and in many cases it will be obvious which individual or individuals are the best suited to getting it done. The simplest approach is to allocate tasks based on skills, but the team might decide to use other criteria as well - they may need to grow their capacity in some area and decide to give the task to someone with less experience to give that person some practice; they may have limited capacity and be forced to give the task to someone who needs to learn the required skill, usually with mentoring from someone on the team. There will also be team-specific and project-specific reasons for not allocating tasks based simply on skill set. The important thing is that the reasons are well-articulated, and that the team member accepts responsibility for the task rather than having it arbitrarily assigned to them.

Although multi-skilled teams are normal and effective, provided the team is dedicated to achieving a result, has sufficient time and is reasonably self-aware you can imagine any arbitrary skills starting point. We could take a team that consisted entirely of testers and give them some work to do. The first tasks they encountered would require some analysis, so someone from the team would need to do this. They wouldn't complete the analysis as quickly or to the same quality as someone with the relevant experience, and they might not enjoy it as much. They might also need to get outside expertise (training and/or mentoring), but they would get through the work eventually. The team might find someone who wanted to grow into this role and make them the primary analyst, or they might decide that no one enjoys it and the role should be rotated through the team (this is probably less efficient, but it explicitly ranks satisfaction and retention ahead of efficiency). The same pattern can be repeated with development and anything else the team needs to get done.

Don't get me wrong - this is clearly a slow path to success and I wouldn't recommend it, but it is a valid approach. It's a contrast to the behaviour I see more often, which is "I can't do X, because I'm a Y". "Can't" is definitely the wrong word - finding the right word will determine how you respond to this assertion. If the person is really saying "I don't like doing X" then keep the assignment short and try to find some other way to make it attractive. If they're saying "I don't know how to do X", then they need training, guidance and support. If they're saying " I won't do X" then they probably shouldn't be part of the team.

That's why I don't like roles - why do I provide descriptions of roles and responsibilities? It's because I would rather start with a team with diverse skills than spend a lot of time developing the same skills, and most organisations understand that as a request for roles. I also appreciate that most people have gravitated towards a role that suits their preferences and skills, and asking people to move into other areas requires both time and motivation that we usually don't have a the beginning of project.

My hope is that companies that go to the trouble of assembling multi-discipline teams will also recognise the benefits of keeping those teams together for long periods of time. Time is the essential ingredient to building role-independent teams - it helps build trust between the team members, it lets people experiment and learn, and it gives the team opportunities to get feedback on different approaches to task assignment.

An interesting exchange

I wrote this in response to a customer email, but it seemed like something that I could put here:

On 14/10/2009, at 9:15 AM, ... wrote:

Morning Steve,

Saw this article and thought it was interesting. http://www.javaworld.com/community/node/3530

Regards
...

From: Steve

It is interesting. I think it's hard to get the tone right when you're dismissive of agile zealots (who it's hard to agree with, almost by definition), without being dismissive of agile in general. Having been involved with agile for a long time I have a nice clear centre that tells me that agile should be adaptive, but I've also seen the problems that come from being too adaptive too early.

I totally agree that the process for one or two really talented, motivated people is different from the process you use for larger groups/applications. Alistair Cockburn has been very explicit about this in his writing about the Crystal family of methodologies, and Kent Beck has touched on the same subject from a different perspective when he wrote his blogs about "Flight of the Startup". The hard part for most of us is dispassionately looking our our team and ourselves and changing process over time. It's easy to err on the side of too much, too soon or too little, too late, but very hard to judge it just right.

On the "where's the Access of today", that's a question that we've thrown around within Cogent as well. My personal opinion, shared by some others in the company but not everyone, is that we've gone backwards over the last 10 years in productivity and our ability to deliver things quickly. Our capabilitity has increased - we can deliver bigger, more sophisticated applications - but in the process everything seems to have become harder.

I agree with the poster who mentioned the combination of Ruby on Rails and Heroku - that's the combination that I'm using for my personal projects now. I think it's the combination that's the winner - there are other frameworks that to me look more promising than RoR but with each of them I have to manage my production environment myself (for some of them even setting up a production environment is a challenge). Heroku takes care of that and make deployment as simple as possible.

On the OS X desktop MacRuby looks very promising, leveraging Inteface Builder with the power of Ruby. I don't play in the Windows space, so I don't have any idea what the possibilities are there.

...

Steve

My Kindle DX and I

I've fielded more questions about my Kindle, and how I use it in Australia, than just about anything else I've mentioned on Twitter so I thought I'd put the information in a blog post.

After October 7 this information is really only useful if you want a Kindle DX - if you're happy with the smaller Kindle then you should buy an internationalised version and avoid all the issues I'll describe.

Why a Kindle?

Books are heavy, and I often want to carry around more than one for reference, especially if I'm doing some writing. At lot of the things I want to read these days are also in PDF and I haven't found a good way to read those - I end up reading a lot either on public transport or just before bed and my laptop isn't convenient in those environments. I tried using my iPhone to read PDFs but that doesn't work for me (other people seem very happy).

The Kindle is great for reading material that's been formatted for the device - I haven't found it to be that good for PDFs (more on that later). It's much better for me than either my laptop or my iPhone. The screen has great contrast, a huge viewing angle, and when I first opened the box I couldn't believe the starting image was being displayed on something electronic.

First Problem

The first problem is that Amazon won't sell you a Kindle DX if your shipping address is outside this USA. My first solution was to have one shipped to a friend in the USA and then shipped on to me, but it turns out that there are people on eBay who can help. My KIndle DX arrived in the original Amazon packaging, with the original seals intact, with a new shipping wrapper pasted over the original.

Charging

The Kindle arrives with a USA style power adapter, but the approach is the same as the iPhone - it's a USB connecter that plugs into the adapter. Since I already have an iPhone charger I can plug into that, or I can charge from my computer.

The Kindle is fairly frugal with power. Since you won't be using WhisperNet you can turn off the wireless connection to reduce battery use. The screen is bi-stable, so it only uses power when you move from one page to another. I charged my Kindle last Friday night - it's currently Thursday morning and I'm still using it happily.

Content

Amazon (who I'll get to later) isn't the only source of content for your Kindle. You can use .mobi files from other sources, or PDFs. For example, I buy combo packs from the Pragmatic Programmers, so I have .mobi versions of all of their books, and their magazine comes out in the same format.

If you want to buy content from Amazon you won't be able to do it with an Australian credit card/address. I've set up a separate Amazon account for my Kindle purchases and given it my old Brooklyn address (you can use that too if you ask me nicely). I buy an Amazon gift voucher on my Australian account and then use the gift card to buy the content on my Amazon Kindle account. It's an extra step, but it's not really that much of a problem. I download the content to my laptop and transfer it to my Kindle via USB (the Kindle looks like any other disk drive).

Carrying an extra device

Yes, it's one more device, but I've put my Kindle in the back pocket of my backpack and I really don't notice the extra weight at all. It's always there if I want to read, and I use it with one hand even if I'm standing on public transport.

Summary

There's no economic reason for me to have a Kindle, but I'm really enjoying the experience. The proof of the Kindle pudding will be how it scales to having the majority of my library on a device I carry around with me. I suspect that this will change the way I treat information.

How I learned to stop worrying and love Enterprise Agile

I spent Wednesday at the Software Craftsmanship North America Conference and the evening at a cocktail party hosted by Thoughtworks. It was a very interesting day, and in the evening a chance comment by Ward Cunningham helped dispel a misconception I've held for a decade. For the last ten years I've been conflating agile and what I'll loosely call mastery. I think it's fair to say that mastery helps you do agile well, but it's not essential to labelling your project agile.

So I sat down and tried to figure out what "agile" was from my perspective. There are clearly lots of ways that you can attack that problem, but for the moment I've settled on this - a project is agile if it uses scope as the control variable and incorporates feedback mechanisms to facilitate that control.

That's a pretty broad definition, but it helped clear something up for me right away. I've been annoyed by resumes that said "agile experience", because I didn't think the people claiming agile experience met the cut. The problem was that saying "has agile experience" is like saying "has programming experience" - it may be true, but it's not terribly useful. You need a lot more detail before you can form any judgement on the claim - what practices has the person been using, how long have they used them for, can they describe the pros and cons? Almost exactly the kind of information you'd want to have about someone's programming experience.

Mastery, on the hand, is about continual learning and improvement, in this case in the agile context. I try to pursue mastery of agile software development, and I prefer to work with people who aspire to be masters, but that's not the only way to approach agile. Most people in any field are not masters, and many do not aspire to be masters in that particular field, but that doesn't mean they won't benefit from understanding and using agile practices.

So while I will personally continue to pursue mastery of agile software development, and want that to be the focus for Cogent Consulting as well, I hope to spend more time thinking about how to apply agile development in environments that don't have access to master software developers.

Software Cultures

I think every programming language (and frameworks too) generates a dominant culture. It might be implicit in the language/tool itself, or it might happen more gradually through self selection. For example, here's how I distinguish three cultures (the boundaries are inherently fuzzy, and I'm aware that this is totally personal opinion, so people are bound to disagree by either raising counter-examples or saying they don't agree, and that's fine). I also have my tongue firmly in my cheek, but I believe there's an element of truth in each statement.

Java - a fascination with flexibility, generally achieved through complexity (and a healthy(?) does of XML). Ten years ago I would have said Java was focussed on solidity and reliability (in the meeting expectations sense), but I think this has changed over time. New functionality is implemented by adding new options. If it doesn't work, it's because you didn't configure it properly.

Rails - a fascination with bright, shiny new toys. Encourages the image of the developer as a person young enough to live in the code, who can deal with either new tools or tools that fundamentally change every three months or so. New functionality is achieved by implementing a new plugin/gem which needs to be compared to all existing alternatives. No solutions is 100% complete because people lose interest first. If it doesn't work, get in there and change the code yourself. [note - I don't comment on Ruby itself as I don't have enough exposure to the non-Rails community]

Seaside - I'm an old-hand in Smalltalk, just learning Seaside. So far I see a fascination with having something that just frackin' works (though it might be heavily engineered). The documentation sucks though, so get into the code. Changes are generally transparent and backwardly compatible. If it doesn't work, you did something wrong - the community is the documentation.

Each of these cultures has strengths and weaknesses. I'm 46 years old (shit, when did that happen), my raw memory isn't as strong as it was, and I don't think as quickly as I used to. But I have a load of experience in developing design models and applications - I want tools that get out of my way and let me build things. Given my Smalltalk experience, Seaside is a great match for me - much better than Rails. If there was the equivalent of "Agile Web Development Using Rails" then it would rock!

In an age when everyone needs to use portfolio theory to manage their software investments, starting low-cost initiatives by the dozen then abandoning the ones that don't work out, Rails is a clear winner over Java. It lets me experiment at low cost, it lets me get something out-the-door quickly. In that environment Java is a set of leg-irons. But the Rails culture thrives when people have enough time and energy to deal with a firehose of changes and alternatives - as an entrepreneur a lot of this is simply waste. One solution might be to standardise on a particular configuration - that seems like a false.optimisation.

What would you like in a code quality tool?

Although continuous integration has been a huge step forwards for the development community I think that over time we've tended to treat it as a rather large bucket that we could keep tossing things into. Sure, someone should immediately address that method that's too long, but should it really stop the build and the release of the next version if all the tests pass? My feeling is no, it shouldn't.

I think that the agile community could do more to encourage various parallel continuous processes that test different aspects of the application. In particular, we could separate the static analysis of the code quality from the behavioural analysis that we perform with tests, be they unit, integration or functional tests. If we separate the two aspects then we can look to improve them at different rates and in different dimensions. This separation is the motivation behind an idea that Marty Andrews and Simon Harris have been kicking around for a few years (Marty is the author of Roodi and Complexian, and Simon is the author of Simian, so they have a long-running interest in code quality). Cogent is now planning to turn this into a product - something that you can point towards your source code repository and simply unleash.

We don't have a name for the product yet (suggest one if you like), but it will run static analysis tools (like Checkstyle, Simian, Roodi, Reek, Flay) against each revision of your code base so that you can see trends over time, and it will produce warnings when the values of the metrics exceed certain thresholds. The product will be free for open source projects.

We'll start with a simple, web-based version, probably to run over Ruby projects in public Git repositories (because that's low-hanging fruit for us), but we're going to be very community driven. With this in mind we have a survey that will let you influence the development direction, even before we start. If a tool like this is something that interests you, please fill in our product survey. As a bonus, the first 500 people to complete the survey will get unlimited free access to the product in recognition of their contributions.

Emerging Agile UX Practices

I am not a UX professional, but I've interacted with a number of them over the last few years, in the context of agile development. The interaction hasn't always been smooth - the prevailing mood has been that agile development was asking UX professionals to do a bad job, but I've never felt that way myself. My feeling is that UX professionals and software developers have been on similar paths in regard to agile development, but the UX people are starting a few years later and have had less leadership so their challenge has been more difficult.

Why do I think the paths for both roles are similar? Because once-upon-a-time many software developers would have said that agile was asking them to do a bad job. After all, how could you do a good job with no upfront design, no long architecture phase, no detailed requirements? But what developers realised (either quickly or slowly, or perhaps not yet) was that agile values didn't mean doing a bad job, they meant doing a good job in a different way. Part of that was learning new skills and new ways to work. The software/programming community was lucky because they had early leadership in these skills and practices.

The feedback I've gotten in the past from UX folk was essentially "when we're in an agile project we can't work the way we work now", to which my answer was a resounding YES! You (as a profession) need to find new ways to work that produce good results faster. It's not your fault that those techniques don't exist yet, or that they may be hard to discover, but that doesn't invalidate the search. But I haven't done very well at explaining that.

However, practices for UX professionals on agile projects are emerging now, and Jeff Patton has done a good job of describing the practices that he sees working in this context. Moving to agile development means developing new approaches for everyone involved, and it's good that this is now a little easier for UX.

How about the small-law firm model?

In reponse to my previous blog post Robert said...

'I've always wondered if the classic small-law firm model would work with IT shops. You know - newcomers start as "associates" and get paid a salary (possibly with bonuses), but the ultimate goal is to get recognised as a partner, in which case you shift to profit sharing.

The associate-level allows the firm to recruit new talent at a fixed risk; the partner-level allows for the co-operative mode. As long as the ratio of partner-associate is good (the case in small law firms, not large) the competition between associates isn't likely to be unhealthy - particular if the promotion to partner is merit based rather than "we've got 1 slot open this year".'

It turns out that we have some of these elements at Cogent, but we didn't have that model in mind when we created them.

We do have two groups for allocating profit share. One is like "partners" - it's myself, Marty and Simon. 50% of the profit pool goes to the partners and the remaining 50% is split evenly over all the employees. We needed that arrangement to make it sensible for the partners to stop doing personal consulting and switch to a salary-plus-profit-share arrangement, and even then we're only just now at the point where the partners would nominally break even. It's also rather abstract because as long as we're pushing consulting profits into product development there aren't any cash profits to share anyway!

So far this is very similar to the small-law firm model. The difference comes when we consider what will happen over time. It seems to me that the small-law firm model is predicated on growth, or at least turn-over - on the expectation that when you get promoted to partner there will be a supply of associates to generate profits. I'm biased against models that encourage growth (though our existing model has that bias at the moment). Over time at Cogent I'm actually expecting to reduce the partners' percentage of the profit share pool - keeping it enough to keep them interested in staying at Cogent, but gradually making more and more of the profits available to the general employees.

There are flaws in both approaches, so it will be interesting to see how the profit share approach evolves at Cogent over time.

Allocating rewards in co-operative environments

At Cogent Consulting we compensate people in two ways - we have healthy base salaries and we offer profit share that is not linked to performance or to salary. It's close to equal shares (there are some details that mean that's not true overall). We debated this arrangement when we created Cogent and I've discussed it with colleagues back as far as 2001, but it's based on our gut feel of what would minimise conflict and maximise co-operation. It avoids the debate about relative performance that bonus systems create, that are normally circumvented by secrecy (secrecy isn't an option at Cogent). So it was interesting to read this in No Contest: The Case Against Competition by Alfie Kohn:

"In recent years, Deutsch and his associates have investigated not only the way tasks are set up but the way rewards are distributed. Among the possibilities are a winner-take-all system (which is what many contests amount to), a distribution proportional to accomplishment, and an equal distribution. Much as we tend to assume that competing boosts performance, so it if often taken for granted that the first two arrangements provide a crucial incentive for working hard: reserving a desirable reward for the winner is thought to promote excellence. A series of six experiments with Columbia University students, involving tasks that ranged from decoding Japanese poetry to estimating the number of jellybeans in a jar, was devised to test this assumption. The results: When tasks could be performed independently - that is, when there was low means interdependence - the system of distributing rewards had no effect on how good a job they did. There was absolutely no evidence to suggest that people work more productively when rewards are tied to performance than when everyone gets the same reward. But for those tasks where success depends on working together, there was a clear difference. A system of equal rewards, Deutsch discovered, "gives the best results and the competitive winner-take-all system gives the poorest results".

Notice that this is also a profit-sharing scheme, not a bonus system tied to some particular behaviours. We hope that our behaviours are driven by our principles, and that long-term this will generate profits. We wouldn't want people to change their behaviours to maximise single year's profit. If we ever detected that we'd need to review the profit-sharing scheme.

Cogent as a business

Updated June 18

Along the Cogent Consulting journey we've documented a few different sets of values, principles and goals. Our manifesto was created quite early. Recently we've supplemented this with a simple list of values

• Openness


• Integrity


• Respect


• Craftsmanship


• Collaboration

and goals

• Develop non-consulting sources of income


• Build some kick-ass software


• Work with good people


• Have flexibility in lifestyle and the amount of time I want to work

We should probably rationalise all this (and I just added that task to Runway), but first I want to add some more philosophical statements that occurred to me after I read Small Giants by Bo Burlingham.

• We need to make a profit, otherwise we can't achieve our other goals. That's a constraint


• Doing the right thing for the customer is more important than maximising profit


• Our families are more important than our customers


• For everything we do we should ask not 'is it profitable', but 'is it the right thing to do?'.


• Right now, product development depends on consulting, and consulting depends on business development. We need to bear that in mind when we're setting priorities.
  

When I started to write I thought there would be more points, but combined with our existing manifesto that seems to say most of what I need to say.