My last blog post was about Scaling and tools available to make sense of your strategies within your organizational process adoptions.
I recently joined an organization that not too long ago was struggling with how to scale software implementation because of their increasing demand for the product and therefore were growing rapidly. After some looking around and attending conferences they got in touch with SAFe. SAFe provided a clear outline for them and felt it met they goal of reorganizing themselves to better handle the demands they were faced with. With the help of SAFe, they went ahead and adopt the Framework in the product organization. Trainings were conducted, coaches were put in place and new hires for some of SAFe’s prescribed roles (i.e RTE). The organization was helped with their very first PSI Planning where all Teams were to gather and live the experience for the first time.
Coincidentally, I joined when the time came for them to plan for their second PSI. This was quite an interesting time for me to join since a brand new CTO had just come onboard. Without selling the whole story, let’s just say that he had his own ideas and felt that the company’s recent SAFe rollout was not helping to release product to customers. Now I must say that I neither like or dislike SAFe since it is just like scrum a Framework.
In other words it is so easy to blame a tool when first using it especially when you believe that the tool will work with little effort or simply fix some of the deep down issues. During PSI, I was asked to remind all the parties present that without proper Strategies and Practices in place you cannot hope to gain efficiency or reduce waste, no matter the Tool you use. Like many things, learning rarely comes from things you say and when skepticism settles in, it is very difficult to root it out with just a few words. As an Agile Coach it is my role to move the Teams and Organization in the direction that They feel is working for them, therefore if your successful @ hammering screws, I may ask “How are the results?”. For all intent and purposes if the results are positive who am I to say they should do it differently. Keep in mind that context is very important when it comes to process adoption.
Nowadays, It feels like we are in a zone where we constantly “almost deliver”. A general sense of frustration sets in and this frustration leads to be reactive more than applying the recipe we have come to understand works “Apply-Inspect-Adapt”. A misconception, from both experience and observation, is that structure and taking a measurable amount of time to Inspect before Adapting is not Agile. The general feeling is that we should be made to act on the spot, we know in this moment it doesn’t work so why wait? Let’s be Agile, right? Let us remind ourselves that it takes a minimal amount of structure and time for us to observe what we achieve as a Team/Organization. I read something interesting which reflects this, “… We need to investigate almost failed as well – it is not sustainable to deliver with magic.” By introducing to many changes too often, we fall prey to “the more things change, the more they stay the same”. Very often little effort is put into understanding the effects of the change, they much rather satisfy an immediate need for the organization.
Finally, whatever you choose to adopt, be careful with blaming it on the Tool. We often say in IT that the problem is 18 inches in front of the computer, same applies in this case. 😉