Disciplined Agile and SEMAT

Collaboration

I’m happy to announce that the Disciplined Agile Consortium (DAC) is now working with SEMAT. SEMAT, Software Engineering Method and Theory, is an international community of people, companies, and universities.  Led by Ivar Jacobson, SEMAT is working together to create a common ground, or kernel, for software engineering.  As you may know I am one of the original signatories who first indicated their support for the SEMAT effort and am currently a member of the SEMAT advisory board.

So what are we doing?  We intend to work together to essentialize some of the key concepts that are unique within the Disciplined Agile (DA) framework and for the DA framework to leverage the great ideas already captured within SEMAT.  Of course it is still early days and there is a lot to do.

Please stay tuned here for further updates!

Recommended Reading

Building Your IT Support Environment

An important aspect of Support that is easily forgotten is the need to build out your infrastructure to enable your support efforts.  This may include:

  • Creating a support knowledgebase so that your Support Engineers can capture solutions to the problems they solve.
  • Provide access to the support knowledgebase to support self-service by end users.  This access is often limited for privacy reasons – end users should have access to solutions to common problems but not the details to specific incidents.
  • A support environment to simulate problems.  In some cases, such as an online trading system perhaps, you don’t want your Support Engineers trying to diagnose end user problems on the live system itself due to potential side effects of doing so.
  • Installing communication systems such as chat software and a phone/call in system.
  • Automated support systems such as integrated voice response (IVR) and artificial intelligence (AI)/bots

Figure 1. High-level architecture for a Support environment (click on it for larger version).Support desk architecture

The Oath for an Agile Coach: Great Start, But We Need to do Better

Coach

I recently ran into The Oath for an Agile Coach.  There are clearly some great ideas in the oath and it would be hard to argue that you wouldn’t want to adopt the advice contained within it.  So I won’t do that.  However, I do feel that there are some serious challenges surrounding the oath but that with a bit of hard work we could do better.

Some Great Ideas Here

Frankly, what’s not to like?  The oath promotes the idea that coaches should do no harm, that they’re guests, that they should respect learnings, that they value discretion, and many other wonderful philosophies.  Several of them are arguably a bit naive, for example:

  • First, do no harm. From one point of view the definition of an agile coach is to do harm – harm to the status quo, harm to the incumbent mindset, harm to the corporate politicians who rose to power building the current environment that the coach is there to help the organization improve.  You wouldn’t be much of a coach if you weren’t doing harm to the bad stuff in your organization.
  • I prevent dysfunction.  Really?  I’ve worked in many environments that are “target rich” when it comes to dysfunction.  I’m expected to help prevent all of these dysfunctions right away?  I’m supposed to prevent dysfunction that is beyond my current scope of influence?  Of course not.  I need to help the people that I’m working with to identify and prioritize their pains, then help them address these pains as and when it is appropriate to do so (if ever).  Clearly the advice in the oath is context sensitive and it isn’t meant to be taken literally.

It’s clear to me that a lot of smart people have put a lot of effort into the oath, that they’ve thought it through, and are honestly trying to make things better.  I also believe that this is a step in the right direction, although at the time of this writing there are some serious challenges surrounding it that can and should be addressed.

 

A Few Serious Challenges

First and foremost, we should give the authors of the oath the benefit of the doubt and assume that they aren’t doing the things I’m about to describe on purpose.  Although what I have to say is harsh, I honestly believe that the authors have their hearts in the right place but have not thought through the implications of what they’ve started.  So here goes.

The oath is deceptive and as a result possibly unethical.  The reason why I say this is that they claim to have based the coach’s oath on the The Hippocratic Oath (which I’m sure they’ve actually done).  The problem is that they’ve merely skimmed the surface of the Hippocratic Oath, lifting ideas such as “First, do no harm” (which the oath doesn’t actually say, that’s the Hollywood interpretation of it) without also adopting the context in which the Hippocratic Oath is taken.  This is important.  New medical practitioners, after years of training, are asked to take the oath, or something similar, by medical schools.  These schools are governed and the medical professionals themselves are governed.  Control mechanisms are in place to ensure that the people who take the oath know what they’re doing and work in a trustworthy manner.  Therein lies the rub – no such governance exists for agile coaching and I suspect the vast majority of agile coaches would chaff at the suggestion.

To see why this is an issue consider the following example.  I have no medical training or background, with the exception of taking a few first aid courses over the years.  Come to think of it, by agile standards I have more than enough medical training to be considered a Certified Surgery Master (CSM), so it’s all good. I have just now recited the Hippocratic Oath and have pledged to abide by it.  As a result I now feel that I am qualified to offer plastic surgery procedures as I’ve heard that this is a lucrative business to be in.  If you would like a face lift, liposuction, or augmentation of a body part please contact me to arrange a procedure.  You can trust me because I’ve recited the Hippocratic Oath and I’m a CSM.  What?  You’re not interested? I’ve pledged to do no harm, so you can trust me.

