I (Gene is here) had the pleasure of having a discussion with Roman Pichler, the author of “Agile Product Management with Scrum: Creating Products that Customers Love” (as well as a few other great publications), who recently wrote “Five Product Owner Myths Busted“, making multiple references to SAFe. In our discussion, particularly, we focused on the following three myths:
- Myth #2: The product owner is a tactical role focused on managing the product backlog
- Myth #3: The product owner is responsible for the team performance
- Myth #4: The product owner is responsible for writing user stories
In this post:
- Agile Transformation Group (ATG)
- Agile Transformation Team (ATT)
- Engagement Example
In their journey, to become more adaptive (agile), organizations need guidance and support. Ideally, organizations should own their own agile transformations: experiments, decisions, successes and failures, with minimal reliance on external help, especially, from low quality consultants and large consulting companies (see recommended mix below). What should internal (to a company) agile coaching organization look like? What/who should it include? Who should lead it? How should it be executed?
Unfortunately, many organizations, still prefer a “quick fix” approach to solve this problem, by loosely relabeling existing, traditional structures into “agile” structures, or rebranding traditional roles into “agile” roles. For example: PMO → Agile PMO, senior project managers → enterprise & team agile coaches, junior project managers → Scrum Masters, etc. This en-masse/big-bang approach, should be avoided. As Albert Einstein once said: “We can’t solve problems by using the same kind of thinking we used when we created them.”
One general advice to an organization that wants to build its own internal agile coaching structure, is to keep in mind that the rest of an organization will look up to it, as a role model. Therefore, an agile coaching structure should keep its own bar high and practice what it preaches, in terms of having a lean design, effective communication and healthy internal dynamics.
For the purpose of this writing, an entire agile coaching structure is referred to as Agile Transformation Group (herein, abbreviated, as ATG). Here are a few recommendations, regarding its purpose/focus, position and structure:
The main purpose of ATG is to a spearhead organization-wide effort to become more adaptive. This includes organizational consulting, training/education, coaching and mentoring capabilities that would be made available widely, to various organizational structures and employees. The main “deliverable” of ATG should be consistent with main optimizing goals (e.g. better competitiveness, increased market share, lowered costs of changes). ATG may refer to its own deliverable as service, or product, or combination of both, or anything else, as long as the rest of an organization understands ATG’s main purpose and sees value in what is being delivered.
It is critical to position ATG in a way that it receives executive management support, steady funding and operational safety. Executive management support and funding must not come in spirit-only (e.g. a town-hall announcement: “we support your agile transformation and here is an unlimited budget for you to spend on this new effort”) but rather with direct and intimate involvement, by executive management that is willing to invest its own time in learning and deep system thinking. Operational safety implies that ATG should not be placed within a traditional organizational structure that historically has not provided a sufficient support to organizational adaptive-ness/agile: PMO, enterprise architecture, etc. You also want to avoid creating centralized power-towers that impose/enforce agile onto the rest of an organization – this will just lead to “broad & shallow” results, system gaming and resentment. When building and positioning ATG, please, consider a healthy balance between centralized vs. decentralized approach, balancing between standardizing coaching approaches, tools & techniques and offering autonomy to coaches that are deeply engaged with teams and products.
ATG should provide a great role model to the rest of your organization, in terms of its design, relationships, communication and dynamics. If ATG’s goal is to help an organization become more nimble, reduce bureaucracy and silos, eliminate contractual relationships (“me vs. you”), promote cross-functional teaming, etc., ATG should be able to demonstrate the same qualities, within its own space.
Lets review an example, when ATG decides to adopt a lean, agile framework, such as Large Scale Scrum (LeSS), used for large-scale, multi-site product development. If such decision is made, it would have to include the following organizational elements in its own design:
- Head of ATG (an equivalent to Head of Product Group in LeSS), whose responsibility would be to provide an overarching organizational support and protection to ATG. Ideally, everyone within ATG would report to Head of ATG, similarly to how everyone (teams and Product Owner) report to Head of Product Group in LeSS.
- ATG Product/Service Owner, whose main responsibility would be to prioritize organizational requests for agile training, consulting, coaching and mentoring support, would be positioned, on par (same level) with teams, and report directly to Head of ATG (similarly, to how Product Owner reports to Head of Product Group in LeSS, mentioned above).
- Teams (self-organized/managed, cross-functional and long-lived), whose responsibility would be to engage with various areas of the rest of an organization, for training, coaching, consulting and mentoring support.
- Communities (informal, horizontal organizational structures), whose main function would be to support and promote functional learning within ATG. Similarly, to LeSS communities, ATG communities would be matrix/hierarchy – free and by-volunteering.
Please, note that ATG should strive to maximize a number of its own people (company’s employees) that uphold positions within a group (and its teams), with minimum reliance on external support. If external support is used, external helpers should be cherry-picked individually and thoroughly, for their unique capabilities and expertise they bring to a table (for specialties and capabilities, see below), using high standards. Mass-engaging of consultants, individually, through staffing firms or large consulting companies, is strongly unadvisable.
For the purpose of this writing, each team within ATG is referred as Agile Transformation Team (herein, abbreviated, as ATT). Here are a few recommendations about its purpose/focus, position and structure:
The main purpose of ATT would be providing tailored support to various organizational areas, anywhere ATT is deployed. This includes training, consulting, coaching and mentoring to all/any organizational structures: technology, business, operations, support, HR, finance, legal, location strategies, etc. ATT’s activities, length and intensity of engagement, should be explicitly decided prior to engaging. It, therefore, implies that each ATT would be capable to perform this function independently (see below).
Multiple ATTs would be a part of the same ATG. If LeSS framework is used as a guideline for ATG structure, then the following LeSS Structure rules would have to be followed for ATT:
- Total of 50-60 (max 70) members within ATG
- 2-8 ATTs per ATG
Note: The above numbers are based on the recommended number of people in Scrum (3-9), and are based on many experiments and research, collected over many years, with the focus on: quality of communication intra- and across teams, as well as communication between teams and Product Owner.
Given that the nature of ATT work would be different from what is typically delivered by LeSS teams (software product development), the above ranges, potentially, could be further experimented with: expanded or constrained, as needed. For example, given that an average ATT size could be noticeably smaller than an average size of a team in LeSS, the range of 2-8 could be widened, experimentally, to keep the overall size of ATG, within the recommended range (50-60).
Each ATT should consist of members that have multiple, overlapping and complimentary skills, with each person having deep expertise in one of the required domains, and some expertise in one or more additional domains. This approach would be consistent not only with LeSS but also with one-team Scrum. Below, is the list of skills and capabilities, each ATT should possess, in order to be able to effectively handle any support request from an internal client:
- Ability to engage at all/any phase: organizational assessment, training, consulting, coaching, mentoring
- Possession of knowledge: frameworks, feedback loops, ability to recognize challenges, utilize organizational enablers, leverage agile and scaling/de-scaling principles, metrics
- Competencies: facilitation, education (training), balancing (e.g. between coaching and consulting), assessing (e.g. between discovery and direction), catalysis
- Specialties: organizational structure/culture/leadership, multi-team dynamics, technical excellence, user experience, marketing/sales, business/operations, HR, budgeting/finance, legal, location/site strategies
Note: Please, avoid diluting/reducing the importance of having the highest quality talent, as members of ATT/ATG. Low quality experts will lead to low quality service, to your organization, and therefore, a loss of reputation, credibility and trust for ATT/ATG. Please, refer to the highest industry standards available (team-level, enterprise-level), when growing your own, internal, ATT/ATG expertise.
Depending on an initial assessment, you may require cross-functional team members, with various complimentary and overlapping skills, as per the above references. The goal is to make sure that a self-formed & managed, long-lasting ATT, forms a strong relationship with an organization that it supports. Depending on the size of an organization (recipient of support) multiple ATTs may have to be deployed, in parallel: determining this number is a local decision. All teams should have similar capabilities and skill set – just like in LeSS.
Similar to LeSS, the aspect of self-organization would be critical, when creating effective ATTs, within ATG. While defining strategic focus and purpose of ATG, consider also defining the most optimal, based on what you know at the time, blueprint for ATT: “what would an ideal team look like, to deliver maximum value to a customer”? Based on this knowledge ATG may have to do additional tailored staffing.
Please, avoid using a traditional top-down managerial approach to build teams. Instead, consider conducting a team self-design workshop, by referencing this publication, as a guide.
For the purpose of this writing, we shall take a look at how the above described LeSS-like ATG and its supporting ATTs, would support an organization that wants to adopt customer-focused, product-centric software development framework – Large Scale Scrum (LeSS). Metaphorically speaking, this situation could be described as: “forging a hammer with a hammer”:
A LeSS adoption (product development, itself), would involve:
- LeSS Product Group
- 50-60 developers (on average), grouped into 2-8 teams
- Product Owner (one)
- Scrum Masters (seasoned, capable of coaching between 1 and 3 teams)
- “Undone Department” (remaining functions that did not make into the original Definition of Done)
- Users/stakeholders and/or customers, expected to provide a supportive role to LeSS Product Group (details, clarifications)- from a few, to a few dozen people
- Very importantly, executive management, HR, budgeting, legal, etc. – whose overarching support (in action) would be strongly required
As such, and this is based on the advice of multiple seasoned LeSS adoption experts (coaches, trainers), there will be at least one, or more, ATTs needed, to support a LeSS organization. This would include:
- Educating/advising executive management on organizational design implications of LeSS adoption
- Training/coaching teams and team members on inter-and intra- teams’ dynamics, including LeSS roles, events and artifacts
- Wide gamut of engineering practices: TDD, ATDD, BDD, CI/CD, unit testing, branching/merging strategies, unit testing, test automation, etc.
Please, remember that every organization wishes to see a great role model in the face of its own agile transformation group (referred as ATG, in this writing). If ATG is lean, nimble, adaptive and has great internal dynamics, then there is a much higher chance that the rest of an organization would be motivated to follow ATG’s footsteps.
But the opposite is also true: if ATG’s structure is cumbersome, bureaucratic, with silos, redundancies and internal competition, it will not be too successful in its efforts, will eventually lose credibility and reputation with the rest on an organization, and therefore, will not succeed in leading an agile transformation.
The topics we discussed:
- SAFe history
- SAFe relevance to RUP
- SAFe relevance to Scrum and agile
- Overall market success/brilliance of SAFe
- SAFe strategic alignment with tooling companies
- SAFe, as a framework of choice by large consultancies (“Why?”)
- Economics of SAFe adoption: client companies vs. SAFe
Main Take-away Points:
- “Developing in isolation can help an individual go faster but it does not help a team go faster. Merge time and rework cannot be estimated and will vary wildly, and the team can only go as fast as the slowest merge.” – Steve Smith
- “A spike solution is a very simple program to explore potential solutions. Build the spike to only address the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away.” – Don Wells
- “The objective is to eliminate unfit release candidates as early in the process as we can …You are effectively prevented from releasing into production builds that are not thoroughly tested and found to be fit for their intended purpose.” – Jez Humble and Dave Farley
- “Feature Branching is a poor man’s modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploy-time they couple themselves to the source control providing this mechanism through manual merging.” – Dan Bodart
- “Feature Branching hinders integration of features.”
“Feature Branching hides work for the rest of the team. Frequently merging back to mainline = communicating with your team”
- “Feature Branching works against refactoring.”
- “Feature Branching creates inventory.”
- “Feature Branching increases risk.”
- “Feature Branching creates cognitive overload.”
- “Continuous Integration Your application is always in a releasable state on main line – with Trunk Based Development”
- “Continuous Integration Your application is always in a releasable state on main line.”
- “Break large changes into a set of small incremental changes”
- “Use Branch by Abstraction when performing large refactoring.”
“Feature Toggles to decouple feature release from code deployment.”
- “Trunk-based development requires a big mindset shift. Engineers thought trunk-based development would never work, but once they started, they could not imagine ever going back.” – Gary Gruver
Additional Learning Assets:
Additional Self-Study Assets:
- 05/05 – LESS TALKS: Dave Snowden: Answering Tough Questions (Q&A)
- 02/27 – LESS TALKS: Q & A on “The Spotify “Model”: Don’t Simply Copy-Paste”, with Evan Campbell
- SAFe: Market Share Increase. Rapid Growth. What is the recipe? (please, make sure to reference to large collection of references at the bottom of this page)
- LeSS NYC meetup
- History & Origins
- Market Share, Framework Versioning and Certifications
- Influence by Large Consultancies
- Business Partnership with Tooling Companies
- Framework ‘Size’ and Traditional Organizational Design
- Team Structure and Coordination
- Backlogs and Product Centricity
- Product Ownership
- Proximity of Customers, Users and Stakeholders
- Integration and Release Management
- Agile Leadership and Frameworks
- Conclusion & References
SAFe was created by Dean Leffingwell – a successful entrepreneur and software development methodologist who has consulted to many companies, over years, including Rational Software, Rally Software, as well as many others. Dean’s LinkedIn profile displays “Chief Methodologist” in the title. LeSS was co-found by Craig Larman and Bas Vodde – both of whom are hands-on software developers, with many years (up until today) of experience, in large-scale, multi-site product development environments, including product companies, large telecom and investment banking. Both co-founders have a lot of experience with organizational design and system modelling (a big part of LeSS). Interestingly, Craig’s LinkedIn profile states “public safety, junior programmer” and Bas’s – “team member“. The irony is in the modesty of their titles, since both co-founders have made a monumental investment in the industry, in the area of agile product development during the last few decades.
The initial release of SAFe program was in 2011, with five major release that followed.
Although, as an *official* framework, LeSS was announced only in 2015, its history goes back decades. The three Large Scale Scrum product development books were written in 2008, 2010 and 2016 years, respectively, with many field experiments collected over of the years, prior to 2008. Essentially, LeSS has been a huge body of knowledge, collected over many years, before it became known as the framework.
SAFe is very widely known. Its market share in the world of scaling is by far, the highest of all known frameworks. Consultancy market is dominated by Certified SAFe Product Consultants (SPC) that hold, at least one, of many SAFe badges. Because there are so many versions of SAFe (2.0, 4.0, 4.5, 4.6, 5.0), naturally, certification holders are driven to come back, for an upgrade training, to remain ‘up-to-date’. Since SAFe supports a number roles that are aligned to traditional organizational roles, many SAFe courses are role-specific. The number of instructors that can deliver SAFe courses is also high, with many course-reselling companies being actively involved in marketing, promotion and re-selling.
LeSS is not as widely known. Its market share, relatively to SAFe, is low. There are only three main types of LeSS certifications (Basics, Practitioner and Executives), with other few types, mainly, being on-line versions of the main ones. LeSS training/certification is not ‘role-specific’. LeSS adoptions are deep and narrow (as oppose to being broad & shallow). According to field experts, there is no expectation that LeSS will become a mainstream in a foreseeable future. This is because LeSS has high expectations for organizational design improvements (see below) that many companies are not yet ready for. Today, there are very few LeSS trained/certified people because the number of accredited LeSS instructors is also relatively low (slightly over 20 people, globally). LeSS, just like Scrum, does not have any versions. There are two LeSS frameworks: [simple] LeSS framework (up to 8 teams) and LeSS Huge (stacks of LeSS, totaling hundreds or more people, if required).
Many large consultancies recommend SAFe to its clients, as a framework of choice (Note: As a corollary, many companies-clients, to officially remain framework-agnostic, adopt their own flavor of SAFe, essentially, using their own internal terminology, while mimicking/mapping to SAFe terminology, structure, etc). For large consultancies, this ensures a more profitable and prolonged engagement, since SAFe implementation involves many people, processes and tools (see below). Dave Snowden refers this type of engagement as an ‘industrial model’, since it ensures a “massive roll out, with lots of people, over a long period of time” (also, see this “Triple Taxation” illustration to understand a financial impact on companies-clients). Another reason why SAFe happens to be a framework of choice by large consulting companies, is that the framework itself does not require any major changes to a traditional organization design and as such, does not put large consultancy representatives, in an uncomfortable position of purists-radicals that have to challenge their clients’ ways of working (not too much status quo challenging ensures a longer and more profitable engagement).
LeSS does not have much recognition by large consultancies for the following three suspected reasons: (1) organizational design of large consultancies [themselves] is inconsistent with LeSS teaching and therefore, there are no internal success stories to share with clients; 2) consultants don’t have enough LeSS adoption knowledge to comfortably support their clients with LeSS adoptions; 3) risk aversion, as stated above (fear to challenge radically, and therefore lose business), makes LeSS a bad choice.
Today, almost any workflow management or bug tracking tool (e.g. VersionOne, Rally, VSTS/TFS, Jira, etc) is very closely aligned (some, also are strategically partnered) with SAFe. This makes SAFe adoption especially convenient, since practically any large company today has one (sometimes, multiple) of the above mentioned tools in its arsenal, and considers them as a big part of agile transformation journey. Practically, every tool that has the word *agile* in its name, also has a module/layer(s) that could be easily mapped (configured) to a multi-layered structure of SAFe. This gives a sense of comfort to a company, about its own ‘agility fitness’, since now a company can conveniently fit its workload and organizational structure into a tool and framework. This also creates great opportunities for SAFe and tooling companies to cross-sell and cross-promote each other.
LeSS is completely silent on what tools should be used to visualize work. There are no strategic partnerships with tooling companies. The only recommendation LeSS gives that whatever tooling is used, it should be very flat (simple) and easy to operate (e.g. no more than three levels of work decomposition; no commingling product and spring backlogs, etc).
SAFe involves many people, teams and departments. One of the main reasons why so many organizations are comfortable to adopt SAFe is that it does not really challenge, a status quo of first-, mid-level management and traditional organizational design. In one of his early-days webinars, recorded with VersionOne, Dean Leffingwell clearly stated: “…We don’t typically mess with your organizational structure because that is a pretty big deal…”. In SAFe, many traditional organizational layers (programs, portfolios) and roles (solutions architects, enterprise architects, various types of managers (project, program, portfolio, release, solutions, etc) have a place to exist. SAFe provides a very safe environment for traditional managers: everyone has a role and some responsibilities. Notably, on a SAFe diagram, agile teams illustrated at the very the bottom of SAFe overall picture, with many management layers coming over the top.
LeSS product group consists of 2-8 teams (maximum 70 developers, assuming a maximum recommended number of developers in Scrum is nine), with a minimal number of additional roles involved (Product Owner, Scrum Masters, users, stakeholders). LeSS Huge adoptions, with hundreds to thousands of people involved (they are gradual and take years) have a very minimal add-on to organizational complexity, in the form of [product] Requirement Areas, prioritized by Area Product Owners.
LeSS explicitly challenges traditional organizational design and calls for organization DE-scaling (flattening), as means of scaling agility and Scrum. In LeSS, a Team of developers is the key organizational building block. In LeSS, middle and first-line managers are not required. Managers in LeSS, if remain, radically change their focus from individuals and work-assignment management to capability-building and teams’ enablement. In LeSS, programs and portfolios cease to exist. LeSS is Scrum, applied to many teams, working together on one large product, and therefore, LeSS is best to use for product centric development, where a product centricity is really important (note: in LeSS a product could be a combination of software and hardware).
SAFe includes various types of teams: agile teams, Kanban teams, XP teams and System teams, DevOps teams, architecture teams, etc. In practice, these are single-functional specialty teams and component teams that are inherited from traditional organizational design and, therefore, still require a lot of additional coordination, integration of work and dependency management. As such, there is a need for release managers (e.g. Release Train Engineers), Solutions Architects and other types of coordination managers – people that are responsible for bringing everything together.
In LeSS, all coordination between teams (each team is a cross-functional feature team) is done by teams, themselves (not even Scrum Masters). Each team in LeSS is fully capable to deliver a product-centric backlog item (feature), from start to finish. In LeSS, teams are responsible for coordination and integration. Dependencies in LeSS are viewed, as something highly undesirable (hard, asynchronous dependencies are viewed as a sign of organizational weakness), internal contracts (“us vs. you”) and unwillingness to work closely together – something that must be minimized, in favor of close collaboration among teams. In LeSS, a lot of emphasis is made on communication through code, mentorship, community learning and other lateral (horizontal) knowledge-sharing techniques.
In SAFe, there are many different types of backlogs: team (private) backlogs, program backlogs, solution backlogs, portfolio backlogs etc. – each representing a respective organizational structure (people that are compartmentalized/departmentalized in their reporting verticals, ways of working and communication) and aligned with a specific team type, at various layers of the framework (e.g. , essential, program, solution, portfolio). In order to keep all backlogs in sync and relevant, there is a lot of coordination and management required.
In LeSS, there is only one backlog: Product Backlog – shared by all (2-8) teams that work on the same, product, while servicing the same Product Owner. As stated above, there are no programs or portfolios in LeSS – these traditional layers of WBS management are discontinued, in favor of a widened product definition. There is a lot of direct coordination between teams in LeSS (intra- and cross-teams), by team members.
SAFe Product Owner is a team member, who is responsible for defining/detailing and prioritizing team backlog items (frequently, component items). SAFe PO can support, at most, 1 to 2 teams because focusing too much on details and tactical implementation requires a lot of time. In practice, SAFe PO is often an ex-business analyst, ex-project manager or a tech-lead – something that works well, because majority of teams in SAFe are [technical] component teams.
LeSS Product Owner is conceptually the same as in one-team Scrum. However, in LeSS, PO focuses on an overall strategy and ensures maximum return on investment (ROI) in the product. LeSS PO puts all of his/her focus on prioritization, whereas clarification, as much as possible, flows through users/stakeholders (see below). In practice, LeSS PO is usually a product manager or a head of business operations (e.g. head of marketing, sales) – for external product development OR an experienced, hands-on individual from one of the major user departments, who is interested in taking on the role and is political savvy – for internal product development.
In SAFe, it is less likely that business people will interact directly with developers, because there are specific, dedicated roles for such interaction. For example, Epic Owners (Portfolio level business people) interact directly with ART (Agile Release Team) / RTE (Release Train Engineers) and Solution Train / STE (Solution Train Engineers). Similarly, Business Owners (Essential SAFe level) that are responsible for governance and compliance, also interact with ART.
In LeSS, users and stakeholders are brought in direct contact with teams, and this is clearly defined in LeSS organizational design and rules of engagement, defined during initial (preparatory) phase of LeSS adoption (up to 2 months, prior to sprinting). For the most part, all clarifications and details about product backlog items flow to teams directly from users and stakeholders. In LeSS, there are no individuals or teams that are responsible for architecture only, solutions only or releases only – all these responsibilities reside within teams of LeSS Product Group, where all teams work on features, in a customer centric way.
In SAFe, the System Team is responsible for development and maintenance of the toolchain that supports the Continuous Delivery Pipeline. It is also responsible for integration of code, produced by delivery (agile) teams. ART (Agile Release Team), spearheaded by RTE (Release Train Engineer) – responsible for releases.
In LeSS, teams (2-8 teams in LeSS Product Group) share the same Definition of Done (DoD) and are responsible for their own integration and production deployment. Teams make take turns, from sprint to sprint, in leading these activities, while closely coordinating with other teams and cross-pollinating each other with knowledge on how to do it successfully. There are no full-time dedicated teams to handle these special activities only. If there is any work that teams are not able to complete by Sprint-end, it is qualified as ‘Undone’ department work (highly undesirable) and is considered as an organizational impediment.
Usually, SAFe is the framework of choice, when an organization is not ready to make any major significant changes and where the following organizational facets are considered “untouchable”: a status quo of mid-level management, traditional budgeting, traditional portfolio structures (projects, programs), traditional HR norms and policies. SAFe adoptions are typically spearheaded by traditional groups, such as PMO, CDO or a center of excellence. People that are in charge of action are best described by Larman’s Law or Organizational Behavior # 4 – individuals that have fast-tracked themselves into agile experts. Adoption of SAFe is a very effective way to provide role safety to many traditional roles, that by minor updates to their titles will remain involved with the effort.
LeSS adoptions have chance to succeed in environments, where there is a real urgency to change, and where there is a strong need to bring real, tangible business value to real customers and users soon. Usually, people that drive successful LeSS adoptions come from hands-on product development (technology) or from business operations (e.g. sales, marketing). The should be also supported by by seasoned organizational design consultants, with years of experience of serving multiple organizations. Prior to proceeding with LeSS, senior management needs to be educated on organizational design implications of LeSS and it must provide an informed consent (explicit agreement to provide support in action, not just in-spirit).
“All models are wrong, but some are useful“. – George Fox.
It is probably impractical to debate which framework is best to use. In order to decide on the best choice, we need to understand what strategic goals and objectives an organization wants to achieve:
SAFe can provide a top-down mandatory structure and control over an existing organizational disarray, without challenging significantly traditional roles, responsibilities, hierarchies (reporting and WBS) processes and tools. Most likely, organizational complexity, will not be simplified with SAFe, but it might be worth it if benefits of order out-weight expected complexity. If an organization wants to do a major, large-scale roll out, involving thousands of people at once, and prefers a well-structured, change management process, based on play books, templates, prescriptive execution and compliance, then SAFe could be a good choice.
LeSS, just like Scrum, is based on empirical process control and continuous inspection, adaptation and experimentation. If LeSS is adopted, with its minimal rules and guidelines, it can provide an array of deep systemic improvements but not every company might be ready to accept them. LeSS would also require a significant change to a sphere of control by traditional roles, responsibilities, hierarchies, processes and tools (LeSS adoption principle #1). LeSS will challenge a status quo of some people, and therefore, success of LeSS adoption is strongly dependent on support by senior management (LeSS adoption principle #2) that must ensure job safety and career opportunities for impacted people. LeSS adoptions will not be fruitful if they are mandatory and based on compliance. Instead, LeSS adoptions require a genuine commitment and are based on volunteering (LeSS adoption principle #3). For example, the oldest, biggest and most active global LeSS (NYC) Meetup is based on the principle of volunettering. One of the most powerful tools (also an effective coaching tool) that is used in LeSS, is System Thinking – something that helps understand various aspects of organizational design (e.g. local optimization) that may not be otherwise obvious.
- SAFE: MARKET SHARE INCREASE. RAPID GROWTH. WHAT IS THE RECIPE?
- Candid, Unscripted Conversation About SAFe, with Roman PichlerJuly 8, 2021
- Candid, Unscripted Conversation About SAFe, with Bob Schatz (CST)July 5, 2021
- Candid, Unscripted Conversation About SAFe, with Mike CohnJune 30, 2021
- Candid, Unscripted Conversation About SAFe, with Tom Mellor (CST)
- Ability to use Velocity as a metric
- Degree, to which combined velocity from multiple teams can be used as a measurement
- Effectiveness of team’s estimation techniques
- Likelihood that Customer/Product-centric development is valued, by business and the whole organization
- Dependency on traditional organizational structure and protection of a status quo of component managers
- Dependency on complex frameworks, processes
- Degree of measurement dysfunction
As well as a few helpful proxy-variables to ‘glue’ the model together.
This writing is way past overdue. I have been putting this off for, at least, a few years. But it is better later than never😊.
About the Programs
Both of them: CEC and CTC – have been developed by the Scrum Alliance volunteers. The evolutionary path of both programs has been pretty long and full of experiments.
CEC came first. Some years ago (more than 10), what is called today as Certified Enterprise Coach (CEC), used to be called Certified Scrum Coach (CSC). At one point, the decision was made to rename CSC into CEC, for a variety of reasons, with one (big factor) being that CEC was more descriptive of a coaching focus, since at this level, a person coached not only Scrum but much deeper and broader (organization, enterprise).
But it was not just changing the acronym, it was also a complete redesign of the program. What used to be a binary pass/fail outcome for an applicant (you submit, you wait for a while, you get a verdict), has evolved into a high-transparency, enriched with short feedback loops, multi-stage, iterative, full of learning and self-discovery, process. Some time, after CEC has been redesigned (around 2014), there also came CTC (about a year later, or so). The main reason for creating the CTC, as a separate program/credential (NB: I was one of the co-creators but more about this below), was that (multi-) team-level coaches, had somewhere different focus than enterprise coaches: CTCs are were focused on multiple teams, CECs were focused on the whole enterprise.
Some Most Common Misconceptions about CEC and CTC
- “…there is no degree or accepted global accreditation that provides comfort around the skills and experience needed for the job…“. Not true. Howard Sublett, Co-CEO/Chief Product Owner of Scrum Alliance explains why this is not an accurate assumption, explaining how CEC and CTC have evolved, over years.
- CEC and CTC are just two certification badges that a person get, by simply attending a course and then passing an exam. Not true. Both programs are supported by a comprehensive application process that requires a wide spectrum of qualitative accomplishments: well documented coaching experience, formal and informal coaching education, mentoring experience (mentoring others and being mentored), long agile community engagement and contribution, deep knowledge of coaching tools, techniques and frameworks; as well as, qualitative “know-how”: deep agile knowledge, coaching competencies and mindset. In a way, both CEC and CTC, remind a dissertation, written by a person who tries to capitalize of a long agile learning journey. CEC and CTC can be graphically visualized as these little blue figures, on the left side, of this image.
- CEC and CTC – is a guarantee to easily secure a job with a significantly higher pay. Not true. Although in some countries/by some companies, a lot of emphasis is made on certifications, there is no statistical data to support that CEC or CTC holders have a ‘golden key’ to companies’ doors, while making significantly more money than non-holders.
- Once a person obtains CEC or CTC, their learning journey is over. Not true. In fact, the opposite is true: the best part of the journey begins after a person earns the credential. Many people, consider getting the CEC-CTC credential as a tremendous boost to a personal ego – an ego to learn and further advance, in order to be ahead of others and continue elevating a coaching bar.
- Since CEC and CTC application process does not involve a multiple choice test, it is prone to errors and personal bias, by application reviewers. Not true. Although, a personal perception factor is always present, whenever one human assesses another human, both programs, are very carefully designed to minimize/avoid subjectivity, bias and anchorage, as much as possible (multiple reviewers, calibrated score cards, recusing from review of colleagues/acquaintances etc.). Check out the above links for details of the process.
My Personal Journey
My journey has begun in 2010, about a year after I received my CSP credential. I applied for Certified Scrum Coach (CSC) – the old version of CEC. I was so confident that I would pass it with flying colors… Oh boy, was I wrong? I did not succeed. Looking at back now, I realize that the reason was two-fold:
- Back then, the process was not too supportive of me, as an applicant. Although I was sure that my reviewers were qualified people (I got to know them in person only years later), the whole process was not transparent and not conducive of iterative learning. For me, personally, it was not a learning journey. I had to work on my application in a complete silo, without having any idea if I was on a right track, without getting any guidance along the way. Then, I summited, and had to wait, for about 3 months, before I got the result back: not ready.
- But to be fair, years later, after becoming CEC, when I reviewed my own, old CSC application, I thought: what a mess it was! I would not pass myself either: style of writing, clarity of thoughts, ability to present content – they were not up to par with what I would consider today as an enterprise-level coach. After not passing the original CS, I took the feedback from my reviewers at its face value (not without a disappointment, of course) and decided to let some time go by, before resubmitting. I wanted to give myself a good chance to advance in my own learning and experience, at my own pace, without having the urge to re-apply fast. Luckily, I did not feel that I needed a credential to find an employer or a client. My other hope was that, eventually, the application process would improve, before I applied again.
Four (4), long years went by…
…Many more coaching gigs, many more read books and white papers, attended conferences, retreats and public events, tons of professional networking. I mentored others and was mentored by more seasoned people. I coached, as a part of my paid job and if someone just needed personal help – I would coach for free, one-on-one.
As an agile coach, I also came to terms with the fact that I am an organizational and team design agent, someone who needs to strive towards changing the ‘world of work’ (also, happens to be the motto of Scrum Alliance), not just coach for the sake of coaching.
In the early part of 2014 I learned that the old CSC program had been redesigned (the effort, spearheaded by Pete Behrens and Roger Brown, who later became my greatest mentors) into the new CEC program and a beta-group of coaches-aspirants-volunteers was required to become the first “explorers” to go through the experiment. Being a huge fan of experiments and having a gut feeling that the time was right, I volunteered immediately. As I recall it now, I was probably the only “scarred” applicant – someone who had experience with the old CSC program…
To make a long story short…it took me close to five months to go through the program. The hot summer of 2014 – it was me, spending many hours each week, reading, researching, writing and re-writing. From time to time, I would get a feedback or request for clarification from my reviewers. I would then jump on it, research it, study it and take another stab at the google document (by then, the application process was put online). I loved being a Guinea pig 😊. The amount of additional learning and self-discovery that I made, while working on my own application was just immense. It also felt, as if I almost relived all of my professional experience as a coach (by then I already had many years of coaching behind my belt). Along the way, I collaborated with other applicants, sharing our experiences and bouncing around ideas (of course, everyone’s application was filled out independently).
In October of 2014, I got notified by Scrum Alliance that I was granted the CEC credential. This was one of the most exciting moments in my professional career! It was truly a huge milestone for me. In fact, I was the very first beta-group applicant that made it through the newly redesigned CEC program. It was a triumph.
Benefits After Achieving the Goal (becoming CEC-CTC)
Although CEC never became an automatic “golden key” door-opener for me, earning the credential certainly gave me additional self-confidence and boosted my ego. I recall being asked by my clients and interviewers what Scrum Alliance *certified* enterprise coach meant and how it was different from “un”-certified. Those moments, were my best opportunities to talk about my professional journey and valuable assets that I bring to the table, as CEC. Some of my more open-minded clients admitted that what they considered as a ‘coach’ up until then, was not even near what a coach is/does.
Becoming CEC has put me in small group of elite-guide-level professionals with privileged access. I gained the privilege of joining closed discussion forums with Agile Manifesto co-signers and Scrum co-creators. Seeing them exchange and engage in hot debates, as well as being able to freely engage in any of those discussions on my own, was such a great asset. At times, just following a thread about Scrum, Kanban, organizational dynamics, scaling, product management, technical excellence, classroom dynamics, business aspect of public training – would enrich my personal knowledge by a factor.
Helping Scrum Alliance to Further Raise the Coaching Bar
Some time, after earning my CEC, I learned that the group of volunteers-CECs was pulled together to create the new Scrum Alliance certification-credential: Certified Team Coach (CTC). I volunteered myself and joined the group (Roger Brown was the leader). The purpose of our effort was to delineate between the two types of a coaching focus: enterprise and (multi-)team. After multiple years of research and discovery, it has become apparent that some coaches wish to focus on teams’ dynamics (e.g. multi-team PBR, multi-team Sprint Planning, Overall Retrospective), whereas others – on enterprise dynamics (HR policies, budgeting-finance, location strategies, vendor management, etc.). Please note, the above are not mutually exclusive.
Rightfully, some of the quantitative (and to some degree, qualitative) expectations from CEC were higher than those of CTC. However, just like the CEC, the CTC program was designed to be a very rigorous and challenging selection process, to identify guide-level, senior coaches.
In January of 2018, I also decided to gain my own CTC credential, since there were many instances in my career, when I had to coach at multi-team level. It also did not feel right for me NOT to have the credential, while being involved in its creation😊.
Today, I run my own mentoring program for people that wish to pursue the CTC or CEC credential. My focus is three-fold: advanced system thinking → improved coaching capabilities → application success.
Other Important Milestones during My CEC Journey
One of the biggest aspirations throughout my entire coaching career was becoming a better system thinker-modeler – a person who could see and assess the whole organizational (eco-)system, not just its individual parts. In enterprise-wide and multi-team settings this skill is a must, at least in my opinion.
Right around the time when l did not succeed with my initial CSC application, I zoomed my focus onto lean and agile product development, at scale and in multi-site settings – something that most of my clients had interest in and trouble with. My attention was drawn to a series of books, written by Craig Larman and Bas Vodde (both later becoming my other great mentors), where they have covered many guides and experiments that I found very applicable in my work. Since then, I have applied much of my learning (today, a.k.a. Large Scale Scrum or LeSS), while coaching individuals, teams and organizations. I find LeSS education a significant asset to my own coaching journey (during and post- receiving the CEC and CTC credentials). Today, I am one of a few (worldwide) Certified Large Scale Scrum Trainers (CLT) – another very unique and valuable milestone in my career that is also very complimentary to being CEC-CTC.
The above is originally posted on my blog.
More about me and my work.
Additional recommended assets:
- 05/05 – LESS TALKS: Dave Snowden: Answering Tough Questions (Q&A)
- 02/27 – LESS TALKS: Q & A on “The Spotify “Model”: Don’t Simply Copy-Paste”, with Evan Campbell
- SAFe: Market Share Increase. Rapid Growth. What is the recipe? (please, make sure to reference to large collection of references at the bottom of this page)
- LeSS NYC meetup
OKRs (Objectives & Key Results) – they could be your best friend or your worst enemy.
Albert Einstein once wrote on a blackboard: “Not everything that counts can be counted, and not everything that can be counted counts. [source]” This usually applies to things that people like to measure. But what does this have to do with OKRs?
OKR – is a way to measure how your initially set [strategic] objectives translate into results, at various organizational levels. With OKRs, there also come numbers, metrics, calculations, RAGs, etc.
What would OKRs look like for a traditional organization (complex structure, many reporting layers)? – this is not the scope of this writing. Frankly, there is a plenty written on this topic. Though, one thing is worth mentioning is that, as “Os” roll down from top (executive level) to bottom (individuals), and as “KRs” roll back up, through multiple organizational layers (managers, teams, departments), accuracy and relevance decrease, whereas variability/variance/inaccuracy and system gaming risks increase.
But what would OKRs look like for an organization that was trying to get away from a traditional structure and wanted to become more agile (adaptive)?
First, we need to define what it means, to be ‘more agile‘? What is the most important factor that defines organizational agility? That is right!!! – organizational design/structure (culture, norms, values etc, come much later). When an organization becomes more agile, what we typically see, is reduction in a volume of processes, artifacts and single-specialist roles – people that are responsible for single, asynchronous tasks. This is sometimes referred to as organizational ‘de-scaling’ (flattening).
By the way, and just to correct frequent misunderstanding of the word means: agile – does not mean ‘faster’, ‘cheaper’, ‘more efficient’ etc. Of course, the ladder may come, as a secondary or even tertiary result of becoming more agile and responsive (e.g. a company, responds to market/clients needs than its competitors –> this leads to increased sales –> increased profits –> better economics) but this should not be the main set goal of agile transformation efforts.
Even at a large investment bank, with its traditional complex structure: multiple reporting levels, many applications (with application owners), many departments (with department managers), many sites (with sites coordinators) – in order to improve agility in e.g. product development, we need to de-scale organizational layers and bring closer together: real customers (or internal users) with development teams (GEMBA). Why?
Because, in a flatter organization, where customers and executive management set objectives, and development teams are expected to produce initial (low-level) key results, there would be fewer errors and omissions, due to a lower number of translation layers.
For example, a good business objective could be to increase an annual revenue by 5 million dollars. This could translate into a requirement of having an X-number of new customer-centric features that, if delivered by a certain date, would help generating more revenue for a company (as per forecasting by its market analysts). These X-number of features could now be entered into a product backlog (owned by a single product owner and multiple teams), refined and delivered incrementally, over time, sprint by sprint. The lowest level key-result, in this case, could be meeting teams’ definition of done (DoD) and delivering a potentially shippable product increment (PSPI) at the end of every sprint. (Please note that ALL teams responsible in product development would be sharing the same objective. By the same token, results would be measured for ALL teams – working together.) The next level key-result, for example, could be delivering some large feature (or a percentage of an initially requested feature), by some arbitrary interim date.
The intention here would be to have as few translation layers as possible, while cascading up results from-low-to-high, to avoid errors and omissions that could be introduced during translation. Of course, this would only be possible if an organizational design inside, around and beyond teams, was simple (de-scaled).
Word of caution:
These days, ‘agile’ is one of the mostly overloaded and misused terms.
Agile has become one of the most popular areas, where transaction takes place and business is generated (recruiting firms, consultancies, tooling companies). The are many, commercially successful, complex frameworks and tooling solutions (with the word “agile” in them) that are marketed, as “unified & comprehensive solutions”. This constitutes, what is sometimes referred to, as a ‘Triple Taxation‘ – and organizations become a victim of it. This is also a part of a bigger, industry wide “agile” framework-tooling problem. Essentially, these approaches, redefine the “old world” with new terminology: projects / programs / portfolios become agile projects / programs / portfolios, PMO becomes agile PMO, BAs become agile BAs, and so on…
With electronic tools that are in close partnership with heavy, RUP-like frameworks (e.g. JIRA + SAFe), neither one of which are focused on improving organizational design, OKRs become just another illusionary improvement.
Companies should avoid falling into the trap described above. Aligning low-level OKRs (e.g. team project) to higher-level OKRs (e.g. portfolio), by merely, “mapping” numbers that are generated at single-team level (e.g. velocity or number of items delivered per sprint) through an “agile tool”, and processing them through multiple layers of projects, programs, portfolios, epics, themes, etc – this approach is prone to *unintentional errors and intentional system gaming*, and will ultimately lead undesirable outcomes, because fundamental problems, such as an organizational structure and its internal communication channels, are not being addressed. Such “cascading” of OKRs may look nicely on reports but because it represents a system that is flawed, it would not be valuable.
OKRs could be a great communication tool and means of providing transparency and managing expectations. But OKRs are only as good as processes and dynamics they represent, with the ladder being fully dependent on an organizational (system) design.
In order for OKRs to be reliable and omissions-resistant, they need to be as simple as possible, and have very few translation layers between the highest-level “O” and lowest-level “KR”. This is an organizational design question.