Scaling Agile – How Organizations are really doing it. Or Not…

Updated post based on presentation I delivered at recent 2014 IBM Innovate conference. Here is the link to the actual presentation, click here.

Agile Practices.   What is SAFe?

The Scaled Agile Framework® (pronounced SAFe™) is an interactive knowledge base for implementing agile practices at enterprise scale. SAFe provides organizations with a set of best practices, artifacts and suggested tooling necessary to scale agile from the team to program to the portfolio level. SAFe** aims to address some of the concern that many have had with other Agile methodologies such as Scrum when attempting to scale. Created by Dean Leffingwell, SAFe has been successfully adopted by a number of large organizations internationally, click link to some of their case studies

Over the last 4 or 5 years, I have had a fair bit of experience helping organizations scale agile, see blog post from 2011 on Scaling Agile – Why Scrum isn’t enough,
so have a good feel of how different approaches have worked for me personally. Last year I was invited to attend SAFe training by my company and obtained my certification as a SAFe Program Consultant certification.

Since then I have had several consulting engagements where I have had the opportunity to apply SAFe, along with other approach such as DAD in complex and distributed environments. So far using SAFe concepts has led to more successful engagements as it seems to seems to address a lot of the challenges that enterprise that I have had to work with face.

In my next couple of blog posts, I’d like to give a bit of an overview of the framework while also sharing some of my thoughts and experiences.

Introduction

The “Big Picture”**, shown below, provides a graphical representation the SAFe roles, teams, activities and artifacts necessary to scale agile from the team to the enterprise level.

022214_2335_ScalingAgil1.jpg

Portfolio Level

In the Scaled Agile Framework (SAFe), the Portfolio Level is the highest and most strategic layer where programs are aligned to the company’s business strategy and investment approach.

The PPM (Portfolio and Program Management) team works with the business to gather ideas to drive the Demand Management process. This process produces a set of Investment Themes (or business initiatives) that the enterprise will focus on over the preceding 6 to 18 months.

Here is a short list of some of the key concepts used by SAFe at the portfolio level.

Investment Themes represent the set of business initiatives that drive the enterprise’s investment in systems, products, applications, and services. These are often broken down into a set of business and architectural epics used to plan, execute and track the set of business to ensure the teams aligned with the overall business strategy.

Business and Architectural Epics a large-scale development initiatives used to realize the value of these investment themes. Each Epic captures the business priority, effort estimate (in story points), and expected value and can be further broken down into sub-epics or features as needed.

Kanban Systems is use to assist the PPM team with visualizing the flow of epic-level value along with allowing the organization ot define work-in-progress (WIP) limits to assure an effective flow and to help manage each initiative through to implementation.

Portfolio Vision defines how the enterprise’s business strategy will be achieved and usually requires the creation of a product road map to visually communicate how the different investment themes are being realized via business epics over time.

SAFe is not right for every organization. Some are too small, some are already invested in their own approach and some are not ready for agile at the enterprise level. Whether you follow SAFe or some other approach is not as important as applying lean and agile applying lean and agile thinking to help realize value across the organization. I have been doing this for years in my coaching practice and that is part of what drew us to SAFe. 

The goal for SAFe adoption as this level is to focus on delivering business value quickly. Agile should be about incremental business delivery not team iterations. The cornerstone for this is to have product portfolio management drive programs which drive the delivery of minimal business increments, click here to read more on this topic.

** Scaled Agile Framework and SAFe are trademarks of Leffingwell, LLC

——————————————-

In my upcoming blog posts plan on digging deeper into how organizations are executing their scaled agile transformation with SAFe at the portfolio and program levels. Will also share some of my experience architecting process and tooling solutions to support the various roles required to make these transformations successful

 

Advertisements

Scaling Agile – Why Scrum isn’t enough

Agile Best Practices – Scaling Best Practices for large organizations

While most teams can start using agile practices, such as Scrum and XP, they often run into hurtles when adoption is extended to other parts of the organization.

