Tag

Agile software development

WHY ?

By | Agile, Communication, Customers, Development, Disruption, Lean, People, Strategy | No Comments

At various times I’ve heard Fiona, Nigel and myself telling people “If you only adopt one Agile practice make it the retrospectives” … But why ?

The boards are useful, but they are really just give you a prompt when you talk at your stand ups, and those are just an efficient way to make sure everyone is communicating.  While the demos and showcases give some social incentive to produce real things and check your progress over a useful timeframe (weeks not months or years).  But … The retrospectives (or reviews), that for me is where the real magic happens.  If you never stop to check, to ask how things are going and question why things are the way they are, why you are doing things and what you should do next in response then you risk having  the veneer of an Agile process which is either just micromanagement on the wall, Waterfall or perhaps worst of all, no real plan at all.

Being Agile isn’t enough.  Being Lean isn’t enough.

It’s all to easy to build and do the wrong things very well and very quickly using these techniques.  Perhaps the single most important thing is that your CEO, your leaders, your product people and you need to understand, ask and articulate is WHY you’re doing things.

If it’s a statement about profit and growth, start running. The powerful WHYs come from passion and insights from your customer (or potential customers if you’re doing something new).

WHY –> WHAT –> HOW … Simon Sinek

There are two standout statements in Simon’s TED talk.

“People don’t buy what you do, they buy WHY you do it.”

“There are leaders and there are those that lead. Leaders hold a position of power or authority, but those who lead – inspire us. We follow those who lead not because we have to but because we want to, we follow those who lead not for them but for ourselves.”

Too many companies and individuals talk about what they are doing, the great ones talk about why.

YOW! 2011 Australia Conference – something for everyone, even the economists!

By | Agile, Development, Lean, Space, Technology | No Comments

As the lunatics in charge of the Luna Tractor, James and I are fortunate to spend time with the 25% of Australian agile professionals who actually give a shit, who we often meet at industry conferences. The smarter among you will have realised I’m rudely suggesting  that 75% of so called ‘agile professionals’ don’t actually give a shit, which sounds harsh until you hear my benchmark number for traditional business people (waterfallers, 5 Year Planners, CMD+CTRL freaks) who give a shit – more like 1/100 or 1%. Maybe in some cases 0.1%, depending on the institution.

The British cabinet war rooms - agile wall, all the comms you need, the right people in the room, iterating by the hour in 1936.

Economics lesson aside, being invited to YOW! 2011 to present was a real highlight for us. James and I gave a 45 minute talk on the history of coincidentally agile-like practices over the past century, and how they have contributed to some great innovations (particularly in the engineering and space fields, our favourites), as well as some Class A ass-saving.

YOW is reputed to be a developer-centric affair, with a speaker roster even including several actual inventors of famous programming languages (check out the superstar roster here), so as the resident economist I was fairly nerve wracked! Should non-developers even go to YOW? Is it just too geeky and engineering focused? My experience is absolutely yes, you MUST go to YOW – per Martin Fowler‘s signoff at Agile Australia 2011, we are all complicit in software development now, and gathering an understanding of that craft is vital.

A speaker like Mike Lee might go over your head if you are not an engineer for 5% of the time, but he chooses to focus as much on issues like learning and intellectual property protection as development language choice (and he is damned funny while he’s at it). Someone like Kevin O’Neill from Melbourne prides himself on keeping it comprehensible for everyone, without losing the pointy stuff, and the joy of invention and discovery. The big kahunas like Simon Peyton Jones are talking as much about the history, sociology and philosophy of software engineering as they are lines of code. Meanwhile the Linda Risings and Mary Poppendiecks are there for everyone to learn from.

You can easily pick a path through the YOW! program that takes in the more social and cultural side of software engineering and working in teams (these are passions for organiser and founder Dave Thomas) as well as some more general interest code and development talks, and if ever there was an environment where it is safe for non-coders to ask dumb questions – it’s YOW!

It’s actually the developers who need to worry about their reputation in front of their peers – just say “hey, I’m not an developer, but I’d love to learn how that works in simple terms so I can understand…” and you will have an erudite, clear answer in no time.

Good software engineers love their work, and want other people to love it too.

We’d also love to see a few more software developers and testers at Agile Australia 2012 in Melbourne at the end of May, joining the lively community of product managers, agile coaches, lean gurus, analysts, iteration managers, project managers, thinkers, vendors and practitioners who gather there each year.

