I sat down to lunch recently with a good friend, and we talked about challenges we face in staying motivated, and in keeping the troops motivated as well. On reflection, I think it is a matter of keeping everyone jazzed.

We all hear about amazing places to work, and Google comes up in a lot of conversations. Flexible work conditions, amazing perks, even one day a week where employees focus on whatever they want to (which has been the fruitful source of many of their products or research areas). Done right, everyone wins, and Google's success is at least partially a testament to this approach.

If we miss something, though, things won't always work out as we had hoped. In this one shop, my friend had set up what seemed to be a great work environment - totally flexible work hours, a comfortable workplace in one of the city's trendiest areas. Even the incentive to the troops to be creative and come up with great new ideas.

What happened was the opposite of what was intended. While not everyone took advantage of the flexibility, there was enough of a drop in energy that the net effect from the group was disappointing. Product wasn't coming through as expected. Those new ideas? Well, not too many materialized. In the end, it turns out a couple of people were let go.

What went wrong? We didn't nail a conclusion over lunch, but I have a hunch or two. If we take a look at what Google stands for, there are a couple of statements that may be relevant. Buried deep in their Philosophy is the statement "Give the proper tools to a group of people who like to make a difference, and they will." While it sounds like this group did what they could to provide the proper tools and environment (granted, their pockets are not quite as deep as Google's), the desired result didn't materialize. Could it be in that phrase "who like to make a difference"?

Stop right there. I'm not headed down the path of suggesting that they were a bunch of deadbeat employees that don't like to make a difference. I think intrinsically, we all want to make a difference in what we do, but we all also go through stages of lower energy. I've gone through bouts where I felt like I was drifting along, I'm even dragging myself out of a stage where I felt quite burned out, after a little too much of that making hay while the sun shone.

Where I am headed with this is that alongside the great work environment, there needs to be a fresh, exciting raison d'être, something that motivates and inspires us to greatness. The second relevant statement from Google's site is their mission statement itself: "to organize the world's information and make it universally accessible and useful".

Few companies have such a compelling vision. While I don't think we can all have such strong visions for our existence, we need to develop the best vision we can, and it needs to be something that the entire team buys into. It has to be something that jazzes everyone in the group, something that inspires them to make a difference. Whether it is inspiration to defeat a common enemy, or altruistic and world-saving, there should be no question about what you are all trying to achieve.

A good workplace is important, to be sure, but the motivation needs to be more than a request to get your work done. A strong vision can truly jazz a team, it is the difference between the workplace being a job and a joy. - JB [top]

Refine the Messaging Platform (Compendium 7.22)

There are a lot of things that I like about the agile movement, many of the things I have been doing myself or recommending to clients for years. Short iterations, plenty of interaction, early value and strong leverage of change. A critical new improvement is that it is now OK to talk about how you are going to approach a problem, to talk about process without thinking that the whole thing is a waste of time and money: a nasty stigma has been removed. One thing that is still holding us back, though, is the argument by many agilistas that you have to jump on the bandwagon or you won't be successful.

Some suggest that the agile movement is crossing the chasm, as Geoffrey Moore has modeled for any technology adoption. For all the useful talk about the value of agility, there are a number of prominent proponents of Agile that go so far as to say that you need to adopt these approaches, no question about it, if you want to succeed in software development. While this talk works well with the early adopters and fanboys that have made up the lion's share of people embracing Agile thus far, it will cause serious heartburn with those that are further along the adoption curve.

Think about these assertions a bit. Many would suggest that deep early-stage analysis will never work, that comprehensive project planning is bound to fail. Some would even suggest that if a team is not doing Scrum, they are not worth investing in. Here is what these assertions tell me.

I have been involved in projects where deep early-stage analysis has provided tremendous value (yes, even recently!), I have led comprehensive planning sessions that drove our successful delivery of what was promised (in a large, iterative project, no less), and have seen project success with an extremely wide range of development approaches, many of which are clearly outside the Agile box. Not only do I think there is value in these techniques, I know the value is there based on personal experience (for projects where these techniques are appropriately applied).

What does this say about assertions that these non-agile practices unequivocally don't work? It tells me that the asserters have never been involved in projects where these practices contributed to success. Either their experience has been too limited to afford them time on these successful projects, or their influence has been insufficient on these projects to drive these techniques to be applied successfully. Or, of course, these statements could simply be hyperbole.

Either way, their credibility has taken a serious smack upside the head in my books. While their evangelical cries from the pulpit to join in on the movement may be welcome to some, they are turning many others away in the process. They are getting bums in seats, but are they the right bums?

We need to recognize that we sell people on change. Most credible sales experts strongly advise against demonizing the competition. A truly effective product does not need an evil demon to compare against, it should be able to stand up for itself on its own merits. Indeed, if we need to support our case by slamming the opposition, if we have to take the "if you are not with us, you are against us" approach, the message loses much of its punch for anyone outside that early adopter (known as zealots to some) category.

Like most people, I think the overall software development industry could use some serious improvement. Unlike some, though, I think that what is best depends very much on the project context, and it is never appropriate to propose a solution before this context is known. If the agile movement is truly crossing the chasm (and it is not clear that we are there yet - for the extremely wide range of clients I work with, agile is not yet part of the mainstream conversation), the message needs to be adjusted for an audience that needs more convincing.

We need to stop the screaming from the pulpit and demonizing practices that have been successful when applied appropriately. If we want to successfully cross the chasm with agile approaches, we need to be careful to avoid jumping the shark. We need to refine the agile messaging platform. - JB [top]

Go With Your Strength (Compendium 7.20)

I see many companies that start out with a compelling idea for solving a nasty business problem, but somewhere along the way their implementation gets a lot fuzzier. In more than a few situations, we are best served if we remember to go with our strength.

The genesis of any new product is an idea. While some products are built simply because the technology is feasible, the really great products come from the marriage of an idea and a business problem that this idea solves. Usually, these ideas come from within companies that have serious domain experience: this is the catalyst for the significant ideas on how to tackle the tough problems they face.

Something happens along the way for too many companies. As they move forward to build their products that solve these problems, this compelling vision can get seriously diluted. In the interest of building a full-fledged product rather than a proof of concept, they start to add things. It can start innocently, with the shopping-cart paradigm that is familiar to anyone that has bought something online. While there is an important problem to be solved, somebody decides the application will get more eyeballs if it handles the social interaction like Facebook. Maybe it would be cool to communicate within this community as with Skype or Twitter, and of course there is the need to be able to blog, and that will have to be supported with RSS feeds, and then there is the rankings and tag clouds and...you get the picture.

Pretty soon we have Bloat 2.0.

Suddenly, if we look at their product from the perspective of what's working or what's front and center for the user, we see a mashup of also-ran technology, none of which was invented here. It's a lot of different things, all those things not quite as polished as the apps they have been mimicking. And the original idea, the whole point for heading down this product path, the uniqueness, is now a lot tougher to see.

One thing to remember is that all the things they have been mimicking - the Facebooks, the Skypes, the Twitters - got to where they are by excelling in a single idea, not by trying to be all things to all people. They do that one key thing really well, and have become a leader in that arena. Others follow, and the VC's will only fund so many of them before ADD kicks in. Not many of the followers make a killing.

If you have got a great idea, if you think you know how to solve a problem that others haven't been able to do, stick with that strength for crying out loud. Resist the temptation of adding all the bells and whistles that seem to be hot, even if the implementation of these things is relatively easy - while you might be adding incremental value, you are diluting your core differentiation. You will probably find that the implementation of your core idea is fraught with challenges that don't exist when you are implementing established technology (as someone has already solved those problems), but if you deal with those challenges, you have something special.

Go with your strength, focus on the core. Push through and really nail that secret sauce of yours. If you can work your way through those challenges and see your valuable, well differentiated solution to the market, you will not find a crowded space.

That is, of course, until others start to copy your ideas and lose sight of theirs. Sweet. - JB [top]

Consulted (Compendium 7.15)

I'm in the process of putting together a project that will involve a number of external resources from different disciplines. The intent is to build a product that will require technical, sales and marketing resources, and likely some branding and analytics effort, most of which will come from external consultants that I know. Being a consultant myself, I have learned the cost of totally missing the mark with a proposal, but I think this is the first time it has happened to me. I feel I have not been listened to, I feel insulted. I realize that this is the concern I often have to battle against with prospects, that they are going to feel 'consulted'.

Here's a draft of my reply, one of those 'better sit on it overnight' things. Names have been changed, of course.

Bob,

After reading your letter about how you see your company supporting this project, I would have to say we're not quite ready to set up a call on Monday afternoon.

If you recall, twice now I have described with detail and passion some of the reasons for developing this product. Yes, in working with any new company, there is a discovery stage, but I have found that in working with SME's it is critical to come to the table with the sleeves rolled up and ready to add value from the start. My experience has been (and I recall your nodding in agreement) that to suggest that you will spend some time doing some planning, having some meetings, doing some other things that are specific to our respective niches, then providing a detailed plan and timeline with recommendations and suggestions for anywhere around $10k, the small business is going to show you the door. You undershot this by $500, but that's probably just to stay below that 5-digit ceiling.

This was a central distinction behind why I have developed this product - to be able to provide value out of the gate. It hasn't been difficult to provide tremendous value for far less money to my clients, and for me the bar has been raised in terms of my expectations. I have learned over the years to recognize the difference between strategic and tactical cash flow. While it may appear to be a good start with a new client to pull in $10k, and there is that dreadful expression of 'not wanting to leave money on the table'. I have found that being sensitive to the needs of the SME is critical for ongoing engagement. Even in times of strong cash flow, the SME is still sensitive to where the money goes.

