Mastering Hybrid Agile: Building the Foundation for Scaled Scrum

In the realm of project management, the evolution towards agile methodologies, particularly through the adoption of Hybrid Agile approaches like Scaled Scrum, marks an important shift for organizations aiming to navigate the complexities of large-scale project and program execution. Scaled Scrum extends the conventional Scrum framework to coordinate multiple teams' efforts, enabling a cohesive approach to managing expansive projects emphasizing collective effort and phased development. This methodology is especially pertinent for organizations that have experienced success with individual Scrum teams. However, many organizations still need the sequential nature of the Waterfall model due to the demands of staying coordinated with the strategic and operational objectives of the organization. Individual Scrum teams emphasize the need for ownership and autonomy. While these are important qualities of a successful Scrum team, cross-team dependencies, timing, and architectural scalability require communication and coordination. Transitioning to a Scaled Scrum environment through a hybrid model provides an opportunity to leverage this success on a broader scale, introducing agility while maintaining the structural benefits of traditional waterfall program management practices.

ACHIEVING BALANCE THROUGH A HYBRID SCALE SCRUM

Integrating Scrum practices into the Waterfall model as part of a hybrid approach allows a melding of bottom-up and top-down approaches using now familiar structures. By blending the predictability of the Waterfall model with the flexibility and responsiveness of Scrum, organizations can achieve a balanced project management approach. This balance is crucial for navigating project challenges effectively and delivering complex projects successfully. However, the foundation of this success lies in the correct organization and optimal sizing of Scrum teams, underscoring the principle that organizational structure is the bedrock upon which agile methodologies can flourish.

OPTIMIZING SCRUM TEAM SIZE IN HYBRID AGILE ENVIRONMENTS

For this transition to be effective, organizations must first ensure they are correctly structured. A crucial aspect of this structure is the formation of Scrum teams that are optimally sized to maintain a manageable span of control This discussion thread on this topic summarizes observations made in many hybrid agile environments. This foundational step is essential for creating teams that can function efficiently and with a high degree of responsiveness within the Scaled Scrum framework. Only with teams that are properly organized and sized can organizations begin to address the dual objectives of maturing their Scrum practices and interconnecting these teams within a hybrid program, especially when these teams are collaborating on a common product or striving towards a shared goal and fully recognizes the benefits of agile.

The tendency of organizations to perceive challenges as stemming from personnel issues rather than underlying structural problems is a common pitfall. This perspective often overlooks the importance of organizational design in facilitating effective team dynamics and agile adoption. Proper organization is a prerequisite for accurately assessing the capabilities of a team, identifying potential skill and behavioral gaps, and implementing targeted improvements. It is only within a well-organized framework that the true potential of each team member can be realized, and the collective strengths of the team can be directed towards achieving project objectives.

EXPLORING AGILE SUCCESS WITH KENWAY

Are you prepared to harness the potential of Agile methodologies for your business pursuits? Whether you are embarking on your Agile journey or seeking to refine established practices, our experienced team is poised to provide steadfast support. Navigate the complexities of Agile alongside us, as we work together to revolutionize your business landscape. Connect with us today to embark on a journey towards transformative success.

FAQs:

What is hybrid agile?

Hybrid agile is a project management approach that leverages both waterfall and agile methodologies. It aims to provide the predictability and structure of waterfall while benefiting from the flexibility and responsiveness of agile practices at the team level.

While Scrum teams focus on delivering value within their sprints, program management oversees the project's overall direction, setting milestones and monitoring progress against predefined schedules and budgets. The project is divided into phases, with each phase representing a significant milestone or deliverable. At the end of each phase, there's an integration and testing phase to ensure the work completed by different teams aligns with project objectives.

Throughout the project, mechanisms are in place to gather feedback from stakeholders, customers, and end-users. This feedback loop allows for adaptation of the project plan, refinement of requirements, and necessary course corrections. Once all phases are completed and the product is ready for release, there's a final deployment phase where the entire product is integrated, tested, and deployed for production use.

What is the difference between agile and hybrid agile?

Pure agile methodologies are favored when projects require maximum flexibility, rapid adaptation to changing requirements, and a high degree of collaboration among cross-functional teams. It's typically employed in scenarios where the end product is not clearly defined upfront or when the market demands quick releases and frequent updates. Startups, small teams, and projects with dynamic or uncertain requirements often find pure agile approaches beneficial.

However, in larger organizations with more complex projects or those operating in highly regulated industries, there's often a need for a degree of predictability and structure that pure agile methodologies may not inherently provide. This is where hybrid agile comes into play. Larger organizations may opt for a hybrid approach when they want to leverage the benefits of agile practices while still maintaining some level of predictability and control over timelines and deliverables.

In essence, the decision to use pure agile or hybrid agile depends on the specific context of the project, including its size, complexity, regulatory requirements, market dynamics, and organizational culture. Pure agile is best suited for projects where flexibility and adaptability are paramount, while hybrid agile is preferred in situations where a balance between agility and predictability is necessary to meet organizational objectives effectively.

What is a hybrid Agile team structure?

A hybrid Agile team structure when scaling with Waterfall Program Management and individual Scrum teams typically involves a combination of traditional waterfall project management practices at the program level and Agile methodologies at the team level. Here's how it can be structured:

Program Management (Waterfall):

At the program level, a traditional waterfall project management approach is employed. This involves detailed upfront planning, sequential execution of phases, and a focus on predefined schedules and budgets.

Program managers oversee the overall direction of the project, setting milestones, monitoring progress, and ensuring alignment with organizational objectives.

Requirements are typically defined upfront and undergo a formal change control process to manage scope changes.

Individual Scrum Teams (Agile):

Within the program, individual Scrum teams operate in an Agile framework. These teams are cross-functional and self-organizing, focusing on delivering value in short, iterative cycles known as sprints.

Each Scrum team works independently, with its own Product Owner responsible for managing the product backlog and prioritizing tasks.

Scrum teams hold regular ceremonies such as sprint planning, daily stand-ups, sprint reviews, and retrospectives to facilitate collaboration, transparency, and continuous improvement.

What is large scale scrum?

In large organizations, balancing top-down planning and dependency mapping with Agile principles at the team level is crucial for successful execution of complex projects. While the Scaled Agile Framework (SAFe) is gaining prominence as a widely adopted approach, it's important to note that SAFe is not the only Scrum at scale methodology. However, SAFe stands out for its structured approach to scaling Agile practices across multiple teams.

At the top-down level, SAFe emphasizes the importance of strategic alignment and planning. This involves defining clear objectives, prioritizing initiatives, and allocating resources effectively. By establishing a shared vision and roadmap, leadership ensures that all teams are aligned with organizational goals and priorities.

Simultaneously, SAFe recognizes the importance of Agile principles at the team level. Agile teams operate in short iterations, delivering value incrementally and responding quickly to change. They are empowered to self-organize, collaborate closely, and make autonomous decisions to achieve their objectives.

To reconcile these two perspectives, SAFe introduces mechanisms for dependency mapping and coordination. Teams identify dependencies early on and work collaboratively to address them. Regular synchronization events, such as PI Planning and Scrum of Scrums, provide opportunities for teams to align their work, resolve dependencies, and ensure that everyone is moving in the same direction.

By maintaining a balance between top-down planning and Agile principles at the team level, organizations can achieve agility at scale while ensuring alignment with strategic objectives. This enables them to respond effectively to market changes, deliver value to customers, and drive continuous improvement across the enterprise.

Agile Flexibility vs. Hybrid Agile: Understanding the Difference

Does the term “Agile flexibility” sound redundant to you? To those familiar with Agile project management, it is implied that Agile practices will allow for flexibility… in theory. In practice, there is often resistance to being more flexible after transitioning to Agile. It’s common for teams to push back against modifying Scrum ceremonies to meet a project’s unique circumstances or adding more traditional waterfall approaches in a hybrid approach.

“We can’t extend the sprint, that’s not how we run Agile here.”
“You can’t set a hard deadline, this is Agile!”
“All team members, regardless of their IT division, need to be involved in this sprint.”
“Where is my project owner? Why aren’t any business people in this Scrum?”
“You can’t run multiple sprints at the same time.”
“We don’t do Agile; we only use the Waterfall Model.”
“This project is all or nothing, Agile just doesn’t make sense.”

These are real phrases that we have heard at client sites while managing projects using the Agile methodology. However, their projects may actually require a more flexible hybrid Agile methodology. The Agile waterfall hybrid approach allows you to cater to the needs and capabilities of the team working on the project. It also enables you to take advantage of the strengths of Agile and waterfall methodologies while minimizing their weaknesses.

