A colleague had previously asked me about using the Agile process in marketing. Since my last post on this topic, I’ve actually joined several Agile teams as a member and gotten to see how differently they do things and the different tools they use. One of my friends who I recently had lunch with is also a Product Owner for another team and they do things in still another way. Yet, many still face the same hurdles. Here are tips from my conversation with him and my own experiences.
Some of the issues of translating Agile to non-software development teams impact software development teams as well but some I think is especially important to address are below:
- One big issue that many non-software teams face is lack of control over timing and components of Stories. Either because they are in highly hierarchical work situations or because of the break-neck speed of start-ups trying to secure marketshare before they run out of funding, the Agile team doesn’t have much control over new Stories being added to their Sprint or the Acceptance Criteria of the Story. One way that that my friend the Product Owner addresses this is with a “fudge room” Story in each Sprint. Basically, his team reduces the number of Stories they take on each Sprint, just in case they get a large, urgent request dropped on them. He advises his stakeholders of this and that, accordingly, they will accomplish less of the other work expected of them. The hope is that this will inhibit stakeholders from forcing falsely urgent or large Stories on the team, to ensure that the regular work gets done. It’s not perfect but it is indicative of the creative solutions Product Owners sometimes need to take to protect their teams.
- As noted above, sizing Stories to fit the time-constraints of the current Sprint is common challenge but it is not limited to situations where Stories are dropped on the team from outside. Teams often do this to themselves with poor planning. The goal of Agile software development is to move fast. This requires crafting Stories that are small and often the result is going live with a minimum viable product and improving upon it. This isn’t always a natural instinct for people used to working on complex non-software projects, though. For that reason, sometimes people will not do a fantastic job breaking down Stories into discrete chunks that fit into reasonable-sized stories. This is when the team needs to review the Story and its acceptance criteria and test it against the INVEST mnemonic until its sized correctly.
- The world’s workforce is going increasingly mobile. Your Agile processes and tools need to support geographically-distant members. The tools need to be accessible via the cloud and the meetings need to occur at a reasonable hour for the various time zones people live in, especially for meetings that occur every day like Stand Ups. I know this sounds obvious but you’d be surprised how many teams forget to think about people they don’t see every day. How productive to you think people are when people are struggling to reach the office or get the family out the door to reach the phone in time – or to stay awake due to the late hour?
- Everyone on your team has to have the same level of skills, in the same areas, or some perfectly complementary balance or sharing the work on Stories will be challenging. This is real problem when working on marketing or other cross-functional teams. You often get experts in a one area but with no experience any other or you’ll find levels of skill vary wildly, from new hire to 20 year veterans. In these cases, the team members have to speak up as to what each member can contribute to a story. Junior people may volunteer to do the grunt work or other members of the team may need to make the suggestion. Similarly, senior people need to be willing to let some elements that they may want to pursue from personal interest go to someone else who has more time.
- The suggestions above, of course, assumes that everyone on the team understands the stories well enough to suggest a way to contribute. This is often not the case. However, teams are sometimes unwilling to spend the time in Sprint Planning to define Stories in sufficient detail or list out all the steps in the description or acceptance criteria. The result is poor execution or a few people working very hard on many stories while others have an unfortunately low workload, contrary to the fundamental concept of Agile of sharing the workload make projects progress faster. Take the time and detail out the Story and the acceptance criteria with the same level of specificity that you would present a project plan to a new team in a non-Agile setting.
There are some great tools that have sprung up to support the Agile process and overcome some of the pitfalls above. The most important one is the actual project management software you use. Many marketing organizations have invested the time and effort to use the same Agile project management tools that software developers use while others are starting small. Below are some of the tools I or friends I know personally have used and reasons why they work for different types of teams:
- Jira – This popular software has as a great interface for hosting Backlogs, tracking Sprint content, and defining Epics and Stories (with detailed description and acceptance criteria fields). However, it really is designed for software development and includes such features bug fix resolution drop downs and other things that are not useful to non-software developers. Marketing teams will need to either ignore these features or translate them to other meanings. Plus, the interface is less than intuitive. Many other software development type Agile project management software have similar pros and cons.
- Mural – On the opposite end of the spectrum from Jira is Mural. It was originally designed for storyboarding but has recently ventured into the world of Agile project management. It’s much more visual than Jira so it’s easier to understand and use for a novice but it also doesn’t have dedicated spaces called out for all the rituals of Jira. Some people like it for that very reason, especially if they are using the Kanban method.
- Trello – I’ve never actually seen or know of anyone using Trello for Agile (only for Sprint Retrospectives) but, based on my personal usage, Trello seems to be a mix of the two systems above, with a better user interface than Jira but more project management elements than Mural.
- Wiki — Some teams just starting out with big intentions but small budgets use the methodologies and regular productivity software to execute the ceremonies. Backlogs of stories are tracked in spreadsheets, for instance, and uploaded into a wiki that lists the elements of the current sprint. Frankly, given the number of changes in process each of the systems above require to be adapted to non-software projects, I’m not convinced using the wiki/spreadsheet method is that bad, regardless of what Agile purists would say. If nothing else, using these basic tools would force the team to really consider each Agile ceremony and adapt their use of the software carefully and with great intention, which is really all you can ask of a new team embarking on an Agile journey.
Comments are welcome, especially if you have faced some of these or other potential pitfalls or found software that helps you use Agile.