Category Archives: Transformation

The Agile Enterprise Coach

Coach

When your organization chooses to transition to more agile and lean ways of working you quickly discover that this effort needs to address all aspects of your organization, not just your solution delivery teams.  Many transformation efforts invest in agile team coaches, which is a very good thing to do, but will often shortchange other areas of coaching in the belief that they’ll figure it out on their own.  It may work out that way, but even when it does this is an expensive, slow, and error-prone approach.  In our experience it’s far better to get help from an experienced Enterprise Coach.

An Enterprise Coach coaches “beyond the team” to help senior managers and leaders to understand and adopt an agile and lean mindset.  As you will soon see, this requires a similar yet different skill set than what is required for team coaching. In this blog we work through three key concepts:

  1. The types of agile coaches
  2. Skills of an Enterprise Coach
  3. Supporting other coaches

Types of Agile Coaches

As you see in the following diagram we like to distinguish between several types of coaches:

  1. Team coach. As the name suggests, a Team Coach coaches solution delivery teams through improvement efforts. The focus is usually on improving the performance of individual teams. This is the most common type of coach, and our guess is that 95% or more of agile coaches fall into this category.
  2. Specialized coach. A “specialized coach” is someone who focuses on non-solution delivery aspects of your organization.  They are typically senior team coaches who have a deep background in one or more process blades.  For example, you may have a specialized coach focused on Enterprise Architecture and Reuse Engineering for example; or one that is focused on Finance, Portfolio Management, and Control; or one that is focused on Enterprise Architecture and Data Management.  The people who are working in non-solution delivery areas need coaching just like people on solution delivery teams do.  More on this in a future blog posting.
  3. Enterprise coach.  Sometimes called Transformation Coaches or Executive Coaches, these coaches work with senior and executive management to help them to understand new ways of working and organizing themselves.  Enterprise coaches will often focus on executive coaching, of which there are three types: IT executive coaching, business executive coaching and manager coaching.  All are equally vital to your agile transformation and continuous improvement efforts.  An area often ignored in coaching is the role of managers as agile leaders and coaches of your agile teams.  Executive Coaches can help guide managers from a style of “managing” to leadership.  Enterprise Coaches often find that they also need to take on the role of a Specialized Coach too. A key responsibility of an Enterprise Coach is to support the other coaches when they need help. The focus of this blog is on Enterprise Coaches.

Agile Communities of Excellence

 

Skills of An Enterprise Coach

The skills of an Enterprise Coach include:

  1. Coaching skills. First and foremost, enterprise coaches are coaches.  They require all the people, collaboration, and mentoring skills of other agile coaches.  They should have many years of hands-on coaching of individual agile and lean teams in many types of situations, from the simple to very complex.
  2. Domain knowledge. An enterprise coach must have knowledge of the domain that they are working in.  There are unique challenges in financial organizations that you don’t see in automotive companies, similarly pharmaceutical companies are different from retailers, and so on.  Yes, it is possible for Enterprise Coaches to quickly learn the fundamentals of a new domain, but you’ll find that in the beginning the executives that the Enterprise Coach is helping to learn agile will have to help them learn how the business runs.
  3. Understanding of how IT works. Enterprise Coaches need to understand how a Disciplined Agile IT (DAIT) department works so that they can coach IT executives effectively.  Enterprise Coaches help IT groups such as Enterprise Architecture or PMOs to understand how they need to adapt to effectively support Agile teams.
  4. Understanding of how to apply agility at the enterprise level.  Similarly, Enterprise Coaches should understand how a Disciplined Agile Enterprise (DAE) works.  Enterprise Coaches should be experiences with modern agile practices related to non-IT functions such as human resources (also called People Management or People Operations), finance, and control.  Coaches bring expertise on practices in these areas such as modern compensation and reward systems, agile budgeting, rolling wave planning, agile procurement, and agile marketing.
  5. Experience and knowledge of the various IT domains. A broad understanding of IT is critical, and better yet deep knowledge of several of the IT process blades so that someone in the Enterprise Coach role can guide any specialized coaches or step into that role themselves.  This is important because people working in areas such as Data Management, Release Management, or IT Governance often believe that they are “special” and agile can’t possibly apply to them (it’s only for programmers after all).  Without a good understanding of these areas an Enterprise Coach will struggle to help the IT leaders that they are coaching to counteract these arguments.
  6. Transformation and improvement coaching.  Enterprise Coaches should understand, and be experienced at, lean approaches to organizational transformation and improvement, often referred to as Organizational Change Management (OCM).   Traditional approaches to OCM will not work.
  7. Ability to support team and specialized coaches.  See below.

Supporting Other Coaches

Enterprise Coaches support other coaches in several important ways:

  1. Transformation/improvement visioning.  Enterprise Coaches help executives to understand modern agile and lean practices used by successful agile organziations and help to create a roadmap for moving from their current to target state.
  2. Organizational structural change.  Experienced coaches can help organizations to create organizational structure to be conducive to the evolution of high performance teams.  This would include design of cross-functional, stable teams aligned to value streams or lines of business (LOBs).  They can also help design workspaces for effective collaboration between team members, and help reduce the need for separate meeting rooms.
  3. Organizational coordination.  One of the most important things that an Enterprise Coach does is help team coaches to overcome challenges collaborating with other, not-so-agile teams.  The reality is that 96% of agile teams must collaborate with one or more teams or groups within their organization at some point, 96%!  Some of those teams may very well be struggling with working in an agile manner and may even be opposed to it.  These sorts of challenges are often beyond the remit of a team coach to address, so when they occur the team coach will often ask for help from an Enterprise Coach who does have the relationships with the right people to smooth over such problems.  Enterprise Coaches can also provide advice for effective collaboration strategies with vendors and offshore teams.
  4. Resources. Enterprise Coaches will sometimes help other coaches to obtain the resources – typically time and money – required to coach the teams that they’re working with.
  5. Communication.  The Enterprise Coach will actively share the overall vision of your improvement efforts, the current status, and any organizational challenges that you’re running into with the other members of the CoE.  They will of course be actively working with the people responsible for communicating this information to the rest of the organization as well.
  6. Coordination. Enterprise Coaches will often coordinate the efforts of the various team coaches in your organization to ensure that they’re working together effectively.
  7. Mentoring.  Enterprise Coaches, being senior, will often be coaching the team and specialist coaches (all the while learning themselves).

There is of course a lot more to agile coaching that what is covered in this short blog.  Our goal with this writing was to overview the role of Enterprise Coach and show how it fits into the overall scheme of things.

Nine Reasons to Choose DAD over Scrum