Hybrid Agile or Agile Flexibility?

What is the difference between hybrid Agile and Agile flexibility? Agile is, by definition, flexible. It was designed for speed and adaptability, which businesses need to compete in today’s fast-moving landscape.

How Agile’s Flexibility Helps Companies Remain Relevant

As businesses struggle with the demands of compiling, scaling, and managing their data, Agile practices offer flexibility that can help them adapt. For example, when a telecommunications firm wanted to incorporate more data-driven processes in their business, they were stifled by constantly changing requirements and business priorities. Kenway took a multi-pronged approach to helping them leverage their data more effectively, with Agile transformation being a key component.

First, we created a more robust data governance process for their reporting applications to minimize data quality and availability issues caused by the high velocity of change in their environment. We called this the “front door.” This streamlined and organized the process for submitting requests for new applications.

Next, we collaborated with their team to build a continual, iterative approach to development. After a request was submitted, we interviewed each client to gather their high-level requirements for each application, with the goal of building out more detailed requirements while setting the expectation that there would be future changes in subsequent interviews. This Agile approach allowed for faster development while prioritizing the firm’s most critical needs first.

Because requirements and features of applications may change from our initial interviews, Agile workflows ensured that our process and applications were built with the idea that there would never be a “final” product. These applications needed to be updated quickly as the business needs evolved. Agile’s flexibility enabled the firm to make requests on a day-to-day basis and achieve quality results in a timely manner without worrying about the effects of continual change.

Why Hybrid Agile Is Needed

Despite the success of companies like the telecommunications firm, using Agile alone may not be suitable for every project at every organization. Transitioning from a traditional waterfall to Agile can result in gaps in vision, planning, and coordination, which often bring frustration and an unwillingness to blend approaches in a way that meets the unique needs of the environment. Often, the most fervent Agile evangelists are hesitant to try a hybrid approach due to the belief of regression or the scrum team losing control and being directed from the top. Deviating from tried and true Agile methods in the eyes of the converted presents a cavalcade of risks.

The hybrid Agile approach allows for teams that are currently using Agile to continue using Agile and gradually blend in any waterfall teams or practices to ensure alignment and the ability to stay in sync with the needs and objectives of the organization. This Agile waterfall hybrid approach can be especially useful for large organizations that want to scale Scrum beyond a small team.

For example, multiple longer-duration, concurrent sprints can be used at the onset of a project. This works well with the waterfall-experienced teams. Eventually, these sprints merge into combined sprints as the project progresses, molding into a more traditional Agile structure. With large projects, a “Scrums of Scrums” can be leveraged in the early stages of the project, to keep teams aligned. A “Scrum of Scrums” or Program Meeting is a regularly occurring forum that brings together representatives from the various sprints and scrum teams in the same meeting which allows for information sharing, collaboration, and planning.

Hybrid Agile in Practice

Kenway was tasked with implementing Agile on a large, complex project that involved five independent IT teams: two that used traditional waterfall methodology and three that used Agile development. The project was on an 8-month (32-week) timeline.

In order to cater to the different teams that used different development methodologies, the initial sprint structure for the first six months had Agile and traditional waterfall teams on concurrent sprints schedules and a program manager. The three Agile teams used traditional, two-week sprints, and the waterfall teams were allowed to run individual, concurrent sprints with longer lengths of four to six weeks.

This gave the teams new to the process (i.e. the two waterfall teams) time to learn Agile tools, become familiar with daily Scrum and stand-up meetings, and the stakeholder reviews of requirements, retrospectives, plans, and backlogs. By extending sprints to four to six weeks, the learning curve around Agile meetings and tools was much easier to handle. Over the final nine weeks, the last three sprints were positioned as a final merge or blend of all of the teams.

Amazingly, the traditional waterfall teams embraced the Agile methodology about two months into the project (roughly midway through the second sprint), and by the time the sprints were merged, several of the traditional waterfall team members became such strong supporters and became “Agile Evangelists.” That is, instead of taking the expected six months to adopt Agile, the traditional waterfall resources embraced it within two!

By allowing extra time and presenting Agile in small steps, the traditional waterfall teams not only had the time to learn the tools and the methodology, but were also able to experience the value of Agile Development—concise design documentation tools and processes, more rapid QA cycles, immediate feedback, and regular interaction with business teams.

The Benefits of a Hybrid Agile Approach

So, what are the benefits of embracing a hybrid agile methodology?

Employee morale and motivation often increase in Agile, because this reward of production-ready code is frequent (monthly or even weekly) as opposed to the longer traditional waterfall cycles. To see your work moving into production using timely software releases following manageable blocks of effort is measurably rewarding.
Furthermore, increased communication between technical and business teams, often a challenge at first, becomes rewarding and enjoyable. The Agile waterfall hybrid approach using program management with multiple Agile teams not only breaks down the communication barriers that often exist between business and IT teams, it allows leadership the ability to influence and guide the efforts in keeping with the strategic and operational objectives of the organization. Agile groups quickly realize that the two organizations are working together toward a common objective. Scrum and stand-up meetings, as well as the backlog grooming, retrospective analysis, collaborative planning, and regular stakeholder meetings, allow personalities to shine and bonds to form that may not have previously occurred. On many occasions, I have witnessed programmers and business managers that had been sitting on the same floor for years without speaking become trusted work partners, even fostering friendships and socialization outside of the workplace! Agile breaks down social barriers as well as business and technical barriers. Yes, cats are playing with dogs, and now white coats and blue coats can eat lunch together!

Finding the Ideal Agile Partner

Undergoing an Agile transformation to improve your organization’s processes is no small undertaking. Kenway can help your organization make the transition and ensure alignment between various teams and stakeholders involved in your processes. Our experts can guide you through the most challenging aspects of Agile transformation, including determining whether and where to incorporate a hybrid Agile approach.

To discuss how Kenway can help with your Agile development concepts and Agile transformations, connect with one of our consultants to learn more.

Hybrid Agile and Agile Flexibility FAQs

What is hybrid waterfall Agile?

A hybrid waterfall Agile approach combines practices from Agile and traditional waterfall methodologies. The hybrid Agile waterfall can help companies ease the transition to Agile and use development practices that are more suited to their projects and business needs.

Can Agile and waterfall be combined?

Yes, Agile and waterfall methodologies can be combined into an approach called Hybrid agile.

6 Steps to a Successful Agile Transformation

What does it mean for a business to be Agile? The common definition of Agile is the “ability to move and think quickly and easily.” In the business world, Agile refers to a set of values and principles that emphasize team collaboration and ownership. Agile business and technology teams work closely to ensure that there is cross-functional communication, full alignment on project objectives, and the ability to respond quickly to change.

Take for example Microsoft, which over the course of ten years had a gradual “bottom-up” adoption of Agile practices among several development teams. By implementing Agile, these teams overcame the common pitfalls of large organizations that have become bogged down by bureaucracy — slow decision-making and resistance to change. They also served to demonstrate to the greater organization that “going Agile” could yield significant success. Eventually, under the leadership of CEO Satya Nadella, who had previously led one of these Agile teams and knew the benefits firsthand, the entire organization embraced an Agile mindset that subsequently became an integral part of the firm’s culture.

Microsoft’s Agile transformation journey is akin to how most organizations finally adopt enterprise agility. However, there are many different ways an enterprise can pursue and achieve agility. McKinsey describes how some organizations are born Agile, while others may reflect one of three other types of Agile journey:

An all-in approach, which requires an organization-wide commitment to becoming Agile
Step-wise, which is more systematic and discreet
Emergent, which describes a bottom-up approach, similar to the one illustrated in Microsoft’s transformation journey

In this blog, we will define Agile transformation, describe an Agile workflow, and take a look at the benefits of Agile planning. We’ll also cover how to develop an Agile transformation plan, potential roadblocks, and their solutions, and review our approach to helping businesses achieve Agile flexibility through transformation.

What is Agile Transformation?

An Agile transformation is when an organization embarks on the journey to fully adopting the Agile development values and principles, as outlined in the Agile Manifesto. At Kenway, we define Agile transformation as an approach under which requirements and solutions evolve through the collaborative efforts of self-organizing and cross-functional teams, product owners, and the customers/end users they represent. Our methodology advocates adaptive planning, evolutionary development, early delivery/feedback, and continual improvement—all while remaining highly responsive to change.

Agile Workflow

An Agile workflow emphasizes team collaboration, testing and learning, and the four core values derived from the Manifesto for Agile Software Development:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change by following a plan

