The Agile Manifesto is celebrating its twentieth anniversary this year. I guess you could say we’re not exactly early adopters here in BDO Digital’s Demand Gen Group, but we are taking the plunge this year with a pilot of the Scrum methodology. It’s a substantial change from our current methodologies and there is much to learn and interpret.
We had some compelling reasons to make the change. The last year has taught us all that we need to be more adaptable and move more quickly when significant shifts in business occur. Working with our clients, we were finding that we were spending too much time up front collecting, debating, aligning, and documenting requirements to ensure we had it right. However, since final deliverable deadlines don’t easily shift, this meant less time was available for demos, user acceptance testing, and enablement.
Agile doesn’t mean “do more with less”; it does mean that we’re checking in more often with clients to ensure we’re collectively on the right path to success and adjusting when needed.
If your organization is also making this shift, I wanted to share some of the early learnings our pilot team has gained as we’ve begun our transformation and how we’ve solutioned for them.
1. Converting waterfall projects into agile sprints
One of the first stumbling blocks we encountered is that we don’t technically “develop software.” The Agile Manifesto’s genesis, after all, came from a group of software architects and developers. This methodology, however, is more of a mindset than something that produces a tangible artifact. At its heart, Agile is about delivering a completed product, whether that’s something you can buy at a store, a new home, a service, or even organization in your family life.
Scrum (one of several applications of the Agile framework) employs “user stories” to capture end user needs, which are then translated into system requirements grouped into “sprints.” Each sprint, typically 2-4 weeks long, ends with the release of user-ready features (or, in our case, client deliverables).
We have several large-scale, best-practice marketing and sales alignment framework projects that we execute for most of our clients, and we have traditionally delivered these following a multi-week timeline using waterfall methodology. We reviewed our waterfall-based project plans for our frameworks and started to break down these features, and we discovered quickly that not all the work needed translates smoothly or easily into user stories. For example, we have deliverables for business definitions, operating models, and roadmaps that have no system implementation, and system setup requirements that simply must be done.
Although some aspects of these projects fit well into a user story format, others did not. For those, we chose an approach called “time boxing,” in which we broke down the waterfall project’s requisite tasks and milestones into a collection of work we believed could be fully delivered within a sprint (the box of time, if you will). As a result, our sprint log of “user stories” is a mix of actual user stories, time boxed pieces of work, and other tasks. Right now, it looks like a bit of a hodgepodge, admittedly, and perhaps over time it will refine into mostly user stories. Our primary directives are to make sure the work is done, and the client is demonstrably seeing progress.
2. Identifying a Product Owner
Scrum teams are led by a “Product Owner,” who sets the team’s vision and priorities, and serves as the voice of the client. It is a significant role. After some internal discussions, we determined that none of our current team roles line up directly to this function.
Product Owner covers responsibilities currently owned by several different roles, including the Client Engagement Manager, Consultant, and sometimes even the Project Manager. And depending on the project work, an Architect or Analyst might even have ownership of certain Product Owner functions. Some agencies prefer to nominate the Product Owner from within the client organization, but given this is our pilot, we felt that would be risky.
What we ultimately decided is that there isn’t a certain role that is always designated as the Product Owner; instead, the Scrum Team aligns together before the kickoff to determine which individual is the best fit. Since this is effectively a leadership function within the Team, the designation of each team member to their respective role must happen at the outset.
Fortunately, our Project Managers aligned well with the Scrum Master role, and our Development Team was easy to identify once everyone understood that “Development” extends beyond actual developers. We still need to think about how Scrum Team members, especially the Development team, shift in and out over the course of the client relationship, because it’s vital to our clients that they are budgeting for resources whose skillsets are the best fit for their project.
3. Delivering on JBGE meetings and documentation
JBGE — Just Barely Good Enough — is an Agile modeling term we latched onto early in the pilot’s development. It doesn’t imply that we take shortcuts or produce lower quality work; it means we do just what is needed, when it is needed. In the Agile framework, meetings are brief and documentation is minimal. Initially, there was some hesitation about adopting the 15-minute Daily Standup prescribed in the Scrum methodology (“we already have too many meetings!”), and only a few had any experience writing user stories and acceptance criteria (as I mentioned, we had been investing more in documentation for business requirements and specifications before commencing development).
We eliminated some of the usual planning meetings to make room for the Daily Standups, and we’ve been pleasantly surprised how productive these new meetings have been. Our Scrum Master is a diligent timekeeper and does some of the prep for the Team ahead of each call. The outcome is that each member knows each day what’s been completed, what’s next, and where they can help each other eliminate stumbling blocks. There isn’t much time for social chatter and the pace of the calls can be intense, but it’s been eye-opening how much we can collectively accomplish in such a short window. At this early stage in the pilot, the improved communication and collaboration coming out of these calls is something other client teams across BDO Digital are already eyeing for their own projects!
We’re still in the early days of crafting user stories and acceptance criteria. There are many templates available online for the format of these outputs, and there is a bit of both art and science to writing these well. We also have many templates for the word-packed BRDs, FRDs, and TRDs that we’ve historically generated, and our proposed approach is instead to shift these from specification to documentation — meaning we create or populate them after the work is released. We anticipate several benefits from this approach: User stories and acceptance criteria are easily recycled into QA and UAT tasks, and we aren’t slowed down creating lengthy documents with lengthy client reviews and a multitude of versions.
Working smarter (not just harder)
Change is never easy, but it’s exciting to see it take hold. Our scrappy pilot Scrum Team has embraced the new approach, and while we know we still have much work ahead of us, the initial results are very positive. We look forward to better aligning with our client teams, strengthening collaboration through the Agile methodology, and being less focused on rigid process and voluminous documentation outputs that frankly few want to read — while continuing to maintain focus on successful delivery. If you’d like to join us on this journey to see how it can benefit your organization, contact us today.
Gaea Connary, Consultant at DemandGen, focuses on helping organizations strengthen their lead management processes, lead scoring, nurturing strategy, and reporting and analysis to get the best return on their technology investment and meet their marketing objectives.
The post Making the Move to Agile: 3 Learnings from the Start of Our Journey appeared first on DemandGen.
About the Author
More Content by DemandGen