Why?

A common question that we hear a lot is “Why choose Disciplined Agile Delivery (DAD) over Scrum?”, so we’ve written this blog to summarize our response.  The short answer is that DAD addresses the myriad of issues that Scrum chooses to leave to you.  To see what we mean, the official Scrum Guide is 23 pages compared to the 500 pages of the original Disciplined Agile Delivery (DAD) book – DAD clearly goes into greater detail than Scrum, detail that your organization will need to spend a lot of time and money figuring out on your own with Scrum as your process base.  We believe you can do a lot better than that.

At a high-level, the primary reason to adopt DAD over Scrum is that you will greatly increase the chance that your process improvement efforts will be successful, and you will do so in such a way that it will be quicker and less expensive in the long run.  This is because DAD takes a holistic, context-sensitive approach to solution delivery as opposed to Scrum’s prescriptive and narrow approach.  Let’s explore the many reasons why you should adopt DAD over Scrum:

  1. DAD extends Scrum
  2. DAD addresses all aspects of agile solution delivery
  3. DAD focuses on solution delivery, not just software delivery
  4. DAD explicitly supports a full delivery lifecycle
  5. DAD provides more options than just Scrum
  6. DAD provides explicit tailoring advice
  7. DAD reflects the realities of enterprise agile
  8. DAD is scalable and provides real advice for doing so
  9. DAD certification is respectable

 

Reason #1: DAD Extends Scrum

The question “Why choose DAD over Scrum” doesn’t make a lot of sense to us because DAD extends Scrum to address all of the process issues that Scrum leaves up to you.  As we describe below, DAD addresses all aspects of agile (not just management and collaboration), it explicitly supports a full delivery lifecycle (not just Construction), and it goes beyond software development to address solution delivery.  Scrum is important, and it encompasses a lot of great ideas, but in practice it proves to be a very small part of the overall agile picture. We’d like to say that it’s the tip of the iceberg, but the tip of the tip of the iceberg would be a lot closer to the mark.

For more thoughts on this topic, see the blog Disciplined Agile Extends Scrum.

 

Reason #2: DAD Addresses All Aspects of Agile Solution Delivery

Right Sizing Scrum

The focus of Scrum is on change management and collaboration, important things but not actually sufficient for software development.  Scrum purposefully does not address architecture, programming, design, testing, governance, analysis, documentation, and many other important issues. Scrum suggests that you start with it as a core and add in what you need, which is a boatload of time-consuming work in practice because Scrum simply doesn’t address the full range of issues that you actually face.  It will take you months, and sometimes years, of effort to evolve to a right-sized process that works for your team.  Worse yet, Scrum will require more coaching (which is expensive), and more experimentation (important, but expensive and time consuming so you to be smart about it) than if you were to start with a more robust strategy such as DAD.

As you would expect, DAD takes a more intelligent approach to process right-sizing than Scrum does. DAD suggests that you start with something a lot closer to what you actually need, thereby saving a lot of time and money.  Why should you have to figure out how to take a streamlined approach to solution delivery when thousands of other organizations have already done that?  Instead, why not leverage their hard-earned learnings and start with something more robust?  DAD encapsulated those hard-earned learnings.

Right Sizing Disciplined Agile Delivery

Being empirical, DAD reflects our observations of what teams actually do in practice to succeed at solution delivery.  DAD is a hybrid framework that adopts strategies from a wide range of sources, including Scrum, XP, Agile Modelling, Kanban, Unified Process, and many others.  More importantly DAD does the “process heavy lifting” that Scrum doesn’t do and puts these things into context, showing you how everything fits together, giving you choices, and addressing important issues such as what to do when and to what extent to do it.  In short, DAD doesn’t leave you hanging the way that Scrum does. We like to say that DAD takes the mystery out of agile solution delivery.

For more thoughts on this, see There is More to Agile Transformations than Implementing Scrum.

 

Reason #3: DAD Focuses on Solution Delivery, Not Just Software Delivery

The fundamental observation is that as IT professionals we do far more than just develop software.  Yes, software is clearly important, but in addressing the needs of our stakeholders we will often:

  • Develop high-quality software
  • Provide new or upgraded hardware
  • Change the business/operational processes which stakeholders follow
  • Change the organizational structure in which our stakeholders work
  • Update supporting documentation

DAD shows how to do all of these things in a streamlined manner, going beyond the “potentially shippable software” mantra of Scrum to the more robust concept of producing consumable solutions.  Our experience is that the focus on potentially shippable software makes it harder for teams to see the bigger picture, to work in an enterprise aware manner that results in the development of high-quality solutions that delight customers and will stand the test of time.

 

Reason #4: DAD Explicitly Supports a Full Delivery Lifecycle

DAD supports the full delivery lifecycle, supporting up to three phases (Inception, Construction, and Transition) where needed (the two project-based lifecycles, the Scrum-based Agile lifecycle and the Kanban-based Lean lifecycle need all three phases whereas the two continuous delivery lifecycles and the lean-startup-based Exploratory lifecycle do not, more on this later).  As you can see in the picture below the DA framework supports a full systems lifecycle that reflects the complete lifecycle from concept (idea) to eventual retirement (decommissioning).

High-level system lifecycle

The following diagram depicts the Scrum lifecycle.  There are a lot of really great ideas here, but this lifecycle clearly isn’t complete.  How do you initiate a Scrum team?  How do you release software into production (or the marketplace)?  The focus here is just on Construction, which is important, but it is not the full picture.

Scrum Construction Lifecycle

 

The following figure overviews DAD’s Scrum-based Agile lifecycle.  As you can see the Scrum Construction lifecycle is at the heart of it but DAD isn’t limited to just what the Scrum folks want to sell you.  Instead DAD takes an approach that is Enterprise Aware in that it covers from beginning to end what solution delivery teams face and it puts the delivery lifecycle into context.

DAD Agile Lifecycle

Note that in the DA framework we choose to use different, more understandable terminology than Scrum does (but feel free to use whatever terms that you like, because DAD isn’t prescriptive), and prefer to depict a more robust version of the backlog than Scrum does (many Scrum adherents now take a similar approach).  The important point is that DAD chooses to explicitly support a full, Scrum-based lifecycle that reflects the realities of enterprise-class solution delivery.  Once again, DAD strives to take the mystery out of agile solution delivery.

 

Reason #5: DAD Provides More Options Than Just Scrum

Because Scrum isn’t the only agile game in town, DAD supports five full delivery lifecycles so as to give teams viable choices.   DAD does this because solution delivery teams face different situations, so one lifecycle will not fit all, reflecting the DA principle Choice is Good.

