The bell that calls us to standup every morning
This post assumes a working knowledge of Agile and Scrum.
I’d suggest familiarising oneself with these to get the most out of this review of our experiences.
OpenUp consists of software developers, government experts, mappers, data mungers and visualisers, and people who just make things happen. We use scrum and believe in agile principles. But as the non-tech side of the organisation has grown, we haven’t always ensured they understand agile. This has caused frustration, confusion, and a feeling of chaos. We tried to address this with simple agile introductions for all staff, with mixed results.
While we’ve gotten a lot done over the last two years, we realised we can do much better if we all understand what it means to work using agile methodologies, and how the agile tools and processes can help us. Some of the issues that have come up at all-hands and water-cooler conversations include feeling:
- we’re changing direction before getting something done,
- we’re trying to do too much,
- that everything seems really important but we’re not really getting enough done, and
- we get conflicting instructions from the same or different people.
As an organisation we have always used agile. So when a couple of projects were formed around mainly non-tech teams, they were frustrated at the apparent lack of process. We believe that in such a case, the ideal would probably be intensive practical training, and subsequent day-to-day support from a trained scrum master. But for some time we didn’t seem to get around to arranging this, so we decided to take a lean approach and try something simple first.
We decided that I would provide a very basic scrum introduction to staff who don’t have a scrum/agile background. While I’m not a trained agile coach, I’ve used it professionally for over 5 years. Given the Scrum principle that the team should own improvement of their process, I should at least be partly aware of how to improve scrum usage.
The training (or introduction) I provided differed between two teams.
For TrainUp, I facilitated their first Sprint Retrospective, encouraged them to hold a retrospective every sprint, and clarified roles of scrum team members and some scrum principles. Adi, their Product Owner who is experienced in agile, further helped them implement scrum, especially at their fortnightly planning meetings.
I walked through a set of slides providing an introduction to scrum with another larger team, who didn’t have anyone with experience of using agile. I spent about 1 hour talking through this with pairs of colleagues. Again, I emphasised regular sprint retrospectives as probably the most important practise. We talked through key principles based on their current roles and experiences. And we often used scenarios that recently played out in the organisation to discuss how one could approach those scenarios according to scrum.
For example, issues around contradictory instructions related to understanding the role of the product owner, who that is on a given project, and that there could be only one. Further, that a sprint board is the source of truth on sprint commitments.
“Now that I understand the philosophy behind agile, I can adapt and use it for my work”
To understand what effect the training was having, I conducted interviews with most of my colleagues. The results were mixed. The sense of chaos is significantly reduced across the board. Tech and non-tech colleagues now have more of a common vocabulary for discussing and resolving challenges. We are also more aware of why we are doing something, which activities have to happen, and which don’t make sense any more. To paraphrase one colleague, “Now that I understand the philosophy behind agile, I can adapt and use it for my work”. On the other hand, it seems that such a light introduction might not be sufficient for a team to adopt the process fully.
For the team who doesn’t have an experienced scrum user guiding them in its application, it’s been difficult to get started and implement several of the scrum tools. The value and intention of each scrum tool is most clear when paired with practical experiences of the relevant scenarios and issues. Talking through the theory was a start, but really a team needs ongoing support to understand and apply the tools scrum gives you. Lacking an experienced scrum user in the team, the next best thing is a champion for the methodology, who sees the potential and seeks opportunities to strengthen the team’s understanding.
Our next steps are to improve ownership and understanding of agile as a fundamental part of how we work. We might review foundational agile principles and collectively choose to highlight those we feel matches our work best. We would also like to get a better understanding of what the project management role looks like for tasks like budgeting and contracting, which the scrum process doesn’t really deal with. Again, trying to get the ball rolling, we will learn from lean start with something simple.
I’d like to thank Alison Gitelson for sharing her experiences and thoughts on how we can take this further.
