Alistair Findlay

Software developer/manager and agile enthusiast

Overcoming resistance to Agile Part 4: Do it all over again

Done Bag

The previous post talked about getting buy-in from management by making progress on a particular project more visible to the company. This post will describe the next steps to rolling out the use of agile to other projects, engaging the entire company in the process, and the important step of putting the customer at the heart of it all.

Present back what you learned as a team

After running several sprints, or perhaps after the first release of the product, you should present back your experiences of using agile methods to the wider business.

"Wider business" could be anything from senior management, members of departments not heavily involved in software development or other software departments who may be thinking of adopting agile methods.

The purpose of presenting back your experiences is to demonstrate the measurable progress made throughout the project and to hopefully show how collaboration between the team has resulted in a better quality product.

A good way of preparing the presentation is to ask the team to contribute their own experiences of using agile methods. You could organise these experiences along common themes, such as planning, day-to-day collaboration, retrospection, Kanban etc. and collate into a slideshow presentation.

When running the presentation, ideally the Scrum Master would lead the audience through the slideshow and then ask for the individual team members to talk through their experience at appropriate points. Having the whole team contribute to the presentation will highlight the collaboration and common understanding of the project that has been fostered throughout the process.

During the project, take regular photographs of the Kanban board and screenshots of the product; collated together they can provide a very good way of demonstrating the rate of change and progress made in a relatively short period of time.

Sometimes simple diagrams or sketches can explain new concepts effectively, especially ones where a lot of new and strange terminology is involved.

For example, you may find it helpful to create diagrams explaining:

  • The sprint structure in terms of planning, stand ups and review.
  • The team structure and roles.
  • The relationship between epics, user stories and tasks.
  • Sample burndown charts.

Of course, documents alone don't give the full picture so it may be helpful to sit down with people one to one and discuss the concepts more thoroughly.

Use what you learned on another project

Having gone through a successful agile project, you may be in a position to apply agile methods to another project.

Of course, you need to pick the development methodology that is most appropriate; agile isn't the answer for all projects, but you should consider it if the following points apply:

  • Is the project long-running and susceptible to business change?
  • Is the project suffering from a lot of technical debt and waterfall methods are failing?
  • Do you have 100% dedicated resource in design, development and QA?
  • Do you have an identified Scrum Master or have the capability to employ one?

And the most important thing of all:

  • Are people prepared to communicate openly and are ready to work closely with each other?

With any project, people are the most important factor to its success. When people are willing to work together and collaborate to achieve a commonly understood goal, great things can happen. If people aren't willing to communicate, lay back and play politics then the outcome is rarely a success.

Remember, don't wait to get started - in the words of part 1 of this series of posts, just go for it! It's important to realise that even though you've got the experience of working on an agile project under your belt, the next project and team dynamics will be different; use what you have learned but continue learning and adapting via continued retrospection and communication.

Engage the wider company this time round

Your "trial run" of using agile methods may not have engaged the entire team or maybe it involved parts of the business only at certain key points along the project timeline. This time round make an attempt to engage more people:

  • Set up open invites to planning or review sessions so that people can see how they run or even contribute ideas.
  • Set up open invites to standups, again so that people can observe or contribute.
  • Create a mailing list for the project that is used to inform people when new builds of the project have been internally deployed for testing (builds can be as frequent as user story check-ins).
  • Put out a call for testers from the entire company - QA should be an endeavour for everybody associated with the company.
  • Importantly, set up a mechanism for capturing user feedback. This could be as simple as an Excel sheet on a project intranet or an online repository such as UserVoice.
  • Set up a blog for the project and use this to highlight for example:
    • Planning session outcomes
    • Review session outcomes
    • Interesting prototype or product work
    • Results of user testing sessions
    • Successful releases
From my own previous experience of working with Waterfall, people across the company don't really engage with the product until release candidate stage when it can be too late to address any issues or requests for change. In contrast, the use of agile methods gives you the benefit of frequent and early testable releases so send out the request for testers as early as possible and you'll be in a much more comfortable position to manage these requests and act upon them.

Put the customer at the heart of development

Having a good set of internal testers is a great start to improving the quality of the product. Even better is to involve the customer in the testing process too.

All too often what the customer wants isn't what they get. You've probably seen this cartoon before:

What the customer wanted (Dieter and Schmidt 2009: 11)
What the customer wanted (Dieter and Schmidt 2009: 11)

The only way to avoid this is to put the customer at the heart of development and have their engagement throughout. There are various ways to achieve this:

  • Early in the project invite customers to provide feedback on sketches of proposed features or functionality. Draw up on paper several options for key features and, with minimal prompting, ask the person to explain how they would carry out certain tasks. Annotate the sketches with post-it notes to gather feedback. Use this to determine the initial approach to the implementation.
  • Have customers involved in the creation of user stories where appropriate. You could use an external facilitator here if you aren't confident in coaching customers in creating meaningful user stories.
  • During the project invite customers to planning and review sessions to feedback on project progress and to provide final say on UX decisions that are difficult to resolve.
  • During deployments, invite a wider audience to test the product via the use of beta releases:
    • For desktop products, you could provide these to select customers via a download or distribution via DVD.
    • For website products, you could run private or public beta sites that run alongside the currently deployed site (if any). You can then use a feedback mechanism such as UserVoice to gather feedback.

All of the above require only a selection of customers so make sure that you choose a representative set. If you are developing a website you can go further and employ even wider measurement and refinement via analytics and A/B testing.

The important thing is to get customers to evaluate the product and give feedback early. Not only does this give the team the opportunity to respond to change in a timely manner, it gets the customer excited and enthusiastic about the product.

After all, there's nothing more satisfying in product development than delivering something that customers love.

Keep going!

Hopefully you can take away some of the advice presented here and apply it successfully to your own projects.

If you want to read more about overcoming resistance to agile methods, then I would highly recommend The Enterprise and Scrum (Developer Best Practices) by Ken Schwarber. You'll be able to find more anecdotes and advice that will give you the confidence to take the first step into using agile for your next project.

Overcoming resistance to Agile Part 3: Being visibly better

Blog title image

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.

Continue reading ›

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 ›