If you know me then you know, I love lists. I love organizing lists and I love schedules. I love organizing lists into schedules and it’s kind of a sick love but it’s one that can’t be denied. So as I got into the product management game in 2010 the term ‘agile’ was still making it’s way into the world of technology. At the time I was working for a small technology company, we were growing and needed to start using processes to increase our capacity to release great products. A coworker introduced agile and scrum methodologies and at first I was not impressed. It felt like process for process’s sake and I was very reluctant to use/learn it.
But after 11 years, I’ve traversed the agile spectrum and have used different flavors of agile, on teams of all sizes, projects of varying difficulty and along side/on top of/underneath waterfall processes and have figured out that there is a lot of flexibility to make it suit the needs of the team over anything else.
If you are unfamiliar, you can read the whole reason for agile here: https://agilemanifesto.org/
And of course there is a bajillion resources out there to read, get certified and become an agile super hero. For the purposes of this post, I’m going to talk about Scrum, a flavor of agile, that is mainly for planning, executing and delivering functionality in a time-box. For an organization, you can see the appeal of being able to condense and squeeze out as much productivity in a predictable time frame would have but the biggest mistake I’ve made and have seen made revolves around trying to shove the team into a process that doesn’t work for them.
When looking at agile and integrating a process it’s really important to define the objectives and goals clearly. Trying to iterate and release products faster? Have a need for the team to work in a more predictable/organized way? Want to report on velocity and figure out how to estimate better? There can be lots of problems to solve for but it’s important to know why you need agile before trying to apply it.
If you can, get certified. There are so many organizations out there with the main goal of educating teams on agile. Personally I’ve worked with Scrum Alliance and really, really enjoyed my experience. It’s an investment but worth while if it means that teams have a shared understanding on what agile can do. When I got my scrum certification it opened my eyes to the depth and flexibility you can have with Scrum/Agile.
Working in an agency setting, I have found very little information around apply agile when the types of projects, team size and organizations vary widely and bobbing and weaving for your clients is crucial to delivering top quality work. What I have discovered is an agile journey can be customized to fit the needs of the team, starting with these three components:
Timing
Example: If it’s a short timeline that won’t accommodate sprints then we can create a roadmap that’s more waterfall focused with due dates or use a continuous Kanban approach
Teams
Example: If it’s a large team, calling into a daily standup might be a total pain, do a virtual one instead. Maybe the team hates creating story point estimations or roll their eyes at planning/estimating. Skip it.
Touch points
Example: There are a lot of scrum ceremonies. If the client doesn’t need a demo of work completed then make everyone have one less meeting to go to and send release notes. Scrum ceremonies can be leveraged as a way to check the health of the sprint/project so use them as milestones instead of meetings.
Recently I’ve started to learn more about applying agile to the design process as design or research sprints, I’m excited to learn more about this and figure out if it is flexible enough to allow for adequate testing, user feedback or iteration. If you want to know more about agile in design, the podcast What is Wrong with UX has a great episode all about Problems with Agile in UX.
Finally, and most importantly, be flexible. In the last 11 years I have yet to encounter an organization or company that is 100% agile or has the team to completely support an agile process T to B (top to bottom). Every team is different and sometimes being agile-ish is more important to create the improvements you are looking for.