Most often these challenges (or agile scaling factors) severely limits it adoption.

Recently delivered a session at the Agile Brazil 2012 conference on why most larger teams often must scale Scrum to overcome challenges (such as geographical distribution, organizational change issues) in their environments to success use agile.

Here it the link to the actual presentation.

Presentation Summary

Agile is a highly collaborative approach to software development that focuses on producing high quality “working code” that is potentially shippable at regular intervals. While many aspects of agile are new and innovative, agile practices are derived from many other successful methodologies such as traditional SDLC, iterative development and lean.

Over the last 5 years adopting practices such as Scrum or XP for small collocated projects has become fairly straightforward but we have found that most teams run into problems as their projects move away from an ideal agile team (e.g., 7 +/- 2 people, co-located team, cross-functional skills, self motivated resources all sharing the same vision and drive to deliver potentially shippable code).

Scaling agile to support larger more complex projects and problems often requires strategies that address both the team’s and the organization’s challenges and perceptions with regards to agile practices.

This session focuses on some of the key agile practices that must be scaled to overcome these challenges. The session uses a number case studies illustrating approaches for adopting more disciplined agile practices. In addition we will also cover 2 or 3 specific agile practices that must be scaled.

Succeeding with your First Agile Pilot Project – Lessons from the Trenches

In a follow up to an earlier post regarding, Succeeding with your First Agile Pilot Project, posted on February 19, 2012 by rfeggins, Have coached several additional teams over the last few months and wanted to share some addition lessons that seem common to most teams starting out.

Pilot

While not difficult, agile adoption does take some time to sink in. Often agile teams need 2 or 3 iterations to work though practices related to being self-organizing. Activities such as creating a properly groomed backlog, estimating and report progress all seem to take some time for most teams. Here is a typical timeline that has worked well for me in the past 

Typical Agile Pilot Timeline

 Consider that the teams new to an iterative approach are usually overly-optimistic and the first iteration is usually the hardest. In addition any infrastructure, tool or integration issues must be resolved prior to onboarding the pilot team and starting Sprint 0 activities.

Tips for Selecting a Pilot Project

Pilot selection is usually very critical. Here are 5 key points to consider: 

  1. Duration – Recommended project length at least 8 – 10 wks
  2. Size – Pick a project that can be done by a small cross functional team (between 5 – 9 resources)
  3. Importance – Select a project critical to business (more visibility)
  4. Motivated Business sponsor – an engaged sponsor can help motivates team and/or help remove organizational barriers
  5. Leadership and Experience – How motivated are the potential pilot team members to adopt agile practices 

Key Activities during Sprint 0  

During Sprint 0 planning, take on modest amount of functionality otherwise the team may not be able to complete of the committed stories or a large amount of technical debt may be incurred. Also the perception of the agile projects success may be dimmed or there will be pressure meet the commitment but not at a sustainable pace.

  • Startup Activities
    • Implement core Scrum practices (e.g. daily stand-up meetings, single product backlog, defining “Done Done” for potentially shippable code)
    • Automate processes automated build process , automated testing
  • Capture stores, requirements written in a scenarios format and work with PO to prioritize them
  • Continue grooming the high priority stories and if possible have the team estimate all high priority stories before the initial Sprint Planning meeting
  • Work with embedded testers to build relationships to help pull testing forward based on prioritized stories and user story acceptance criteria.
  • Track test case results to story cards, manage defects from iteration to iteration

Adoption Team

Finally, here are some additional considerations that the team assisting with the  adoption should take into account:

  • Special care must be taken to ensure you have consensus from the project leaders regarding the pilot objectives and the success criteria.
  • Select the appropriate metrics that help guide the team’s adoption
  • Beware of too much oversight by management. Remember the old saying “A watched pot never boils”

What is an agile methodology anyways?

Agile methodologies is a collection of lightweight software development approaches (some would call them “best practices”) that evolved in the mid-1990s and early 2000s in reaction to heavy weight waterfall processes common in most organizations.