Whether it is a matter of providing faster value only to the SME's or to provide this to all clients is a matter of choice (in larger firms the decision makers are not as closely wedded to the budget, and ten grand here or there is more like pocket change) - my choice is to provide this value to all clients.

Bob, in our discussions earlier, we talked about how deep down, while all clients would suggest they are different, they are actually similar in many more ways than is apparent on the surface. This is true for consultants as well. We both know that the traditional discovery phase that you propose has elements that have been reused from previous discoveries, even if the client is unaware of this point. Producing a detailed report of recommendations often leverages cut-and-paste from previous reports, and the report generation is the double-edged sword of mind-numbingly billable effort. I have no interest in doing that, I have no interest in billing for that sort of thing, and I have no interest in paying consultants to do that for me.

In your letter, you cite the notion of clear ROI for our collaboration. Thus far, you have proposed $9500 for telling me what I already know and identifying what you are going to do to provide value, which will cost me 'TBD' more. If we are deep down all the same as consultants, then you should be able to give me a credible expression of ROI based on your experience with similar clients, some concrete examples and reference clients of similar size, and you should be able to provide this expectation from day one. If the model is compelling enough, I'm certainly willing to drop all of these initial fees and let you participate in the action, something I am always willing to entertain with clients. To borrow a phrase from your letter, "Your success will be our success".

Bob, I think you have completely missed the mark here. If you are interested in engaging with Clarrus, you will have to demonstrate that you have heard what we already have discussed, and sharpen your pencil. My goal is not to spend here, my goal is to gain value.

--end of draft reply--

So, should I send this? In my travels, I have found there are consultants that are in it for the money, and there are consultants that are in it to provide value to their clients. As a prospect, I know that there is a sales pipeline somewhere that has prematurely bumped me to a new level. As a consultant, when you look across the table, do you see a bag of cash or an ongoing relationship? - JB [top]

Trust Proxies (Compendium 7.10)

I recently sat down for a discussion with a prospect about why they should use our services. I have faith that we are the right people to develop the application they are looking for from the technical perspective. From the purchaser's perspective, though, everyone they talk to will have that same spin. How do we engender a measure of trust when we're an unknown?

The strongest form of trust is grown through a series of rich and successful interactions over time. If you manage to demonstrate a track record of paying your bills, the banks will extend more credit. If you have been involved in a relationship and have been able to meet or exceed expectations, you are deemed trustworthy. In both cases, a key element of deep trust involves a lot of time.

The challenge arises, though, in a business environment like this one. We're responding to an RFP, and we have no history with the purchasing organization. We're not a public company, so there is no way do dig up financial statements or any audited information about our track record, for whatever that is worth. From my experience, merely being a public company doesn't instill a great deal more trust.

There are a number of prominent companies with quite a public track record, but it is a record of taking on big projects, running them poorly, making a profit on change orders and ultimately disappointing the client. No names will be mentioned, but this is not my idea of trustworthiness. It seems, though, that as long as we haven't been burned personally by those big public companies, they still carry the pedigree of being trustable. For some people, being in the public eye or having been able to jump the hoops of fiscal scrutiny, can act as a proxy for trust.

If we don't have the track record, or the public exposure that can be seen as a reasonable substitute, we need to translate trust into something we can work with. In most situations, we can think of risk and exposure as a way managing trust. A highly trusted source (through one of the more traditional avenues of trust) reduces the likelihood of risk occurrence to an acceptable level. Even if a violation of that trust were to occur, with a potentially extreme cost (including the destruction of whatever level of trust existed), the overall exposure is seen to be reasonable, and we'll go with that option.

Where traditional trust doesn't yet exist, we need to turn the equation on its head. We may not be able to provide assurance that the likelihood of problems is low, but we can manage the cost should these problems arise, and hence keep the overall exposure down to tolerable levels. Thinking in this manner, it can then be a reasonable approach to manage the compensation model so that it is more concretely tied to actual deliverables, rather than expecting a large down-payment or periodic payments along the way without having delivered any value. An iterative lifecycle, if managed properly, can serve to balance these payments by providing real usable value along the way (noting that this is far beyond merely something that runs). We need to drive the relationship with an understanding of how 'trustable' we are, and propose models that increase our attractiveness accordingly.

If we're on the client side, the same considerations exist. If we were only to work with people we have done business before, or with companies that have a public record, we are constraining ourselves to a wide range of opportunities. We can work with people we do not yet know, if we manage our trust models accordingly. It's all in how we drive the relationship.

In working with a publisher on my first book, I was an unknown entity, and the contract was structured accordingly. While I was given an advance, there was very little skin in the game from the publisher's side until they had a complete manuscript in their hands, 14 months after the contract was signed. At that point, they sat down and asked themselves if they were ready to move forward with publication. Had they decided against it for any reason, they could have even asked for their advance back!

Whenever we enter into a transaction, we need to build structures that give us a reasonable level of trust. Whether reduced likelihood of disappointment because of our past history or reduced cost by managing our cost/value model, we can work with anyone by managing our trust concerns with traditional risk exposure approaches. - JB [top]

Cultural Vital Signs (Compendium 6.48)

Once in a while, I get the opportunity to work with a great team, in a company that 'gets it'.

One of the things I do whenever I visit with a client company is to try to see if they would pass my employment test: would this be a place that would interest me as a place where I would want to work. Not as a means of surreptitiously identifying the next target for my CV, of course, but as a structured means of looking for clues about the culture there. My way of taking vital signs.

There are a number of criteria that I look for. All them come in shades of gray, rather than simply being checkable items from a list. In many ways, the things I look for at client sites are the same traits that I continuously strive for with my own business. Nobody I have ever encountered has absolutely nailed all of these things (myself included), and I would be surprised if anyone ever did. These don't come in a rank prioritized order, but more the order that they become apparent in our engagements. The company I worked with last week (and several times in the past) scores highly on all counts.

The first thing I look for is their openness to working with others: fellow teammates, new people in the group, consultants coming in. I've been to places where the people are quite cold to outsiders, where management wears an obvious façade when discussing issues. New employees feel like they have been left to fend for themselves. There are often walls between groups and interpersonal issues that fester and overwhelm what needs to get done. My preference is for complete openness, in a positive way: a recognition that we have all come together for the greater good, that together we are all smarter than any one of us. Trust and respect abound, and this is readily apparent.

