Category Archives: DA 2.0

Is it Disciplined Agile Delivery (DAD) or Disciplined Agile (DA)?

The quick answer is of course “Yes”.  😉

A couple of years ago we caused a bit of confusion when we expanded the scope of the Disciplined Agile Delivery (DAD) framework to address the activities of an information technology (IT) department.  When we did this we realized that the scope of the framework and the name no longer matched, so we decided to rebrand to be simply the “Disciplined Agile (DA)” framework.  Having said that, sometimes it makes sense to say DAD and sometime DA depending on what you’re focusing on at the time.

The Scope of Disciplined Agile (DA)

As you can see in the following diagram, which depicts the scope of the DA framework, it’s clear why there has been some confusion because the DA framework covers a lot of ground.

Scope of Disciplined Agile

Let’s explore each aspect depicted in the diagram:

  1. Disciplined Agile Delivery (DAD).  DAD addresses all aspects of solution delivery from beginning to end, in a streamlined manner.  This includes initial modelling and planning, forming the team, securing funding, continuous architecture, continuous testing, continuous development, and governance all the way through the lifecycle.  The framework includes support for multiple delivery lifecycles, including but not limited to a basic/agile lifecycle based on Scrum, a lean lifecycle based on Kanban, and a modern agile lifecycle for continuous delivery.
  2. Disciplined DevOpsDisciplined DevOps is the streamlining of IT solution development and IT operations activities, and supporting enterprise-IT activities, to provide more effective outcomes to an organization.
  3. Disciplined Agile IT (DAIT).  As the name suggests DAIT addresses how to apply agile and lean strategies to all aspects of IT.  This includes IT-level activities such as enterprise architecture, data management, portfolio management, IT governance, and other capabilities.
  4. Disciplined Agile Enterprise.  A Disciplined Agile Enterprise is able to anticipate and respond swiftly to changes in the marketplace.  It does this through an organizational culture and structure that facilitates change within the context of the situation that it faces.  Such organizations require a learning mindset in the mainstream business and underlying lean and agile processes to drive innovation.

Some History

The first “1.0 release” was the original Disciplined Agile Delivery book in June of 2012.  As the title suggests the focus was on DAD, although it laid the groundwork for Disciplined DevOps in that it baked in the development side of DevOps right into DAD.  In 2015 we began publishing our work in both Disciplined DevOps and Disciplined Agile IT (DAIT) and renamed the framework to Disciplined Agile (DA) to reflect this expanded scope.  Now, in 2017, we are beginning to flesh out Disciplined Agile Enterprise strategies and will soon begin the share them here on this site.

What do Reuse Engineers do?

Reuse engineering is an important, and arguably advanced, aspect of the Disciplined Agile framework.  The challenge is that reuse engineering requires significant discipline and organizational maturity to be successful, hence we tend to run into far more talk about reuse than action.  Having said that, many organizations have been very successful with reuse.  The following diagram overviews the internal workflow of a reuse engineering team, capturing key activities (the blue bubbles) that the team performs.  This blog posting explores what reuse engineers do in practice.

Internal workflow of a reuse engineering team

Let’s work through the primary activities performed by reuse engineers:

  1. Guide teams in reuse.  An important activity for reuse engineers is to provide guidance to delivery teams regarding what is available for reuse, how to go about accessing and applying the reusable artifacts, and educating teams in why reuse is important to both the team and to your organization.   Very often a team’s architecture owner will collaborate with the reuse engineering team to bring a reuse engineer into the team at the right time.
  2. Obtain assets.  Reuse engineers will obtain reusable assets from a variety of sources, including from the marketplace and from internal delivery teams.  Based on the various organizational roadmaps, and the needs of the delivery teams that they’re working with, the reuse engineering team will often work with delivery teams to identify and obtain the appropriate assets from the marketplace.  The goal is to find assets that fit the needs of individual teams in a way that aligns with the direction of the organization.  Furthermore, reuse engineers tend to monitor what delivery teams are doing, often by working closely with the organization’s enterprise architecture team and the architecture owners on delivery teams, to help them identify potentially reusable assets.  When a team believes it has built something that is potentially reusable by others, or when the reuse engineers believe they have done so, then the reuse engineers will work with the team to understand and harvest that asset.
  3. Publish reusable assets.  An asset is potentially reusable when it is of high quality, it is appropriately documented, one or more examples exist of how to use it, and it is findable by others.  The publishing process ensures that all of these criteria are true.  The reuse engineers will do the work to publish the asset, refactoring and documenting it as needed and harvesting any usage examples if available (and creating some when not).  After doing so, they will save the asset and its related supporting artifacts into your organization’s reuse repository, announcing the availability of the new asset after doing so. Note that reuse repositories, also called asset managers, have fallen out of favor in the past few years due to the complexity of the available products on the market and the propensity of organizations to use products like Git or Microsoft SharePoint as repositories.
  4. Configure asset for specific use.  Reuse engineers will often work with a team to help them to configure an asset for specific use.  The goal is to make it as easy as possible for others to reuse existing assets, thereby increasing the chance of rate of successful reuse within your organization.
  5. Integrate reusable assets into a solution.  Reuse engineers will often work with delivery teams to integrate a reusable asset into their solution, once again to make it as easy as possible for teams to reuse existing assets.  Interestingly, an important aspect of harvesting an asset for reuse is to help the source team to integrate the improved version of the asset back into their solution.  This helps to increase the likelihood that teams will offer up potential assets for harvesting and publishing.
  6. Evolve reusable assets.  Assets need to evolve over time to reflect changing requirements and implementation technologies.  The implication is that the owners of the assets, often the reuse engineering team, will need to evolve their assets, publish new versions, and deprecate old versions.  This is work that must be funded and supported properly.

If your organization is serious about reuse engineering then they will explicitly fund a reuse engineering team and enable them to work in the manner that we’ve described here.  For more information, you will find the article Reuse Engineering to be of value.

The Disciplined Agile Poster v2.1

