How did I get into Agile?
Working in ecommerce strategy in 1999, I was advising business leaders on the use of the internet. My team’s focus was working with both corporations and entrepreneurs to identify new business models and start innovative technology businesses. It wasn’t until we were asked to get involved with some projects that had gone awry that I realized how much my team worked differently when compared to our core web development team. While the team members were experienced developers and highly trained project managers, each of the projects that we reviewed had one common denominator- lack of alignment between what the clients wanted and what the development team delivered. As a result, clients were dissatisfied, and the team was at an impasse because the process they used was not outfitted to deliver the best results. As each week passed without resolution, the bills on both sides piled up so finding a solution both sides valued became the priority.
I found myself in a mediator’s role. First, I would review requirements from the project manager and then would listen to the client lead to better understanding where there were misses. It became abundantly clear that the project manager was doing her job superbly and that was leading the team right into a trap. The insight was that a project manager’s job was to follow the plan which are the requirements, but the requirements were changing, and changing rapidly, because the market was rapidly moving and evolving. The project manager was frustrated because the client wanted changes and the project manager was under the impression each change was taking the project off course rendering a defunct roadmap. In my team, projects had high uncertainty in identifying and developing new business models, so we never went a week without client feedback and discussion of direction which had allowed for changes and learnings to drive priorities. At that point I realized that the way my ecommerce strategy team was working was more than our finesse, it was an approach to help navigate when there was no clear path, and it might help fix these types of situations too.
The process for software development used by the core teams’ project managers was what was taught and the common, proven approach: a simple set of steps sometimes coined “waterfall”:
- Discover – the requirements
- Design – the architecture
- Develop – build
- Deploy – to test and deploy
However, this process was broken because it took months and the client was put “on the hook” to know exactly what they wanted upfront which, many times, was either a situation where the client was unsure until the deliverable was seen or until the customer tried it. If the outcome was known, the common waterfall process had worked well. In uncertainty as with the projects I assessed, the waterfall process did not work so well. These projects were, in fact, new-to-the-world ideas or new approaches to technology that included a reasonable amount of uncertainty. It became clear that shorter cycles and more feedback were needed to drive success and mitigate uncertainty. When my team and I reworked the approach with the project manager and showed the client intermittent demos to discuss changes within that short cycle, it was magical. The client felt empowered and team satisfaction skyrocketed because they were progressing, albeit a vague target, toward the client’s vision. The project manager could still do their job, only now in short, frequent cycles or “sprints,” allowing the client to review and align before beginning the next sprint.
Similar situations were happening in many new-to-the-world projects across technology with business startups and new products where an elevated uncertainty existed. Of course, at the time, there were a mix of methods such as extreme programming (XP), the spiral method, adaptive software development and SCRUM, trying to address this problem, but nothing was yet well understood or accepted. In 2001, thought leaders, who had been working to solve this type of project problem, assembled and started what became the “Agile Manifesto” for software development. Agile has become a major influence on project management frameworks that has improved the performance of many organizations.
At Valen, I have applied my form of Agile to the firm’s methods since its inception over 20 years ago. As an entrepreneur, the Agile approach made sense as an effective way to quickly drive value when tasked with projects accompanied by high uncertainty. Valen has adapted a variety of principles inspired by the Agile Manifesto to fit the firm and drive our growth, innovation, partnership, and supporting insight approaches. These principles are:
- Satisfying the customer – is the highest priority and results from a cadence of review and refinement with the customer to ensure value is delivered (the customer is the client, channel stakeholders, and consumers/end users)
- Requiring a client and Valen sponsor – to align and support the team’s needs, build engagement around motivated individuals, and foster an environment of freedom and trust to allow them to communicate the facts needed to decide the next steps
- Creating agility – specifically in engagement design, to be able to welcome changes in project approach and learning methods
- Showing over Telling – delivering working prototypes or examples (such as a concept), from a couple of weeks to a couple of months, with a preference to the shorter timescale
- Debriefing at each interval – on how the team can be more effective, then tune and adjust behavior accordingly
What is Agile?
Agile is a project management methodology based upon iterations of using smaller increments of work and leveraging subject-matter experts alongside a development team. The simplification of focus provides faster results, not to be confused with the outcome of Agile, which is speed. We don’t work faster to be agile; our agility allows us to work faster, make decisions quicker, and with more certainty. Agile forces teams to create short timeframes and focus on the priority outcome or answer. In summary:
- Agile is not speed, Agile produces speed
- Agile is a philosophy to create focus by delivering smaller increments of work more frequently
- Agile comes from the software development industry – to better navigate uncertainty
It’s the ideal project management approach when there is uncertainly in project outcome that allows for the immediacy of feedback, eliminating surprises and delays.
How does Agile work and what are the benefits?
Agile is not about quickness – Quickness comes from being agile. Agile is about short-duration, focused market learning with the freedom for teams to decide and adjust early and often to outcomes and feedback. The benefits are:
- Shorter periods (sprints) with information presented regularly
- Never be surprised
- Easier communication
- You are part of the decision process
- More democratic than a presentation
- At times, selective data is presented and can allow for unintentional bias
- Focusing on fewer, but very impactful learning objectives in a short deliverable period
- Get more work done and more satisfying
- Allows for decisions earlier in the process
- Whether a pivot to change direction, stop and work on something else more productive, or pour more resources into the project to go faster
- Better manage resources
- Bias for action, like behavioral learning, over discussion
- Learning is about getting closer to customers
- Trying things or building prototypes/showing examples is strongly preferred
- Team freedom to identify solutions and bring back feedback in short windows of time
Kill the “big bang” presentation
For me, I never like to get surprised with the “big bang” presentation. While it was great theatre to those presenting, it was a terrible way to collaborate and debate major decisions. The big bang is when you present information after information, working to build up to the conclusion, and finally…bang! – the answer, conclusion, or recommendation. I found this exceedingly difficult to sit through, and if someone disagrees or has conflicting facts, it can really derail the argument. Thus, Valen works exactly opposite of this – from an answer-first approach. If you start with the outcome or answer and work backwards to explain the support, it becomes quite easy and clear to debate. In the first slide, you know the answers, something a busy executive will appreciate. It also saves time because where there is alignment, there is no need to dig further into conclusions or support, and the focus can be on risks or uncertainty solved by creating an efficient decision meeting that, many times, can end early or on time.
Utilize Sprints
Sprints are the common way to create focus, and thus, a short project duration. Sprints help streamline development and allow for a pause for feedback with frequent updates and ability to adjust the learning plan in each progressive iteration versus working in one, large project cycle.
How does Valen apply Agile to our strategy consulting services?
Agile, as a methodology in strategic analysis, helps focus decisions on the most important points while helping teams decipher uncertainty in results. We use an answer-first presentation method that allows us to unpack the conclusion and align around the supporting facts to ensure we are moving forward in a sound way. Executives love the approach because the presentation is often short and focused specifically on edge issues or next steps.
How does Valen apply Agile to activation methods, such as innovation or market research?
Innovation is defined as doing new things that add value. Doing new things is often uncertain and Agile provides an ideal framework to learn in a highly uncertain environment. Frequent target customer, consumer or end-user check-ins on specific, “of-the-moment” insight can help steer a team to find the best solutions and improve new product launch outcomes. Many discuss the need for customer listening, but Agile market-learning is about iteration to provide depth and clarity versus periodic learning. Iterative feedback allows for faster, more confident decisions. Every sprint is defined by feedback from the customer and by doing so, the project can be very cost effective with better insight.
How does Valen apply Agile to Strategic Brand Licensing?
The first thing to understand about brand licensing is that it is a strategic partnership between an organization who gives rights to use the brand, the licensor, and the organization that produces the product, service, experience, etc., the licensee. Strategic partnerships by their very nature require both sides to agree so when one side seeks out a partner or, for that matter say, an acquisition, the outcome is uncertain. You can’t make the other side agree. This is why partnerships can seem hard to executives because they don’t have control. We utilize a lean startup approach, based upon agile, to test the waters early in a category or set of partners to determine likelihood and better forecast or manage results with clients. The idea of learning from the market and adjusting works extremely well with the types of large, strategic deals we develop for clients.
Getting started with Agile
First, try Agile market learning with qualitative research for exploration or validation, see Fusion Methodology™. In the new product or new ventures space, Agile market learning is the first skill to master, and it is best learned like you are an entrepreneur with a limited budget, seeking to determine if your idea has merit. The entrepreneur would start qualitatively, and probably with some concept, sketch, or prototype to see if people would use and pay some consideration for their new idea.
How do you know your market research is agile?
There are three easy ways to keep your market research agile:
- Agile is not about focusing on one project and being done or trying to get all the answers upfront. Since Agile is iterative, studies can be more focused. If you are conducting one round of qualitative learning with the same consumers and walking away, you are missing the depth and richness of insight. Going back and iterating on findings drives truth and contextual understanding. Elongating your learnings by stringing together several, smaller learning steps.
- Do not get fixated on a detailed project plan, a single method, or the discussion guide. Be open to varying the method with which you begin. Changes occur because the findings guide the research and the next questions. This progression enables you to apply the right method based upon the situation and requires having a team with an understanding of multiple methods surrounding insight and project roadmaps. This is similar to how entrepreneurs conduct early listening when focused on product/market fit and then test in-market behavior-oriented usage. It does not mean that we cannot field a “large sample” study, it is just that the prevailing idea is that this study will feed the focus of the next study, and to adjust along the decision process in short durations.
- We always use video and text analysis for insight, as well as multiple methods in a study. Utilizing video to capture the interactions with consumers allows for behavioral insight, not just discussion or interview.
Do I always need to use an Agile methodology?
Agile works well when there is high uncertainty in the requirements or outcomes. If the requirements or outcome are well known and unlikely to change, a waterfall method will work well and there is less of a need for an Agile approach. However, we have found that having one approach, Agile, which will work in any project situation is helpful because uncertainty is, well, uncertain in our work of helping a business drive growth!
Talk to our strategists about how Agile market learning can help you increase speed, satisfaction, and market results for your work.
Enjoy the journey and the results will come.
