Engineering Blog

My first exposure to Agile was a disaster. I didn’t even know we were trying to be ‘Agile.’ One guy read a book about Scrum and presented it to the team. We really liked the idea of avoiding a lot of up front design and documentation, but we weren’t so keen on testing, pairing, regular releases, or daily stand-ups. Our development practices might best have been described as ‘chaos.’ As you might guess, that Agile roll-out didn’t meet or exceed expectations. It was a dark time, and I prefer not to talk about it. I think we should move the goalposts, say that wasn’t really Agile, and – presto! – it doesn’t count.

So: my first real exposure to Agile was an unqualified success. The team started from the Agile Manifesto, laying a groundwork for why we were implementing these practices. We used a scrum-like process and we fostered a discipline around our practices:

• ALWAYS test first; If it’s not tested, it doesn’t work
• ALWAYS pair program
• ALWAYS commit your code at the end of the day (if it’s not done when you go home, revert and start over the next day)
• Constant (read: daily) customer involvement on every story

At first, the team struggled. We threw away a lot of code. But our focus on the process rather than individual work items was critical! Every story is special in it’s own magical way; there’s always some reason why this story isn’t worth testing, or why that could be banged out by a solo programmer, or how this story is almost there! I just need to work an hour on it when I come in in the morning. Our focus on the process encouraged us to look at why those ‘special’ cases came up, and what we could do differently as a team to minimize them. Getting an individual story through wasn’t our goal; enabling the team to consistently get any story through was.

Throughput was up; quality was high; customer involvement and satisfaction was through the roof. Every developer knew they were working on the right thing – or, at worst, they only lost a few hours of development time. We were able to respond to customer feedback on the order of hours; average response time for other teams in the organization were on the order of days. Life was good.

So – why did I leave? Why come to Rally?

As you may have gathered, I am in love with Agile. My personal job satisfaction was higher when I was on that team than it ever was before. I KNEW that I was delivering value; I talked to the customers almost every day and they told me so. For me, Agile is the way to do software development and I never want to go back to any other way. Rally’s product helps teams be Agile, and that is cool. (Maybe not rock-star-cool; my family’s eyes glaze over when I tell them what I do. But I think it’s cool.) We use Rally in Rally; I am an expert user of the product I develop. It’s hard to conceive of a shorter customer feedback loop that that!

But most important: as a company that sells the tools we do, we have a baked-in commitment to creating agility.  This is magic; there is understanding at the core of the company that these ideas are valuable and are worth implementing.  Being Agile is hard; continuous process improvement is hard; but I know that everyone in the company is focused on making it happen. Our debates are not about why we should be Agile, but about how we will be.  And that’s why I came to Rally!