Can non-tech teams be agile?
In my opinion the answer is yes, with a few caveats or changes (of course).
When visiting a restaurant some of us have preconceptions on what should happen during our visit but mostly assume expectations will be met. i.e. receive delicious food so we can have fun with good company. During this experience our requirements are defined by the menu (or altered as we wish), our faith lies with the chef and their team to deliver good quality meals for the price.
One of the reasons we pay to eat out is to outsource the cooking process, therefore we don't need to approve the recipe or procedures on how the team execute the meal. All we know is the end result. It determines how high or low our customer satisfaction is and whether we visit that restaurant again.
What we don't see or want to see as customer is what happens under the hood (or in the analogy above - the kitchen). Which is hard work, preparation, planning, hierarchies of skills and most importantly agility. Agility to pivot when things go wrong and quick decision making by all skill levels.
The same concept can be applied to a corporate environment, for all different types of products and services. The customer only wants to see the end result or have input into necessary decisions based on tangible outputs.
Diving into agile software development and the scrum - The customer is the focus on the product development, change is flexible and pivots as needed, delivery of the product or software is as it is complete and ready to be seen i.e. speed is key, the business and tech work together (this one is fundamental), keep individuals motivated and supported.
If you break these principles down they seem quite simple but the work that goes into it is subsequent, just like the predecessors using transitional project methodologies; planning, structure and input is critical to the success of the outcome. However, the main change here is speed and agility, hence the label Agile. And this is something non tech functions battle with, but why?
Trust and control.
What is trust? To me its the ability to be vulnerable and let the process take its course. Which could mean some failures and change in direction, but failing in the short term is better than failing big at the end of a 2-3 (or 10) year project. Success comes with less of the massive reviews and approvals of content.
Multi-tiered approvals is a problem and is quite the opposite of Agile. We have all been there. You just want to get stuff done but the hoops are small and could even have flames, and yes you have to jump through them (a few times) to keep everyone satisfied. There is nothing wrong with understanding risks and being thorough but tight control and the need for perfection hampers creativity and quite frankly stunts competitive market advantage.
The bottom line? For all functions, customer and non-customer facing, we can all be agile, even leaders!
Remove non-value add process steps
Give the experts we hired mandate and freedom to make decisions and produce results
Trust and empower
Don't be the roadblock
Make sure the customer is at the center of everything you do.
“The ability to establish, grow, extend, and restore trust is the key professional and personal competency of our time.” – STEPHEN M.R. COVEY