A great example of our agile community’s need to think more holistically was raised by Mary Poppendieck and Linda Rising at YOW, who both called  “bullshit” on agile’s current obsession with teams of 7 +/-2 people (read devs, testers and a scrum master) as ‘optimal’, when organisations that deliver products to end customers clearly involve everyone from the person on the phone to customers at the front desk, all the way to the intern. Teams of 30-70 are way more normal and work just fine, so stop obsessing about your tiny team at standup being the whole agile gang. That mirrors our experience at Lonely Planet for sure.

If you didn’t manage to get to YOW! in 2011, or as always seems to happen, were forced to choose between sessions, the majority of the papers are up on the site, and most of the presentations were video recorded – check out the YOW Eventer website put together by the Cogent crew in Melbourne for the video over the next days – there’s a couple up already including ours.

Craig Smith with Mary Poppendieck at YOW 2011 Brisbane - the gold standard 'hard act to follow' at a conference

A copy of our slides (with still images replacing the video we showed in Melbourne and Brisbane) can be viewed online here: Luna Tractor YOW 2011 Decades of Agile

YOW! is a multi-media affair, so naturally there’s a podcast – produced by two of the Australian agile community’s bright young things, Craig Smith (who blogs here when not

Breakfast at Brew Cafe in Brisbane - sensational

coaching and inspiring agilists) and Renee Troughton (who has a great site called The Agile Forest). This was done in a fab (very Lonely Planet) little cafe called Brew in Brisbane, so the background noise is fairly busy, and we discussed (I suspect that should read ‘Nigel talked about’ – Ed. JP) a vast range of topics around agile, Lonely Planet, consulting and change.

You can listen to that podcast here, and of course it’s available on iTunes: http://www.theagilerevolution.com/episode-19-luna-tractor-with-nigel-dalton

My very best impression of the French gallic shrug - perhaps in reponse to Charles' line of questioning on whether Microsoft could be agile 😉

And finally on the media front, Microsoft’s Channel 9 conducted interviews of many of the speakers at the conference.

You’ll find them all on their prolific and rich tech-focused website, while my own epic 30 minutes of righteous crapping on about everything agile, Lonely Planet, and offering unqualified advice to Microsoft about becoming agile can be accessed right here.

See you all next year.

Luna BAHA Award nominee #1: “Implementing Scrum in your project will certainly be a cakewalk after this training”

By | Agile, People | 2 Comments

Picture credit: Dan Abramson

We’d like to present our first nominee for the Newt Gingrich ‘Lunar Colony 2020’ bullshit agile hubris award (the Luna BAHA).

Ed Cortis, the lucky recipient of the email below, is CIO at Lonely Planet, and has a pretty decent knowledge of how  challenging it is to upgrade from the organisational equivalent of Microsoft Windows 3.11 (using commands to control!) to a more Mac OSX agile-like culture – for 4 years he built and ran Lonely Planet’s agile – ITIL – DevOps operational teams, before taking over technology overall in 2011. It is an organisational transition that not many people pull off – but once an Apple agile convert, you’ll never go back.

Ed consequently knows a fair bit about Scrum, plus XP and even Kanban, and the resulting hybrids that the couple of dozen teams at LP now use every day to get things done.

It wasn’t the email’s bizarre spelling and grammar, or the screwy mail-merge that started it off with ‘Dear Cortis’ that sent the numb feeling to Ed’s legs – it was the suspicion that within Australian business’s desperately scrambling to ‘see their business grow at an amazing pace like never before’, too many IT departments would fall for an email like this and leap on the vendor’s international Scrum certification bandwagon, believing the hyperbole. I mean, they’ve got Mike Beedle, world-renowned Scrum guy!

I can hear it now – “Off you go to training, and then come back to make us live by the values and practices of agile please!” As we say in NZ – “yeah right”. It would be a funny joke, if it weren’t horribly true.

Are we being too literal, harsh and grumpy? You decide:

Oddly the  main benefits quoted are about you getting a certificate, not a team successfully transforming to a top agile modus operandi. Resume driven development then.