DAD includes five lifecycles:

  1. Agile (Scrum-based)
  2. Lean (Kanban-based)
  3. Continuous Delivery:Agile
  4. Continuous Delivery: Lean
  5. Exploratory (Lean Startup)

Even when you start with the Scrum-based agile lifecycle you will find that a team eventually evolves away from it, as overviewed in the diagram below.  This happens because agile teams own their process, and part of that ownership is the adoption of continuous improvement strategies such as retrospectives where a team strives to identify potential improvements, communities of practice (CoP) where people explicitly share their learnings, and of course purposeful experimentation where teams discover what works for them in practice.

Agile lifecycles and continuous improvement

It’s important to note that management can become very concerned with the philosophy that solution delivery teams should choose, and then tailor as needed, a lifecycle that reflects the context of the situation that they face (see the principle Context Counts).  Many organizations make the mistake of assuming that teams must follow the same lifecycle so that management may govern them consistently.  In DAD we show that assumption to be false – DAD has the same light-weight risk-based milestones across the five lifecycles (when and if they apply to that lifecycle).  These milestones are summarized in the diagram below.  This enables consistent delivery team governance without taking on the risk (and cost) of inflicting the same processes inappropriately across teams.

 

You may find the blog How Do You Choose Between Software Lifecycles? and the article Lean IT Governance to be interesting reads.

 

Reason #6: DAD Provides Explicit Tailoring Advice

Scrum is prescriptive, giving you one way of doing things.  For example, when it comes to addressing changing requirements Scrum has a single way of doing so called a Product Backlog which is managed by a Product Owner.  This is a great approach which has its advantages and disadvantages.  But, it is only one of several ways to do so.

DAD takes a more robust approach, depicted in the goal diagram for the Address Changing Stakeholder Needs goal.  DAD supports Scrum’s Product/Requirements Backlog strategy, but it also supports the work item pool approach from Kanban, a work item list strategy (which some Scrum adherents choose to adopt, although typically still call it a backlog), and even a formal change management approach (applicable in regulatory environments).  Each of these strategies has advantages and disadvantages and each one of which makes sense in some situations and is a rather bad idea in others.  Instead of prescribing a single strategy, which may make sense for the context that you face or it may not (how would you know when you don’t know what your actual options are?), DAD instead provides you with choices and walks you through what you need to consider when making those choices.  Of course there’s a bit more to it this, you can see that there are several decision points to consider, including how you go about prioritizing work, when you accept changes (if at all), how stakeholders will interact with the team (egads!, Product Owners are only one way to do so and might not be the best way), and how you go about eliciting requirements from stakeholders.

Process goal: Address changing stakeholder needs

DAD organizes agile solution delivery into a collection of process goals, depicted below. Each of the 23 goals are described with a goal diagram such as the one above, walking you through the choices that you have (we believe that Choice is Good).  DAD also puts each practice/strategy into context by indicating its advantages and disadvantages (we also believe that Context Counts) so that you can make intelligent choices.  Not only does this approach get you going in the right direction early on, helping you to avoid costly mistakes, it also helps you to make better decisions in retrospectives and thereby improve your ability to improve your process. Once again, DAD takes the mystery out of agile solution delivery.

DAD Goals

 

Reason #7: DAD Reflects the Realities of Enterprise Agile

Modern enterprises face a myriad of challenges, including having existing non-agile cultures, existing non-agile processes, legacy systems and data sources, and significant technical debt.  Furthermore, your organization likely has multiple teams that range in size, geographic distribution, organizational distribution, and other scaling factors (see DAD is Scalable for a more detailed discussion).  The point is that in enterprise-class settings, very likely the situation that you face right now, that the environment is neither pristine nor ideal.

The implication is that you might not have the luxury of taking a pure agile approach, at least not immediately, but instead you must make do the best you can in the situation that you face.  You must adopt strategies that reflect the context of the situation that you are in, and yes, you should push the boundaries whenever you can.  This is why DAD offers choices, suggesting that you be pragmatic and choose the best strategy that you can right now and be prepared to learn and improve later on.

For example, consider the process goal Address Changing Stakeholder Needs.  When you see a decision point that has an arrow beside the list of choices – in this case Manage Work Items, Accept Changes, and Stakeholder Interaction With Team – that’s an indication that the strategies towards the top of the list are generally more effective than the strategies towards the bottom.  When you first form an agile team a very common problem is that it’s difficult to find someone with the skills and authority to be a Product Owner (PO).  Many teams find that they need to make do with a business analyst at first, which in general isn’t as good as having a PO (as you can see in the goal diagram above) as Scrum prescribes.  It’s not ideal, but it’s the best that you can do right now.  Hopefully, in time, you will be able to grow someone into the PO role and thus work in a more agile manner.  Having said that, having a PO (the Scrum approach) isn’t as effective, generally, as taking an Active Stakeholder Participation approach (an Agile Modelling strategy).

In short, to address the realities of enterprise agile DAD prefers pragmatism over purism – do the best you can given the situation that you face, and be prepared to continuously improve and get better over time.

 

Reason #8: DAD is Scalable and Provides Real Advice For Doing So

Disciplined Agile Delivery (DAD) provides a foundation from which to scale agile strategies both tactically and strategically.  Tactical agility at scale is the application of agile and lean strategies on individual DAD teams.  The aim is to apply agile deeply to address all of the complexities, what we call scaling factors, appropriately.  These scaling factors are summarized in the following diagram.  It is interesting to note that Scrum is geared towards the simple end of these six scales, the ends towards the centre of the radar chart.  Although this is very good advice, why wouldn’t you want to keep things as simple as possible, as numerous agile scaling studies have found (see the November 2016 study for our most recent) agile teams do in fact commonly face situations that aren’t that simple.  Once again, the DA framework prefers pragmatism over purism and provides you with choices to help address these scaling challenges actually faced by agile delivery teams – DAD takes the mystery out of agile solution delivery.

Software Development Tactical Scaling Factors

 

Strategic agility at scale is the application of agile and lean strategies broadly across your entire organization.  As you can see DAD provides a base from which you can extend to implement Disciplined DevOps and Disciplined Agile IT (DAIT).  You can apply Disciplined Agile strategies even wider, across all divisions and teams within your organization to have a truly Disciplined Agile Enterprise (DAE).  Our point is that the DA framework provides advice across the entire spectrum of your organization, providing a real vision for business agility and more importantly concrete advice for getting there.

Scope of Disciplined Agile

 

Reason #9: DAD Certification is Respectable (Because You Need to Actually Earn It)

