How to stop avoiding agile in your business

How to stop avoiding agile in your business

How to stop avoiding agile in your business

0 comments 📅17 September 2013, 02:45

How to stop avoiding agile in your business

I have used agile methodology to manage many software and transformation projects to deliver on time, on budget with great results, and while I firmly believe that any team can become agile, I understand why agile can be difficult to adopt. Many of the challenges are caused by a mix of habit and psychology, and here’s how you can overcome them with minimum difficulty.

1)  What specific culture are we trying to move away from?

I said that almost any team can become agile, and part of that involves being aware of what we need to move away from. Your team can’t become agile while the organisation is so inflexible that you aren’t allowed to adopt the flexible, adaptive approach that agile is all about. There are a few specific warning signs:

  • Territorial behaviour and a refusal to share information, or to accept anything that came from outside the silo, prevent the development of new behaviours that all stakeholders need to learn
  • Inflexibility around corporate policies: whether it’s a “if it’s not authorised, it’s banned” or “this is what we’ve always done”; this prevents people who are otherwise willing to engage with agile from doing so
  • Unhappiness with uncertainty can cause problems because agile rarely confirms an end date or what features will be delivered next.
  • Not treating developers as intelligent, independent people is a common problem because traditional organisations saw a pool of essentially identical developers who need to have important decisions made for them
  • Insist development is linear in the traditional “waterfall” method which makes it very hard for information to flow back “uphill”, or from users back to developers: constant feedback is one of the strengths of agile but it can be a culture shock.

None of these are insurmountable, but making a real change can require very strong support from the highest levels of management, along with hands-on commitment to developing new behaviours.

2)  How to explain the basics of an agile approach?

One of the trickiest concepts in agile is that while there are many methodologies (Scrum, XP, Kanban, TDD, BDD, Continuous Integration and so on), these aren’t agile in themselves. You’re not agile just because you’re following the methodologies, and likewise you could be agile without knowing anything about them.

Agile is a mindset, and it’s been very aptly likened to theatrical improvisation.

Agile is all about moving forward together, rather than worrying about the direction you’re moving in. As they say, “no plan survives contact with the enemy”, so while you may have a good idea of what you’re trying to achieve, continuous iterations and feedback can, will, and are meant to change the outcome. That’s what agile is all about: collaboratively figuring out what you need and building it together.

3)  How can we tell if we’re doing it “right”?

Following on from the previous point, agile is a framework for improvisation around software development, and ultimately there’s no “right way” beyond what works for you. On the other hand, there are methodologies like Scrum, Kanban, TDD, BDD, XP and more, and these are certainly useful models to follow which can help.

Because agile can be used on so many levels and degrees of competency, (and can be restrictive or freeform as a result) it’s important to really understand that experience can make a difference in how we interact with it.

In any activity, there are degrees of competency that translate neatly to ways of working. For example, in any activity, the vast majority of people can be categorised as either complete or advanced beginners. That’s not to say they aren’t good at their jobs; it means that they hold closely to the established rules because they know these will work. An advanced beginner can muddle through but they don’t have the understanding of the big picture to develop their own conceptual models: the big challenge is making that jump to being a competent user.

The difference between them is in understanding that agile is a culture rather than a process. As the original agile manifesto put it:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Therefore, you’re doing Agile properly if you’re trying to use these principles in your work.

4)  The importance of clarification

There is a classic fallacy in project management: “the mythical man-month”, as Frederick Brooks puts it. This fallacy leads to logical conclusions that nine women can have a baby in one month, or that you can calculate how long you will take to eat an elephant without considering how many friends and how much Tupperware will be involved.

The problem in these cases is that the problems can’t be broken down neatly: the activity isn’t linear. In the case of a software project, you might ask whether bringing in a second developer will reduce the time to code the project. It might, but you need to factor in the “ramp-up time” that developer will need in order to get up to speed with what’s going on, and similar factors.

This is another agile element that needs to be addressed by all participants. Developers need to become comfortable asking “why?” when faced with big challenges rather than getting excited by the challenge and leaping into it. Meanwhile customers and managers need to think deeply about the “why?” questions in order to work with the developers to puzzle out what outcome they really need and how it can be achieved.

Sometimes you will find there’s no real knowledge of why a particular feature has been requested (so how can you be sure it works?) and other times asking “why?” will unearth some very different requirements or an easier way of delivering.

By clarifying the requirements around complex projects you ensure that everyone is working toward the same goals and understands the project. Best of all, you might avoid the dreaded tree-swing diagrams.

No Comments

No Comments Yet!

You can be first one to write a comment

Leave a comment