An Agile workflow is cyclic and there is no assumption that the client can describe what they want. This contrasts with a traditional workflow, which begins by identifying requirements, then developing all or most of the solution, all of which is contingent on the assumption that the client can accurately describe what they want and the development team will be able to create it.

A key characteristic of an Agile workflow is the idea of learning by doing. At Kenway, for example, we have traditionally used the Scrum methodology to implement Agile. Teams are encouraged to begin developing working software or solutions. We use the recurring meetings of retrospectives (internal sprint debriefs) to talk about what is going well and what can be improved. This way the team has improvement processes embedded into the sprint cycle that enable them to continuously improve every sprint.

Organizations that would greatly benefit from adopting an agile workflow are often experiencing pain points such as:

Late delivery of software/product
Constant revisions or redoing of work
Teams struggling to communicate or work together effectively

These are just a few examples of issues that can be alleviated by implementing Agile workflows and may signal a need to engage a consultant to help you navigate your Agile transformation journey.

Benefits of Agile Transformation

Seventy percent of organizations say Agile has added value to their business. There are several benefits to implementing Agile processes and planning in your business. These include:

Increased employee morale and motivation. In an Agile workflow, team members engage in frequent product/project review sessions and receive regular feedback throughout the project which makes teams feel like incremental progress towards the goal is always being made. Additionally, Agile teams have more autonomy and authority over their deliverables, which creates a greater sense of project ownership and self-management. A McKinsey report found that, because of these changes, successful Agile teams enjoy a 30% increase in employee engagement
Improved communication and collaboration between teams. Frequent in-person communication is prioritized within Agile teams. Regular meetings, occurring as frequently as every day, help to keep teams in sync on tasks and ensure that project objectives are aligned.
Faster time to market with more flexibility for changes. Seventy percent of companies that implemented Agile say they’re better at managing changing priorities. Agile teams are empowered to be significantly more flexible than their more traditionally managed counterparts. Agile teams work in smaller iterations, known as “sprints,” that create more frequent opportunities for feedback from stakeholders and allow teams to implement changes on short notice, from one sprint to the next.
Embedded self-evaluation and improvement. Product owners and developers regularly assess progress throughout sprints, allowing them to catch potential roadblocks early and address them before they become larger obstacles. Retrospectives are also conducted to identify opportunities where the team can improve in the next sprint or project. According to McKinsey, continuous improvements contributed to a 30% increase in operational performance among highly successful Agile teams.

What Are the Steps of an Agile Transformation?

The benefits of incorporating Agile are clear — but what does it take to reap them? Let’s take a look at key Agile transformation steps.

Understand and embrace Agile values and principles. It is imperative that for a full Agile transformation to take place, employees at every level of the organization must understand and adopt an Agile mindset and apply the principles to their processes.
Define your organization’s roles and responsibilities. Leadership teams should be created with the express purpose of coaching their respective teams to embrace change and begin to implement an Agile mindset. For example, teams should be led to self-organize by experienced scrum masters to continue maturing in Agile and facilitate more collaboration and better communication across teams.
Find expert coaching on Agile frameworks and practices. Agile coaches should be appointed to evangelize various Agile frameworks and practices. Scrum, kanban, crystal, and feature-driven development are all examples of Agile frameworks. If your business does not have the relevant subject matter expert available internally, consider bringing in outside corporate consultants, like Kenway Consulting to oversee your Agile transformation plan and help establish effective frameworks from the start.
Build a transformation road map. This step will help you specify your objectives and build corresponding checkpoints into the process. Your road map should include:

Defining the end goal or the vision for the finished product
Laying out achievable, time-based milestones
Moving away from teams operating in silos to a cross-functional setup
Defining the objectives and key results (OKRs)

Test, learn, and course correct. Practice and learn by running sprints, identifying any issues or roadblocks, and making updates to the process as you go. You don’t have to be running Agile workflows flawlessly to be able to test and learn.
Assess Your Transformation Progress. You should be tracking your business’s transformation journey and ensuring that you are moving towards your Agile transformation goals. Look for areas of the process where traditional development or project management is still prevalent and consider what may be holding back the adoption of Agile practices. If your progress has stalled, consider bringing in outside transformation consulting to support in making your transformation efforts stick throughout your organization.

Potential Roadblocks—And How to Solve Them

There are some common hurdles that you may encounter on your Agile transformation journey. To avoid becoming “Agile in Name Only” (AINO), here are some problems you’ll want to avoid:

Inconsistent communication throughout the process
Broken or non-existent feedback loops
Imprecise requirements
Traditional development processes are still in play/failure to adopt Agile practices

Solving These Issues

Achieving organizational change is no easy feat. The simple format of “start, stop, and continue” has proven effective at identifying problems with workflow processes or behaviors. Once identified, an organization can list potential improvements and prioritize which ones to focus on first. Tackling one or two problems per sprint can make the change more manageable.

Another approach is to utilize Agile workflow frameworks, such as Scrum. Scrum is a lightweight framework that helps organizations generate value through adaptive solutions for complex problems.

The Kenway Approach to Agile Transformation

The key to beginning an Agile transformation is to simply start and learn by doing. Using the principles of Agile and specific frameworks, like Scrum, teams are encouraged to begin developing working software and solutions. Recurring sprint review meetings (demonstrations to the product owner and other key stakeholders) and retrospectives (internal sprint debriefs) provide for built-in improvement opportunities within the sprint cycle that enable continuous process refinement.

Valuable Agile Techniques We Leverage

Work on the customer’s highest priorities first
Mandate right-sized documentation
Enable high collaboration
Deliver a working product early in the life cycle
Mandate a product showcase with customers/sponsors
Identify issues early when they are cheaper to fix
Mandate retrospectives (a.k.a. lessons learned) to improve

Agile Transformation: The Final Takeaways

Looking back at Microsoft’s Agile transformation, some notable points are worth mentioning. First, their transformation began with a bottom-up approach. A few teams implemented Agile practices first and achieved a level of success that made other teams wonder how they did it. They tested, learned, and eventually the transformation was expanded to the larger company. This point leads to the second takeaway — Microsoft’s transformation took time. Effective Agile transformations are often slow processes of change and process adoption over time. Third, the best Agile transformations eventually affect every area of a business and should become rooted in the culture and mindset of the organization.

Scaling Agile practices organization-wide is no small task. An enterprise may realize the value of becoming more agile and its need for transformation, but may not have the internal resources to see the process through to completion. This is where partnering with a transformation consultant with the expertise to fill in the gaps and identify your company’s needs could mean the difference between success and failure. Kenway specializes in helping their clients digitally transform their businesses and reap the benefits of becoming more Agile.

Connect with us to learn more about how we can help your business achieve its Agile transformation goals.

Agile Transformation FAQs

What must management do for a successful Agile transformation?

A successful Agile transformation relies on leaders to buy into the value of the Agile approach and drive adoption throughout the organization. Management must take the following steps to ensure their company reaps the full benefits of transitioning to Agile:

Develop the vision for what Agile transformation looks like and communicate that vision throughout the company.
Create a roadmap for Agile transformation.
Identify, train, and support change agents to implement Agile throughout the organization.
Continually monitor progress and improve.

How to build an agile transformation roadmap

To build an agile transformation roadmap, take the following steps:

Determine which outcomes you want to achieve from your Agile transformation.
Set milestones with achievable timelines.
Begin removing barriers between teams to promote a more collaborative, cross-functional approach.
Establish your objectives and key results.

How do you create an Agile transformation strategy?

To create an Agile transformation strategy, take the following steps:

Create your Agile leadership team. Engaging stakeholders throughout the organization, especially on the senior leadership team, is essential for a successful Agile transformation.
Define your Agile vision.
Identify an experienced Agile coach. This may be an internal subject matter expert or an external consultant.
Create a timeline for Agile adoption. Set target dates for certain milestones you want to archive in your Agile journey.
Identify an Agile pilot project or team.
Plan to assess your progress and continually improve.

Enterprise Agile Change Management

Organizations that have embraced traditional best practices for Change Management, we embrace the ADKAR framework, are familiar with concepts like “start at the top,” “create ownership,” “communicate the message,” etc. Those same companies execute job impact and change readiness assessments, communication plans, and change risk analysis. But is that enough? What if companies executed Enterprise Change Management agilely, achieving the same benefits Agile offers to software development (e.g., transparency, predictable delivery, improved quality, risk management, etc.)?

Risk vs. Uncertainty

Before we can answer this question, we must first accept that uncertainty exists in all change initiatives, whether the change is driven by IT or non-IT programs. With that in mind, it is important to recognize the difference between risk and uncertainty.

