Recently, I have undertaken a number of roles as an Agile Engagement Lead, working with large corporates as they began the journey of migrating their operations and delivery to agile ways of working. In most cases, I was starting with entirely new teams who had absolutely no agile experience. It was challenging, but interesting as I had to develop a systematic approach to rolling out Scrum. There were a number of hurdles that kept on repeating themselves and along the way, I was lucky to be able to pilot a few new approaches
Hurdles
They say that Scrum is easy to understand, difficult to master – Be under no illusion that this is true and be prepared for the backlash. The more you prepare, the better. On a few occasions recently, I encountered a significant lull, a couple of sprints in. Whether it’s apathy to attending the events, or a weakening of the agreement within the Definition of Ready, it will happen and it can be quite a big wobble. A good coach and team can head it off at the pass if they see it coming early enough and focus on the weaknesses. But it is also an opportunity to start to look at the mindset. Are the team working late every night to deliver to their promises? Are the estimates still completely out from the actuals? Are new items being introduced mid-sprint? The bottom line is this, are the team starting to see the benefits of agile? If not, why not?
ShuHaRI – I will leave it to the reader to look up the term in Wikipedia, but the basic concept is around the three stages to mastery of a topic. In the first stage (Shu), you adhere absolutely to the techniques. In Ha, you have the experience to begin to digress and experiment. In Ri, you transcend, you separate from the tradition (or even the scrum techniques).
Scrum is revolutionary, not only does it entails a change to how we work but also, a dramatic shift in mindset. But many within the organisation will simply see a delivery framework that they need to bend to their will. They are at stage one but have already decided what they need, don’t need from the framework. It makes everything a lot easier in the beginning but It is the surefire route to failure
Note from the boss –
Hello Mr Agile Coach Person,I want you to completely transform our ways of working, but without any dramatic changes to our ways of working. Keep up the good work!
What do you say to that one?
Cynefin Framework – Basically, Cynefin helps you to understand what type of changes you are working on and what decisions you need to make based on this knowledge. It will also help you to understand what framework you should be working with, Scrum is only one of many ways of working. Blanket decisions to roll-out Scrum across a department or organisation are the wrong thing to do. Help your client to make sense of the work that they do, and this will help you to collaborate on what framework they should use to deliver. Specific to my experience, we saw a huge amount of enthusiasm for ideation and innovation and the desire to run sprints to progress. It became apparent very quickly that we needed to introduce the concept of design thinking and to educate the parties in the various phases of product development.
Misconceptions about agile being a framework for delivering software – I sometimes work on non-technology agile engagements. Agile started in software and this can sometimes be used by new groups, as a rod to beat you with. “That won’t work for us, that’s just for software”. The bottom line is that agile is now widely recognised as a framework for delivering value to your customer.
At the same time, as someone pointed out to me recently, context is key. As a coach, you need to be fully aware of the context of the teams into which you want to deliver Scrum. Having an industry counterpart to work alongside and bounce concepts off, will go a long way to help. I recently read this article by Steve Denning which I think makes a far better argument than I can.
Approaches
So, those were a few hurdles from recent roles. Below, are a few approaches I took to improve our ways of working.
Plan – In one of the engagements, I designed a systematic approach to rolling out scrum across various global regions. With these guidelines, the agile coach in Asia, was able to provide the same level of expertise as the coach in Europe. It incorporated a schedule and a list of events to be applied during each of the phases. It focused on the training needed in the lead up to our first sprint, day 1 workshops to get us up and running and learning sessions as we began our sprints.
Coaching working agreement – It is quite common with Scrum teams, to produce a Working Agreement to detail good practices on how the team interacted with each other. We took it a step further and established a coaching agreement from the get-go. In the agreement, we asked the team to commit to regular learning time with the coach (eg brown bags to up-skill on the scrum practices), or collective agreement to focus areas (see point 5 below) etc. We were very upfront about what we needed from the team and it saved all the pain from people resenting our interruption of their already busy working weeks.
Community – Tied to the agreement, was a coaching community of practice which we set up so that the coaches could get together on a weekly basis and talk through what they were working on and what hurdles they were coming up with. This was a key element to our continuous improvement journey. We noticed that many of the pitfalls and hurdles were beginning to quickly repeat across different zones. As I brought more coaches on-board, the coaches that commenced first, were able to help with solutions and guidance.
Playbook – The community collaboration led to a playbook which we implemented across all regions. The playbook was continually updated with the rule being that anyone could diverge from the guide, if they could gain the agreement from the community on any deviation in their ways of working. It worked very well and was excellent in getting all parties to think deeply about the topics that were important to them. Please remember, this playbook was not a reproduction of the Scrum framework, more a guide to how to move from zero to full integration.
Uniform Scrum roll-out approach – As a group, we put together a checklist, with over one hundred scrum good practices and we began to measure our teams progress against these, starting with a simple yes / No to such questions as “Are the development team having a stand up each day” As they matured, we moved to a 1-3 criteria to replace the Y / N giving a more in-depth view of the maturity of the team against the criteria, answering questions like “Are the team using the correct user story format for all PBIs”. Having this checklist and reviewing against it on a regular basis allowed us to understand our progress and then to determine areas of focus for the coming period. As a side note, it is my view that user stories and estimation are two of the most difficult areas that need to be addressed in any agile roll-out and need serious consideration on the questions of how and what will we use.
Feedback – The importance of feedback loops and the use of retrospectives to help to counter leadership resistance to change. The most fundamental feedback loop in Scrum is the sprint retrospective. There are many other ways but I like the fact that this one is in the diary, one per sprint, rain or shine. Very often, while working as a scrum master, I have used the promise of the impending retro, to dissipate heat of the moment anger by pointing out “what a great item to bring into the retrospective”. Putting some distance between the anger and the debate, can be enough to break the tension, and further to this, the retrospective gives the right collaborative frame of mind to address the item evenly.
But recently, I saw another purpose with the retrospective as a tool to reinforce the commitments made by various parties to the overall success. Product Owners who are not pulling their weight, leadership stakeholders who made a commitment to be part of the process all fall into line after a few iterations if they are constantly reminded that the team are aware and counting on them holding up their side of the bargain.
Caveat: This article is more a musing on my past experience with a collection of best practices that we implemented in our specific circumstances rather than a mantra for agile roll-out. I am also aware that areas like user stories are not included in the Scrum guide so I apologise in advance for taking the liberty of including them in this conversation!
A few interesting points that cropped up were
- The absolute need to build a set of success stories within that industry to gain more trust within the teams that agile is the way to go!
- To branch out further than Scrum and propose Agile and Lean alternatives when Scrum is either too big a step or not the right way to go
- The need to consider methods like design thinking, to work in the ideation phase of product management and the need to educate the teams that processes like design thinking and Lean Startup have their place in the end to end journey
- The checklist turned into a powerful tool in our arsenal to counter the initial internal views on how agile should be bent to the enterprises will. By documenting and highlighting the areas that were progressing against those that the groups had no appetite for, we were able to make the necessary escalations and gain the necessary approvals to counter those who had decided what they thought was and was not important. It was a slow process but progress was made in areas like adherence to a set sprint cadence etc etc
That’s about it. I hope some of these hacks help you along the way!
Dave
