Category Archives: Business

Remote Coaching & Pairing: for Individuals & Teams

If you’ve worked with me or Andy Palmer before or you’ve read one of our blog articles, sometimes you might be thinking…

Antony/Andy would know how to make what I’m doing better/easier right now, if only they were here!

Maybe all you really need is 30 minutes to an hour pairing or just talking, not a whole day of our time. Maybe all you need is a few emails back and forth between us. Rest assured, we’re here and we’re happy to help, on anything including:

  • For product and technology teams:
    • Thinner slicing of your Minimal Viable Products (MVP)
    • Effective user stories, Feature Injection & agile business analysis
    • Effective Cucumber scenarios
    • Communicative, narrative code
  • For coaches, managers and leaders:
    • Values & building a culture of innovation
    • Enabling more adaptive teams
    • Challenges of culture and process change
    • Facilitating effective workshops: story-sizing/planning/retrospectives

All sessions are strictly confidential and we’re more than happy to sign a mutual non-disclosure agreement if required. If you aren’t sure if either of us can help, why not get in touch and let’s see. If we can’t, it won’t cost you anything…

Individuals: Pay what you think it was worth

Maybe you need to talk about a challenge you’re facing with your team, colleague or management. Perhaps you have some nightmarish Cucumber scenarios that are making your head hurt. Perhaps you just need someone independent to bounce ideas off.

We’ll have a conversation on Skype, Google Hangouts, Facetime or just on the phone. At the end of the time, all you do is:

  • Tell us what you thought it was worth and
  • Pay only what you are comfortable paying

Money is relative to both your personal income and your responsibilities. You know what they are and we trust you to make a fair exchange of value. All we ask, when you pay whatever amount you’re comfortable with, is to tell us what you thought the session was worth.

You may work in a company that trusts & values your judgement, allowing you to expense personal development activities. This model equally applies, but when that isn’t an option…

Companies: Pay what you think it will be worth

Many large, established companies find it hard to work in the above way. You may not feel you have the freedom to work in the above way (in which case we really should talk). Your manager may want to sign it off and your finance team may want to have a purchase order in place for a fixed amount before you talk to us. So, if you want let’s talk a bit about the challenge and what a new way forward in addressing that challenge is worth. We’ll agree a price and we’ll go from there.

After a chat, you might find that you have a lot more freedom than you think and we can help you make things easier. For more information, get in touch with an email or a call to +44 845 056 9606. We’re happy to help.

Slow is Smooth–Smooth is Fast

A few years ago, to explain what goes wrong for many organisations that “go agile”, I wrote an article called “Putting the Kart before the Horse” [1].

Go-karting is where most of the current Formula One racing drivers first learned the basics of race-craft. Antony Marcano, a former kart racer himself, recounts a father-and-son racing experience that helps him explain what goes wrong for many organizations that adopt Scrum as their first attempt to “go agile.”

In this article I explained how novice drivers try to go as fast as possible rather than trying to master the racing line:

At the open practice session my son and I attended, novice drivers seemed to approach their first lap as if it really were as easy as experienced drivers make it look. They floored the throttle and flew down the straight only to crash—painfully and expensively—into the barrier at the first hairpin turn.

I went on to liken this to how many teams adopt agile…

Organizations starting their transition to agile methods with Scrum are much like the novice drivers trying to go fullthrottle before learning how to take the corners. Before being able to truly bend and change their software with speed and ease, they fly into short iterations and frequent incremental product delivery—crashing painfully into the barrier of hard-to-change software.

It was my son’s first experience in a go-kart. We started by driving slowly with him following me to learn the racing line. We gradually went faster and faster. Soon, we were the quickest drivers on the track.

Since then, he has gone on to advance further and further in his racing. Back then, we were in slow, 35mph go karts. This year he started racing for a team in race-tuned karts (see photo). The driver-coach in the team watched him driving on his first few attempts in his new high-performance machine (70+ mph, super-car acceleration). While he was reasonably quick, he wasn’t smooth.

Photo of Damani Marcano driving his 2013 Mach1 Kart for MLC Motorsport
Damani Marcano driving his 2013 Mach1 Kart for MLC Motorsport

