Alistair Findlay

Software developer/manager and agile enthusiast

Overcoming resistance to Agile Part 3: Being visibly better

Post it notes

The previous post talked about using commonly agreed estimations to better plan the team's work; this post will explain how you can start to engage the wider business by making progress through the work more visible.

First steps to making the progress more visible

The most important thing about making progress visible to everyone is that it's presented in a form that everyone can understand. This is where Kanban boards are very effective because they present tasks in a simple "to-do list" manner.

From my experience of making the transition to agile methods, people do get used to new terms quickly (such as Kanban) as long as they are used consistently and are explained clearly. Don't be afraid to introduce them!

The key thing to getting started with using Kanban boards is to use what tools and space you have available at the time.

If you have no space for a physical Kanban board, use an online tool as the focus, such as Trello or Visual Studio Online. You could even use an Excel spreadsheet hosted on an intranet or shared folder.

The use of both a physical Kanban board and an online tool is good for visibility for people located in or outside of the office.

Encouraging regular communication

With the Kanban board giving a focal point for discussion you can start to arrange regular stand-up meetings.

It's a good idea to use the physical Kanban board as the location for the stand up meetings. For online boards, you could use a meeting room with a projector or use video conferencing. It helps massively if people have something to point to when discussing their progress through their work.

The key thing with the stand up meetings is ensuring that there is a comfortable environment for people to raise issues, whether "good" or "bad". Ideally, you want to aim for a culture where people don't regard things as "good" or "bad" but simply as work items that need to be taken on board, planned for and acted upon.

Be prepared that this is a cultural change that can sometimes take time to achieve.

You may also find that in the early stages of introducing agile methods only designers, developers and QA attend the stand ups but this is OK; the visibility of people standing around a board full of post it notes should at least pique interest from other parties, if anything!

Ultimately, the act of getting as many people involved in the project together at regular intervals - even for a short amount of time - is the thing that will foster an environment of proper collaboration.

I have generally found that the best communication within the team happens immediately after the stand up meetings have concluded.

The first few sprint reviews: Admitting you're bad

The first time you try anything, the chances are that you're going to be bad at them. I always liked this quote from Tim Vine (a comedian who has nothing to do with agile by the way):

"If you try out new ideas it's OK if they're crap."

I also speak from experience here!

It's tempting to put a positive spin on something when you're trying to get buy-in from others but it's important to set off on the right foot with the review process by making sure you're as open as possible about the progress made.

This means reporting on only what has been achieved and not what is in progress. It's helpful to explain this prior to the review session itself and set expectations that the review isn't a demonstration of prototype work but a review of fully tested work that could be released to the customer.

Also set expectations that the review session will highlight the work not done and potential issues why. It can be an uncomfortable situation to report on perceived negatives but the fact that these issues are being found early on is much better than finding them at the end of the project.

Hopefully, people will recognise that the issues raised are not a symptom of the methods being used (although they could be - see the next section), rather that the method is being effective at highlighting the issues instead.

As you go through more and more review sessions, people (especially management) should appreciate the openness of the reviews and understand how their regular input is vital to the success of the project.

Although reviews are meant to be an informal discussion session, it can help to set an agenda or a simple slideshow in early review sessions to ease the transition from presentation-oriented demonstrations to the more collaborative nature of these sessions.

Refining the process with regular reflection

Inevitably there will be plenty of room for improvement with the process itself.

Although there are certain core values that agile methods possess, the methods should mould to the people and the project to allow the team to do their work as effectively as possible.

Critical to agile methods is the idea of retrospection so it's important to hold reviews with the team about the process itself. Again, the more people in the room the better; people are much happier when they are empowered to improve their working environment together.

Some examples of refinements that you could come across include:

  • More frequent builds, from weekly down to continuous deployment.
  • Changing the layout of the physical Kanban board to reflect any online tooling.
  • Using different coloured post-it notes for different types of work items
  • Changes in the way design and development share work, such as sharing the HTML/CSS/Javascript implementation.
  • Changes in the way development and QA works, such as pair programming.
  • Training of individuals in dedicated agile roles (such as Scrum Master)

Getting buy-in from management

It's entirely possible to run the first few sprints as a trial of agile methods and start to engage management when you can demonstrate visible progress. It all depends on how comfortable you think people are with these new methods.

Transitioning to agile methods definitely involves a cultural change so be prepared to encounter conflicts with management and uncover dysfunctions with existing processes. Some things to be prepared for include:

  • Highlighting of inefficiencies in current deployment processes (which could hopefully lead to discussion about introducing continuous delivery).
  • Nervousness from project managers around the lack of "percentage complete" reporting.
  • Nervousness from project managers about the in-built uncertainty in planning that agile methods embrace.
  • Blaming agile methods for introducing more bugs (in fact, agile methods are highlighting bugs in a much clearer and addressable way)
  • A perception that the regular stand up meetings and reviews are designed to "catch people out" rather than give people a forum to productively highlight both progress and impediments.
  • Training requirements for new roles when agile methods are rolled out more formally (such as that of Scrum Master).
  • An initial perception of less work being delivered due to the definition of done including design, development and QA effort, not just development alone.
  • Reverting back to waterfall methods within sprints, that is, leaving QA tasks right at the end as opposed to designers, developers and testers working in parallel.
  • A perceived increase in administration overhead, such as the management of the Kanban board and the various meetings.

In all of these situations, it's critical to discuss and resolve the issues with the relevant people as soon as possible; nipping things in the bud early will only help people get better together more quickly.

From my experience, it takes around nine months to a year for agile methods to be understood and adopted across an average sized company. It will take years for such a company to become good at it.

Hopefully now you can demonstrate, via the initial sprints, that agile methods are suitable for the project and you can continue to make the transition with the full support of management.

At this point, with the initial resistance to agile overcome, you can start to implement agile methods more formally across the wider company and start to become a truly customer-centric business, which is the focus of the next post.

Next: Part 4 : Do it all over again (coming soon)

Overcoming resistance to Agile Part 2: Making plans for Agile

Blog title image

Following on from the previous post about taking the first steps into using agile methods, this post will cover how you can progress to making better estimates for your project as a team.

Continue reading ›

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

Blog title image

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.

Continue reading ›