In this article, we delve into the Agile Transformation Basecamp Model, also known as the Agile Basecamp Model. While there has been limited external critique of this model, we applaud those who are actively working to transform their organizations. Our aim is to share our firsthand experiences with this model and provide insights on how to adapt it for your organization’s success.
This document has been authored by individuals with extensive experience in implementing, operating within, and transitioning out of the Agile Basecamp Model. The primary author was one person who has witnessed all phases of the model’s implementation, beginning in 2017. This consultant initially served as an Expedition Lead, implementing the model for an organization. Subsequently, they took on the role of a Delivery Manager, tasked with delivering within the model. Most recently, they re-engaged as an independent consultant to help stabilize an organization that had experienced a lengthy, somewhat successful implementation of the Agile Basecamp Model.
Our Background
Let’s commence our exploration of the Agile Basecamp model by explaining Detroit DevOps’ bias through our fundamental premise statement:
In most organizations, the primary driver for individuals is to fulfill personal goals. These often include financial stability, access to health insurance, meeting household needs, and securing basics like food and shelter. It’s essential to understand that the majority of employees in Western organizations aren’t inherently malevolent or ill-intentioned. They are participants in the existing system, striving to shape their employment in a way that suits their needs and allows them to decide when to conclude their tenure.
While many organizations grapple with organizational design, software products frequently wrestle with technical debt arising from missing or misaligned competencies and capabilities. Improvement necessitates experts actively involved in driving software outcomes and offering practical solutions for organizational design. Addressing only one aspect of this dual challenge will lead to limited success.
The Agile Basecamp Model
In this exploration, we delve into the world of Agile and the Agile Basecamp Model, dissecting the advantages and drawbacks that organizations may encounter. Whether you are a seasoned Agile practitioner or a curious newcomer, this analysis will shed light on the intricate balance of implementing Agile methodologies in the ever-evolving landscape of modern business.
The Agile Basecamp model, grounded in System theories and originating prior to the early 2010s, has long been a robust approach in organizational change management. However, it lags in popularity behind methodologies like Scrum, SAFe, and LeSS, possible due to its absence of formal certification, conferences, and published materials.
It views practices such as Automated Testing, Continuous Delivery, and DevOps as aspirational objectives, emphasizing process improvement, dependency management, and organizational structural changes before addressing technical challenges. The model adheres rigidly to agile requirements, including mandating that teams create epics, stories, features, and maintain a high level of rigor in agile ceremonies.
To implement the model by the Playbook, it demands a high density of personnel to guide the organization through the change management process. This typically includes the following roles: Transformation Lead, Expedition Lead, Portfolio Coach, Product/Program Coach, Delivery Team Coach, a Staff Consultant responsible for metrics and presentations, and occasionally, a technical coach.
The term ‘Expedition’ is employed to characterize the change management process. Each Basecamp Trek necessitates an Expedition, and this undertaking involves the roles listed earlier. Notably, an Expedition is exclusively applicable to a single portfolio. Consequently, in larger organizations, the need often arises to execute multiple Expeditions concurrently or sequentially.
The time investment required to implement a single Basecamp typically spans 12-16 weeks, although extensions to 20 weeks are not unusual. This timeline is informed by various common workshops and execution plans:
- Two-Day Workshop: This session involves executive sponsors and the transformation lead engaging in discussions about aspirational goals.
- Pilot Define the End State: Typically, a 2+ week process, this phase focuses on designing the pilot Expedition. This includes formulating change management strategies, identifying sponsors, structuring the organization, creating assessments and metrics, developing activity plans, and preparing playbooks.
- Pilot Expedition: The implementation of the pilot expedition itself generally spans 12-16 weeks. However, it’s worth noting that extensions beyond this timeframe are not uncommon.
- Define the End State (Post-Pilot): Following the pilot, this session is dedicated to refining and tailoring each new expedition plan further.
- Expedition Implementation: Similar to the pilot, the full expedition typically takes around 12-16 weeks for implementation, although variations in timelines can occur.”
The System of Engagement
The System of Engagement integrates key components from the following three systems. As of the summer of 2022, it remains somewhat aspirational and lacks a clear definition. The primary aim of this system was to enhance clarity and governance within the broader change management framework.
The System of Improvement/Continuous Improvement
The System of Improvement is another aspirational system designed to encompass both the System of Delivery and the System of Transformation. Its objective is to establish an internal organizational capability for improvement, which may involve the creation of an Agile Transformation office or its related functions.
The System of Transformation
In the context of our discussion, the System of Transformation represents an executive leadership structure, championed by the C-suite, with the explicit purpose of driving transformation objectives within an organization. This system is particularly notable for its efficacy, and its success can be attributed to fundamental principles, and uses command and control structures that already exist to drive organizational change management.
One of these principles emphasizes the importance of fostering a two-way street of communication between people actually doing the work and executive leadership. In our case, the System of Transformation exemplifies this concept beautifully. It creates a direct channel through which executives can receive rapid escalations of issues and concerns without these reports being “perfected” or diluted by middle management layers. This unfiltered feedback loop empowers executives to gain a raw and unvarnished view of the organization’s challenges, enabling them to make informed decisions. It’s successful because it forces the executive time to set a vision and align their organization to achieve that vision. It creates a net new governance body accountable for the change, which bypasses classic middle management.
Furthermore, another key principle underscores the significance of prioritizing investments in improvement over strict adherence to product delivery. This principle aligns seamlessly with the System of Transformation, which places a laser focus on achieving tangible business outcomes. These outcomes are intricately linked to the development of organizational competencies and capabilities that are driven by a well-structured plan that encompasses the current state, the next state, and most crucially, the measurable impact these changes should have on the organization tying to EBITA or the 10k.
In essence, when executed with precision and commitment following the Plan, Socialize, Tailor Implement, Review (PSTIR), the System of Transformation has demonstrated its ability to bring about meaningful and sustainable change within organizations. It stands as a testament to the power of fostering direct, unfiltered communication and prioritizing improvement over rigid product delivery timelines. When it is coupled with the right business outcomes, executed with discipline, it will most likely drive the measurable impact desired.
The System of Delivery
The System of Delivery, in the context of organizational software development, pertains to the methodology used for delivering software solutions. While theoretically, this could encompass various delivery models, the Basecamp Model typically comes with a pre-established delivery approach.
At its core, the Default Basecamp System of Delivery follows a predefined, comprehensive model that can be broken down into the following components:
Target Basecamp
In the Default Basecamp Model, there are five Basecamps. In theory, an organization can continue to operate within these Basecamps indefinitely. In essence, the Agile Basecamp Model progresses through these five Basecamps, each with its distinct objectives and strategies. This sequential journey represents a deliberate and strategic approach to transforming an organization’s software delivery capabilities, from predictability and efficiency to autonomy, automation, and ultimately, a culture of perpetual learning and innovation.
- Basecamp 1 – Predictably: This inaugural stage in the Basecamp Model is dedicated to the establishment of predictability within the software delivery process. Its core objective is to introduce a level of consistency and reliability into the workflow. By doing so, organizations can minimize uncertainty and ensure that they can meet their commitments and deadlines with a higher degree of accuracy. Basecamp 1 lays the foundation for a more structured and controlled approach to software development, allowing teams to better plan and manage their work.
- Basecamp 2 – Reducing Batch Size: Moving on to the second phase, Basecamp 2 centers on the strategic goal of diminishing the size of work batches. This reduction in batch size is a deliberate effort to enhance operational efficiency. By breaking down work into smaller, more manageable units, organizations can streamline their processes and reduce the complexity of tasks. This leads to quicker feedback loops, shorter lead times, and an overall acceleration in the software delivery pipeline. Basecamp 2 essentially promotes a leaner, more agile approach to work execution.
- Basecamp 3 – Break Dependencies: In the third Basecamp, the primary focus is on identifying and dismantling dependencies that may exist within the organization’s processes and systems. Dependencies can often create bottlenecks and hinder progress. Basecamp 3 seeks to eliminate these hindrances, allowing teams to work more autonomously and without unnecessary constraints. By reducing dependencies, organizations can significantly enhance their ability to innovate, adapt to change, and maintain a consistent pace of delivery.
- Basecamp 4 – Increase Local Automation: As we progress to Basecamp 4, the central theme revolves around increasing the level of automation within the organization. This phase goes beyond just process improvements; it involves restructuring the organizational hierarchy into a more streamlined two-tier governance model. Automation is leveraged to reduce manual, time-consuming tasks and to optimize workflows. This not only boosts efficiency but also reduces the potential for human error. Basecamp 4 signifies a move toward a more tech-savvy and automated approach to software delivery.
- Basecamp 5 – Investing to Learn (Lean Startup): The concluding stage, Basecamp 5, focuses on cultivating a culture of continuous learning and innovation, drawing inspiration from Lean Startup principles. At this point, the organization recognizes that ongoing growth and success depend on its ability to adapt and innovate. Basecamp 5 encourages experimentation, risk-taking, and a willingness to learn from both successes and failures. It’s a dynamic phase where the organization embraces change as a means of achieving long-term sustainability and competitiveness.
Governance Model
Within the context of the Basecamp Model refers to a structured framework for managing the end-to-end process from investment decisions to final delivery. It is typically organized into three to five hierarchical tiers, each serving specific functions and responsibilities. Here’s an elaboration of these tiers and their roles:
- Investment Teams: These teams are responsible for making decisions related to where and how to invest resources. They evaluate potential projects or initiatives, considering factors such as business value, strategic alignment, and available resources. Investment teams help prioritize and select which projects should move forward.
- Portfolio Team: The portfolio team plays a crucial role in aligning the chosen projects or initiatives with the organization’s strategic objectives. They oversee the portfolio of work, ensuring that it remains in line with the company’s goals. This team also monitors progress, assesses risk, and may make adjustments to the portfolio based on changing priorities.
- Product Team: Once projects are selected, product teams take over. They are responsible for defining and developing the actual software products or solutions. This includes creating roadmaps, setting priorities, and managing the day-to-day work of delivery teams. Product teams work closely with stakeholders to ensure that the product aligns with customer needs and business goals.
- Delivery Team: At the delivery level, agile development teams are responsible for executing the work outlined by the product team. They follow agile practices to build, test, and deliver software incrementally. The delivery team aims to meet the requirements set by the product team while maintaining high-quality standards and responding to changes as needed.
- Additional Tiers (if applicable): Depending on the complexity and scale of the organization, additional governance tiers may be introduced. These could include program management teams, executive steering committees, or other oversight bodies responsible for ensuring alignment, managing risks, and providing guidance.
In operation, the Governance Model serves as a robust framework, providing organizations with a well-defined structure for making critical decisions, establishing accountability, and facilitating communication across all stages of the software delivery process. Its primary purpose is to empower organizations to make informed and strategic investments, meticulously monitor progress, and adeptly respond to evolving circumstances.
One distinguishing feature of the Governance Model was it’s ability to confuse adopters. Should there be unwavering commitment to comprehensive requirements gathering that places a strong emphasis on thoroughness and clarity in articulating project requirements in verbose epics, stories, and features? Or should it be on the back of a napkin? The implementation details were unclear.
Outcome-Based Planning, Metrics, and Assessments
These items are integral components of a Basecamp Model transformation process. They provide a structured framework for setting goals, measuring progress, and ensuring alignment with the organization’s objectives. Here is an overview of these components:
1. Outcome-Based Planning (OBP): OBP is a strategic approach that focuses on defining specific outcomes or results that the Agile transformation seeks to achieve. These outcomes are tied to the organization’s strategic goals and provide a clear direction for the transformation efforts. OBP typically involves the following steps:
- Defining Outcomes: Identify and define the desired outcomes of the Agile transformation. These outcomes should be measurable, achievable, and aligned with business objectives.
- Mapping Activities: Determine the activities, initiatives, and changes required to achieve the defined outcomes. These activities serve as the roadmap for the transformation journey.
- Prioritization: Prioritize the identified activities based on their importance and impact on achieving the outcomes. This helps in resource allocation and sequencing.
- Monitoring and Adaptation: Continuously monitor progress toward the outcomes and be prepared to adapt the plan as needed to stay aligned with changing circumstances.
2. Metrics: Metrics are quantifiable measures used to assess the effectiveness of Agile practices and the progress of the transformation. Metrics provide objective data that helps in decision-making and performance evaluation. They can be categorized into various types, including:
- Outcome Metrics: These metrics are directly tied to the outcomes defined in the OBP. They measure the success of the transformation in achieving its intended results.
- Process Metrics: These metrics assess the efficiency and effectiveness of Agile processes and practices. Examples include cycle time, lead time, and sprint velocity.
- Quality Metrics: Quality metrics focus on the reliability and quality of software deliverables. This includes metrics related to defects, test coverage, and code maintainability.
- Team and Individual Metrics: These metrics assess team performance and individual contributions, helping identify areas for improvement.
3. Assessments: Assessments are a means of evaluating the current state of Agile maturity within the organization. They help in identifying strengths, weaknesses, and areas for improvement. Key points about assessments include:
- Tailoring for Teams: Assessments should be customized for each Agile team and expedition. One-size-fits-all assessments may not capture the unique challenges and contexts of different teams.
- Alignment with OBP: Assessments should be closely aligned with the outcomes and activities outlined in the OBP. This ensures that the assessment focuses on areas directly related to the transformation’s goals.
- Triangulation: Assessments should gather both qualitative and quantitative data. Qualitative data may include surveys, interviews, and observations, while quantitative data involves metrics and measurements. Triangulating data from multiple sources provides a more comprehensive view of Agile maturity.
- Iterative Process: Assessments are not static but should be conducted periodically. Regular assessments help track progress over time and identify changes in Agile maturity.
- Actionable Insights: The results of assessments should lead to actionable insights and recommendations. They should inform the development of action plans and improvement initiatives.
In summary, Outcome-Based Planning, Metrics, and Assessments are interrelated components that drive the success of an Agile transformation. They provide a structured approach to setting objectives, measuring progress, and continuously improving Agile practices to achieve desired outcomes. Tailoring these components to the specific needs of teams and expeditions ensures a more effective and adaptive transformation process.
Success Means
To achieve a Basecamp the metrics and assessment must align to the outcomes, and the Outcome-Based Plan must be 100% executed.
What Works
Change Management
One of the model’s notable strengths lies in its ability to effectively manage change using the System of Transformation. This is evident through the Expedition Leadership Team, Transformation Leadership Team, and Executive Steering Committee, all composed of the client’s own employees and leadership. This structure compels the C-Suite to play an active role in driving organizational change.
Outcome Alignment
A crucial aspect of the model’s success is its capability to align outcomes with tangible, quantifiable metrics. By crafting a clear taxonomy of outcomes and tying them to specific business capabilities, the model ensures that activities are directly connected to these outcomes. This alignment, in turn, yields positive and measurable results.
PSTIR Framework
The PSTIR (Plan, Socialize, Tailor, Implement, Revise) framework provides a dependable and comprehensive guide for all transformation initiatives. It is the core structured required for a success change management outcome. It streamlines processes and fosters adaptability throughout the transformation journey. This structured approach helps organizations navigate complex changes efficiently.
In our experience, particularly in 2019, the pinnacle of this model’s implementation, the Basecamp model placed a strong emphasis on rigor, discipline, and quality – and teams could consistently achieve Basecamp 1 when transformation consultants executed the model as planned. In fact, many organization’s employees were trained to implement this model at scale allowing the organization to adopt this model with limited outside support.
A Story About the Challenges
Unfortunately, in 2023, if organizations are struggling to achieve Basecamp 1 or Basecamp 2 globally, these fundamental aspects have eroded, it could indeed explain some of the challenges the organization is currently facing. When executed proficiently, the basecamp model is strategically designed to hold executive leadership accountable for driving transformative change.
When success is not achieve, the coaches often cite the organization’s inability to create “clearings and conditions for change”. In fact, some transformation coaches could point fingers at the organization, and hide their inability to grasp and implement this foundational model due to execution mistakes e.g. (missing metrics, not tailoring the plan, too much change in progress). In all reality, the failure lies in the ability for the change managers to effectively communicate the conditions needed for the change. If this is happening, it will be clear in the Outcome Base Plan, PSTIR, Metrics, and Assessment – more on this later.
Most important, it must be noted that the scope of change within this model can encompass a wide array of initiatives, depending on the consensus among executives. One notable challenge often arises from the model’s content, which, in some instances, might feel outdated and ill-suited for addressing the demands of software in 2023. This, too, can contribute to the hurdle adopters of the Basecamp Model currently are facing.
The core challenge the model must overcome is its overemphasis on predictability and process change. It is setup to prove the value of aspirational goals from 2008 that are commonplace in 2023. In the time since its inception, the landscape of business and technology has evolved significantly. Concepts like Artificial Intelligence (AI), Continuous Delivery, and full-stack development have become commonplace practices in the industry. Simply said that in 2008 Continuous Delivery was novel the book was published in 2010, and now in 2023 Continuous Delivery is ubiquitous, meaning the investment to create the measurable value of technical craft is worthless, since most organizations accept the value of high skilled technical craft.
Beyond the model’s disregard for technical challenges at the outset. Organizations that embark on this journey typically invest heavily in Basecamp 1 and 2, a process of change management that spans approximately a year in 2 expeditions. Very few, if any, organizations have successfully achieved Basecamp 3 and beyond and continue to operate at that level, partly due to transformation fatigue, and the overall lack of clarity on Basecamp 3-5 in the Playbook. We believe this to be because the fundamental technical challenges were not immediately addressed on Day 0 in Define the End State.
Additionally, achieving “Basecamp 1 or 2”, there is a critical juncture where many organizations face a pivotal decision due to several challenges e.g. (political process to change faster, the lack of measurable change, and the rough experience of the change management model itself). Many adopters may opt to stop their journey with the Basecamp model altogether, while others may explore alternative models that better align with their evolving needs and capacities e.g. (SAFe, LeSS, or hybrid models). It underscores the importance of adaptability in the face of shifting challenges and objectives within the realm of software development.
Overall, we believe in the short order; the organization can create coaches to implement this model without outside influence. As individual implementors of the model, we had the opportunity to work with a diverse range of organizations, and one case stands out. In this instance, a single person could successfully coach 40 teams through Basecamp 1 without the overhead of a consulting Expedition Leader (EL). This achievement was accomplished within a relatively short timeframe, approximately 16 weeks or four months, despite the teams comprising entirely of new coaches supplied by the organization.
In hindsight, it was recognized that had we chosen to further speed up the process by condensing the sprint duration to just one week, we could have potentially achieved this milestone in as little as 8 weeks or two months. However, the core lesson learned from this experience is that organizational transformation is not a one-size-fits-all endeavor.
With another organization, we met a different approach. The Transformation Leader (TL) at this organization opted to deviate from the established best practices and guidelines for learning at scale. Instead, this person pursued their unique method at the cost of the organization being implemented. In fact, it appeared that this Transformation lead was inclined to label transformational stages as “complete” without substantial evidence, perhaps to maintain a semblance of progress and appease peers which is against the core beliefs of the model. Unfortunately, we believe that misunderstanding of the core concepts of the model, and the fear of not showing progress and keeping executives ground reality, could create a false sense of improvement. All of which further clouds the adoption and validation of the Base Camp model due to the ability to understand if the challenge to adopt and implement is execution, design, or organizational constraints.
Most importantly, it’s worth questioning whether the Basecamp model was ever deliberately designed to tackle technical challenges. Over the past decade, it appears that many organizations tend to halt their transformation efforts at Basecamp 1 since Basecamp 3 tackles the technical challenges of an organization. While the current situation points to difficulties at the Basecamp 1 stage, it’s essential to consider the long-term implications.
40 Things We Question
- No exit plan: Unfortunately, many individuals involved in coaching and implementing the transformation often experience an abrupt ending, which is colloquially referred to as being ‘celebrated out the door.’ This can be disheartening for those who have invested their time and effort into the transformation. This issue isn’t limited to external coaches and consultants; entire transformation teams have been disbanded due to a lack of clarity regarding the value delivered by the Basecamp transformation.
- No Evidence of Success for Basecamp 3-5: After nearly 15 years of operation, the model has failed to provide repeatable, clear definitions for BC3, BC4, and BC5. As of Summer 2022, these items were not documented in the centralized Playbook although proposals had been submitted every year, but never adopted. If considering the model, it might be prudent to request a live and immediate share of the BC5 playbook. This raises significant questions about the model’s adaptability and relevance in addressing the complex technical landscapes organizations face today due to the misunderstanding and lack of complete documentation in comparison to SAFe, Less, or any other well documented governance model.
- Long-Term Dependence on External Consultants: One prominent challenge lies in the prolonged reliance on external consultants. While the model itself is relatively straightforward, its documentation is lacking. In some instances, it’s perplexing why such an extensive consultant presence is necessary beyond a 16-week timeframe. Even considering the “See One, Pair on One, Do One” model, it’s reasonable to expect that internal employees should be capable of handling day-to-day transformation activities within a year. The simplicity of the Basecamp model contrasts with the diversity of outcomes it attempts to address. After completing a single expedition, many coaches should possess the knowledge to derive the entire Outcome-Based Plan based on the next stable state. Thus, maintaining a continual dependency on external consultants might not align with the principles of a sustainable model.
- The Transformation Outcomes are Not Business Outcomes: The Basecamp Model, like many transformation frameworks, sometimes falls into the trap of emphasizing internal transformation outcomes over direct business outcomes. While transformation outcomes, such as improved Agile practices and team collaboration, are important, they don’t always directly align with core business objectives like increased revenue or customer satisfaction. This can lead to a gap between successful internal transformation and tangible business value. It’s crucial to remember that true success lies in aligning transformation efforts with strategic business goals. This ensures that the organization not only transforms internally but also sees a meaningful impact on its overall success, making the transformation sustainable and valuable.
- Too Many Transformation Coaching Roles: The high density of coaches and transformation roles creates an expensive, political, and slow change. Rather than leaning an team leads, managers, and other organizational leaders – the model requires these roles to be successful.
- The Model Doesn’t Trust Software People: The Basecamp Model displays signs of aging due to its persistence in assuming that developers can only perform coding tasks. This is notably visible in the composition of coaches, where the majority are non-technical. Additionally, the model imposes stringent governance on software professionals, driven by the System of Transformation’s emphasis on rigid processes and the prioritization of achieving “perfect agile” over successful technical outcomes. It’s noteworthy that as of Summer 2022, the playbook and assessment still reference manual testing as acceptable up to Basecamp 3.
- Heavy Focus on Development not Day 2 Operations: One of the primary criticisms is that the Basecamp Model heavily emphasizes software development and Agile practices while giving comparatively less attention to what happens after software is deployed. While it excels in promoting Agile development, it often lacks clear guidance on how organizations should manage and maintain software in production.
- Limited Guidance on Ops Practices: Traditional Ops practices, such as system monitoring, infrastructure management, and incident response, are typically outside the scope of the Basecamp Model. This can create a gap where organizations may excel in Agile development but struggle when it comes to ensuring the reliability and performance of their software systems.
- Incomplete Software Lifecycle Coverage: The model tends to focus on the earlier stages of the software development lifecycle, including ideation, planning, development, and testing. While these are crucial phases, they are only part of the broader software lifecycle. Post-deployment activities like monitoring, scaling, and optimizing are equally essential but often receive less attention in Basecamp.
- Risk of Technical Debt Accumulation: Neglecting Day 2 operations and Ops can lead to the accumulation of technical debt. This debt arises when shortcuts are taken during development to meet tight deadlines, and these shortcuts can result in operational challenges and increased maintenance efforts down the line. The Basecamp Model’s limited coverage of Ops practices may not provide organizations with adequate strategies for managing and reducing technical debt.
- Integration Challenges: Integrating Agile development practices with Ops can be challenging when organizations have primarily adopted the Basecamp Model. The lack of guidance on this front can result in friction between development and Ops teams, hindering collaboration and potentially impacting software quality and reliability.
- Outcome Deficiency: Another challenge surfaces in the misalignment between transformation outcomes and tangible business value or EBITA (Earnings Before Interest, Taxes, and Amortization). The assumption that every organization prioritizes predictability above all else is flawed. While predictability can demonstrate the value of external agencies, it doesn’t necessarily accelerate actual business outcomes. The Basecamp model may need to better integrate its outcomes with specific business metrics to ensure that transformations yield meaningful results.
- PSTIR Oversight: Neglecting the PSTIR model, which stands for Plan, Socialize, Tailor, Implement, and Revise, can result in generic transformation plans that fail to cater to the unique needs of an organization. These plans may lack the necessary endorsement from executive leadership, leading to confusion and chaos. Properly adhering to the PSTIR model is essential to tailor transformation efforts effectively and ensure alignment with an organization’s specific requirements and goals.
- Sponsor Engagement: Sponsors, often high-ranking individuals within an organization, can struggle to fully comprehend the intricacies of transformation outcomes due to their limited understanding of the model. Unfortunately, this realization typically occurs later in the transformation process. This lack of expertise can lead to challenges in effective sponsorship. It’s a common occurrence, and in some cases, the Transformation Leader (TL) may be replaced with a new one to better align sponsorship with the model’s requirements.
- Lack of Visual Representation and Accountability: To enhance clarity and align goals effectively, there’s a need to integrate the PSTIR model with visual representations. Tools like a large kanban board or software platforms such as Jira can provide a visual framework for tracking and managing transformation efforts. This visual representation helps in making the progress and goals more transparent and accountable throughout the organization.
- Outdated Basecamp Model: The original Basecamp model, dating back to early 2010, was established before the widespread adoption of modern software engineering practices. As a result, it may not adequately emphasize technical outcomes, capabilities, and competencies that are crucial in contemporary software development. Adapting the model to incorporate these modern practices is essential for its continued relevance and effectiveness.
- Technical Debt Overshadowing: Transitioning to Basecamp 2 (BC2) can encounter roadblocks when there is unaddressed technical debt. This can cause significant setbacks that might have been mitigated if technical debt had been tackled from the outset. Addressing technical debt early in the transformation process is crucial to ensure a smoother transition to subsequent stages of the Basecamp model.
- Unclear Technical Approach: The documentation and guidance for Basecamp 3 (BC3) are notably lacking, making its implementation a questionable endeavor. In cases where organizations attempt to implement BC3, they often find themselves in a situation where they must create custom solutions. This customization can result in a prolonged timeline for implementation, particularly for organizations that have not kept pace with modern technology practices such as Continuous Integration and Continuous Deployment (CI/CD). Such organizations may experience delays in mastering these practices, further extending the implementation timeline. Further delaying the value of adoption of BC4 and BC5.
- Overestimating Coaching Duration: There exists a common misconception that coaching can fully equip engineers within a mere 16 weeks. Scaled or not, this notion doesn’t align with the reality of acquiring the years of experience often required for mastery in complex technical domains. Moreover, the coaching provided under the Basecamp model tends to focus on dated practices like Extreme Programming (XP), Mob Programming, Pair Programming, and Test-Driven Development (TDD). It does not adequately address modern practices such as the formation of platform teams or the utilization of artificial intelligence (AI) to enhance technical debt remediation. This misalignment with current industry standards can hinder the effectiveness of coaching efforts.
- Ignoring the Outside World: In some instances, organizations using the Basecamp model have been observed attempting to build custom Behavior-Driven Development (BDD) Continuous Integration/Continuous Deployment (CI/CD) pipelines rather than leveraging existing tools and practices available in the broader industry. This approach can impede progress and efficiency, as it isolates the organization from industry-standard practices and tools, potentially leading to inefficiencies and misalignment with best practices in software development.
- Scaling Challenges: As organizations progress through the Basecamp model, they often encounter difficulties when attempting to scale technical coaching or product extraction. This approach may not represent the most efficient strategy at this juncture. In fact, it lacks a proven success story, and its effectiveness in large-scale implementations remains uncertain. Instead of focusing on scaling these aspects, organizations might consider alternatives such as outsourced technical remediation and recruiting experienced developers. In many cases, organizations do not require individuals capable of remediating major technical debt; rather, they need people adept at adding new features and enhancing existing systems. Investing heavily in skills that are predominantly used once can be wasteful in terms of time, effort, and financial resources.
- Accurate & Transparent Assessments: Transparent assessments, which include active involvement from leadership, are crucial for ensuring an accurate evaluation of progress within the Basecamp model. Unfortunately, this transparency is often overlooked, and sometimes misunderstood or hidden from leadership due to the misconception that “managers and leaders are not agile.” This lack of transparency can result in unclear acceptance criteria for success, and, more importantly, leaders may struggle to effectively sponsor the transformation initiative.
- Tailored Assessments: Customizing assessments, with the endorsement of leadership, is essential to ensure alignment with an organization’s unique context. Tailored assessments serve to promote a unified message from top-level leadership down to the rest of the organization regarding the transformative changes. When this customization is neglected, it can lead to situations where middle managers inadvertently coach against the transformation, further complicating the change management process.
- Outcome-Tied Assessment Criteria: Linking each assessment question or activity to specific outcomes reinforces the direct impact on transformation goals. This allows the entire organization to be involved in the transformation. When this doesn’t happen coaching makes little sense, and teams and leadership get frustrated.
- Continuous Reassessment: Regular reassessments are essential to capture any backsliding and rectify deviations from desired outcomes. Unfortunately, a common practice is that once an assessment achieved “always” it would never be readdressed. This would ensure “basecamp outcomes” were achieved on paper, but not reality.
- Co-Creation of Coaching Plans: Assessments should trigger the creation of collaborative coaching plans by the team and the coach, endorsed by stakeholders. When this doesn’t happen, the coaching is completely ineffective, and the stakeholders are completely confused on where they are within the transformation.
- Outcome-Tied Assessment Criteria: An effective practice involves linking each assessment question or activity to specific outcomes that directly contribute to transformation goals. This linkage ensures that the entire organization is actively engaged in the transformation process. When this crucial connection is missing, coaching efforts may seem disconnected from the broader objectives, resulting in frustration among teams and leadership alike.
- Pre-Expedition Assessment Criteria: A crucial aspect of the transformation process involves establishing assessment success criteria upfront, which may include metrics like completion percentages and non-negotiable objectives. This proactive step serves to set clear expectations, particularly for executive leadership. It aligns all stakeholders with the desired outcomes and helps avoid ambiguity. One notable part of this process is referred to as “Define the End State,” where client leaders are actively involved in defining the ultimate goals, the subsequent stable state, and the comprehensive transformation plan, often referred to as Outcome-Based Planning (OBP). However, when this critical step is either missed or not executed effectively, it can lead to widespread confusion among stakeholders. Unfortunately, these issues often don’t become apparent until later stages of the transformation, typically around week 12 or later, making early clarity and alignment even more vital.
- Metric Clarity: Early in the transformation journey, it’s imperative to define and establish clear baseline metrics for outcomes in BC1. This proactive measure serves to prevent confusion and misdirection within the organization. Surprisingly, this critical step is often overlooked and tends to emerge as a concern around the 10th week of the transformation process.
- Effective Data Collection: To ensure the accuracy and consistency of metrics, organizations must implement a reliable data collection process. This typically involves the use of tools like Excel and Application Lifecycle Management (ALM) software. Excel plays a role in promoting critical thinking within the team, while the chosen tools help verify the accuracy of the collected data. In cases where these processes are not in place, it’s essential to understand that, by rule, the reassessment of metrics becomes necessary, adding at least six more weeks to the timeline. Fortunately, by the time I concluded my involvement, most major ALM systems had been configured to efficiently collect these metrics.
- Predictability through Metrics: The choice of sprint duration can significantly impact the transformation process. While the two-week sprint is a common practice, its necessity remains unclear, often causing unnecessary delays. Consideration should be given to shorter sprints, such as one-week iterations, which can expedite the establishment of trendlines and enhance predictability.
- Regular Metric Socialization: Metrics must be shared consistently throughout the transformation journey. This includes presenting them during sprint demos, discussions in product team meetings, and dialogues with leadership. By ensuring that metrics are effectively communicated to teams by stakeholders and executives, organizations maintain a sense of safety and alignment. Failure to share metrics regularly can lead to unforeseen challenges, with teams caught off guard by the lack of progress, particularly around the 14-week mark.
- Comprehensive Tier Metrics: Coordinating and accurately recording metrics across all tiers of the organization is a persistent challenge, yet it remains essential for gauging overall progress. This aspect of metrics management is frequently overlooked and tends to become apparent only later in the expedition. Failing to address this issue in a timely manner can create uncertainty regarding the true extent of progress achieved in the transformation effort.
- Approved OBP: The Outcome-Based Plan requires endorsement from sponsors (ELT/TLT/ ESC), cementing a foundation of aligned expectations. When this isn’t done, the teams do not feel safe implementing the change, and the middle management will fight the change. It should follow PSTIR, like everything else.
- Clear and Measurable Outcomes: Outcomes must possess measurable criteria that directly relate to assessment results, reflecting tangible transformation progress. When they aren’t tailored to the organization, the coaching is disruptive, and everyone fights the change e.g. (no estimates vs story points, quality is a part of the development team). Each outcome should move across the PSTIR kanban and be accepted by the leadership.
- Guiding OBP Principles: The “For, To, with” model grounds the OBP process, emphasizing collaboration and co-creation with stakeholders. A common mantra is “We can’t do it for you, we can’t do it to you, we can only do it with you”; but without tailoring using PSITR and without the support of the leadership chain, the entire model remains a “To” Model, because no one is involved in the next stable state. It makes no sense and isn’t safe.
- Aligned Outcome Working: Enabling each outcome to be tackled individually through the PSTIR Kanban with a Work in Progress (WIP) limit of 1 fosters accountability and prudent decision-making. When multiple outcomes are in progress, executive leadership isn’t required to make the “clearings and conditions for change” exist.
- Outcome Completion Criteria: Achieving outcomes necessitates completing all activities and acceptance criteria, with teams and TLT endorsement with supporting metrics. This requires the expeditions to be set up appropriately. Normally this isn’t caught until week 10 of the expedition or later.
- Tailored Coaching Playbooks: Activities, akin to coaching sessions, require personalized playbooks. Adhering to tailored coaching strategies avoids mishaps. Unfortunately, in “Defined the End State”, this is overlooked. Additionally, “agile” coaches try to implement things that do not tie back to executive measurable outcomes. Things like pure scrum, pure agile, pure XP, dilute the organizational objectives, and create noise.
- Team Acceptance: Activities should be discussed and embraced by the team. Activities involving critical elements like estimation and acceptance criteria may need repeated iterations for approval. However, too many coaches treat activities like a check list and impose their myopic will on the team.
Our Recommended Next Steps
For those currently entrenched in the adoption of the Basecamp Model, the path forward need not entail a complete overhaul of existing practices. Instead, a strategic blend of elements from various methodologies can be a viable approach. Specifically, there is an opportunity to amalgamate the foundational components of the Transformation Leadership Team (TLT), Executive Steering Committee (ESC), and Outcome-Based Planning (OBP) with select principles from the Scaled Agile Framework (SAFe) or another model defined by the organization.
Crucially, this adaptation doesn’t necessitate a prolonged reliance on external coaching. Rather, the potential exists for a smoother transition toward a more comprehensive operating model that maintains a semblance of continuity with existing practices, while using internal coaching and leadership to design and implement the desired change.
If this article resonates with your organization’s objectives and aspirations, there is a network of professionals well-versed in both Modern Software Delivery principles and the intricacies of Transformation Governance that can help you achieve your outcomes. We stand ready to facilitate this transition, bridging the gap between your current practices and a more holistic and responsive operational model. The result is a strategic evolution that leverages the strengths of different methodologies to meet your specific needs effectively.
Our 3 Things
1. Continue to operate the System of Transformation lead by an internal executive change manager: The System of Transformation, ideally spearheaded by an internal executive change manager, serves as the driving force behind the transformation endeavor. This leader is responsible for championing change within the organization, working closely with C-suite to align transformation objectives with the company’s strategic vision. This step ensures that the transformation stays on course and maintains the commitment of leadership.
2. Design your future state, next stable state, using common practices such as Value Stream Mapping: To achieve a successful transformation, it’s essential to have a clear vision of both the future state and the next stable state of the organization. Utilizing common practices like Value Stream Mapping allows teams to visualize and understand the current state of operations, identify areas for improvement, and design a future state that aligns with transformation objectives. This step provides a roadmap for the transformation journey, guiding teams toward their desired outcomes.
3. Augment the technical capabilities until the teams have mastery of the practice: Technical proficiency is a cornerstone of successful transformation, especially in today’s rapidly evolving technological landscape. Organizations must invest in enhancing their technical capabilities to ensure teams have the mastery required to execute the transformation effectively. This often involves upskilling and reskilling employees, adopting modern software engineering practices, and leveraging emerging technologies. Mastery of these practices empowers teams to navigate technical challenges and drive the transformation toward its desired outcomes.
We can help. Rather than use a static model out of 2008, our staff augmentation engineers have experience in the basecamp model and can help your organization achieve the outcomes you select, and are willing to help by writing code on the team.