Disciplined Agile

The Disciplined Agile (DA) tool kit references hundreds of agile, lean, and in some cases “traditional” techniques, putting them into context. One such technique is database refactoring, adopted from the Agile Data (AD) method, which is critical for the Improve Quality process goal. Where a code refactoring is a simple change that improves the quality of code, a database refactoring is a simple change to your database that improves the quality of its design without changing the semantics in a practical manner. Database refactoring is a sophisticated practice, in fact I co-wrote a 400+ page book about it, Refactoring Databases: Evolutionary Database Design, with Pramod Sadalage in 2006. The book, which won a Jolt Productivity Award, provides a detailed description of the practice. But what if you’d like to start with something simpler before jumping into the details? This is where Essence comes in.

A few months ago a group of us – Roly Stimson of IJI, Nebojsa Trninic, Vladimir Savic, Ervin Varga, and myself – decided to experiment with the idea of essentializing DA. To focus our work we decided to start with a simpler problem, that of essentializing a subset of the techniques referenced by DA, in this case those of Agile Data. We then focused further on a minimal viable product (MVP), in this case the single practice of database refactoring.

We captured the practice using Essence Enterprise 365 from IJI, a screen shot from which is shown below. Essence is a language for describing software engineering methods and practices from Ivar Jacobson International (IJI). Essence was created as a part of Software Engineering Method and Theory (SEMAT) and approved by The Object Management Group as a standard in 2014. I’ve been working with SEMAT from its beginnings in 2009 and have known (and admired) Ivar since the late 1990s.

As you see in the screen shot we summarized database refactoring using the tool, describing the practice as a collection of cards. The tool can be used to develop process material, as we’ve done, and more importantly it can be used by teams to tailor and evolve their own process. Within the tool are dozens of practices, including ones from Scrum and XP, that a team can configure to reflect their own way of working (WoW).

In the following picture you see that these cards can also be printed out and used in a physical manner, often for process tailoring or training. In November I experimented using the cards to train a small group of people. We played a game where the group worked through how they would go about refactoring an existing database. They discussed each card, moving them around on the table until they had something that looked like the picture below. The cards provided a tactile way for them to explore database refactoring by thinking through how they would apply it in practice. IJI has identified a collection of teaching and process tailoring games using cards such as this.

An interesting result of this teaching experiment is that we discovered that we wanted more cards. The group wanted cards to explore automated database regression testing, agile data modelling, and continuous database integration in detail, and of course how all of these things fit together. So it looks like we have our work cut out for us.

We’d love to hear what you think about this effort. This blog has been a brief description of our work to essentialize the practice of database refactoring, but we have a lot more work ahead of us. A more detailed description will be presented in a forthcoming research paper that the team is working on. We also intend to continue with this essentialization effort to share some of the key DA techniques within Essence. Stay tuned!

Our new book, Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working, is now available!

This handbook is an indispensable guide for agile coaches and practitioners to identify what techniques – including practices, strategies, and lifecycles – are effective in certain situations and not as effective in others. This advice is based on proven experience from hundreds of organizations facing similar situations to yours.

There are literally hundreds of books that have been written on agile and lean. So why one more? Most books focus on just a subset of what is required to delivery end-to-end solutions in an agile manner. Developing a coherent approach to the complete picture by piecing together these practices is difficult, especially when the advice in many of these books is conflicting and not well researched, often based on just a few successful applications in a specific context.

Disciplined Agile (DA) is the only toolkit available that combines the most effective practices across lean and agile methods into one comprehensive context-driven approach that you can use to optimize your way of working (WoW).

This book is organized into several sections:

1. Disciplined Agile in a Nutshell. This section describes guided continuous improvement, the Disciplined Agile (DA) Mindset, and of course DA itself.
2. Successfully Initiating Your Team. This section describes strategies for how a team can do just enough work to get themselves organized and to come to a general agreement around the scope, architectural strategy, and plan for the current release.
3. Producing Business Value. This section describes a myriad of agile and lean strategies for producing a minimal marketable release (MMR) of a consumable solution that is ready to be transitioned into production or the marketplace.
4. Releasing Into Production. This section describes techniques to successfully release a consumable solution into production or the marketplace. Ideally this is a fully automated activity that runs in minutes or hours.
5. Sustaining and Enhancing Your Team. This section describes strategies that support the team and/or help to make it more effective. This includes techniques for helping to grow individual team members, for evolving your team’s WoW, and for coordinating both within the team and with other teams in your organization.