DAD Poster People 7-4

On Wednesday, September 21 2016 we ran a webinar overviewing the latest version of the DA poster. A recording of the webinar can be viewed online from the DAC Webinars page and a PDF of the slide deck is posted on Slideshare entitled The Disciplined Agile IT Department.

During the webinar we received several questions, many of which we answered, although we did run out of time and did not get to all of them. As usual, we’ve written a blog posting to answer these questions. We’ve organized the questions into the following topics:

  1. The poster and terminology
  2. Organizational issues
  3. Adoption of DA
  4. Learning more
  5. Miscellaneous

 

1. The Poster and Terminology

1.1 What’s the significance of the concentric circles in shades like white, blue yellow? How do we look at those groupings?

Those are groupings on the poster. There are headings, they sort of look like ribbons, indicating the scope of each one: Delivery, Disciplined DevOps, IT.

1.2 What’s the best way to read or traverse the diagram (for beginners)? left–>right, top–>bottom, inside–>outside … ?

It’s a workflow diagram that is cyclic, so in a way it doesn’t matter. However, it does make sense to start in the top left corner if you like.

1.3 What was the thought behind the “process blade”?

We have a detailed article about the term process blade here.

 

2. Organizational Issues

2.1 What range of IT dept sizes is DA best suited for? Is there a sweet spot?

We’re seeing Disciplined Agile being adopted by IT departments as small as 40 people and as large as 20,000+. The issue really isn’t the size of the IT department but rather how well it is able to support the rest of your organization,

2.2 What is a role played by Chief AO and Chief PO in terms of Solution Delivery? Where can we put DAD Roles in the DA poster?

If you visit the DA home page there is the poster on there. There is also a button in the bottom left corner leading to a beta version of the diagram with the roles on it.  The IT-level roles are overviewed at Disciplined Agile Roles at Scale.

2.3 Where would someone like say a “Peoplesoft Administrator” fit into the new (beta) DA 2.x picture. I’ve seen loads of similar people/roles in a Agile Transformation initiatives at a Bank and hence the ask.

This sounds like a specialized version of an Operations Engineer to me. Also, sounds like more of a position than a role.

 

3. Adoption of DA

3.1 Do you have any examples of organizations in Canada (besides IBM) that are using DA or DAD framework?

There are many organizations using Disciplined Agile although this is not a complete list nor is it broken down by country. If your organization is using DAD, and you would like to get on this list, please reach out to us.

3.2 Any recommendation for terminologies/nomenclature in Agile Portfolio Management? sub-task=>story=>Epic=>Initiatives/Product=> Themes??

Use the terminologies and techniques that are right for your organization. There is no standard terminology in agile, nor will there ever be. Furthermore, every organization is unique so one process size does not fit all. You need to tailor your approach to address the situation that you face.

 

4. Learning More

4.1 Will there be a new book re IT and DevOps additions? When?

Yes, we have a book underway right now. Having said that, we always publish to the web first. We have published a lot here on the Disciplined Agile site, including a detailed article on Disciplined DevOps.

4.2 Is a new version of the big book coming up? Any updates to the Certification or tracks wrt. DA 2.x?

At the present moment we do not intend to publish an update to the big book. We find publishing smaller books, such as Introduction to DAD, to be more effective, and that’s what we’re currently focused on. When we publish the new book we will also be updating the certifications to reflect that, so please stay tuned.

4.3 Your current book says very little about scaling, but with the example of Barclay’s 30K IT Dept, will the new book have more “scaling” content?

We have published a fair bit about scaling online. The page Agility at Scale is a good starting point.  Also, Disciplined Agile Delivery (DAD) provides a foundation from which to scale, so I would argue we’ve written quite a bit, even in the first book.

4.4 Where I can find guidance for process blades? Will new version of book cover it?

We have published detailed information about the process blades at the DA site. A good starting page is Strategic Agility at Scale. Yes, we will be covering this material in the new book.

4.5 Will the download posters be updated to 2.1? Lot nicer to follow and look at 🙂

The poster is available for download, in various formats, from Disciplined Agile Posters.

 

4.6 This is very new in Europe. What are your plans to expand your DAD coverage there?

We are actively looking for business partners, including both trainers and consulting firms, in Europe, Asia, and Australia. For more information, see our Certified Disciplined Agile Instructor (CDAI) Program and our Certified Disciplined Agile Partner Program.

 

5. Miscellaneous

5.1 Governance is depicted at lower left (and appears IT centric). Isn’t the reality that each of the artifacts (and there are lots! on this poster) can be subjected to a simple artifact governance? Does DA leverage this?

Governance is built right into all aspects of the DA framework. The IT Governance blade is purposefully IT centric because that is the scope that we chose to address. It is in fact one part of your organization’s overall governance strategy (often referred to as a control strategy, yuck).

5.2 Does DA group recommends any tools for Agile?

We try to avoid recommending tools because it really does depend on your situation. However, we do have a good relationship with Blueprint Technologies and have been working with several of the agile management tool vendors. We do have a page discussing tool support for DAD but it’s not comprehensive.

5.3 Should operations teams run one of the lifecycles like a software delivery team? Should support?

Operations teams and support teams should definitely have a method that they follow to do their work. Given that they often need to respond to help requests, or address production problems, they very likely need to consider adopting a lean lifecycle for that type of work. In particular the Continuous Delivery lifecycle is likely closest to what they need, but this of course depends on the situation.

5.4 Where do you see DA complementing SAFe or vice versa.

In many ways SAFe is an instance of a portion of DA. Where SAFe prescribes an approach DA gives you a range of options and asks you to choose the right approach for the situation that you face.

 

 

Why is Disciplined Agile So Complicated?

ConfusedWe often hear the refrain that Disciplined Agile (DA) is too complicated, that it needs to be simpler. Believe me, we’re all for simplicity and we do everything that we can to make DA as simple as possible. However, to be fair, we often find that the people complaining about this are often coming at the situation from a different point of view than we are.

