“The ones that are crazy enough to think they can change the world are the ones that do.” – Albert Einstein
My organization is changing and adapting. As a leader, I am being purposeful to make this happen. I have brought in 2 managers to focus on the “day to day operations” and to continue to perpetuate both our technical and cultural growth. This has allowed me to start thinking with much more depth and breadth about the organization while ensuring that the culture that has been built continues to receive the appropriate level of care and feeding so it can be nurtured to continue to grow. Many were shocked that I did not do this sooner but, again, as a leader, I wanted everyone from the most junior level employee to the most senior level employee to initially have no obstacles directly to me. This also meant based on the levels of time approvals, performance reviews and personal coaching that I was instilling into the culture the ability to be self-organizing and self-managing. It created a “top down” support culture as opposed to a “top down” decision culture. In doing this, I think the balance has been found very well inside the culture where people feel the autonomy of teams to make good decisions and accept the responsibility of those decisions.
My colleague (amazingly customer service oriented), who handles all of the operational aspects of the business has been trying to help his group find a balance of agility in how they operate. He does not have any real champions today who “get agility” and based on the needs of the culture in place (as operations is much more enriched in a process and procedure approach than a looser framework) they understand the need but have difficulty applying it to the work. I am hoping to be able to assist them in finding the balance for themselves.
The Context of Work
Early on, I really struggled with the idea that the operational group could not adapt to becoming more agile in their approaches. I almost felt that they were not even being open to it. They went to classes, etc but never seemed to embrace it. Then I finally got it. Leadership had been asking them to “become more agile” without ensuring (or assisting) that they even knew what that meant or even where to start.
The funny thing is that this realization really hit home with me when looking for some Sriracha sauce in my refrigerator. I looked into the fridge and couldn’t see it so, as I am want to do, I asked my wife where it was. She said it was right in the door to which I replied; “where? I can’t find it”. This usually results in her coming over and pointing out the bottle right in front of my face. To which I often say “if it were a snake it would have bitten me”. It was right in front of me, I knew what I wanted yet somehow I could not secure it. This made me think about the teams and what they really may think about what “being more agile” really meant. Maybe it was right in front of their face and they just needed someone to point it out to them (like my wife was kind enough to do for me).
I also realized that perhaps why they were struggling was based on the context of the work they do itself. I believe that it was Stephen Covey who talked about trying to find rocks and ask “is this it” when taking a moment to ask what kind of rock you needed may have made this task more efficient. So, I was guessing that they understood the concepts and goals but applying it to a work context that was less about creativity and more about consistency seemed like scaling Mt. Everest.
Eating the Elephant One Bite at a Time
Often times, our leadership team uses this phrase to talk about the decomposition of work. It has always seem to convey a universal understanding with us that it is easy to become overwhelmed by something too big but if decomposed into bite size pieces, it becomes more consumable. So, this is what I suspect I can use to approach this goal of operational agility.
When I first started, the deployment of software in my organization was a heavily document driven process with staging server folders and handoffs and low communication and high mistrust between development, operations and database that someone would do something that they should not do. So, in response to this; things were locked down in certain levels only to be touched by a master craftsman. This high speciality of skills meant that deployment became very dependent on 1-2 people with the knowledge and skills to deploy code to the production servers. This always struck me as a really bad plan. So this was one of the things I tackled first.
My first goal was to understand the concerns and needs of the involved groups.
Development wanted to get code to the stakeholder as quickly as possible and not have at to jump through hoops to have small changes made. (They wanted to control the development environment so they could be responsive).
Operations wanted consistency among server environments and guidance in what was needed to be changed in the environment to ensure that the changes did not create a supportability issue. They did not want people making server level changes without being involved. And they wanted documentation that clearly outlined the steps for deployment, the dependencies, etc.
Database was less complex. They wanted to to know if there was a precedence of order for their work in the deployment. Since they personally ran all database scripts, they would check them and ensure that they did not have a negative environmental impact.
So all of the needs and concerns were pretty much on the table to address. However, the idea of moving from a manual process to one of full automation was a large task (an elephant).
So, we started with asking operations to sit with development and if we did a build and deploy to the server share, what details would they need at that point. This allowed us to automated the code delivery mechanism and only leave manual the server deployment. Over time, we were able to work with operations to secure and work together to stand up a deployment server tool that would allow them to review the deployment, secure product owner approval via a workflow and then deploy the code and restart services at the push of a button (removing the expert dependency).
Taking this “one step at a time” approach helped us achieve higher agility and facilitated communication on both sides of the process to ensure we fully understood the needs that each group had and find a balance. Does that mean it’s done? Not by a long shot. We still have room to raise the bar but by using the core tenants of inspection and adaptation, we can retrospect on how the process works and further improve. As Mike Cohn is quoted to say “agility is not something you become, it is something you become more of” …
So what does this mean in my work context?
What this boils down to is often people focus to become textbook agile. They think it’s an application of process and procedure but they leave it devoid of the cultural shift. Take a moment (I often say this as I feel often we “do” but never take that necessary time to assess) and assess the pain points of a situation in terms of the agile principles and ask yourself the following questions:
- How could this situation become improved through the increase in individuals and interactions? Are we relying on processes and tools as this mechanism to meet the need today? Often times taking away that face to face interaction loses the overall understanding of the need (ever had an argument over a text message thread?).
- Are we “end goal focused” in terms of meeting the need in terms of the value of the solution? Or are we in a “cover your ass-sets” mode that is overloaded to ensure people do not do the wrong thing? Have we allowed a historically bad situation to shape our overall approach?
- Are we focused on collaboration as the primary way of working to create a solution and shared understanding? Have we developed a culture that is more focused on an end document than the quality of the solution? If we are using a document as a point of shared understanding, do we review it regularly to ensure that it continues to create that understanding and adjusts as needed?
- Do we embrace the overall concept of change? Have we created mechanisms that attempt to stall or avoid change for the sake of being consistent? As painful as change is, it is a given. Things always shift.
- Are we using fear as the driving mechanism for what we are trying to accomplish? Has our outlook been colored by a previously bad situation in which a given process was implemented in reaction to this. Any process that has been created in an attempt to ensure that “this will never happen again” is probably open to scrutiny. Given too many rigid constraints, people will work twice as hard to find ways to work around them through informal channels, relationship building and holes not yet discovered. Be open, honest and trustful to the end value and the people performing the action. Bad situations typically arise from lack of knowledge, general mistakes or incompetence. Those are all things that can be remedied. I have rarely found a situation in which someone intentionally set out to do something malicious in terms of the general process of work.
So why did I take the time to think out loud about this?
This topic came to me as I have seen more and more people struggling with how to be “agile” in their approaches, especially when it comes outside of the context of software development (which has a lot of frameworks for guidance). I have seen managers try and apply kanban and lean and scrum in other functional work contexts without starting with the basic ideas of defining how they work, what the workflow is and with a lack of understanding to the underlying principles of agility.
Take a moment to read the agile manifesto and see how the meaning can be adjusted to better fit your work context, determine a purpose and end value proposition to the things you are striving to do and look at how you are working with wide open eyes. Include people, ask questions, understand needs of the end result and inspect and adapt within a regular horizon. Keep in mind that the cultural installation of agility allows you to adapt any process when things breakdown or in the face of shifting priorities, circumstances or needs.
Have a great week everyone and stay agile!