The work environment is another key element to consider. In many shops, management has the corner offices and the developers and testers are located and equipped as an afterthought. There is a clear hierarchy, a caste system that indicate whose opinions really matter, and the environment reflects this. While most places will readily provide the latest tools that are requested by the team, it can be another matter when it comes to resources that are scarce. I lean towards environments where everyone gets their share of fresh air, natural light, and room to flourish, regardless of rank. Interestingly, one thing that I have found is that workplaces that allow people to bring their dogs are naturally more open environments. There are several clients that do so (including the one I'm describing here), and all of them would be near the top of my list in this category.

Once we actually get moving on the engagement, the quality of work they are doing becomes apparent. We're not talking the difference between playing with some cool disruptive technology and writing reports for a standard application. It's more the novelty of new functionality over fixing stuff that was only half-done to begin with, it's the fun of creative design over the drudgery of tinkering with the code until it seems to work. Nothing is mundane if you attack it with the attitude of doing the best job you can, and you will get the added benefit of being able to spend more of your time on the new and novel work.

Finally, one of the critical behaviors I look for is a hunger for ongoing learning. Some shops seem to force their people to take training that they don’t seem interested in. The excuses to leave the session come early, and those that are stuck can often be found surreptitiously keying their Blackberries. It is far more fun to work with a group that is engaged in the learning, actively listening and challenging me throughout the session, hungry for more.

Indeed, with this group, they have settled on a very practical collaborative development approach. While very heavily based on Scrum, they also respect the value of deep analysis for their products, and will sometimes invest in formal inspections for core components. They understand that there are times to go fast, and times to slow down in the name of quality. Every time I work with them I am energized, their senior management is actively engaged, and it is more like a shared exploration through the day's topic than a lecture. Indeed, during a break I had a chat with someone that had just started that week. He saw the same things I did, and was very happy with his choice. Perhaps most revealing, he was actively engaged with everyone else in the room during the day – he already seemed to belong.

In working with the founders of this company several years ago, I know that all of these issues were conscious decisions and directions on their part. They have been successful in building a company that supports the people working there, and everyone benefits: the team, their clients, even the consultants that come in to engage them from time to time. - JB [top]

Industry Evolution (Compendium 6.41)

I spent a few days last week down in Portland, at the Pacific Northwest Software Quality Conference. It’s a local conference run by a group of volunteers, but you wouldn’t know that by looking at it. The conference is well attended, drawing many people from the West Coast and worldwide, there are a number of significant local companies (Intel, ADP, HP in Corvallis, among others) that continue to promote it, and it draws many of the A-list speakers.

One of the key points for me is that the presentations are peer reviewed before being accepted into the conference, rather than being selected based on a pitch of 150 words or less. Overall, the PNSQC is a strong conference to attend, certainly when you consider the alternatives up here in this neck of the woods.

This year was their 25th anniversary, and the theme of the conference was ‘25 Years of Quality: Building for a Better Future’. During lunch on the final day, there was a panel session revolving around the state of the industry today and where it is headed for the future. The panel and the audience all provided a wide variety of perspectives: a host of accomplishments, counter pointed by a number of persisting gaps. Evolving methodologies, women in IT, apparent neglect of requirements and design and outsourcing issues were all raised and discussed. As expected, lots of interesting points, but few drawn conclusions.

What stood out for me was that testing was the predominant theme of the entire conference. Three of the four invited speakers, easily more than half of all the track presentations, and a show of hands at the panel session indicated that testers were in the majority at the conference. Indeed, it was an afterthought for the MC to ask if there were any developers in the room. This seemed to be the case last year as well: even though it is not a test-centric conference by title (unlike STAR East and West, or the PSQT series), the emphasis seems to be on dealing with issues we have injected into the systems we build.

Not that there is anything wrong with excelling in the area of test, of course. Indeed, the industry as a whole seems to be at a point where emphasis on testing as the primary driver for quality is at its peak. Test certifications are pervasive, almost every company’s QA group spends most of its time in test-related activities, and the advances by the thought leaders in this area have been stellar. Michael Bolton, Cem Kaner, Rex Black, Jon and James Bach, and a host of others have raised the status of software testing beyond something we get the newbies to do (because it is less interesting or it keeps them out of harm’s way) to a level where the techniques and practices constitute an advanced discipline unto itself. Testing has come of age.

What does this say for the overall evolution of software development, though?

For me, it says we still have a long way to go. We have evolved from the early days where we solves simple problems with cumbersome languages to the point where large teams can solve very complex problems, but the stats show that as projects grow in size, we are more miss than hit. We continue to argue about the relative merits of one approach over another, rather than recognizing that the conscious selection of a reasonable approach is a decision still neglected on most projects today. We continue to build more sophisticated frameworks, more expressive languages, and tackle more complex problems, but our emphasis on quality remains on the end game: effective approaches at finding and eliminating the defects we have injected into the system, rather than working in a way that ensures we’re on the right track to begin with.

Software testing has risen in prominence because we continue to rely on it for cleaning up the problems that we have injected along the way. While overall we may have made some progress in the delivery of value to the end user, this seems to be a small incremental step which is still fraught with risk, rather than a massive breakthrough that can revolutionize the industry.

[Possible stepping on toes ahead...] There was a lot of ‘agile namedropping’ at the PNSQC again this year (last year, Agile was the only track that participants wanted to see less of at this year’s PNSQC). Along with the standard marginalization of waterfall as an evil way of developing software, there were a number of instances where one agile pundit claimed their approach was more effective than other ‘agile approaches’. Several people claimed their preferred practices were ‘true agile’, whatever that means. All this posturing and dogma diverts our attention from the real issues. While iteration and customer focus and continuous integration all add value (and all did so long before that marketing campaign started in Utah in February of 2001), we are still relying on testing, ever-so increasingly sophisticated testing, to ensure we have a quality system.

We have shortened overall schedules by pushing to implementation faster, even though stats suggest that half or more of our defects have their basis in requirements. As we dive into code faster, there is a good chance that this number increases, as an unspecified requirement is just as much a defect as one that is specified incorrectly. Our push for agility, in many cases, has forced us to become more effective at testing our systems to usefulness. We have indeed reduced some of the early stage waste associated with less agile approaches, but have we thrown away the baby with the bathwater by diverting our efforts to more testing at the end rather than exhaustive specification up front? The answers are not as black and white as many pundits would suggest.

For all but the simplest of implementations, I think we continue to have a great deal of latent waste and uncertainty in our projects to recover, regardless of the implementation approach we choose. We need to better understand how to collaborate so that we make the right decisions when it is appropriate. The real optimizations are to be had by working in a way that prevents the injection of defects to be found later, or at least building in mechanisms that capture the defects as soon as possible after they are injected. We need to involve all stakeholders, every step of the way, using approaches for collaboration that are natural for everyone. The techniques for doing so are available, but rarely applied on software projects.

What I saw as a seminal presentation from the conference was by Ward Cunningham (interestingly, the conference used a new rating scheme with red, green and yellow cards that allowed people to see how others rated the speaker – by audience feedback, Ward didn’t seem to do so well). He presented a system they are using as a framework for automating many of the manual workflows for the Eclipse Foundation. From one perspective, it could be perceived simply as xUnit on steroids. Most importantly, though, it was a system that allowed the developers, the testers, and the end users to all work in conjunction as the system evolved, viewing it from different perspectives. It was a system that supported ongoing conversations between the groups. Everyone worked from the viewpoint that they were the most comfortable with. While it may have started as a test infrastructure, it supported all stakeholders, and drew them in.

Ward didn’t name drop a family of practices, or suggest that his approach was the way to go (which may explain his audience ratings). Indeed, his humility that what they had built was still not completely validated was refreshing. What he presented, and what I saw, was that they had developed a system that allowed all stakeholders to effectively collaborate in the ongoing evolution of their product. It worked in their instance, but was not manna from heaven.

As an industry, we still emphasize quality as reactive control rather than proactive assurance. There remains plenty of room for refinement in how we develop software today. We need to step back from the infighting about pet practices, and learn to do as Ward demonstrated at the conference. We need to manage effective conversations to solve problems. - JB [top]

Repairing the Fixed Price Model (Compendium 6.39)

I’ve been working with a colleague recently, and it has been interesting to see how his company can work with clients to build software applications under the fixed price model. While it is generally the case that outsourcing is quoted on an hourly basis (because of what is seen as inherent risks in the software industry), this group is one of the few that can make a fixed price work.

In most cases, whether software development is being outsourced or developed in-house, there is so much uncertainty in how the project will play out that it is impossible to state up front just how much time it will take to build the application, or how much it will cost. We tend to try to work to constraints and recalibrate as we go, but statistics such as the Chaos Report have consistently shown over the years that many projects are either disappointing or outright failures. Because of the uncertainty up front, there is just too much risk to bid on projects using the fixed price model, unless you expect to either a) use this as a loss leader, or b) expect to rigorously manage change and make your money by billing for these changes.

Either way, someone will usually lose in the transaction.

From the client perspective, to go with an outsourcing group on an hourly basis has shown to provide limited value. The client still retains the risk associated with the unknowns around the project – as the surprises arrive, they are usually still on the hook to pay for them. As is often the case, management of scope is done relatively weakly (as with the software industry in general), but there is an added layer of communication that makes the effort even more difficult to wrangle. Often, that additional effort more than consumes any cost saving that the client might have expected by selecting a vendor with a low hourly rate. While astute clients can leverage outsourcing to balance workload fluctuations for their IT department, most don’t find a cost savings or risk reduction in doing so.

This group seems to have found the right answer to the outsourcing dilemma – they can effectively deliver on fixed price, and in doing so provide the client a dramatic reduction in risk. The trick is to drive effective collaboration with the client, and through deep analysis, significantly reduce the uncertainty associated with implementing the system.

The approach makes a lot of sense. In a couple of very focused sessions, sit down and truly understand the needs of the client. From this, deeply model the problem and solution space, to the point where much of the risk has been mitigated. They are able to nail down the vision and scope of the system at the business level (indeed, this becomes the basis for the fixed price contract), and develop the initial requirements for the system to be built from. This allows both a straightforward implementation and the unique ability to precisely price this implementation for the client.

They recognize that the detailed requirements still have some volatility (though much less than usual, as they have established a clear vision to work from), so rather than ‘signing off’ the spec, they recognize that the the detailed requirements and system design are living (yes, an actual case of a ‘living document’ in action). They use this as the basis for ongoing discussion and clarification with the client throughout the project, and this ongoing collaboration allows them to closely manage expectations throughout.

There are two key differentiators here:

This group has extremely strong analysis skills. They bring to the table a wide variety of different modeling techniques (they’re not hung up on any single technique), and recognize that these techniques are merely tools for channeling collaboration with the client to gather the appropriate information. They go far more deeply that to merely ask "what do you want".
They are great listeners. They recognize that it is the client that best understands the domain and problem space, and their role is to elicit this information as thoroughly and efficiently as possible. They know better than to suggest "this is what you need".

In speaking with the customer, we get feedback that is almost unprecedented in the field. The CFO of one company clearly recognizes the reduction of risk associated with this analysis-driven model, and is at the point where what started as an amicable relationship has become a strong enduring bond. There is no adversarial negotiation of changes along the way, just delivery of value as expected. Indeed, when asked what the biggest surprise in the engagement has been, it was that "there were no surprises at all".

The end-user that was involved with the initial modeling sessions had an equally glowing viewpoint. For the first time, she felt that the analysts were actually listening to her, rather than trying to tell her what she needed for her own domain. Unlike previous attempts where even internal IT managers failed to deliver on expectations, she is looking forward to using the system, both for the additional features it provides for her, as well as for all the other stakeholders involved. She has become a true advocate for seeing the the system deployed.

The solution is relatively simple in principle, but rarely practiced in the industry. With well-focused customer-centric analysis up front, they can provide dramatic value to the client while turning a profit. No reliance on heroes, no death marches, just disciplined, predictable software development.

Oh, and profitable repeat business, as well. - JB [top]

Planning Cycles, Thinking Rhythms (Compendium 6.28)

I was running a training session with about a dozen executives a couple of months back. These were all people from relatively small companies, so even though by title and role they may face strategic issues most of the day, they still have at least one foot firmly planted in day-to-day issues, and many of them remain more comfortable in a technical environment than a boardroom.

During the opening of the session, as everyone was introducing themselves to the group, I noticed that two people there had a copy of the same book, and another in the group had mentioned something about the book as well. Apparently, a number of them had recently attended another seminar, where the contents of the book were presented. The book was Mastering the Rockerfeller Habits, by Verne Harnish.