With risk, we may not know for sure that something will happen, but we do have an idea of its probability of occurring. With uncertainty, we have no quantitative basis to predict the likelihood of a future event occurring, or even what is the potential obstacle. Traditional change management techniques are not designed to guarantee outcomes that are inherently uncertain.

To ensure the success of our change initiatives, we must navigate through significant uncertainty. Agile methods allow us to manage uncertainty as we might manage risk, helping us accept and manage through uncertainty. The fundamental mental shift is accepting that we will learn or discover new things that necessitate an adjustment to our original plan. We accept the new situation and embrace that we must adjust when we make those discoveries. Since we can never know enough to plot a fool-proof course, we must learn as we go and make course corrections along the way. This is Agile at its core! You can implement the core Agile concept of multi-level planning to accomplish change management agilely:

How an Agile Change Management Plan Address the Three Primary Types of Uncertainty

There are three primary types of uncertainty, that if addressed agilely, can ensure an effective adoption of a change initiative even at the enterprise level. Consider below how multi-level planning addresses the three primary types of uncertainty:

Human motivations often remain hidden from our view

From the very beginning, stakeholders not only participate in but share the change initiative. The sponsor candidly admits what they don’t know and invites others to fill in the blanks. By changing course in response to concerns, the sponsor demonstrates that they not only are in touch with reality but responsive to concerns and emergent problems. Motivations may be obscure, but behavior is easy enough to ascertain if you take the time to observe. This incremental collaboration will instill confidence that the initiative is on the right track.

The future is inherently vague

Agile change management never positions the change sponsor as knowing more than they could possibly know. Since management really doesn’t know everything up front, the fact that things are going off track will often be obvious to the staff before it is to management. Agile change management does not provide a crystal ball, but it does provide ways to keep track of the emergent state of the evolving change initiative and to broadly share it. Perhaps most importantly, it expects the plan will need to adapt rapidly and frequently over the course of the initiative.

Once groups fall out of equilibrium, you can’t predict what will happen

Since agility expects change and the need to adapt to this change, it provides tools to stay tuned to developing conditions minute by minute. If for whatever reasons (i.e., unanticipated consequences), negative patterns start to emerge, they can be addressed in a timely manner and before they get out of hand.

Enterprise Change Management inherently carries with it uncertainty. Often the response to such uncertainty is resistance. However, Agile Change Management provides a way to manage through the uncertainty. You might be surprised to learn that when offered the opportunity to change in an agile way, people don’t resist significantly less because they can influence the change and thus have ownership. So go out there and be agile with your Change Management!

Kenway’s Approach to Agile

Here at Kenway, our expertise is coupled with our passion to guide organizations through the process of adopting Agile methodologies and principles. Regardless of where you are in your agile change management plan within your enterprise, Kenway experts are here to guide you throughout the entire process. If you’re ready to take the next step in your Agile journey, connect with one of our consultants to learn more.

FAQs:

How is change management handled in Agile?

Key considerations when applying agile to change management.
- Transparency and Communication: Agile emphasizes open and transparent communication throughout the organization. Change management efforts should start with clear and frequent communication about the proposed changes, their rationale, and their expected impact. Stakeholders should be informed and involved from the beginning.
- Stakeholder Engagement and Feedback: Agile change management encourages active involvement of stakeholders, including employees at all levels. Engaging employees in the change process ensures that their concerns and motivations are addressed. This collaborative approach promotes ownership, a shared understanding of change goals, and the proactive resolution of any difficult conversations, conflicts, or challenges that may arise. Continuous feedback loops help identify problems early and allow for corrective actions, ensuring that the change initiative stays on the right track.
- Leadership Support: Leadership plays a crucial role in Agile change management by setting the tone, providing resources, and modeling agile behaviors. Leaders should be visible champions of the change and actively support the Agile approach.

What are the benefits of agile change management?

- Increased Adaptability and Emotional Resilience: Agile change management embraces the idea that change is inherently uncertain. When organizations expect and plan for change, it tends to decrease emotional responses to the unexpected, helping the team remain fact-based and rational. This adaptability and emotional resilience ensure that change initiatives remain aligned with the organization's goals and can be adjusted as needed.
- Higher Quality and Predictability: Agile principles borrowed from software development, such as transparency and iterative planning, can improve the quality and predictability of change initiatives. By breaking down changes into smaller, manageable increments, organizations can more effectively track progress and make data-driven decisions for continuous improvement.
- Employee Ownership and Alignment: When employees are actively involved in shaping the change, they feel a sense of ownership. Agile empowers individuals and teams to make decisions and implement changes within their areas of expertise, increasing their commitment to the success of the initiative. Recent scaled agile frameworks have proven effective in reconciling the dynamic tension between bottom-up ownership and autonomy with top-down strategic and operational objectives. This alignment ensures that organizational goals and individual contributions are harmonized, leading to more successful change implementations.

Does Agile have a change control board?

- In Agile methodologies, the concept of a traditional change control board, as commonly seen in more structured project management approaches, may not be explicitly present. However, Agile initiatives do recognize the need for effective leadership and guidance to support change. While it may not be referred to as a "change control board," Agile initiatives often establish a leadership steering committee, sometimes referred to as a "steerco."
- This steering committee serves as an essential component in Agile change management. Its primary purpose is to provide guidance, support, and demonstrate leadership commitment to the change initiative. The name may vary, but the function remains consistent. Whether it's called a change control board, a steerco, or something else entirely, the crucial aspect is that it consists of key leaders and stakeholders who play a central role in overseeing and steering the change process.

What is the difference between change management in a waterfall and an Agile scrum?

- The main difference between change management in Waterfall and Agile Scrum lies in their approach to planning, flexibility, communication, and the timing of change implementation. Waterfall is more structured and planned upfront, whereas Agile Scrum is adaptive, collaborative, and allows for continuous adjustments throughout the project.
- It's important to note that there is no hard-and-fast rule that dictates you must exclusively use one approach over the other. Depending on your specific circumstances and project requirements, you may choose to adopt a hybrid approach that combines elements of both methodologies. However, traditionally, Agile is preferred when there is a high level of uncertainty, and you anticipate learning and adapting during implementation. In contrast, Waterfall provides more certainty but may be less suited for projects where change is expected and the environment is dynamic. Ultimately, the choice between Waterfall and Agile should be based on a careful evaluation of your project's unique characteristics and the degree of uncertainty involved.

Scaling Scrum Beyond the Pilot Team: Navigating Larger Agile Initiatives

Agile methodologies have transformed the landscape of project and product management, playing a pivotal role in shaping organizations' approaches to Agile initiatives. By promoting business value, continuous improvement, and adaptability to ever-changing environments, Agile has become the default operational mode for both enterprises and smaller application teams. This approach thrives on the evolving collaboration of self-organizing, cross-functional teams along with their customers or end users. It encompasses adaptive planning, evolutionary development, timely delivery, and encourages frequent reflection and enhancement. While Agile often yields immediate benefits for smaller teams, expanding its principles to larger groups or across the enterprise spectrum introduces a fresh set of challenges. The effectiveness that comes so naturally to Agile teams can be at risk if scaling is not undertaken thoughtfully and deliberately.

As organizations grow confident with the Agile framework within individual teams, some may contemplate scaling their processes. It’s a significant leap from managing single teams to coordinating multiple Agile teams working together on the same product or program. Before embarking on this journey, it’s crucial to ensure that you’ve mastered the art of Agile on a smaller scale. While no organization is perfect in all areas, you should look for signs that you’re ready to expand:

Successful Pilot Teams: Your pilot Agile teams should be high-performing, with a track record of delivering quality work within the iterative cycles of sprints.
Leadership Buy-In: Executives and other stakeholders understand the value of Agile and are committed to supporting the transition on a larger scale.
Cultural Readiness: There's a culture of collaboration and continuous learning that can embrace the changes scaling brings.
Stable Agile Mindset: There should be a widespread understanding and lack of active resistance of Agile principles across the organization, not just within the pilot teams.
Scalable Infrastructure: Your organization has the tools and processes in place that can be extended to support more teams without loss of efficiency.

Blending Agile with Other Approaches: Hybrid Models

When scaling Scrum, it’s not always practical to stick to a single methodology, especially in complex environments. This is where Hybrid Agile/Waterfall models come into play, blending Agile's iterative nature with Waterfall's structured milestones and organizational leadership communication. This approach is particularly suited to organizations that manage a variety of project types or need to meet rigorous regulatory requirements.

The success of a hybrid model hinges on pinpointing the optimal integration points between Agile and Waterfall through trial and error. Adequate documentation and tracking, along with a communication cadence that supports the flexibility of Agile while respecting the defined milestones of Waterfall, are critical to this model's effectiveness.

Scaling with the Scaled Agile Framework (SAFe)

For large, intricate enterprises, the Scaled Agile Framework (SAFe) presents a more formulaic approach to scaling. By combining Agile principles with Lean thinking, SAFe enables broad collaboration and delivery at scale. Its structure, extending from individual teams to the entire portfolio, provides a robust framework for scaling Agile. It emphasizes the significance of alignment, built-in quality, transparency, and the essential Program Increment (PI) Planning events that guide the larger Agile endeavors.

Introducing Scaling Methods

As we navigate through the complexities of scaling Scrum, we recognize that there is no one-size-fits-all solution. Each organization must meticulously evaluate its unique challenges and select a scaling path that resonates with its strategic vision, culture, and project-specific needs.

Considering the move to scale Scrum within your organization? Whether you’re taking the first steps in scaling multiple Agile teams to work cohesively on a program, or deciding between a hybrid model and SAFe, the path ahead requires thoughtful navigation. Contact us to begin a conversation that could transform your Agile journey. Our expertise is in tailoring solutions to fit your scaling needs, ensuring that you maintain the Agile spirit while broadening its reach and impact.

FAQs:

What is scaling in Scrum?

Scaling in Scrum refers to the practice of extending the principles and practices of Scrum beyond a single team to encompass larger and more complex projects. It involves coordinating the work of multiple Scrum teams, often referred to as "Scrum teams of teams" or "tribes," and may involve the creation of an Agile Release Train (ART), to deliver a unified product or solution. Scaling Scrum is necessary when the scope of a project exceeds the capacity of a single Scrum team or when there's a need to collaborate across multiple teams to achieve a common goal.

Organizations typically leverage frameworks to scale Scrum effectively. Some notable frameworks include:

SAFe (Scaled Agile Framework): SAFe provides a comprehensive and structured approach to scaling agile practices across various levels of an organization, from teams to portfolios. It emphasizes alignment, collaboration, and delivering value to customers at scale.
Scrum@Scale: Developed by Jeff Sutherland, co-creator of Scrum, Scrum@Scale is a framework specifically designed for scaling Scrum. It focuses on a lightweight, modular approach that adapts to different organizational contexts while emphasizing decentralization, autonomy, and continuous improvement.
Hybrid Approaches: In addition to established frameworks, some organizations create hybrid frameworks by combining elements of Scrum with other agile or lean practices tailored to their specific needs. Hybrid approaches provide flexibility and customization options while maintaining core Scrum principles. They are often chosen when existing practices need to be integrated with Scrum or when unique scaling requirements arise.

These frameworks and approaches help organizations maintain the agility, transparency, and customer-centric focus of Scrum while addressing the challenges posed by larger and more complex projects. They enable organizations to harness the benefits of Scrum across their entire enterprise and deliver value more effectively to their customers.

When should you scale Scrum?

Scaling Scrum should be considered when an organization meets specific criteria that indicate the need for a larger and more coordinated approach to agile development. Here are some key indicators:

Successful Scrum Implementation at the Team Level: Scaling Scrum is most effective when an organization has already experienced success with Scrum at the individual team level. It's essential to have a solid foundation in Scrum practices, including regular Sprint cycles, effective Sprint Planning, Reviews, and Retrospectives, and a commitment to the Scrum values.
Understanding and Support from All Levels of Leadership: Scaling Scrum requires strong support and alignment from leadership at all levels of the organization. Leadership should have a clear understanding of agile principles and the willingness to promote and sustain the agile transformation. Without leadership buy-in, scaling efforts may face resistance and challenges.
Need for Coordination Among Numerous Teams: The decision to scale Scrum becomes evident when the scope of work exceeds what a single Scrum team can handle effectively. This often involves multiple teams working on a single product or solution. When dependencies between teams increase, and the need for synchronization and alignment becomes critical, it's an indication that scaling Scrum can help address these challenges.

What is the disadvantage of Scrum scale?

Scaling Scrum, while beneficial in many ways, also comes with its set of challenges and potential disadvantages. Here are some of the disadvantages associated with scaling Scrum:

Balancing Autonomy and Alignment: Striking the right balance between top-down alignment with strategic and operational objectives and team autonomy and ownership can be difficult. Some organizations may struggle to maintain both alignment and the empowerment of self-organizing teams.
Complexity and Overhead: Scaling Scrum introduces additional roles, ceremonies, and artifacts to coordinate multiple teams. While these are necessary for alignment and collaboration, they can also add administrative overhead and complexity to the process.
Tooling and Technology Challenges: Scaling Scrum often requires tools and technology solutions to support collaboration and communication across teams. Selecting and implementing these tools can be complex.

Scaling Scrum can be a complex endeavor, but with careful planning, training, and a commitment to addressing these challenges, organizations can successfully scale Scrum and harness the benefits of agility at scale.

What is the main issue when Agile is scaling to large systems?

When Agile is scaled to large systems, several significant issues can arise, continuing to expand the ideas discussed in the disadvantages previously mentioned. Here, we'll provide more details on how these issues manifest in organizations:

Balancing Autonomy and Alignment: In large systems, there's a natural tension between the need for alignment with strategic objectives and allowing teams the autonomy to make decisions independently. This issue can manifest as teams feeling constrained by top-down directives, leading to frustration and reduced motivation. Conversely, too much autonomy without alignment can result in teams working at cross-purposes, causing inefficiencies and conflicting priorities.
Complexity and Overhead: As organizations scale Agile, they often introduce additional roles, ceremonies, and artifacts to facilitate coordination. However, this can lead to increased complexity and administrative overhead. Teams may find themselves bogged down by excessive meetings, documentation, and processes, slowing down their ability to deliver value.
Tooling and Technology Challenges: Implementing tools and technology solutions to support collaboration and communication across large systems can be challenging. Inefficient tooling choices or poor integration can lead to siloed information and hinder effective cross-team collaboration. Teams may struggle with learning and adapting to new tools, impacting their productivity.

These issues, if not effectively addressed, can undermine the success of Agile at scale in large systems. Organizations need to carefully consider how to strike the right balance between alignment and autonomy, streamline processes and ceremonies to minimize overhead, and select and implement the appropriate tools and technology solutions that enhance, rather than hinder, collaboration across teams.

Scrum Basics: Getting to Good

In the world of software development and project management, understanding the Scrum basics is essential for success. However, while its foundational principles are widely recognized, many teams grapple with its practical application. Time and again, two recurring issues emerge: the creation of substandard user stories and the oversight of skipping retrospectives.

Scrum User Stories

User stories serve as the backbone of any Scrum project, acting as a bridge between abstract ideas and tangible product features. Their effectiveness, however, hinges on the depth of detail, clarity, and comprehensiveness. A well-crafted user story dives deep into the nuances of the feature, providing a clear picture of the desired outcome. The more detailed the user story, the less room there is for ambiguity. In today's interconnected digital landscape, user stories shouldn't exist in isolation. Linking to external documents, mock-ups, or any relevant reference material can provide invaluable context. Moreover, crafting acceptance criteria that can be answered with a binary "yes" or "no" eliminates gray areas, providing a clear benchmark for completion.

Continuous Improvement Through Scrum Retrospectives

But Scrum isn't just about planning and execution; it's about reflection and growth. The beauty of the agile mindset lies in its commitment to continuous improvement, and at the heart of this commitment is the retrospective. In the agile world, stagnation is the antithesis of progress. The business landscape of today is fluid, with “you know’, change being the ONLY constant. Retrospectives provide teams with a structured platform to reflect on their actions, celebrate successes, and more importantly, identify areas of improvement. They act as a compass, helping teams identify their current phase and guiding them towards the next. By fostering a culture of introspection and evolution, teams can transform challenges into opportunities and ensure that they are always at the forefront of excellence.

While Scrum's core philosophy is sound, its effectiveness is only as good as its implementation. By emphasizing the importance of detailed user stories, integrating external references, setting clear acceptance criteria, and harnessing the power of retrospectives, teams can ensure that their Scrum journey is both efficient and effective.

Embark with Kenway on your Scrum Journey

Grapple with the effectiveness of your implementation of Scrum? Whether you're just starting to explore Scrum basics or looking to improve individual team effectiveness, our experts at Kenway Consulting are here to guide you every step of the way. Dive deeper into the world of Scrum with us and discover the benefits of agile today. Reach out today and let's start the conversation.

FAQ

What are the five principles of scrum?

At the foundation of Agile methodologies, including Scrum, lies the crucial principle of trust. Trust catalyzes open collaboration, adaptability, and a shared commitment to delivering value. From this core principle, Scrum builds upon five distinct values:

Commitment: Each member of the team pledges commitment to the tasks and goals of the current Sprint. Beyond just timelines or objectives, there's a mutual agreement to make a good faith effort to complete all work brought into the Sprint, ensuring value delivery and trust among team members.
Courage: The team possesses the courage to confront the status quo, face challenging problems head-on, and remain true to Scrum's principles. This involves being transparent about progress, even when facing uncertainties or challenges.
Focus: With a clear shared purpose, everyone remains centered on the work of the current Sprint and the overarching goals of the Scrum Team. This concentrated attention ensures the consistent delivery of high-quality results.
Openness: Openness in Scrum isn't just about communication; it's about visibility and collaboration. Teams visualize work using tools like task boards or Kanban boards to maintain transparency. Practices like pair programming and peer review embody the principle of openness, ensuring knowledge sharing, quality assurance, and collective ownership of the codebase.
Respect: At its core, respect in Scrum is about recognizing and valuing the individual strengths and contributions of each team member. This mutual respect supports self-organizing teams, allowing them to arrange and adapt their work methods to capitalize on each member's strengths.

What are the basics of Scrum?

Scrum is a popular Agile framework that aids teams in developing and delivering high-quality products. At its core, Scrum emphasizes collaboration, adaptability, and iterative progress.

What are the key roles in Scrum?

Product Owner: Represents the stakeholders and is responsible for maximizing the value of the product by prioritizing the Product Backlog.
Scrum Master: Facilitates Scrum for the team, ensures that Scrum practices and values are followed, and helps remove any obstacles the team might face.
Development Team: A cross-functional group responsible for delivering potentially shippable increments (PSIs) at the end of each Sprint.

What are the core Scrum events?

Sprint: A time-boxed period, usually 2-4 weeks long, during which a "Done" product increment is created.
Daily Stand-up (or Daily Scrum): A 15-minute event for the Development Team to synchronize activities and plan for the next 24 hours.
Sprint Planning: An event to decide what work will be performed in the upcoming Sprint.
Sprint Review: Held at the end of the Sprint to inspect the increment and adapt the Product Backlog if necessary.
Sprint Retrospective: The team reflects on the past Sprint and plans improvements for the next one.

What are the key scrum artifacts?

Product Backlog: A prioritized list of features, enhancements, and fixes required in the product.
Sprint Backlog: A subset of the Product Backlog that the team commits to completing during a Sprint.
Increment: The sum of all the Product Backlog items completed during a Sprint combined with the work of previous Sprints, resulting in a potentially shippable product.
Definition of Done (DoD): A shared understanding within the team about the criteria that must be met for work to be considered complete.

What is Time-boxing in Scrum?

All Scrum events are time-boxed, meaning they have a maximum duration, ensuring efficiency and focus.

Just because these are the basics doesn't mean they have to be implemented all at once. Visualization of the work, adopting a product mentality, and embracing short development cycles can serve as starting points, especially if there's a need to continue delivering on deadlines during the transition.

What are the 3 pillars of Scrum?

The Scrum framework is built upon three foundational pillars that uphold every implementation of empirical process control. These pillars are essential for successfully employing Scrum's iterative and incremental approach. They are:

Transparency: This means that all aspects of the Scrum process and the work being done must be visible to everyone involved. Whether it's the progress in a Sprint, the metrics being used, or the visualization of tasks on a Kanban Board, everyone should have a clear and shared understanding. The Kanban Board, in particular, serves as a visual representation of the workflow, allowing team members and stakeholders to see the status of tasks and how they move through different stages, fostering a common perspective that aids in effective collaboration and decision-making.
Inspection: Regularly examining the Scrum artifacts and the progress towards a Sprint Goal ensures that undesirable variances or issues can be detected. Scrum practices, like Daily Stand-ups and Sprint Reviews, are set opportunities for inspection. However, inspection should be an ongoing activity to monitor progress and quality.
Adaptation: When the team or stakeholders identify aspects that are outside the acceptable limits, or when the product or process can be improved, an adjustment must be made. This is where the importance of retrospectives comes into play. Retrospectives provide a dedicated space for the team to reflect on their processes, successes, and challenges. By doing so, they can identify actionable improvements, ensuring the team is self-correcting and continually enhancing their methods to deliver the highest value.

The Benefits of Agile: Why Your Business Needs It

Let's get straight to the point. You've probably read countless articles stating "the only constant is change." Yes, we know it's true, especially in today's fast-paced business environment. But the real question is, how do we navigate this change effectively? Traditional business methods, with their rigid structures, just aren't cutting it anymore. They're becoming outdated in a world that demands adaptability and swift reactions.

This is where Agile comes into play. It's not just another business buzzword; it's a transformative approach that's reshaping how businesses operate. The benefits of Agile is that it has flexibility, collaboration, and the power to stay ahead in a market that waits for no one. It's the toolkit modern businesses need to not just survive but thrive amidst constant change.

At its core, Agile is a mindset—a way of thinking and approaching challenges that prioritizes adaptability and customer-centricity. Agile didn't just pop up overnight. It has its roots in the software development world of the 1990s, where traditional "waterfall" methods were causing more headaches than results. The solution? A set of principles and practices that emphasized collaboration, iterative development, and delivering real value quickly. These foundational pillars include Customer Collaboration, Iterative Development, Flexibility, and Team Empowerment.

Leveraging MVPs for Agile Success

While there are traditional descriptions of what a Minimum Viable Product (MVP) is, it also possesses a unique superpower. This superpower grants the Product Owner and the team the ability and mechanism to push back against the natural inclination of businesses to want everything all at once. An MVP is the most basic version of a product that allows a team to release it to the customers and gather feedback with the least amount of effort. Instead of spending months perfecting every feature, businesses can launch an MVP to test the waters, see how the market reacts, and then iterate based on real-world feedback. The power of the MVP approach lies in its speed, the feedback it garners, and its ability to reduce risks.

Embracing Agile Adoption and Ongoing Evolution

In the journey of Agile transformation, many organizations mistakenly believe they've "made it" once they've adopted the basics. With this type of Agile adoption, they roll out a few Agile practices, celebrate some initial wins, and then... they hit the pause button. They feel they've reached the pinnacle. But in the Agile world, there's no final peak—only endless climbs. Imagine a ship constantly adjusting its sails to the shifting winds. That's what Agile teams do. They don't just set a course and stick to it blindly. They're always tuning, tweaking, and turning to ensure they're on the right path. And one of the primary reasons for this continuous evolution? The environment and the team itself are always in flux. Markets change, customer preferences shift, technologies advance, and team dynamics evolve.

In the modern business landscape, staying competitive isn't just about having a great product or service. It's about how quickly and effectively you can adapt to changes, meet customer demands, and innovate. This is where Agile shines and you can find Agile success stories. Agile methodologies prioritize delivering value quickly. By focusing on iterative development and MVPs, businesses can launch products faster and adapt them based on real-time feedback. The Agile approach is built on flexibility. Whether it's a shift in market trends, a sudden competitor move, or a change in customer preferences, Agile teams are equipped to pivot and respond. By emphasizing customer collaboration and feedback, Agile ensures that products and services are closely aligned with customer needs.

In today's dynamic business world, the old playbook just doesn't cut it anymore. Sticking to rigid plans and ignoring the ever-changing landscape is a recipe for stagnation. The benefits of Agile is that it offers a fresh, adaptive approach that aligns businesses with the realities of modern markets. By embracing Agile, organizations position themselves at the forefront of innovation. They become more attuned to their customers, more responsive to changes, and more adept at navigating the complexities of the modern business environment. It's not just about doing things faster; it's about doing things smarter, with a clear focus on delivering value at every step.

Discover Agile Success with Kenway

Ready to harness the power of Agile for your business? Whether you're just starting your Agile journey or looking to refine your practices, our team is here to guide you every step of the way. Dive deeper into the world of Agile with us, and let's transform your business together. Connect with us today and let's chart a path to success!

FAQ

1. What are some the benefits of the agile development methodology?

In software development, methodologies play a pivotal role in determining how a project unfolds. Historically, the Waterfall methodology was default. It was a linear approach where each phase of a project was completed before moving on to the next, thus the reference to a waterfall. This method was internally focused, with a strict adherence to the initial scope, time, and budget. While it provided a structured approach, it often lacked the flexibility to adapt to changes, especially those stemming from external factors or evolving customer needs.

