When Agile Isn't Enough: The Evolution of Agile Part Two

We were initially drawn to a development framework known as waterfall, but quickly realized it wasn't ideal for the type of products we were developing (read about more about our experience in Part One).

From there we moved on to Agile, and from the get-go we loved working within the agile framework. Shorter, function-based projects provided a nice balance of speed and flexibility, and our team felt less burnt out than they had when using waterfall. However, we discovered that our clients, the executive stakeholders, weren’t as thrilled with the process, primarily because they felt like accountability was lost in the process.

We found that the largest source of difficulty between executives and Agile teams tended to revolve around mismatched timelines. While most executives work within 5-10 year timelines that are broken down into yearly and quarterly goals, a purely Agile system often lacks, or leaves overly flexible, the timelines or milestones, as Agile’s nature requires reevaluation of the project every two weeks.

Agile coaching will often say “work towards a common goal” , without describing how. We realized that to stay Agile while simultaneously maintaining accountability to our executive stakeholders, we would need to add a management layer atop agile’s sprints and scrums that would allow us to focus on strategic clarity and long-term project vision.

To make Agile more actionable and accountable to executives, we developed “Applied Agile”, a management system that sits on top of traditional agile processes, providing a framework for how communication should flow throughout the product development cycle.

By adding the following series of strategic meetings and planning tools, focusing on different levels of granularity, we are able to tie high level executive strategy into the day-to-day tasks of a product development team.

1. Onboarding Sprint
This sprint puts the product development team and executive stakeholders on the same page and sets the team up for success. Budget, time frame, metrics for success, stakeholders, product owner, roles and responsibilities should all be discussed during this time.

2. Roadmapping Sprint
This phase involves significant research and generates critical decisions such as primary user personas and the recommended tech stack. The first batch of user stories will be drafted and prioritized from the work done in this sprint.

Executive involvement in this phase is mandatory as execs will be trained on what KPIs and metrics should be used to measure progress. Future Vision Alignment and Review Meeting(s) need to be scheduled at this time to accommodate busy schedules.

3. Rapid Prototyping Sprint
The first few sprints are about establishing a velocity benchmark and building the foundational elements of the product. Within the first sprint, the team should build something functional, even if it is bare bones. The goal of the rapid prototyping sprint is to establish momentum. For really cutting edge technology it can take multiple sprints to build that momentum, so monitor carefully.

4. The Agile Scrum Sprints
There should be a healthy backlog of user stories now created and prioritized. Agile sprints are typically 2 weeks with dedicated teams of no more than 5 full time developers and designers. A product owner that reports to the executive team should be involved.

5. Vision Alignment and Review Meetings
This meeting must include the team leads, the product owner and the executive team, and will be run every 3 sprints (6 weeks). The agenda is as follows:

(1) demo the product to the executive team
(2) review the product roadmap
(3) measure success against achievements along the roadmap and any other criteria established
(4) discuss any issues
(5) readjust the roadmap based on new inputs or strategic goals.

After each Vision Alignment & Review, the executive team will establish success criteria for future Agile Cycles and approve the recently completed work unless deemed unacceptable. The product owner and team leads will then run a Retrospective meeting with the product team. Feedback from the executive meeting is shared with the team at this time.

Because timelines are the major difference, these tools and meetings allow us to focus in on different time blocks: day to day, week to week, month to month, quarter to quarter and year to year. This system marries the two week iterations of agile with the longer term strategic plans of executives.

We’ve found that Applied Agile keeps our projects on track, minimize the total time, cost, and provide decision makers with all the information they need, keeping our teams productive and our executive stakeholders confident in the status of their projects.

Applied Agile has been a gamechanger for our team. If you’d like to learn more about the Applied Agile process, check out our Introduction to Applied Agile, or reach out with any questions you may have.