I think that you inherently know it would be a bad thing for me to perform plastic surgery on you.  I’m obviously not qualified.  Therein lies the rub.  I could easily advertise that I’ve pledged the oath, tell people about my CSM credentials, and make it sound like I’m qualified, particularly to people who don’t have much of a background in agile.  In fact, recently in Toronto, a 19-year old woman did something very similar to this and as you’d expect it didn’t work out well for the recipients of her surgery endeavours.

By claiming that the agile coach’s oath is based on the Hippocratic Oath the authors are taking advantage of something called “prestige association.”  The Hippocratic Oath is prestigious – the people who pledge it have to work very hard to be asked to pledge it and are subsequently held to its high standards throughout their careers.  By explicitly associating the agile coaching oath with the Hippocratic Oath the prestige of the latter is conferred to the former.  This is deceptive at best and unethical at worst.  I believe we can be better than this.

 

How We Can Do Better

It isn’t appropriate to complain about the Agile Coach’s Oath without also providing some possible ways to fix it.  Here are my initial thoughts:

  1. Avoid prestige association. The very first thing, and easiest thing, that could be done is to stop comparing this oath to the Hippocratic Oath.
  2. Define paths to becoming a great coach.  A straightforward, and relatively easy, way to add real value would be to put together a path, or more likely several paths, that people could follow to become a great coach.
  3. Help people to follow those paths. In short, build a respectable agile coaching guild that focuses on helping people over making money off of them.
  4. We need to respect ourselves. This is an observation for agilists in general, but particularly important for agile coaches.  At the present moment the Agile Coach’s Oath is yet another vapid agile band wagon for people to jump onto without having to do any real work.  As coaches we lament the large number of lame agile “certifications” that are little more than participation ribbons, so perhaps it’s time we choose to say enough is enough.  We know that effective coaching requires skill, knowledge, and experience that require years of hard effort to earn.  Just like the medical community requires years of education and training before extending the privilege of asking someone to take the Hippocratic Oath, we could choose to do something similar.  But first we’d need to respect ourselves enough to actually do that.

I believe the people who developed The Oath for an Agile Coach have good intentions.  They’ve gotten a great start on an interesting and potentially valuable idea. But, they need to follow through and make it something real if they really want this oath to be meaningful.  I hope they choose to build a vibrant community that does exactly that.  Time will tell.

 

Related Postings

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

Bridging the Gap Between Agile and Data


At the Agile 2017 conference this week Lynn Winterboer was kind enough to invite me to her workshop which explored how to apply agile strategies in the data space.  She did a great job of facilitating the group of about 40 people through identifying the challenges currently faced by teams. The main issues that the group explored were:

  • Product ownership and data
  • Agile data architecture
  • Data testing and tooling support
  • How to include data people, and activities, in development

Lynn will soon be blogging about the results so I’m not going to dive into that here.  I suspect that her blog post will be very interesting.

What I’d like to do here is share a few thoughts about what I observed:

  1. The discussion was very healthy. This was a group of very smart people coming from different backgrounds.  Everyone was interested in sharing their experiences and working together to solve some tough problems.
  2. Context counts. “Agile and data” is a big topic.  A few people were dealing with the issue of how to address data issues on application development projects, some were focused on agile data warehousing/business intelligence, and some were focused on complex data analytics.  In our conversations it was very clear that strategies which worked for app development wouldn’t work for analytics, and vice versa.  This is why Context Counts is one of Disciplined Agile’s fundamental principles.
  3. The challenges are tough. Everyone was working in organizations that were struggling with these challenges.  For each of issue we could have spent much longer exploring the potential solution(s).
  4. Every challenge we discussed are solved issues.  I’ve always found it frustrating when people, who are very smart and who have been struggling with a problem for awhile, have clearly never thought to simply google “database testing tools” or “agile architecture” to find out what advice is already out there.  When we discussed testing I even asked why people hadn’t done such as search, and then pointed out that there are a lot of tools available and even a few people maintaining lists of such tools (such as 40+ database testing tools).  All of these challenges, and more, have solutions described by techniques of the Agile Data and Agile Modeling methods from about 15 years ago.  These techniques have of course been adopted, and put into context, by the Disciplined Agile (DA) framework and in particular Disciplined Agile Delivery (DAD).
  5. The “factions” behaved differently.  Long ago I pointed out that there’s a cultural impedance mismatch between the data and developer communities, and it was pretty easy to observe during this workshop.  For example, during the workshop we were asked to identify solutions to the challenges.  Lynn wanted us to write this information on flip-chart paper so that she could later scan it and share it with others.  For awhile the groups dominated by data people discussed the solutions without writing anything down.  Their conversations were good, but they quickly got stuck in analysis paralysis mode because they seemed to be afraid to write down information for fear that they couldn’t easily update it (the challenge with having paper to write on instead of whiteboards). The groups dominated by agile people, the ones focused on development and architecture, started by writing on sticky notes and putting them on the flip chart paper.  This fundamental agile modelling strategy enabled them to visualize and share their work transparently, enhancing their conversation and enabling them to move forward easily.
  6. Database (tool) vendors need to up their game. Speaking out tools, database vendors and data warehouse tool vendors really need to up their game.  Here’s a few very harsh questions: Does your database tool vendor or ETL tool vendor offer testing tools that enable both black box and white box database testing?  Answer: very likely no, because their customers don’t demand that of them.  Did your data team even think to ask for such tools?  Answer: very likely not.  How many database testing books do you think have been written? Answer: very few, go do a search and see for yourself.  Why does the data community have such a huge blind spot when it comes to testing? Answer: this is a huge side effect of the cultural impedance mismatch.

