Disciplined Agile

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

On August 8th I facilitated a workshop at Agile 2018 that focused on agile architecture. I promised everyone, we had over 150 people in the workshop, that I would post the pictures of their strategy canvases online so that they could have copies of it.  So here’s my promised blog!

How architecture fits into agile ways of working (WoW) has been an important topic from the very beginning.  As with all other aspects of agile, the Disciplined Agile (DA) toolkit provides you with choices – because every team is unique and faces a unique situation, they need to choose their WoW to reflect this (we like to say that context counts).  To enable teams to effectively choose their WoW they need to know what choices they have available to them (we also believe that choice is good) and what the trade-offs of those choices are (because there’s no such thing as a best practice).

So in this workshop we worked through twelve agile architecture strategies.  Granted, there’s a lot more than this, but we only had 75 minutes so I lead everyone through some of the key strategies.  This blog overviews each strategy and then shares the strategy canvases that the class developed.  Our approach was to assign each strategy to several tables and then ask each group to discuss the advantages of the strategy, the disadvantages, and when you would use it. There are pictures below of each strategy canvas – it’s important to note that I don’t agree with all of the sticky notes, but for the most part it’s solid stuff.  Our upcoming book, trending to arrive in October 2018, explores these strategies (and more).

During the workshop we explored three fundamental questions:

1. How Do You Explore Your Initial Architecture Strategy?
2. How Do You Bring Architecture Skills Into the Team?
3. How Do You Evolve Your Architecture?

How Do You Explore Your Initial Architecture Strategy?

Each group was given one of three initial architecture strategies to discuss:

1. No modeling
2. Lightweight modeling
3. Heavy modeling

No modeling

At the beginning of our project/endeavor we will perform no architecture modeling or exploration at all.  We believe that all aspects of the architecture will emerge over time during Construction.

Lightweight modeling

At the beginning of our project/endeavor we will invest a bit of time, potentially several hours or even a few days, to perform some lightweight agile architecture modeling.  We believe that we should think through the high-level architectural issues now but that the design details will emerge over time. Our “models” will be created using inclusive modeling tools such as whiteboards, paper or sticky notes. We’re likely to create one or more high-level sketches, each of which explores an architectural view (such as the technical architecture, the data architecture, the communications architecture, and so on).

Heavy modeling

At the beginning of our project/endeavor we will invest a fair bit of time, potentially several weeks or even a few months, to work through the architecture of our solution.  We believe that we need to think through most, if not all, aspects of the architecture in detail before we can safely proceed with Construction.  Our models may be either visual (i.e. UML component diagrams, Free-form architecture diagrams, Data Models, …) or textual (e.g. white papers) in nature.  Our visual models will be supported by sufficient documentation to capture the details overviewed by the diagrams.  Our models will be captured with software-based diagramming tools (e.g. Visio, OmniGraffle), documentation tools (e.g. Word processors or Wikis), or modeling tools (e.g. Enterprise Architect).

How Do You Bring Architecture Skills Into the Team?

Each group was given one of five architecture skills/roles strategies to explore:

1. No architect
2. Part-time architect
3. Modeler architect
4. Developer architect
5. Architecture owner

No architect

On our project/endeavor we do not have anyone on the team responsible for architecture work nor do we have anyone with sufficient architecture skills to do so.  Luckily we are a group of smart, experienced developers and we believe that we will be able to evolve the architecture of our solution through teamwork and experimentation.

Part-time architect

On our project/endeavor we have someone on our team acting as a part-time architect.  This person is very experienced and is a member of our corporate architecture team, supporting several solution delivery teams including our own.  The part-time architect guides our team in architecture decisions, providing advice, educating us in any existing corporate architecture guidance, and reviewing any work that we do on our own.

Modeler architect

On our project/endeavor we have someone with deep architecture experience and skills.  In the past they were a developer but over time they worked their way out of that role to become an architect.  Their job is to work through the architectural strategy for the team, describe that architecture strategy to us, and develop and maintain sufficient architecture models and documentation throughout the lifecycle.  Although they are technically adept and well versed in the domain, they do not have technical experience with some of the platforms and technologies that the team is likely to work with. 

Developer architect

On our project/endeavor we have someone who is a full-time member of our team who has deep architecture experience as well as development skills. They are responsible for formulating the architecture strategy for the team although will often work with other team members to get their input into architecture decisions. When they are not doing architecture work they are an active developer on the team.

Architecture owner

On our project/endeavor we have someone in the role of Architecture Owner (AO).  This is a full-time team member who has architecture experience, is well versed in our corporate architecture guidance/strategies, and also has development skills.  The AO:

• Guides/facilitates the team through architectural strategy and related work
• Mentors/coaches team members in architecture thinking and skills
• Work with our corporate architecture team as needed to ensure that our team is following, to the extent appropriate, the overall architectural vision
• Is an active developer on the team when they are not performing their other responsibilities

How Do You Evolve Your Architecture?

Each group was given one of four architecture evolution strategies to explore:

1. Architectural Guidance
2. Architecture Spikes
3. Walking Skeletons
4. Just-in-time (JIT) Model Storming

Architectural Guidance

One of the approaches that our team uses to evolve our architecture is refer to our organization’s existing architectural guidance. We typically do this by talking with someone on our team familiar with that guidance, such as an Architecture Owner (AO).  This person may decide to look up the current version of the architecture guidance as needed (hopefully this is captured in an agile, lightweight manner).  Such architecture guidance may include:

• Technologies we’re moving towards
• Technologies we’re moving away from
• Technologies that we mustn’t use
• Previously identified architecture experiments to run (important in multi-team environments to coordinate learning efforts)
• Results from architecture spikes performed by other teams

Architecture Spikes

One of the approaches that our team uses to evolve our architecture is to run architecture spikes (or simply called spikes). Whenever we run into an architectural issue, such as how a technology works within our environment or how a combination of technologies work together, we write a bit of code to explore the issue.  This is typically throwaway prototyping code because we want to quickly experiment to gather sufficient data to make a better-informed decision.  Spikes typically take a few hours to a few days. A spike can be thought of as a very small proof of concept (PoC).

Walking Skeletons

One of the approaches that our team uses to evolve our architecture is to develop a walking skeleton, also known as a working skeleton or steel frame, of our solution early in Construction.  We do this by focusing on a small collection of requirements early in the lifecycle that implement sufficient functionality to address our highest-risk items so as to show that our architectural strategy works in practice.  Once the walking skeleton is in place we spend the rest of Construction putting the functional flesh onto it.

Just-in-time (JIT) Model Storming

One of the approaches that our team uses to evolve our architecture is to explore requirement and design details at the last most responsible moment.  We do this via light-weight agile modeling (sketching, sticky notes, …).  Model storming sessions are often impromptu and last for several minutes, often starting with a request along the lines of “Hey, can you help me work through this…”.

Parting Thoughts

After the workshop I received a lot of great feedback from attendees.  It really resonated with people and seemed to provide them with a lot of value.  I was glad to hear that.  

Further Reading

• Architecture Owner
• Identify Initial Architecture Strategy
• Enterprise Architecture
• Agile Architecture Strategies