With this blog we work through how why the complications encompassed by DA reflects the reality that we face in modern enterprises. To do this let’s explore why DA may appear to be complicated at first. This blog explores the following issues:

  1. There is a natural complications in what we do
  2. Enterprise solution delivery is inherently complicated
  3. Enterprise IT is inherently complicated
  4. Choice is good, but having choices adds complications
  5. People underestimate the inherent complications of the familiar
  6. DA purposefully includes some questionable choices
  7. Most people prefer to focus on a small part of the overall process
  8. What would you take away?
  9. What would you like to add?

There is a Natural Complications in What We Do

Software development by itself is complicated: we need to work closely with stakeholders to understand their needs, we need to architect and design solutions, we need to build or configure these solutions, we need to test them, we need to deploy them, we need to organize this effort somehow, and many other things. There’s clearly a bit of natural complexity in software development. Furthermore, the overall IT process surrounding software development adds even more complications to operate, manage, and govern our overall IT ecosystem.

This is why we get paid what we get paid – if it was easy, organizations could find a multitude of lower-skilled, and lower-paid, people to do this work.

 

Enterprise Solution Delivery is Inherently Complicated

Complex process

The Disciplined Agile Delivery (DAD) portion of the DA framework addresses solution delivery in enterprise-class organizations. Sometimes people who have only worked in startups or small companies don’t appreciate the realities of enterprise-class development. A small company that has been in business for a few years is very different than a large organization that has several decades of legacy systems, legacy processes, and legacy thinking in place. Adopting agile and lean ways of working when you effectively have a clean slate to start from is a very different proposition than working in an organization where you need to respect and evolve the existing legacy ecosystem.

But don’t other, simpler methods such as Scrum work in these settings? Yes, they potentially do, but they address a much smaller scope than does DAD. Scrum is less complicated because it only looks at a very small portion, likely not even 5%, of the software delivery process. The focus of Scrum is on a few collaboration patterns for organizing small software construction teams and for managing changing requirements. It purposefully does not address the full project delivery lifecycle from beginning to end. Nor does Scrum address technical practices for architecture, design, testing, programming, modeling, documentation, deployment, and many other aspects of solution delivery. DAD, on the other hand, purposely addresses all of these aspects of software delivery from beginning to end in a streamlined manner. And Scrum only describes a single way of working, what DAD calls the Agile/Basic lifecycle, whereas DAD includes five lifecycles (Agile, Lean, Continuous Delivery: Agile. Continuous Delivery: Lean, and Exploratory/Lean Start Up) to choose from to address a great range of needs. So yes, as a framework DAD is much more complex than Scrum because DAD answers the multitude of questions that Scrum leaves up to you.

Interestingly, from the point of view of enterprise agile transformation, DAD is a less complicated solution to adopt because it’s already done the “heavy lifting” for you on the process side of things.  We wrote a blog a few years ago about how it’s easier to right-size your process by starting in the middle with something like DAD than it is to start at the “simple bottom” with Scrum.

 

Enterprise IT is Inherently Complicated

Disciplined Agile IT (DAIT) extends DAD (and Disciplined DevOps) to look at all of IT. The workflow of a Disciplined Agile IT department is depicted in the following diagram, and that diagram is merely a high-level overview. Many of the challenges that developers like to complain about – dysfunctional governance, ineffective enterprise architecture, slow data management, non-existent reuse, questionable HR processes, and many more – DA chooses to explicitly address. Because DA deals with the much wider range of enterprise IT issues than just software development it encompasses more complexity than many developers may be comfortable with, or even aware of.

DA addresses this bigger picture because our philosophy is to provide coherent, pragmatic advice to help organizations address the challenges that they face in improving their processes. In fact, the DA framework appears to be the only source of information that addresses enterprise agile IT in a coherent and comprehensive manner.   Without a holistic vision such as this an organization will end up development a piece-meal strategy where the individual parts may be effective on their own but do not integrate well as a whole. Not looking at the entire IT picture at once is the primary cause of organizational dysfunctional in your department today, with the DA framework you can avoid this problem as you evolve into an agile/lean way of working.  BTW, you can download a copy of the workflow diagram shown above from the Disciplined Agile Consortium (DAC) posters page.

 

Choice is Good, But Having Choices Adds Complications

Disciplined Agile looks at a range of situations, giving you choices. Other methods and frameworks, such as LeSS and SAFe, prescribe a single way of working.   Certainly a small development team will work differently than a medium-sized development team which works differently than a large team. A team that is co-located will work differently than a team spread across a single building, than a team spread across several buildings in the same city, than a team spread across the world. A team working in a regulatory environment will work in a more sophisticated way than a team in a non-regulatory environment. A team where everyone works for your company will work differently than a team where some of the work is being outsourced. A team facing a simple domain problem will work differently than a team facing a complex problem. And so on. Although many people just want to be told what to do, they just want a single way of working given to them, that desire for prescription is a recipe for disaster in modern IT organizations. You have a range of teams facing a range of situations: One process size does not fit all.

Many choices

Having choices is definitely complicated. This is similar to “needing a new outfit”, going to the store, only to be overwhelmed by the myriad of choices presented to you.

Small number of choicesOne way to deal with the this is to divide and conquer. Recognize that deciding on an outfit that is right for you is actually a collection of simpler choices. For example, your need to choose the right shirt, the right pants, the right shoes, and so on. Of course you shouldn’t make these choices in isolation because your outfit needs to work together as a whole.  You either need to coordinate your decisions and effectively make them in parallel or if you prefer to make decisions one at a time then be prepared for your shirt choice to limit your follow-on clothing choices.

