As companies grow, scaling Agile product development becomes tougher. According to 52% of respondents in the 13th State of the Agile Report, the differences between organizational culture and Agile values are the main drawback in their work.
Organizational leaders are able to leverage Agile culture to improve product development. A robust Agile culture involves team autonomy in approaching complex problems, close work with clients, and long-term vision and strategy.
These abstract values are difficult to assess and engage in. In an organization, implementing an effective strategy to leverage them becomes non-trivial work. The Mission Driven Development (MDD) approach has risen from mid-stage startups as an alternative to grow such a culture.
Several slowdown patterns can emerge when scaling. Team motivation can decrease with projects that have an unclear end. Product managers can feel lost in operational meetings and thus lose time to design strategic product paths. Deployment of new features and products can slow down as systems grow increasingly complex.
These barriers should be approached from a cultural and practical perspective. Overcoming them involves relinquishing control, growing team autonomy, implementing radical transparency, and setting up an efficient product development framework to drive results.
|Slowdown Patterns||Management Levers|
|Team motivation decreases.||Relinquishing control and growing team autonomy|
|Product managers feel overwhelmed by operational meetings.||Implementing radical transparency|
|Deployment of new features slows down.||Setting up an efficient product development framework|
Challenges of Scaling Traditional Agile Frameworks
When scaling Agile, the management and team levels need to be synchronized. The management level is responsible for developing the company strategy, creating and communicating product vision, executing staffing decisions, and fostering team development. The team level carries out the necessary tasks to efficiently translate this vision and strategy into valuable products and features.
Traditional Agile frameworks (XP, Scrum, and Kanban) are optimized to operate at the team level, leaving management relations mainly unaddressed. A new wave of scaled Agile frameworks evolved to fill this gap, i.e., SAFe, LeSS, Scrum of Scrums, Nexus, DAD, etc. However, these approaches require a lot of planning to implement and effort to manage and maintain.
A lightweight approach, the Mission Driven Development framework gives enough guidelines to implement a robust structure around scaling development and leveraging Agile values.
Core Elements of Mission Driven Development
The starting point is Mission Discovery. A business mission takes time and effort and should identify a latent problem, a solution space, and the desired business outcome. When accurately defined, a mission drives motivation, fosters collaboration, and promotes research on broader design spaces.
The accountable actors for the success of each mission are squads. In collaboration with product managers, small teams of 2-4 people conduct the necessary activities to deliver solutions that fit the mission goal and time restrictions.
The 6-week timebox allows all squads to follow the same timeline for base planning while also giving enough time to deliver a meaningful outcome.
The MDD framework commonly includes a one- or two-week buffer period for final integrations and deployments, training and skill development, innovation activities, and next cycle planning, among other things.
The Importance of the 6-Week Cycle
While the six-week period might seem like a lot for some Agile practitioners, it contains several important benefits.
Teams working in short cycles tend to lose engagement for the product vision, as they feel like they are checking off a “laundry list” of fixes, bugs, and small features. This threatens the teams’ autonomy to explore and choose the best way to deliver solutions.
As cycles go longer, product estimation accuracies decrease. As a result, it requires heavy planning efforts by product teams.
Six weeks has been called the Goldilocks of product timeframes, providing enough time to deliver a Minimum Viable Product through innovative thinking, quick prototyping, and continuous delivery.
The 6-week cycle further enhances team vision engagement by leveraging autonomy. Micromanagement is not necessary as long as missions are clearly stated and the cycles are short enough for teams to focus only on desired outcomes.
Finally, product managers can engage in planning activities every six weeks, maintaining enough predictability for teams to keep on track toward the mission. As a result, more time can be focused on the strategic and exploratory dimensions of product development.
Implementation of Mission Driven Development
Let’s take, for example, a mid-stage startup that has a B2B product offering network pricing optimization which increases client revenue through the use of artificial intelligence applications. The business has recently signed a new funding round, with the goal of consolidating itself as a relevant industry actor and growing market share by 300%.
In this scenario, there are several product development challenges:
- How can feedback from current and potential clients be obtained to validate the pending value hypothesis?
- What features should be built or removed from the platform for a compelling user experience?
- How can the management structure be set up to handle scaling and leverage cultural values to accelerate growth?
In the end, to avoid complex frameworks, the company decides to apply the Mission Driven Development framework. In Mission Driven Development, “last-mile” details are defined by every organization. The main elements to be defined are:
- Mission discovery
- Mission structure
- Squad assembly
- Inspection and adaptation
- Buffer iteration
- Capacity planning
The starting point is Mission Discovery. Tim Herbig describes discovery as the iterative process of reducing uncertainty around a problem or idea to ensure that the right product gets built for the right audience. Before any mission is committed in an iteration cycle, it should be as comprehensively validated as possible.
The Mission Discovery process is conducted by specifically allocated teams. The discovery team is led by the product manager and consists of product researchers, business analysts, and designers. When multiple product managers exist, they report to the Chief Product Officer (CPO), who assures common vision across products, fit of products and global company strategy, and timely delivery.
The recommended starting point for mission discovery is challenges, problems, or opportunities. Starting from a challenge, for example, helps the team explore in more design spaces, finally broadening the solution possibilities.
Mission validation involves several activities that help the company better understand client needs:
- Conducting market research and competitor analysis
- Understanding the problem space in which the mission is defined
- Designing low-fidelity sketches and prototypes
- Defining a clear scope for the mission
- Gathering client feedback and validation
These activities help the mission to be a solid guideline for the development squad and guarantee that value will be created for users.
As a result, some missions are validated to enter the Mission Backlog, which continuously evolves with discovery activities and feedback collection.
In the example, let’s take this challenge: What features should be built from the platform to produce a compelling user experience? Only one discovery team, led by the product manager, would be adequate to tackle this challenge.
Let’s assume that currently, the example company’s platform takes the client’s raw data and returns an optimized pricing network on processed data files. However, the platform UX hasn’t been optimized for a captivating experience. The goal at this point is to determine whether client value will come from improving the UX, developing new features, or enhancing the platform services.
After initial market research, the decision is to develop new features. Candidate features for the platform are:
- Ultra-fast repricing
- Fast and responsive interface
- Intelligent and advanced repricing rules
- Repricing and sales history
For discovery purposes, the company decides to take a design sprint approach: a five-day process for answering critical business questions through design, prototyping, and testing ideas with users. The discovery process is run for each candidate feature to see which will create more value for current and potential clients. The top feature selected for development is intelligent and advanced repricing rules.
Achieving a solid mission definition is not a trivial task. It has to depict a clear business challenge and set boundaries for its outcome, while also giving enough space for squads to arrive at an innovative and efficient solution. A clear, precise mission:
- Clearly states a business challenge, having identified and delineated the problem space.
- Synthesizes all information and insights discovered in previous phases.
- Links to a desired business outcome.
- Is result-oriented, clearly indicating the picture of mission success.
- Is realistic and achievable within the 6-week cycle opportunity.
- Is sufficiently narrow to guarantee focus and sufficiently wide to stay away from details.
In the example, after a week of discovery, information and user feedback have been collected and synthesized.
Target user: Client pricing analysts.
Problem space: Users want to be able to set and manage intelligent and advanced rules for pricing so that they can automatically adjust pricing given certain conditions.
The most valuable conditions for rules are competitor price, shipping urgency, order total, available inventory, and discount for premium clients.
Insights: Rules should be applied in custom priorities and be modifiable, if required.
Analysts would like to easily see which rules apply at certain times for a given product.
Desired business outcome: Increase user platform engagement by 25%, as measured by time spent on the platform.
The team formation process is done ad hoc for every development cycle. Team autonomy and self-organization principles remain central. Team assembly is guided by a mix of factors, ranging from mission complexity, developer and designer skills, interests, and squad chemistry.
The process of squad formation is facilitated by Agile coaches. Before any decision, each person is asked what type of work they would like to do over the next six weeks. Then, based on experience, knowledge, and skills, squads are built ensuring they have the necessary knowledge and skills to successfully tackle the mission.
Agile coaches work with several squads along the development cycle, helping them raise impediments and dependencies. When several Agile coaches exist, they report to the Head of Agile, who is responsible for squad assembly, continuous improvement, and Agile product delivery.
The recommended squad size is 2-4 people: usually, one designer and one or two developers, depending on mission complexity. A QA engineer is considered to assist one or more squads in achieving the desired quality standards.
Squads are often mixed after every cycle, so everyone can cooperate with different people, spread knowledge, and work on different product dimensions, though a high-performing squad may work together for a few cycles.
The particular squad in the example should consider people with UI design, data processing, and data visualization capabilities.
Inspecting and Adapting Within the Cycle
Transparency, inspection, and adaptation should be encouraged continuously by Agile coaches through standard Agile practices.
Short weekly meetings are held to organize work and facilitate raising impediments and dependencies. Grooming is done, if necessary, to ensure that the squads fully understand the mission and user stories. Short retrospectives are conducted at the end of every week to identify and implement changes and improvements.
Continuous delivery practices should be maintained throughout the cycle. The mission goal could be met earlier, as the 6-week cycle timebox is a cadence-based approach to set ground rules while helping achieve squad predictability.
A good practice to enhance transparency is a demo at the end of the fourth week, based on an agreed milestone between squads and product managers. The goal of these demos is to adapt, reducing or increasing scope as required.
For the example mission, a release plan has been agreed between the squad and the product manager in four different releases:
- New rule feature UI
- Competitor price rules
- Shipping urgency rule
- Order total rule
- Rules priorities
- Available inventory rule
- Visualization application rule
- Discount for premium clients
Release 3 is agreed as the demo for the fourth week. As releases have been carried out throughout the development cycle, the desired business outcome (in this case, user engagement) should be tracked from the moment the development cycle starts. Graphically, progress would be expected as follows:
Taking one or two weeks as a buffer period is a practice replicated through Mission Driven Development implementations, as well as through other scaling approaches such as SAFe.
In SAFe, an innovation and planning iteration is done in every development cycle. It serves as a context switcher, enabling processes and activities of exploration and innovation usually left out by other delivery-focused frameworks. Examples of activities implemented in this buffer week:
- Final integration of solution. When deploying near the end of the 6-week cycle, it’s probable that integration, verification, documentation, and validation remain pending. Dedicated time helps to ensure an effective and smooth integration of new solutions in existing products.
- Mission planning and prioritization. Missions are refined, classified in small or big batches, and prioritized for the next development cycle. When prioritizing missions, some companies implement pitch days during which top missions are presented to the company and then—in a collaborative way—committed to for the next development cycle.
- Hackathons. Hackathons have gained increasing popularity among startups and companies thanks to their ability to foster innovation, create community, and build new knowledge and skills in a fun way. Results are presented to others and become candidates for the Mission Backlog.
- Experimental prototypes development or side projects. It is common practice to give engineers and designers time to work on whatever they decide, as long as they show the work done at the end of the buffer time.
- Engineering work. Pure engineering work such as infrastructure development, test automation, technical debt reduction, and systems migrations is usually carried out.
- Development of new skills and knowledge. The rapid pace of knowledge evolution forces developers to stay updated on global trends. The buffer time is suitable to hold on-site training, communities of practice, and technology workshops, among others.
Buffer periods should rely on identified knowledge gaps, innovation objectives, and needs for the next cycle. For example, a buffer period of one week could look like this:
|AM||Final integrations||Previous cycle retrospective||Hackathon||Hackathon demo||Mission pitch day|
|PM||Documentation||Training and workshops||Training and workshops||Next iteration planning|
When deciding mission commitment for the next development cycle, a common practice, according to Basecamp Co-founder Jason Fried, is to first identify small or big batches. Big batches refer to large product features or functionalities, while small batches refer to smaller iterations or tasks. In the given example, the selected mission for a new feature could be considered a big batch.
The recommendation here is straightforward: always have a mix of small and big batches. Small batches are missions that are estimated to take 3-4 weeks, and big batches could take six weeks or more.
If a small-batch team has accomplished its mission by week 3 or 4, the agreed demo is the opportunity to assess whether the squad should keep working on improving the implemented solution, help another squad, take a new small-batch mission, or begin unplanned work.
A good mixture of big and small batches keeps people from working at 100% capacity, thereby allowing them to maneuver and adapt in case of unplanned work. Big-batch teams get as much focus as possible during the cycle, while small-batch teams can deal with ad hoc tasks that arise from unexpected work.
Combining small and big batches also reduces risk. Having only big batches can increase the probability of a negative impact on user experience. If several new features are released close to each other, they should be accompanied with good change management. Furthermore, in case of unplanned work, there will be less capacity available. Lastly, if several big-batch teams fail, the iteration could be sensed as unproductive and thus demoralize the squads.
Risks of Mission Driven Development
There are many benefits of implementing Mission Driven Development, but as any prescriptive framework, it has several inherent risks that need to be considered.
Missions should be realistic, aiming at a good fit between challenge complexity and squad skills; otherwise, the impact on development outcomes can be significant.
An overly ambitious mission could raise frustration and anxiety, negatively impacting squad performance. On the other hand, an unenthusiastic mission could cause squad demotivation and boredom. Thus, a Minimum Viable Product mentality should remain constant within the framework.
The Why of a Mission
Robust business missions should have a comprehensive definition of the problem space and its relation to the company vision. If this relationship isn’t clear, valuable insights can be lost due to a lack of understanding of how problem resolution impacts company goals.
Falling into a waterfall model during the six weeks is a natural tendency for squads. There are two main factors for this. First, pressure for deploying is stronger near the end of the cycle. Second, squads want to squeeze as much scope as possible within a mission, resulting in an urgency to deploy at the end of the development cycle. Therefore, continuous delivery practices should be encouraged to achieve Agile releases throughout the cycle and avoid waterfall-related risks.
Product operation tasks such as managing infrastructure, services, or monitoring components should be kept outside the scope of squads, as they could impact velocity. Relying on development standards and practices like atomic design reduces development efforts and consequently accelerates scaling. Another common practice under this framework is a central operations team that handles infrastructure, in addition to managing product operations and monitoring.
6-Week Cycle as a Myopic Framework
Some scenarios won’t be adequate for the framework. This becomes especially true when dealing with big and complex systems that can have an enormous impact on client experience, such as R&D projects or migration of critical systems.
A Lightweight Option for Scaling Agile
Scaling Agile to keep up the pace of product development and company growth is a latent challenge for Agile practitioners. As a recently developed Agile approach, the Mission Driven Development framework has gained popularity among companies for its ease of use and implementation. The MDD framework sets in motion an end-to-end, transversal product innovation process, from discovery to delivery, that fills the gaps present in traditional Agile structures. Mission Driven Development has the potential to be the new Scrum for growing companies.
Understanding the basics
There are many different Agile frameworks suitable for different situations. Traditional frameworks for one or few teams include Scrum, Kanban, and XP. Scaled Agile frameworks include SAFe, LeSS, DAD, Scrum@Scale, Mission Driven Development, etc.
The normal development cycle, according to SDLC, consists of planning, analysis, design, implementation, and maintenance.
The six stages of the product development process are idea generation, market research, concept development, product design and development, testing, and launching.
The five stages of a project cycle are initiation, planning, execution, monitoring, and closure.
The elements of a project cycle are scope, resources, schedule, quality, and risks.