I’ve spent the last few years consulting at a large enterprise retailer that has traditionally managed IT projects using a waterfall methodology. It made sense—being so large, the company is very silo’d with separate IT departments for different functions and a strong business operations team that constantly gets feedback from the field. A structured requirements and design process with very specific scope was a necessity, as budget was allocated to “projects” at the beginning of each year.
But a few months ago, some of the IT leadership started to push for projects in the new year to be managed with an agile methodology (which included the teams that we were working with). I had a lot of doubts as to whether this would work or not, mainly due to the size of the organization and because only a portion of IT was to use agile.
Some of our team members have had experience with agile in smaller organizations, usually startups, but this is a different beast. As one of my friends often jokes: “Agile is just waterfall without requirements and design.” I thought that’s what it was going to be, but a couple of months in, our progress has exceeded my expectations.
The first few weeks of the project I tried to keep a positive attitude, but was definitely cautious about how this was going to turn out. Some of my initial questions about how things would work were:
- What was going to happen when we needed some data modeling work from a team that didn’t use agile?
- How is testing going to work when there’s an entire department dedicated to QA?
- How will non-project work, like production issues or helping other teams, be integrated into the process?
- How will deployments work with continuous integration? We can’t just deploy to every retail store in one day (current process take 6 weeks to get everywhere), so how often are we going to have production deployments and how quickly will they roll out?
Within the first few days my skepticism grew. What’s with all of these meetings? We really need 4 to 8 hours for sprint planning? AND we’re going to spend hours preparing for and doing a demo at the end of each sprint. How does that make us more productive if we’re spending all of this time in meetings?
Here are a few things that our team has figured out so far:
Since those first couple of weeks, we’ve learned and have grown a lot as a team. I wouldn’t say we’re functioning at our peak yet, but I think things have worked out better than I expected.
- We had 2 solid weeks of Sprint 0 to start the project to complete tasks such as: environment setup, build setup, high level design documentation, etc. We didn’t complete everything, but it definitely set the project up for success and we really hit the ground running on Sprint 1.
- The first sprint planning meeting was a long and tedious process, but since then we’ve all become more efficient and comfortable with the discussion.
- It’s so much easier to see what everyone is working on and the progress we are making (a project manager’s dream). We’ve been using Jira to manage user stories and sub-tasks, which has some limitations and sometimes causes frustration; but generally it gets the job done.
Some Growing Pains
Here are some of the pain points we’ve encountered that we’ll look to fix in the upcoming months:
- One week almost the entire team was at a local developer conference and was out three days. We tried estimating this during the sprint planning meeting, but we underestimated what impact this would have. When this happens again—like around 4th of July—we’ll be more prepared to estimate properly.
- As expected, relying on teams and departments external to the project has been challenging. While we try to drive each user story to completion by the end of the sprint, the other teams are on their own timeline and often don’t prioritize helping us because it’s not their project.
- Recently there’s been some last-minute requests from outside teams that require work and time from our team members. These aren’t included in the sprint user stories, so how do we track these? And how will they impact our burn rate? We talked about adding them as tasks so that we can at least compare our burn rate across sprints (e.g. one sprint we have two non-project tasks and the next sprint we have six non-project tasks). We’ll need to figure this out.
I have no doubt that we’ve been successful because of the strength of all of the team members. We’d probably be just as productive using waterfall methodology too, but the fact that everyone has picked up the changes so quickly and effectively is a testament to the talented team members we have.
It will be interesting to see how our first production deployment goes in a few weeks and how much time is spent on that versus other user stories. I’m looking forward to a retrospective in a few more months to see how we’ve progressed.