Let’s bring the conversation back to software process. In Disciplined Agile Delivery (DAD) we called out a collection of process goals that a team should fulfill in some way to be successful at agile solution delivery. These goals included exploring the initial scope, putting the team together, developing a consumable solution, coordinating activities, and deploying the solution into production to name a few. Each process goal is overviewed by a process goal diagram, the one for Explore Initial Scope follows below. Each goal is organized into a collection of process decision points, each decision point has options, and each option has advantages and disadvantages. Where one agile method might advise you to write a collection of epics and user stories to identify the initial scope, in DAD we say that you need to explore how people will use your solution (and writing epics and user stories are two of many options available to you), you may need to explore the user interface, you should consider to what extent (if any) the initial requirements should be documented, how you will go about eliciting requirements, and other important decisions. Ideally, if you want to be effective, then you want each team to own their own process and make the choices that are best for them given the situation that you face.

Explore Initial Scope

 

 

 

Back to the clothing analogy. Just like Scrum and SAFe prescribe one way of working, you could similarly take a prescriptive approach to shopping for new clothes. This is the equivalent of saying that you will be successful if you wear a red polo shirt, blue pants, blue socks, and black shoes. That may be great advice if you are working as a food server at your local restaurant chain but horrible advice if you need an outfit that is appropriate for a wedding, or for working in a formal office, or for going to the beach. When buying the right clothing you need first need to understand the context and then hopefully have several choices available to you. You want to be able to choose the right shirt for you, not the one prescribed to you. You want to choose a nice pair of pants or a skirt that complements that shirt, and so on. Yes, it’s much easier just to buy exactly the clothes that you’re told to, but it doesn’t give you as satisfying a result in most situations.

In Disciplined Agile we extended this choice-driven approach to IT-level activities such as Portfolio Management, Enterprise Architecture, Reuse Engineering, Data Management, and others. The following diagram is the process goal diagram for Enterprise Architecture, depicting the process decision points that your EA team should consider addressing and a range of options for each choice.

Agile Enterprise Architecture

People Underestimate the Inherent Complications of the Familiar

Casual guy

When most people are asked what the gentleman in the picture is wearing, they’ll say a blue dress shirt and slacks. However, he’s also wearing shoes, socks, a belt, and underwear (we hope).   It is quite common for people to abstract away, to ignore, details that are familiar to them – the “shirt and slacks” answer abstracted away the details of the entire outfit. However, for someone to whom western clothing is new, this “simple outfit” appears quite complex to them until someone helps them to understand it.

The exact same thing happens in the software world. When asked what we do it’s easy to casually say that we work with stakeholders to understand what they want, we write some software, and then we deploy it. Of course the reality of what actually goes on is a lot  more complex than that.

We invite you to spend a few minutes and jot down all of the activities that your team does to actually build and deploy software in practice. Pretty long list, isn’t it? And for every strategy on that list, you’ve selected one of many options available to you.

 

DA Purposefully Includes Some Questionable Choices

Good and bad choicesWe all make choices in our diet. Some of those choices are good and some of those choices are rather bad for us. We know that we’re making poor choices yet we still choose to do so, perhaps because that’s the best we can do at the time or simply because that’s what we feel like eating right now.

It’s exactly the same when it comes to process – we have a range of choices and some of them are better for us than others. For example, consider the choices we have when it comes to the level of detail that we capture when exploring the initial scope. We could choose to: write a very detailed requirements specification; write a light specification (perhaps using index cards, whiteboard sketches, and a bit of overview documentation); write a simple bulleted list of goals; or not capture any requirements information at all. Many agile purists will say that writing a detailed requirement specification isn’t agile, and in the vast majority of situations it isn’t, although we have seen life-critical regulatory situations where it is appropriate.   But, what if you’re in a situation where detailed requirements specifications aren’t appropriate yet someone is demanding that you create one? Agile purists will likely get into religious arguments with this person: the traditionalist will argue that their way is best and the purist will argue that there way is best, but in the end the person with the most political clout will win. With a DAD-based we recognize that there is a range of options available to you, including writing detailed specifications. But we take it one step further and are clear about the advantages and disadvantages of each approach and when the approach is appropriate.   Now you can have more intelligent conversations and pragmatic about your process choices.   When you get into situations such as this you can go beyond the “but that isn’t agile” refrain to have coherent reasons that as to why one strategy is better for another strategy given the situation that you face. Choice is good.

 

Most People Focus on a Small Part of the Overall Process

Locally focused

Many people choose to focus on their part of the job, which is fair enough. But what about all of the other activities that your team performs from beginning to end? You may be a developer focused on software construction, but what about all of the initial inception work that occurred, such as gathering initial requirements, putting the team together, and getting funding for construction that occurred before you began your work? What about the activities that occur within other teams that interact with, often to support, your team? For example, there may be some enterprise architects responsible for evolving and supporting a technical roadmap for your organization, there may be an infrastructure team responsible for operating your technical environment, and there may be people responsible for people management/HR activities (such as seeing that you get paid). Disciplined Agile looks at the holistic picture, not just at your piece of the overall puzzle. Just because you’re not involved with data management, or portfolio management, or operations doesn’t mean that those activities, and the teams that perform them, aren’t important to the overall success of your organization.

 

What Would You Take Away?

Now that you understand the overall scope of DA, what would you remove? We’re asking this question from the point of view of:

  • The complexity faced by modern enterprises
  • That you need choices if you’re to actually own your process
  • That we’re considering the overall picture, not just your part of it

If you think Disciplined Agile (DA) contains something that it doesn’t need, please add a comment at the end of this blog.

 

What Would You Like to Add?

Ha! Every single time we’ve had this conversation with someone, and they were willing to consider the issues above, they’ve told us that we needed to include one or more techniques that they’ve found effective in practice. EVERY. SINGLE. TIME.  In short, the conversation goes from DA is too complex to DA is not complex enough.  Argh!

So, once again, please add a comment at the end of the blog for anything you think we’re missing.

 

A Few Parting Thoughts

Software development, IT in general, and in fact your organization is a complicated game with many moving parts that are evolving all of the time. It’s natural for us, as human beings, to want simple answers. But sometimes the simplest answer can still be quite complicated. Simplistic answers may be more attractive, and in the short term or in very narrow situations they may in fact be a good solution for you, but more often than not they’ll make your situation even worse.   In Disciplined Agile (DA) we actively strive to drive the complications out of the software process but at the same time we have the courage to look at the bigger picture and explicitly address the range of issues that modern enterprises face in practice. With DA we’re working together to make the process as simple and streamlined as possible.