His coach told him “slow down”. His coach said “whatever speed you can do while still driving on the ideal racing line is the speed you should be going”. My son went out again. Initially slower than he was before, his speed progressively built… we watched his lap-times improve dramatically.

Yet again, we relearned this lesson: slow is smooth–smooth is fast.

For some reason, I see teams who are novices in agile development make the same mistake, however, not always feeling like they have a choice. Kanban might make it easier to start from where you are and gradually improve but it’s ok if you’ve decided to start with Scrum. When starting with Scrum, start slow, focus on doing fewer things well first then progressively improve. On a course I gave recently, one of the attendees said “but how do you get management and marketing to back-off enough to allow us to slow down?”

My answer: avoid going faster than you can. But if you feel compelled to go faster, make it a business decision. Help them understand that there is a risk that whatever time you save now will cost you more in the future. Help them understand all the effort you’ll spend repairing the damage that going too fast will cause. Pretty soon you’ll be spending so much time fixing problems and struggling to adapt hard-to-change code that there will be little capacity left to add new features. Essentially, incurring a  “Technical Debt” .

As a general rule, I always try to start something new, slow and steady. I only go as fast as I know I can while predictably and sustainably delivering. I’m mindful of business pressures but experience has shown me that by focusing on “making things right” we can deliver smoothly, build trust and progressively become faster.

—————–

[1] You can read the original article here: Putting the Kart before the Horse? – published in Better Software Magazine, 2009

My son’s story is continued here: http://damanimarcano.com

Is updated here: https://www.facebook.com/DKMRacing

And here: https://twitter.com/DKMRacing

And here (updated 03-02-2014)…

UPDATE [11-12-2013]: Damani Marcano finished his first ever season 3rd in the Hoddesdon Kart Club Championship Junior Rotax Formula at Rye House, the track that started Lewis Hamilton’s career. This achievement is significant since, as a novice license holder, Damani had to spend the first half of the season starting every heat from the back of the grid. Find out what happens next season by following his story on Twitter and/or Facebook. Who knows, by adding to his ‘likes’ / ‘followers’ you may become a part of his story by helping him become more attractive to a potential sponsor.

Knowledge-work, is serendipity-work

Serendipity is core to the success of modern companies. While some may not have articulated their insights as facilitating serendipity, it was certainly what they were thinking, even if they didn’t realise it.

Enabling Serendipity

For example, Google’s 20% time, where employees can spend 20% of their time working on anything they like, has resulted in numerous “happy accidents” where pet projects have matured into fully fledged revenue enhancing products, such as gmail.

Charles Leadbeater talks of the “we think” phenomenon, where innovation occurs simply by people having access to products that give them flexibility in how they use them. This philosophy taps into the free thinking collective consciousness of the social web. The birth of Twitter is the perfect example. Hash tags, “@” mentions, retweets are all customer innovations that were subsequently added to the Twitter experience we know and love today. It’s highly likely that “@” mentions were a significant factor in boosting user engagement and hashtags are now one of Twitter’s revenue sources.

Countless more examples exist but how is this achieved and what does this have to do with serendipity?

Adrian Cockroft of Netflix explains that you can’t force innovation, you have to get out of the way of innovation. This applies to what we enable people to do with products, such as the Twitter story, as much as what people do with their 20% (or more) time.

Facilitating Serendipity

It’s not just the organisation that needs to embrace serendipity, the working environment does too. In “Designs for Working” Malcolm Gladwell highlights:

“Who, after all, has a direct interest in creating diverse, vital spaces that foster creativity and serendipity? Employers do.”

He uses Greenwich Village, where opportunities for people to meet by happenstance are rife,  as a model for the ideal work environment. Many of his ideas can be found in the forward thinking companies, I’ve already mentioned, that are breaking all the rules and being so successful as a result.

Much innovation in what we produce or even how we produce it may never have happened if they had required a typical business case or if the working environment was more like a factory-line or made up of closed offices.

The Serendipity Economy

Daniel Rasmus, the person who coined the phrase “the serendipity economy”, captures the problem with your traditional business case so well when he says:

“If the only economics you have to work with come from the industrial age, then everything looks like a factory.”

Rasmus highlights, in “Welcome to the Serendipity Economy”, the benefits of knowledge, ideas, experimentation are not immediate or predictable within a specific time-frame or quantifiable with traditional measures of productivity or returns on investment. He highlights the importance of serendipity in innovation and the power of social networking in accelerating the process.

