Skip to main content

Six things you should ask yourself before you adopt agile practices

1. Who cares?

Who wants it? Is your customer asking for a more agile approach? Is Agile the latest flavour sweeping the floor? Has someone new arrived in your department with fancy ideas? It’s always a good idea to collect together, bat around the topic, share experiences positive and negative. Identify the like-minded people who are going to support this kind of change. It’s a people-change as well as process so you will need your pals.

2. What will your development teams tolerate?

Do you have agile fans in the development team, or active doubters? Architects can find it very threatening to advocate not doing big upfront design. Some developers simply loathe the idea of pairing on code. IT teams are densely populated with introverts and some find daily stand-ups and high levels of collaboration with business people too confronting. Happily these issues can often evaporate over time, but I have witnessed quite a lot of resistance to agile practices from development teams so it’s very wise to tread carefully and not mandate wholesale process change without buy-in.

3. Are you trying to fix something?

Can you see an issue you believe can be addressed by ‘going agile’? Do you have poor business engagement? Do you do endless mopping up work in the form of changes after a project is delivered? Are your business solutions not fit for purpose? These issues may well benefit by using a more agile approach to development but beware if you think a methodology in itself can cure all ills. Issues of this nature should be addressed irrespectively. Agile can be useful in opening a door to these conversations.

4. Does your technology ‘stack’ up?

Can you use agile development practices on your current technology platform? I’ve seen teams struggle with this on legacy systems, trying to force development practices into a code base that seems to hate it. I believe you can even go backwards attempting this. Using an agile approach to prioritise manage and deliver scope (requirements) without utilising continuous integration or TDD can still give you a lot of benefit, consider this if you are not building a nice green field application, or if you are building with a language that is not agile development practice friendly.

5. Do you know what you are doing?

Consider a coach. Agile coaches are out there, not only have they been on and run agile projects before, they’ve also made the mistakes that you will make before. That’s already a compelling reason to use one. Here’s another one; using an external coach is more palatable then telling your business users “we don’t really have a clue, but agile seems like a good idea so we will plunge in and give it a go!” For some reason organisations like to hear the opinion of outside experts rather than trusting the opinions of experts already on the payroll. Agile practices first came about by people on projects seeking better ways to do things, not by a bunch of expensive consultants having an off-site think tank on how to be agile. You can try it yourself using literature and countless web-documented experiences, but it’s likely to be more painful and take longer than using a coach.

Here’s another great reason – a coach can be objective.
Another – they can pass on the skills to allow you to stand on your own feet.

6. Who’s going to ride the wild horses?

Who is going to support you when you encounter the first obstacle? What if your agile project uncovers a bunch of scope that doubles your project in the first few weeks? What if you realise you need an extra BA to feed the team with enough work to keep them on track? You need to foster some heavy weight support within your business community as well as the development department. You need some champions for the agile cause, with the mettle to stand by you in troubled times.


Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …