Scaled Agile Frameworks - A Simple Guide to SAFe, SaS, LeSS, etc.

Scaled Agile Frameworks - SAFe, SaS, LeSS, etc.

With most organizations practicing some form of agile practice (Kanban, Scrum, Extreme Programming XP, Lean, etc.) at a team level and reaping benefits,  organizations are now asking "how can we deploy agile practices to whole departments or at an enterprise level?".  

We explore the answer to this by diving into several scaled agile frameworks.  These will help organizations in the journey to scale agile practices across departments or across the enterprise.

Introduction

If your organization is considering scaling agile practices within your organization, it is important to understand the differences in the frameworks and the strengths and opportunities posed by each.

Over the past week, I read two (2) articles on scaled agile frameworks.  The first article was, “6 Scaled Agile Frameworks – Which One Is Right For You?” by By Marjan Venema.  Marjan walked through six (6) scaled agile frameworks and explained the benefits, origins, and opportunities of each.  The second article was, “The Ultimate Guide to Scaled Agile Frameworks: SAFe, LeSS, DA, Scrum@Scale” by Maruti Techlabs.  Maruti Techlabs article walked through four (4) scaled agile frameworks and provided additional context of each.  The Maruti Techlabs article also plugged Maruti Techlabs experience in the space.

Scaled Agile Journey - Mindset and Challenges

Mindset

In the article "6 Scaled Agile Frameworks - Which One is Right for You?", Marjun stresses the importance of the mindset shifts that are needed when scaling agile in the organization.  The mindset shift needed is, “letting go of (much of your) control and trusting that everyone wants to perform at their best.”

Marjan pinpoints the mindset shift means the following:

1. Decentralizing Decisions
2. Building transparency and alignment on strategic goals and how you organize work.
3. Determining the right balance between autonomous teams and cross-team dependencies.  And having a system in place to manage cross-team dependencies.
4. Changing virtually everything in the way you organize work.
5. Delivering sooner and perfecting products “in the wild” (in production).
6. Collaborating throughout your business and with your customers.
7. Updating, replacing, and integrating your information systems to enable transparent information flow throughout your company.

Challenges

Most Organizations run into challenges when scaling agile. 

Here are the most common challenges when scaling agile in an organization:

1)  Poor or no long-term planning

Long term planning for product roadmaps and product deliveries is important so the agile teams understand the work items which are most important.  

It is important for the organization to take ownership and make sure teams are accountable for long term planning. 

2.)  Delegated Authority Handling

It is important for an organization to get skilled at delegated authority handling.  This is needed to minimize disconnects and allow self-directed teams to get in synch with the organizational priorities and business decisions.

3.)  Lack of Synchronization

Large-scale organizations have many development teams.  Due to the magnitude of teams working in the organization it proves difficult for teams to be entirely self-organized, so it is important to synchronize across the teams in the organization.

It is common for self-organized teams working on similar products to challenge the need for synchronizing deliverables.  They are also prone to not wanting to work on delivering them together.  

However, it is important to synchronize across teams to minimize duplicate or wasted work, and to minimize disconnects that could impact deliveries to customers.

4.) Lack of Innovation

Large organizations may be stifled in being able to innovate.  It is important for large organizations to drive conversations and the necessary actions around innovation.  It is important for organizations to celebrate innovation and reward innovation that takes place within the organization.

5.) Culture and Work Management Shift

Agile and Scaled agile is a cultural shift.  The Maruti Techlabs article effectively states, “Agile scaling methods require the entire organization to process, act and react differently in every dimension. Unsuccessful shifts to company culture is one of the primary challenges faced by agile transformation failure.”  

So, the cultural shift is critical for the success of institutionalizing scaled agile.

One of the most important cultural shifts in the organization is that the culture needs to become value-driven and trust based.  The Maruti Techlabs article states it this way, “Value-driven organizations are guided by principles that empower people.  To be agile, trust must be built throughout the organization for anything that gives value to customers and facilitates agility throughout the company.”

Maruti Techlabs goes on to say, “Organizations can shift their flow of work in the scaled agile framework by doing the following things:

• Evolve to a more open style of leadership rather than a command and control approach.
• Balance the budget practices from being project-driven to being determined by the value stream. 
• Alter the team structure to allow active collaboration and rapid experimentation.
• Modify the communication styles from top-down to more horizontal.
• Update the role of the PMO from the force that dictates how work gets done to the connecting fabric that promotes knowledge across the enterprise.”

6.) Technology Shift

An important ingredient for scaled agile per Maruti Techlabs is, “increased visibility, transparency, and information flow across the organization.”  

This means you need to evaluate your technology stack and augment your technology to support scaled agile.

It is important for the technology solutions in the organization to support alignment at a tactical level.  Teams cannot successfully scale agile without the right technology and solutions.  This is true even when the organizational culture and the workflow are properly aligned.

Organizational Benefits of Scaled Agile

There are a great number of benefits organizations realize when implementing scaled agile.  Besides revenue growth and increased profitability, the most common benefits are: 

1. Better Capacity Management
2. Greater alignment of work and the strategy of the business
3. Employee Engagement
4. Enterprise-Wide Visibility

Simple Guide to Scaled Agile Framework

We review six (6) scaled agile frameworks, provide an executive summary for each, and discuss the main foundational points of each.  

The six (6) Scaled Agile Framework approaches covered are:

1. SAFe – Scaled Agile Framework
2. SaS – Scrum@Scale
3. LeSS – Large Scale Scrum
4. NEXUS
5. DA – Disciplined Agile
6. Enterprise Kanban, aka Portfolio Kanban

Before we walk through each approach, it is important to point out that the Scaled Agile Framework (SAFe) is a good method for scaling Scrum in large organizations as it is well documented and more organizations have experimented with this approach to scale their enterprises.

SAFe – Scaled Agile Framework

SAFe is the most widely used scaled agile framework and is well documented.  SAFe provides concrete guidance without forcing the organization to immediately rebuild the organizational structure or product architecture.

Image courtesy of Scaled Agile, Inc

An important tool of SAFe is the quarterly planning event “Program Increment Planning” (PI Planning).  This is a top-down collaborative planning cycle to feed the standard Scrum Sprint cycles.

SAFe is known as a highly reliable method for outlining the performance / delivery and performs well in organizations with hundreds of teams.

Nexus

This is a scaled agile framework for product delivery.

A Nexus group of 3 to 9 scrum teams is defined with a single product owner and a single product backlog.  A Nexus Integration team and Cross-Team Refinement group is assigned to coordinate the work and dependencies between teams.

Image courtesy of scrum.org

The Nexus integration team consists of the product owner, plus a scrum master and members from the development teams.  They deal with integration issues so the organization can deliver an integrated product increment. 

The Cross-Team refinement is an ongoing activity to surface cross-team dependencies and the teams that will need to work on them.

Scrum@Scale (SaS)

Scrum@Scale is a newer framework so there is not as much information or evidence yet for the framework.  The framework was published in 2017 and enables you to scale agile for product delivery.

Image courtesy of ScrumAtScale

Scrum@Scale (SaS) defines two (2) distinct but overlapping cycles:  (1) Scrum Master Cycle for product delivery and (2) Product Owner Cycle for product discovery and definition aligned with company’s strategic vision and goals.

SaS defines two (2) new roles.  They facilitate scaled versions of Scrum events: the Scrum of Scrums Master and the Chief Product Owner.

Scrum at Scale (SaS) is flexible approach.  This is an appealing choice for teams working on a critical product where ample documentation is required for ensuring audibility.

Large Scale Scrum (LeSS)

LeSS is focused on scaling agile for product delivery and is looking to avoid organizational overhead and the need for local optimizations.  

Image courtesy of less.works

Large Scale Scrum foundation is a single team Scrum and implements very few modifications.  LeSS adds an overall retrospective, a preliminary part to the sprint planning, and the per-team sprint review is replaced with an all-teams one.

LeSS is one of the least prescriptive frameworks around.

Disciplined Agile (DA)

Disciplined Agile is more of an assessment based approach to understand how business functions work together and what to address for agile at scale in what is called the Disciplined Agile Enterprise.

Image Courtesy of pmi.org

DA is a lightweight framework that identifies the “what” and the tools need but leaves the “how” up to the organization.  

DA provides guidance at four levels:

• Foundation – provides insight on principles, promises, lean and agile practices, roles and team structures, and what needed to choose your way of working
• Disciplined DevOps – focusses on integrating security and data management
• Value Streams – helps tie strategies together to improve each part of the business in the context of the whole
• Disciplined Agile Enterprise – guides on creating a structure and culture that embraces change, learning, and innovation.

The DA toolkit is extensive yet DA is lightweight as it doesn’t force you in any particular direction.

Enterprise Kanban, aka Portfolio Kanban

Kanban is about optimizing workflow not about how you structure your organization.  The four principles and six practices guide an organization in optimizing workflow, encouraging leadership at every level, focusing on customer needs and expectations, and continual improvement and learning.

Image Courtesy of kanban.university

Kanban can be applied to any workflow or value stream, and at any level in the organization or work process.  Because of this Kanban is extremely scalable.

Final Thoughts

Each of these scaled agile frameworks is designed to provide the insight and foundation to help an organization scale their agile practices.  

If your organization is looking to scale agile to the entire enterprise, then SAFe and Disciplined Agile are the most viable options.

LeSS and Enterprise Kanban are good for organizations that need to run lean or want as little overhead as possible.

If our organization is guided by best practices and you would like to pick the best approaches and tools for each aspect of your organization, Disciplined Agile is a good choice.

Don’t spend too much time trying to pick the perfect option.  Experiment with an approach and if it is not working learn and move on to the next best option for your organization.  So, get started to start the cultural and mindset shift needed to scale agile within your organization.

To read more posts on Project Management and Agile explore these:

• Why Big Projects Fail and How to Increase Big Project Success Rates
• What does a Project Manager Do?

(C) 2022-23 jspublishing.blogspot.com

What does a Project Manager do?

Tales from a Project Manager – Project Manager Role

Are you thinking about becoming a project manager?  

Are you asking, "What does a project manager do"?

In this article, "What does a Project Manager do?" is explored and answered.

So, what does a Project Manager do?

A project manager is responsible for planning, organizing, and orchestrating the completion of projects for a company or organization and making sure projects are completed within budget, on time, and deliver the defined scope.

While the exact duties of a project manager may differ depending on the industry, company, and the types of projects assigned, all project mangers share responsibilities across the “project life cycle”.  

The project life cycle consists of the following five (5) processes (or phases):

• Initiating
• Planning
• Executing
• Monitoring and Controlling
• Closing

While many think of these as steps a project sequences through, in reality they are processes that the project continually iterates through till the end of the project.  The project manager returns to these processes throughout the life of the project.  For example, if hardware is needed before software can be installed, the hardware installation may be executing, while the software installation of the project is still being initiated.  Or if new scope items are added to the project, the project manager needs to take the new scope items through the initiating process while the original scope items of the project are in the executing and monitoring and control process.  Another example is while executing a project, the project team may discover issues or external dependencies requiring the project to go through the planning process again.

Lets take a closer look at each process and the roles and responsibilities of the project manager.

Initiating

It is vitally important during the initiating process (or phase) that the scope, purpose, and main objectives of the project are clearly defined and socialized.  Also, it is extremely important to identify key internal and external stakeholders, perform stake holder analysis, discuss shared expectations, and gain the required authorization to kick off the project with the project team.

Much of the project initiation activities aren’t done by the project manager alone.  And quite often a project manager is not assigned to a project until much of this work is already done or is well under way.

Stake holder analysis is where the project manager assesses stakeholder needs, determines stakeholders that are supportive and those that are likely not supportive, and determines strategies to manage stakeholder needs.

Key questions for the project manager and leaders to answer during the initiating phase are:

1. What information from past projects should be considered to help the project team and ensure project success
2. Is the project budget approved?  If not, how will the project be funded?
3. What does done look like for the project?
4. What is the specific problem trying to be solved?
5. What is the importance of the project?  Is it to save the company money?  Is the project revenue generating?  To deliver a new service or capability, etc?
6. What are the explicit success criteria for the project?  How do you know if the project is a success or not?
7. What are the requirements and constraints of the project?
8. What assumptions are being made?
9. What are the unknowns of the project?
10. What is in scope for the project and what is out of scope for the project?
11. Who are the stakeholders of the project?  Who is impacted?  Or Who impacts the project?
12. Who are the supportive stakeholders for the project?  Who are resistant stakeholders for the project?
13. What are the desired outcomes of the project?  Again save money?  Generate revenue?  Reduce # of man hours?  Increase customer call volume traffic?  Reduce mean time to failure?  Etc.
14. Are there time constraints?  Are there unrealistic expectations? 
15. What are the risks? 
16. Are statements of work with 3rd party vendors needed for the project?
17. What is the experience level of teams impacted by the project?

Once a project manager is assigned the project manager needs to fully engage to make sure they have a clear understanding of the project, the stake holders, and determine strategies to work the project within the organization.  The project initiation phase culminates in the project manager working to get the project chartered and formally approved.

Planning

Once a project is formally chartered and approved, the project manger works with key stakeholders to create an integrated project plan to achieve the project goals.

The project plan should include all aspects of the project including documents that need to be authored, testing, equipment purchases, installs, external project dependencies, and any project constraints.  The project plan allows the project manager to oversee cost, timeline, scope, risk, quality, and communications for the project.

During the planning phase, the project manager needs to outline key deliverables and milestones, and work with the team to identify the tasks that need to be completed to achieve each deliverable and milestone.

Project “planning” doesn’t actually end until the project does.  The project plan needs to be treated as a living document that evolves as the project evolves.

Prior to moving to the “Executing” process it is important to baseline the project plan.

The desired outcome of the planning phase is to have an end to end project plan with assigned resources for each project task and to make sure the plan is socialized and that the project team and key stake holders are aware and have bought into the key milestones and that the milestones and deliverables are achievable.

Executing

The executing process or phase is all about executing to the project tasks and plan that was laid out during the planning process (or phase).  The assigned team members complete the work that is identified in the project plan to accomplish the goals of the project.  During executing the project manager main responsibility is to assign the work and to ensure tasks are completed as scheduled. 

It is important for the project manager during the executing process to be observant and protect the team from distractions, communicate effectively, work and facilitate issue resolution, lead the team through changes in the project, and keep stakeholders informed.

During the executing process or phase it is also critical all operational support items are prepared and are worked.  And all necessary training (formal or informal) is scheduled and delivered to the teams responsible for maintaining the solution going forward or to end user teams.

Monitoring and Controlling

A project manger needs to monitor and control the project throughout the life cycle of the project from planning to closure.

The monitoring and control process (or phase) lasts the entirety of the project from the very beginning of the project throughout planning, execution, and closing. 

For monitoring and controlling the main responsibilities of the project manager are:

• Track actual project plan performance against the planned/scheduled performance – compare variance to plan
• Track and work with the team to ensure key milestones for the project are reached
• Track and monitor the progress of key deliverables and the overall progress of the project
• Manage the project’s budget
• Communicate project status and variances to plan to key stakeholders
• Track and manage project risks and issues

It is important to realize that projects rarely go exactly according to plan, so a project manager needs to be astute, flexible, and adapt as situations and events occur.  

Closing

During the closing process (or phase) a project manager should verify that all key deliverables, objectives, and activities for achieving the final project results are complete.  Also, during project closure verify that all operational support teams for the solution have all necessary reference documents for maintaining the solution going forward.

Some of the key responsibilities of the project manager during closing are:

• Work with key stakeholders and clients to get formal sign-off of project deliverables and sign-off the project is completed and can be closed
• Verify operational owners have been trained
• Perform a lessons learned or after action review with the project team and any key work partners
• For third party vendors or partners, review work delivered, review vendor performance with team and address any significant vendor issues.  Administratively close vendor contracts and make sure invoices are paid.
• Release all resources (budget or staff) no longer needed for the project and thank them.
• Prepare project closure report documenting lessons learned and any punch list items that need to be resolved
• Archive project files for reference on future initiatives

It is important that once the project is closed all deliverables or solutions requiring ongoing operational support need to transition to the appropriate operational support organization.

Final Thoughts

The project manager is the main orchestrater ensuring that a project is well defined, well organized, well staffed, and is well planned.

It is also vital for a project manger to perform stakeholder analysis to determine the appropriate strategies and plans to keep stakeholders informed, aware, and engaged on a project and to appropriately minimize or respond to resistant or outright unsupportive stake holders.

There are many different aspects that project mangers need to address from day to day.  It is important to lead, listen, accommodate, and assist the project team and project stakeholders to deliver a successful project and ultimately a successful solution for the business.

Stay vigilant, hopeful, responsible, and address any team behavior issues so they don’t distract the rest of the team.

(C) 2022-23 jspublishing.blogspot.com

Why Big Projects Fail and How to Increase Big Project Success Rates

Leading Teams and Projects – How to Increase Big Project Success Rates

You should be aware big projects have a high probability of “failure.”  The sheer scale, number of stakeholders, and number of teams impacted by big projects lend to disconnects, missed tasks, missed critical deliverables, and integration failure as the series of project work tracks don't seamlessly come together .      