I was talking with one client the other day about their budget approvals process. It was so heavyweight that several increments of the product could have been developed with the money spent on documenting theoretical feasibility and commercial viability.

Exploiting Serendipity

Instead, companies would be better off adopting a lean start-up model for new projects. Ensure that employees have social networking tools at their disposal. Share the ideas. Create a simple sign up page that’s sent out to employees or even the general public. Get feedback. Provide “seed-funding” to the projects that inspire the most passionate responses. Get the first few features built. See how hard or easy it is. If it works out, you’ll have empirical data to base future estimates on and you’ll have the beginnings of the product (maybe something releasable).

All this can be done with less than many large companies would have spent on writing business cases with hypothesised technical-feasibility and unproven commercial-viability. Yes, some ideas will flop, but that experience could be the very thing that inspires your biggest success.

Google, Twitter, Netflix and more show us that investing in serendipity (and talent) is key to the modern organisation’s success. It will take a leap of faith that many feel they cannot afford to take in these difficult economic times. But, to survive and thrive in the future, you have to ask if it’s a leap you can afford to not take.

Sushi, Hibachi and Other Ways of Serving Software Delicacies

Let’s say you own a restaurant. Quite a large restaurant. You’ve hired a manager to run the place for you because you are about to take the fruits of your success and invest in opening three more around the country. You leave the manager with a budget to make any improvements he sees fit.

After being away for a few weeks, you return to your restaurant. It’s very busy thanks to the great reputation you had built for it. The kitchen has some new state of the art equipment and you can see that there are a lot of chefs and kitchen-staff preparing meals furiously. Obviously, with a restaurant this full you have to prepare a lot of meals.

Too many chefs?

But then, you notice that there are only a few service staff taking orders and delivering the meals to the customers. Tables are waiting a long time for their meals. You notice the service staff spending a lot of their time taking meals back to the kitchen because they have gone cold waiting so long to be served. You also overhear several customers complaining that the meal they received was not the one they ordered, increasing the demand for the preparation of more meals. You call the manager over and ask him what’s going on… he says “because we need to invest more in the kitchen”. You wonder why. He tells you “because there are so many meals to prepare and we can’t keep up”.

At this point, it’s quite obvious that the constraint is not through lack of investment in the kitchen. Instead the lack of investment is in taking the right orders and getting the meals to the customers. To solve this, I think most people would increase the investment in getting the order right and in how the meals get to the customer not by investing more into the kitchen.

Obvious, right? Despite this, time and again, I see organisations happy to grow their investment in more programmers writing more code and fixing more bugs and all but ignore the end-to-end process of finding out what people want and taking these needs through to working capabilities available to the customer. Business analysis, user-experience, testing and operations all seem to suffer in under investment. If it takes you four weeks to write some code for several new features and then another four weeks for that to become capabilities available to your customer, hiring more programmers to write more code is not going to make things any better.

Sushi and Hibachi

So, how would you advise the restaurant? In the short term, you can get some of the chefs to serve customers while you hire more service staff. Another solution is to invest in infrastructure that brings the meals closer to the customer, such as in hibachi restaurants where the chef takes the order and cooks the meal at the table or in sushi restaurants where meals are automatically transported via conveyor belt.

In software teams, we can bring the preparation of features closer to our customers. We can involve a cross-functional team in the conversation with the customer (such as the chef being at the customer’s table). We can also automate a large proportion of the manual effort of getting features from a programmer’s terminal into the hands of the customer (as in with the conveyor belt). And, there is so much we can automate.

Integration, scripted test execution, deployment and release management can largely be automated. Since speeding up these tasks has the potential to increase the throughput of an entire development organisation, it seems appropriate to invest in these activities as we would in automating any other significant business activity – such as stock-control or invoice processing.

Cooking for ourselves

Why not ask a good number of our programmers to take some time out from automating the rest of the business and automate more of our own part of the business? Taking this approach seems to be the exception rather than the rule. I see organisations having one or two dev-ops folks trying to create automated builds; and similar number of testers, with next to no programming experience, trying to automate a key part of the business – regression testing. And then asking them all to keep up with an army of developers churning out new code and testers churning out more scripted tests.

