Software Principles - Agile or not - 2 of 3

Continuing my theme of Principles, I’d like to outline my own principles of “Agile Software Development”. As I implied last time, these may be simply “Software development principles” but right now I’ll keep the “Agile” word.

1. Highly adaptability over highly adapted

Strive to make you processes, practices, team, code and environment adaptable rather than adapted. The future is uncertain and shows no signs of getting more predictable. Rather than try and predict the future and be adapted to it, strive to be adaptable to what ever may come.

Code design and architecture is a good example of this. Rather than spending a lot of time designing a system for the requirements you think the business wants - they may even aware blind this is what they want and sign in blood - accept that things will change.

Adaptability comes not from exhaustive contingency measures but from simplicity, reflection, learning and change.

Plan, design, for the short term but put in place mechanisms to roll with change. Don’t spend weeks designing, spend hours, be prepared to refactor, put in test frameworks to allow change. Sometimes there are architectural things you can do to allow for change - for example the plug-ins pattern - but these are fewer than you think.

Don’t implement this or any other architecture until you actually see the need for it. Don’t build it because you have a hunch.

2. Start small, get something that works, grow

In keeping with the principle #1 above and dis-economies of scale always start as small as you can, if things work then grow. For example: Start with the minimal viable product, if customers like you product add to it. Start with the smallest team you can, if the team delivers good software people use then grow the team

3. Need to think

Agile is not for those who want to follow a flow chart or for those who want to leave their brains at home and follow procedures. Indeed, if you are such a person then working in IT is probably a bad move in the first place.

Not every Agile method or practices will work were you work. Agile experts and methods disagree. You need to think about this.

You also need to think about what you are actually doing, what you have been asked for, and how you can work most effectively. Unfortunately economies of scale thinking has created a lot of companies whose modus operandi seems to be to stop staff from thinking.

1. 4. Need to unlearn

Doing Agile practices is the easy bit. The hard bit is unlearning: the things you have to stop doing. If you have burn down charts you don’t need Gantt charts; if you have an automated test suite you don’t need a regression test process; if you have supplies you trust you might not even need a contract; etc. etc.

Things that have made us successful in the past are included here. Teams advance, companies change, to much baggage from the past is carried forward making life in the new world expensive. Remember the words of John Maynard Keynes:

“The difficulty lies, not in the new ideas, but in escaping from the old ones, which ramify, for those brought up as most of us have been, into every corner of our minds.” The General Theory of Employment, Interest and Money (1935)

5. Feedback: getting and using

Agile doesn’t work out of the box, as the two points above say: you have to find what works for you. Some of this might be obvious at first but the more you get into this the more you are dependent - in all sorts of ways - on feedback.

Feedback about the thing you are building. Feedback about the way you are working - as team and as individuals. Feedback about how your customers are responding. etc. etc. etc.

6. People closest to the work make decisions

The people doing the work are usually in the best position to make decisions about the work itself. They have the most knowledge about the work and they have the most immediate need of a decision.

Every time a decision traverse up a decision tree information is lost and delay is introduced.

7. Know your schedule, fit work to the schedule not schedule to work

Easy really. Know when something is needed by and fit the work to that schedule.

In part this principle is a reaction to Kelly’s First Law of Project Complexity - coming in the next blog entry.

8. Some Agile practices will fix you, others will help you see and help you fix yourself

Some Agile Practices - like planning meetings - will administer a fix and you will get a little bit better immediately. Other practices - like retrospectives - will not fix anything but will help you see what is happening and find your own solutions.

Most Agile Practices are somewhere in the middle. Iterations and stand-up meetings are good examples. They may fix some problems immediately - they will improve focus and communication for sure. More importantly they will help people see what is happening and will, in some cases, force you to get better at what you do.

Software Principles - Agile or not - 1 of 3

I should have been at Tom Gilb’s annual gathering this week - GilbFest as some people call it. Instead I’m sitting at 36,000 feet somewhere over Newfoundland heading for Chicago. I don’t often get out of Europe but maybe my fame is spreading.

The theme at GilbFest this year was Principles - defined by my dictionary as “a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning.” In fact principles is something that has been on my mind a lot over the last year or so. My “What and Why of Agile” which I gave to BCS London a few months ago featured a few thoughts on principles and I started a blog entry on the subject but never finished it.

Now is the time to finish it. Had I been at GilbFest this is what the audience would have heard about, or rather, this blog entry is the first of three instalments on what I would have said.

Let me say I don’t care whether you call these Agile or not, since we can’t define just what Agile is I’m prepared to accept they may just be principles. That said, I will divide the list into “Software Development Principles” and “Agile Software Development Principles” because I think the first set are universally applicable to software development while the second set require you to at least accept the idea of Agile.