This is why Agile has gained acceptance as a superior methodology in most situations, it revolutionized the way teams approached software development. One of the biggest benefits of Agile is its emphasis on customer satisfaction. Unlike Waterfall, where the product is often revealed only at the end, Agile promotes frequent releases of working software. This means customers can see progress in real-time, provide feedback, and feel a sense of involvement in the development process. It also solves the issue that the client cannot usually tell what you want before they see what they don’t. Products then are more aligned with customer needs and expectations.

Another significant advantage of Agile is its ability to bring products to market faster. In the Waterfall approach, the entire product is developed and then released, which can be a lengthy process. Agile, on the other hand, focuses on delivering features incrementally. This incremental approach not only allows for quicker releases but also ensures that any feedback can be incorporated in subsequent iterations, leading to a product that's both high-quality and relevant.

2. How do you measure benefits in agile?

One of the cornerstones of Agile is the concept of velocity, which offers a glimpse into the amount of work a team can complete during a sprint. This insight into a team's consistency and delivery capability over time becomes a valuable indication of its efficiency.

As teams navigate through their sprints, the Sprint Burndown Chart provides insight into how well the team is progressing on meeting their sprint commitment, illustrating the remaining work.

While the positive trends in the amount and predictability of development is crucial, so is the focus. Agile teams are mindful of their Work in Progress (WIP). By monitoring WIP, they ensure a balanced workflow, emphasizing completion over the initiation of numerous tasks. This balance is important in maintaining a rhythm and preventing teams from being inundated with too many concurrent tasks.

However, perhaps the most compelling measure in Agile is the concept of delivered business value. Over time you can integrate business stakeholders and have them score the work the development teams are doing. They assess features or user stories, scoring them based on anticipated business value. As these features are implemented, a comparison is drawn between their potential and the actual delivered value. This ongoing evaluation ensures that development efforts align with the strategic objectives of the business, culminating in products that not only function well but also drive tangible business outcomes.

3. What are the five most important benefits of Agile transformation?

Agile transformation offers organizations a way to reshape their work processes, organizational culture, and mindset. The five most transformative benefits of agile are:

Enhanced Customer Satisfaction: Agile emphasizes regular feedback and iterative development, ensuring products evolve in line with customer needs. This alignment leads to products that developed based on customer expectations, fostering loyalty and trust.
Improved Team Collaboration: Agile encourages cross-functional teams to work together. This collaboration results in innovative solutions as diverse perspectives work together to address challenges, and teams feel ownership of the product because they determine the path to get to the solution.
Increased Flexibility and Adaptability: Agile organizations can adapt to changing market conditions, customer preferences, or technological advancements with ease, ensuring they remain competitive.
Faster Time-to-Market: By focusing on incremental development, organizations can release features or products faster, allowing them to respond to market demands promptly.
Continuous Improvement: Agile teams regularly reflect on their performance, ensuring they are always improving. This commitment means inefficiencies and conflict are identified and addressed quickly, leading to refined processes.

4. What are the potential cons of Agile?

Agile, a transformative methodology in software development and project management, brings with it a unique set of challenges.

No Steady State: Agile's essence is continuous evolution. This perpetual iteration means products or processes rarely reach a "final" state. This constant change can be challenging for some organizations or individuals, giving a feeling of ever-shifting goalposts.
Requires a Cultural Shift: Agile is more than a methodology; it's a mindset. Adopting Agile can be met with resistance, as it often necessitates a profound cultural transformation.
Scope Creep and the Need for Strong Product Ownership: Agile Scrum employs a backlog to manage and prioritize scope. Without robust product ownership, there's a risk of scope creep, where the project's objectives expand beyond its original intent. Moreover, there's the danger of introducing functionality that doesn't add value or isn't necessary. Strong product ownership is crucial to ensure that the backlog is meticulously managed, and features added align with the product's vision and offer genuine value.
Not Always Ideal: Agile offers numerous benefits for many projects. However, it might not be the optimal fit for all. Projects with static requirements might be better suited to a traditional approach.

Scaling Agile, the Right Way!

Agile is now the default way to run project and product initiatives. Either at an enterprise level or within just a few application teams, companies today have gone down the path of adopting agile methodologies into their development lifecycle in order to reap the benefits focusing on business value, continuous improvement and embracing that the environment will forever be changing.

For those new to agile software development, it is best described as an approach under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customers / end users. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement to deliver software in a rapid and flexible response to change.

Success in agile can often be achieved with smaller sized teams (10 people or less), but many companies are struggling to take agile methodologies to the next level by either scaling to a large single application team or scaling at the enterprise level.

I have observed approaches to scaling agile that introduce new challenges and, ultimately, make a high performing agile team less effective. These approaches (with slight variations) are:

Adding developers disproportionately to other agile team member roles.
Increasing team member numbers but not scaling supporting tools & processes (e.g., Development Operations [DevOps] and Planning).
Increasing the length of a sprint or the number of sprints.

These methods fail to increase throughput because they create bigger bottlenecks with testing, deploying, etc., or as with the case of the longer sprint, they increase batch size. This is an anti-pattern to the lean agile approach. Scaling agile effectively involves adding elements of all team members proportionally to create multiple encapsulated agile teams. These standalone teams are commonly referred to as feature teams. The number of feature teams can increase the overall development capacity by aligning them to logical scope within a single application.

In the following diagram, the feature teams include members from product management, development, architecture, security and the testing teams. Even though all the feature teams are working on a single application, these fully functioning agile teams work independently on separate backlog items with continual integration of the code.

Successful scaling of agile incorporates the following principles:

Ensuring collaboration between teams increases as much as scaling team member numbers. Often a feature lead role is used to ensure effective collaboration between the multiple feature teams. These feature leads are assigned very early in the product lifecycle.
Scaling team members in proportion for all roles on an agile team. As noted in the diagram, the ratio of product team members, developers, architects, etc. are proportionally in line with other feature teams, and therefore staffed optimally.
Increasing release and product planning activities as much (if not more) than scaling in team member size. Introducing Program Increment (PI) Planning concepts is an effective way to plan at scale. Pipeline meetings and cross program prioritization are critical activities when scaling agile.
Increasing DevOps capabilities to support increased technical complexity such as multiple code branches, multiple environments, and additional development dependencies.

The benefits of scaling agile by creating multiple feature teams are:

Effective communication between teams to ensure alignment and dependencies are identified and tracked.
Increased overall throughput of development capacity.
Increased flexibility to ebb and flow teams to specific functionality or capabilities.
Re-enforcement of the team mentality.

For example, Kenway has guided clients that scaled their agile teams by adding many developers, without increasing their product management capacity accordingly. After correcting the proportions of all agile team roles or creating additional teams to maintain the optimal team size, we introduced a new feature engagement process that added a monthly pipeline review meeting, feature prioritization meetings, and ensured (well, maybe forced) collaboration between agile teams. Effective communication was significantly increased, and all agile teams felt more connected with the feature roadmap while optimally planning for upcoming features.

Kenway provides IT Strategy services that can help any team trying to scale agile or just wanting to take their effectiveness to the next level. To do this, we can provide embedded expertise inside your delivery teams to provide coaching and / or scrum mastering to teach effective agile techniques while performing work as part of the agile team. Or Kenway can help by conducting an agile assessment to provide an outside perspective with observations and recommendations to make your agile team(s) more effective.

If you’re interested in learning more about Kenway Consulting’s approach to agile methodologies, please contact us at [email protected].

Tips and Tricks from the Pros: A Guide to Comprehensive Project Management Documentation

In my many years working in IT Program and Project Management, my favorite part of the work is serving as the narrator of the project delivery story. When managing large programs, I ask the project managers to “tell the story” of their project versus “report the status”. When you report status, you take a “one-size-fits-all” approach instead of considering your audience and what they need to know at each point in the journey. Each perspective told through a team member’s project management story is key in driving understanding and alignment, whether you’re talking to an executive or a mid-level team member.

Just like in creative writing, there are tools you can use to effectively document your project’s current status, the latest progress, and the rationale behind key decisions. For effective project management, you must employ the skill or “art” of communication. At Kenway, our Program and Project Management methodology emphasizes communicating swiftly and effectively across all channels regardless of whether the news is good or bad. Kenway leverages these best-practice tools to support and document the overall project story in order to drive successful delivery.

The Beginning