Serving up the capabilities

Instead, let’s stop looking so closely at one part of the process and look more at the whole system of getting from concept to capability. Let’s invest in automating for ourselves as much as we automate for others – and let’s dedicate some of our best people to doing so.

In short, it’s not just about the speed at which we cook up new features. It’s as much about the speed at which we can serve new, working capabilities to our customers.

To hack, or not to hack

Recently, Engadget reported that Nokia had decided to abandon MeeGo in favour of Windows Mobile. What was interesting is the reported process used to make this decision:

Elop drew out what he knew about the plans for MeeGo on a whiteboard, with a different color marker for the products being developed, their target date for introduction, and the current levels of bugs in each product. Soon the whiteboard was filled with color, and the news was not good: At its current pace, Nokia was on track to introduce only three MeeGo-driven models before 2014-far too slow to keep the company in the game.

This brought to mind some blog posts I wrote in early 2010 (now copied to this blog – see previous two entries). I talked about ‘critical mass’…

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

In the case of Nokia and MeeGo, there isn’t enough information to know if that’s what had happened but it does suggest, at least, that it was more economical to choose an alternative third-party OS than to continue with MeeGo. Integrating Windows Mobile is going to come at some cost, of course, but clearly they decided it was less than sticking with their current strategy.

This is an example of modern markets demanding more sustainable, adaptive and agile product development cycles, and a company recognising this and acting on it.

It is also a demonstration of how an ever-growing cost of change (e.g. through the number of bugs consuming resources that would otherwise be adding new value) is really deferring of cost – i.e. technical debt.

There are many arguments for ‘prudent’ acceptance of technical debt… This story, I think, is an example of where it wasn’t obvious when that debt was no longer prudent until it was too late for MeeGo as a product.

And this is one of the problems with some lean concepts applied to new products and start-ups. The advice is often to get feedback from the market quickly by hacking the product together and release as quickly as possible. The trouble is, at what point do we take a step back and change to more sustainable practices? Probably around the time the product is selling… but then we’re under pressure from competitors who have seen our innovations and want to copy them… so we’re tempted to keep hacking out more features only to find that the faster we hack the slower we go.

There is no magic answer, to the question “when do we stop hacking and start sustainably building?” We might wait until we’re making enough money to hire more people to do remedial work.

As soon as we find we’re enhancing a feature, it might mean that it’s a key part of our product – one we’re going to keep. We might then treat any code we touch during that enhancement as legacy code, building in the cost of remedial work into the enhancement.

Some would argue that it’s faster overall to never hack things in and to commit to  sustainable product development practices from the get-go. This probably applies in many cases but especially to large complex products like operating systems.

Whatever the strategy used, there will come a point where you can’t hack in any more features. The question is, will you decide when that happens or will the cost of change decide for you.

 

 

Old Favourite – More Sharks and Delaying Critical Mass

This article originally featured on my old blog on 19th January 2010.

In a previous post I talked about Critical Mass of software. I showed how an ever-increasing cost of change resulted in it becoming more economical to completely rewrite the system than to enhance and maintain the original.

I explained how this could be avoided by using practices that sustain a consistent and flat cost of change. I also mentioned that you could defer reaching critical mass. Some teams find it difficult to get the time to do this because “the business” always has “more important” or “higher-value” things on their backlog.

What are the implications of reaching critical mass? Well, depending on what the software does and whether the rewritten version still has to do all of those things, it could cost millions… or more.

Presented with the situation that the product could reach critical mass within a year – costing millions to replace – do you think “the business” would start to think it is worth investing in reducing the cost of change? Obviously, I would advise teams to avoid this situation in the first place:

The reality for many teams I’ve encountered is that they don’t feel empowered to push back on the business’ demands for that next feature in half the time it takes to do it properly. If we could present back the impact of that choice as shortening the time to Critical Mass and bringing about costs to replace the software far in excess of the value gained by delivering that feature a month early then perhaps the business would be better informed.

A big visible chart on the wall, showing the estimated point at which Critical Mass was reached could play a big role in getting the business more interested in sustainable change, or at least inspire a conversation on the subject.

Convincing “the business” to invest in some remedial refactoring or allowing three times as long for each feature to facilitate enough remedial refactoring for each new feature and refactoring-as-we-go for the new feature might be easier if we could represent this idea visually:

The problem with this idea is how do we credibly determine when Critical Mass is going to be reached? Many experienced practitioners could probably reasonably accurately estimate when that was going to happen purely on gut feel but this would be torn to pieces by many product managers. I’ve not solved this problem yet because doing this would require a mathematical model, determined by empirical data.

Perhaps someone will take inspiration from the ideas in these blog posts and find a solution. Perhaps someone has already done this or maybe this is an idea for a future PhD I might undertake? Maybe someone else will take inspiration from this article and undertake that work before I do. If so, they’re welcome to (with due attribution where applicable of course ;-)

I think it is possible, however, to come up with a simple model based on the average complexity per unit of value (assuming that the team is using value and complexity). Trending this and keeping an estimate of a complete re-write up to date might allow the simple charts above to be maintained along side release-level burn-down charts.

These ideas are still in their infancy for me. Has this problem been solved already? If not, I encourage others to explore my hypothesis and help take it from just an interesting idea to something more useful.

Old Favourite – Sharks, Debts, Critical Mass and other reasons to Sustain Quality

This article originally featured on my old blog on 18th January 2010.

A while back I tweeted about critical mass of software:

Critical Mass of Code – past which the changeability of the code is infeasible, requiring that it be completely rewritten.

An elaboration of this might be:

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):

Note:The cost of a rewrite gradually grows at first to account for the delay between starting the re-write and achieving the same amount of functionality in the original version of the software at the same point in time. The gap between the cost-of-change and the cost-of-rewrite begins to decrease as the time it takes to implement each feature of comparable benefit in the original version grows.

It was just one of those thoughts that popped into my head. I soon discovered that critical mass of software is not a new idea.

One opportunity that I feel organisations miss out on is that this can be used as a financial justification for repaying technical debt, thus preventing or delaying the point at which software reaches its Critical Mass, or avoiding it altogether.

Maintaining quality combined with practices that keep the effort involved in completing each feature from growing over time can defer critical mass indefinitely:

Note: The cost of a rewrite is slightly less at first assuming that we are doing a little extra work to ensure that we get the infrastructure we need up and running to support sustainable change (e.g. continuous integration etc.)

This flat cost of change curve is one of the motivations of many agile practices and software craftsmanship techniques, such as continuous integration, test-driven-development, behaviour driven development and the continuous refactoring inherent in the latter two. A flat cost-of-change trend is good for the business, as they have more predictable expenditure.

The behaviour I’ve noticed with some teams is to knowingly accrue technical debt to shorten time to a near-future delivery in order to capitalise on an opportunity and then pay it back soon after:

This certainly defers reaching critical mass but it doesn’t prevent it.

Unfortunately, I see more teams taking on technical debt and not repaying it (for various reasons, often blamed on “the business” putting pressure on delivery dates).

If we had a way of estimating the point at which we’d reach critical mass, we’d be able to compare the benefit of repaying technical debt now in order to avoid or delay the cost of a rewrite… or even better, demonstrate the value of achieving a flatter cost of change.

I’m not sure that we have the data or the means of predicting it, but perhaps these illustrations of a hypothetical scenario will help you explain why sustaining constant quality, automating repeatable tests (or checking as some prefer to call it) wherever technically possible and, on those occasions when we do need to make a conscious choice to compromise quality to capitalise on an opportunity, that the debt is repaid soon after.

One company I know reached this point a couple of years ago and embarked on a department wide transformation to grow their skills in agile methods so that they not only re-wrote the software but could also avoid ever reaching critical mass again. A bold move, but one that paid off within a year. Even for them, they’ll need to avoid complacency as time goes on and not forget the lessons of the past. Let’s hope they do.

Financial Rewards & Poorer Performance

I like the message in this post by Johanna Rothman on Hiring Technical People. Johanna voices her disagreement with something said to her at a conference:

“I don’t think people have the same passion about their jobs. They just want more money.”

Johanna goes on to say:

I, of course, disagreed. The reasons people want money is that organizations have broken the implicit social contract to be fair with their employees […] That means there is strictly a financial contract between the employee and the organization.

There is, however, even more to this topic that I’d like to share.

The Business Incentive

There is a business incentive to paying more per employee that gets hidden by typical “per-unit” cost-budgetting.

