Using eXtreme Practices to Run Your Business

To me the great innovation of XP was to shift the emphasis of software development away from realising a set of specifications to realising value for the customer and the twelve practices are all about maximising the team’s ability to do so. Its no great insight to recognise that running any kind of business is also about realising value for the customer and about a year after starting my first business I saw that we could usefully apply some of the XP practices to the business management as well as software delivery.

That was a number of years ago but this week I was reminded of the value of applying these practices, especially in the context of a lean startup where the need to discover your product/market fit and develop your business model is directly analogous to the XP team’s ‘discovery’ of the system implementation that achieves the greatest value for their customers and to keep on doing so.

Pairing – In a startup you can’t afford to do everything together; there has to be some division of responsibility and labour. However, the key business management activities – accounting, customer discovery, sales, marketing, product development – are best paired. Working as a pair to produce the monthly financial summary is so much more valuable than reviewing a spreadsheet produced by someone else and everyone on the management team needs to know what is going on in sales and customer discovery. The pair-programming benefits of lack of a single-point-of-failure, cross-pollination of skills, improved quality of output and so on are just as desirable in business management as software development.

Planning Game – However you execute the ‘planning game’ the same principles and outcomes are desirable in business planning as software delivery planning:

  • Quick and Easy. If you spend all your time plotting how to take over the world only one thing is certain: you wont.
  • Short-term Focussed. You need some idea of where you’re going but the emphasis has to be on what you do in the next few weeks to find out what your customers want and to make those sales.
  • Feedback-Driven. Don’t forget, in the relentless drive towards growth, to look at what has been working and what hasn’t.
  • Priority-Driven. There is no such thing as “not enough time” only “too much to do“. Make sure you’re doing the right things.
  • Visible. Getting the tasks up on the wall and making them visible to everyone is a powerful way of ensuring the priority tasks get delivered, everyone can see when things aren’t happening fast enough or when someone is struggling, and everyone can contribute to ensuring the goals for the business iteration are achieved.

Test Driven – My personal moment of epiphany with XP came when I realised how TDD meant we could spend a lot less time worrying about ‘architecture’ and ‘the design’ (less, not none) and more on saying what we wanted to happen and then making it happen. Setting simple tests for business management tasks like running a marketing campaign or pursuing a particular deal makes it easier to focus on getting things done and to learn from the outcomes.

Continuous Integration – Just as separately developing several streams of code and then trying to bring them together after a long period of time is usually a disaster, having the product people go off and develop the product separate from the sales and marketing people, separate from the people worrying about the money will usually end up with a bust company. Even in startups such as ours where the product people, the sales and marketing people and the people worrying about the money is actually a grand total of two people, the various strands of thinking and work need to be ‘integrated’ on a continuous (daily or weekly) basis.

Sustainable Pace – The first six months of a start-up are the hardest, except for all the months that come after. Which is to say that, if your startup is a success, you will work extremely hard to get it off the ground and then have to step your game up to keep it in the air. If you need to work 20 hours a day, 7 days a week just to get it off the ground, there’s a very good chance that you don’t have a business there. There’s also a very good chance that you’re just trying to do too much. Either way, you will have difficulty sustaining that level of effort when you get to the point the business really needs it.

As an aside, one thing that’s important to recognise about Sustainable Pace in running a startup is that for many people its not just your Sustainable Pace. If you have a partner and/or children, or just friends that you value, what’s the pace that you can sustain and that they can too?

I think its also worth saying that I don’t see XP as being a blueprint for lean start-up management and there are at least two XP practices that I think don’t really work:

Collective [Code] Ownership doesn’t really have an analog in business management. As mentioned earlier, most startups rely on some degree of division of labour. The fact that delivering a new sale or a marketing initiative requires building a whole load of relationships and interacting with people rather than a deterministic machine means that someone else can’t just step in at any point, make a bunch of changes and then roll back if it doesn’t work out. By all means collectively own the business and the objectives but no-one should be able to just go and interfere in someone else’s work at the drop of a hat.

Whole Team – Possibly a controversial one this but, after 13 years of running startup businesses, I’ve come to the conclusion that the running of a business is not a matter for the whole company. Yes objectives should be shared, there should be some form of vision for everyone to buy into, everyone should have a voice that is listened to. But not everyone has the skills and experience to make good judgements about the business direction or about the business’s current position. Especially in startup where things like cashflow, market conditions, and sales prospects are extremely volatile, the management team needs to know how and when to communicate about how the company is doing to everyone in it and how and when to respond to feedback and ideas from outside management.