The course we were running was a series of workshops on small business success, covering a range of topics from setting up a financial infrastructure to leveraging the range of available Government assistance, do planning and driving successful projects to realize your vision. A key part of the workshops was the one on one sessions we ran with the executives, to take the classroom materials and more directly apply it to each specific scenario.

In one of the sessions, a copy of the Rockefeller Habits was sitting on the desk beside us, and I inquired about it. The person I was working with indicated that this was actually a second copy he had, and offered that I could borrow it for a while.

It turned out to be a quick and engaging read. In essence, the book describes a relatively straightforward system for strategic planning, and is embodied in a 1-page Strategic Plan.

I have seen many different variations on this theme for strategic planning, from Word Documents to PowerPoint decks, and they have a lot in common. There is always discussion of the competition and financial targets, often accompanied by a miraculous hockey-stick growth two or three years out, usually without a sound story explaining how this growth will occur. They often paint a very rosy picture of the future, but provide little support for how to actually get there.

The distinction I see in the Rockerfeller Habits is quite compelling. The structure of the brief strategic plan acknowledges that we need to consider a wide range of planning cycles from the strategic vision down to what we want to get done this week, and we need to synchronize them. They all need to fit together concentrically, like so many Russian Matryoshka dolls. Strategically, they start with Core Values and Beliefs, and wind down through a set of Quarterly actions and themes that we can implement as a means of working toward our goals and achieving our visions. Getting any more detailed than quarterly issues in the context of strategic planning doesn’t make much sense, so it is appropriate that it stops there. It would be impossible to provide a generic structure for daily operations across a wide range of domains, anyways. Layered on top of his system is a metrics model that sets specific expectations, and is based on historical performance. Nice.

This is a wonderful complement to the concentric planning cycles that are discussed in the agile community these days. Whether the straightforward representation from Scrum of the 30 day sprints and daily scrums or the more involved eight concentric cycles shown in Extreme Programming, the idea is the same. More Matryoshka dolls, in a very detailed sense. These cycles fit very nicely inside those of the Strategic Plan above, and indeed, many agile implementations I have seen would benefit from extending the metaphor upward.

We need to recognize the value of planning and behaving in the context of this range of perspectives. Knowing our overall strategic objectives and being able to map them down in a planning exercise is a very powerful way of achieving our goals. When we are explicit about identifying each of these perspectives, we can ensure they are aligned, improving our chances for success. With all of the steps captured, we have an approach that is a basis for discussion and debate, and we can identify not only what our big fat audacious goals are, but what steps we are going to take to get there. We consciously remove the ‘and then a miracle happens’ steps in our business plans.

In our day-to-day activities, we need to ensure that we take the time to focus at each of these different levels of planning, that we recognize the different thinking rhythms that are needed to achieve the long-terms. This is not to say that each of us splits our day across the different levels, but someone in the organization has to take charge for each level, to ensure that it is clear and well communicated, and that it meshes with the levels below and above it. At the highest level, senior management will drive the overall direction, while at the lowest level (especially if we extend the metaphor down to the daily level) we all as individuals need to ensure that what we are doing contributes to this overall direction.

Any gap in the spectrum of these thinking rhythms can lead to problems. Where are the gaps in your organization? - JB [top]

Unintentionally Non-Profit (Compendium 6.23)

I have been recently exploring different ways of contributing to the community where I live, and there have been a couple of times where I have had discussions with people involved in non-profit organizations.

Thus far, I have learned that the people involved in non-profits are passionate about what they do, really want to make a difference, and don’t mind discussing their hopes and fears about what drives them. Their vision is not centered on the almighty dollar, but on genuinely solving people’s problems.

It also appears that most non-profits are also struggling to make ends meet. Being cash-strapped, they are unable to do everything they would like to be able to do. Theirs is generally an exhausting cause, and long hours or a frustrating lack of resources often leads to burnout amongst the support staff. There is no certainty that the funding they do get will continue, and there is always the danger that their project can be shut down at a moment’s notice.

As a larger community of non-profits, there are the additional challenges of competing for the little money to go around, and for the people willing to contribute their time to the various causes. With a competitive viewpoint rather than working together for the greater good, their efforts are often at odds with one another, further contributing to the frustration and burnout.

Except for these groups being consciously and intentionally non-profit, this sounds a lot like the situation in startup software organizations, that are often unintentionally non-profit.

Both the positive and the negative. The passion for their activities, the intent to truly make a difference, and their zeal for spreading the word and solving real problems. Unfortunately, the long hours, frustration and burnout, lack of certainty and competition are part of the mix as well. Oh yeah, the lack of resources too, of course.

That lack of resources, both for non-profits and not-wildly-profitable, appears to be at the root of the problem.

Certainly in an organization flush with resources, it would be easy to allocate the funds or get the people to do all that strategic stuff that the big businesses seem to do so well (or indeed, sometimes seem to do to excess). Separate groups with the required expertise to drive operations, sales and marketing, finances, and all the other divisions that are headed by a CxO of some kind. They are staffed with people trained in their areas, and work to contribute their share to the overall organization’s goals.

Without the resources to build up a huge infrastructure, though, the perception is that every dollar available needs to be put to good use, and that is generally seen as doing the real task at hand. Fingers to keyboards in a small software shop, people helping those in need in a community-based non-profit.

Given the goals and the passion, this is admirable, to be sure. I would bet, though, that most of these groups would dramatically benefit from a little more strategic thinking.

In the non-profit world, there are a large number of organizations, all working to address their vision of how to change the world. These are often different perspectives of a larger overall issue, and there will be times when cleaning up one symptom will make other symptoms more pronounced. With everyone heads-down, there will naturally be collisions and frustration. If we were to step back and understand the overall landscape, both the greater issues to be resolved and all the stakeholders at the table, I would expect that the coordination could improve results dramatically.

Higher level thinking would be valuable for small software startups as well. Success requires far more than a technical idea to be realized, and quite early there needs to be an understanding of how their product plays in the overall landscape of the business world. For some groups, this understanding will suggest that it would make sense to stop now, as there is no foreseeable business benefit for what they are doing (even if it is a great technical idea). For others, insight might suggest there is value in investing heavily to speed the time to market, to take advantage before the window of opportunity closes.

In both cases, it is usually safe to say that objective insight into current operations, regardless of the soundness of the vision, will reveal opportunities to improve efficiencies.

From day one, whether you are building the next big technology solution or working under the non-profit model to make the world a better place, there is tremendous value in acting and behaving like a real business. Start with a clear vision. Obtain a deep understanding of all your stakeholders, their needs and attitudes toward your goals. Build clarity around how you intend to realistically achieve your goals, and an understanding of where you need to shore up your capabilities with support. Maintain an ongoing focus on ensuring that your resources are being used as efficiently as possible.

For non-profits, this can reduce frustration and burnout, and may lead to more synergy with some of your peer organizations. For unintentionally non-profit technology startups, this can mean survival. - JB [top]

No Problem! (Compendium 6.20)

While rare, there have been times that I have run into businesses that consciously chose to turn a blind eye to what was clearly dysfunctional practice. In both cases, this blind eye was accompanied by a rationalization that allowed them to justify this behaviour.

Amazing!

The first instance was a number of years ago. I was facilitating a retrospective with a local company, one that had made great strides in recent years to improve their approach to developing software. They were doing a much better job at nailing their schedules, getting the functionality they wanted out into the field, and at the same time improving the quality of that delivered product. Recognizing there is always room for improvement, they wanted to incorporate more substantial retrospectives into their practices.

We were discussing the overall project measures, comparing estimates and expectations against actual performance and how well they managed to meet their goals. As many groups do, towards the end of the project schedule, this group used the number and severity of outstanding defects as one perspective to consider whether the product is ready to ship. There was a clear correlation between the defect count dropping and the decision to release the product. So far, so good.

As I do regularly, though, I solicited input from everyone in the group, anonymously, in advance of the session. While this usually generates some interesting points, this one produced an absolute gem. It turns out that this group had found a novel way of driving their defect count down: a short time before the calendar indicated that it was time to ship, they stopped looking for new defects!

Heck! Anyone can ship with a low defect count with that strategy...

The second instance was more recent, in discussions with a senior executive from a consulting software development shop. We were talking about the issue of rework, which is generally seen as something to be avoided in software development.

In this case, this person indicated that the group consciously decided to not be concerned with the amount of time they spent in rework. After all, with time and materials contracts, the customer was paying for all this time.

Tactically, this might seem to make a great deal of sense. After all, you wouldn’t want to ‘leave money on the table’, would you?

Thinking about it, though, there are elements of this approach that eclipse even the first example as dysfunctional. It’s common to not be aware of time spent in rework, and to bill the client for all that time – I would expect that is the practice of most consulting shops in the industry. Indeed, most software teams in general, whether consulting or in IT or product development, are blissfully unaware of the time they spend in rework.

It is an entirely different matter to be consciously incompetent, to be aware of dysfunction but to choose to do nothing about it. As a client of such a firm, I don’t think I’d be too impressed with that attitude, and this example will certainly make me think about my criteria for hiring such a firm in the future.

Beyond that, though, this organization is on the brink of harnessing a huge strategic advantage and choosing to not take that next step to make it a reality. If they were to actually manage their business through the measurement and reduction of rework, they would gain a variety of opportunities for differentiating themselves from their competition.

