On our path to get the most return from our efforts at becoming Agile, I am becoming more and more aware of how daily improvements to our process are contributing to the overall success of Agile in our company.
Each organisation is unique, and importantly each team has it’s own objectives. Finding the right way for you is going to be key to making Agile work for you. Below are some of the concepts I have been trying to wrap my head around with our development team… (and if you have ideas, solutions or opinions, share them!)
Agile and Scrum aren’t friends
The essence of Agile is to be flexible and adapt to changing environments. Scrum methodology teaches us to protect the team within time-boxed iterations (Sprints) What I’ve learnt in trying to tackle unplanned work without interrupting the Sprint, is that Scrum can’t help.
We have moved towards using elements of Kanban with our Scrum, whereby instead of blocking new work from being scheduled we now limit work in progress. There is provision on our planning board for unexpected projects and the team is able to accommodate these requests without stopping other projects. If no new requests come in, there is no idle time as each team member pulls tasks from other areas of the board to keep a continuous flow of work.
Roll over of tasks and points
Our team has started estimating effort points and this is awesome for me to get an idea of the scope of work required on a task. Trouble is, our projects tend to stay active for time periods longer than our Sprint. Therefore, I am struggling to measure the team’s velocity with Burn Down Charts (even trying Burn Up Charts) because a minimal amount of tasks move to “Done” within the Sprint.
We need to assess if we are pulling in too much work, are our projects too large, inadequately specified, or are our Sprints too short? There is visible completion of work (and a Shippable Product) at the end of each Sprint and actual effort points are recorded, only we have a roll over of ‘un-done’ which enters the next Sprint.
As Scrum Master, if I can work through these questions with the team and really clear the Sprint backlog for each Sprint, then we can even look at moving towards Release Planning!
Product Owners telling Stories
The most successful technique we implemented to get our Product Owners (PO) to increase their involvement with our Agile process was to encourage a ticket writing system. We showed PO’s a preferred format for writing a User Story and we now set up briefing meetings for new projects to work out the ins and outs together. This has helped team members better understand a project from a development perspective (got them wearing different hats) and it has helped the team with testing as we have a defined set of outcomes and expectations.
The continuous learning and real-life experience is benefiting the team and every day there is something that works and something that doesn’t. We get better as we progress and failing means that we know how to do something better the next time.