Skip to main content
Category

Agile

Top 10 agile and lean resources

By Agile, Lean, linksOne Comment

I’ve just written a friend an email with our curated list of resources to inspire teams to start working in a more modern way.

Looking at it, I think it makes a half decent blog post – so here it is!

Passion for customers: you can’t beat Seth Godin. I recommend 2 books – Meatball Sundae which will tell you why you need to think differently to amaze your customers in a digital world; and The Purple Cow for becoming remarkable (as opposed to perfect).

Passion for people: Dan Pink (motivating knowledge workers through autonomy, mastery and purpose) is the king here, though Simon Sinek (emphasising the ‘why’) is a close second. Luckily, YouTube is your friend here.

Agile product development: Steve Blank is the guru here, but being a Stanford lecturer his writing can seem a little impenetrable at times. Two of his students wrote this book which makes far more sense and gets to the point quickly: http://www.custdev.com/ also available on Amazon.

Lean startups: Eric Ries has some great ideas for people starting out, whether they are a real startup or just starting something new in an old world organisation: see some basic slides here, and his upcoming book (due September 2011).

Testing your ideas and products with real people: at Lonely Planet, applying the lessons in this book is how we started to seriously find out things about our digital products that we never knew before: http://www.amazon.com/Rocket-Surgery-Made-Easy-Yourself/dp/0321657292

There is a great online service mentioned in the back of the book that removes all barriers to you trying this approach of asking real customers what they think about your product or service, for about $35. No excuses! http://www.usertesting.com/

Lean as a new way of thinking: one great book, covering Toyota’s development of lean manufacturing (the parent of agile) is Jeff Liker’s book The Toyota Way. It gives you the basic premises of running a lean business with lots of examples.

If the nerdy tech stuff starts to fascinate you, then it’s hard to beat James Shore’s primer on agile software development. Any deeper than that then Martin Fowler’s blog is compulsory reading: http://martinfowler.com/

You’ll impress the pants off people if you can comprehend and quote from these principles: http://agilemanifesto.org/ and http://agilemanifesto.org/principles.html

Getting things done fast: no better book (or easier read) than Rework by 37 Signals. This puts a lot of the principles above into practice, and if you only read one book, this might be it.

And lastly, from a cultural and organizational change perspective, this is a toolset you should plan on using with your teams: http://www.human-synergistics.com.au/ plus they have a free conference in Melbourne later in the year that people should really try to find a way of getting to.

Working in an Agile way will change habits, and with careful planning those changes in habits can start a landslide of cultural change.

Charles Darwin – agile 150 years ago

By AgileNo Comments

Darwin's journal from the Beagle voyage contains this diagram and the beginnings of a world-changing idea. Note the 'I think' at the top.

Working at Lonely Planet has taught James and me a lot of lessons about the publishing business – not the least of which is the chasm between the product lifecycles enjoyed by the average travel guidebook and the average digital guide.

A good guidebook, written by people who actually went to the place being written about, may take up to 2 years to hit the shelves – but with a useful life of another 2 years, it has a fair chance to pay the publisher back with sales over a long period. Basically, when that guidebook finally hits the shelves at Readings, the authors are back on the road.

Printed books are nearly impossible to revise – once the ink dries and the binding glue is set, it’s pretty much done – apart from the reprints – which are a bonus not often seen given careful planning for sales volumes. Earthquakes, regime changes, tsunamis, and recessions are the travel publisher’s nightmare. For publishers of longer lasting texts like novels, the discouragement to change is simply cost. Customer feedback be damned! And the author is likely to have moved onto the next project (very waterfall!).

Lonely Planet has been working (in a most agile fashion) on a new way of publishing guides. With Amazon now selling as many eBooks as paper books, the world of apps and digital texts has opened an opportunity to do things very differently.

But Lonely Planet is far from the first group of authors and publishers in the world to understand agility, continuous release processes and adapting to customer feedback. And a great example from 150 years ago is Charles Darwin’s Origin of the Species. As always, we’re not going to rewrite Wikipedia here, so we’ll focus on the agile bits.

1. Darwin was a practitioner of Toyota’s lean manufacturing principle of genchi genbutsu (roughly ‘go and see for yourself’)  – not the least of which was enduring a famous voyage on the Beagle from 1831 to 1836, where as botanist he was staggered to discover the world was not as the English experts had surmised.

2. There were many iterations of his theory researched, discussed and written before the idea was released. Darwin had a reasonably well-formed theory by 1838, but the book was held from public view until 1859. Darwin wanted it to be a great book, well-written and suited to a general reader. Quality takes time, and he had other projects he was working on in parallel – including the journals from the Beagle voyage, which were finished in 1854.

3. When the production release of Origin finally hit the bookshops, it was a conservative print run (about 1,200 copies for sale), designed to gauge initial customer reaction to a controversial topic. Within 8 weeks a 2nd edition was on the shelves, with a print run of 3,000. It went on to have 6 releases in total, and by the final edition in 1872, the book was selling 250 copies a month.

4. Darwin had no fear of adding content, deleting sections he was not happy with, and responding to reader’s questions and complaints. Ben Fry’s amazing infographic showing the evolution of the book can be viewed here at http://benfry.com/traces/