Chapter 2 of Dan Pink’s book “Drive” references research (funded by the United States Federal Reserve Bank) that showed that monetary incentives for cognitive tasks will actually have the opposite of the desired effect – perhaps because cognitive capacity is wasted on thinking about what happens if the criteria for the financial incentive are met/not met.

So, financial incentives actually result in poorer performance for cognitive tasks.

Instead, Dan recommends paying enough that money just isn’t something that the employee ever thinks about. This frees up cognitive capacity to focus on the work at hand – thus increasing performance.

As a result, the total output of fewer employees who are paid more can be greater than having more employees who are paid less. This assumes that all the people in these two situations are of comparable levels of talent.

Add to this the fact that a company that does this will not only attract and retain the best talent, the performance gains through increasing the organisation’s “talent-density” can be even greater!

Even if your total salaries budget was the same in both cases and you just had fewer employees, each paid more but delivering the same as the scenario with the larger number of employees – there are still savings to be made on accommodation costs, management overheads etc.

Understanding Drive & Motivation

In Part Two of Drive, Dan Pink explains the three elements of motivation:

  • Autonomy
  • Mastery
  • Purpose

Many of Johanna’s suggestions mostly fall into the “Mastery” category – conferences, book-allowance, etc. Some of her suggestions imply autonomy  – such as more flexibility in working hours and holiday/vacation.

A great example of this is Netflix. They started with old-fashioned holiday limits, but eventually…

…some employees recognised that this arrangement was at odds with how they really did their jobs. After all, they were responding to emails on weekends, they were solving problems online at home at night. […]

Since Netflix wasn’t tracking how many hours people were logging each work day, these employees wondered, why should it track how many holidays people were taking each work year?

From the Telegraph Newspaper

Netflix no longer tracks holiday time taken by their employees. Despite this, Netflix offices aren’t deserted with everyone on a permanent holiday and its people have made Netflix so successful that they (arguably) played a role in driving a much larger, more well established provider of blockbuster movie rentals to bankruptcy.

Dan delivers some compelling arguments that motivation and getting the best performance from people comes from giving people autonomy, the opportunity to master what they do and a clear purpose (beyond just making a profit for their employer).

Choosing the right incentives

We can take Dan’s “Three Elements” to inspire ideas about what incentives will motivate our people. Or, we can take these ideas completely to heart.

Rather than telling our employees that they have a book allowance and a conference/workshop budget and so on, we could simply give individuals (or teams) a “Mastery” budget and give them autonomy in how they spend it. Or, we could just pay it directly to the employees (like many companies do with a car allowance) and trust that they’ll spend it wisely.

Realistically, there may be taxation benefits to not giving the money directly to the employees. It may also offer more flexibility, say if a team, wanted to combine some of their budget for coaching or bringing a trainer in-house rather than individually going on the same public course.

The biggest fear some will have is that employees will abuse this freedom. If this happens, we can consider the misspent cash as an investment in discovering the people in our company who we might not want in our company anymore.

Some may argue that this is too much of a risk, but you know what they say… the greater the risk, the greater the rewards.

Many of the things I mention in this post can be heard in Dan Pink’s 10 minute talk on “Drive”…

 

Old Favourite: Adaptive Budgets? “Pull” the other one!

This was originally posted on my old blog on 10th April 2010

Recently, I wrote about my views on using and estimating with task-cards. I highlighted that tracking progress with burn-up/down charts showing effort completed/remaining is not a true measure of progress, especially if we subscribe to the idea that we measure progress with working-software.

I also highlighted how tasks “horizontally slice” a “vertically sliced” story.

This inspired an article on infoq by Mark Levison. Since its publication, there have been several comments.

There are some specific points I’ll be answering on infoq, but some general points are more easily answered here…

True measures of progress
One of the key points I was trying to make in my first post (linked to above) is that if “working software” is our measure of progress then tracking task completion is not consistent with that.

One of the problems task-hours are trying to solve is to provide a visible indication of progress. It’s also something that many people find easier to understand. The idea of relative-points estimation seems to baffle many people when they first encounter it.

In my original post (linked above) I referenced an approach, blogged about by Jason Gorman, outlining a solution to providing a visible indication of progress that is compatible with the idea of measuring progress with working software. It also works more seamlessly with the solution of measuring throughput trends of the team (e.g. with story points) so that the team can estimate how much can be done in the next iteration.