With a solid handle on getting things done right the first time, they could be more comfortable with fixed price contracts, or they could bid the same time and materials projects and provide greater client value than before. In addition, through conscious reduction of rework, their product quality would go up, essentially for free. My guess is that this differentiation would tend to make more clients stick with them for future work as well.

So close to all these advantages, they opted for the cash that was on the table.

Almost in the same breath, this executive indicated that their competitive advantage was their people. The question is, how would their people enjoy working in a more efficient environment, with less chaos and happier clients?

To be aware of dysfunction, and to use that dysfunction as a way of artificially boosting your numbers or meeting your goals, is a very short-sighted way of getting ahead. Better to use that knowledge for greater strategic advantage. - JB [top]

Zero-Sum Lunacy (Compendium 6.16)

It has been fashionable for quite a while in business circles to study competitive philosophy. Whether from the ancients such as Sun-Tsu’s The Art of War (I know my wife and I each had a copy before we met each other), Machiavelli’s The Prince, any of the hundreds of variations of these that are available, or some other source of military doctrine. There are all sorts of interpretations and translations to choose from, and I expect the niche will remain healthy in the future.

I’ve read my share of these books, and indeed found them fascinating and insightful. It’s pretty clear to me that those involved in warfare are best served by studying the insights of those that were successful in the past, and the strategies and tactics provided offer a wealth of information. I’d be surprised if there was a military power today that did not have these books on their required reading list.

Military strategy is one thing, but I have problems with books of this nature being considered important reading in a business setting.

Donald Trump recommends The Art of War, for what it is worth...

In military strategy, one of the basic premises is that you are in the game to win. That’s fine, I think the same is reasonable in business as well. The distinction I make between the two is that for one side to win in a war, there will be another side, the enemy, that loses. The overall result is zero-sum (or actually sub-zero, in most war situations).

While many business people tend to think in this manner, I disagree. If we think zero-sum for business, we are missing the point.

If business is indeed a zero-sum environment, who is the enemy? There are a number of possibilities, none of which are really that palatable.

Are other businesses in the sector the enemy? Here we are thinking about ‘the competition’, the ones we want to take market share from, the ones we are upset with when they beat us out to win the client. While this might be the case when the ‘winnable goods’ are limited, in many sectors (for both goods and services) there is a largely untapped market to draw from. There’s plenty of fish in the sea for everyone, and quite often collaborating to enlighten and expand the markets is in everyone’s best interest.

What about organizations that tout a particular technique or product for their market? The tendency here is to brand themselves as distinct and better from the competition, but these broad, sweeping strokes are dangerous. My daughter is at the stage these days where she constantly asks questions like "what’s the best car?", or "what’s your favourite colour?". My answer is always "that depends on the criteria." As noted before, it’s tough to say your product is the best when you don’t understand the buyer’s needs.

In both these situations there is an external ‘enemy’ that takes the form of other businesses, and there is danger that the other guys will end up the winner.

We can take the competitive issues out of the situation, though, and there is still danger in playing the zero-sum game.

I have seen a number of businesses that treat the client as the enemy, even though it is not explicitly stated. These are the companies that are focused on short-term financial gain, and can often be seen overstating their capabilities or under delivering on their promises. The snake-oil salesmen. Just as in the old stories of these shysters, they are always busy reinventing their product space, trying to maintain their attraction with the latest and greatest craze. Unfortunately, this also means they must constantly work to gain new business from a diminishing supply of potential clients.

Even without thinking of clients, a zero-sum game can be played within an organization. Management will often treat employees as expendable items, attempting to drive the team to completion in a death march. The short-term gain, if any, is illusory. Apparently early wins will often give way to schedule delays, unmanageable product defects, and poor morale and high turnover.

In every case above, thinking of anyone you deal with in a business environment as the enemy (whether you use those terms or you simply behave that way) ends up looking a lot like war. While there may be tactical victories, it is pretty rare that there ever becomes a clear winner.

It is far better to seek out synergies with everyone involved, and in most situations it is easy for everyone to gain more value out of the transaction than what they see as the cost of their contribution. Everyone can win. - JB [top]

Labour Shortage, or Underfostered Talent? (Compendium 6.13)

In what seems to be a vicious cycle, the local tech community is currently expressing a dramatic need for more talent. There is a huge number of job postings that remain unfilled, and upswing in placement activity for the local recruiting community. At a personal level, far more people are asking me if I know someone that can fill a role, rather than asking if I know anyone that might need their services.

This situation seems to alternate with the times where organizations feel they are cash-strapped. Combining the two, the number one concern that I have seen from the tech community for as long as I can recall is this overall resource constraint.

Let’s look at this issue a little more closely, though. In particular, how this resource constraint manifests itself as a labour shortage.

An expressed shortage is really an imbalance between supply and demand. There is more stuff that companies would like to do than there are resources to get the work done. To remedy the imbalance, we can increase the supply or decrease the demand, but to decrease the demand doesn’t seem like a reasonable approach, so we need to focus on supply.

I would expect we’re all in violent agreement so far.

With supply being the limiting factor, we need to recognize that this can be broken down to be a function of quantity and quality: the number of resources available (or in other times, the amount of capital available), combined with the efficiency of output for these resources.

The emphasis for remedying the situation is perpetually on increasing the quantity, so let’s explore this (admittedly, some of the elements discussed here are based on the local economic situation, but I believe most of the arguments are generally applicable).

It has been suggested that there is a need to increase the labour force in BC in this sector significantly in the coming years to meet a growing demand. I see a few potential sources for this: the post-secondary system to produce new graduates, or importing new talent from outside the geographic region (retaining existing talent reduces the need to import additional talent).

Currently, the post-secondary institutions are challenged to even fill available seats in their technology programs. At the post-graduate level, many of the seats are filled with non-resident students, many of which take take their talents elsewhere soon after graduation. Even if the institutions were to magically fill their programs, there would be a multi-year delay before new graduates hit the workforce. This does nothing to improve the current picture.

Layer on top of that the challenges of finding the top talent from the graduating classes and the limitations of the educational system in producing seasoned talent, and this doesn’t appear to be a reasonable short-term remedy at all.

So let’s look at the potential for attracting talent from outside the region to come to BC to work in the tech community. Historically, the story has been "come to BC, it is beautiful here", with the hopes that the natural resources will distract you from the realities of the High Technology workplace.

I’ve already ranted in the past about the draconian labour standards we have in this province. In BC, high technology is the only sector where the labour codes have explicit exceptions that erode the rights of the employee. From what I have seen, this is the only province in the country where these exceptions are in place, and indeed the only exceptions nationwide in any sector that serve to erode the rights of the individual.

I know at least 2 ‘anchor’ companies in town where it is an unwritten practice (unwritten for good reason) to pay less than the industry standard. Consultants recognize they need to head South or East to make real money, and the industry acknowledges that the region generally pays less than neighboring geographic areas.

Companies here are frustrated that they can’t get good, cheap resources, that will work under labour conditions that are among the worst in the nation. Add to this the soaring housing prices over the past few years, and the attractions to move to the region from elsewhere are diminishing.

So we can’t depend on an influx of talent from the schools, and we’ve actively set up an infrastructure that is not attractive for importing talent. We have done nothing to improve the outlook of the situation yet - maybe we should consider the quality drivers, rather than the quantity drivers of supply.

In over 15 years of working for and with a wide range of companies in the province and worldwide, it has become quite clear to me that there are always opportunities for improving internal practices, in every team. The current cries for more supply hover around the 15% mark from the industry, while I would suggest that the strong software teams are only running at perhaps 70% efficiency, and most organizations are far less efficient than that.

However the inefficiencies are manifested, the bottom line is that software teams are not making good use of the resources they have (both in terms and people or money). For most, an internal efficiency improvement that is more than the current perceived labour shortage of 15% is quite easy to obtain. Done internally, this also eliminates the cost of recruitment, the risk of bringing additional resources on to the team, and the additional overhead of managing a larger pool.

Internal improvements also bring about secondary value such as increased quality or reduced risk and uncertainty, which is not the case when we address the supply problem by increasing the size of the team.

In a session this week where this topic was discussed, someone raised the famous JFK quote "Ask not what your country can do for you, ask what you can do for your country." Very appropriate, but for reasons quite different than those expressed in the session.

We continue to see the supply problem as a labour (or money) shortage, which is expressing the problem in terms that force us to rely on external resources to solve our problems. The same problem can just as readily be seen as a failure to adequately foster our existing talent. In doing so, we are one step closer to understanding that we have an opportunity to resolve our own problems, despite the environmental conditions that are working against us. For companies that think strategically, this is a massive opportunity to tap into, with no dependency on industry pundits, the government, or the education system.

The supply vs. demand problem we are experiencing is an indicator of a robust economy in the sector, which is great. Overall, the industry has dramatic goals to resolve the problem, but these goals appear to be based on underlying perspectives that make these goals less attainable. We are asking how to make our half-empty glass more full, rather than asking how we can foster our existing talent to make our half-full glass more productive.

Especially in the current geopolitical environment, the latter approach is far easier to achieve. There is no labour shortage here. There is a talent underutilization that is within our grasp to do something about. - JB [top]

Cultivation (Compendium 6.8)

A common business adage these days is that “if you don’t move forward, you will fall backwards”. This is reasonable, in a sense. There is a good chance that in a competitive environment, maintaining the status quo internally will give others an opportunity to make advances and leave you in the dust. In effect, you indeed fall backwards.

I have a problem with this, though, in that it implies that our approach should be to aggressively stay ahead of the competition in order to survive.