For more information, please visit the Choose Your WoW! book page.

On Monday I attended a talk by Mike Rosen about successful Digital Transformation.  As always, Mike’s presentation was very insightful.  One of many points that he made is that most organizations are struggling with the current talent shortage, something that in my experience has been a problem worldwide for several years and will continue to be so.

There are many reasons for why there is a talent shortage:

1. It takes years to master your craft.  In the distant past, the 1980s, I had to go to university for four years to become a junior programmer.  Then I had to work for years to gain the experience and skills to become a developer. And things are certainly more complex now than it was back then. My point is that it takes years, not days or weeks, to gain the skills and experience that organizations are looking for.
2. Organization’s planning horizons are too short. Demand has outstripped supply for many years within IT, and we’re clearly seeing this within the agile space. Having said that, the growth of IT has followed a steady and predictable curve for years that organizations could have planned for, and more importantly executed on, had they chosen to. But, the multi-year time frame to grow talent doesn’t mesh well with the quarterly-results focus of most organizations.
3. Organizations have cut back on training. In the 1980s and most of the 1990s it was common for IT people to be given two or more weeks of training every year.  This was slowly whittled away down now many people are lucky to be given the funding to attend a single workshop or one-day conference each year.  Yes, there are some great resources online that can provide a substitute for training, so that’s bit of help. Unfortunately most organizations expect people to learn on their own time.  Some people do in fact do that, but many do not. I regularly meet people at conferences who have taken a vacation day and spent their own money to attend the event – it’s laudable that they’re doing this, but incredibly frustrating that they’ve had to resort to doing so. My point is that if your organization has not been investing in its people it seems disingenuous for it to complain about the lack of skilled people available to it.
4. Apprenticing is virtually non-existent in IT. Many other professions have a culture of apprenticing to help bring new people in and help them to gain the skills and experience required. Although I have seen several organizations attempt to institute a mentorship program, and have seen limited successes at doing so, I have never run into an organization with active apprenticing. Non-solo work practices such as pair programming, mob programming, and modeling with others are arguably the start at apprenticing practices within the agile space so perhaps this is how it begins in IT.  Time will tell.

Here are a few things that your organization can do to start addressing its talent shortage:

1. Become an attractive place to work. It’s important to note that attractive organizations, the ones that are known for doing interesting work and for providing their people with autonomy to learn and to choose their way of working (WoW), don’t seem to have problems attracting and retaining good people.  Granted, this doesn’t grow the pool of talented people but it does help to address your challenge.
2. Start investing in your people long term. If you want talented people in your organization you need to grow and nurture them yourself.  You can do so by providing coaching, mentoring, training, and education opportunities.  You can support the creation of communities of practice (CoPs), also called guilds, and create centres of excellence (CoEs).  Motivating teams to experiment with non-solo work practices such as pairing and mobbing will enable them to learn from each other.  And of course all of these strategies require investment of time and money.
3. Become a learning organization. If you want people to grow their skills you have to allow them to do so.  Allow them to experiment with new ways of working (WoW), recognizing that some of those experiments will “fail” and you’ll discover what doesn’t work for you in your context. Also recognize that individuals and teams have to be allowed to choose their WoW, and to evolve it as they learn, so that they can improve.

The primary reason why there is a shortage of talented people is because organizations are underinvesting in the learning paths of their staff.  If you want talented people you’re going to have to help create them.

Related reading:

• The People Management process blade
• The Grow Team Members process goal

Since 2001 we’ve applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so. What we’ve learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations in which we have applied agile and lean strategies. Because the original authors of the Agile Manifesto have decided not to evolve the Manifesto, a decision that we fully respect, we have decided to move forward on our own.
The Disciplined Agile Manifesto is an evolution of the original Manifesto for Agile Software written in 2001. We first published it in the book Disciplined Agile Delivery (DAD) in 2012, evolved it again in 2014 here on this website, and just recently evolved it yet again in our forthcoming book Choose Your WoW!

We believe that the changes we’re suggesting are straightforward:

1. Solutions , not just software. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, DA suggests that we should focus on solution delivery. In short, we prefer solutions (software + hardware + supporting documentation + business process + organization structure) over just software. We also believe those solutions should be consumable (provide valuable working functionality + be usable + be desirable) rather than just be working.
2. Stakeholders, not just customers. Where the original manifesto focused on customers, a word that for too many people appears to imply only end users, DA suggests that we focus on the full range of stakeholders instead. We prefer stakeholders – end users, operations people, sustainment people, audit, finance, and many more – over just customers. See Chapter XX for a more detailed discussion of this.
3. Teams, not projects. Where the original manifesto talked about projects, we believe it is more accurate to talk about teams.
4. Organizations, not just teams. Where the original manifesto focused on development teams, DA suggests that the overall organization and its improvement be explicitly taken into consideration.
5. We’ve learned a lot since 2001, so let’s make that explicit. The original manifesto focused on the understanding of, and observations about, software development at the time. But we’ve learned a lot since then, particularly around continuous delivery and testing strategies that are embraced by DAD.
6. Feedback, not just change. As Neil Killick and Dan North both point out, being agile is more about responding to feedback than it is to responding to change. This is an important nuance because it underlines the importance of working closely with our stakeholders. Additionally, it is more accurate to say that requirements emerge rather than requirements change as we develop a better understanding of the true needs.
7. Lean and agile, not just agile. We have learned from the lean community. The Disciplined Agile Manifesto incorporates lean principles, in particular considering the whole, visualizing workflow, and minimizing work in progress (WIP).

The original manifesto principles were crafted to reflect the environment in the ‘90s when it was an accomplishment to have a demonstrable increment of a solution even every month. In modern times the bar is significantly higher. As such, if you compare the wording of the updated principles as we describe them to the original, you will observe that they reflect a lean philosophy of a continuous, just-in-time, experimental, and emergent approach to everything we do. What we have written may be perceived as heresy to some agile religious puritans but we believe it is time to move on to reflect modern realities and capabilities.

We’d love to hear your feedback.

Good things to know

1. This blog posting has been modified from Chapter 2 of the book Choose Your WoW!
2. We’ll be working with the translators of the DA Manifesto to get the translations pages up to date.  We expect this to take a month or so.
3. Dan North’s Agile Revisited talk from 2015 provides some very interesting insights.

A common question that we get from customers who are new to Disciplined Agile (DA) is how do you aggregate, or "roll up", metrics from agile teams into a portfolio dashboard?  A more interesting question is how do you do this when the teams are working in different ways?  Remember, DA teams choose their way of working (WoW) because Context Counts and Choice is Good.  Even more interesting is the question “How do you aggregate team metrics when you still have some traditional teams as well as some agile/lean teams?”  In this blog we answer these questions one at a time, in order.

Note: We’re going to talk in terms of a single portfolio in this article, but the strategies we describe can apply at the program (a large team of teams) too, and then the program-level metrics are further rolled up to higher levels.

How Do You Aggregate Agile Team Metrics Into a Portfolio Dashboard?

Pretty much the same way you aggregate metrics from traditional teams.  There tends to be several potential challenges to doing this, challenges which non-agile teams also face:

1. You can only aggregate metrics with similar units. You do need to be careful with some measures, such as team velocity, because the units vary across teams.  It is possible to enforce a common way to measure velocity across teams, but this tends to be more effort than it’s worth in practice. Sometimes there are metrics which you think you should be able to roll up but you discover (hopefully) that you really shouldn’t.  One example of this is number of defects by severity.  You can roll this metric up when the severity of a defect is determined in a consistent manner across teams, but this isn’t always the case in practice.
2. Sometimes the math gets a bit complex.  Aggregating metrics isn’t always based on simple addition.  Many times you will need to weight metrics based in terms of time, size, financial impact or combinations thereof.  Interestingly, although some metrics can’t be rolled up because they are measured in different units, you can often roll up the trends of those metrics.  For example, acceleration is the change in velocity of a team.  Given an appropriate weighting formula you can roll up an average acceleration figure across teams.
3. Some people believe you can only aggregate the same metric. Basically, when a common metric is captured across teams (for example Net Promoter Score (NPS) or cyclomatic complexity) then you can easily (albeit with some “complex” math in some cases) roll them up to a program or portfolio level.  In the Govern Team process goal we refer to this strategy as consistent metrics, an option of the Provide Transparency decision point. This strategy works well when teams actually collect the same metrics, but in when teams choose their WoW this isn’t always the case.