Although agile can sometimes seem like a missionary sale to large corporations, none of have suffered the public criticism leveled at Charles Darwin for his theories.

5. The most fascinating addition is the phrase ‘survival of the fittest’. Herbert Spencer, a philosopher who had published his book Principles of Biology in 1864 had coined the term, and Darwin felt it useful to comment at length on the concept (having coined his own term ‘natural selection’ to explain his theory), as well as responding to his critics in a whole new chapter. It is widely noted that Herbert Spencer’s other contribution to western civilisation was the paperclip – truly a great inventor!

It is this last point that seems most relevant to agile product and software development today – in particular the massive  misunderstanding that being the biggest, the strongest, the fastest, the wealthiest or the most aggressive will kill off the others and win the race. Darwin had only adopted the phrase so willingly because it better explained the impact of environmental pressure and competition on the rate of change of species.

As Darwin reputedly pointed out late in his life, when asked if he had any regrets, he conceded that the entire concept of the qualities needed to endure had been  misunderstood widely from that edition and the populist phrase ‘survival of the fittest’ onwards. What he had always meant, was that the species most adaptive to change would be the one that succeeded.

And that, is fundamentally agile. Think of Charles Darwin when you next write the agile tenet ‘embrace change‘ on a whiteboard somewhere.

When you should do nothing – maximising the performance of knowledge workers

By Agile, DevelopmentOne Comment

Most of the ideas we write about are well supported by research, leaders in software development and business or at the very least are well established as best practice.  Instead today I want to write about a personal theory of mine, which is still very much developing but I think is important enough to share.

The training program for nearly any serious athlete these days is planned around the ‘season’ of their chosen sport, then their most important events and they work back from that to ensure they are in ‘peak’ condition at the most important times of the season.  As they build up to these peaks their program will push them through a series of harder and harder training sessions, building up fatigue and forcing the body to adapt to support the increased stress (essentially driven by our fight or flight reflex).

The body doesn’t get stronger during the workouts though, it’s actually being stressed and broken down during these sessions.  When an athlete stops to rest, eat and sleep the body has a chance to rebuild and adapt; because of the stress it’s been under the body adapts and prepares for the next time by building strong, faster muscles, etc.

It seems logical then that the best approach is to steadily increase the training load each session and over time get stronger and stronger and stronger.  In practice this doesn’t work. Athletes stop improving, they burn out and become injured or sick from the constant stress they are placing their bodies under.  There are two things at play here.  The first is that by training hard enough to stress their body and cause the positive adaptation they are also building up a debt of fatigue which eventually becomes too much for the body to overcome causing sickness, injury and burnout.  The second is that due to the consistent pattern of stress the body adapts, the workouts may become a little easier, but the athlete improves more and more slowly.

Enter periodisation, a process developed in the Eastern Bloc countries and now widely adopted by athletes the world over.  With periodisation a year, the macrocycle, is broken into a series of blocks, often four week mesocycles which are then composed of a number of week long microcycles.  Each mesocycle will include week long microcycles of training (increased stress), and most importantly a microcycle of recovery.  This cyclical approach allows the athlete to stress their body, but also to have periods of recovery allowing their body to reach a new peak of performance as it rebuilds and sheds fatigue.  This new peak then feeds into the next cycle, allowing them to undertake more stress, train harder and over the macrocycle increase their performance to levels unobtainable by a stead state training program.

Now let’s turn our focus to an Agile software development process; the routine and rhythms of a sprint process remind me a lot of an athlete’s training microcycle.  Week in, week out we kick off the sprint, have daily stand-ups, write code, test code and have a demo and retro at the end of the sprint.  Then next sprint we do it all again.

A common pattern I’ve observed with teams who adopt Agile is that around the 3 month mark they start to loose faith.  At the start the buzz of something new, a different way of working and the rapid feedback and transparency let the team quickly improve their performance.  But after a while the sprint to sprint performance increases slow, or even stop, and yet the team is working just as hard each sprint.  Often times the team’s performance will even drop off as they grow weary of maintaing all the habits for no noticeable improvement.

Does this sound familiar to the earlier example from the athletes?

Why are intensely focused working groups (often conducted off site from your normal office) so productive and satisfying? If it works so well why don’t we work like that every day? Why is it that often the best ideas come at unexpected times, under the shower, out for a walk or on holidays for a week or two?  Why do software developers seem to work so intensely sometimes and yet spend so much time going around and around on a problem getting nowhere, or surfing the web and staring into space ?

I think these things are just examples of accidental periodisation by knowledge workers and my theory is that the human brain is just like the human body in the way it can be trained and leveraged for maximum performance.   While ad hoc training programs can work well for athletes a structured program will nearly always deliver a better, and more importantly consistent result.  My hypothesis is that these same principles of training apply to the human brain and there are lots of practical ways to apply this for knowledge workers but I’m already overtime on this post… so I’ll save those stories for another day.

“You can’t control what you can’t measure” – Tom DeMarco recants on his famous principle.

By Agile2 Comments

Tom DeMarco