Value Points & Task Points
Value points were mentioned in the infoq comments. Value points are solving a different problem and don’t help the team estimate what can be done. The value of a story isn’t an indication of its complexity. Value, combined with complexity points, can help determine priorities. Arlo Belshey explains some interesting views on this.

Prioritisation is, in my view, one of the few reasons to place some sort of estimate on value & complexity. Unfortunately, it seems to be often used to establish a contract with the team for when something will be done and apply pressure when the estimates turn out to be inaccurate.

Non-estimating pull systems
My preference is to use such estimates only for prioritisation… after that, things just take as long as they take. There is some benefit in tracking accuracy trends so that we can learn from them, however, spending too much time on these things simply slows down the process of getting things done. Interestingly, I have not yet seen the business be quite so passionate about evaluating whether their value estimates were accurate when the product makes it to the real world. Funny that.

Instead, I prefer to leave estimation behind once we’ve prioritised things and pull stories or customer valued work items through the system without using previous estimates to predict their completion date. With the way that most budgets are determined and allocated, this idea isn’t compatible with the way much of the business world works. For pull systems that eliminate estimation as a means of predicting the future to work (such as Kanban), we need a more adaptive approach to budgetary spend. Business needs to find a way to adapt budget allocation more frequently, perhaps as frequently as monthly, perhaps more frequently still. The business now needs to look at how it can respond to change rather than focus on following a budget-plan.

Business-world: now it’s your turn
Budget holders now need to be more agile. We, those who evolve the implementation of the ideas of the business, have responded to their demands to be able to respond to rapidly changing markets and provide that competitive edge. For the more mature implementation teams, the hindrance now is no longer how we make the products, but the business culture of inflexible and predictive budget allocation.

Your Company Values What?

I’ve recently given some time to think about company values on behalf of a client. In my research, I have looked through the stated corporate/business/company values of several organisations, I’m not convinced that many of them are really values.

I’ll take Zappos company values (as they were at the time of writing this) as a perfect example of what I’ve been seeing:

  1. Deliver WOW Through Service
  2. Embrace and Drive Change
  3. Create Fun and A Little Weirdness
  4. Be Adventurous, Creative, and Open-Minded
  5. Pursue Growth and Learning
  6. Build Open and Honest Relationships With Communication
  7. Build a Positive Team and Family Spirit
  8. Do More With Less
  9. Be Passionate and Determined
  10. Be Humble

I love the spirit of these statements and Zappos have a culture that seems to reflect them. These statements, however, are not really ‘values’. Instead, these statements are more like ‘behaviours’.

Behaviours are the things we do. Values are the things we care about.

What are the things we care about?

The things we care about are the things that cause an emotional response – such as when we get angry or frustrated at something someone does, shame at something we do or feel joy and pride when we or someone else does something.

For example, if we care about delighting our customers, we may feel frustration when we see a colleague act with apathy towards a customer complaint or we may feel pride when we or a colleague does something wonderful that our customer didn’t expect.

We may see these responses towards in our clients too. For example, if we value Compassion and Empathy and our customer intentionally delays payment because it helps with their cash-flow we may get frustrated – or if they pay well before the final due-date we may feel positively towards them. But the issue of ‘choosing the right clients’ is perhaps beyond the scope of this article.

When we see our people reacting in these ways, we know that we have an organisational culture based on shared values. We know that we care about the same things.

Why do we want ‘company values’?

For some companies, it’s more about branding – a display of the type of company they think future customers or future employees would want to buy the products of or to work with. It is something that appears on the face of the company but isn’t necessarily reflected in the actual behaviours of the people, as we can see from this article about Enron’s company values. The journalist makes the point that all company values are much the same and really are little reflection of the reality:

I know one writer who, while struggling to draft one of these corporate credos, threw up her hands in despair and observed: ”Why not just come right out and say it? ‘We will strive to make as much money as we can without going to prison.’ ”

She was joking, of course.

