Alistair Findlay

Software developer and agile enthusiast

Overcoming resistance to Agile Part 1: Just go for it!

In any business, changing deeply ingrained working practices can be a real challenge. As a developer you may want to employ agile working practices but meet resistance from other developers or managers in your company.

I myself have been through this process of overcoming resistance to agile methods and want to share my experience of managing the transistion in a series of blog posts:

  • Part 1: Just go for it! - making the first steps to better collaboration and planning work
  • Part 2: Admitting you're bad - having no ego, promising less and making progress more visible to others
  • Part 3: Making things better - refining the process and using tools to report progress back to business
  • Part 4: Do it all over again - Taking what you've learned to apply it to other projects and to spread the good word

Just go for it!

I believe that sometimes it's better to just do something and ask for forgiveness later rather than ask for permission first. It's easier for people to see something working or not working when you're actually doing it rather than debating it as part of an intellectual exercise.

My understanding of the resistance I was seeing to the agile methodology was that people didn't truly understand what it meant. It can be quite daunting to get a handle on what agile methods involve.

For me, the agile methodology is all about collaboration between people. From this simple idea all the benefits of agile methods follow, such as:

  • Sharing a common understandable goal that everyone is aiming for
  • Giving better visibility of what people are working on throughout the project
  • Enabling people to discuss both the work and the process itself so that both can be improved at any opportunity
  • Fitting the process around the people and the project
  • Making people happy and enthusiastic about participating in the project

First steps to better collaboration

To get people talking to each other in a productive way, it's effective to give people a focal point by using regular reviews:

  1. Start scheduling in fortnightly "review" sessions with as many people on the project as you can. Even if it's just two developers sitting round a computer and inspecting the code, this is a great start. Use the time to talk about what you achieved in the two weeks and what you will be working on in the next two weeks.
  2. In between the sessions, talk to each other. Talk about how you're getting along and if you need any help from each other. This shouldn't be just exclusive to developers either - talk to designers and testers if you can. Tell them about the sessions and invite them along. The more people you can get to come to the review sessions, the better.
  3. Eventually, try and formalise the review sessions with your manager. Book a meeting room with a projector (or video conference) and use the time to show demos of your work and start recording decisions about what you'll be working on next. Document it however you see fit.

At this point, the review sessions are almost enforcing a fortnightly sprint or timebox.

We can now start using these sprints as constraints which force better planning.

First steps to better planning

If you're working with waterfall methods then you most likely will have a requirements document.

Normally the requirements document is written up front but then inevitably goes out of date as the needs of the business change during the development phase. You may find that the review sessions start to highlight these required changes as the project progresses.

This is an ideal opportunity to start writing requirements in the form of user stories and use these as the currency in planning people's work (if you feel uncomfortable with introducing the term, “user stories” at this stage, then “requirements” is still fine):

  1. As an initial consideration, when writing the user story make sure that you don't end up writing something that is too large to achieve in a fortnightly sprint. It should be a small piece of functionality that will still give the user some value. In other words, a user story shouldn't describe an entire feature, rather it should be bits of the feature that can be released and still be useful for the user.
  2. Be prepared to explain the change. The reason for writing many requirements for one feature is to break the work down into more manageable pieces that can be worked on and completed within an individual sprint.
  3. Introduce a consistent format. As a rule, suggest that you introduce the following format for user stories:

    As a <user type> I want to <do something> so that <I achieve something of value to me>.

    For example:

    As a user of your website I want to be able to search for a product by its title so that I can read more details about it.

  4. Make an effort to write the "so that" part of the user story. This is the part that traditional requirements documents miss out. It is this justification that usually leads to more requirements being unearthed, particularly if there are a lot of "and's" in there!

You are now introducing the first agile concepts where you might have some explaining to do. User stories are unique to the agile methodology so it's up to you to judge when people are ready to start using the terminology.

Be prepared to explain why you're suggesting a change in the way in which requirements are recorded. As a starting point, here are some benefits of user stories that I've discovered myself (in no particular order):

  • They are written in the language of the business so everyone can understand them.
  • The justification part of the user story reduces ambiguities in how the requirements are interpreted.
  • They describe large features in more detail and so capture the true intention of the feature with more clarity.
  • Anybody can write user stories, including actual users.
  • The format of the user story puts the user at the heart of the requirements which means that the user is getting value all the time.

At this point, we are now creating manageable useful pieces of work that are understandable and visible to everyone.

The next steps are to start introducing methods to use these units of currency in the planning and estimation work, which is the focus of the next blog post.


Next: Part 2: Admitting you're bad (coming soon)