Software developer/manager and agile enthusiast
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.
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:
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.
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:
And the most important thing of all:
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.
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:
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.
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:
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:
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.
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.
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.
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.
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.