What’s the best way to learn the Agile development methodology? Some teams take a gradual approach, easing their way into the new methods and principles. But for our team, which was developing the Intel Software Market (a centralized enterprise app store), we chose to dive in headfirst and become Agile overnight.
Now, this wasn’t easy. In fact, one of the reasons I’m sharing our experience is because it was such a significant learning for us. But it did enable us to deliver a usable product in a reasonable amount of time.
Our first challenge was simply learning the new terms and how SCRUM really works—sprints, standups, stories, tasks, asking the right questions, writing good user stories. Team members went through a quick SCRUM course, and one of the members who was experienced with SCRUM became our diligent SCRUM master.
In SCRUM, each feature is developed according to a user story that takes the form “As a [role], I want to [purpose], so that [result].” Now that might look simple. But phrasing these stories correctly is crucial to the success of the sprint, so developers can efficiently plan activities.
My role was story owner, in addition to being the project’s integration engineer. Initially, it took me a lot of time to develop these stories. In fact, it took 2 or 3 months to learn to write stories the SCRUM way. And my SCRUM master grilled me all the time!
Other roles had similar challenges. Developers learned how to accurately assess the work and how much time it would take for each feature. The planner had to translate my stories into tasks—again not necessarily a straightforward process. But as I got better at writing stories, this helped the planner. The entire team learned from each sprint.
We all had to learn to do things differently from what we had done before and become accustomed to the intensive nature of the SCRUM process. We were no longer masters of our own time—every second was managed. And although our team is flowing and fun to work with now, we did not achieve that level of productivity without friction. In fact, we had to go through a forming stage again (the other stages are storming, norming, and performing). Sometimes it was stressful. But most of the time, people were in good spirits as we worked through the challenges together.
Today, we continue to use SCRUM for other projects. It has become easier for us, and the team has definitely reached the performing stage.
I hope sharing our experiences with moving to Agile can help other teams do the same—especially those who may be hesitant to make such a move. I’d be interested in hearing other teams’ experiences, tips, and tricks for implementing Agile development, and I encourage you to read more about our enterprise app store efforts.