Your Personal Treasure Map

Recently, a colleague wanted me to talk to her client about marketing transformation, including the potential use of the Agile software development process. As a strategic partner to the client, she wanted to help make their transformation more successful and had looked me up in our company directory as someone who knew about their type of transformation (based on customer journey mapping) and see if I could share any learnings with their Chief Marketing Officer.

Agile is just one way to address the way you manage your project. It’s very popular right now, with some people seeming to think that it is somehow a guaranteed way to achieve your goals. It’s not. It’s a methodology, not a treasure map with a pot of gold at the end.

It’s also not for everyone, certainly not for marketing transformation teams that are not already using Agile in software development (since you will need to rely on other team leads for advice a great deal in the beginning). There are many alternatives to Agile, including Six Sigma or Project Management Office (PMO), to help you think through process improvement and especially in measuring results in terms of customer thinking, however, it is very useful in certain situations.

One great benefit of Agile in non-software development projects is that it forces you to think in terms of results, not activities. Specifically, you have to break down your project into “epics,” then break those down into “stories.” Both epics and stories have to be constructed to clearly state how the tasks relate to the end user. An example is noting that creating a skills assessment and aligned education program will allow a marketer to determine which training courses to take to build more effective campaigns.

A side benefit I really like is that this way of linking activities to end results, shared during team meetings called “ceremonies,” allows everyone on the team to understand the connections between activities and ensures that they remain on track with the project’s ultimate goals. Agile also requires you to time-box tasks so they fit into the current work period (called a “sprint”). That helps diagnose problem areas that are not making progress and need more help.

For that benefit to kick in, though, you have to be incredibly realistic about not taking on too many tasks at any one time. You also have to be really clear on what constitutes completion, with no fudging or extending or changing (at least until next sprint). This allows priority tasks to get done first and, generally, more quickly than they would if team members were pulled in other directions by other tasks. Coincidentally, having a set of clearly defined set of priority tasks done each sprint also generates a really nice set of data for reporting progress to stakeholders.

If you move forward with Agile, you must ensure that the team members leading the adaptation of the Agile methodology to non-software development for your team are the right fit. Be especially careful when selecting the “Product Owner” and a “Scrum Master” as they will help set up the program and keep it on track over time.

In Agile, the Product Owner, stands in for the end user, defines what needs to be created, and ensures that the team stays on track to create that. I am the Product Owner or our team, however, we changed my title to “Visionary Guide” since we didn’t have a product per se. I think that change is really helpful, as it describes the role this person is expected to have under the modified Agile process.

In contrast, the Scrum Master is the person who ensures that checkpoints occur, that tasks are completed or problems are resolved, and so on. Since the Scrum Master owns the process, she must be well-trained in the traditional Agile process, otherwise you won’t be able to translate those to non-software development very accurately.

Lying is bad so I will tell you flat out that adapting Agile to a non-software development project was hard. It got easier over time but the time involved – especially in the beginning – is not trivial. However, I think that thoughtfulness actually helps people stay on task and better aligned.

Why was it so hard? Because everything in Agile serves a purpose related to coding software and you have to translate those terms and processes into something for process development, selecting a vendor, implementation, and so on. You have to translate what a completed task means in a non-software development sense. You have to determine what your team can realistically get done in single sprint (fyi, my team skipped the idea of using points since non-software development tasks are harder to quantify at such a detailed level compared to coding). You have to train yourself to define your project’s elements from the end result backwards when you define your stories and epics.

This translation process requires a Visionary Guide who has a very clear idea (or vision) of how all the dots connect practically and what the ultimate result will be like and a very practical, detail oriented Scrum Master. And all members of the team have to be willing to be flexible and adjust if the process is not quite perfect the first time—or the second or even after the third adjustment. It’s called Agile, remember…

Whatever else happens, one thing to keep in mind is that Agile – and any other project management system – doesn’t work if there is lack of commitment by participants. If a team member consistently does not update his stories or attend meetings, you have to be willing to remove this person from the team. If you can’t get participation in setting up the tracking process, you are much, much more likely to have miscommunication, missed opportunities for better alignment, and general mistakes.

Don’t be intimidated. Take the initiative like and learn about the options like I did and you may find Agile, Six Sigma, or some other process matches your organization’s situation very well. If you choose Agile to help you manage your project, look at all the content online abut adapting Agile to non-software projects. It can be done and it can help improve team cohesiveness and production.

Comments welcome, especially if you have examples of how your organization uses Agile in a non-software development situation.