The competition. The other guys. The focus is often in the context of someone else. How do we make our products better than theirs? How do we ensure we have all the cool features that they have? Too many companies see this as the approach to success. Period.

Layer on top of this the obsessive devotion to doing things in a particular manner with dogmatically defined processes, and we get an environment where we are always focused externally for growth, and stagnating internally.

This consumerism culture mimics society in many ways, which is probably one of the reasons that it is so entrenched. Given that most fall into this trap, companies aren’t seen to be penalized for adopting this approach. People are treated as a disposable resource with this externally-focused viewpoint: as people leave, we can simply hire in new ones. It’s the cost of doing business, some would say.

These costs, though, are rarely quantified, and when they are, the magnitude is usually limited to the cost of recruiting, hiring and training. Rarely taken into account are the opportunity costs of the creativity that has departed, and the additional burden to the rest of the team. It is usually the most marketable people that depart on their own accord, but approaches to "cutting out the deadwood" also exact a toll on the team.

Philosophically, many shops treat their people the same way as office plants. You know, the ones that seem to be on the brink of extinction before they get watered. There may be a specific initiative to rally the troops once in a while, usually done after a disappointing quarter or the completion of a particularly challenged project. Take the team out for a paintball excursion, throw a lavish party, then drop them into another situation that looks eerily like the last one.

I think this philosophy is all backwards, and presents an opportunity to compete by differentiating from the crowds.

What every organization has as a largely untapped resource is the internal talent of the team. We want to consciously cultivate this renewable resource, much as we would a garden. There are a series of steps that we would need to take, in order, to successfully cultivate our team:

We need to be mindful of the attitude we bring to the game. Without a spirit of inclusiveness, without an appreciation that business success is not a zero-sum game where someone has to lose, we will get no further. The only way to thrive in this environment is to focus on the success of all participants. This attitude itself is counter to the way that many ‘leaders’ have managed to ‘succeed’ in business, but there are far more that have tried and failed with a zero-sum approach.
We need to appreciate the distinctions between the people we work with. This diversity in experience and motivations is the strength that we need to harness for innovation and success, rather than repress through cookie-cutter hiring approaches. Hire for attitude, train for skills, grow for broad perspectives. Explore and foster these perspectives, this is where novel ideas are born.
We need to respect the systems we use to coordinate our teams. We certainly need a system to ensure that everyone is working to the same objectives, but this system must be centered on the level of principles, rather than practices. To specify a set of practices to be followed before knowing what we are going to build will effectively handcuff the team, preventing them from flexibly using the right approaches for the task at hand. Focusing on the principles of a shared vision, thorough analysis and rigorous validation of the work products will give you a framework for success regardless of the tasks.
We need to understand our stakeholders that we are working to provide value for. Once we have built a machine that can generate product, we need to be ruthlessly focused on understanding how we are adding value to our stakeholders. We also need to appreciate that stakeholders include more than the consumer of our product, but everyone who is involved in the construction of the product as well. If our team is consumed in the process of building a product, we have not succeeded.

Done in this order, we have a sustainable approach that only gets stronger with time. Skip any step, and the cultivation will fail. With proper focus, the business will thrive as a natural consequence of building an effective and motivated team.

We can easily name a few great successful companies that focus explicitly on their people. This is an indication that there remains a great deal of opportunity to use this as a strong differentiator, but it requires a significant mental shift. Winning at the expense of others, whether the external competition or our internal team, is a frail success.

We need to continuously cultivate an environment for growth and innovation. If we neglect it, it will decay. - JB [top]

How Do I Know? (Compendium 5.52)

We are all consumers of software in our daily lives. While we may not even be aware of the software that runs in our refrigerators, there is a greater awareness of the software behind the keyboards that we use, the cel phones plastered to our ears, and the systems we use to drive our businesses. For those of us that are in the software community, the ubiquitous nature of software is apparent. For those that are strictly consumers, software can be interesting, mysterious, or downright frightening.

There are more and more people that rely on software, but are ill-equipped to make reasonable decisions about the goodness of the software. They may be consumers looking for a new accounting package, they may be running companies whose products now contain a greater component of software or firmware than ever before. For those that need to acquire software or to have software built for them, either by their own internal team or from some outside organization, how do they know that they are working with a good developer or group or organization? How can they know that the software they receive at the end of the day will do what they want it to do?

In many ways, building a relationship with a software team is similar to the relationship we build with our doctors or auto mechanics. For many of us, cars have evolved to a point where the mysteries under the hood have become as complex and foreign to us as the mysteries of the human body. When we surrender our cars or bodies for service, either preventive maintenance or more invasive intervention, we have to place our trust in the hands of the mechanic or doctor. We have expectations that they know what they are doing, that they are working in our best interests, and that we will be better off at the end of the day.

Unfortunately, this is not always the case. There will always be doctors ready to write a prescription for whatever we ask for, then shuffle us on so they can get their next patient through. There will always be auto mechanics that will tell us our engine needs to be rebuilt when all that is needed is an oil change. In a similar vein, there are software practitioners and consultants and organizations (oh my!) that are incented more by their income than the value they provide to the client. Unscrupulousness and incompetence spans industries, but we still need to select.

There are a few things to look for before we choose to engage. When discussing the challenges you would like them to help you solve, are they effectively listening to you? Are they taking the time to truly understand your situation, your needs and concerns before proposing a solution?

Are they willing to describe their approach so that you are comfortable with what you will be getting? Are there acceptable checks and balances along the way so that there is some assurance that you can reasonably track progress towards your goals? Remember, these are mechanisms that you can establish even before you discuss the detailed problem you are looking to solve.

When discussing their approach and your challenges, are they focused at the right level of abstraction? Are they concerned about value to you, or are they concerned about specific implementation details that, while they may be mechanisms that improve their productivity, are not a concern for for you?

It is critical to go beyond merely talking to the candidate before making a decision. Talk to others that have worked with them in the past, both those that have been happy with the results (that you would likely get as references), as well as those where things have not gone well (which would take a little digging). For those whose experiences have not been positive, what would they have done differently? Talk to multiple candidates, even to others where it is clear that the discussion is for information only – ask them what you should be looking for.

Work hard to find other opinions. Bringing in someone new is very risky. It is far safer to bring in support based on trusted third-party recommendations and referrals, safer yet to rely on someone that you have successfully worked with in the past.

Overall, do you feel comfortable with the prospect of working with them? Can you trust them? Do you click? If not, there are likely to be problems. If you aren’t comfortable with them, there will always be lingering doubt. If you can’t trust them to do their work, you will be an impediment to their progress. The relationship needs to work from both sides before you commit.

As you are working with them, there are other behaviors to look for. Do they continue to keep you attuned to the situation as it evolves, and ensure that you are still receiving the best value for your investment? Do they take the time to explain what is going on, or do they treat you like an idiot, with expectations that you will simply trust them? Do you have to continuously ask them what is going on?

What happens when things are not going smoothly? Are they skilled at deflecting ownership for the challenges on to others, or will they step up, take responsibility, and proactively work with you to resolve the problems as effectively as possible. Are they able to provide you with information that is useful, whether or not it is positive?

Finally, at some point you will receive the product of their efforts. Is it what you were looking for? Do things seem to be going smoothly up to the scheduled date, then all hell breaks loose? Are there a series of delays that occur, each new target missing specific information that would clarify why the delay is warranted?

You need to be comfortable with your choice, and a lot of that can be distilled to trust and ongoing open communication. It takes a lot of effort to build, and can be eroded in a second. At any point in time, something may happen that sours the whole relationship. Be prepared to disengage if this happens, and discuss this possibility in advance. Explicitly describe the sort of things that would warrant severing the ties, and be open to a set of clear responsibilities and rights from both perspectives.

Of course, all this needs to be balanced to the level of risk and exposure. Less diligence is warranted when you are simply purchasing a software package off the shelf, but far more is required when you are contracting for a custom software application or hiring into a key role in your team. For the latter, it is definitely worth the investment to ensure that you initially can communicate effectively, that you can work together with reasonable insight into progress and effective management of change, and that you can be assured you will get the product you want at the end of the day. - JB [top]

Inconspicuous Consumption (Compendium 5.49)

It was always interesting around the turn of this century to visit startup companies for the first time, primarily to witness each of their unique versions of unbridled spending. Aeron chairs for everyone, projection TV’s with game consoles and leather sofas to recline on, and beer fridges that were always stocked despite prodigious use. There was a gold rush in progress, and it seemed that the flow of money would never stop.

For a while, it didn’t stop. A few years later, the furniture delivery trucks that blocked the streets in the tech parks were replaced with trucks picking up the same expensive furniture. This time, though, it was for fire-sale auctions of assets for the same, now cash-strapped companies.

The era of conspicuous consumption was over, at least for the time being.

Many of those high roller companies no longer exist, at least partially due to their extravagances. The investors that bankrolled this excess have become far more timid, and far more conscious of how their money is spent. For the visible expenditures that they track, anyways.

There is a trickle of new game systems showing up, indicating that perhaps we are running back up the cycle of conspicuous consumption. It is still safe to say that this is not the greatest source of unnecessary costs in most shops, and probably never was. While being mindful to avoid creature comforts that might peak out at 5-10% of their costs, almost every company I have worked with has no idea how much money they are burning through inefficiencies.

Let’s throw the recent Sarbanes-Oxley legislation into the mix. Companies are starting to recognize that what was originally perceived as another burdensome cost can actually be a driver for getting their costs under control, for reducing their corporate risks, and making them far more competitive. So far, so good. Unfortunately, even with these increased demands of accounting practices, focus is generally constrained to tracking and accounting against traditional line items: specific projects and activities, and so on. There remains little visibility into the cost of inefficiency, and this needs to change.