The Disciplined Agile Certification Program is based on the principles that certification must be earned, it must be meaningful, and must be measurable.  DA certification implements a Shu-Ha-Ri strategy in that it supports four certifications:

  1. Certified Disciplined Agilist (CDA) (Shu) – You must have a comprehensive knowledge of DA strategies and ideas.  This is verified via a comprehensive test.
  2. Certified Disciplined Agile Practitioner (CDAP) (Ha) – You must be a CDA (proven knowledge) plus have at least two years of agile solution delivery.
  3. Certified Disciplined Agile Coach (CDAC) (Ri) – You must be a CDAP (proven knowledge + experience) plus be actively sharing your skills with others through writing, teaching, or coaching.  This giveback does not need to be public, many CDACs write, teach, or coach internally within their own organizations and that’s great with us!
  4. Certified Disciplined Agile Instructor (CDAI) (Ri) – You must be either a CDAP or CDAC (that way you understand and have experience in what you’re teaching) and be able to teach (we ask CDAIs to do a co-teach so that we can see them in action first).

Many Scrum certifications, in particular the Certified ScrumMaster (CSM) designation, are questionable at best.  You’re a “Certified Master” after staying awake in a two-day (sometimes three-day, whoopdie-do) workshop and you’ve passed a test that has 99%+ pass rate?  The vast majority of CSM holders are embarrassed to admit that they have it, which is good to see, but it’s a clear indication that CSM can’t be taken seriously.  In the DA community we’ve chosen to do better.

 

Parting Thoughts

A lot of people want to do Scrum, and rightfully so because there are some great ideas there.  But even when you’re “doing Scrum” the reality is that Scrum is only a very small part of the overall picture.  A very small part.  Once you recognize this to be true, you quickly realize that you’re much better off to adopt a robust framework such as Disciplined Agile so as to help gain lightweight guidance through your process choices.  This will not only increase your chance of success at adopting agile strategies it will also reduce the cost and time required to do so because DAD takes the mystery out of agile solution delivery.

 

Further Reading

Teal is the New Black

Just as your process must be flexible and adaptive, so must your organization. In Reinventing Organizations Frederick Laloux works through the history, and arguably a maturity model, for organizational design. The premise, which is overviewed in the diagram below (you can click on it for a high-res version), is that over time we’re seeing organizations evolve from tribal and often violent structures (Red) through more formalized hierarchical structures (Amber/Orange) to agile approaches (Green/Teal). Today the vast majority of organizations, believed to be 80-90%, are somewhere on the Amber through Green scale.

Laloux Teal Organizations

There are several important observations we’d like to make about Laloux’s organizational maturity scale:

  1. For your organization to support agile it should at least be (mostly) Green, with a participative and values-based culture, or better yet Teal with a truly adaptive and aware strategy (as we’ve been preaching throughout this chapter).
  2. Your organization will start its improvement journey wherever it currently is on the scale. Laloux’s model provides insights into what your current challenges are likely to be and what potential improvements you should consider making.
  3. Teams can still be agile within Orange and Amber organizations, but the organization itself will struggle with agility due to cultural impediments.
  4. It is difficult to jump organizational levels – in other words if your organization is currently Amber then you need to move through Orange, then Green, and finally Teal.
  5. To move between levels you need the both top-down support from leadership as well as bottom-up support from front-line staff – bottom up, “stealth” improvement efforts will fail on their own when organizational antibodies fight back.

You Want to be At Least Green

Why does your organization need to be at least Green or Teal to become agile? Green organizations support a participative culture style that enables collaboration within and between teams. Green organizations explicitly align people around common values, so injecting any missing agile and lean philosophies often proves to be straightforward. Teal organizations go one step further and bring it all together by explicitly recognizing that they are complex adaptive systems (CASs). This provides an environment where agile teams are able to experiment, learn, collaborate, and most importantly thrive as they find new ways to delight their customers.

Improving Horizontally is Much More Realistic

Laloux himself is very clear about the importance of top-down support if you want to become a Teal organization, or frankly just to move up the hierarchy (say from Red to Amber).  In chapter 3 of Reinventing Organizations he states that for an organization to become Teal that it requires the support of both the CEO/founder and the owners of the company.  Our experience is that a third factor is required, the support of the front-line staff (and better yet middle management), for your transformation to be successful.

Laloux believes that it’s much easier for organizations to improve horizontally – become the best Orange or Amber organization that you can be.  In many ways this is much more conducive to a lean continuous improvement strategy than an “agile transformation” strategy.

Your Organization is Probably a Rainbow

It’s attractive to think that your organizational culture is consistent across the entire enterprise, but it is far more likely that you have teams or divisions with differing color ratings according to Laloux’s model. This is because the culture of a team (or division) is greatly influenced by the leader of that team, and leaders vary in their style, and because teams face unique situations – sometimes a red strategy is the most appropriate given what the team faces. Context counts!

Suggested Reading

Agile Adoption and Team Productivity

A common question that people ask is how does the adoption of agile within a team affect its productivity?  The answer to this question will vary by team, but there are several common patterns that we’ve seen over time.  In this blog we explore:

  1. What does increased productivity mean to you?
  2. Agile adoption patterns
  3. What milestones to look out for as a team adopts agile
  4. What you can do to increase your chance of success
  5. How do you know productivity improved?
  6. Agile is about more than productivity improvement

What Does Increased Productivity Mean to You?

Productivity is defines various measures of the efficiency of production, and is calculated as

Value of Output divided by Cost of Input

The implication of this calculation is that there is flexibility in the way that we can increase the productivity of a team:

  • Produce the same output with less cost (i.e. with fewer people).
  • Create greater value with the same number of people.
  • Deliver value incrementally more often, thereby earning value sooner for a longer period of time (this is called decreasing the cost of delay)

Remember that context counts – each team will choose the most appropriate way for them to increase their productivity. Having said that, a common result of a team adopting agile is to incrementally deliver value more often.

Agile Adoption Patterns

The following diagram overviews three common patterns when it comes to productivity change when teams adopt agile.  You’ve likely seen simpler versions of this diagram elsewhere that only show the dark green line, but our experience is that’s only part of the story. You can see in all three cases that the adoption of agile results in an initial productivity loss on a team – this reflects the reality that with any type of change it will take time for a team to learn the new strategy, to identify how it fits into their environment, and to learn the new requisite skills and behaviours. Agile adoption productivity

