The First Impression
The first time I experienced an Agile approach to software development was over a decade after the Agile Manifesto, XP, Crystal, and Scrum first appeared. I had read about Agile, admired it from a distance, and wondered why I hadn’t experienced this revolution myself. By the time I experienced a team trying to use Agile in earnest, I had already been at over half a dozen different tech firms and many more projects.
I remember being excited. I also remember walking into the project manager’s office and reading the bits of paper stuck on their monitor bezel. They read:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
The team had a planning meeting at the beginning of the sprint, daily scrums, sprint demos, and sprint retrospectives. We had a digital sprint board and a giant analog sprint board with sticky notes. It was a Scrum shop.
We used Agile practices like test-driven development, continuous integration, automated functional tests, and had a reasonably clean software architecture on the technical side. It was easy to build the backend because we separated high-level concerns into many Java components. We didn’t need to rebuild the whole application when making small iterative changes. I had the full stack in a prod-like environment on my dev machine using virtual machines managed by Vagrant. I could develop and troubleshoot very quickly. I could even put my dev environment in the same state as prod promptly at any time!
By all appearances, I had landed in my first real-life Agile experience!
As time progressed, I began to notice a few things that concerned me. We had locked ourselves into a framework for business rule management that was inappropriate for most of our use cases. The software was managing business processes and business logic. A business process management solution governed by rules would’ve been more appropriate. The problem was that we had thousands of business rules defining processes that were difficult to test and maintain. When I asked about correcting this technical debt, I was told, “Sure. Do it on your own time.”
The bug database was growing many times faster than we were resolving issues. Consequently, my team was spending more time on unblocking our users instead of analyzing and implementing requirements. When the ticket data trends indicated that my entire team would be consumed by support within six months, leadership told me it wouldn’t happen. It did.
At the time I joined, the project was already four years over schedule and millions over budget. Worst of all, our users’ impression of the software was terrible. It ranged from frustration and apathy to pure resentment. Many would move work from the new software to the old to avoid frustration and wasted time. Often, this behavior would last well beyond some of the issues they had first experienced.
I didn’t understand why this was happening on an Agile team following the processes and the technical practices. By the time I could see the problems, my analyst-engineer team was already fully immersed in support. I had to understand. I took it upon myself to collocate with our various customers. I learned to do their work, how they worked, and how the old and new software improved and diminished value.
Here’s what I found:
- Our users didn’t have consistent representation on the development team.
- We were creating the software to fix the business processes.
- I found that many of our customers knew their world better than we were giving them credit.
- We didn’t document stable and known policies and requirements well enough to prevent frequent bugs after release.
- Customers didn’t have a voice in acceptance criteria.
- We weren’t getting the value of inspection out of the sprint “demo.”
- Users stopped engaging with the development team because they had been dismissed and gaslighted too often.
- We didn’t reflect our value statements in action.
I didn’t know it then and wouldn’t have been able to describe it clearly. But I had landed in a power-oriented pathological culture. No number of posters displaying company principles can replace living them out. And no process, even sublime ones like Scrum, can change our attitudes and behaviors alone.
Having a background in iterative process improvement, my view of Agile was very rooted in the processes defined by frameworks like Scrum. I understood and admired the values, but like many abstract statements of values or principles, I hadn’t yet internalized their power and central importance to Agile development’s functioning. And I had few experiences with organizations and institutions that acted with integrity and consistency to model.
When I began to analyze our interactions with customers, stakeholders, each other, and users, I started to realize that we weren’t Agile in many of the most important ways. It also became clear that some folks were weaponizing the Agile values. For example, when I built a matrix of acceptance tests for a story after an in-depth consultation with a user, I received public criticism. A leader called me out, saying I valued documentation and planning more than working software and responding to change. My attempt to demonstrate the value of customer derived acceptance tests fell on deaf ears.
I’m not sure if my response was pure courage or just the vitality that can accompany naiveté. I gathered the data. Then I brought it from one leader to the next until it was eventually in front of the executives. Weeks later, my team was “restructured,” leaving me unemployed. Given the culture, I knew this was a possibility. Before I started down that road, I discussed the situation with my wife. We both decided I needed to act in alignment with my values regardless of the outcome. I did learn that courage was more valuable than stability. We’ll dig into that another time.
What happened there was mistaking the source of business value. The execution and implementation wasn’t the biggest issue. The most significant problem was mistakenly believing that merely following a framework’s methods would produce value. Unparadoxically, acting in line with the framework’s values creates value. The framework is simply a means to express values.
Living Values
Is sprint planning intrinsically valuable? No, it’s not. It’s the people and the quality of their interactions that create value in a planning meeting. When our conversations generate shared understanding, commitment, and purpose, we create incredible value!
Is the daily scrum where we all hear what each other did and plan to do a valuable activity? Nope. However, when we openly share risks to our goals, what we learned, and our challenges, we empower our teammates.
Is a sprint review used to demo our product going to make cash fall from the rafters? Certainly not! When we’ve worked to build trust and respect with our customers, we create a safe place for deep collaboration to flourish.
Will documenting what’s working and what isn’t in a retrospective going to create a high-performing team? If that were the case, coaches, consultants, and thought-leaders would be out of work. When we have the courage to commit to running experiments and evaluating the empirical evidence, we will find sustainable high performance.
Let’s start thinking about sprint events as times to focus on living our values in the context of the event’s goals. We’ll need to commit to practice, patience, and gracefully working through a few awkward moments. It’ll be worth it!
Leading with Values
The first step we can take is to clearly and consistently communicate the higher purposes of our processes’ events at the beginning of each meeting.
“Hi, friends! Welcome to planning. Today, our goal is to leave with a shared understanding and commitment to a sprint goal we can all agree on. Then, you’ll select stories you believe will help us meet that goal. Finally, we will make sure the selected stories have easy to understand and verify customer acceptance criteria.”
Part of the team’s process to achieve these outcomes might be negotiating the sprint goal, planning poker, and clarifying functional and technical requirements. Whatever works for the team. Shared understanding will help reduce requirements defects and support a predictable and sustainable velocity.
Second, we can coach the team during events on how to stay focused on expressing the values. When we see a conversation devolving into a circular argument, we need to step in and reestablished shared purpose, respect, and trust. When scope starts to creep beyond the sprint goal, we can ask, “How does this story help us meet the sprint goal?” Sometimes it will in a way we didn’t realize. When we have a team member who struggles to contribute, we need to find activities that create safer spaces.
Again, the goal isn’t estimating stories or filling a sprint backlog. It’s a shared understanding. And that requires focus, openness, and respect. That includes respecting people who engage with social experiences differently than we do.
Finally, we must model the values ourselves. Not just in the events, but as many interactions as possible. That’s a tall order. It won’t be easy and probably isn’t possible. Making an effort and actively listening to our teams will help our actions become consistent and our values more integral. When we do, it will become easier to answer “yes” to all these questions:
Is information actively sought?
Are messengers delivering bad news trained?
Are responsibilities shared?
Is cross-functional collaboration encouraged and rewarded?
Do failures cause inquiry?
Are new ideas welcomed?
Do we treat failures primarily as opportunities to improve?
Answer “yes,” and our organizations, products, teams, and individuals will flourish.
Whichever flavor of Agile we practice, our focus must be on providing value to our customers early and often. We need to foster empowered teams and customers. And also drive sustainable delivery of technical excellence.
I hope you’ll join me in trying to act out our values every chance we get.