While the definition of project failure may vary, project failure usually means the project didn’t obtain the pre-defined organizational objective or work wasn’t completed on time.  

In the Harvard Business Review article by Nadim Matta and Ron Ashkenas titled, “Why Good Projects Fail Anyway” Nadim and Ron confirm, “Big Projects fail at an astonishing rate – more than half the time, by some estimates.”  Nadim and Ron are not surprised by the failure rate as the article goes on to state, “Complicated long-term projects are customarily developed by a series of teams working along parallel tracks.  If managers fail to anticipate everything that might fall through the cracks, those tracks will not converge successfully at the end to reach the goal.”

And project “failure” demoralizes a team and produces stress and anxiety in staff.  It impacts the teams confidence and behaviors.  Nadim and Ron state this regarding project failure, “And the toll they take is not just financial. These failures demoralize employees who have labored diligently to complete their share of the work.”

To increase big project success rates, Nadim and Ron suggest a strategic approach to reduce the risk of project unknowns and integration risks.

Nadim and Ron suggest layering in Rapid-Result initiatives and teams to combat “white-space risks” and “integration risks” on large scale multi-year projects.  Nadim and Ron go further, “The key is to inject into the overall plan a series of mini-projects—what we call rapid-results initiatives—each staffed with a team responsible for a version of the hoped-for overall result in miniature and each designed to deliver its result quickly.”

So, in essence rapid proto-typing of the project deliverables at a much smaller scale upfront with core project teams to learn and adapt the project plan to scale up more successfully for the longer-term overall project.

Rapid Result initiatives intentionally are commissioned to produce measurable results.  

So, how do rapid result initiatives work?  

Nadim and Ron explain it as follows, “Using a traditional project management approach, you might have one team research and install software packages, another analyze the different ways that the company interacts with customers (e-mail, telephone, and in person, for example), another develop training programs, and so forth. Many months later, however, when you start to roll out the program, you might discover that the salespeople aren’t sold on the benefits. So even though they may know how to enter the requisite data into the system, they refuse. This very problem has, in fact, derailed many CRM programs at major organizations.

But consider the way the process might unfold if the project included some rapid-results initiatives. A single team might take responsibility for helping a small number of users—say, one sales group in one region—increase their revenues by 25% within four months. Team members would probably draw on all the activities described above, but to succeed at their goal, the microcosm of the overall goal, they would be forced to find out what, if anything, is missing from their plans as they go forward. Along the way, they would, for example, discover the salespeople’s resistance, and they would be compelled to educate the sales staff about the system’s benefits. The team may also discover that it needs to tackle other issues, such as how to divvy up commissions on sales resulting from cross-selling or joint-selling efforts.”

So with Rapid-result initiatives the rapid result teams are implementing a rapid proof of concept at a smaller scale to 1) identify disconnects or “unknown problems” upfront, 2) Get greater buy-in with teams resistant to change, 3) Identify lessons from the smaller scale to apply to the larger initiative.

In my many years as a project manager I can confirm the challenges and Nadim and Ron speak about in the article are very typical challenges that all organizations face with large scale projects and initiatives.  

I agree with Ron and Nadim that by implementing Rapid prototyping and instituting mini projects of Rapid-result initiatives up front an organization will have a far greater probability of success for big project initiatives.

What I have seen is rapid-result teams provide leaders and managers with measurable results that are used to educate and convince other stakeholders who are initially skeptical to get on board with the goals and support the project.  

Many times external teams within the organization who are impacted by the project or view the project goals as unwanted change will either overtly or covertly work against the project and will be hostile to the project objectives.  

Rapid-result initiatives that provide real results and show efficiencies convince unsupportive stakeholders to give the project a chance.  This in turn gains greater collaboration and buy-in from resistant parts of the organization or teams.

Final Thoughts  

Big projects have an alarming rate of failure.  Being strategic and implementing rapid-result initiatives will increase the success rate of big projects.  Rapid prototyping of project deliverables at a smaller scale provides the quick wins to convince others in the organization to get on board and support the initiative.  

Rapid-result initiatives allow the project team to identify lessons from the smaller scale work that can be applied to the big project implementation.

Rapid-result initiatives work in conjunction with other best practices like identifying clear project objectives, having an executive sponsor, and setting realistic expectations.  

(C) 2022-23 jspublishing.blogspot.com