Software developer/manager and agile enthusiast
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.
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.
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 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.
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:
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:
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)
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.