Setting the Stage: Whether you are developing a Project Charter that summarizes the objective of a project or determining the Minimum Viable Product for an Agile development effort, you need clear documentation on the objective of the project and the success criteria. After all, a novelist who writes a book no one can follow hasn’t done a good job. Formalizing the scope is not just a deliverable to check off the list, but is also a critical step to be discussed to ensure understanding by the entire audience before proceeding. After alignment, to ensure no one forgets the goal of the project, creating a one-pager to reiterate the purpose of each step of the journey is crucial.
Planning: Once you have your purpose, you will need to spend time creating a project plan for how you will achieve the project objectives. While an author may have full autonomy in how they plan a narrative, Project Managers must facilitate others to build a plan that is feasible to execute. Just as when you start a new book and guess where the story is taking you, you start a project with certain assumptions. In Agile, the goal is to plan shorter increments (sprints) so that as more is understood, you can pivot your approach. No matter the methodology, the audience needs to know how the project will get to the objective in a clear way. Communicate what is known and what is unknown; the audience needs to know where we are now (committed) and how we are reaching the next step (target).
Foreshadowing: When I am reading a book, there are times where I will get this chill up my spine – this gut feeling that says, “I think I know what may happen here.” In a project, similarly, a team member may identify a risk that may disrupt the current project plan. Although for a project, unlike a book, you don’t just “sit and wait”, you mitigate the risk by trying to figure out what can be done now so the risk doesn’t become an issue later. The better you mitigate risk, the closer aligned you will stay to your target plan. The more that risks become issues, the longer it will take to get where you are going.

The Middle

Character Development: As the project moves forward, especially those longer in duration, building relationships and understanding each person of your audience becomes very important in how you communicate. As you read a novel and start to feel connected to characters like you know them, you need to understand the perspectives of the team members and those sponsoring the project. Ask them how they like to receive information, and listen to their input and ideas. The more knowledge you gain on the project characters and on how they work best, the more effective you will be able to manage the communication of information. Remember you are the narrator, and you need to ensure the voices are heard.
Plot Twists: In most stories, you will face a plot twist. For a project, this surprise can mean time and money, so you need to prevent the drama! There are clear tools to manage these moments using issue management and change control. If something happens that delays a date on the critical path, then you need to quickly help the team drive to resolution to minimize the impact. Once the impact is known or realized, you must clearly communicate a change control, so everyone knows the impact to the original plan. In communicating and gaining sign-off from project sponsorship, the impact is accepted and the plan baseline is reset. It may take longer or take more money, but that is part of the journey which is never perfect.

The End

The Conclusion: As you near the end of the book or project, the anticipation is growing for getting to the finish line and everyone is feeling the fatigue of the road traveled. Keep the team focused by increasing the frequency of communication on progress from weekly to daily to ensure each step is staying on track. Moving to daily stand-up meetings to ensure everyone stays on the same page also swiftly lets leadership know where issues may cause delays, keeping everyone aligned through the final strides into the finish line tape.
Acknowledgments: When you finish that last sentence of a book, you feel that satisfaction and turn the page to see all the references and acknowledgments. On a project, sometimes the day after a project deploys can be the hardest. You need to ensure that everything is working as planned and any production issues are urgently addressed to minimize impacts. While everyone is happy to have gotten to the delivery date, the journey may not be over, and it is important to reflect on the journey and acknowledge the contribution of each person who helped achieve the goal.

When the journey is managed and narrated well, the project will be a success. However, if the audience is confused and frustrated about what is happening in the story, they may just stop reading and switch to a different book. I have read many books and have managed many projects and always learn from the story to help me in my life and work. I look forward to the next project journey and its first chapter.

Let Kenway help you navigate the intricacies of project documentation and management, allowing you to narrate and manage the journey of your next program or project with ease. Connect with us to learn more - we can’t wait to hear from you.

FAQs About Project Management

What is project management documentation?

Documentation for project management involves the various documents and records that are created and maintained throughout the life cycle of a project. These documents are vital to the understanding of a project and give a clear account of the project's objectives, scope, timelines, budgets, risks, and stakeholders. This project documentation can also provide a record of the project's progress, decisions, and outcomes. Some examples of documentation for project management include -

Project plan: This document outlines the project's tasks, timelines, budgets, and resource requirements.
Risk management plan: This document identifies potential risks to the project and outlines strategies to mitigate them.
Change management plan: This document outlines the process for managing changes to the project scope, timelines, or budgets.
Status reports: These documents provide regular updates on the project's progress, including completed tasks, upcoming tasks, and any issues or risks.
Performance reports: These documents show the project's progress and performance in terms of meeting objectives, timelines, and budgets.

Why is project documentation important?

Project documentation ensures that all team members are aligned and working towards the same goal. Documentation is crucial to a project’s success for a variety of reasons, including the below:

Communication: Project documentation can provide a way to communicate important information to all team members, stakeholders, and clients, easily and without risk of missing any plotlines in the overall story.
Tracking Progress: Project documentation enables the project manager(s) to track the progress of the project and identify any issues or risks that need to be addressed. It also allows the team to measure the project's performance against established goals, deadlines, and budgets.
Accountability: Project documentation provides a record of the project's decisions, actions, and outcomes, among other aspects. This can be used to hold team members and stakeholders accountable for their part in the project.
Reference: Project documentation can serve as a reference for future projects and can provide valuable lessons learned to avoid repeat mistakes and shorten the learning curve when taking on similar projects.
Compliance: Certain industries have specific regulations and compliance requirements that need to be fulfilled. Project documentation can help organizations meet these requirements with confidence.

The Art of Asking a Question

Asking a question is an art, and I recently made an artistic fail.

As a consultant, you ask a lot of questions: What are the pain points? What is the current state of affairs? And my all-time favorite, how long will it take to accomplish such task? Questions are supposed to give you answers, and yet, something about the way I asked my question did not yield the answers I needed. It took me at least 24 hours of rapidly proceeding through denial, anger, grief and acceptance (I’m pretty sure I skipped the bargaining stage) to start to figure out where was the fail.

While providing project management, scrum master and business analysis services for a particular project, I asked the development team lead to provide me with an estimate to complete a specific portion of the application software project. He answered at a face-to-face meeting on Monday. However, by Thursday of the same week, a new development manager posed a similar question and the answer and estimate were 400% higher. As the development manager was discussing the “new” estimates with me, I was gobsmacked! How did that happen in just four days?

You often hear that situations gone wrong are the best learning opportunities. I wholeheartedly agree, but it is still a terrible feeling. It’s embarrassing and something that you would prefer not to repeat. It was time for me to figure out what lessons this “Golden Opportunity” had provided. After analyzing the situation and debriefing with team members, I was able to derive three key lessons learned.

Lesson #1: When one resource is providing multiple services (i.e. wearing many hats) on a project, it is imperative they balance the competing priorities that could create conflicts of interest.

The resource providing scrum master services acts as coach and ensures the team is continuously evolving in the agile methodology. The resource providing project management services is the keeper of the timeline and budget and needs to critically evaluate whether the current situation presents potential issues or risks to the timeline and/or budget. The resource providing business analysis services helps to uncover the project business requirements and is responsible for encouraging the team to add as much functionality as possible. If the business problem is challenging and you are committed to solving it, there is a tendency to encourage optimism and over-commitment.

Lesson #2: Estimates are notoriously understated because of the optimism bias.

As a lecturer who teaches project management, I have discussed this bias with my students ad nauseam, which makes re-learning this lesson even more painful. We are all guilty of failing to see the many possible things that could go wrong during a project. And for those risks we do identify, we believe we are less likely to experience them than is true. This conundrum was reinforced as I continued to read and research all that goes into software development estimation. Studies have shown software estimates to be, on average, 40% underestimated[1]. So, unless the estimators in question have already learned that valuable lesson or perhaps never needed to learn it, you might want to consider multiplying that estimate by 140%.

Lesson #3: An estimate can be biased by the process.

The last contributing factor to the underestimated piece of work is the way I led the estimating conversation. The work for our team was divided into two-week increments, “sprints” in scrum language. When I asked for the estimate, I embedded the pieces of work inside the sprint schedules. The resource providing the estimate was anchored on a two-week time frame, to which I confirmed my expectation that the work could be completed in such time. Anchoring is influencing the frame of reference for the estimate, thereby biasing based on that frame.

Requesting an estimate is often a qualitative and subjective process that can be translated into a number often perceived to have a level of precision that it may not possess. That does not mean you cannot do it more effectively. My role in this project was to set up the conversation in a way that gave the team the best opportunity to ensure as accurate an estimate as possible. I will approach it differently next time and feel reassured that there are effective tactics in place that could better set up the team.

These three lessons learned do not make a master artist. However, making a commitment to improving one’s self by learning from past mistakes puts you on the road to powerful improvement.

I look forward to the journey.

[1] Software Estimation: Demystifying the Black Art