One more element to throw into the mix. These days, I’m beginning to see many references to something that appears to return in a cycle of 7-10 years, the concerns about a skills shortage. In addition to the articles that are appearing on the topic more often, I am fielding far more requests for qualified resources than usual. Indeed, there is a shortage of resources, and far more demand than can be reasonably filled. Statistics 101 dictates that half of those precious few resources available will be below average. Not every organization can top up its resource pool with the 'best people available'. There is so much demand, in fact, that if this is the only avenue that companies pursue to address their needs, many will be left high and dry.

When I talk to groups about their cost of inefficiency, I get a range of responses from "we actually do pretty well here" to "we’re dying here with the waste and rework". Despite the range, all of these groups have two things in common. The first is that they don’t actually know what this cost of waste is. They don’t actually measure it, and usually don’t even have a common definition of what would fall into that ‘waste’ category. The second thing these companies all have in common is that they don’t recognize this waste as a massive opportunity that is entirely within their sphere of control. There is little being done to manage and reduce these inefficiencies, they are often seen as merely a by-product of running hard towards an ever-evolving goal, with an ever-changing team.

Do the math. Rework is one possible dimension to measure the inefficiencies in your organization. Studies have shown that for software companies, rework comes in at the 30-40% range. I’ve measured it to be close to double that in companies, and others in this line of work have similar horror stories. If you don’t know the numbers in your organization – that is, if rework has not been an area that is top-of-mind – there isn’t any reason to believe it is less than the 30-40% found in companies that know this is being measured. Let’s be optimistic and suggest you are running with 30% rework – dealing with stuff that you thought you had washed your hands of.

It would be naïve to suggest that with the wave of a hand you can eliminate this, but it is pretty clear from my experience that with a little consideration, especially when it is the first time you think this way, it should be relatively straightforward to chop this number in half. Not by adding resources, but by doing more of the good things you are currently doing, less of the things that are contributing to waste.

In this little thought experiment, we have gained 15% of our time back. If we annualize that, we would be looking at an Aeron chair and game console for everyone in the place, a cruise to Hawaii for the entire team over Christmas, and still have enough efficiency left over to get more product out the door. If your organization is really feeling pain, the math here only becomes more compelling.

We all look at the obvious extravagances in some companies and cry "what a waste", while unbeknownst to us our inconspicuous inefficiencies are far more wasteful!

As an industry, as we mature in our accounting practices we need to look at all the dimensions of consumption. If we do our job right, we can easily find greater value via legislated accounting requirements that will open up vast areas for improvement right under our noses, and eliminate the problem of having to go to the very tight open market for additional resources. We win on all measurable accounts, and the softer issues of morale will improve dramatically as well. - JB [top]

Home Handyman Syndrome (Compendium 5.46)

Most people that own a home have at least one project languishing somewhere around the house. We have a few window sills that remain unfinished from a renovation started 5 years ago, there’s that stained glass project that sat around for a couple of years before my wife recently finished it. This has now become a project on my list, as I have to frame it.

While these remain unfinished, there’s always pressure to start up new projects as well. We would like to reclaim part of our basement for organized storage (which will allow us to reorganize the office), and for some reason there is a need to repaint walls that look perfectly fine to me.

I have come to realize that there are a number of principles that tend to govern odd jobs around the house:

We have a tendency to underestimate the effort required for things that we don’t fully understand. How can it possibly consume more than a few minutes to fix that leaky faucet? That small plumbing job that we’ll tackle this weekend expands into the cleaning up of 2 significant messes and 5 additional trips to Home Depot, and expands to 3 separate weekends.
We tend to overestimate our capacity to extend our knowledge and skills into new, unrelated domains. I have a degree in Physics, landscaping should be a breeze, right? Closely tied to the first principle, we repeatedly fail to recognize that every specialization has evolved because of the magnitude of knowledge and experience required to do well in that field.
We tend to unrealistically constrain our work into arbitrary durations, with little appreciation of the effort required. The majority of jobs around the home are artificially constrained to an afternoon, or a weekend if they seem very large. Those that spill over often are the ones that languish for years.
We hope we will not run into unforeseen challenges, even though we can’t recall a home improvement project that has gone smoothly. We don’t recognize that it is our naïve rush into the unknown that actually creates some of the challenges that frustrate us. I still have a useless pair of needle-nosed pliers with a disintegrated tip from the time I tried to replace a live breaker.
We select projects based on our personal perceptions and motivations, rather than focusing on what is more appropriate in a broader sense. Given a choice between a backbreaking chore that might provide a great deal of benefit or a simple little fix that is actually relaxing, the law-of-preservation-of-the-back will usually win out. We lean heavily towards the easy, the low risk, the safe activities.

In a lot of software shops, there can be a tendency to drive work based on the same principles that drive household tasks.

Underestimation is a chronic issue in the industry, as we commit to single-point numbers (not estimates) based on a superficial understanding. Rather than appreciating the uncertainty associated with the unknown and working to reduce uncertainty, we blindly forge ahead based on commitments that have been hastily made. Our own experience will tell us that this is rarely successful.

Specialization in the software industry is unavoidable, it is rare to find a jack-of-all-trades that truly excels in multiple disciplines. What this means is that we should actively seek out reasonable expertise for the task at hand, rather than assuming we can simply muddle through the task. A plumber can finish off a couple of tasks in a few hours that have been languishing in the home for months; the same is true for the appropriate technician in the software field.

With little supporting information about the technical magnitude of the task ahead of us, we are often left to use targeting and promises as the primary driver of schedule on our projects. Granted, some projects do have genuine calendar dates that cannot be moved, but in all instances we need to understand the work on our plates and the time-based goals and constraints and appropriately balance the two. Technical people will often bemoan management or marketing for setting unrealistic dates, but the responsibility remains for us to have a stronger defense than to merely say "that’s not enough time".

Given often unrealistic time constraints (because we have not adequately made our counter-arguments), there is no time for contingency on our projects. This, along with the tendency for us to neglect to truly understand what went wrong on our previous projects, leads us into trouble. Our headlong rush into current projects often drives us to inappropriately cut the wrong corners, and we make costly mistakes. Without measuring the cost of our mistakes, it is easy to justify not doing the simple things that can make our lives safer, such as shutting down the mains before replacing a breaker, or getting a common vision for a project before we move forward.

Projects are often driven by someone’s pet interests, rather than understanding which initiatives are most appropriate for the business. This is easy to add; that is cool technology; I have one client that asked for this feature. We need to step back and understand the business value we are building, and the needs of the client we are addressing. If we can’t articulate both, it’s not a project worth pursuing.

It is understandable that odd jobs around the house are often run in a chaotic manner – few of us have clear education or reasonable experience in the area, and I don’t recall seeing a manual for proper care and maintenance when we bought our 50 year old home. We are learning through trial and error, with emphasis on both terms. That is no way to run a software business. - JB [top]

Lost in Translation (Compendium 5.43)

A couple of weeks ago, I was driving an online training session, with more than my fair share of challenges.

For those of you that have never run online training, from the instructor’s perspective it is a little like being the Wizard of Oz. Remember the scene where Dorothy and the others finally manage to get in to see the Wizard, and Toto pulls back the curtain to reveal someone frantically pushing buttons, swinging levers. "Never mind that man behind the curtain", the Wizard cries out. In order to make the experience engaging for the students, the instructor has to monitor a range of different indicators, advance slides and use pointers or reveals to show where we are, watch for people with their hands up, respond to private chats, and talk through the presentation. This is a simplification of the challenge, but you can probably see where I am coming from.

In this particular course, we had already made it past some hiccups regarding the start time and the version of the online environment we should be using, and were into the first session. I needed to know how many people were dialed into the phone bridge so that I could arrange break-outs for an upcoming exercise. I had a private chat window open with the support person for the training, and asked him "any way of determining how many people are on the phone line?"

The response: "yes u can do that."

Great! Here I am juggling more than a handful of students in the middle of the session, flipping levers and pushing buttons, and I am told that what I want to do is possible. Give me the phone sequence to press, or do it yourself and give me the answer, but don’t just tell me that it is possible! Looking back, the response was reasonable given a literal parsing of my question, but it certainly did not meet my expectations.

We made it through the session, but I decided to minimize my expectations on the technology and support and focus on delivering a reasonable experience to the group primarily through discussion. Less bells and whistles than the Great and Mighty Oz could conjure, but the important points were made.

The support for this company’s online training had recently been outsourced, and I was experience a great deal of pain.

In the book The World is Flat by Thomas L. Friedman, the author suggests that the convergence of technologies in the past decade have brought us to the point where anything can be done anywhere in the world. The lowering of trade and political barriers (can someone please tell this to US Immigration?) and the ‘digital revolution’ has given everyone the opportunity to be as connected as they wish. He highlights the influence of China and India on the global supply chain, and this is something that we are all seeing in the software domain. The author weaves a very compelling story, but I believe it is an oversimplification for the masses that is hurting us.

Apparently most of us that take our taxes to be done by a company like H&R Block actually have their taxes done in India. Often when we call for customer support, we expect someone to ask us questions from a script and walk through a flowchart based on our responses. More often than not, we can detect an accent, and there is a good chance that it is the wee hours of the morning where that person lives. For these well structured interactions, either carefully scripted like first level phone support or financially precise given the business rules of tax law, it only makes sense to do the work where it is most cost effective.

