Agile

I have been involved in the running of a number of Agile teams over the years and I have to say the success of the projects were due to the very talented developers and support staff that made up the teams.

Agile comes in a number of different shapes and forms the most common two are Scrum and Kanban. This section of my blog is not how to teach Agile but to inform on my experience of the benefits you can achieve by moving to the Agile methodologies.

Scrum

A better way of building software

Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Management and teams are able to get their hands around the requirements and technologies, never let go, and deliver working software, incrementally and empirically.

Scrum itself is a simple framework for effective team collaboration on complex software projects.

I am not going to comment much on Scrum as it is documented throughout the web, except to say it works but you have to be fully committed.

I have worked on projects where their idea of an Agile project was 20 developers having a scrum in a small room for an hour every day discussing life the universe and everything.

So, companies please give training to Scrum Masters a team lead does not necessarily automatically make a good Scrum Master 🙂

Kanban

Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. This approach presents all participants with a full view of the process from task definition to delivery to a customer. Team members pull work from a queue.

Kanban in the context of software development can mean a visual process-management system that tells what to produce, when to produce it, and how much to produce – inspired by the Toyota Production System and by Lean manufacturing.

A Kanban board is very much like a Scrum board except Kanban is based on a Work In Progress (WIP) limit for each column. There is no right or wrong rule for the amount of work in progress it is dependent on your teams abilities. I usually put the WIP limit in each column as the size of the team responsible for that column. i.e. if I only have two testers then the size of the “To Be Tested” column would be 2. The WIP figure for each column will change as the Kanban board gets more experienced. If you see columns that are under used or over used, causing blockages, examine your processes on why that is happening. i.e. is there too much unnecessary process, is it you really just don’t have enough staff to fulfill that columns expectations etc.

One of my most enjoyable times in my career was consulting on a development project where they were having issues managing the amount of internal defects raised on an, as of yet unreleased, product. There was a “Team Lead” who would spend all his days allocating defects to specific people whether they were capable or not whilst neglecting his real job of “Team Leading”. This led to developers feeling under valued, under used and a square peg round hole syndrome.

Along comes Kanban.

My first job was enlightening senior management with a small presentation on the benefits of Kanban, the main advantage management liked was the visual representation of progress. My next job was to convince the senior technical staff that Kanban could be a good thing and it would release them up to do the thing they enjoy the most, the technical work.

Everyone was now convinced to give it a go.

We draw up the first Kanban board, then another, then another until we get it right.

One of the advantages of Kanban is you can use the experts in your team to fix certain areas, Scrum on the other hand assumes you have a generic team who can work on anything, I have yet to see a team that can do that.

So we populate the “To Be Done” column on the Kanban board and watch as things start to happen. In a compressed time scale, this did take 4 – 5 weeks for the developers to become familiar with being their own boss, the rate of defect fixing exploded. Developers cooperated more and the quality of the software improved.

One little trick I found very useful was using different coloured sticky notes to represent failed tests at the Integration Test stage. A developer seeing a bright red Kanban card returned to the “To Be Done” column with their name on it always ensures better quality code the next time around.

In Scrum, you are meant to prevent changes to the Sprint cycle you are currently in, since in Kanban there are no Sprints you can add and remove tasks from the “To Be Done” column at any time. This allows you, as the supplier of tasks, to influence the work that needs to be done, even though the team is empowered to pull the work they want from the Kanban board.

I heard a quote once that Scrum is like a bucket of water you fill it up then empty it, as in you start a sprint finish it and then deliver. Kanban is like a hose it doesn’t have a bucket to fill and you can deliver at any practical point.

The crowning glory of this project was realizing the team had gone from a 25% successful defect fix rate to a 98% successful delivery rate. Everyone was happy.

So try Agile. You may be surprised for the better.