The three patterns, from least desirable to most desirable, are:

  1. A failed agile adoption (red line). Teams fail to adopt agile for several reasons, usually because the team doesn’t want to adopt agile ways of working, the organization doesn’t properly support their adoption efforts, or the rest of the organization continues to drag them down with traditional ways of working.
  2. A successful agile adoption (green line). Luckily most teams succeed in their agile adoption efforts, and numerous studies have shown a wide range of benefits including faster time to delivery, increased quality, increased stakeholder satisfaction with the delivered solution, and improve team morale to name a few.  Every team is different, but overall on average adopting agile is a positive experience.  You’ll land on this curve when you treat agile adoption as a project, something you do for a few months to help make the team more effective, if you’re successful.
  3. A successful agile adoption evolving into continuous improvement (green dashed line). The most successful teams realize that process improvement isn’t a short-term project but instead is a long-term journey that you undertake.  This is reflected in the dashed line in the diagram below.  You typically start by following a transformation strategy with the team – you get them some initial training, some coaching, help them change their work environment and tooling to be more collaborative.  Then at some point an improvement mindset begins to take hold within the team, one of the fundamental aspects of agility.  The team reflects on a regular basis, identifying potential ways that they can improve and then they experiment with those strategies to see which ones work in practice for them. It’s at this point that they’ve shifted out of the transformation strategy into more of a continuous improvement strategy, which is what enables them to reach higher levels of productivity than what is typically achieved with just a transformation strategy.

What Are the Key Milestones to Look For?

There are three key milestone points on the successful paths that you should watch out for:

  1. Productivity trough (4-8 weeks). With anything new there is always a learning curve, and agile is no exception.  When a team begins to move towards agile their productivity will drop for several reasons: they will likely invest some time taking training, it will take people time to learn new techniques and adopt new ways of working, and it will take time for the team to determine how they will work together following these new agile strategies.  Your productivity levels tend to bottom out after four to eight weeks and then after that will start to improve.  The amount of time varies by team, depending on whether any team members have previous agile experience that they can leverage, how much team members want to change, how effective the training is, and whether you have the support of an experienced and effective coach.
  2. Productivity recovers (2-4 months).  For most teams, the ones who are successful at becoming agile, their productivity levels will recover back to the level they were before they started on their agile improvement journey, within two to four months of starting.  This amount of time depends on the same issues mentioned before.
  3. Improvement culture takes hold (3-6 months). This is the point where the improvement mindset really kicks in and the team starts to explicitly work together to improve the way that they work. This is a reflection that the team is actually “being agile” and not just doing agile ceremonies. Sadly not all teams reach this point and move up onto the dashed green line in the diagram above.  Whether they do so or not is primarily dependent on the willingness of team members to become agile, the quality of the coaching that they receive, and whether your organizational environment allows them to own their process.

How Can You Improve Your Chance of Success?

There are several strategies that you can employ to increase your chance of successfully adopting agile and shifting to a continuous improvement culture within your team:

  1. Invest in training. Get the team started on the right foot with training that not only goes into the fundamental concepts behind agile (“being agile” training) but also works through from beginning to end how agile works in practice (“doing agile” training).  Being agile training is incredibly easy to find, but good “doing agile” training that is comprehensive is much harder to find.  Luckily there are several very good Disciplined Agile training offerings that focus on how to “do agile” in enterprise-class settings.
  2. Hire an experienced coach. A good coach will help your team to avoid common learning pitfalls, and better yet quickly guide you through “learning experiences”, working through with you how to improve the way the team works. Hiring a coach can be a challenge because as we show in Why is it so hard to find qualified coaches? it is possible for anyone, and unfortunately they often do, to claim that they are an agile coach.  Effective coaches have deep experience in what they are coaching as well as skills in the act of coaching itself.  The majority of “agile coaches” tend to to be short on both of these things, and the few coaches that are qualified are in high demand.  There are several Certified Disciplined Agile Partners that you may want to reach out to for Certified Disciplined Agile Coaches (CDACs).
  3. Give the team an “organizational pass.” It’s incredibly difficult for a team to become agile when they are still surrounded by other groups that are actively working in a non-agile manner.  Agile teams need to collaborate with others to achieve their goals (in fact, the 2016 Agility at Scale study found that 96% of people indicated that their team needs to interact with at least one other team).  So, if you want to enable a team to become more agile and improve then you also need to motivate these other teams they rely on – such as the data team, the enterprise architects, and even the governance team – to be sufficiently flexible to work with the agile team in an agile manner.  In some cases the agile team may need to be “given a pass” from creating the mandated artifacts, or having to jump through the mandated “quality gates”, required by these teams.
  4. Help the teams that they collaborate with to become more agile.  The next step after giving an agile team an organizational pass it to recognize that this is an opportunity to experiment with improving other areas within your organization.  Help the enterprise architects to learn about agile and to try a few agile strategies themselves.  Similarly the data team can experiment with agile data management strategies and certainly your IT governance team can also take the opportunity to up their game as well.

How Do You Know That Your Productivity Actually Improved?

Although the chart above intuitively makes sense, how do you know that your productivity has actually increased?  To definitively answer this question you need to determine what productivity means to you, what the productivity level of the team currently is, and then continue to measure the level of productivity over time. This strategy tends to fall apart because few organizations know how they want to measure team productivity and fewer yet have actual measures in place. This of course is particularly vexing when senior management still requires you to prove that your productivity has increased as the result of your agile adoption efforts.  Luckily there are ways to measure the change in productivity even when you don’t know what the baseline productivity level currently is.  We’ll address this topic in a future blog.

Agile is About More Than Productivity Improvement

There are many benefits to agile, improving team productivity being just one of them. Potential benefits, some of which lead to greater productivity, include:

  • Improving the quality of the delivered solution
  • Improved stakeholder satisfaction
  • Greater adaptability to market changes
  • Increased team morale
  • Quicker time to market
  • Greater frequency of delivery
  • and many more

Agile Metrics: Questions and Answers

Metrics

On March 21 2017 we ran a webinar entitled Measuring Agile: A Discipline Agile Approach to Metrics.  We unfortunately didn’t have enough time to answer all of the great questions that we received so we said that we’d write a blog with the answers.  This is it.

We’ve organized the blog into the following sections:

 

Convincing Management

First and foremost, please read our blog entitled 7 “Easy” Steps to Convince Management to Support a Hard Change.  This blog has a lot of great advice for getting support from senior management for the changes asked about below.

 

Q: What is the message to deliver to the board of directors of a company and/or sponsors of projects when it comes to metrics?

The principles section of the webcast made this pretty clear I think.  The principles we discussed are:

  • There is no easy answer
  • Every metric has strengths and weaknesses
  • Compete against yourself
  • Measure to improve
  • You get what you measure
  • Measure outcomes at the team level
  • Each team needs a unique set of metrics
  • Team use metrics to self organize
  • Trust but verify
  • Adopt common metrics categories across teams
  • Don’t manage to the metrics
  • Automate wherever possible
  • Prefer trends over scalars
  • Prefer leading over trailing metrics
  • Prefer pull over push