Puzzle - canstockphoto18141553 Small

Lean IT Governance: A Goal-Driven Approach

Governance is a common thread throughout all aspects of the Disciplined Agile Framework. Delivery governance activities were built right into Disciplined Agile Delivery (DAD) v1.x, each of the Disciplined Agile 2.0 process blades include a governance process factor, and there is an IT Governance process blade that coordinates all IT governance activities.

The following process goal diagram overviews the potential activities associated with a disciplined approach to IT governance.  These activities are typically performed by a variety of people within your organization. In the Disciplined Agile framework each of the process blades includes activities around governing the activities encapsulated by that blade. For example, the Enterprise Architecture blade includes architectural governance activities and the Data Management blade includes data/information governance activities.

Disciplined Agile IT Governance

The process factors that you need to consider for IT governance are:

  1. Governance view. There are many potential aspects, or perhaps subsets, to IT governance including security governance, data governance, delivery governance, and more. Too many organizations make the mistake of treating each of these issues separately, which is easy enough to do given the different focus of each one. The Disciplined Agile framework promotes a more holistic, integrated view that results in a streamlined, consistent, and effective governance strategy. Another common mistake is to focus on portfolio governance over other aspects and have your Portfolio and Project Management Office (PPMO) be responsible for IT governance. PPMO-led governance efforts tend to result in documentation-heavy, bureaucratic strategies instead of lean, risk-based approaches.
  2. Develop metrics. Metrics define the measurements that you will take to gain insight into what has happened, what is happening, and hopefully what may happen in the future. The least effective approach to metrics is to have a standard set that all teams are expected to collect whereas the most effective is a context-sensitive approach such as a light-weight implementation of Goal Question Metric (GQM).
  3. Measure. The measures themselves can be collected either manually or automatically (usually as the result of tool or system usage). We have found that a combination of the two is required – although automated metrics are inexpensive, accurate, and real-time you cannot always automate all of the measurements that you need to collect.
  4. Monitor. Information radiators are sufficient in smaller organizations, but automated dashboards in combination with direct interaction with teams are also needed in modern enterprises. Traditional strategies, such as status reports or status meetings, do not prove to be effective in practice nor do they provide an honest assessment of what is actually occurring.
  5. Guidance detail. An easy and important way to support governance within your organization is to have commonly accepted guidance, including standards and guidelines, for teams to follow. We suggest that you keep this guidance lightweight, starting with high-level rules but aiming towards principles whenever possible.
  6. Develop guidance. Guidance is ideally developed collaboratively with a combination of practitioners and experienced enterprise IT professionals who understand the bigger picture.
  7. Define roles and responsibilities. The definition of roles and responsibilities is an important aspect of your overall governance strategy as it describes what is expected of people. We’ve found that the most effective way to do this is to start with the roles and responsibilities described in the Disciplined Agile framework and then collaboratively evolve them from there. The framework ha both delivery team roles as well as enterprise IT roles defined.

Manage IT risk. Risk management for the entire IT portfolio, including both in-progress development teams as well as operational risks. Small risks on individual teams can add up to a large risk across your organization. For example, if many teams adopt a new and relatively unproven framework and that framework is then abandoned by its creators (think about how many open source projects or new companies flounder) then you have a serious problem. Similarly, when multiple teams start addressing a similar business opportunity and that line of business dries up or is legislated away.  Although risk management is addressed on delivery teams via the goals Identify Risks and Address Risk, their focus is on risk management within a team as opposed to risk management across all of IT, or even across all of your organization.

Related Reading:

Lean Governance Strategies

Close collaboration

There are several strategies that you can adopt to promote a lean approach to governance. These strategies include:

  1. Empowered teams. Teams should have both the authority and responsibility to fulfill their mission. Agile teams should be allowed to be self organizing, the implication being that the team itself determines who will do what work (the team doesn’t have a manager telling them what to do).   Related to that the team should own their process, which is the agile way of saying that the team is allowed to determine how it will work together and as the team learns it will evolve the process that it follows – of course the team will be guided and constrained by your organization’s governance strategy.
  2. Enterprise awareness. One of the principles of the Disciplined Agile (DA) framework is that you should work in an enterprise aware manner. It is based on the observation that your team is only one of many teams, so therefore you need to consider the bigger picture when you’re working and do what is best for your organization, not just what is convenient for you. Promoting enterprise awareness throughout your organization is a fundamental enabler of lean governance.
  3. High-level roadmaps. High-level technology and business roadmaps, produced by your Enterprise Architecture and Product Management efforts respectively, will provide important guidance to your teams. These roadmaps capture the vision as to where your organization is heading, helping teams to understand what the overall vision is, to focus on what is important to your organization, and to help guide and constrain their decisions.
  4. Collaborative enterprise IT professionals. The DA framework includes several process blades, including Enterprise Architecture, Reuse Engineering, Data Management, and others that address enterprise level concerns. The people performing these activities should work closely with their customers, the delivery teams and stakeholders, in a collaborative and evolutionary manner. This promotes better governance for two reasons. First, by getting the vision, knowledge, and skills of the enterprise professionals into the hands of their customers it increases the chance that they work in a manner that is consistent to the needs of your organization. Second, the enterprise professionals want to get feedback from their customers and learn more about what their customers need from them. This enables them to be more effective at serving the enterprise and guiding their customers.
  5. Enterprise IT knowledge in teams. Although roadmaps and enterprise IT professionals collaborating with development teams help, it is far more effective to have people with enterprise knowledge embedded within the development teams. This is why we promote the idea that Architecture Owners (AOs) should not only work closely with the enterprise architects but should preferably be a member of the EA team. Similarly, Product Owners (POs) should either work closely with the product management team or preferably be a member of that team.   And it’s possible to do better than that – if team members are truly enterprise aware and are continuous learners, then it is reasonable to expect them to pick up enterprise knowledge over time. The more knowledgeable people are about their organization and its goals the less supervision/governance they will need.
  6. Automated dashboards. Automated dashboards, a strategy that we’ve referred to as development/operational/IT intelligence in the past, is a scalable form of information radiator. With just a bit of work you can take the information being generated by your tools and, using business intelligence (BI) technologies, populate team and even portfolio dashboards in real time. These dashboards provide important information that teams can use to manage themselves as well as governors to monitor what is happening within your organization. This enhances governance because when you get better quality information into people’s hands and they are more likely make better decisions.
  7. Defined roles and responsibilities. Defined roles and responsibilities help people to understand who does what, what are they are responsible for and when they need to collaborate with others. This is an important aspect of governance because critical guidance about how people will need to interact with one another.
  8. Defined organizational structure. You may choose to have a hierarchy of teams, a network of teams, a collection of circles (along the lines of holocracy), or combinations thereof. This is important to your governance efforts because people need to know what are the teams and how do they interrelate within your organization.
  9. Common guidance. Guidance – standards and guidelines – is important to your governance effort because it helps people to understand how they can develop consistent assets which in turn are easier to understand and evolve. Common development guidance includes coding standards, data naming conventions, user interface (UI) design guidelines, security standards, and more. This guidance should be straightforward, ideally be supported through automation, and collaboratively developed.
  10. IT governance team. People, typically senior people, are responsible for IT governance. The team, who is on it and what they do, should be defined and publicly known by those being governed. Everyone knows who the governors are and what they do, so that your governance strategy is open and transparent.

In the next blog posting in this series on governance we’ll overview the process goal diagram for IT governance.

 

Related Reading:

Lean vs. Traditional IT Governance

Arguing

Traditional IT governance typically focuses on a command-and-control, documentation-based approach. Teams are expected to adopt and then follow corporate standards and guidelines, to produce (reasonably) consistent artifacts, and to have those artifacts reviewed and accepted through a “quality gate” process. The following diagram overviews such a process for an IT delivery team – in practice we’ve seen several traditional governance lifecycles that were more complex than this and a few that had less quality gates.

Traditional IT delivery governance

Traditional governance strategies often prove to be both onerous and ineffective in practice due to the focus on artifact generation and review. For example, delivery teams will often produce required artifacts, such as requirements documents or architecture documents, solely to pass through the quality gate. The implication is that these artifacts often reflect what the team believes the governing body wants to see, and that may not be what the team is actually doing. The result is a governance façade that often injects risk, cost, and time into the team efforts: the exact opposite of what good governance should be about.

Lean IT governance, on the other hand, is a lightweight approach to IT governance that is based on motivating and enabling IT professionals to do what is best for your organization. Lean IT governance strives to find lightweight, collaborative strategies to address governance areas. It does this by focusing on risk mitigation, not on artifact generation, by leading people not by commanding them, and by enabling people by making the “right things to do” the “easy things to do”.

The following table compares and contrasts traditional and lean approaches to IT governance. The table also indicates where each governance area is addressed by the Disciplined Agile (DA) framework.

Governance Area Traditional Strategy Lean Strategy Disciplined Agile Implementation
Common roadmaps – What should we be doing as an organization? How should we be doing it? Detailed technical and business architecture models

Architectural reviews to ensure conformance

High-level technical and business roadmaps/models

Architecture owners embedded in teams

Enterprise IT professionals work collaboratively with teams

Product Management is responsible for producing and supporting business roadmap

Enterprise Architecture is responsible for producing and supporting technical roadmap

Decision rights and processes – Who is responsible for doing and deciding things? Defined roles and responsibilities

Defined organization structure

Teams are empowered with responsibility and authority to fulfill their mission

Defined roles and responsibilities

Defined organization structure

Self-organizing teams with appropriate governance

Robust set of agile roles defined for both delivery teams and for enterprise IT

People Management is responsible for supporting creation of effective teams

Exception and escalation processes – How do we work together to address unexpected issues or problems? Defined exception and escalation procedures

Defined roles and responsibilities

Defined organizational structure

Teams are empowered with responsibility and authority to fulfill their mission

Defined roles and responsibilities

Defined organization structure

Defined Enterprise IT workflow of DA 2.x

Self-organizing teams

Teams are enterprise aware and expect to work with each other

Defined roles and responsibilities

Governing body – Who is responsible for governing and how do they go about doing it? IT Governance Team

(Optional) Topic specific (e.g. data governance, security governance) teams formed to address those specific issues

IT governance team

Topic-specific governance is built into those processes

IT governance team formed if and when needed

Enterprise IT teams self-organize to address topic-specific governance activities

Investment in IT – How can we spend money on IT wisely? Quality gate(s) for assessing financial viability Light-weight milestones

Continuous financial review

Portfolio Management is responsible for making and monitoring IT investment decisions

Light-weight milestones: Shared Vision and Project Viability

Product Owners are responsible for monitoring team finances

Iteration wrap up includes explicit go-forward decision

Knowledge sharing – How can we learn together and promote common understanding across the organization? Training and education programs

Coaching and mentoring

Communities of practice (CoPs)/Guilds

Centers of Excellence (CoEs)

Same Continuous Improvement focuses on sharing learnings across teams

Improve Team Process and Environment process goal

Support for CoPs and CoEs

Metrics and monitoring – How can we gather intelligence to make better decisions? Metrics gathering (automated and manual) and reporting

Status reporting

Goal-Question-Metric (GQM)

Automated dashboards

Manual metrics gathering (as needed, very limited)

Light-weight GQM

Automated dashboards (Development and Operational Intelligence)

Support for light-weight GQM

Metrics and monitoring built into each process blade

Procedures and guidelines (guidance) – How do we do what we do? Defined, and often comprehensive, guidance and templates Critical guidance is captured in a light weight manner

