Water Falls Away
So, after getting back from an unanticipated extended vacation in Toronto, started updated all of our product planning. I got everything back to the way I thought it should be.
And then it hit me when I saw this line come through from my CTO:
“We’re waiting on requirements”
…this in relation to a new product launch we’re working on. I have been mortified ever since reading that. On the way to a great weekend in Dallas with friends, I spent the entire 2 1/2 hour plane ride from LAX to DFW thinking, “how can I stop this from happening again?”
Each time I started thinking through us developing in an agile-like environment, I would hit a wall of, “and then we move into product design.” Wait. We don’t have any design expertise in-house. Or even externally that we can call upon.
But then, the next day, I received an e-mail from our lead VC asking me to phone interview…wait for it…a usability expert. So sweet. Perfect. Plants align. Let’s see if this person can help - keep your fingers crossed, folks.
OK, so now what? Well, we are working on a couple of big things at the present time — as I mentioned, a new product launch, but also, a big upgrade (of sorts) to an existing product. That project has one of our senior-level developers attached. So what did I spend some hours working on this weekend?
Taking what I had started as a waterfall-style requirements document and turning it into user stories. Yes, sir. Here we go.
Now, the beauty of this scenario is, everyone at the company is currently amp’d on getting user feedback before releasing. Mission accomplished there. So, what I’m embarking upon isn’t an “overnight change to proper agile methodologies.” No, no.
We are already doing agile-style stuff. But what’s the next piece of the puzzle? Putting trust in the developer’s hands to be accountable to working through details. And, pushing more estimates and risk assessments through dev.
Now, we won’t get to assessing risk right away. I also won’t be graphing up project velocity tomorrow either. The name of the game is, “here are the stories, work with the product designer on the UI, and we’re all going to meet (technical writer, QA, dev, product, design) every day for 1/2 hour after lunch to discuss what’s been done in the last day, and what will be done in the next day.”
This also helps to move away from a structure that gave me major headaches while trying it push out another product revision. The developer lost track of requirements, I wasn’t keeping tabs on the development status well enough, and folks were being brought into the project at waterfall-style times.
It’s like we were trying to do agile stuff, but forcing those pieces into waterfall-like structure. Yuck!
But I think I’ve figured it out. But like I said, I recognize that it won’t be an overnight change - it will take time. And will we follow an agile methodology to a tee? No way. But, after living and breathing our development for over a year now, and learning and growing more as a product manager, I now see how valuable some of those practices are for us as a team.
And hopefully, it will keep our CEO happy. He loves to see product ship - and see product ship that’s going to help us accomplish our financial goals. So, with quick reactivity to the market / and FOI (”flashes of innovation”), we’ll be able to speed up dev, but speed it up responsibly.
I don’t know why I slipped back into waterfall-style thinking. But I’d like to thank Jeff Lash for breaking me out of it. We had exchanged a couple of e-mails last week, and a couple of things he said broke me out of that. Thanks, Jeff.
