In a previous blog post I asked if I was Michael Fish. This started me wondering what other famous sayings or characteristics that are attribute to/aligned with well known people/characters, which I may display as an Agile Coach and/or Scrum Master.
Over the last couple of months many of the people around me have been going through their annual PDR/PDP process, receiving feedback and setting objectives for the year ahead. This reminded me of a comment made about me to a colleague. When relayed to me, it made me think of a quote from Manuel in the BBC sitcom Fawlty Towers:-
“I can speak English. I learn it from a book.”
The comment that was made intimated that I was very ‘by the book’. I can understand why the comment was made, while at the same time I would also like to disagree and argue that I do like to try ideas that are a little out of the ordinary in order to inspire and get the best from the team(s) that I am working with (more on that in future blog posts).
The comment came from a member of an organisation who were still (even though they may disagree) transitioning to an Agile way of working. As much as the development teams were writing code and testing iteratively, the planning and release of delivery items were very much waterfall activities.
When I joined this organisation I found that Sprint forecasts were being treated as commitments and that these commitments were regularly being missed. Deadlines were hard dates which meant that team members were often being asked/expected to work longer hours/weekends and morale was low. With teams unable to meet management expectations, changes were very much being implemented top-down, resulting in four different delivery structures in 18 months.
As you can imagine, some of the actions that were being put in place, particularly extended working, began to make things worse. The ‘you must hit this date’ attitude and long hours resulted in reduced productivity, an increase in absence and a decrease in quality, with an increase in defects both in-Sprint and post-release.
On discussing possible improvements with colleagues I was met with, ‘that’s the way organisation does it’, and that there was limited or no room for manoeuvre. As an example, I wanted to add two dwell columns to JIRA in order to better understand the teams bottlenecks and provide meaningful metrics/evidence of these. These columns took six months (and a lot of nagging) to be added.
I took the decision to try and address some of these dysfunctions (asking forgiveness rather than permission). To get the team back on track I took the team back to basics, which did mean doing things a little more ‘by the book’. With the support of the team we looked to increase transparency by making the progress that we were making visible alongside the risks, issues and impediments that we were facing.
As a team we:-
- Visualised our work in progress on a physical board (in addition to an electronic board)
- Forecasted what we could deliver in a Sprint – we never committed
- Identified a potential delivery window using average velocity, rather than trying to hit a set date
- Shared our ways of working, definition of ready and definition of done
- Highlighted the impediments, risks and issues that the team were facing
- Discouraged, and in some cases prohibited, working additional hours (particularly weekends)
- Attempted to make our working environment collaborative, fun and engaging
Although there was not an instant increase in velocity or throughput, once we had a stable team (another issue we faced were team members being moved in and out of the team) and a stable environment, the team started to hit their Sprint forecasts and velocity steadily improved. Possibly the biggest change that was seen was in the teams morale, which also increased as the team found their feet.
As their Scrum Master I worked to empower the team so that they could start to realise their potential and begin their journey to the high performers that they are destined to become. In order to get the best from them I needed to remind them of some of the fundamental building blocks of Scrum and Agile software development. Would you even look to build a house without foundations? No, so why would you look to transition to (or scale) Agile without the core principles and practices in place? It is that old adage,
“we must learn to walk before we can run.”
Where did I get this knowledge? Well, some of it came from books, so yes, in some ways I am like Manuel, but a lot of it comes from experience, working with and understanding teams. Every team is different and will need support and coaching in a different way. This means that my line is more likely to be:-
“I can coach teams in order to help them identify where they can make improvements. I learn [some of the ways to do] it from a book.”
Once you have learnt, understood and applied the foundations of the methodology/framework that you are using to develop and deliver a product, and have started to become predictable on your output, only then can you start to experiment in order to go faster and/or deliver more while maintaining quality. However, don’t forget to check those foundations regularly for signs of cracks/subsidence as you do not want to slip into bad habits that could be difficult to shake, creating instability and thus effecting you in the longer term.