About 6 years ago I started to hear a lot about Agile Project Management, Scrum and Kanban, and was keen to understand what these things were all about and whether we could use these methodologies in my team. One of the team went on an Agile Project Management course and came back really enthused. So we took one of our big development projects and tried to run it using the principles of Agile Project Management. Whilst we got some positive results, it didn’t really take off. I think the biggest problem was that we hadn’t considered how this could work alongside our day to day work, and which developments would suit this approach.
About a year later we had a major issue with one of our statutory submissions. The main cause of this was a reliance on a key individual who was juggling lots of different work, supporting other staff plus constantly responding to day to day queries. Juggling competing demands was a real challenge for the team and one that is common in most workplaces. I needed to find a solution to the problem relating to this submission which included removing the reliance on one individual, and ensuring we had a quality assured and robust process in place for this submission. I decided that we would re-look at using Agile project management methodologies to get this sorted. I spoke to senior management in the organisation and asked them to support us solving this issue through using Agile Management. It was really important that I got this support so that senior management could help me make sure people understood the impact this could have on our other workload.
We set up one of our offices as a ‘sprint office’ and identified key stakeholders, a product owner, scrum master and the development team with a mixed skill set. We sat down and agreed a clear Product Backlog; this then allowed us to agree the Sprint Backlog and the timescales that these could be delivered in. We agreed that the development team would work on this project from 10am to 4pm for 2 weeks allowing time at the beginning and end of the day to catch up on emails, pick up any other work and support the wider team. Between 10 and 4 they would turn off emails and phones, and no one was allowed to disturb them unless it was something urgent. Even then they had to come via me so I could understand why they needed to interrupt them. In practice no one actually needed to disturb the development team and everyone was happy to wait to talk them before 10 or after 4 without a detriment to the wider team and our other workload.
At the end of the two weeks we had got the products that we had agreed to during our Sprint Planning Session. During the Review and Retrospective we agreed to have an extra week to improve them even further. Everyone was keen that we didn’t wait to do this so we started the final sprint the following week. The project/sprint was a great success; at the end of the 3 weeks, knowledge had been shared, the process had been completely re-built, the process had been tested with a quality assurance element incorporated, and procedures had been written and tested by the development team and by others in the wider team. This meant that we had now removed a reliance on one individual; we had a quality assured process and could assure the wider organisation and senior managers that there was very little chance that we would have any further issues. With this new approach having such great results we were able to get support from the wider organisation to use this methodology in the future.
I had always worried that if I took a few people out of the team to work on something in protected time that we wouldn’t be able to manage the demand and priorities outside of this. It was great to see that this wasn’t the case and I was able to challenge our priorities and manage our workload alongside using this methodology. This was mainly because people could see how many benefits Agile was delivering and they only had to wait slightly longer for other work.
Since then we have continued to identify and run projects using elements and principles of Agile project management with varying success. The varying successes are generally down to having the wrong mix of skills in the team, not always having a clear Product/Sprint Backlog and not always having engagement from key stakeholders. Despite this we have learnt from both those that have gone well and those that haven’t, and worked out what recipe is required to make these a success, and the results are always an improvement on what we would have previously been able to do.
It is also brilliant to get positive feedback from those who have been part of these projects, they have really welcomed having focussed time on something so they can do a really good job on this and they always learn something new. It is great to see the team motivated to run sprints and I love seeing real collaboration in action.
I also try to embed the principles of Agile project management into our approach to managing all our workload. It’s not always possible to have sprints to do everything as there is not always enough resource and capacity to work in this way. However one of the main principles of Agile is time management so these can definitely be applied without having a formal project.
I recently organised a one day ‘hackathon’ for my team. I was reluctant to call it a sprint because it was one day and we weren’t going to be using kanbans or have scrum meeting plus there was 17 of us. During a previous away day we had all agreed that due to the staffing changes over the last 18 months we really needed to revisit our processes within the team. So we hired a room big enough for the 17 of us, I organised the day into sections and split the team into 4 groups. We had 16 processes to re-write so each group took 4 processes and had about an hour to write their four. During this first hour the group discussed the processes and debated how these were constructed. Then we circulated the processes round the groups giving them 40 minutes for the following sets of processes so they had 10 minutes per process to review it and add to it. By the end of the day we had 16 processes drafted which everyone in the team had had chance to review and add their ideas to. So not only did we have processes that we could now take back into the office and test out, everyone had been involved in writing them, and everyone had learnt about other processes from other work areas in the team.
If we had tried to write these processes alongside our usual work they would have been written probably in isolation with little input from others in the team. It would have also taken weeks to get them done and embedding these processes into practice would have been more challenging. The processes are now more efficient and all have a similar structure. By taking just one day out of the office (less than 7 and half hours) we have progressed a very important piece of work, and we have only delayed our wider workload by a day. No different to having an extra bank holiday thrown into our working week!
I would highly recommend finding out more about Agile Project Management and thinking about how this could be embedded in your work place. These project management methodologies are primarily used for software development but I definitely think they can be used in most business settings. It is also worth noting that if it doesn’t work then you haven’t lost much time to try things a different way, you may have lost a day or a week but you haven’t lost months trying something that literally doesn’t work. Fail fast and learn quick!!
My favourite things about Agile Project Management:
Kanban charts – I love using a Kanban chart to manage a scrum. All you need is post it notes and a board to stick them to. There is something so nice about picking up your action on a post it note and moving it through “to do”, “in progress”, “testing” and “done”! Take photos each day to see how the board changes during the sprint, and how all the “to dos” end up (hopefully) in the “done” column!
Time-boxing – this is such an obvious thing but we all lose time doing certain tasks and trying to perfect elements of your work and end up working late. Be strict on the time and then you will get through the actions that you had planned.
Clear Product Backlogs and Sprint Backlogs – It is so important to have a clear project scope. Don’t over promise, agree what can be achieved during the time you have with the product owner, scrum master and development team. And allow time for problem solving! This will all help to reduce the chance of scope creep and ensure you complete everything you had agreed to complete.
Focussed time – this is one of the best things. How nice to be able to concentrate on one specific job at a time without interruptions. Guaranteed to give you a better output!
Collaboration – working in this way means real team working and collaboration! It gives you opportunity to share ideas, problem solve together and learn together.
Scrum Master – having a Scrum Master coming in and keeping you on track is just brilliant. They also take away any impediments so the development team can concentrate on the things they can get through without been pulled off the project to liaise with people outside of the project and solve problems that are probably too big for the time allowed.
Engagement and Product Owners – having engagement from key stakeholders during the sprints means that they are involved all the way through the process, they can give feedback along the way, and there are no surprises at the end so they end up with something that they have helped to shape.
Iterative development – much better than getting to the end of a build and finding out that it isn’t quite what the customer wanted. Keep sharing and tweaking until it does the job it’s intended to do. Think of it like having a renovation to your house, you would constantly be checking in with the builder to see what they are doing and changing your mind along the way!
Top tips for making this a success:
Go on a course – classroom courses for Agile are much better than online. You need to feel how this works not read about it. Make sure the course includes a practical exercise to test out the theory.
Sort out the space you are planning on working in – make sure it has the right equipment, lots of whiteboards and a door you can shut. Remove all interruptions (divert those phones and put your out of office on your emails)!
Get a good Scrum Master – make sure you have someone who is able to make decisions, lead a team, and take away impediments and get them sorted.
Make sure to have a development team with good mix of skills and knowledge – they need enough knowledge and the right skills to progress the task, and are able to organise themselves to get through the work.
Time-box like a ninja – be strict! If you say you will finish at 4 then finish at 4. Rest time is as important as focused time! If you say you will give a task 20 minutes then stick to it (you will learn by trying, so this may come with experience). Check out the Pomodoro Technique!
Make sure your product owner and other key stakeholders are available during the identified sprint time – This is critical to make sure the end product delivers the agreed objective and you are not guessing what you think they might want. The time allowed is strict so engagement needs to be the same.
Hope you enjoyed reading my blog.
If you want to chat more about Agile and time management then drop me a line!
