Agile is a great framework for new teams to bootstrap initial expectations about roles and responsibilities. As the team progresses from forming through storming, norming, and performing, success depends on evolving those baseline expectations into real, earned trust. No process can fix a team where trust does not exist. Once trust is built, the team can be successful with any process.
It’s right there in the Agile Manifesto:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
My Favorite Career Moments
Whether it was as an individual contributor, tech-lead, or front-line engineering manager, the best projects in my career correlate 1:1 with having excellent trust with a product partner. Especially in the second case, I could have easily balked at the idea of committing an entire team to a fixed deadline project with no defined product spec. But, I would have missed out on one of my favorite career moments.
Bullhorn Reach
Early in my career, I had worked my way up to senior engineer, and then a tech lead of a small team. I had an excellent relationship with a pretty junior PM, after working well together on normal product backlog stuff for about a year. We were an Agile team. One day, the CEO asked if just the two of us wanted to work on a special project.
We took a PowerPoint mockup directly from the CEO, threw out most of our process, and built a new product from scratch. In a couple of weeks, we had the basics up and running, on totally new infrastructure. Over the next 9 months, we iterated and eventually ended up with a $10m revenue stream. Along the way, we added more team members and added back a more Agile process. But the early weeks and months were the best part.
Using the basic Agile framework and roles, we broke stories down into their barest essence. We tracked our work on a physical bulletin board. We had daily stand-ups and demos. But we didn’t estimate anything. If I had a product question, I would just turn my chair and say it out loud, and we would answer it together, right then. At the same time, the PM was learning to code. We would spend our lunch breaks pairing together.
None of this would have been possible without a baseline of trust. I trusted this PM to make the best product decisions he could, he trusted me to make quick technical decisions, and the organization trusted us to deliver on an open-ended problem. We both trusted that the company would recognize the effort, in the end.
NerdWallet Mobile App
When the General Manager scheduled a 1:1 and asked me if I could ship the company’s first mobile app by Christmas, I thought he had gone insane. The company didn’t have any mobile engineers. I don’t even do front-end, my specialty is back-end services. And, Christmas was six weeks away at this point. He asked me what I needed, I told him, and we went and got it done.
In the end, we gathered six of the best engineers in the company, canceled everything else, and locked ourselves in a room. We had a working app in two weeks, and we got a more polished version submitted to the app stores in plenty of time for the holiday deadline. Plus, we shipped on both iOS and Android.
The core of the team was me as the TL, plus my existing excellent PM and design partner. There is no way we would have gotten this done with a new engineering/product/design cohort; the trust we had built up to that point was critical. We defined the scope in about two hours. We had wireframe mockups by that first night. We picked a technical platform, React Native, over lunch. We all trusted each other and knew we had to optimize for development speed.
Again, we threw out a lot of Agile processes, but the core remained. We didn’t do estimates, but we did refine the scope regularly based on what we learned. We canceled all meetings, including retrospectives and 1:1s, but I felt like people were never more engaged and growing. We worked at a sustainable pace, no overtime, by remaining flexible about scope.
Some not-so-great Moments
Hearsay Social
This was a different team that was struggling with the basics. Missed deadlines, confusion about the scope, quality problems, you name it. Coming into the team, I attempted to quickly move from zero process to an Agile process. But, we didn’t have the requisite trust built up. The team ended up losing some senior talent, restaffing, and THEN adopting Agile.
In retrospect, there was a real lack of trust between the cross-functional leads on the team. The senior engineer didn’t trust product to prioritize correctly. Product didn’t trust the engineers to make scope/time trade-offs. I didn’t trust the team to execute against a deadline.
My main learning from this experience was that Agile is not going to fix a lack of trust or team cohesion. No process can fix that, at least not by itself. What we should have done is focus on building trust first, and then work on process second.
NerdWallet (again)
My last team had been re-orged, and their product roadmap was put on hold. There was a vague idea for a new product, but no specifics. I was pushing to continue wrapping up the existing work, paying down technical debt, etc, until we had a product spec. Specifically, I was determined that we needed a product manager to guide the work, or we couldn’t start it.
The counter-proposal was that I fill in as the product manager, in the meantime. In retrospect, this probably would have worked fine. But I was too hung up on the process, and the idea that the team could not be successful without a traditional product owner. The issue exacerbated a relationship with our head of product that already had some trust issues, due to a previous misunderstanding.
This hurt my creditability with the head of product and ended up with me leaving the company. Again, the core issue was trust. No amount of adhering to process would have repaired that trust — and if we had that trust, we would not have needed to adhere so religiously to process. If I had handled this differently, maybe this could have been a third highlight project.
Conclusion
Just recounting the first two projects, I can’t help feeling that these should have been stressful, and likely failures. But, they weren’t. The lesson that I draw from them is not that Agile is too heavy-weight, or not necessary, or should be paired down. It’s that a team can do anything with enough trust. For me, Agile has always been best for steady-state teams, and it builds teamwork and trust in the team that you can leverage for the genuinely exceptional times when you throw it all away and just execute the heck out of something.