We have been adopting agile for over a year and a half as our primary method for designing and building software. Saying we’re finished with the bumpy evolution of our process would be misleading. It continues to change to this day. Along the way, however, we’ve learned how Agile can be implemented in a consultative environment - an environment that is often asphyxiating with fixed-bid engagement models. Even though we are a consultancy, lessons learned apply to internal software teams that need help initiating process change, as well. This article is not about why you should switch to agile, or even why folks still use the fixed-bid model, but rather how we’ve implemented Scrum in our company. There are thousands of great articles that cover benefits of iterative product design and so I’m going to assume you’re a believer looking for direction.The first step, then, is qualification.
Qualify Your Project
Not everything can be built using an iterative process, nor should it. Our primary focus today is building enterprise software, but a significant portion of our work comes form designing and implementing CMS websites. They range from simple brochure-ware to complex, multilingual, multi-site implementations, but for the sake of this example I will focus on the low complexity website.
Building a corporate site requires the team to go through a really well-defined workflow of inventorying content, establishing goals, building Information Architecture, designing visual language, prototyping, and so on. In fact, most corporate website projects are mechanically identical. Requirements are typically well defined upfront, there is little deviation along the way, and the whole team (both you and the client) has a good understanding of the end result. Finally, the scope of such a project is relatively small in terms of labor hours (less than 1500, for example). Using the rituals of Scrum for such a website would actually be wasteful. The process is too linear and there’s not much to iterate on (note: you can still iterate within each deliverable, for example, wireframes).
On the other hand, imagine designing a new digital product. The team makes assumptions. Success is not guaranteed and outcomes are projections at best. In fact, enterprise products typically induce change in process and as a result are met with a lot of critique and friction from adopters in the company. A project like this, then, does not lend itself well for sequential design and development approach, has little definition early in the schedule, and requires validation with the user base along the way. The project is also likely to be much more complex and expensive (over 1500 hours). Using Scrum, the team will be able to tackle the highest priority features first, test functional prototypes with actual users, adjust course, and eventually deliver a product that matches expectations of the stakeholders.
Qualify Your Team
There are qualifications for your team, as well. Our Product Teams usually consist of:
- a Product Owner (50% allocation)
- a Scrum Master (Team Lead, 100% allocation)
- a couple of web developers (100% allocation)
- a QA analyst (100% allocation)
- a UX designer (50% allocation)
Using two-week-long sprints, the team of five FTE's burns through approximately 320 hours per sprint. Sprint 0 is typically spent on onboarding; by sprint 2 the team would have used up more than 60% of the allocated budget. Can you see why 1,500 hours becomes problematic for a full product team? It’s like calling in a drone strike on the ant problem we have in the kitchen.
There’s also a pattern I’ve noticed from our own experience and stories shared with owners at Owner Camp. As companies grow, their internal team structure tends to shift. Smaller organizations (sub 30 employees) often have teams based on functional roles. In other words, a team of UX, a team of front-end developers, a team of QA. This introduces challenges long-term, as this structure only works for sequential project management. To truly collaborate and utilize Agile the teams must be multi-functional. That opens up the possibility for creative solutions as engineers and designers solve problems together vs. engineers just implementing what designers cooked up in the previous phase of the project.
Unsurprisingly, project size plays a large role in the transition to functional teams. Utilization of resources dramatically impacts profitability and success of a consulting company. Shifting a functional team between two projects is an expensive and time-consuming ordeal that always results in some idle time. There are kickoffs, everyone has to read through the requirements, onboard with the client, and so on. We’ve learned that engagements of at least three months is necessary to make functional teams justifiable.
Train Your Client
Last, but not least, consider the environment that your client is coming from. Scrum requires a significant amount of time from the stakeholders throughout the project. This includes contributions to planning, product demos, and acceptance. Can you secure your stakeholders for up to 15 hours a week? Will they have the time to perform sufficient acceptance on the product?
We’ve also seen organizations struggle with Agile due to their processes related to compliance, legal, and resource management. You, the Product Team, are Agile, flexible, and ready for a bumpy road ahead. Your client (internal or external), however, may follow a very different process. Team onboarding and training becomes critical in these instances, and with any luck, you will also secure the blessing of leadership to try something new. I will talk more about training and process change in the next post of the series.
To summarize, we use the following criteria to determine if Agile is a good fit:
- Does this project follow a tried and true algorithm with very little deviation (e.g. making pancakes) or does it involve creativity and change of course along the way (e.g. playing a Jazz piece)?
- Is there enough scope and complexity for the allocated team to leverage an iterative process? We look at the estimated hours and lean towards Agile for 2000+ hour projects for a team of 5 FTE's.
- Is your team large enough to warrant the overhead of Agile rituals? Not much use out of a daily standup if there are only two of you.
- Is your team structure and size ready for shifting to Agile?
- Is your client (internal or external) willing to invest time into the project and change their standard practices?
The next article will discuss day-to-day process nuances, client education, communication patterns, and more. The third and last article will focus on performance management and metrics.