Back in 2002, I didn’t have a clue about how much Agile would change the world of software delivery. But Agile did feel right; so my small team at the New York Stock Exchange went for it. Why? Honestly, I’m not sure we totally knew why – as I said, it just felt right – and certainly it felt more fun. But I definitely didn’t realize the tremendous benefits we would gain from it. Fast forward to 2015: I’m a seasoned veteran of creating agile teams. And maybe by “seasoned” I mean, “Yada, yada, yada. Here we go again. Okay, let’s organize into small autonomous teams; let’s estimate in story points, blah, blah, blah.”
But recently, I had this unexpected moment of tremendous pride. We’ve been doing Agile at Tasktop for years, but in the last 6 months or so our engineers and product managers have elevated the way we do Agile to a whole new level. Why? Well… this is the cool part. How it happened is sort of odd and, I think, inspiring.
Tons of people and organizations talk about doing Agile, and you hear talks at conferences, and read articles online and think, “Wow, they are really doing Agile,” we are just mere amateurs compared to what they are doing.” So, about six months ago, we sent all of our product owners and scrum masters to training… and it changed everything. They came back, and independent of one another, reached the same conclusion. They thought they were going to learn about the things we need to do to BE agile. Instead, they learned that we already ARE agile. And I watched everyone’s confidence level go up a notch or two. And I watched them take that confidence and apply it in a truly amazing way. Since we were already “really” doing Agile, our product managers and scrum masters topped what we were doing—taking us to an even better place. And that makes me proud to be a Tasktopian. I thought it would be helpful to other agile teams to share how we make Agile happen in a way that has allowed us to take it to the next level.
Things we do:
- For almost four years now our release cycle has been six sprints followed by “JOG” week (stands for Just Over GA). Our field loves it and our customers love it- because it is consistent and reliable. (And our finance guys like it too since it means we release quarterly ;)). And I’m proud to say we have never missed a release date. What I love even more is that while we release every quarter, we could release anytime. In fact, we do release to many customers mid-release cycle to allow for experiments and early testing. Continuous delivery is ingrained in our teams.
- “JOG” week is cherished. This is where teams “re-charge,” but they also do (imo) the most important part of Agile: they talk. And they talk. And they talk. About new features and new architectures.
- We tag every story as either tech debt, defect, or user story, and at any given time, our engineering management can report on the % of “true business value” we are delivering. Business value is a tricky thing for many engineers to internalize as the key ingredient. I frequently find myself saying things like, “What do my users get? Are they getting something? How will it help them?” We harp on the fact that tech debt and defects are an inevitable part of software, but we want to measure business value. So if our user story percentage falls below 70% or so, we take a hard look at why. Because user stories are the only things that deliver business value. Period.
- Every story is part of a feature that is articulated in business speak and includes descriptions that focus on the problem we’re solving and for whom (not what we are building).
- We really do “commit” as teams – each team stands up during JOG week, each team stands up and tells the story of what they’re going to deliver in the next release cycle. Their hearts are in it, everyone is on the same page, everyone is committed to working as part of a team, and everyone is committed to the business.
- We also have a special “Fast Track” process where entire features, not just stories, can be switched out mid-release cycle if business needs warrant it.
- Our teams are smaller than the teams of our Fortune 100 customers, but we recognize the value of SAFe (the Scaled Agile Framework) and we use it (see my colleague’s blog about SAFe). We also drink our own champagne. Our features are in TargetProcess, because our product owners find that tool best suited to their needs, and our stories are in JIRA, because our developers find that tool best suited to the way they work. But our tools and teams are inextricably linked. And using Tasktop to implement our Requirements Traceability pattern, we’ve had great success enabling collaboration among all of our practitioners and we make sure they have the right information at their fingertips and in the tools they like to use.
- Every team has a standard “Release Progress” page with two very distinct pieces. I call the pieces the “numbers bit” and the “gut bit.” The numbers are the standard burndowns (Actually, we call ours our “burnups,” because it’s more inspiring to see things go up rather than down ;)). The second piece, the “gut bit,” is the piece I find more interesting. As we know, Agile is about communication, and numbers don’t tell us everything. That’s why we created a space on the release page for weekly commentary from the product owner and scrum master– with the fundamental questions considered: Gut feel, are we going to make it?” This type of communication is extremely valuable to the teams and to management.
And, believe it or not, there’s more. Last week, Tasktop had its annual “Thanks-for-givin’er” company party (otherwise known as Canadian Thanksgiving). I was chatting with some of our engineers, and Dawn, one of our team leads, said, “Nicole, This is the first time I’ve seen a large team that truly embodies what Agile is all about. At my last company, we held a daily Scrum and estimated in story points, but here we take Agile to a whole new level. We really do it!” And, in typical Tasktop fashion, another team lead replied, “Yes, I agree, but I think there are still some things we could do to improve.”
That is when I realized that you’ve really “made it” as an Agile organization when you have an extremely reliable, resilient, robust foundation that supports the way you “do Agile.” And the ongoing fine-tuning, the tweaking, is “decorating Agile” (reminds me of the classic GoF decorator pattern). You’re making it more workable, more comfortable, more suited to your teams, your delivery style, and, most importantly, more in-tune with what drives your business. With our stable foundation, the backbone of our Agile practices in place, we can continually innovate and experiment – paying particular attention to the special nature of our products and business.
So my message to all Agile teams is: take a step back and revel in what you really do. I bet there are many teams out there that have quite a bit to be proud of. And, I hope many of you are already at the “decorating” stage of Agile. For those who haven’t quite reached that point yet, know that it is absolutely attainable. Believe in your ability to build an Agile foundation that will not only hold for the long term, but allow you to continue to accomplish truly incredible things on top of it. We should all be inspired by that.