I’ll publish these as separate blog entries, there is a lot here. After that I’ll also return to Kelly’s Law which I penned some years ago - before blogs!

Software Development Principles:

Principle 1: Software Development exhibits Diseconomies of Scale

Many, if not most, of us have been brought up with the idea that if we “do” bigger things get cheaper. Buying 2 litres of milk is cheaper than buying 1 litre. Building 1,000,000 identical cars is cheaper than building 10 different cars 100,000 each.

In software this isn’t true. Bigger teams are more difficult to manage, more expensive and less productive per head than smaller teams. This effect is so pronounced that really large teams might be less productive in total than small teams.

For example: a team of five will, per head, be more productive than a team of 25. Still the team of 25 will achieve more in total than the team of 5. However a team of 50 might be less productive than a team of 25 in total.

And its not just teams. Large software releases are more expensive than lots of small releases. Producing software to satisfy 100 users is more expensive than producing software to satisfy 10, or 1.

The effect appears again and again. Its why Lean folk like to emphasis small batch sizes. Unfortunately post-industrial society has internalised the concept of mass production and economies of scale. You, me, everyone, needs to purge themselves of economies of scale thinking and embrace dis-economies of scale if you are going to be be successful in this world.

By the way, I suspect this applies to other industries, more than we realise, however, I am a software guy, I can talk with authority about software so that I’ll stick to there.

Principle 2: Quality is essential - quality makes all things possible

By quality I’m really thinking bugs, I want to see bug-free software. I definitely do not want to see gold plating, I have no time for reusable code (as I said in an earlier blog).

Philip Crossby said it best: “Quality is Free” - Neils Malotaux puts it more accurately if less dramatically “Quality is cheaper.” The basic message is the same: pay attention to quality, rid yourself of rework and it will work out better. I said more about this in my “How Much Quality can we afford?” presentation.

And when we get to Agile I’m quite clear: if you don’t build in quality I don’t see how you can get iterations to work and I have no hope you will ever truly achieve Agile.

I’ll finish here for now, I’ll continue with the Agile Principles in the next entry.

To finish I should say these principles are a work in progress. That doesn’t mean that I intend to change them when things get tough. Rather I mean a) there may be some more I haven’t get identified, b) there might be some even deeper underlying truth below some of these principles.

Intellectual proprerty

Something else that came up at BCS Edinburgh was a question about protecting intellectual property. To be honest, I can’t actually remember the question but I do remember my answer. So since this is a blog, and I don’t need a question to sound off, let me do so….

Protecting your intellectual property (IP), with a patent, is a good idea if only so someone else doesn’t claim the patent and accuse you of breaking their patent. Offset against this is the time and expense of getting the patent.

I don’t really believe that a software patent can protect your IP from the competition, it can slow down the competition, it can make things expensive for them but then, it also makes things more expensive for you and slows you down.

Certainly if you look at the “patent wars” that Google, Microsoft, Oracle and others are engaged in now its hard to see how any of these companies will really benefit. Sure the lawyers will make some money but will any of it really benefit their customers?

And there in lies the really issue with IP: the customer.

Ultimately customers still have the same needs, the same problems, the same demands. Patents only address part of the solution. If you can find another way of addressing the need the IP is meaningless.

So the solution to all of this is really: Innovation.

Seek to innovate to address the customer needs better.

Base your company on innovation and continual change, rather than patents and attempts to freeze technology at some point.

Stay ahead of those who would copy you by innovating, don’t worry about copy-cats, be onto the next thing.

The fly in the ointment here is patents: if you do do something innovative, and you don’t move to protect yourself - a defensive patent - there is a danger that someone else will. I can’t help but see all of this as a diversion from innovating and addressing customer needs.

Are the Business Patterns more widely applicable?

As I mentioned in my last entry about Business Patterns for Software Developers, the audience at BCS Edinburgh asked several good questions. One of these questions was:

“It strikes me that many of these patterns are more broadly applicable and could be applied outside the software industry. Why have you limited them?”

This is true, if you look at the pattern Customer Co-Created Product you will see it is illustrated with a picture of a Boeing 777. Or look at Single Product Company you will find a picture of a Model-T Ford. Many of the patterns use examples drawn from outside of software, and many of the patterns are applicable in other industries.

This in fact is a question that has been asked many time during the writing and reviewing of these patterns: “why limit them to software?”

There are really four answers: my knowledge, customer segmentation, brevity and application. Let me explain each one in its own right, although in truth the four as interlocked.

My knowledge: I first earned money from selling software in 1986, over 25 years ago. I know the software industry. I’ve worked in other industries (electricity supply and investment banking to name two) but I was always on the software side so I was still in the software industry. I know about this industry so I write about what I know.

