The following is the first in a series of blogs aimed at providing a concise comparison of the most salient features of the leading Agile scaling frameworks. Hopefully, this information will help you choose the framework that is most suitable for your organization to meet their business needs.

For large software development projects involving up to a 100 to several 100’s of software developers, analysts and testers, the inherent techniques of agile methodologies such as Scrum or XP prove inadequate for effectively managing the progress of such enormous effort.

In this blog, we look at a quick comparison between two leading frameworks for scaling the Agile approach for large software development projects: Scaled Agile Framework (SAFe 4.5) and Large-Scale Scrum (LeSS).   Each has its strong points that may fit different organizational situations of large software product development.

Let’s get started: the “Big Picture”

See below the overview pictures for each of SAFe (www.scaledagileframework.com) and LeSS (less.works).

Right off the bat, you can see that while the SAFe Framework appears more comprehensive, it also appears more process-heavy.  In fact, the inventors of the LeSS framework are proud of its acronym indicating less process, less artifacts, and fewer roles, remaining faithful to having mainly the original Scrum roles of PO, SM and Team.

For example, SAFe offers the role of Product Manager, who is in charge of setting the priorities and overall scope of functionality to be delivered by a Program containing many Agile teams.  The Product Owner in SAFe performs the usual Scrum role for up to a couple of Agile Teams that typically work from a similar/shared backlog.

In contrast, LeSS offers the regular Scrum role of Product Owner (PO) for up to 8 Teams.  This is because in LeSS, the PO is not a liaison with the end-Customer: the Teams get to interact directly with the end-Customer to understand the details of the requirements, giving the PO the opportunity to focus on the overall priorities and scope for up to 8 Scrum Teams.

Hence if an organization can afford the opportunity for the Agile Teams to interact directly with the end-Customer LeSS can be a good fit in this particular aspect. Otherwise, SAFe can accommodate both the Team-direct and the liaison-PO situations.

SAFe 4.5 Framework

Organizational Structure

The Inventors of LeSS very much believe that culture follows structure.  To that end they offer LeSS not just as a practice to scale up the Scrum approach, but as a direct impetus for change of organizational structure.  The picture below shows what LeSS advocates for organizational structure for up to 8 Scrum Teams working together to develop a software product in order to provide what an Agile culture needs from an organization to succeed.

In this picture, you can see that there are no functional departments (e.g. development vs. testing) or a PMO.  Instead, in addition to the Scrum Teams, there is the Head of the Product Group, which LeSS views (as it views all other managers similar to the “Toyota Way”) as a teacher of those reporting to him/her, there is the Product Owner team that provides a pool of PO’s for every Scrum team (large or small scale) effort, and then there is the Undone Department.

The latter is a curious thing.  In LeSS, a permeating theme is that the Teams are supposed to do everything needed to put a high-quality software product in the hands of end-Customers: from analysis to development to testing to packaging, all while coordinating with other Teams.  All of that is represented in the Definition of Done of the Teams.  But it may take the Teams a few years to mature to that set of comprehensive capabilities.  Hence the Undone Department is a placeholder for resources that fill in for whatever the Teams are yet to be able to do (e.g. DevOps) until the Teams mature.

In contrast, SAFe does not advocate drastic organizational change as emphatically as LeSS.  It presents its approach for adoption even with the current organizational structure, and lets the organization take its time deciding when it may want to restructure to be more efficient with Agile.  That’s not to say that LeSS presents its approach as an “all or nothing deal” – it just emphasizes structural change in the organization more strongly than SAFe does.

Differences in Planning

SAFe stipulates that sprints should be grouped in sets of 4-5 consecutive sprints, each set being called a Program Increment (PI).  And while the Teams (and the Product as a whole) are expected to demonstrate incremental achievements at the end of each sprint (i.e. completed Stories), it is at the end of a PI that complete “Features” of the software product are expected to be available.  SAFe, however, maintains the option of releasing on-demand any time during a PI with the Features, or even Stories, that happen to be complete at that point in time.

Planning in SAFe happens in a 2-day session at the beginning of each PI, in addition to the usual sprint planning at the beginning of each sprint.  In the PI planning session all the Teams working together in what SAFe calls an Agile Release Train

(ART) attend to commit to delivering a set of Features for the PI, and to have each Team present a plan showing which stories (which are children of Features in SAFe) the Team plans to complete for each sprint in the PI.  Finally, in addition to the usual sprint demos and retrospective, SAFe has an overall Inspect and Adapt Workshop (analogous to the Sprint Demo and Retrospective) at the end of the PI which includes a PI demo, Quantitative Measurement, and a Problem Solving Workshop that dives into deeper root cause analysis than a normal Sprint Retrospective.

In contrast, LeSS remains faithful to just the usual sprints of Scrum, with the following additions:

  • Sprint Planning happens in 2 stages. The1st stage is attended by 2 representatives of each Team, which do not usually include the Team’s Scrum Master.  This stage decides which items from the common Product Backlog each Team will develop.  It also has cross-team estimations to unify the estimation numbers.  This is in contrast to SAFe, which suggests normalizing cross-Team estimations by equating a story point to a story that would take ½ day to code and ½ day to test.The second stage of sprint planning is the same as sprint planning in regular Scrum.
  • Each sprint review is held with all Teams as a “science fair”, where each Team has a station to demonstrate its accomplishments for the sprint. Attending stakeholders can visit the stations in which they are interested.
  • The Sprint Retrospective is held in two stages: the first being the same as regular Scrum; the second is for the overall progress of the software product being developed by the Teams.

Portfolio Management

As represented in the top level of the SAFe “Big Picture” shown earlier, SAFe offers a comprehensive approach of prioritizing “projects” (represented as Epics or a set of related Epics in SAFe) and budgeting for them in an Agile manner.  In its latest version, SAFe 4.5, there is an additional, optional, level for Large Solutions (shown below the Portfolio level in the aforementioned diagram) – it is usually relevant to projects with hundreds, or thousands of participants comprising multiple Agile Release Trains.

In contrast, LeSS does not delve into Portfolio Management: it only offers techniques that can be compared to the Program and Team levels of SAFe.

2 Versions of LeSS

LeSS has two versions:  the one we saw earlier for 2 to 8 Teams, and Less Huge for more than 8 Teams, depicted below.

LeSS Huge is formed by having several regular LeSS frameworks working in parallel with each other.  The most notable addition in LeSS Huge is making each regular LeSS belong to a separate Requirements Area with its own Area Product Owner (APO) under the overall Product Owner.

If you were thinking “Well, isn’t an ART the same as a Requirements Area?” you’d be partially right; a similarity is that the Product Backlog relationship to the Area Product Backlog is analogous to the relationship of a Portfolio Backlog to a Program Backlog in the sense that items on the former are coarser grained than items on the latter.  However, one of the differences is that an APO is still only one for 8 Teams, whereas the SAFe PO covers very fewer Teams.

Other Differences between LeSS and SAFe