What I want from stating our company values is to understand what kind of company we want to be and to guide – even drive – what we do, who we hire and who we fire. I want to see that people in our organisation (and even our clients) have shared, or at least compatible, values. I want to see a negative emotional reaction to situations that go against these values and a positive emotional reaction to situations that are aligned with these values. I want to see the people I work with instinctively do ‘the right thing’ based on our shared (or compatible) values without having to be told what ‘the right thing’ is. I accept that ‘the right thing’ for one person and another may be different – and this is where shared or compatible values are the key to a consistent experience of what we do – for the people inside and outside the company.

The things we care about drive us to act, instinctively, based on the situation at hand. If our people share these values, we’ll act reasonably consistently with each other – delivering a consistent service to our customers.

A Code of Conduct?

When we list our values as the things we do there is a danger that these statements become, to all intents and purposes, a code of conduct. Why does this matter?

A code of conduct, in some ways the ‘laws’ of a company, tells people what to do and what not to do. If we need to tell our people what to do and what not to do (i.e. what is ‘the right thing’ and what is ‘the wrong thing’ to do), I believe, we are compensating for having hired the wrong people.

“Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws.” – Plato

Codes of conduct are a way of constraining freedom. In a society where we have no choice as to who is a member of it, this may be necessary. In an organisation where we do have a choice over who is a member of it, the only reason we would have to reduce freedom is if we compromise on the ‘quality’ of the people we hire.

From slide 38 of this presentation from Netflix, they explain how many companies curtail freedoms as they grow and why they aim to increase freedoms. Hiring the right people is key to the success of this approach.

Many companies try to grow more quickly than they can find the right people to do so effectively. They hire the least-worst from the available candidates in order to grow quickly rather than hiring the best. Netflix have chosen to grow no faster than they can find the most talented people who share in their values.

The people in such an organisation can simply be trusted to do the right thing, in any situation, even if that situation isn’t one we’ve thought of previously. A code-of-conduct and its loopholes is then redundant.

RiverGlide Values

We spent a lot of time thinking about our company values when we first created RiverGlide. We (Andy Palmer, James Martin and I) discussed, explored and refined our understanding of what we cared about and reflected that in our stated values. We learned more as time passed. We added to them (quite recently) because we realised there were many more things that we cared about. How we state our values continuously evolves as we deepen our understanding of what matters to us and what we think differentiates us. These values are not the values we aspire to or the values we want to impose on others. They are the values that reflect what we actually care about. They are the values we see in the people we want working with us.

We originally found ourselves wording our values like this:

<the thing we care about> – <how we reflect that in our behaviour>

Now, I think we’ll be experimenting with this subtle change:

<the thing we care about> – <how it makes us feel when…>

For example:

  • Trust and Transparency – We feel great when we know you trust us through our extreme levels of transparency.
  • Integrity and Courage – We would be unhappy if we told you what you wanted to hear if that was not the same as what you need to know.
  • Innovation and Personal Growth – We get a buzz from learning new things, developing skills, trying whacky ideas and cultivating outside-the-box thinking.
  • Compassion and Empathy – We love what we do when you love what we do. We are as passionate about your people and products as we are about our own.
  • Joy and Creativity – We are inspired by fun and creativity – whether it’s in what we do or what we help you do.

Behind these values is a single purpose to our company – we make things easy – hence our tag-line “flow without friction“.

Your Company Values What?

So, what does your company appear to actually value? What values does the culture of your organisation reflect through how it rewards, recognises and respects the things that people do? How do you feel when people act in a way that is aligned or against these values? How does all of this match up to what your company says are its core values?

Why does any of this matter? It matters to me because I am happier when the people I work with are happy – clients, contractors, employees and colleagues alike. It matters to me because I want to trust that the people around me will ‘do the right thing’ and that we’ll all generally agree that what they did was the right thing (even if sometimes we have to have a discussion to understand why). It matters to the people in the company because we know we’ll share in a vision of what kind of company we should be and be motivated to make it a success together – from the most skilled & experienced craftsmen to the smartest and passionate intern.

For us this was relatively easy because we figured out the essence of our core values early in the life of our company and it has formed the foundation of all our working relationships. For you, a legacy culture may not be so easy to redefine. But, if you have a vision of the culture you want to inspire in your organisation or team… If you understand what matters (or should matter) to you and your people and what will bring your company, and the people within it, success… I think you’ll have a great starting point to begin the harder task of spreading those values throughout the culture of the people in your company and teams.