Catalyzing Agile Minds
I’ve worked with a number of companies and on several teams of people who tried Agile and had mixed results. Some found freedom and delivered predictably, with quality. Others found it annoying or painful. Their complaints were similar — long ceremonies, constant status updates, not able to deliver meaningful work in a single sprint. Some said retrospectives were a waste of time.
They were right. Bad agile practices were prevalent. It was an unfortunate side-effect of layering agile on top of things like endless meetings or an overwhelming list of priorities. Perhaps the biggest blocker is lack of a safety culture. People are often afraid to speak up about internal dysfunction for fear it might cost them their job.
The problem isn’t agile. The problem is not knowing how to catalyze and cultivate agile minds.
Centil is a company of agile and DevOps coaches and practitioners working in the defense space. Early in our company’s history, we focused on systems engineering, configuration and change management. We soon realized a lack of agility in defense culture was blocking value delivery. The agile prescription wasn’t yielding results. So we started to work with customers and partners to catalyze and cultivate Agile minds. One of the most effective ways to do this is to disrupt our thought process and business practices. Regularly.
Sometimes we catalyze agility by facilitating discovery and planning sessions. When facilitating, we seek a rhythm of what Nyls Zimmerman at Competendo calls convergent and divergent thinking within our groups. Divergent thinking engages a group by promoting creative brainstorming. Convergent thinking keeps re-focusing the energy on the main point. Everyone wants meetings with a clear outcome.
We’ve found 5 important elements to catalyzing agile minds within our teams:
- Be willing to take risks often and publicly.
- Use creativity to engage people in the discussion.
- When possible, limit the audience size to the ‘2-pizza team’ guideline to increase engagement. (For example, scaled frameworks will break into small teams for feature-level planning.)
- Invite representatives from your entire value stream. This includes customers, engineers, vendors and stakeholders.
- Prepare to ask a lot of questions.
One of my friends has a saying I really like, “People are better busy.”
It’s true. I hate being bored or doing work that doesn’t challenge me. I love it when my days fly by and I can see results from what I’ve done. I know a lot of people who think the same way.
But there’s a dark side to that statement. Imagine being so busy you can’t take care of the truly important work in front of you. Visualize customer priorities sitting in stagnant piles between people who are loaded down with other work.
The key is to be busy with the right stuff. Many of us in corporate or government America are accustomed to being busy. Maybe it’s innate. Maybe our managers pressed it into us. The sad side effect of this attitude is not taking time to practice asking new, creative questions about our work. So how do we find the right kind of busy?
You could do a lot worse than starting with the most important insight agile principles and practices gives us: It’s all about the customer, baby.
Recently, I was invited by a colleague to facilitate network configuration and services integration using a story map. The audience, which included technical experts, project managers and a government program manager — was resistant to the idea for several reasons. First, the topic for discussion seemed pretty straightforward — the usual planning approach always worked fine. Second, the audience expected a classified-level discussion. This discussion was unclassified. Third, our team wasn’t accustomed to release planning sessions. We were systems engineers, hardware and network experts, not software developers. We typically hashed out a way forward in Technical Interchange Meetings. (If that sounds painful, in my experience it often can be.) With all of this resistance, why not try anyway?
My colleague wanted to encourage an agile mindset by disrupting the typical way the team planned their configuration projects. He built traction for the meeting with a small prototype. Weeks before, he decided to experiment with storyboarding as a way to visualize possible network paths for a new communications circuit. It was a very creative move.
He took the time to plan an integration approach by himself using agile methods, and more importantly took a risk with his customer. He provided the results in a visual with much greater transparency than the customer was used to. Transparency can be risky, it allows others to see how we are thinking. Sometimes we run into those personalities whose natural tendency is to find every flaw instead of engaging in the dialog. His risk paid off, and the customer was interested in trying this approach with network configuration.
Despite his early success, the meeting almost didn’t happen. My colleague made a couple of phone calls days before to quell the unease over trying something new. There were growing concerns an unclassified meeting wouldn’t provide value for configuration decisions.
We invited a broad audience — our customer, configuration manager, systems engineers, product owner, scrum master, cybersecurity engineer, site support team (including someone with deep knowledge of missile defense daily duties and the applications used in those duties), and vendor engineers. Not everyone came, but we had good representation and stayed within our 2-pizza limits.
I began the session by explaining what storyboarding was. My intent was to get a picture of this product’s intended use case, and an idea of the value it would provide to Space Missile Defense. I explained we wanted to use storyboarding to understand how the new messages would make a difference for an end user. I reminded the team we weren’t in the business of acquiring data unless it had immediate or near-term value. Then I asked the customer to give us a vision of the product.
Instead, the dialog immediately shifted to what I jokingly refer to as our Usual Operating Framework. Its an efficiency-minded approach to tackling complex problems:
- The customer tells everyone what needs to happen and the best delivery approach.
- A technical expert tells everyone how we can deliver this.
- Technical experts start to disagree.
- Someone says how nice it would be if we just had more documents so we understood what we were up against. What if we schedule a classified meeting?
- Rabbit trails begin to form.
Time to kick the bushes.
I had tried to interject a few times to shift the conversation, but it was pretty involved. I found my moment and paused the meeting long enough to bring it back to the agenda. I asked an operator to tell the story, at a high-level view, of a ‘day-in-the-life’ for an operator. We wanted to understand the story our user was living in, to see how our product idea could make a difference for them. Turns out, many of us didn’t know the full story. It wasn’t very complicated, but when we were done, we had a very rough sequence of events on the whiteboard. The team was engaging.
With a draft picture on the board, we asked ‘how does the product make our users’ story better?’ We looked for gaps in the story. We decided on priorities to start with, and what to work later. We walked through several scenarios to pull in the new messages and display them. Amid the wildly diverging conversations, we wrestled out a potential first release with a handful of sticky notes. I was somewhat satisfied. At least we had a plan for ingesting the data, but we didn’t have a user interface for it. We could have gotten to this point in 30 minutes, and we were almost 2 hours in. Too much sideways energy.
Then I remembered something that triggered our turning point. A little comment, dropped from a vendor about 20 minutes ago, indicating that a basic user interface was available through a web proxy. Nothing complicated, nothing profound.
“Wait a minute,” I said. “I want to be sure I understood something. A while back, I thought someone said we could leverage a hosted, basic user interface and save the effort of ingesting these messages into our servers. Did I hear that right?”
I was taking a risk, pulling us back to topics we had already talked about. There was a long pause. Someone started to disagree. Then a vendor spoke up.
“Yep, that’s what I said.”
The customer shifted in his seat to face the vendor. You could see everyone’s wheels turning. We might be onto something. A lightweight solution that would give us early feedback. Not the full capability we eventually wanted, but it would complete our story, giving our operators a visual picture of the messages. What’s more, we wouldn’t have to spend time and effort getting expensive security approval and integrating the messages into our framework for this first release. Faster value delivery was achievable and relatively simple — a rare find.
More questions followed, and before long everyone agreed this was a good first approach. Besides, we had at least a dozen other projects we were working on anyway (more on that another time).
We followed up a week later in a classified room to hash out remaining technical details. In just over an hour, we had seven stories written and ready for our next sprint. Seven stories — that was it, and none of them were complicated. It was a proud moment for all of us.
Agile ceremonies can be helpful. Events can give us guardrails to prevent conversations from devolving. Artifacts can reinforce the kinds of outcomes we want. But methods and frameworks are no substitute for real, messy agility. That requires agile minds.