For the novelty of challenges associated with real-time event logistics, or even worse, the novel innovation and creation of a software product, the world is not so flat as we would be led to believe. Fluency in the English language is a long way from a shared understanding, and we need to go well beyond Berlitz to ensure that we are all on the same page. Cultural differences are very real and very significant.

In software development, where most organizations are very weak in building a reasonable requirements spec for internal use, confusion and misinterpretation and disagreements are the order of the day. How can we expect to take this same weak basis for a product and send it halfway around the world and expect success at 15% of the going rate? There have been too many instances of higher costs, lower quality and overall client dissatisfaction to turn a blind eye to the challenges.

I don’t know of a company that has succeeded with the offshore outsourcing model without a significant investment in management oversight, acclimatization to culture differences, and sensitivity to linguistic nuances. It is not simply a matter of passing the work out to the lowest bidder, and even ISO certification or high CMM maturity do nothing to address the real issues of globalization. The cost savings argument is weakening, and we need to recognize other areas of value if we are to reap the benefits of outsourcing, such as leveraging external expertise or managing demand fluctuations for our resources.

The world is flattening, to be sure, but we have to be careful to manage the speed bumps we are encountering along the way. - JB [top]

Out With the Old... (Compendium 5.32)

It’s been stated in many different forms that change is inevitable, and that change is resisted by all of us. We don’t have the time to learn new things, we can’t afford to do more things, we’ve tried that ‘change thing’ and it just didn’t work. It is easier to embrace the inertia of our current practices, dysfunctional or not. The devil we know drives the vast majority of our actions.

We need to see change as a double-edged sword. Indeed, we will need to learn new things and change old habits, and it is usually safe to say that we start out doing these new things relatively poorly. If we have never consciously designed a system, for example, our first designs will be fraught with problems. The learning curve can be a painful experience, but we learn best by doing.

Along with all this negativity, however, comes a silver lining. Assuming we have selected the appropriate changes, what we have is not an addition of things to do, but a displacement of activities. Literally, we need to make time for the new practices, as we cannot introduce more hours to our day. In some shops, the simple practice of spending less time at the office can have a net positive result. In all cases, it becomes an ‘out with the old’ approach to allow for ‘in with the new’.

The trick to change is to ensure we are optimizing the effectiveness of our practices, not merely adding more things to do. Diving straight into the code without thinking out the design and architecture (or even considering what the scope should really be) is highly inefficient, even if it may appear on the surface to be engaging. Placing appropriate focus on early stage efforts will not eliminate the need for developing code, but the activity will become a lot more efficient. You will find yourself able to focus on the implementation details rather than discovering the design on the fly.

The sad truth, though, is that many organizations have perfectly adequate defined practices and lifecycles, but never seem to be able to get a project out the door. When we think of change and process improvement, we normally think of changed practices, and the out with the old, in with the new strategy is certainly a critical component for success here. Unfortunately, a defined approach is insufficient. We need to consider change in other dimensions as well – the dimensions of behaviors and attitudes. From this perspective, we find another crucial, and often neglected, side of change.

In some cases, the ‘out with the old’ will end up applying to people as well as practices.

As practices are changed, or as existing practices are finally enforced, there will be a disruption to the comfort zone of the team members. Some will learn to adjust and recognize the value to themselves and to the team as a whole. Others will find that they are no longer comfortable. They may grouse about the changes, they may even consciously try to undermine the changes in order to regain their previous comfort zone. Eventually, if the changes stick and discomfort persists under the new approach, these people will often move on. Even if they were team leads or strong influencers within the group, if they cannot fit within the system that the team is working with, this move is probably best for all involved.

To have an agreed-upon approach is one thing, to follow it even when the pressure is on is quite another. There is a broad range of attitudes that people take when it comes to the application of best-practices, and this is an area that needs to be just as consciously defined and managed. For an approach to work, it needs to be consistently applied. There can be no opting-out for the sake of tactical convenience.

I’m not an advocate of cleaning house before giving people a chance to show reasonable attitudes, but I do advocate laying down the clear laws and sticking to them. There is no room in team-based software development for individual approaches that jeopardize the integrity of the overall system. Nobody should be immune to the check-out/check-in procedures, nobody should be exempt from peer reviews, nobody should be allowed to go dark. Period. If people consciously buck the system (as opposed to reasonably debating the merit of the system itself), their next task should be to find a new job.

This, like working fewer hours in a day, may be all that it takes for some organizations to dramatically improve their performance. Simply plugging the holes in the well-structured but leaky boat.

When we manage change, we need to consider the approach as well as the application, acceptance and evolution of the approach by the team in order to ensure success. - JB [top]

Games People Play (Compendium 5.26)

As we interact with others, we’re all playing a game, all the time, and the games that are played in the business world can be quite extreme.

Very few of the rules are explicit, the rules are often broken at surprising moments, and because of this it is rare that we are all playing to the same set of rules. At times the rules to the games may be called cultural norms, at times they are seen as standard business interaction, at times simply interpersonal relationships. If we step back and recognize that we are indeed always immersed in a game, if we consciously understand the rules that govern our actions as well as those of our peers, we have harnessed a very powerful tool.

I spent some time recently with a large group that, as with many large groups in this industry, demonstrates the game being played in a wide variety of situations and responses. A diverse group will always bring a number of different players to the table, and it can be fascinating to step back and watch the moves the players make. I’m sure this industry is no different than any other.

This particular group is dominated by what one could call a pack of alpha males. Very bright and competent, to be sure, but also very adept at working the system to help them achieve their goals. They have advanced within this system through leveraging influence, exhibiting behaviors that demonstrate their superiority, and at times maneuvering craftily through the political landscape. Sometimes, they even leverage their deep technical knowledge, but this is not their strong differentiating trait. They understand the game, play it well, and thrive in their environment. They play to win.

There are others that see the game for what it is and choose not to get caught up in the machinations. They have found their niche, their comfort zone where they can gain satisfaction from a job well done despite the game going on about them. They are not as deeply impacted by their environment, and could perform well in a wide variety of different games – while they may not come out as the dominant winner, they are also less likely to suffer deep losses. Consciously or not, they behave in a manner that supports themselves and others, recognizing that working to win the game often means that most end up losing.

Finally, there are those that are frustrated by the games. They are often overwhelmed by the strong players, sometimes to the point of having to leave the game altogether, through choice or through exhaustion. It can be a tough thing to realize that business is more than the reading, writing and arithmetic that they fed us in school, some never do realize it, or continue to hold on to the notion that business should be fair and have clear, transparent rules.

While there are a few businesses that work that way internally, most play the games, and all of them have to work in a broader business environment where the games are even tougher.

You have surely seen the games in progress at some point. Perhaps a group of senior managers sitting in a meeting, all suggesting they can pull off miracles, not willing to be the first to blink. Maybe the executive who can only show their approval for an initiative by suggesting a change rather than shutting it down outright – essentially marking their territory. How about the team consciously setting fuzzy goals, making it easy to declare success whatever the outcome. All games, with plenty more examples that can be just as dysfunctional, just as damaging to the other players and to the organization as a whole.

If you are seeing this sort of thing, step back, recognize it is a game, and use it to your advantage. Give the players something to chew on, anticipate their moves, give them the opportunity to believe they have the upper hand, think a few steps ahead of them. Playing your cards right, not only can you achieve your goals, but you can do it in a manner where others feel they have won as well. Now that’s taking the game to another level. - JB [top]

Backsliding (Compendium 5.20)

Almost anywhere I go, I hear stories about individuals or companies that do great things, only to have that greatness backslide over time, often to a point where that great performance never really happened.

We’ve worked in one organization with a wide range of people over time on their personal effectiveness. One of the recurring points of feedback we get at the end of the session is that there is concern that these newly developed good habits will disappear, often based on their exposure to peers where this has already happened.

One division of a large company embraced formal software inspections. Their experience was so overwhelmingly positive that it is commonly held up as a significant industry benchmark identifying the value of the practice of formal inspections. In speaking with some of the engineers involved in the study, they indicate that they don’t really do that anymore: “Well, you know, we had a reorg...” is how the story starts.

I just finished working with a company that has embraced the CMMI as an improvement framework (for all the right reasons, for a change). There are indications that some of their divisions that have made it to Level 2 or 3 are showing signs of backsliding.

A lot of companies that change the way they do business often find themselves falling back into their familiar old habits.

I’m just starting to learn the saxophone, and after a week or two on the road the instrument feels foreign. It feels like I’m starting from scratch when I pick it up again, my fingers need to be retrained where to go.

It’s not a software team syndrome; it is part of the human condition to quickly lose what has not been conditioned and reinforced in favour of what is familiar, regardless of the consequences.

In Leading Strategic Change, from J. Stewart Black and Hal B. Gregersen (Prentice Hall, 2003), the authors suggest that change is a cycle as follows:

We start in a state where we are doing the right thing, and doing it well – the proverbial status quo.
Something happens (market conditions change, for example) and we find that while we are still doing the same thing, and doing it well, it is no longer the right thing to do. In software, I would modify this to suggest that while in the status quo state, some disastrous event or astute introspection highlights that we actually weren’t doing the right thing in the first place, but we were oblivious to the problems.
We change our behaviour, and initially, the new practices, although they are the right thing to do in the new situation, are not being done well. In software, this is where we learn to see the value of appropriate application of best-practices.

It is at this point where we need to ensure that there is strategic continuity in what we do. We need to constantly reinforce our belief that the new behaviours as the right ones,