Collaborative development of guidance

Teams are enterprise aware and expect to follow appropriate guidance

Each process blade includes development of appropriate guidance

Quality – Is the quality of our IT assets sufficient? Quality gates

Reviews

Automated quality metrics

Organizational guidance

Automated quality metrics

Organizational guidance

Build quality in from the start

Quality strategies built into delivery process via Move Closer to a Deployable Release, Improve Quality, and Align with Enterprise Direction process goals

Reuse Engineering promotes ways for teams to rescue and reuse assets

Enterprise Architecture promotes greater consistency across teams via common technical roadmap and strategy

Data Management responsible for promoting greater data quality

Reward and compensation – How do we recognize the work of our staff and pay them appropriately? Human Resources (HR) program for IT Same People Management addresses reward and compensation strategies
Risk mitigation – Have we taken on an acceptable level of risk given our current situation? Risk monitoring via status reporting and reviews of artifacts Risk monitoring via automated dashboards and close collaboration with teams Portfolio Management process blade addresses IT-level risk

Identify Initial Risks and Address Risk process goals build risk mitigation right into delivery process

Risk-based milestones built into delivery lifecycles

Roles and responsibilities – Who does what? Many narrowly defined roles

Roles and responsibilities are well defined

 

Fewer, more widely defined roles

Roles and responsibilities are defined

 

Delivery team roles and responsibilities defined

IT roles at scale defined

Status reporting – What is going on? Regular written status reports

Automated dashboards

Automated team dashboards

Automated portfolio dashboard

Automated dashboards (Development and Operational Intelligence)

Related Reading:

What is Lean IT Governance?

Auditor

As with most things in IT, there is no standard definition of what IT governance is. For example, the IT Governance Institute provides this definition:

“IT Governance is the leadership, organizational structures and processes to ensure that the organization’s IT sustains and extends the organization’s strategies and objectives.”

Gartner, on the other hand, offers this definition:

“IT governance (ITG) is defined as the processes that ensure the effective and efficient use of IT in enabling an organization to achieve its goals. IT demand governance (ITDG) is the process by which organizations ensure the effective evaluation, selection, prioritization, and funding of competing IT investments; oversee their implementation; and extract (measurable) business benefits. ITDG is a business investment decision-making and oversight process, and it is a business management responsibility. IT supply-side governance (ITSG) is concerned with ensuring that the IT organization operates in an effective, efficient and compliant fashion, and it is primarily a CIO responsibility.”

In Disciplined Agile, we promote the following definition:

“Lean IT Governance is the leadership, organizational structures and streamlined processes to enable IT to work as a partner in sustaining and extending the organization’s ability to produce meaningful value for its customers.”

As you can see in the following diagram, IT governance is part of your organization’s overall corporate governance strategy. IT governance encompasses several more narrow forms of governance, including but not limited to the governance of IT delivery/development, data/information, IT security, IT investment, enterprise architecture, and IT operations activities.

IT Governance in Context

IT governance typically addresses areas such as:

  • The effective and timely investment in IT to sustain and extend the organization over the long term
  • The evolution and support of roles and responsibilities to streamline how people work together
  • Definition of decision rights and decision making processes to streamline interactions between people
  • The evolution and support of common procedures and guidelines to ensure appropriate commonality of activities and artifacts
  • The evolution and support common roadmaps to guide the efforts of IT teams
  • The monitoring of activities to provide insight into their effectiveness
  • Formation of a governing body that is responsible for guiding governance activities
  • Definition of exceptions and escalation processes to streamline critical interactions
  • Creation of a knowledge sharing strategy to grow individuals, teams, and the organization as a whole
  • The support and monitoring of risk mitigation strategies to promote appropriate and holistic adoption of IT solutions
  • Adoption of a reward and compensation structure to support the attraction and retention of excellent staff
  • Status reporting to share information throughout the organization

In future blog postings we will explore why IT governance is important, the differences between traditional and lean approaches to IT governance, and the activities addressed by IT governance.

Related Reading:

The Agile Tractor Engine Analogy

Since 2001 agilists have been focused on finding ways to improve how software is developed.  We’ve adopted fundamental strategies such as regular coordination meetings, regular demos, product owners, developer regression testing, retrospectives, and incremental releases of working software.  Disciplined teams have adopted more advanced strategies such as active stakeholder participation, continuous integration (CI), test-driven development, continuous documentation, continuous deployment, measured improvement, and incremental releases of consumable solutions (to name a few).  We experiment with new techniques to learn what works for us in the situation that we face, improving our approach as we do so in an incremental kaizen-style manner over time.  In effect we are finding ways to tune our “development engines” so that we can deliver more valuable functionality, to reduce our cycle time, and to be more productive as a team.  This is very similar to a Formula One team who over the years improves their racing car engine to deliver more power and more speed for less fuel consumption so as to help them win the race.

Race car engine

Our challenge is that a race engine alone doesn’t win the race, what we really need is a race car. We see too many agile teams, who on their own are doing a great job at improving the way that they work, get bogged down by the organizational environment in which they work.  This is particularly true in established enterprises that have been in operation for decades and sometimes even centuries.  Your development team tries to work in an agile manner but they’re forced to conform to your PMO’s existing traditional governance strategy that requires creation of inappropriate artifacts following a lifecycle that is far from agile; they’re forced to work with a bureaucratic data management team who often takes weeks or months to do work that should be accomplished in minutes or hours; or they’re forced to work with a review-focused enterprise architecture team who hasn’t been actively involved with software development for years (to name but a few common challenges).  This is akin to putting their racing car engine into an organizational tractor.  Is it any wonder you’re not winning the race?
Tractor

Yes, it’s nice that we’ve discovered ways to get better at software development, but what we really need to do is streamline our approach to IT in general so that we can enable our organization to become a lean enterprise.  Our software development engine needs an effective IT chassis so as to enable our lean enterprise racing car to win the race.

Race car