Common agile methodologies include Scrum, Extreme Programming, Adaptive Software Development, and Feature Driven Development.

Scrum, one of the most commonly adopted agile method, focuses on quickly delivering value to the customer by breaking up tasks into small units, called “Stories”, which developed in short time boxed iterations lasting from one to four weeks.

Teams are typically between 5-9 people with cross functional skills. Small teams help simplify collaboration and team communication. In some cases multiple small teams are formed when projects require a larger number of development resource to meet the customer goals.

Each iteration involves a team working through a full software development cycle, including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.

Using this approach, teams are able to reduce project risk by providing teams with frequent points for customer input along with focused planning sessions that helps the project to adapt to changes quickly. Stakeholders produce documentation as required.

These and other agile methods promote collaborative planning, teamwork and lightweight development and testing practices. All support one or more of the twelve principles, first articulated in the Agile Manifesto.

    • Customer satisfaction by rapid delivery of useful software
    • Sustainable development, able to maintain a constant pace
    • Close, daily co-operation between business people and developers
    • Face-to-face conversation is the best form of communication (co-location)
    • Projects are built around motivated individuals, who should be trusted
    • Continuous attention to technical excellence and good design
    • Simplicity- The art of maximizing the amount of work not done – is essential
    • Self-organizing teams
    • Regular adaptation to changing circumstances

Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.  Finally, all agile practices use “working software” as the primary measure of progress and value  face-to-face communication over detailed written documentation. And focus on working with the customer (sometimes called the “Product Owner”) to prioritize “needs” based on business value that can be achieved at the start of the iteration

References
Agile Manifesto, http://agilemanifesto.org/ Ambler, S.W. “Examining the Agile Manifesto”. Retrieved 12 December 2011.http://www.ambysoft.com/essays/agileManifesto.html
Beck, Kent; et al. (2001). “Principles behind the Agile Manifesto”. Agile Alliance. Archived from the original on 14 June 2010. Retrieved 6 June 2010.

Succeeding with your First Agile Pilot Project

Successful agile transformations often times require successful agile pilot projects. Often time a successful initial pilot is the most critical step early in a successful enterprise agile adoption. If the pilot project is a success then the organization has a tangible example to get behind but if the project fails (or just fails to meet expectations) then the entire agile initiative could be derailed by critics. Because no one really likes change unless they are driving it.

Here is a presentation a I delivered a few years ago on running a successful agile pilot Succeeding with your First Agile Pilot Project

The presentions covers

  • Picking the Right Agile Pilot
  • Choosing the best set of Agile Practices to adopt
  • Providing the necessary education, tooling and governance
  • Learn and Adapt from the pilot

Picking an Agile Coach – Lessons from the Trenches

Picking an Agile Coach is often a trying task for most organizations. What is an Agile Coach and what qualities make a good one. These are just some of the common questions most organizations have.

As it takes time to really adopt new practices and behaviors, the Agile Coach must be more than just a recently trained ScrumMaster that usually “swoops in” to deliver words of wisdom and then makes a sharp exit. The coach must be able to spend time with the team to help them to become more aware of their workflow and how to collaborate effectively.

In a nutshell, an “Agile Coach” must help the project leaders, and the teams learn how to successfully apply the required agile practices.  The coach must be familiar with how each agile role (e.g.,  Team, Product Owners, and ScrumMaster) are impacted by an Agile Transformation as well as the roles outside the team that are impacted, especially the Project Managers and senior management (e.g., managing triple constraints or how will weekly / monthly progress be collected and shared)

Being an Agile Coach is different than a ScrumMaster leading a project team as it’s more of a transitory role not tied into project duration. However, your success / failures are directly impacted by how the team performs and grows. So while our goal as an Agile Coach is for the whole team to become self-coaching and adept in applying agile.

In many cases, organizations already have some skilled resources with some real-world experience: ScrumMaster who’s led small / medium projects and/or software developers who have worked on agile projects in the past. These organizations need coaches with experience with rolling out and applying agile practices to boost their performance and proficiency in software development as well as to accelerate their adoption of certain practices.

