This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
From VersionOne Customer to VersionOne Employee – Part 1
As a former customer working with VersionOne as my agile project management tool, I’ve now crossed over to the other side by coming to work for VersionOne as a Product Specialist. I can tell you that I’ve had positive experiences so far on both sides, successfully overcoming the challenges of converting from a traditional waterfall development cycle to agile development and then bringing it full circle by helping other organizations transition using VersionOne. It’s extremely rewarding.
In this 2-part series I will explore our shift from waterfall to agile and some of the growing pains we experienced, then how we selected VersionOne to solve our problems and the things that made agile rewarding for our team.
WHY WE DITCHED WATERFALL FOR AGILE
As part of the QA team in my former job, there were days when we’d receive a build to test at 5pm on a Friday, with a note reading: “It would be great if this could go out first thing on Monday morning.” Goodbye, Friday night. And then there were times when developers were handing off their work for testing on Day 13 of a 15-day waterfall cycle, giving us only 2 days to test 13 days of development work. And we can’t forget all the bugs and outdated requirements inevitably securing the failure of completing testing by the scheduled release date. Something had to change.
We explored the idea of agile development with one team initially, and luckily that was mine. Immediately, the results were positive. The developers were speaking to each other more, and more importantly they were speaking to the testers even more. Increased collaboration allowed us to understand the requirements before development started and tests were written. And somehow an increased sense of pride and teamwork grew. Now no one wanted to fail by passing off bad code or missing release dates. The easiest way to collaborate with your team would be by just talking to them, preferably face to face – it seems so simple. But unfortunately in this day and age of digital communication and distributed teams, this is not as simple as it used to be.
It’s important to keep track of conversations between team members and any updates to the work the team is doing, in addition to conversations with external stakeholders – anyone involved in the project . In our environment, agile collaboration is key to fostering teamwork and open lines of communication. You can get some additional ideas on how to facilitate agile collaboration across your organization by watching this AgileLIVE webinar playback: “Collaboration that Scales.” It highlights some techniques for accomplishing this with VersionOne.
Now that we got the team talking to each other, this is not to say this was without its set of growing pains. We still didn’t know what to put in our backlog, how to define requirements properly in a user story, how long our sprints should be and why we needed a ScrumMaster. We needed training and an agile project management tool to help us manage our agile process. Through several agile training sessions we learned how to adopt agile development to fit the needs of our organization. We even brought in a few agile coaches to help us execute an agile methodology that worked for us. VersionOne not only offered an agile planning tool, but also brought professional services like agile training and coaching to the table so our team could get started on the right foot.
In Part 2 I’ll dive deeper into our experience with VersionOne and how agile collaboration helped streamline our transition from waterfall to agile.