Governance and funding of business investment using agile development methods are two hotly debated and misunderstood topics among the agile community.

With governance principles originally borrowed from the exacting fields of construction engineering and accounting, where things can often be calculated to 2 decimal places, it seems weird that we more often than not disappoint our customers by delivering a different result to that which was blueprinted or planned in software ‘engineering’.

Fred Brook’s 1975 treatise The Mythical Man Month was probably the first to hint at the

core differences between engineering a bridge versus the knowledge work of solving a problem by creating code. In the 20th anniversary edition he added an extra commentary entitled ‘No Silver Bullet’ in which he further reflected on the shortcomings of applying a mechanical engineering metaphor to software development. It is a must-read book for everyone involved in agile or lean development – and if you’ve read Clay Shirky‘s 2008 book Here Comes Everybody you’ll recognise some early sources of Clay’s work on complexity of organisations.

By the way Clay Shirky also has my favourite definition of governance – ‘rules for losing‘.

Fred aside, one of my greatest heroes of the software world is Tom DeMarco, who wrote the seminal text on project and engineering control called Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982). But this one is a book you probably do not want to own. Why? Well, approaching 70, Tom gives us the benefit of his time to reflect in the newsletter of the IEEE Computer Society in 2009, downloadable here:

http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

My favourite quote, which describes in a nutshell why measurement and management aren’t as closely linked as he surmised 27 years earlier:

“Imagine you’re trying to control a teenager’s upbringing. The very idea of controlling your child ought to make you at least a little bit queasy.

Yet the stakes for control couldn’t be higher… now apply “You can’t control what you can’t measure” to the teenager. Most things that really matter–honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyalty, humor, kindness–aren’t measurable.”

And a lot of product deliveries and projects I’ve been involved with acted way more like moody, irrational, changeable teenagers than respectable septuagenarians.

SDC Conference Agile Resources from @nxdnz Keynote

By AgileNo Comments

Monkeys, Hack Days and Nerf Guns: what can agile look like?

Software Education run an annual conference in both Wellington and Sydney that focuses on the changing role of Business Analysts in the agile sphere – a tricky and much debated topic. I had the honour of being invited to present a keynote at the official dinner where I wove together tales of life in an agile world at Lonely Planet, with some key lessons from commentators ranging from the 1970s to the present day. Plus shot Martyn with a nerf gun. Excellent evening indeed.

We will post the presentation and speaking notes in a separate post.

Key Reading and Resources

  1. From Gutenberg to Zuckerburg, Gus Balbontin from Lonely Planet presenting at O’Reilly Tools of Change, 2011
  2. The Innovator’s Dilemma, Clayton Christenson, 1997
  3. How Great Leaders Inspire Action, Simon Sinek at Ted, 2010
  4. Dan Pink on the Surprising Science of Motivation, Ted Talk, 2009
  5. Steve Blank on Customer Development (The Four Steps to the Epiphany)
  6. The Entrepreneur’s Guide to Customer Development, Brant Cooper and Patrick Vlaskovits, 2010
  7. Rocket Surgery Made Easy, Steve Krug, 2009
  8. Mythical Man Month, Fred Brooks, 1975
  9. Steve Hayes’ Blog on The End of Passion.

My thanks to a wonderfully receptive audience and our fine hosts Softed.

You are what you measure

By Agile, DevelopmentOne Comment

When you put a volt meter into an electrical circuit to measure the voltage difference between two points the internal resistance of the meter itself changes the circuit and impacts the reading. The best volt meters are designed to have very very high internal resistance, but in all circuits the resistance of the volt meter changes the circuit and impacts the measurement (circular yes!); in sensitive low voltage circuits where accuracy is most important the impact is greatest.

One of the agile development teams I’ve worked with decided that they would use the number of cards as their measure for planning, velocity and by implication productivity. Each iteration the cards from the last release were proudly pinned to the wall and counted. An interesting pattern emerged over a number of iterations: the number of bug cards completed went up, and up and up.

We spent a great deal of time trying to work out where our development, testing and release process was going wrong that we were seeing so many old bugs. Were we finding old issues with more thorough testing? Were the developers being lazy? Or was the work we were tackling just much tougher than previous projects? It turns out that the explanation was in fact very simple. Previously developers found and fixed bugs as part of their development tasks (this is quite normal), now they were writing these up as cards and running them across the board through the full prioritisation and QA process. Consciously or subconsciously the developers had been sent a signal that the number of cards was being measured, and thus they responded to and optimised their process to meet that benchmark. Issues which would have been fixed quickly while the developer was deep in their context now became tasks of their own, a much more expensive and unnecessary process.

Perhaps a better title for this post might be ‘Only measure what you truly wish for’. This is a topic which we’ll surely return to again and again, but I’ll leave you with a quote I write into the front of every one of my notebooks to remind me of a valuable truth.

“Not everything that counts can be counted, and not everything that can be counted counts.” – Albert Einstein.

Subscribe to the Luna Newsletter

Close Menu

Quote of the week

The new competitive advantage is the ability to anticipate, respond and adapt to change.

Recent Luna Posts

Become Remarkable.