Common interview questions:

  • Years of experience with Agile, Scrum, XP, etc
  • Describe some of your key experiences leading agile transformations
  • Can you share some of the common challenges you ran into as an Agile Coach and how you over came these challenges?
  • How is being an agile coach different from a team lead or project manager job role?
  • Describe what you believe are some of the core practices for a team to adopt to be called agile (. Explore their understanding of Whole Team, Agile Planning to make sure they know more than just Scrum, assuming the team must scale.
  • What are some of the different roles impacted by an Agile Transformation beyond the (PO, ScrumMaster, Team) roles?
  • What techniques have you used in the past to report progress, document team performance, make adoption recommendations,  etc.?
  • Are you familiar with using tools like Rational Team Concert (RTC) to assist with agile planning, dash boarding and Adoption Activities?
  • What measures do you typically collect to determine if the agile transformation is on track?

Understanding core skills

The core skills for coaching agile teams are solid communication skills, such as listening, asking questions and giving feedback.

To engage the whole team, an Agile Coach must be able to provide one-to-one mentoring to the core roles, be effective at running meetings with good facilitation skills along with the ability to intervene when needed.

For example in his book entitled “Leading Teams”, Richard Hackman asserts that three basic types of coaching intervention: Motivational, Consultative, and Educational where he defines a coaching intervention as “any action that seeks to minimize process losses or to foster process gains.”  He further elaborates on these coaching intervention categories in that:

  • Motivational interventions improve the team’s effort by building shared commitment and minimizing free-riding
  • Educational interventions improve understanding and skills on the team
  • Consultative intervention foster process improvement by helping the team become more aware of their (mindless) habits

Further reading

Retrospectives What are they and how do they help teams adopt Agile practices?

Retrospectives – “What purpose do they server?”

Many small to medium size projects teams have successfully adopted agile practices such as Scrum but some agile teams do fail.  Often as not they fail because of factors outside their control but here are some common reasons why agile project teams fail that are within their control:

  • Not implementing the whole process
  • Scaling Factors not addressed
  • Team not co-located or team governed like a Waterfall project)
  • Team too big or team has strong functional role boundaries
  • Team / Management not committed to Agile principles
  • Roles not followed (Organization compromise on the Product Owner / Scrum Master responsibilities)

When we look at the Principles behind the Agile Manifesto we find that the first principle is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable

So a failure in the context of an agile project could be stated as an “unsatisfied customer due to late or sporadic delivery of valueless software”.

But Agile provides teams with the opportunity inspects and adapt the process to make changes that help overcome these changes. In Agile a Retrospective is used to help teams improve their processes and practices. Similar to a postmortem performed atthe end of a traditional project, retrospectives allow teams to quickly identify things

  • They are doing well;
  • They should improve; and
  • Outside their control but are risks to the overall project

Here are some some practical tips and tricks for conducting an effective Retrospective along with some best practices for using Rational Team Concert to collect, manage and communicate the impact of the teams improvement activities.

Retrospective help teams improve and holding them at the end of each iteration has several advantages

  • Standing meeting focused on improving team performance (every 2 to 4 weeks) at the end of each iteration or sprint
  • Team prioritizes improvements and takes ownership over making changes
  • Team knows where they stand. Retrospectives occur right after Sprint Demo so they have the feedback from the Prod Owner
  • Quick-wins can easily be implemented rapidly where with traditional post-mortems happened at the end of the project with limited ability to make real changes.

Common issues that come up during team retrospectives include:

  • Story estimates are not acturate
  • Some members of the team are being pulled into other projects limiting their time
  • Team missed Sprint due to resource issues
    • Team had several tasks (e.g., DBA tasks) that only one person on the team can perform.
    • During the sprint that resource worked very long hours to complete his tasks and became frustrated that other team members could not do more to help with those tasks.
  • In another case say a team has was spending too much time dealing with failed builds. That team decided to implement continuous integration but the team does not want to risk disrupting their regular build process.