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!
