Hi everyone,
Later this month I will run a 2 day "Agile" workshop in Edinburgh for the owners and managers of everyday software-development organisations.
Note: this is about the business side of agile – selling* and delivering custom-built software for profit - it is not a technical course.
If you know of anyone who might be interested in this workshop then can you please forward it on to them?
Thanks,
Clarke
* I will be running a version fo this course which has been designed specifically for IT departments later in the summer.
Everyday Agile: Using agile to make LOADS more money in everyday businesses
Course Summary: How everyday businesses, using everyday technology, employing everyday staff, can deliver LOADS more software development projects and make LOADS more money by doing just-enough agile.
This course is for anyone who currently develops software successfully using the old ways ... but want to do it LOADS better.
I've designed this course for people who are missing out on the benefits of Agile because they think it is too hard or that it won't work in their organisation. It really bothers me that as Agile keeps getting better and better, it also keeps getting bigger and bigger. This is great news if you're a practitioner, but if you're new to Agile, evaluating it, then it looks complicated, confusing and daunting. It looks like you need to employ rocket scientists but you don't.
A lot of businesses miss out because agile looks far harder than it needs to.
This course is an easy introduction to Agile where the goal of the course is to get you profiting from agile quickly. You'll soon be delivering better quality software projects, in far less time and delighting your customers too.
Selling Agile Projects:
Most importantly: the course covers not only how to do "just enough" agile, but also how to sell it to your customers. This is important because once you start doing agile you will deliver each project in between 50% and 80% of the time it used to take you, using the same number of staff. If each project takes, say, 33% less time to deliver than before (which is likely), then you've effectively gained 50% more capacity without employing any new staff. If you want to realise the full benefits of Agile then you'll need to figure out how to sell that extra capacity.
The problem is that you don't (or shouldn't) sell agile projects in the same way as you normally do. Agile is better for your customers - they'll get the software they want (not what they asked for) it'll be better quality, and they'll get it far sooner - but you'll have to sell it to them differently. Why?
First, you're producing software which is worth more to them than what you are currently delivering but … it costs you less for your to produce it (because it takes considerably less man-days per project). If you currently sell on a daily rate basis and continue to do so then you'll make less money per project. You may choose to lower your prices and risk a price war … or you may chose to sell your projects based on the improved value to your customer, not your cost. You'll discover during the course that the Agile model comes pre-built with a very effective means of avoiding most price objections. We will adapt your current offer further (using the SPIN Selling model) so you sells the benefits of your new approach at higher margins.
Second, in order for your customers to get the most value from you, you'll have to teach them to work with you COLLABORATIVELY, rather than contractually (or even adversarially). You need to create the collaborative working relationship during the sales negotiations, not after.
We will cover both of these aspects - probably the hardest, and most overlooked, parts of any agile implementation - during the workshop.
Introducing EverydayAgile:
For the last 4 years I've been developing a simplified version of Agile which works anywhere. It's the Agile I write about - but don't name - in my book. I call it EverydayAgile because it is specifically designed for everyday people who work in everyday organisations. It is entirely technology agnostic - I've used it with COBOL and with JAVA, for instance, and the principles are identical. I've taken the 20% of Agile practices which gives you 80% of the (financial and social) results, revved them up with Lean and Theory of Constraints practices and packaged them up to give a very fast, yet simple, version of Agile which works anywhere.
So, you get yourself running with EverydayAGile and then once things are running smoothly you'll be in a good position to start experimenting with some of the more technical agile practices. You'll continue to get better and more profitable.
After attending the workshop you will be ready to:
- Explain both the business and the technical aspects of Agile software development to your colleagues, including why it is way more profitable for your business and for your customers and why it is more enjoyable for your development team.
- Sell your first EverydayAgile project to one of your customers using the compelling offer you prepared during the course;
- Deliver your first EverydayAgile project, using the approach taught in the course.
Making Agile stick: the money side
Earlier this year a colleague and I did a "therapy" session with a small software development company where the technical staff were slowly bankrupting their company in the name of technical "agile" perfection. They were following all the rules they'd read about in some agile book but they couldn't produce code that was technically pure enough for them to ship. The owner of the business was devastated because he couldn't invoice, his customers were leaving him and he didn't know how he was going to pay his staff their wages. I imagine the author of the agile book would have been horrified.
If you go down the agile road then you've got to make it a blatant financial success in order for it to stick.
Here's the example (which I've tried to make as simple, fair and representative as possible but I don't know your numbers. Why don't you try it with your own numbers? What kind of productivity improvement would you need to achieve to double your profits?)
Imagine a small software development company which pays their development staff £300,000 a year, has £75,000 in other costs, and earns £500,000. What's their profit? £125,000. Now imagine that this company found a way of preventing expensive rework – i.e. by using agile – which meant that they finish every project in two-thirds of the time they normally take. If you've seen agile in action then you'll know that this is a reasonable saving and many projects will finish sooner. How does this affect their profits?
If each project takes only two-thirds of the previous effort then that amounts to a … 50% increase in capacity. Does that surprise you? It surprised me when I first figured it out a few years ago – I still double check the numbers. This company can now do 18 months worth of projects in a year. That's not bad. Now let's say they keep their prices the same (their sales folk need a kick in the butt for not figuring out how to charge more – we'll cover this in the course) and they managed to sell half of the new found capacity. That is another £125,000 cash flowing into their bank accounts and their new annual revenue figure is £625,000.
But what's happened to their profits? Their costs haven't changed (let's assume they didn't need to hire another sales person to sell the extra capacity) so their annual profit has risen to £250,000 (£625,000 - £375, 000). That's double their previous profit of £125,000. (And they still have a lot of spare capacity left to do even better.)
They could also have doubled their profits if they finished their projects in 80% of the time and sold all of the extra 25% capacity that generated. All but the most negligently run agile projects can achieve that.
Details
The course will be held in Edinburgh City Centre on the 27th and 28th of May and it will be limited to the first 8 people who sign-up. It is specifically aimed at businesses which develop custom code for external customers*. The 2 day course costs £800+vat for the first person from each company (i.e. well less than 3 days worth of contract Java code) and £700+vat each for the second and third. If, after the first morning, you decide that it's not going to work for you then feel free to head back to the office and I will happily refund your fees in full.
Email me at clarke.ching@spiceUpIT.com if you'd like to know more.
If you know of anyone who might be interested in this workshop but isn't already making more money from "agile" then can you please forward it on to them?
Clarke Ching
079 2011 4893
* I will be running a different course for IT departments later in the summer.