I’m very happy to see that Lynn is actively trying to bridge the agile and data communities, helping us to learn from each other.  This is something she’s been doing for years and doing it quite well.  My experience is that both communities would benefit greatly from more collaboration with each other.

How Do You Choose Between Software Lifecycles?

Confused

As you know the Disciplined Agile framework supports several delivery lifecycles – Agile, Lean, Continuous Delivery: Agile, Continuous Delivery: Lean, Exploratory.  We do this because solution delivery teams face different situations, so one lifecycle will not fit all.  This begs the question of when would a team adopt each lifecycle?  That is the focus of this blog.

This blog explores the following topics:

  1. What lifecycles does DAD support?
  2. What criteria should you consider when choosing a lifecycle?
  3. Who chooses?

What Lifecycles Does DAD Support?

The delivery lifecycles we will explore are:

  1. Agile/Basic. DAD’s Agile/Basic lifecycle which extends Scrum’s construction lifecycle. We call this the basic/agile lifecycle because it’s likely where you’re going to start. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.
  2. Lean/Advanced. The Advanced/Lean lifecycle encompasses lean strategies such as minimizing work in process, maximizing flow, a continuous stream of work (instead of fixed iterations), and reducing bottlenecks. New work is pulled from the work item pool when the team has capacity.
  3. Continuous Delivery: Agile.  The Continuous Delivery: Agile lifecycle  is a natural progression from the Agile/Basic lifecycle. Teams typically evolve to this lifecycle from the Agile/Basic lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations.
  4. Continuous Delivery: Lean. DAD’s Continuous Delivery: Lean lifecycle is basically a leaner version of the Continuous Delivery: Agile lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
  5. Exploratory/Lean Startup.  DAD’s Exploratory lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.
  6. Waterfall/Serial.  Although this is not supported by Disciplined Agile, we do recognize that some teams will still follow this more traditional way of working.  For more thoughts on this subject, please see the blog posting When Does Traditional Software Development Make Sense?

 

What Criteria Should You Consider When Choosing a Lifecycle?

The following table compares the lifecycles, suggesting when you would choose to follow each one.

Lifecycle Team Type Time to Market Advantages Disadvantages When to Use
Agile/Basic Project Medium
  • Straightforward lifecycle based on Scrum that is easy to learn due to its prescription
  • Iterations (sprints) motivate teams to build functionality in multi-week batches
  • Releases into production typically months apart
  • Tends to fall apart when requirements change often