If I had to pick a key message, it’s that you need to be flexible and enable teams to take a context sensitive approach.

Q: How do you address the resistance to ranged estimates?  We see a lot of resistence to this with leaders!

Sadly this is all too common.  There is a desire for an “exact number” for the cost/schedule for an IT project, the belief being that such precision leads to lower financial risk. This never seems to work out, and in practice it tends to increase overall financial risk.  Worse yet it motivates some very ethically questionable management practices such as padding the budget (lying about the cost to get the fixed estimate as close to the upper end of the range as possible), dropping scope late in the lifecycle (lying about what will be delivered and wasting money working on stuff you had no hope of delivering in the first place), or asking for more money when it’s clear you’re not going to deliver it (this is arguably extortion).  In the article Estimating on Agile Projects I go into further detail about the need for ranged estimates.

As we discuss in the 7 Easy Steps blog, you need to educate management on the trade-offs involved with their current approach and help the to see that it isn’t working out well for them in practice.

Q: My management definitely wants to know if they are on time and on budget… how should I handle this problem?

This is also another common problem in more traditional organizations, and is sadly a mindset that is often promoted by project management canon.  The first thing to do is ask them why “on time and on budget” is important to them, and to continue to explore their goals via an evolutionary “5 why” strategy until you get to the heart of the matter.  Usually the real issue is that they want to reduce schedule risk and financial risk but they only know to ask for on time and on budget respectively.  Help them to recognize that they can do better than that.  For example, a more effective question to ask instead of “Are we on budget?” would be “Are we spending the money wisely?”, the latter question requiring competent governance to truly answer.  Similarly, a more effective question to ask that “Are we on schedule?” would be “Are we going to deliver when the functionality is actually needed?”, also a question requiring better governance than many organizations seem to have today.

Q: Executives and senior management wants common metrics period… can you talk to this – how should a change agent (me) handle this?

Sadly another very common problem.  This proves to be selfishly motivated in most cases – they want a common set of metrics to make it easy for them to monitor teams (they have less thinking to do when all the dashboards look the same).  As we discussed in the webinar, this isn’t realistic because every team is unique, they face a unique situation, and they have a unique set of priorities.  Yes, there are commonalities between teams but also differences.  For example, it makes sense for teams to measure quality.  BUT, surely it’s obvious that a data warehousing team will measure quality different than a mobile app team, which in turn measures quality differently than a team sustaining a mainframe-based system.  This is why I promoted the idea of asking teams to address common categories (such as Quality, Stakeholder Satisfaction, Finance, and so on) but to do so in a manner that makes sense for them.

 

Transformation Metrics

Q: In a transformation is the ‘stakeholder vision’ milestone something that you see ‘could’ be used as a way to guage adoption of the framework across an Enterprise?

Stakeholder vision is a milestone that marks the end of the Inception phase.  I’m not sure how it could be used to gauge adoption.  It could be used to gauge readiness to move forward with the transformation though.

Q: Is there more thoughts you have on transformation metrics?

Context counts.  In general, take a context-sensitive approach where you measure what is important to you.  I worked through a lightweight approach to Goal-Quality-Metric (GQM) during the webinar and the OKR approach is also good.  There is no one single answer.

Q: How do start-up agile projects best survive in a really non-agile organization?

Sadly, they generally don’t.  If you go poking around on the web you’ll find that there’s a lot of advice around this sort of issue, and a large portion of it advising you to jump to another organization.

 

Specific Metrics

Q: Please throw some light on Accelaration metric. I’d like to implement that in my org.

We have a detailed blog about acceleration.

Q: Velocity, used to calculate acceleration, can only be calculated if velocy is based on the same point system… I don’t agree acceleration factors out the points, the points have different meaning potentially by project – can you talk to this some more?

You’re wrong,  Here’s a quick answer:

  • Team 1 has a velocity this iteration of 20 and a velocity 5 iterations ago of 15.  Velocity is measured in Atari points on this team.  Acceleration = (20 Ataris – 15 Ataris)/15 Ataris = 33% over 5 iterations.
  • Team 2 has a velocity this iteration of 30 and a velocity 5 iterations ago of 20.  Velocity for this team is measured in Nintendo points by this team.  Acceleration = (30 Nintendos – 20 Nintendos)/20 Nintendos = 50% over 5 iterations.
  • When I divided Atari points by other Atari points the unit of measure, Atari points, disappeared.  Similar thing happened to Nintendo points.  Hence acceleration is comparable as long as it’s calculated over a similar time period (if not, adjust so that you are dealing with a similar time period).
  • Read the Acceleration blog for details.

Q: Is value is only monetary value is $?

No, it doesn’t have to be but often is.  You should measure value in units that are important to your stakeholders.  Perhaps value may be measured in market share by them, for example.

 

Miscellaneous

Q: Excecutive leaders want to measure “team health” using metrics and compare teams – maybe reward or punish based on these metrics – please talk to this.

This is generally recognized as bad practice because as soon as teams realized that they are being judged by management they’re motivated to game the metrics as best they can.  In the case of automated metrics that are difficult to game, then perhaps its possible to compare against that (code quality metrics come to mind).  But, management will get what they measure.  For example, if they judge teams based on how many defects they fix, chances are pretty good that the team will start identifying relatively trivial defects and then “fix” them to make their metrics looks good.  However, if they judge teams based on code quality trends (i.e. Is code quality improving?) they will likely get higher quality code in the long run.

As I said in the webinar, the primary usage of metrics should be to provide insights to teams to help them to improve.  Monitoring teams, part of your overall governance strategy, should be an important but secondary concern.

Q: What if the teams don’t agree with the metrics established by management?

My advice is for teams to identify the metrics that make sense for the situation that they face via a lightweight GQM approach (or something similar such as OKR).  Management may want to guide teams, perhaps by insisting on certain categories of metrics, see the earlier discussion, or even by suggesting metrics being collected by other teams.

If it’s a situation where management is trying to inflict a common metrics strategy across all teams, which is a relatively bad idea as I discussed earlier, then I think that the team should justify why they don’t agree with the metrics prescribed by management.  I also hope that they would suggest a more appropriate strategy and that management would listen to them.

Q: What are some of your favorite tools for metrics?