This isn’t to say I don’t know about other industries. As I said, I’ve worked on the edges of other industries; I’ve read about other industries, I’ve spoken to people form those industries and studied them on occasions. Ultimately its all business. Still, by writing about what I know best, the area my knowledge is concentrated, I believe I write better and add more to the debate.

Customer Segmentation: A book is a product like any other, now its published it needs to sell -Yes! Buy Business Patterns today! Even better write me a review :)

I consciously decided to target this book at a specific audience, the audience I know best. This shouldn’t be a surprise, the book contains a pattern called Customer Segmentation which says exactly this.

Brevity: By sticking to one domain, an industry I know well, by addressing specific readers, I can write less. I can assume more about the readers existing knowledge and I can write less. Had I tried to write a pattern like Product Roadmap and cover other industries I’d need to generalise it more, add more words, in the process I’d loose the applicability….

Applicability: By applicability I mean I try and make the patterns applicable to the software industry, I try to write about concrete steps you can take in the industry to build these patterns. I might not always succeed but I’m sure if I’d tried to write in more general terms I would have been even less specific. Ultimately the book would have ended up being any other abstract book on business.

This lesson was brought home to me when I wrote my first business patterns: The Porter Patterns. These patterns are not in the book. If you want to read them you can download The Porter Patterns for free from my website - as you can the earlier versions of all the patterns in the book.

The Porter Patterns are based on the work of Professor Michael Porter. He proposed several generic models are analysing businesses - Cost Leader, Market Niche, etc. etc. In analysing these models I realised: they don’t tell yo what to do. The models describe businesses strategies but they are pretty useless at telling you which one is right for your business today.

You could add in Porter’s Five Forces Model but even when you do this there is no advice on what you could do. Because I believe Patterns should help you decide what to do I deliberately moved away form this approach and have not included these Patterns.

So there you go, I am sure that many, if not all, the 36 patterns in Business Patterns for Software Developers are applicable outside of software but I leave it as an exercise to the reader to make the necessary additions.

Business Patterns for Software Developers

On Wednesday night I was in Edinburgh to speak to the local BCS group - I’m sure you remember the British Computer Society, that no longer exists, this was the Charted Institute for IT which just happens to be known as The BCS (obvious really). Anyway, I digress….

I was there to talk about the software business, or more specifically, patterns of software business…. OK, I admit it, I was there to plug my book Business Patterns for Software Developers - sales are going well, although I can always do with more and a few more reviews on Amazon would be well received.

The presentation itself can be downloaded from my website - Business Patterns for Software Developers - or viewed on Slideshare. There must have been 30 or so people there and the presentation was well received.

After the presentation there were several interesting questions which, time allowing, I’d like to reprise in this blog in the coming weeks. Right now I’ll stick to one question and answer.

One of these questions concerned the book’s title: Business Patterns for Software Developers. Someone said they had expected something more technical and they were a little confused by the title. Well, let me explain….

The choice of title was a little complicated. Partly because over the years the name “Business Patterns” has been used by some to refer to code level patterns. Lets be clear - BSP, as I call it for short, doesn’t contain any code.

(I call it BSP because the earliest drafts were entitled Business Strategy Patterns - have a look at the early patterns on my website. Over time I focused the patterns more and more on the domain I know best, software development.)

The title reflects two things - both of which are in the second half “Software Developers.” Firstly I am using the term “Software Developers” in the broadest sense, I am including anyone, or any organisation that creates software. Indeed, one of the earlier versions had the title as “Business Patterns for Software Creators” but that was felt to be a little vague.

Second, when I was writing the book I tried to imagine the reader. Who was going to read this book? What did they look like? Where did they come from?

The people I imagined were code-face hands on developers. People like the members of the ACCU. People who spent most days building someone else’s system and dreamed of building their own product someday. Some of these folk wake up one day and realise that they now hold a management position and they need to understand the business they are in.

In other words I segmented my market. I had personas for my readers. And yes, I imagined specific individuals reading this book. I won’t name them, I don’t want it to go to their heads, I’ll let them guess.

Actually, one person I will name: my younger self. In many ways the developer I was imaging was the younger me, the me that used to - sometimes still does - dream of creating a best selling software application.

Dialogue Sheets - Maro, where are you?

For the last few weeks there has been something wrong with the blogger commenting system. Comments get posted but when I come to moderate them there are missing.

Unfortunately this happened with a really good comment from Maro at Thales in Argentina. Maro also posted as Anonymous so I can’t contact him back - Maro are you there? Please contract me!

Maro’s team had been trying my Dialogue Sheets, I think they may have translated one themselves, although we now have one Dialogue Sheet available as a Spanish translation. He has posted his experiences on a blog, DosIdeas - in Spanish but Google will translate.

He also tells me that his team have developed another facilitator less retrospective technique using index cards. I’m looking forward to hearing more about this.