So sorry to disappoint anyone, but:
a) The simple task of ‘just getting rid of conventional ways of working’ will take most of the organisation to change their ways, and that won’t come with this certificate;
b) Implementing Scrum in your project will never be a cakewalk, no matter how many credits you collect, or exams you pass; and
c) Once you’ve finally grasped that, and you’re certain Scrum is the one for you, why not just club together the cash you and your mates might have dropped on a certificate each, and get someone like Kane Mar at Scrumology, Martin Kearns at SMS-Renewtek, or Sandy Mamoli in NZ (or plenty of other good local people) to show you hands-on how Scrum actually works on an actual business or product problem you have.

Hell, they even do certification training, but I don’t think you’ll find them ever promising a cakewalk.

A moon walk maybe…

Eating our own Dog Food

By | Agile, Development | No Comments

Some Luna friends, Horsham Colour – or I should say now HC Pro – are one of the largest professional photographic labs in Australia, situated in the charming country town of Horsham in the middle of the wheat belt of western Victoria.  Their business is as a high volume, but still very high quality, photographic and print production house.

As a generation of wedding and portrait photographers grow old and retire, a new generation of photographers and products have grown in their place.  Customers no longer just want prints in frames, but albums, cards, books, canvas and prints bonded onto metal etc.  Enabling photographers to understand and order such a wide range of products online has been a goal for the lab for some time.

hcpro.com – a new website which describes the lab, their products and the online ordering process – has just gone online with a bunch of hard work from the guys in Horsham, Grant Bisset at www.speakinteractive.com and ourselves at Luna Tractor.

We extol to teams the virtue of actually using their own products and processes… to eat their own dog food.  With this web project we took exactly the same approach we would recommend to others, ourselves.

We started with a brain storming and culling exercise to decide what the  minimal viable product was – which messages we had to communicate to give us focus.  Working through three areas:

  • Brand – What people remember.
  • Content – What people learn.
  • Action – What people do.

With each of those three areas defined as 2 or 3 easy to understand anchors we went away and designed a simple site. From there we made basic, hand drawn wireframes.

Next we drew up a rough content plan based on the wireframes and started to flesh it out by doing the product photography and copy writing. Over about a week we continually updated our content ‘board’ until we were happy with how it was sitting.

Ready now for construction, Grant did some work on the build in short cycles with Michael (from HC Pro) and I engaged in a review and then tasks to create missing pieces of content.   Having the whole website as a visual picture on the wall made it easier to choose images that conveyed the story we needed to tell,  quality and careful made products.  It also showed us what was missing, and we could put in place holders which served as our to do list, and a kind of burn down chart. Building a very small site (which is really only a version 1.0) made it easier to get quick feedback from potential customers.  From here we’ll listen to what real life customers say, how they use the site from the stats, and phone them to ask why.

The end result is a surprisingly small and simple site, just what we were aiming for.  It never ceased to surprise me how often our solution to problems was simply to remove content, text or extra ‘fluff’ which we had designed in but wasn’t answering one of our core Brand, Content or Action goals.  Check out the site and let us know what you think.

Before:

After:

Reflections on Agile in Australia

By | Uncategorized | No Comments

James and I were both on the roster of speakers at Agile Australia 2011 this year. There were some great presentations over the 2 days, the highlight for me being Martin Fowler’s closing address on the profession of software development in the 21st century. His point was simply “we are ALL software development companies now, so you need to understand some technology basics”.

It resonated for me having led the charge over 4+ years on the journey from Lonely Planet proudly proclaiming it was “not a technology company” in 2007 (thus they’d seemingly outsourced everything that had a green LED light on it) to one where our digital and publishing businesses both revel in having high levels of technology competency on the teams.

If you have not heard Martin talk about technical debt, software complexity and development abandon this blog immediately and read these 3 blog posts:

Martin Fowler of Thoughtworks delivers the final address.

Technical Debt 101

Technical Debt quadrant diagram

The design payoff line (aka the line of regret)

Having attended Agile Australia for the last 3 years, I was amazed to see the change in the profile of people attending, and how rapidly agile is taking hold in Australia.

The plaintiff cry was pretty much “we’ve been doing agile for a year now, but we still feel the pull of gravity back to the world of 5 year plans, business cases and large teams working on projects where the design is done up front – why is agile such hard work? It’s not fair!”

That matches our own experience at Lonely Planet – year 2 can be pretty agonising as some team members lose the faith (having suffered a failure or two); a lot of ‘hiding Harrys’ have their shortcomings at prioritising product features and joining the dots at standup every day exposed; the scrum zombies get a foothold; and in our case, romantic memories were revived by finance of life under waterfall governance being somehow more certain in its outcomes. “Certain to fail” I was forced to point out at times, pulling out our $6m clock.