Here are several strategies to help you to go beyond building an agile software development engine and instead build a “racing car” organization:

  1. Go beyond agile software development.  When we’re optimizing a race car, it’s not just about the engine.  The tires, the shape of the body, the shape of the spoiler, the design of the suspension, and many other factors come into play.  Similarly, it’s not just about optimizing your delivery teams, instead we need to optimize the whole of IT and more importantly your organization in general.  We need to be enterprise aware in our agile transformation efforts: While our development teams to be more agile we also need to transform the teams that they’re working with.  This includes our stakeholders, the data management team, the enterprise architecture team, the portfolio management team, and others.  The challenge, as we point out in principle #15 of the Disciplined Agile Manifesto, is that these teams will likely need to support a multi-modal IT department – some delivery teams (we hope most) will work in an agile/lean manner, some will work in a more traditional manner, and some may even work in an ad-hoc manner.  The implication is that anyone working with more than one IT delivery team will need to be prepared to work in a mode that reflects the paradigm the team is following.  In other words, you’ll work with an agile team in an agile manner, a traditional team in a traditional manner, and so on.  More on this in a future blog posting.
  2. Adopt a flexible, context-sensitive mindset.  Races are run in a range of conditions, and a race car must be sufficiently robust to operate in these conditions.  Similarly IT teams work in a variety of conditions: They range in size and in geographic distribution; the face zero or more regulations; they face a range of domain and technical complexities, and of course every team is made up of unique individuals with their own preferences, experiences, and skills. In short, one process size does not fill all.  To address the need for process flexibility the Disciplined Agile framework supports multiple delivery lifecycles, it promotes a flexible goal-driven strategy that guides you through process choices, and it now includes process blades describing flexible strategies for strategic IT capabilities such as release management, enterprise architecture, reuse engineering, and many others.
  3. Optimize the flow across all of IT.  All the parts of a race car work together effectively as a whole, they are more than a collection of parts bolted together.  It is the same for an IT department.  For an agile software development team to be effective they must be governed in an agile manner, the enterprise architects must support them in an agile manner, the data management team needs to be responsive, the release management team needs to be able to short frequent releases, and so on.  For the enterprise architecture team to be effective the software development teams that they support must be enterprise aware, the data management team needs to recognize that architects need to look beyond data, and so on.  Every team interacts with other teams and must do so effectively.  When one team wants to work one way and another team wants to work another way its the equivalent of trying to use a metric gear with an imperial gear – they simply aren’t going to mesh and progress will grind to a halt.  It is far more important that these teams all follow flexible and compatible approaches rather than approaches that are locally optimized for each team.  Just like a perfect metric gear won’t work with a perfect imperial gear, a strategy that is perfectly optimized for your enterprise architects will likely not work well with a strategy that is perfectly optimized for data management.
  4. All teams will improve.  Your IT department, and your organization as a whole, is a complex adaptive system.  It is a collection of teams working together to achieve, we hope, a common goal.  Each of these teams will be learning from their experiences and improving their approach.  Changes in one team will potentially affect the way that they work in other teams, requiring changes there.  The implication is that your organization is constantly evolving, we hope for the better.  With a goal-driven approach teams can recognize what their process options are, and the trade-offs of each, providing lightweight guidance for choosing effective strategies to address the situation they find themselves in.

We’d like to leave you with this: The collaborative, evolutionary strategies of the agile paradigm isn’t just for software development, but instead should be applied to your IT department and your organization as a whole.  We need race cars, not just race car engines.

People Management: A Goal-Driven Approach

This posting, the latest in our series focused on a disciplined agile approach to people management, overviews the activities associated with it. The Disciplined Agile (DA) framework promotes an adaptive, context-sensitive strategy.  The framework does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog posting we present the goal diagram for the People Management process blade and overview its process factors.

The following process goal diagram overviews the potential activities associated with disciplined agile people management. These activities are performed by, or at least supported by, your people management (often called a human resource) team.

Disciplined Agile People Management

The process factors that you need to consider for people management are:

  1. Manage staff.  Your organization needs to perform basic functions such as hiring (onboarding) staff, letting people go (offboarding), promoting, demoting, transferring them and providing benefits to people.
  2. Organize IT.  What is your strategy for organizing your IT department?  Do you do it by job function (e.g. have a business analyst group, a project management group, and so on), by geography (e.g. a North American IT department, a European IT department, and so on), by business division (e.g. an IT group to support Retail banking, an IT group to support brokerage, and so on), or by value creation (e.g. an IT group to support a specific product line).  Or combinations thereof?
  3. Guide careers.  Your organization should support the career aspirations of its staff, providing opportunities to people and supporting their efforts to achieve their goals.
  4. Staff IT.  You need to identify, and plan for, your organization’s staffing needs.  This includes succession planning for senior IT people, critical technical positions (yes, that includes all those legacy COBOL programmer positions), and other critical roles such as product owners.  This also includes staff capacity planning/forecasting as well as determining your mix of full time employees (FTEs) and contractors.
  5. Reward staff.  There are many ways that people and teams can be rewarded, including base pay, bonuses, and non-monetary rewards.  For some people in some organizations their pay is publicly known (for example, in Canada public employees who make over a certain amount have their salaries published annually) whereas for most people their remuneration strategy is private.
  6. Form teams.  There are different types of teams that can be formed to address IT functions, each of which are (self) organized differently.
  7. Evolve teams.  Team membership and structure evolve over time, and there are several common strategies that enable this.  Some teams are ad-hoc, forming when their needed and disbanding when they’re not, with little or no management intervention.  Sometimes people are assigned to teams and sometimes people volunteer to be on a team.  Some organizations are adhocracies where teams are self-organizing and have defined strategies for enabling collaboration and communication between teams.
  8. Govern people management.  Your people management activities, just like all other activities, should be governed effectively.  An important aspect of people management governance is the definition of roles and responsibilities (see Roles on DAD Teams and DA Roles at Scale for suggestions), as is the usual measurement and monitoring activities.

For more details, please read the article People Management.