How Do You Aggregate Agile Team Metrics Into a Portfolio Dashboard When the Teams Choose Their WoW, and it’s Different For Each Team?

When a team is allowed to choose it’s way of working (WoW), or “own their own process,” the team will often choose to measure itself in a manner that is appropriate to it’s WoW. This makes a lot of sense because to improve your WoW you will want to experiment with techniques, measure their effectiveness for your team within your current context, and then adopt the techniques that work best for you.  So teams will need to have metrics in place that provide them with insight into how well they are working, and because each team is unique the set of metrics they collect will vary by team.  For example, in Figure 1 below we see that the Data Warehouse (DW) team has decided to collect a different sent of metrics to measure stakeholder satisfaction than the Mobile Development team.  The DW team needs to determine which reports are being run by their end users, and more importantly they need to identify new reports that provide valuable information to end users – this is why they have measures for Reports run (to measure usage) and NPS (to measure satisfaction).  The Mobile team on the other hand needs to attract and retain users, so they measure things like session length and time in app to determine usage, and user retention and NPS to measure satisfaction.

Figure 1. Applying consistent metrics categories across disparate teams (click on it for a larger version).

Furthermore, the nature of the problem that a team faces will also motivate them to choose metrics that are appropriate for them. In Figure 1 we see that each team has a different set of quality metrics: the DW team measures data quality, the mobile team measures code quality, and the package implementation team measures user acceptance test (UAT) results. Although production incidents and automated test coverage are measured by all three teams, the remaining metrics are unique.

The point is that instead of following the consistent metrics practice across teams by insisting that each team collects the same collection of metrics, it is better to ask for consistent metric categories across teams. So instead of saying “thou shalt collect metrics X, Y, and Z” we instead say “Thou shalt collect metrics that explore Category A, Category B, and Category C.” So, as you can see in Figure 1, each team is asked to collect quality metrics, time to market metrics, and stakeholder satisfaction metrics but it is left up to them what metrics they will choose to collect. The important point is that they need to collect sufficient metrics in each category to provide insight into how well the team addresses it. This enables the teams to be flexible in their approach and collect metrics that are meaningful for them, while providing the governance people within our organization the information that they need to guide the teams effectively.

So how do you aggregate the metrics when they’re not consistent across teams?  Each team is responsible for taking the metrics that they collect in each category and calculating a score for that category.  It is likely that a team will need to work with the governance body to develop this calculation.  For example, in Figure 2 we see that the each team has a unique dashboard for their team metrics, yet at the portfolio level the metrics are rolled up into a stoplight status scorecard strategy for each category (Green = Good, Yellow = Questionable, Red = Problem). Calculating a stoplight value is one approach, you could get more sophisticated and calculate a numerical score if you like.  This is something the governance body would need to decide upon and then work with teams to implement.

Figure 2. Rolling up metrics categories (click on it for a larger version).

From the looks of the Portfolio dashboard in Figure 2 there is a heat map indicating the overall status of the team (using green, yellow, and red again) and the size of the effort (indicated by the size of the circle). Anyone looking at the portfolio dashboard should be able to click on one of the circles or team stoplights and be taken to the dashboard for that specific team. The status value for the heatmap would be calculated consistently for each team based on the category statuses for that team – this is a calculation that the governance body would need to develop and then implement.  The size of the effort would likely come from a financial reporting system or perhaps your people management systems.

How Do You Aggregate Team Metrics When Some Teams Are Still Traditional?

With a consistent categories approach it doesn’t really matter what paradigm the team is following.  You simply allow them to collect whatever metrics are appropriate for their situation within each category and require them to develop the calculation to roll the metrics up accordingly.  If they can’t come up with a reasonable calculation then the worst case would be for the Team Lead (or Project Manager in the case of a traditional team) to manually indicate/enter the status value for each category.

Parting Thoughts

For the consistent categories strategy to work the governance people need to be able to look at the dashboard for a team, which will have a unique collection of widgets on it, and be able to understand what the dashboard indicates. This will require some knowledge and sophistication from our governance people, which isn’t unreasonable to ask for in our opinion. Effective leaders know that metrics only provide insight but that they shouldn’t manage by the numbers. Instead they should follow the lean concept of “gemba” and go see what is happening in the team, collaborating with them to help the team understand and overcome any challenges they may face.

Related Links

• The Governance Process Blade
• The Measure Outcomes process goal
• The Organize Metrics process goal