LeSS can appear to offer one seemingly shocking advice (which is not offered by SAFe):  Don’t scale! (But if you have to scale, use LeSS J). It advocates that even very large software products can be built more successfully by a relatively small Team of co-located master programmers and testers.  They cite at least one example on their website (less.works) of a huge software project that followed a torturous path to completion.  When the overall project director was asked if he were to do it again, what would he do differently, he said that he’d pick the 10 best programmers and have them build it all.  I can cite a more recent example with the Affordable Care Act, where a traditional government contractor put an enormous number of resources on the project that failed miserably.  Later, about a dozen master developers and testers were put together in a house to work on fixing the ACA, which they did within a period of several months. (See http://www.theatlantic.com/technology/archive/2015/07/the-secret-startup-saved-healthcare-gov-the-worst-website-in-america/397784/)

  • Whereas SAFe is generally tool-neutral from a specific vendor perspective, SAFe does encourage early and often automation as much as possible, utilizing the system team to support that.
    LeSS, on the other hand, strongly recommends that you not use automated tools until after your organization becomes quite proficient with LeSS, opting instead to use manual resources like very big white boards and wall charts. Otherwise, LeSS declares that if you automate a mess, you get an automated mess.  And even after the Teams become proficient with LeSS, it recommends that you only use open source tools, which you can easily jettison if they don’t work out for you, without losing high-dollar investments in them.
  • SAFe takes a more customary view of the role of Scrum Master. In SAFe, the SM is pretty much a permanent role with the Scrum Team and does a lot of intra-Team and inter-Team coordination.  In LeSS, the SM is first and foremost a Teacher.  He can fade away from the day-to-day Team dynamics once the Team becomes proficient in the Scrum and LeSS approaches.
  • In SAFe: Epics, Capabilities, Features and Stories are explicitly handled as integral parts of the SAFe backlogs. LeSS, on the other hand, only talks about coarser vs. finer grained Backlog Items, staying faithful to Scrum by relegating Epics, Features and Stories as instruments of XP, which is not part of Scrum proper.

Conclusion

The quick comparison between LeSS and SAFe in this blog is by no means comprehensive.  Yet it shows SAFe to be more wide-ranging in offering processes and roles to handle the development of software from the highest profile levels down to the individual Agile Team for large-scale Agile efforts, while making those roles and levels configurable according the organization’s needs.  Furthermore, for a typical traditional large organization it is perhaps more palatable to begin to adopt SAFe than LeSS, since the latter strongly advocates some major changes to the structure of the organization as early as possible in the adoption of LeSS.


Scaled Agile Framework (SAFeTM) change agents often face similar challenges when trying to implement SAFeTM within an organization. Change agent is a person from inside or outside an organization, which is driving a transformation for an organization. Change agents also have useful and creative tools and techniques in their toolkit to try to drive this change within the organization. However, many times transformations fall short.

Why does this happen?

As SAFe change agents, we need to reorganize and repurpose our toolkits to ensure that our tools and techniques for implementing SAFe clearly adhere to the SAFe principles and core values.

Scaled Agile transformations are really hard.

They are massively complex, have significant unknowns, and leaders typically expect results now!  On top of that, with SAFe transformation comes the need for a dramatic culture shift within the organization.  As a result of this complexity, there are several approaches to implementing SAFe within an organization. But ultimately, the value takes too long to achieve, the uncertainty around culture changes become unmanageable and the transformation loses momentum.

Does this sound familiar? The particular issues that arise when implementing SAFe are some of the same challenges that drive organizations to want to adopt SAFe in the first place: the value of a product takes too long to get to the end consumer, requirements and consumer needs change at an unmanageable pace and the teams lose motivation.

So, if they have similar challenges, can’t they be solved by the same solution? Assuming yes, why not solve transformation challenges by leading the transformation with SAFe principles and values?

There are five concepts from the SAFe principles and values that are critical to ensuring a successful SAFe transformation.  By using these concepts, an organization can set its vision for the change, consistently inspecting and adapting yet getting quick value added wins, and is able to set a foundation for continuous improvement.

Build a Cross Functional Transformation Team

Building a coalition for change is critical to any transformation.  When working to put together a transformation team to lead this change, consider what makes up a quality scrum team.  Cross-functional teams are the best type of scrum teams as members can make decisions and work through dependencies within the team.  So, a scrum team should have developers, testers, user experience experts, hardware, software, etc., so the team can build business value systems within the team.

With a team leading a transformation, the approach needs to be similar: i.e. assemble teams made up of members from all impacted areas of the change – business owners, program / project managers, software developers, infrastructure, human resource and a representative from every area that may be impacted.  The key is to have a team with a wide enough perspective to help drive the change and deliver consistent messaging and processes across all areas. This will help to manage the variability in the messaging of the change.

Also, training is critical to ensure the team marches to the same beat. Every member of this transformation team must become a SAFe educated change agent in the organization to help drive the culture change across all layers/areas of the organization.  While speed of change is important, we must spend a substantial amount of time on training to build a solid foundation for the transformation.  If solid training of the core values and principles of SAFe is not implemented early, when the transformation team starts to drive change, they will fall flat in the organization. This is when you observe organizations doing the motions of agile rather than living the behaviors of strong agile values.  Remember to spend time on training, leading agile thinkers and change leaders, to build that solid foundation upon which to move the transformation forward.

Visualize a Transformation Roadmap and Vision

Humans do not do things just for the sake of doing. We all have intrinsic motivation that drives us to change. In a transformation we demand a lot of our organization and team members.  The transformation team must build up such intrinsic motivation for team members to change.  Within SAFe, we achieve this goal by aligning the scrum team’s backlogs to strategic themes, vision and roadmaps.  Theme, visions and roadmap should also set the context around why the organization needs to change, what are the opportunities and proposed solutions that are going to make the organization better. This gives the teams a context for the work and shows them how the work they are doing provides value back to the organization.

In a similar way, we must provide the context as to why we are taking part in specific agile ceremonies or changes in culture.  People may see these changes as a waste of time or an attack on them personally, which often results in a negative reaction.  People need to understand where they fit and even if they are apart of the to be motivated to fight with and not against the change. But if the context around the ceremony or process is presented, we can build up that intrinsic motivation and encourage a deeper engagement. Without this context, team members will just go through the motions without getting the true value. The key is unlocking that intrinsic motivation: it will enable the value to emerge behind those changes and build positive reactions toward the changes.

Daily Scrum Example:
  • Without intrinsic motivation behind change: If a team member is simply asked to go to the daily scrum, they will show up, give quick answers and move on with their day.
  • With intrinsic motivation behind change: The team member comes empower to social decisions made within team and address any blockers that need resolution.

The following are four steps that can help visualize the vision and roadmap to unlock the intrinsic motivation of team members:

  1. Establish a Vision – After initial training of the transformation team, set some time to establish a vision and context for change. Establish the leading drivers for the change, e.g. faster time to market, high quality, etc.
  2. Build a backlog of opportunities – The backlog should contain a specific set of tangible challenges within the current state of delivery in the organization. This helps make the changes real and relatable.  The benefits behind the changes become tangible.
  3. Refine the backlog – The refinement process within the SAFe framework helps to reduce complexity and ambiguity around the work at hand. Refining the backlog of opportunities will reap the same benefits for the transformation, as it will help align opportunities around the value to the organization.
  4. Establish a roadmap – The backlog may seem intangible due to its size or complexity. Understand that a transformation does not happen overnight or over a period of weeks. Establish a six to twelve month rolling roadmap to help manage the amount of change as well as work in progress.

Take a Systems View When Planning

When taking a systems view in the Scaled Agile Framework we arrange backlogs to enable system development of business value over technical component development. A system can be an end-to-end solution, a set of people and a process to build an enterprise or a value stream to an end consumer. A system is only as good as it weakest link so a weak component within the system will tend to drive down the value of the stronger components and therefor hinder the value to the end consumer. The value behind a system is the cross functional slivers of value to the customer. Think of the 7-layer cake analogy, one bad layer and the whole cake is ruined, but if the layers are blended together it is culinary bliss.  Without taking a systems approach to planning of the work, the value will always be bottlenecked by the weakest component to the end user.

The same thought process must be taken when looking at a transformation with the Scaled Agile Framework.  SAFe is a system in itself and, like any system, if it has weak links, it will fail to provide its maximum intended value.  When looking at the backlog of items for a transformation, it is critical to align opportunities around value to the organization.  This ensures that as the framework is being integrated in the organization, it is built to maximize value in the system rather than create a weak link in the system.  Below is an example of a value added SAFe System and a weak link SAFe System.

Value Added SAFe System: Implementing Kanban refinement processes at the Portfolio, Program and Team level which all align to the strategic themes of the enterprise.

Weak Link SAFe System: Performing a full PI Planning event without conducting an Inspect and Adapt workshop to learn from opportunities that arose.

This approach becomes critical to establish early wins in your transformation.  When the transformation takes a systems approach, it provides value directly back to the organization, and any external stakeholder or agile naysayer in the organization will begin to see the light and positives of this approach.  When we fail to take this approach, the door is left open for agile naysayers to latch on to the fact that the value is not achieved due to the weak links in the system. Implementing SAFe with systems thinking in mind will aid in getting support and changing those naysayers into change agents.

Take an Economic View of Prioritization

Taking an economic view when implementing in Scaled Agile framework, demands that we ensure maximum business value is delivered in the shortest about of time. Therefore time to market is essential and prioritizing backlog items based on those criteria is critical.

With SAFe transformations, the factor of time is the amount of cultural change that has to take place to implement the change.  Transformations often experience severe delays or halt completely because of an organization’s inability to change the culture in a timely manner.  Similar to SAFe, when looking at the transformation backlog, time should be factored in as the amount of cultural change a specific item should take over another.  Implementing a change with minimal cultural change may become a quick agile win over trying to implement something that requires a significant amount of cultural change to overcome.  This becomes critical to the SAFe Transformation providing business value.

An economic view translates into a review of the backlog for items, which would provide the most value and most significant progress in the shortest amount of time.  Within the SAFe model, using the formula for Weighted Shorted Job First (WSJF) does this.  This formula helps to identify the return on investment upon doing one piece of work over another with the primary focus around Cost of Delay (COD).  It compares the COD relative to job size for a subset of the backlog.  This formula should be used for the transformation backlog with some modifications.  For transformations, the WSJF should be calculated as Value to Organization, Time Criticality, and Risk Reduction/Opportunity Enablement relative to the Degree of Cultural Change.

 

 

Since the largest blocker to any transformation is cultural change, it is critical to evaluate this factor when prioritizing. Let’s take two examples to show this,

  1. As a part of a transformation there may be significant value in establishing the Product Owner role with someone from the Business. This would ensure work is aligned to business value.  But in this company the business is an entirely different organization than IT, thus forcing them to establish a Product Owner role would be a giant culture change.  Using the transformation WSJF this would score fairly low due to the high impact of the degree of cultural change.
  2. On the other hand, establishing daily scrums and the scrum of scrum practices within an organization, which already has scrum master in place, would be a high transformation WSJF. This change has value to the organization, high-risk reduction and a low degree of cultural change.

Transform on a Cadence

The complexity behind software development is due to the unknown and variability in development. Technologies change, dependencies evolve and requirements change quicker than ever.  With a SAFe Transformation, similar unknowns and variability will occur around the amount a change an organization is willing to take on at once.  People have a tolerance limit to change and in general many people are change adverse.  In any given situation within an organization the amount of change an organization can vary based upon that organization and a given situation.  Several factors out of the control of the transformation team will limit the amount of change an organization is willing to handle.  As a result, a transformation should be conducted on a program increment and iteration cadence.  This would include having PI Planning, Iteration Planning, Stand Ups and Inspect and Adapt workshops as a minimal viable product.  The purpose of this is control and managing work in process, inspect and adapt on complete transformation work, and line up future work, based on value.  A description of how each of the ceremonies should be run to gain this purpose is shown below.

Transformation PI Planning – All members of the transformation team and key sponsors attend.  A half day meeting where the vision and roadmap is updated. The outcomes should be a determination of any major milestones, an updated vision and roadmap, commitment of backlog items and resolution of any critical barriers. The team should establish measurements of success of the program increment and commit to their work around those measurements.

Transformation Sprint Planning – Conducted every two weeks with the entire transformation team.  Each meeting should last no more than one hour.  Outcomes of the meeting include resolving any upcoming issues, monitoring change tolerance, and committing work for the next 2 weeks.

Transformation Stand-Up – Occurs 2 to 3 times a week and follows typical standup ceremonies across the transformation team.

Inspect and Adapt – Conducted every two weeks focusing on the progress made, lessons learned, updating of future backlog items.

Transforming on a cadence allows for constant commitment to change as well as constant feedback.  It also creates a sense of urgency around the change, which the transformation team, and rest of the organization, can feel and build on throughout the transformation.

Empowering Changing Agents

At the begin of this journey, I discussed the need for SAFe change agents to reorganize and repurpose their toolkits to transformations with more SAFe values and principles. I have outlined some of my modifications to my toolkit to be better aligned to SAFe principles and values.   My hope is that you, as SAFe change agents and leading agile thinkers and organizational leaders, are now empowered to reflect on how you are transforming your organization and ask are we following SAFe principles and values during your transformation.

  • Do you have a properly trained transformation team to lead this change?
  • Is your Transformation roadmap and vision clear and understood?
  • Are you taking a systems view to planning your transformation?
  • Does prioritization of your transformation backlog occur with an economic view?
  • Are you driving your transformation in a scrum like fashion?

If no to any of these, take time to reflect and take action to allow your transformation to be better aligned to SAFe principles and values.

If yes to all these, than I challenge you to keep true to the SAFe principles and values and look for continuous improvement.

_________________________________________________________

Dan Teixeira is currently an Agile Change Agent for Blue Agility, helping lead organizations from team level to portfolio transformation to optimize delivery of business value. Dan brings his expertise in Agile/Lean best practices and industry experiences to help teams deliver the right results, faster and with higher quality. Dan is passionate about shepherding organizational change management across all levels of the enterprise by empowering people with new and innovative ways to view problems and solve challenges. He strives to bring meaningful new approaches into organizations to ultimately improve the lives of people.

 


Real World Coaching and Mentoring Expertise Combined with a Leading Knowledge Management Platform Bolster Client Success

Philadelphia, PA – August 17, 2016: Blue Agility, an industry leader in large-scale agile transformations and application lifecycle management (ALM) technology, and PEDCO, creators of Applied SAFe®, a fully-fledged ALM tool agnostic implementation of the Scaled Agile Framework® (SAFe®) as a process model, today announced a strategic partnership to help organizations accelerate and streamline the implementation of the Scaled Agile Framework (SAFeTM). The two industry-leading companies are teaming up to support the growing number of PEDCO’s Applied SAFe clients seeking to maximize the benefits of their large scale agile adoption. The synergy between Blue Agility’s expertise and proven track record with large and complex agile adoptions and PEDCO’s innovative product will enable their clients to customize the framework and tailor it to their industry and specific business context.

For large organizations in an increasingly competitive marketplace, moving from traditional waterfall software development processes to lean, agile and synchronized efforts bring the promise of improved quality, shortened time to value and increased client satisfaction. However, scaling those efforts from small teams to an enterprise level introduces myriad of challenges. It is at this point where clients need the support of an experienced coach backed by a leading process management platform. Together, Blue Agility and PEDCO provide the experience and technology to ensure a smooth and successful transition effort and significant return on investment.

“I’m excited about our strategic partnership with Blue Agility. Their experience with providing expert coaching and training services for large scale SAFe implementations significantly enhances PEDCO’s ability to ensure a seamless transition to agile, lean and compliant processes for the growing number of Applied SAFe clients,” said Peter Pedross, CEO at PEDCO.

“We truly understand the challenges faced by our clients when implementing SAFe, particularly for those operating in regulated industries. By working in partnership, PEDCO and Blue Agility are uniquely positioned to provide customized and comprehensive enterprise-ready solutions for organizations wanting to adapt SAFe to their context,” said Eyal Abukasis, Chief Operations Officer at Blue Agility. “With PEDCO’s Applied SAFe, the potential to smooth the path to a full SAFe adoption that ultimately translates to high business value and customer delight is substantial.”

About PEDCO
PEDCO – Managed Process Services is a public limited company based in Zurich, Switzerland and a collaboration partner with Scaled Agile Inc., Boulder (USA) and Method Park, Erlangen (Germany). PEDCO supports enterprises around the globe for process implementations for complex product lines or within regulatory environments. We offer a comprehensive range of solutions to set-up, select, operate, and develop lean, compliant and efficient processes.

Applied SAFe® is a stand-alone product from PEDCO. It is a fully fledged ALM tool agnostic implementation of the Scaled Agile Framework (SAFe®) as a process model and kept in sync with the actual SAFe® version by Scaled Agile Inc. (SAI). It serves as your own comprehensive, customizable and tailored instance of SAFe®. Together with our Applied SAFe Consulting Partners, we ensure a smooth transition to agile, lean, efficient and compliant processes. www.AppliedSAFe.com.

About Blue Agility
Blue Agility specializes in large-scale Agile transformations leveraging the Scaled Agile Framework® (SAFe™) and Application Lifecycle Management (ALM) tools. Blue Agility provides a framework of people, process and technology, enabling the enterprise with continuous delivery capabilities. Leveraging our bluejazz™ knowledge platform (2015 Beacon Award), organizations access customized role-based tool usage models, ensuring scalable and sustainable enterprise-wide transformations with end-to-end traceability. www.blue-agility.com


Whom Do you Seek?

A major key to success of a sustainable agile transformation is finding the right person or persons to lead the transformation. This person(s) need great prior experience at the Enterprise level coaching and mentoring as a ‘Sherpa guide” through the difficulties of an Enterprise wide agile transformation. This is an “OZish” view of the behind the scenes of how an agile adoption can proceed, leadership and its role and the case for the “determined person”.

Follow the Yellow Brick Road…

I often ask people who their favorite character is in the movie “The Wizard of OZ”. Usually it is Dorothy or the Scarecrow. Those that answer Toto. I worry about. My answer is “I like the Man Behind the Curtain”. Here is the actual wizard working the flash and bang of the big show from a small side stage and he does not mean to be seen or heard (other than through his avatar).

Man behind curtain

Good mentors are like that. Good Enterprise Transformation Coaches are very much like that. They project leadership and strong qualities, and work the invisible pedals and levers of the Transformation within your organization. A great coach or mentor is always taking a back seat to the Employee who leads the Transformation. Even though they may be for this one topic of Transformations “the smartest person in the room” they don’t act it. They work at drawing out people, providing behind the scenes coaching, salting the conversation with ideas that others can latch onto as their own.

If required, they have the strength of character and leadership capabilities to take charge, but as a least acceptable solution. The Enterprise Coach should get their sponsor and lead to step up to the role of leading the Transformation.

What Comprises a Set of Skills?

Defining the Enterprise Agile Transformation Coach role is a mix of:

  • Communicator (up and down the whole chain of command)
  • Agile experience and practices
  • Enterprise Transformation experience
  • Technology savvy across multiple knowledge domains
  • Business experience and savvy to connect with non-IT types
  • Exposure and experience across the IT organization

Basically, someone who has been there done that, built and burned down the T-Shirt factory a few times. So they must have had experience with Enterprise Transformations before. There is no replacement for experience in this realm.

Most important they have a force of will to drive to get things done. Many years ago I read a paper on the concept of “The Determined Person”. The basis of the story was that The Determined person is someone who, despite what seem to be overwhelming odds manages to persist through the effort to its conclusion. Someone of strong conviction and faith that we can solve problems and overcome inertia of culture. This strength of will is coupled with persistence. This persistence of vision from Calvin Coolidge is my favorite quote of all times.

“Nothing in this world can take the place of persistence. Talent will not: nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not: the world is full of educated derelicts. Persistence and determination alone are omnipotent.”

Do I Hire Someone Who is Certified?

Certifications are not a replacement for experience. I’ll take the seasoned veteran of the fight any time over someone with 5 certs on their resume. An interesting question to ask in an interview to sort out who is experienced is “So tell me about a major transformation failure and how did you get out of it?” An experienced coach will have interesting (and sometimes scary) stories for that one. (FYI, the more interesting part of the answer is how they got out of it).

TrekkersSomeone with little or no experience or who is too cautious to answer is likely not the kind of Mentor you are looking for. You want someone with wisdom, and unlike the catch phrase, “with age comes wisdom” it really should read with EXPERIENCE and failure comes wisdom.  Once you’ve had your metaphorical legs blown off by stepping on the various landmines strewn on the path to Transformation, you learn what a landmine is and how to avoid it. I want to follow that person.

These Coaches Are Really Expensive…

So I got one of these people lined up, now I can’t afford them. Yes, experience comes at a cost. The kinds of consulting we are discussing is expensive. Cheaping out just means you get what you pay for. Besides, transformations are cheaper with a good guide. Experienced coaches save you money by offering up, “I did this in three accounts, it worked in these two and failed here because… This kind of guidance can save lots of time, energy and money.

The value a Mentor brings is the experience and guidance to provide you with the capability to succeed. Just like climbers of Mount Everest hire Sherpas, you need to do the same.

I hope you’ve enjoyed and learned from our “Playing the Agile Transformation Game” Blog series. Did it answer some your questions? We’d love to hear from you…

And stay tuned for our upcoming blogs!


I’ve been working at doing Enterprise transformations for 18 years now and I can guarantee you that Murphy’s law is quite alive and well. Or as technologists know – the perversity of the universe is optimized toward the maximum. I do have to say all of these events are predictable, and with proper vigilance, can all be avoided. Now you just have to pay attention to find the ones I have not identified.

Here are lots of lessons learned from war stories of how large scale adoptions go off the rails with great ease.

“Left to themselves, things tend to go from bad to worse.” – Murphy’s First Corollary

Failure of the Agile Transformation Team to Deliver

So it turns out you have assembled the best team capable of delivering a new agile transformation to the organization. We have key representatives from all contributing departments; we have the best and brightest decision makers to get to right plans in place and we are ready to begin. We hold our first Transformation team meeting and we have a 70% or better “no show” rate because of press of business on the part of all these people who also have full time (as in 120% booked) day jobs.

Fallen chess pieces

This becomes a real failure upon the part of the Agile Transformation Team to deliver. The team consistently fails to meet; they consistently fail to deliver any assigned work as it is not as important as their day jobs. Essentially you get nothing done.

What happens to your well-conceived Agile Transformation is that you encounter the Second Law of Thermodynamics – and a state of entropy occurs. Your transformation dies a universal death.

Failure to Measure Against a Plan

Simple logic dictates plan the work, work the plan. This is a simple axiom to follow, yet it seems when we actually encounter the work, the plans go out the window. This always amazes me when professional project leaders dump logic and purpose for panic.

It seems that staff on the Agile Transformation Team are not aware we will fight battles, win some lose some, and as long as we win a majority and re-fight when we are in a stronger position for the others, we will ultimately win the war. Instead, each battle is assumed to be the war.

If the plan is no good, of course jettison the plan in favor of a better one. Just don’t proceed day to day without middle term and long term goals and objectives and a path to get there.

Measure progress forward and backward to the plan, use it to gauge and inspect and adapt to the vagaries of the workplace. As Dwight Eisenhower said “Plans are nothing, but Planning is essential”. Do contingency planning, have a Plan B, C, D and Z if necessary.

Failure to Communicate

“What We got here is a Failure to Communicate” – Strother Martin from “Cool Hand Luke”

Failure to communicate is often a cause for failure. Our goal is to establish an agile environment where Transparency and Trust are vital to the success of agile adoption and our transformation. Too often, due to the nature of trying to deliver “stuff” (“Stuff” is a technical term for anything we need that is support or infrastructure necessary to our cause) we miss the opportunity to shout from the rooftops the availability of “stuff” for teams to use to do their jobs.

Or we miss the opportunity to create celebration moments for highlighting successes. We do this for generating excitement and good will for the program. When was the last time you celebrated a success with the team? Get your leadership from both the IT and business sides to go to the team and congratulate them in front of their peers who may not yet be on agile teams. “Hey, look the boss is throwing a pizza party for the agile team, how do I get a pizza party?” That is what you want everyone NOT on an agile team to start thinking… then we can introduce them to agile.

road-sign-63983_1280
Communication Plans and Change Management plans ala Cotter or ADKAR as essential to the success of a transformation. Use every means at hand to communicate what’s happening. Especially WHY you are doing what you are doing. The WHY is just as important as the HOW and the WHAT.

Failure to Lead

I once read an article that dealt with the topic of “the determined person” and how that person would use their talents to overcome any obstacle placed before them. I view agile transformations at the enterprise level to fit that category of “any obstacle”. Lots of barriers, cultural roadblocks, technical traps and management indifference await the determined person who will now need to overcome these barriers.

These types of barriers and more are already in place and awaiting you to be challenged. If you fail to provide leadership and the ability to lead by example, how can you expect that your Agile Transformation Team will follow you? All these barriers, challenges and obstacles will require your best every day to overcome them.

“Everything will go wrong at once” – A Modern Revisionist’s Murphy’s Law

Thinking Too Small

Agile Transformations for very large organizations (2000 staff and up) can take years. Don’t get caught without a strategic plan to accomplish growth over time. Your timeline could look something like:

  • 1 – 6 months Organize, Mobilize and plan the whole effort
  • 4 months to end of year 1 – Early Adopter and piloting
  • 1 year – 3 years Bulk of the adoption based upon organization size and complexity
  • 1 year and on – Establishing stability of the conversion

Don’t get caught thinking that for very large organizations, you will get this done in a year. If you can and do, maybe you belong with the Justice League saving the universe.

Organically Growing Due to Lack Of Management Education

This is a result of abandoning planning. You are just moving from one shiny object to another based on management whim. As an agile Transformation team, you need to broadcast and syndicate support for a plan across the board. Make it public and work the plan. Having a rolling 4 quarter plan that accommodates change is fine. Just keep it in front of everyone so there are no gotchas.

Little or No Change Management Capabilities

Key messaging and managing expectations are keys to success for these Enterprise Transformatons. You have to let everyone in the division know what’s happening, when they may be part of an agile team, what the expectations are, what training they will receive, that coaches are available… you get the idea. Spew information like Linda Blair in the exorcist spewed pea soup all over the priest. If the staff start telling you “too much Information,” you’re doing your job well.

Failure to Get Bottom Up Support for Your Efforts

This is a variation on a theme of the Failure to communicate problem. Actively solicit your teams to speak with leadership; have them tell their stories to their peers. Ask them to sponsor communities of interest for various aspects of agile practice. Work the teams to tell their stories and talk with their peers. This is much more powerful than you think.

“It is impossible to make things foolproof, because fools are ingenious” – Murphy’s second Corollary

Failure to Keep Your Ear To The Ground To Help Avoid External Events Like Poor Business Performance Terminating Your Budget

This happened recently to a company I know of. A downturn in business caused severe budget cuts in the IT area (as well as companywide cuts). End result is many of the Agile Coaching and Enterprise Transformation staff got cut. This caused a loss of capability to achieve forward motion. Agile Transformations can be very expensive, and therefore are a potential target for budget cuts.

One shop I worked in had invested $18.5 Mil in a transformation, they were acquired and the acquiring company having just come out of a bankruptcy had a mentality that “if it does not make us a penny today, don’t do it” The $28.5 Mil investment in the Transformation was scrapped. Keep your ears open for events like this. Even public companies can show signs of upcoming bad news. How would you prepare for a downsized Agile Transformation so you can keep it alive?

Loss of A Key Sponsor

It has happened to me three times now in 22 shops. One heart attack, two changes in management for reasons I cannot mention. The losses were sudden, and new replacements essentially meant new direction too. There was always some period where the new sponsor undertook to come up to speed so as not to rock the boat initially, but in all three cases, the new CIO wanted to prove something to their superiors, that they could get more done with less.

This put a large target on any efforts that were not directly contributing to the business, and unless your transformation is well documented, has serious success stories, has won the hearts and minds of the new CIOs senior staff and is well entrenched as a “good thing” for the business, you should be checking out alternate business opportunities within or outside of the company because your future as the lead of the Agile Transformation team is a short term thing.

Backsliding or Just Plain Failure of Teams to Adopt

My experience says adopting agile is not that hard. Almost all teams properly mobilized and organized can practice agile as SCRUM or KANBAN. So if you are encountering failure to launch, or serious backsliding, check the competence of your coaches, evaluate the competence and effectiveness of your training materials, question the veracity of your competence surveys before you blame the teams. Something in your delivery mechanism is broken. Look internally first, before you blame the teams.

Missing Overcoming the FUD Factor

FUD – Fear Uncertainty and Doubt. Having teams overcome the FUD factor when adopting agile is very important. If they never get over it, that team will be a failure. The FUD Factor is not hard to discover. You can actually see it in the faces of the team members who just don’t get it, or those who see their current job description being disintegrated before their eyes. Having the successes to point at, having leadership address the change in methods and that all are still valued under the new ways are good ways to address this problem.

So there you have it, the challenges, the pitfalls, the problems, the landlines, and Murphy. But don’t despair… Just be prepared!

Get ready for our next and last blog coming soon.


There is a lot of noise in the industry now about “Scaling” Agile. I think you need to consider scaling for the right reasons. An executive order may be the impetus, but what are the real reasons that inform the decision-making process? What do you intend to gain for the organization? What is the timeframe for adoption? What is the payback or Return on Investment?

In this blog, we’ll review the scaling models and the need for them. As an Enterprise Agile Coach, I often describe the “Ideal versus the Real” when I speak about reasons for adoption. No two companies are alike but all have similar qualities and reasons for scaling. Here are some of them.

Why Would I Want to Scale?

So here are some of the reasons that would make logical sense to consider for scaling. Again, going back to the Ideal vs. Real concepts, Ideal Scrum is not always a good practice in real corporate life.

SCRUM or KANBAN Is Not Enough

We find that having SCRUM teams is good, but now we find that complex, large programs require more coordination, more collaboration and frankly, just more horsepower in our development engines than simple Scrum teams can provide.

Regulatory Compliance Needs

I have worked in several regulated industries, Utilities, Banking and others, that require more than User Stories and working software as documentation of systems. Regulated industries demand traceability and audit trails far beyond what is provided by simple outputs from SCRUM events.

Audit Compliance

As a corollary to the Regulated industries, Audit also requires knowing Inputs, Outputs, roles, separation of responsibilities and documenting the same – not always the case with SCRUM practices where we overlap a lot of responsibilities.

Major New Initiatives Requiring Speed to Market

This may be another variation on a theme of SCRUM being too small for the effort required, however consider major manufacturing or government programs where there are thousands of contributors, hundreds to thousands of vendors and suppliers delivering to large scale systems. It takes more than just “more scrum teams” to get the job done. We need an infrastructure capable of delivering major systems of systems on the scale of a jet fighter or an SAP conversion.

Enterprise PMO Looking for More Accountability

To do forward looking plans and budgets, large scale companies often employ Enterprise level Project Management Offices for the purpose of delivering Programs and projects for the enterprise with efficiency and effectiveness. These organizations will require more accountability on the part of SCRUM teams.

Tighter / More Effective Connection to the Business’s Needs

One on One in front of a whiteboard is the recommended approach for SCRUM teams to gather requirements for delivery of Minimum Viable Product. When your business customers are for example, banking managers for a global bank with participating units in 100+ different countries all with different banking laws, Face to Face does not work well.

In your organization, one, some or all of these topics (plus others) may be prevalent. What does your organization need to address? This sets the stage for making some headway on the topic of Scaling Agile across the enterprise.

What Does a Transformation Look Like?

An Enterprise Transformation is different for each individual company, but does have similar major phases and milestones. So here is a generic model for adoption.

Early Adoption-9

Figure 1 – Enterprise Agile Adoption Phases

Mobilization

In mobilization, we do the kinds of things discussed in the first entry in the series, we:

  • Define the Vision
  • Define and deliver the Executive Steering committee
  • Define and deliver the Adopter Delivery Group
  • Get a budget
  • Select measures to determine “Done”

Method Selection or “The Bake Off”

  • Selection
  • Evaluation
  • Picking a “Winner”

Early Adoption

  • Customization
  • Training
  • Roll out
  • “Piloting (Early Adopters)”
  • Measuring
  • Publishing Success Stories
  • Develop a Communication Plan
  • Develop a Change Management plan
  • Develop a Metrics plan

Major Adoption

  • Continued rollout
  • Measuring “are we there yet?” See next blog for an explanation of Metrics
  • Measuring compliance with agile practices and tool usage for all adopters.

Sustainability

  • Ongoing maintenance and continuous improvement of the Enterprise Agile Transformation program intellectual property and practices.
  • Measuring compliance with agile practices and tool usage

So how long does an Enterprise Agile Transformation Take?

Well, the answer is a very Zen-like answer to a question which is “How long does a piece of string need to be?” The answer is “Long enough”. So how long does an Enterprise Agile Transformation take? As long as it takes. There are too many variables to give an accurate estimate. It can take 1 1/2 to 4 years depending on the size of your organization, your Transformation plan, How you approach it and what your “Definition of Done” is.

What does an Enterprise Agile Transformation look like?

An Enterprise Agile Transformation is a multi-layered beast. At its Core you find:

People Crosscutting the Org

To misquote Bill Clinton in his 1992 debates with George Bush, “It’s the people, stupid”. At the heart of all of the work we do is the need to capture the hearts and minds of the people who do the work. NO amount of mandating by management will make an agile transformation work at any level, scaled or not.

We have multiple constituencies who we need to educate, and cause to change direction and stop using old patterns and adopt new ones. To do so, we have to assure that the people in the organization understand the why, what, when and how of what we are attempting to do.

Processes “Workable Selection”

Whatever process or method we choose for scaling, very likely it is not an IT-only decision process. And even within IT, there are several service groups affected differently by agile methods. All need to be included in the agile tent.

Tools “Enterprise or Local Selections”

Tools are often like religion, there are many and it seems we have different selections within large corporations. Some companies mandate the use of a specific toolset, others are very linear in their attitudes about tool usage. Regardless, the tools need to often provide upward reporting of metrics on adoption and sustainability of agile practices.

Requires Strong Leadership

“Personnel is Policy” to misquote Elizabeth Warren. Whomever leads the charge needs to have strong leadership skills Someone who can influence, what I call “Sell or Tell” and can make their arguments heard and stick. More on this topic in the last in the series “The Man Behind the Curtain.”

Acceptance is Highly dependent on:

Change Management Plan

All the good works done by the steering committee and the adopter group are no good if we do not have a strong change management plan. This sets the direction and rollout for the enterprise.

Communications Management Plan

Also essential is great communication plan. This plan outlines the messaging required for all levels of management for top down communication, and also describes the strategies and tasks for generating bottom up support for the program.

Figure 2 - Holistic Approach to Enterprise Agile Transformations

Figure 2 – Holistic Approach to Enterprise Agile Transformations

OK, I’m Geared Up and Ready To Go! What Are My Choices?

Here are the most popular, in alphabetic order, showing No favorites:

  • DAD – Disciplined Agile Delivery
  • Hybrid – Mix of best practices from two or more
  • LeSS – Large Scale Scrum
  • SAFe – Scaled Agile Framework

Of the listed methods, one stands out from the rest in a recent survey conducted by VersionOne, an agile tool provider. Per their 10th Annual State of Agile Report, the Scaled Agile Frameworks leads the pack with 27% of respondents reflecting that they were in some stage of adoption. This compares to 6% for LeSS – Large Scale Scrum and 3% for DAD – Disciplined Agile Delivery.

SCRUM and SCRUM of SCRUMs leads all with 72% responding that that is their method of choice.

So what do each of these Methods look like?

Disciplined Agile Delivery (DAD) 2.0

DAD poster

Figure 3 – Disciplined Agile Delivery 2.0

My Impressions:

Good for Regulated Companies

If you are in a regulated industry and need more technology related approaches to building your apps, DAD is a good process to follow. It is strong across the IT infrastructure and is growing into the business community. Strong Milestones, and data points – lots of recommended system and technology related documentation.

Maturing to include Program and Portfolio levels

Differing from the original 1.0 version, there is new emphasis on Program and Portfolio level organization and delivery.

More Technology direction than other two

There is strong technical and technology direction form DAD. It covers details the others do not about “how to” in SCRUM and KANBAN environments.

Recognizes DevOPS Challenges

Separate from the other two, it specifically calls out and defines practices for DevOPS, a growing trend in these scaled methods.

Least adopted of the three proposed Methods.

Large Scale Scrum (LeSS)

Large Scale Scrum (LeSS)

Figure 4 – Large Scale SCRUM process

My Impressions:

A Scrum of Scrums

This for all intents is just a Scrum of Scrums. Great practice to follow if you have organizational discipline and can enforce the rigor of using this approach as with simple scrum.

Very Idealistic Scrum of Scrums Implementation

To my Ideal versus Real argument, like all these methods LeSS is an ideal picture of how things work. Your mileage may vary. The higher the regulation and compliance needs are probably the less (no pun intended) you will likely adopt Large Scale Scrum.

Requires Discipline and Rigor

This approach in particular, will require significant discipline and rigor for adoption and sustainability. Since it is scaled scrum, likely it would require some to a lot of customization to work in your organization.

Not really a Method, more a set of Procedures

This is the original definition of a scrum of scrums with some additional roles to help it scale a little better.

Scaled Agile Framework (SAFe)

f85118383f9d306f1cd2cd8587e19b68

Figure 5 – Scaled Agile Framework 4.0 Expanded to 4 layers

My Impressions:

Most adopted of the three

According to VersionOne’s 10th annual Survey of Agile, SAFe is the most widely adopted and accepted method of the three recommended. It has traditional KANBAN and SCRUM support, and for programs and projects has sync and cadence points for matching up disparate types of waterfall, and agile projects.

LEAN Based

SAFe does represent a built up, ground up approach to a method based upon LEAN practices.

Business centric based (lots of business collaboration)

As indicated by the diagram above it is in my opinion the method that goes the farthest to include the business in a collaborative process. Its sweet spot is 150 to 400 participants and covers the whole organization. It provides an even balance of Tech and Business focus.

Moving to Scrum implies a behavioral change

–      to the Agile mindset
–      supported by the Agile Principles found in the Agile Manifesto
–      potential organizational change

Many teams find themselves in the land of FrAgile (i.e., fake Agile)

–      Scrumbut (i.e., we are doing Scrum, but not some of the practices)
–      WaterScrumFall (i.e., some elements of Scrum within a waterfall lifecycle)
–      Kantban (i.e., Kanban without respecting the queues)

This may be because there…

–      wasn’t a commitment to go full Agile
–      wasn’t an understanding of what an Agile method entails
–      wasn’t the talent (such as an Agile Coach) available to help bring about that change
–      was an incremental Agile deployment approach which stalled along the way

Frameworks like LeSS, Dad and SAFe are developed by experts. Who’s writing your hybrid? How measurable is the work done under your hybrid?

Comparison Criteria

Each Enterprise has different needs and characteristics that would inform your decision making.

Here are some common areas to develop criteria to use if they apply to you:

  • Regulation (Sox, Banking, Pharma and other)
  • Geographic Distribution (multiple locations for both business and IT)
  • Offshore contracting / Vendors and Suppliers inside the firewall
    • (“Inside the firewall” meaning teams from these sources are part of the local team)
  • Size of teams (Do you organize around projects or work?)
  • Audit Requirements and Compliance needs
  • Internal Need for Command and Control (politics, cultural resistance to change)

Selection Criteria

So I have to start this section with a Disclaimer:

These sample criteria represent my opinions alone and no other organization or business. If you want to argue about them, feel free to ping me. Don’t blame anyone else for my choices.

Hybrids are not represented as it would not be possible to determine value for individual Hybrids, I’ll leave that up to you…

Here are SAMPLE Selection Criteria I have found useful over the years. Please bear in mind YMMV (Your Mileage May Vary) depending on any number of variables governed by and informed by Comparison Criteria.

Selection Criteria

Which One Should I Pick?

So here’s a simple consultant’s answer: “IT DEPENDS…”. It depends on your culture, your tolerance for change, on how you are organized, what timeframe you have, what problems you have to solve and what regulatory and compliance needs come up.

Each company I’ve worked with since my beginning Enterprise Rollouts in 1998 has had differing business models, differing requirements and what works for one org may not work for the next. What works in one portion of an org may not work in another. So you are left with the question, “What works for you?”. This is something you have to answer for yourself.

My Recommendations

However, I do have some recommendations based upon past experience doing Enterprise rollouts.

They are:

Stick with Popular Methods (DAD, LeSS, SAFe)

Look for commonly supported methods. Between these three you are very likely to find a solution that you can customize to your need. These are supportable, customizable and have a long life span of 3 to 10 years.

I should note that I am not a big fan of Hybrid solutions. They take too long to define, compromise by committee will not achieve your long term goals, and likely will end up worse than waterfall in execution. Hybrids are technology bound, do not have a support structure for the long term and usually die a quiet death over 2 – 3 years due to adoption of methods that work.

Only scale for the right reasons – have a solid business case with an ROI

Do not start an Enterprise rollout without a case and an expected ROI. How else will you justify a budget, and the time expense and change to the organization without one?

Do not expect to adopt a Method Out of the Box

I have yet to see a successful adoption that did not do some to major customization of the out of the box method. Just the evidence of different business models says “one size does not fit all”. Expect you’ll have to do some customization. Some of these methods are like the fake town at the end of the movie “Blazing Saddles:”, just propped up storefront explanations of deep and wide topics. Get a close a fit as possible then tailor to your need.

Get a Sherpa guide

Get a Sherpa guide. You will be surprised during the journey what you discover you did not know and did not consider. While it may seem an expensive step, it is going to save you a lot of money and time if you get an experienced guide. See the last blog, “The Man Behind the Curtain” for a more in-depth explanation.

I Picked One, Now What Do I Do?

So what comes first, what comes next? We do the mobilization steps until we reach a critical mass of staff and budget approval. Then we move forward with selection. Once we finish that, then we start with:

Customization

Any adoption will most likely require an Out of the box (OOTB) Method with customization to your company’s needs. OOTB solutions are generic, and not meant to be adopted wholesale. Expect that you’ll make changes like a tailor building a bespoke suit of clothes.

Training

You have several groups that need training:

  • The Agile Transformation Team
  • The Early Adopter teams
  • The Leadership of the Early Adopter Teams
  • Executive management on both the IT and business side

Dealing with Vendors, suppliers and contractors also should be a matter of focusing their contracts and SLAs along the lines of supplying staff that are trained in basic agile skills, so they can get ramped up quickly when they join your teams.

Roll Out

As part of the Change and Communications plan, you will need a communications plans to establish a roll out plan and process to get the customized method and training (and potentially tools) in the hands of the early adopters.

“Piloting (Early Adopters)”

Have you noticed I keep referring to “Early Adopters”, not “Pilots”? I do not like the term Pilots. It is a term that makes me think that if the plane is going down, you can bail out. Early Adopters has more of finality ring to it.

Measuring Are we there yet? Are we there yet? Are we there yet?

Conversion measures begin with early adopters. The quality and quantity of the teams on the journey need to be measured.

Critical Mass and Sustainability

Our goal is conversion of most or all of the organization. So let’s define what portions are being converted and target them in our change and communications and rollout plans.

Publishing Success Stories

Per John F Kennedy, “Success has a thousand fathers, failure is an orphan” – let’s celebrate our successes as much as possible. Let’s find every possible communications channel to highlight that staff are being successful with agile within and outside of the organization.

Who does this work? – The Steering committee, the Agile Adoption Group and Enterprise Coaching.

Parallel Processes are Engaged

Parallel Processes

 

You’ll find that once you start, there are a LOT of parallel processes you need to kick off. This implies a strong change management function be employed. I recommend the use of tools like any of the popular work item management tools Rational ALM, VersionOne, Jira, CA Agile, and others. Pick your own poison, but use one religiously to control all the parallelism and interaction of these different work streams.

Here is a sample list you might encounter:

 

  • Create / customize training materials
  • Configure tools templates
  • Create new outcomes and outputs from new processes
  • Create new metrics to measure new / different ways of doing work
  • Define new roles
  • Craft messaging for change management plan
  • Cobble together news sources to publish events and news about the new method and success stories

So, a hint, staff effectively!

Picking Early Adopter Projects

“Don’t Use the Word “Pilot”

As I’ve said before, don’t use the word “Pilot”. I like the term “Early Adopters”.

Choose Early Adopters Selectively

Look for potential successes for early adopters. I had a psychologist show me a card trick once, and regardless of who he played, and what selections were made, the answer was always the 10 of spades. We want to use the same mentality in picking early adopters. We want to maximize the selection criteria so that the teams will succeed despite picking up an entirely new method.

Choose 8 Or 10, Early Adopters – You Are Likely to End with 1 – 3

The work assigned to early adopters can prove to be frail projects. My experience is that over the course of 6 – 9 months, projects get killed, de-funded, put on hold for more important work, and what started as 8 to 10 selections winnows down to 1 – 3 remaining survivors. Not a good showing when you want to validate the results with working teams.

Expect that you’ll need to run these experiments for a while, about 3 – 6 months, to determine actual success.

Here’s a model to also consider when selecting the teams. Some early adoption teams will like to take on new ideas and practices. Others at the opposite end of the spectrum, the Skeptics and Rebels may never adopt. My advice for that holdout group is “vote them off the island”, by finding them different roles in the organization where their negative attitudes do no harm. The figures are samples, YMMV.

Adoption TimingI’d also pay attention to who is affected over time when adopting these new practices. There are a number of paradigm shifts that take place both for the adopter teams and for the rest of the organization.

Organizational units affected by change

Hopefully, this blog has given you a start in the right direction.

In the next blog, you’ll learn all about how to measure your transformation results. Stay tuned!


Enterprise Transformations are a great game. From the starting line, what do I need to do to transform my Enterprise into a lean, agile shop? Which Scaled Agile Model is right for me? What change can the Enterprise absorb quickly? What are the key aspects for creating a sustainable lean, agile Transformation model? How do I budget and staff for a transformation? What makes it work? Last, What’s in it for me and the Enterprise?

Armed with your list of pain points, you can use this and the following articles as a high level guide to selecting and implementing a Scaled Agile Method that would be a best fit for your Enterprise.

Choose a Scaling Method that is sustainable for a long time – what options are available to me?

Agile practices have been in mainstream use for about 16 years now, with real traction in major companies for at least the last 10 years to some degree or another. Scaling methods are relatively new, most either evolving from older iterative methods, or springing up new in the last 5 years or so. Despite their relative new-ness, these methods are finding great acceptance with large and global corporations who for the most part found shortcomings with SCRUM practices for small teams not meeting the needs of large scale corporate efforts.

Climbing, Scaling

Considering the cost, involvement and effort to make the transition, choose a method that will be sustainable for a minimum of 5 years and may be in place for as long as 20 years. Also assure that the chosen method allows or future flexibility and growth along with the Enterprise’s needs.  Some of the most commonly available and practical models to choose from are:

  • Disciplined Agile Delivery – DAD
  • Scaled Agile Framework – SAFe
  • Large Scale Scrum – LeSS
  • Hybrids of in-house methods and selected practices from the methods mentioned above

Later in this series, we will do some side by side comparisons. So where to start?

Gauge the Ability of the Enterprise to Accept Change

So you think you want to start down the path of change. Let’s begin with the ability of the Enterprise to accept and adapt to change. Some questions immediately come to mind.

Will there be any major barriers to change, and what might they be? How big and diverse is my Enterprise, and what is the culture like regarding accepting change? Who will be impacted and how?

Answers to questions like these will determine the size and scope and timing of the Transformation. You will find that some of the answers to these questions, like the ability to accept change within the Enterprise, will set upper limits to how fast you can go, or if you can go at all. Geographic and demographic issues pop up, in-place agile efforts underway may need consideration or change, failed agile efforts may be an impediment.

How you structure the Transformation teams may also be a limiting factor. A 5-person team tackling a 2000-person Enterprise is likely to take a long time. Getting a handle on the size and scope of the Transformation is a great start.

Find a sponsor “Way Up” in the Enterprise

You have decided to move forward, so you will need executive sponsorship to assure this program is visible, funded and a priority. Find a sponsor who is one of the decision makers regarding the Enterprise, someone at the Enterprise level, not a department or a division. Expect that you need more than one – people who are valuable will move on, you will need replacements and these transformations can span one or more years so it is always wise to cultivate more than one sponsor.

Build a Fulcrum Upon Which You Can Leverage Change

Per Archimedes “Give me a lever long enough and a fulcrum upon which to place it, and I shall move the world”. You cannot do this transformation alone. Even the most determined person is typically outmatched by the effort to change their world, so get help.

FulcrumPhoto

I recommend two groups, a Steering Committee to set direction for the Transformation and a Delivery Group to get the Transformation done. These two groups can become the fulcrum upon which you can lever your Enterprise.

Steering Committee

Create a Steering Committee made up of key affected staff with a strong interest or a stake in the success of the Transformation project whose sole focus is Agile Transformation by the Enterprise. This group of individuals (usually a cross functional management team who has the Accountability, the Authority and the Responsibility to get things done) is responsible for:

  • General operating policy, procedures, and related matters affecting the Agile Transformation as a whole
  • Defining Operation, Scope and Venue of the Transformation

All participants act as champions of the Agile Transformation whenever and wherever possible. They as senior managers are key message bringers who deliver the “top down” portions of the messaging from the change management plan.

In terms of Operation, they:

  • Set Goals and boundaries for the Transformation Process
  • Set Objectives for the Transformation project with a one-year horizon
  • Meet as required to provide guidance to Adopter Groups
  • Acts as SDM Change Management clearinghouse for changes
  • Spin off working committees to address significant matters that affect change in the Enterprise

Here’s a potential structure for a steering committee…

Committee
Delivery Team

In addition to the Steering Committee, you also need a bunch of “Doers” who get “stuff” done. (”Stuff” is the technical term I use regularly for all the messaging, change management, toolsmithing, templates, mentoring, coaching that takes place as the key transition activities of the Transformation).

The Delivery team’s makeup is mostly technical and consulting in nature as they are the delivery mechanism for all the “Stuff” required by the Enterprise making the transition to Agile.

The Delivery team’s major deliverables are:

  • Process Definition and rollout
  • Tools adoption and support
  • Training and education on tools and process
  • Mentoring
  • Metrics generation for consumption by the Steering Committee

A hint about these two groups, if the lead of the Enterprise Transformation heads both committees, you have a built in communications device for making sure that what is decided is implemented.

Attach your Fulcrum Teams to a Very Visible Enterprise Level Group

Now that you have your teams mobilized, insert them into the workstream of the Enterprise at the right level. Choose a visible and important internal Enterprise to attach the Enterprise Transformation effort. This Enterprise Level Groups is likely aligned with your executive sponsor, like an Enterprise PMO Group, or the Office of the CIO. A transformation of this type is normally highly visible and needs to be supported by the Executive management and given the visibility and priority it deserves.

Get a realistic budget for the first year

“Money makes the world go round” – Money from Cabaret

You need a competent budget. Or, another way to look at is it TANSTAAFL – There Ain’t No Such Thing as a Free Lunch”. And yes, to mis-quote Midas (The muffler people, not the King with the Golden Touch, “You are going to pay a LOT for this muffler”. So get your money’s worth from the effort.

Expect to pay for:

  • Training
    • For the Steering Committee
    • For the Delivery Group
    • For the staff being transformed
    • For other interested parties in the Enterprise touched by this transformation
  • Cost of Full Time Staff who do the transformation
    • Steering Committee
    • Delivery Group
    • Other supporting areas like purchasing, legal and others
  • Consulting
    • Likely you do not have these transformation skills in house
    • Good Mentors and coaches do not come cheap, bad ones do
  • Licensing for Methods
    • There is potential that selecting a specific Method may require some licensing fees
  • Licensing for (new?) tools
    • Unless you already have development platform tools with agile support, you may end up licensing new tools
    • Infrastructure for tools support
    • Time and effort to customize the tools to match the new Agile Method(s)

Set expectations of how long you may be at this effort, and how much it may cost. Delivery Team, training resources and budget are limiting factors and affect how fast can you go, and therefore how long will it take.

Plan to Live in a “Glass House”

Some advice, one of the most often asked questions I get is “If I have to adopt this, why aren’t you? Expect that if evGlass Houseeryone else has to adopt agile tools and processes – you better do so too.

Also plan for transparency on all issues good and bad. Better you air your dirty laundry about successes and failures than others doing it for you. That way, you have a better chance of controlling the messaging that gets out surrounding failures.

Consider the End Goal

Last, envision what the Enterprise will look like in 2,3 5 years after the transformation – what will you gain for the effort? How far does the Transformation go?  Write it down in a vision. 1 – 3 pages long, take the major components and put them in a roadmap by Quarter for at least the first year and now you are ready to begin.

Develop Measures to define “Done”

A definition of “Done” that we can all agree upon is also a key to success, you are not done until you are done. This will be important for long term adoption programs. What is the goal and how are we measuring progress (or lack of) against our goal.

Ok, this blog is DONE. Look for the next one in our series.