My advice? With stakeholders, stop talking about agile and start talking Lean at this point. Focus on measuring value, eliminating waste, improving flow of work, building what the customer has pulled, and speed of delivering to customers. Talk about ‘time to cash’ and start measuring customer outcomes. Put those metrics up on the board alongside the points delivered and burn down charts. Focus and talk about being great, not being agile.

James Pierce

James spoke on the subject of agile workspaces – a topic on which there is very little written. A lot of dangerous fallacies exist about open plan offices that can impinge the success of any transition to agile working methods. It is not all about rows of desks with paired programmers yammering away to each other – you need carefully designed quiet spaces and well thought-out dynamics. From the level of questions that ensued, this is a topic that needs further expansion.

Nigel Dalton

I presented a series of case studies on agile product development – using examples of a number of Lonely Planet stories where things had not gone as planned, and linking those results back to where we overlooked some key agile principles like customer input, releasing early and testing.

I was delighted to score tweet of the day with my flippant “every time you draw a gantt chart a fairy dies”.

Jean Tabaka provided Day 2’s opening with a stern reminder that the agile community has its destiny in its own hands, and essentially should stop whining and start building. That means all of us!

The Truth about DevOps

By | Development

DevOps seems to be the new cool kid on the block lately, especially in Agile circles.  New user groups are popping up and it’s a fashionable topic to talk about at conferences; Many of the more leading edge consultancies are working hard to establish themselves as having creditable practices in the space.  Right now DevOps feels like Agile did 10 years ago.

Here’s the first paragraph from the top hit in google, it is of course from Wikipedia …

“DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for development (applications/software engineering), technology operations and quality assurance (QA)”

… and it’s 100% wrong. DevOps isn’t a process; Unlike Agile, DevOps doesn’t have a neat set of rituals to build the habits and enable the right communication and feedback cycles – perhaps we need to invent some.  There are definitely some things like co-location which help, and getting everyone coming along to one daily standup isn’t going to hurt. But, you can do those things and fail to create DevOps.

Here’s another thing it’s not, Continuous Deployment.  Releasing your software regularly and having an automated build and testing pipeline is another good process, it creates good habits and it does create closer ties between your developers and your ops group; But it’s not essential to DevOps and it doesn’t ensure you’ll have DevOps.

So here’s what it really is:

  • Developers caring about deployment and production systems.
  • Ops caring about the development of new features.
  • Developers with access to production systems, monitoring and deployment processes.
  • Ops engaged with feature development from the start.

It’s about creating a team of engineers, rather than a team of developers and a team of operations folks.

DevOps is just a neat new word to describe how little companies have managed their development and deployment for years – If you don’t have many people and you don’t have lots of departments then your developers get involved in deployments, and if you’re lucky enough to have a dedicated ops person then you can be sure they will be working with the development team as well, usually on the database and back end parts of your system. In bigger companies it’s not as simple, bigger systems mean more complex platforms, more sophisticated network configurations and database clusters.  As projects get bigger it’s only natural, even essential that within your engineering team there are specialist roles.  UI/UX specialists, back end, API and model specialists and DevOps is about engaging staff who would have previously been part of your ops team.

Just like Agile, DevOps means taking a leap of faith and seeing how things work out.  Here’s how to start, get a developer to sit and type all the commands to deploy one of your system with an ops person looking over their shoulder – I promise you they will be coming up with ways to automate your deployment by the end of the day.  Next time you have a performance problem, get your ops folks to pair with the developer working on it, matching up data from your system logs and monitoring system with the active code.
Just today I enjoyed watching a ‘developer’ and an ‘admin’ working together to shave 20% off the run time of our full test suite in 30 min just by building a shared understanding of what was required and tuning the platform together.

“‘Devops’ is a movement of like-minded sysadmins and developers interested in bridging the artificial gap between our camps. It’s impossible for sysadmins to do their job without reading or writing code, and developers need intimate systems knowledge to scale their software.

The walls between us are being broken down — it’s time to start learning from each other.” – www.devopsdownunder.org

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

By | Agile | 2 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.

Subscribe to the Luna Newsletter

Quote of the week

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

Recent Luna Posts

Become Remarkable.