I typically don’t like recommending tools because the answer to this question is context dependent.  Tool choice will be driven by:

  • What you are hoping to measure
  • Your existing platform(s)
  • Your organizational preferences around tooling (are you a Microsoft shop, are you willing to pay for commercial tools, are you willing to adopt open source tools, …)
  • Your previous experiences around such tooling, if any

So, identify what you situation is then do a bit of research to identify the tools that are right for you.

Q: Is it realistic at scale to have multiple dashboards? +900 teams.

I’ll turn this one around.  Is it reasonable to ask teams not to have dashboards simply because your organization is big?  Is it reasonable to give up on monitoring teams because your organization is big?  Is it reasonable to give up on automation because your organization is big? You see where I’m going with this.

 

7 “Easy” Steps For Convincing Senior Management to Support a Hard Change

Puzzled manager

We’re often asked how do you convince senior management to accept new agile ideas and strategies.  Examples of such ideas include:

Why is This Important?

There are three reasons why it’s important for agile coaches, and Team Leads/ScrumMasters for that matter, to know how to convince senior management to support new ways of working:

  1. You need their support.  There are many aspects of an agile transformation that an agile coach doesn’t have the authority nor the resources to change.  As a result you need to collaborate with others and very often earn the support of the people who do have the authority and resources.
  2. Agile transformations are complex.  Agile transformations are about more than just transforming software development teams.  The 2016 Agility at Scale study found that 96% of agile teams need to collaborate with other teams external to them to get their job done.  The implication is that these other teams that they are collaborating with – including your business stakeholders, governance team, data management, internal audit, security group, and many others – need to at least be able to interact with your agile teams in a reasonably flexible manner if not work agilely themselves.
  3. Agile transformations are fragile.  If you want to transform your IT department, and more importantly your organization, then you’ll need to transform all aspects of the department/organization.  All it takes is one or more groups to refuse to work in an agile manner and suddenly your transformation is at risk.  The implication is that you need to get good at convincing others to support your efforts if not change themselves.

Why is This So Hard?

There are many reasons why senior management may be reticent to consider this change that you believe to be very important:

  • They have other priorities that you may not be aware of.
  • They have many other issues to deal with, this is just one of them.
  • They may be very happy with the status quo and don’t recognize the problem.
  • There are other people advising the exact opposite.
  • There are people who are entrenched in the existing way of working, and that may include senior management.
  • They will need to convince their peers regarding the benefits of the change and they may not know enough to be able to do so, or may not have the political capital to effect the change.
  • Change can be disruptive and it may jeopardize their existing commitments which incidentally might be tied to their compensation plan.
  • The manager realizes that this change has greater ramifications than you may believe.

The Seven “Easy” Steps For Convincing Someone to Support Change

Here is an approach that we’ve had work in practice for us.  You will very likely need to work through all of these steps, pretty much in order, to be successful.  These steps are:

  1. Pick your battles wisely.  Ask yourself whether this issue is the most important thing that you need help with from this person.  There will be only so much willingness to invest time and effort in supporting the changes that you believe to be made, and not all requests are going to be supported.  As Rod Bray, CDAC, likes to say: “Choose the hill that you’re willing to die on.”
  2. Know the topic and the language around it.  Chances are that you will need to be able to explain whatever it is that you’re asking for help on, what the trade-offs are, why its better than the current approach, and what the impact of the change will be.  To do this you will need to understand the trade-offs are of the current approach and understand the issues and language of the topic.  For example, if you’re asking for help to change the way that IT projects are funded, are you able to speak intelligently about the existing annual-based budgeting process, project-based funding, and perhaps even the implications of CAPEX/OPEX?  Or, if you’re asking to improve the current approach to IT governance, do you understand the existing governance process, what it’s trade-offs are, and what the potential impacts of applying traditional governance to agile teams may be?  If you don’t have this fundamental understanding of the topic then you will very quickly sound like you don’t know what you’re talking about, so why would management want to support you?
  3. Plan the conversation.  Although you very likely have some very great ideas, if you spring them on others they will very likely be threatened by them at first (human beings are psychologically wired to treat surprises as threats).  A better approach is to first ask permission to discuss a new idea that you have, and even share an overview of the idea beforehand so that they can think about it a bit, before you get together to seek their support.
  4. Explore their concerns.  Once you’ve pitched your idea to them they will very likely want to discuss the trade-offs with you, in particular the impact on other groups and the time and effort required to support your change.  The implication is that part of your preparation before you make your pitch should be to think about what concerns they may have with your suggested approach so that you have arguments to counteract any concerns.
  5. Ask them to share their actual experiences.  It is very common for people to become attached to ineffective ways of working.  This sounds strange on the surface, but people are like this.  Whenever we run into someone who believes in a strategy that we know to be ineffective – fixed price funding, documentation-based governance, detailed up-front modeling, significant amounts of manual testing to name a few – we ask them how well it’s working for them in practice.  Very often they’ll tell you about the positives, but if you know the topic (and better yet the history of that strategy within your organization) then you can start exploring the negative aspects with them too.  It’s particularly useful to be able to bring up several past projects where that strategy was applied yet it didn’t work out so well in practice. The point is to help them to recognize that their favored strategy isn’t working as well as they’d like, and that there is a need to rethink your current approach.
  6. Educate them.  Walk them through the trade-offs, both good and bad, of your suggested approach.  Be prepared to discuss the trade-offs of the current strategy, and in particular relate those trade-offs back to the experiences that they just told you about.  You may often discover that they didn’t realize that there are other options available to them and that they’ve been ignoring the problems with their existing approach.  Help them to understand that they have a better choice available to them.
  7. Convince them to run a small experiment.  Making a large, whole-scale change is scary.  If the new approach doesn’t work out then you’ve got a serious problem to deal with and the manager who sponsored the change may be punished for it.  But, running a small, contained experiment to see if the new strategy works in your environment isn’t very threatening and better yet is a fundamental risk management strategy.  So start small, get a visible win, learn from the experiment, and the roll out the change more widely.  It is important that you “negotiate” the changes as they will be more likely to try it if you let them know that the change is an experiment and they will have the opportunity to revert back if the expected benefits do not materialize.  Note that some organizations are leery of running “experiments” but are very willing to run “proof of concepts (PoCs)” – go with the terminology that works in your organization.

We wish that we could tell you that we’ve had a 100% success rate with this strategy.  Sadly we haven’t.  We have done very well with this, but sometimes it doesn’t always work out the first time.  Or the second time, and sadly sometimes not even the third time.  Your goal should be to get them thinking about new ways of working and to give them the time that they need to decide to support you.

Agile Transformation: Comparing Transformation Strategies

Three-legged stool