Advertisements

6 thoughts on “Using eXtreme Practices to Run Your Business

  1. Petar Shomov

    Excellent read, I agree with almost everything except the last point, it’s controversial indeed ;). Could you elaborate in what kind of situations should management NOT engage in a dialog about the direction of the company? I guess it is hard for me to see this since we were a startup of 4 (7 currently) and we are all involved in the decision process for pretty much every move the company makes.

    Reply
  2. pauldyson Post author

    One concrete example is when you have to make radical changes to the business in order to save it. Sacking people or asking for redundancies is a very hard step to take and I don’t see how it is possible to make such decisions collectively without destabilising the company at a point where it is, by definition, in a very fragile state. I’ve been there … I hope you never have and never will.

    But that’s a radical example. More generally I would simply say that just because someone works for a company, they don’t necessarily have the skills or judgement to make decisions about what best to do with it. My company sells high-value products to customers and each sale is a very complex process with lots of decision points. In order to participate in those decision points you need to understand all of what has gone on before. Signing a customer is a business-changing decision but I don’t expect the guys in the dev team to have to understand all of the sales process just like I don’t expect the sales guys to understand the tech decisions being made. That doesn’t mean we never talk about the sale in the round, quite the opposite, just that the decisions to be made lie with the management team

    Of course, if your business and the people working in it all making decision collectively and that’s what you’re looking for, then great. But I don’t think this scales and isn’t even all that desirable so prefer to be clear early on that a) this is a business not a mutual or a collective, b) that everyone has their areas of responsibilities (and are accountable for the decisions they make) and c) that we make good decisions by asking for input and information but not by taking votes or acting as a union.

    Reply
  3. John S Nolan

    Collective Ownership: Isn’t the analogue in business the practice of everyone stepping in when necessary if an opportunity arises, (for example, the techy “Selling” if they happen to talk to someone in a bar that expresses an interest, the sales person answering the ‘technical help line’, everyone doing expenses clearly and efficiently so the accounts are correct)

    It’s interesting you use the term “interfere in someone else’s work” – that’s often the resistance to collective code ownership

    Reply
    1. pauldyson Post author

      Not everyone has the necessary skills and experience to operate in every aspect of the business. This isn’t the case with Collective Code Ownership: we assume that all coders have the ability (guided by the tests and in a pair) to change any part of the code … even to the extent that they may try to change code in an area of the system they’ve never seen before or in a technology they are not so familiar with.

      In the examples you cite, I’m very happy the techy engages with a potential customer and also believe everyone in a start-up has to be prepared to do some level of selling if they ever meet a potential customer. But I wouldn’t be happy for that techy to start trying to negotiate a price or make the sale; the appropriate response to questions of price, discounts, timescales, etc. is “I’ll have a sales person call you”. Equally non-techies will always have to pitch in taking support calls but, again, their ‘ownership’ is limited to answering the phone, getting an understanding of the problem, and then involving the right person if it is isn’t a simple matter to resolve. Promising an issue “will be fixed within the hour” or diving in trying to change the code themselves is going beyond the boundaries of their ownership.

      As you write, the notion of ‘whole team’ has become corrupted from how I understand it to being some weird Utopia where every member is equally responsible for everything that goes on and equally capable of contributing to every area. Sounds more like a cult than an effective development team or a business to me. Collective code ownership works because, in a good XP team, every coder really can be equally responsible for the code and equally capable of making changes to the code but I don’t think this scales up to all aspects of system delivery and I certainly don’t think it scales to running a business.

      Reply
  4. John S Nolan

    You seem to be saying it works with coders because they can take responsibility and autonomy within their constraints (tests) and capabilities. Could the same not be done for other areas of business ? Does this not imply that the management team (of an eXtreme business) should define the constraints in each area for a level of capability and responsibility?

    I often think of ‘ownership’ being about leading and ‘responsibility’ about doing. e.g. a techy finds some interested in the product in a bar, passes it over via intro to a sales guy but follows it up. techy has ownership but sales guy has responsibility?

    Reply
    1. Paul Dyson

      No I’m saying it works *with code* because code is deterministic, unemotional, verifiable, infinitely malleable and extremely tolerant of human failings. And its version controlled. Customers, partners, the bank manager, journalists et. al. are not.

      I think your notion of ownership is interesting and can see some circumstances where it might be desirable. Personally, however, I prefer to see the ‘handover’ be of both responsibility and ownership. The techy should trust the salesperson to approach the lead appropriately and to involve the techy if a when necessary.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s