Teams new to agile
Lean/Advanced Project Fast
  • Functionality is released into production when it`s ready to go
  • Work can be prioritized via a variety of criteria
  • Small batches of work lead to quick flow
  • Requires greater skill and discipline compared to the Agile lifecycle
Disciplined teams with quickly evolving requirements
Continuous Delivery: Agile Product (long lived) Fast
  • Functionality is released into production regularly at a steady flow (typically weekly)
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment
Long-running teams
Continuous Delivery: Lean Product (long lived) Very Fast
  • Functionality is released into production continuously, typically one or more times a day
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment
Long-running, disciplined teams
Exploratory/Lean Startup Experimental Fast
  • Quick and inexpensive way to run business experiments
  • Low-risk approach to validating potential new business strategies
  • Requires a way to target a subset of your (potential) customer base
  • Often not applicable in regulatory compliance situations
  • Often perceived as a strategy for startup companies only
Identification of a new product or service offering for the marketplace where there is a high risk of misunderstanding the needs of potential end users
Waterfall/Serial Project Slow
  • Comfortable approach for experienced IT professionals who have not yet transitioned to an agile or lean way of working
  • Tends to be very high-risk in practice due to long feedback cycles and delivery of a solution only at the end of the lifecycle
  • Associated risks are often overlooked by management due to façade of predictability and control provided by the paperwork produced
Low-risk situations where the requirements are stable and the problem has a well-known solution.  For example, upgrading the workstations of a large number of users or migrating an existing system to a new platform

 

Who Should Choose the Lifecycle?

The team.

They will often do this with the guidance of an experienced Disciplined Agile coach, particularly when they are new to DA.  It’s tempting to have your portfolio management team to make this choice, and they may often make a (hopefully solid) suggestion when the first initiated an endeavour, but in the end it needs to be the choice of the team.  As you see in the table above there are common considerations for when to use each lifecycle, but the primary considerations are always the skill and preferences of the team itself.

 

Related Reading

The Seven Disciplined Agile Principles

Principles of the Disciplined Agile Framework

We recently published a collection of articles overviewing the seven principles behind the Disciplined Agile (DA) framework.  The article is entitled Principles Behind the Disciplined Agile Framework and it in turn is supported by detailed articles, one for each principle:

  1. Delight Customers – We delight our customers when our products and services not only fulfill their needs and expectations but surpass them.
  2. Be Awesome – Awesome teams are built around motivated individuals who are given the environment and support required to fulfill their objectives.
  3. Pragmatism – Let’s be as effective as we can be, and that may mean we go beyond being just agile.
  4. Context Counts – Every person, every team, and every organization is unique.  Let’s find and evolve an effective strategy given the situation we actually face.
  5. Choice is Good – Different contexts require different strategies. Teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. Having process options to choose from, and understanding the trade-offs of those options, enables you to home in on better options sooner.
  6. Optimize Flow – Your organization is a complex adaptive system (CAS) of interacting teams and groups that individually evolve continuously and affect each other as they do. To succeed you must ensure that these teams are well aligned, remained well aligned, and better yet improve their alignment over time.
  7. Enterprise Awareness – When people are enterprise aware they are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the sub-optimal goals of their team.

We hope that you find these articles insightful.

Announcement: An Executive’s Guide to Disciplined Agile is now available!

An Executive's Guide To Disciplined Agile

We’re happy to announce that our new book, An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility is now available.  The book is currently available on Amazon in paperback for $39.99 US and will soon be available on the Kindle.

Overview

The agile community has figured out how to build and then continually improve very high-performance software development teams. This is akin to creating a race car engine and then evolving it to get more power, better fuel efficiency, and greater speed. Sadly in many cases we take these great engines, put them into an organizational tractor, and then complain that we’re not winning the race. What we need to do is take our great race car engines (our development teams), put them into a race car (a DevOps ecosystem), have a great pit crew and driver (an effective IT organization), and then provide somewhere to race (an organization that can leverage IT to make money). That’s what this book is all about – Moving from optimizing team performance to optimizing the entire enterprise.

Business agility – being an adaptive, lean, responsive, and learning organization – is the race that enterprises need to win today. Yet there is no quick fix, no silver bullet, to attain business agility. This is a multi-year journey requiring hard work, experimentation, and most importantly a willingness to improve. The Disciplined Agile framework lowers risks and provides a path to accelerate your journey to business agility. The framework is unique in that it is the only one that puts all the pieces together into a cohesive enterprise roadmap for business agility transformation.

This book begins with an overview of the challenges and opportunities that organizations face. We then describe seven principles that provide the underpinnings of the Disciplined Agile framework. Then the book works through Disciplined Agile Delivery (how to build a world-class engine), Disciplined DevOps (the race car), Disciplined Agile IT (the race car and its team), and what it means to be a Disciplined Agile Enterprise (the racing business).  The book ends with a plan for starting with an Agile transformation and then evolving into a long-term continuous improvement strategy.

Do you have the discipline it takes to win the race to business agility?

For More Information

Please visit the page An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

Introducing the Continuous Delivery: Agile Lifecycle

Agile Continuous Delivery Lifecycle

This lifecycle is a natural progression from the Agile/Basic lifecycle. Teams typically evolve to this lifecycle from the Agile/Basic lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations. Teams require a mature set of practices around continuous integration and continuous deployment and other Disciplined DevOps strategies. This lifecycle is suitable when:

  • Solutions that can be delivered to stakeholders in a frequent and incremental basis
  • Work remains relatively stable within an iteration
  • Organizations with streamlined deployment practices and procedures
  • Projects where getting value into the hands of stakeholders rapidly, before the entire solution is complete, is critical
  • Teams have mature DevOps practices in place including continuous integration, continuous deployment, and automated regression testing
  • The team is long-lived (stable), working on a series of releases over time

Related Reading