In Agile Transformation: Being Agile, Doing Agile, and Supporting Agile we described three factors – people (being agile), process (doing agile), and tools (supporting agile) – that in our experience must be addressed during your agile transformation.  In this blog posting we compare agile transformation strategies in terms of addressing combinations of the three factors.  The following diagram overviews the eight potential strategies that you may embark upon.

Agile Transformation Strategies

Let’s compare each agile transformation strategy one at a time:

  1. None of the factors are addressed.  Good luck with that.  😉
  2. Focus on people only.  When you focus solely on being agile your teams don’t really learn how agile techniques fit together, nor do they understand the implications of how they’re working.  An example of a people only strategy is to give everyone training and coaching in leadership and collaboration skills and then expect them to self-organize into effective agile teams because “they already have the skills and they’re smart people who can figure it out”.  We saw this sort of strategy fail at a large product company when the teams who received this coaching and training invariably went back to their former ways of working.
  3. Focus on process only.  With this approach you get “cargo-cult agile” that is layered on top of your existing processes. What we mean by cargo-cult agile is that the team adopts many of the straightforward management practices, the ones that Scrum tends to focus on, such as holding a daily coordination meeting, an iteration/sprint demo, an iteration/sprint retrospective, and iteration/sprint planning.  You end up with people holding “all of the agile meetings” and who on the surface take on their version of agile roles such as Product Owner and Team Lead.  They have the appearance of working an an agile manner but they really aren’t, and worse yet they don’t even know it and usually nor does senior management.  This is a very common problem when an organization’s entire agile transformation strategy is to send their people on two-day workshops so that they may become “certified masters.”
  4. Focus on tools only.  Some organizations believe that if they buy several agile tools, or even an entire agile tool suite, and then force their staff to use them that the tools will somehow make their teams agile.  The actual result is that you end up with a “standardized” approach to agile that is both overly complex (the tools typically include far more features than you’ll ever want, many of which provide functionality completely inappropriate for your situation) and incomplete (you can’t automate everything and even if you could the vendors haven’t gotten to it yet).  The worst offenders are the Application Lifecycle Management (ALM) suites, many of which seem to be offered by vendors who themselves are struggling to deliver consumable products into the marketplace.
  5. Focus on people and process. A common agile coaching refrain is to address tooling once you understand the process, which is good advice to an extent, but it quickly falls down when you realize that many technical practices such as continuous integration (CI) and automated testing require adoption of tooling from the very start. When you ignore or at least greatly downplay tooling issues you tend to grow “agile purists”, and even “agile zealots”, who only know how to apply agile in simple contexts.  Ignoring tools can ease your agile transformation at first but eventually tends to get you into trouble when you start to apply agile in more complex situations.
  6. Focus on process and tools. When you don’t coach people in the skills and mindset around
    “being agile” you tend to end up with cargo-cult agile with automated bureaucracy.  Agile transformation requires a paradigm shift, which inherently implies you need to address what it means to be agile.
  7. Focus on tools and people. When you downplay how to “do agile” you tend to get agile children playing with shiny new toys.  They tend to know the agile language and mindset, and will often have a cursory understanding of simple agile practices that they learned on their two-day certified mastery workshop, but they really don’t know how to successfully build consumable solutions from beginning to end.  Teams who receive little help on “doing agile” tend to spend a lot of time, and a lot of money, figuring out the agile process.  Worse yet, they often adopt a WaterScrumFall approach where Inception and Transition tends to be more traditional and heavy and only Construction is lightweight and agile.
  8. Focus on people, process, and tools simultaneously.  When your agile transformation strategy addresses all three factors at once you have the potential to create Disciplined Agile teams that can work at scale.  This only happens when your “being agile” efforts help people to shift to an agile mindset, when your “doing agile” efforts teach a comprehensive yet flexible (think goal driven) view of agile strategies and practices, and your “supporting agile” efforts lead to a context-driven, enterprise aware approach to tool selection.

In your agile transformation you will spend much more effort addressing people-oriented (being agile) issues than you will either of process (doing agile) or tooling (supporting agile) issues.  Think of it like this: these three factors are effectively the legs of a stool, if you don’t address all three then your agile transformation will fall over.

If you’d like help with your agile transformation, please contact us via ScottAmbler.com.

Agile Transformation: Being Agile, Doing Agile, and Supporting Agile

Many organizations struggle to transition to a more agile or lean way of working.  In this blog posting we address three questions:

  1. What factors should your agile transformation address?
  2. How important are these factors in practice?
  3. How difficult are these factors to address?

What factors should your agile transformation address?

Our experience is that successful agile transformations need to address three fundamental issues:

  1. People (being agile).  This factor addresses issues such as individual mindset, team and organizational culture, and team and organizational structure.  As a Disciplined Agile coach you must help people to evolve to an agile mindset, learn new skills, adopt improved collaboration strategies, and evolve the way they are organized to reflect their new ways of working.  As you can see below, this factor typically comprises between 80 to 85% of your agile transformation effort.
  2. Process (doing agile).  As a Disciplined Agile coach you need to help organizations adopt new agile and lean practices, strategies, and the Disciplined Agile framework itself.  This tends to be between 10 to 15% of the overall transformation effort.
  3. Tools (supporting agile).   Agile teams will need to adopt new tools, such as continuous integration (CI) tools, testing tools, and perhaps even agile task board software to name a few.  Agilists will use existing tools, such as their configuration management environment, in new ways.  And they will abandon some existing tools, in particular traditional test management tools, that aren’t applicable in the agile world.  Reworking your tooling strategy tends to take about 5 to 10% of your agile transformation efforts.

Agile Transformation: Focus of Effort

How important are these factors in practice?

In the 2014 Agile Transformation survey we asked a series of questions around how important it was to address various people, process, and tooling factors.  The survey respondents had either been through an agile transformation or were currently well into one.  The figure below shows that the first and third most important transformation factors were aligned with being agile, the second and fourth most important factors were around doing agile, and the two least important factors were around tooling (supporting agile).

Agile Transition Factors - Importance

How difficult are these factors to address?

In the 2014 Agile Transformation survey we asked a similar series of questions around how difficult organizations found it to address various people, process, and tooling factors.  The first and third most difficult factors to address were cultural (being agile).  The second and sixth most difficult factors to address were process oriented (doing agile) in nature.  The fourth and fifth most difficult factors addressed tooling.

Agile Transformation Factors - Difficulty to address

Our experience is that if you don’t address all three factors in your agile transformation effort that you will run into serious trouble.  This topic will be explored in our next blog posting.

If you’d like help with your agile transformation, please contact us via ScottAmbler.com.