Terraforming is the act of making an environment suitable for human habitation. Terraforming has been popularized in science fiction as the act of evolving a planetary ecosystem, but in our context terraforming is the act of evolving your team’s physical workspace to make it more habitable for you to work. Doing so in an important enabler for improving your way of working (WoW).
The Evolve Way of Working (WoW) process goal, the diagram for which is shown in Figure 1, involves several decision points that are pertinent to terraforming. In Disciplined Agile (DA) our philosophy is that teams should choose and evolve their WoW over time as they learn, and an important aspect of doing so is to recognize that you should be able to evolve your physical as well as virtual workspace.
Figure 1. The Evolve Way of Working (WoW) process goal diagram (click to expand).
As you’d expect, you have choices available to you. In Figure 1 there are three decision points relevant to terraforming:
We’ve found that a great strategy for a company is to make physical things such as furniture and whiteboards readily available to teams. Something as simple as a room full of (currently) unused furniture that a team can simply take from, or contribute things they’re no longer using into, goes a long way to providing flexibility. And of course allowing teams to buy what they need, when they need it, is also crucial. Smart organizations realize thatone of the best investments they’ll ever make is to spend a few thousand dollars on furniture and whiteboards to enable a team of people earning five or six figure annual incomes to improve their WoW.
Ideas for this blog was adapted from the book Choose Your WoW! This book is a handbook overviewing hundreds of agnostic techniques and strategies that agile and lean teams may decide to experiment with to see how well they work in the situation that they face.
One of the interesting trends that we’re seeing within organizations taking a disciplined agile approach to solution delivery is the preference for stable teams. Stable teams, also called stable product teams or simply long-term teams, are exactly as they sound – they remain (reasonably) stable over time, lasting longer than the life of a single project. This blog explores the differences between project teams and stable teams and then overviews the advantages and disadvantages of the stable team approach. We also explore the issue of how stable teams evolve over time.
As you can see in the following diagram, with a project team approach we say that we bring the team to the work. What we mean by that is that we first identify the need to run a project, perhaps to build the new release of an existing solution or to build the initial release of a new solution, we build a team to do the work. Once the work is done, in this case the solution is successfully released into production, the team is disbanded and its team members move on to other things.
The stable team approach is a bit different. In this case we first build an effective team then we continuously bring valuable work to the team to accomplish. In this situation the work never really ends, but instead we replenish the team’s work item list (or work item pool depending on the lifecycle being followed) regularly. The team stays together and continues to produce value for your organization over time.
Of course the term “stable team” is a bit of a misnomer as they do evolve over time. For example, many people like to stay on a team for a couple of years and then move on to another team to gain new skills and perspectives. This is good for them and good for your organization as it helps to keep your teams fresh. Sometimes you will want to grow or shrink a team. Sometimes you will discover that two people aren’t working well together and you need to split them up. The point is that there are very good reasons for your stable teams to evolve over time.
We wouldn’t be disciplined if we didn’t explore the trade-offs involved with stable teams.
The Advantages of Stable Teams
There are several advantages to stable teams:
The Disadvantages of Stable Teams
There are several disadvantages to stable teams:
Evolving Stable Teams Over Time
Stable doesn’t mean stagnant. Of course you still have basic people management issues such as people wanting to expand their skill set by working on something new by rotating to another team, people leaving the organization, and new people joining the organization. So the team itself may go on for many years even though the membership of the team evolves over time. Ideally these membership changes are not too disruptive: It’s not too bad adding a new person every month or so, or losing people at a similar rate, but gaining or losing several people in a short period of time can be painful.
Start experimenting with stable teams if you’re not already doing so. For most organizations the advantages clearly outweigh the disadvantages. In fact, you can see this in the Longevity decision point of the Form Initial Team goal diagram below.
One of the iconic movies of the 1980s was The Breakfast Club, which told the story of five very different teenagers who were forced to come into school one Saturday to serve detention. Recently I’ve been working at a large insurance company helping them to adopt the Disciplined Agile (DA) toolkit. One of people whom I’m working with has a Breakfast Club poster on the wall near her work area and it got me thinking about some of the dynamics that I’ve seen watching agile teams form and eventually gel. Here are my thoughts.
At the start of the movie the kids didn’t really like each other, they were very different from one another, they certainly didn’t want to be there, and they were each coming to the group with their own point of view and background. Sadly, I’ve seen more than one software project team that was put together like this. As the movie progressed they began to really talk with one another and their stories started to emerge. They started to work together, hijinks ensued, and they bonded as a group. As part of their punishment they were each asked to write an essay describing what they learned from their detention. Instead they wrote a single letter, which follows, that they submitted as a team.
“Dear Mr. Vernon: We accept the fact that we had to sacrifice a whole Saturday in detention for whatever it was we did wrong, but we think you’re crazy to make us write an essay telling you who we think we are. You see us as you want to see us… In the simplest terms and the most convenient definitions. But what we found out is that each one of us is a brain… …and an athlete… …and a basket case… …a princess… …and a criminal. Does that answer your question? Sincerely yours, the Breakfast Club."
So how does this relate to agile teams?
The Breakfast Club is a great movie. If you haven’t seen it, or haven’t seen it lately, then I highly suggest watching it again.
We learned in a previous blog posting, The Mindset of a Disciplined Agile Enterprise Architect, that disciplined agile enterprise architecture (EA) teams work in a very collaborative manner, evolving their artifacts over time based on their learnings. But how do you organize an enterprise architecture team so that it can be agile? Answering this question is the goal of this posting.
As you would expect, the answer is “it depends”. There is no one right way to organize an enterprise architecture team, your approach must be driven by the context of the situation that you find yourself in. We start with the strategy that we call the “hands on” approach because members of the EA team are also members of IT delivery teams. We then describe a small EA team approach, a common strategy when you are first getting your team in place or when the team doesn’t have the funding required for the hands-on approach. We end with a discussion of how to go about this in very large organizations.
The “Hands On” Team Structure
Every DAD team has someone in the role of architecture owner (AO), sometimes called an agile solution architect or simply agile architect. This person is responsible for guiding the team through architectural decisions and for mentoring and coaching other team members in architecture and design skills. An AO should have a solid understanding of your organization’s technical and business roadmaps, if they exist, and be willing to collaborate closely with the enterprise architecture team. With the “hands on” EA team structure, AOs are members of the enterprise architecture team. The following diagram shows how an AO is a member of a delivery team and a member of the enterprise architecture team at the same time.
A few important observations about the “hands on” team structure depicted above:
The AO will spend most of their time (90-95%) working with one or more delivery teams and the remainder working performing enterprise architecture activities. There are several strategies that you can consider for determining who will be on EA team:
The “hands on” team structure is typically used by:
The Small Enterprise Architecture Team Structure
The following diagram depicts what we call the “small EA team structure.” In this case external teams will submit a request for the EA team to do some work. These are typically requests to review their work or to provide some guidance on an architectural issue. The enterprise architect(s) will address the requests in priority order, often working in a Kanban-style manner.
This small EA team approach is common when EA teams are starting out or when they aren’t adequately funded to have people on every IT delivery team. Although it is possible to keep this lightweight, and that is often a necessity due to funding constraints, it can sometimes devolve in to a review-based, documentation heavy approach. Furthermore, due to understaffing the enterprise architects rarely have the time to coach others in architectural skills. In extreme situations the EA team becomes a bottleneck for the IT delivery teams waiting for help from them.
The Multi-Level Enterprise Architecture Team Structure
Very large organizations, often those with thousands and sometimes tens of thousands of people in IT, need a more sophisticated approach to organizing their EA team. In these situations they tend to have a multi-level approach. For example, we have one customer who is taking a three-level approach to the hands-on team strategy described earlier. The first level is enterprise architecture for the line of business within a specific geographic region (i.e. retail banking in Europe), the second level for the geographic region, and the third level for the overall company. With this strategy someone is an AO on a delivery team and a member of the first level EA team. The chief EA of the first level team is a member of the second level team for their geographic region, and the chief EA of that team is a member of the organization-level EA team. In short, this multi-level EA team structure reflects the overall organization’s structure.
Each EA team structure described in this blog has advantages and disadvantages. No one approach fits all situations, and as the context of the situation that you face evolves over time so will the structure of your enterprise architecture team.
In this blog posting we describe two issues for organizing your release management strategy: How to scope release management and how to organize the team.
There are two fundamental issues to consider when scoping your release management efforts:
These two issues lead us to the following quadrant chart depicting the potential scope for release management:
From a Disciplined DevOps point of view we of course promote a Holistic Enterprise scoping strategy. Whatever scoping strategy you choose your release management strategy will need to be able to support the scaling situations faced by your delivery teams. This includes teams of various sizes, different levels of geographic distribution, dealing with different levels of domain and technical complexity, teams that are organizationally distributed, and teams in compliance situations.
There are three strategies to consider for organizing your release management team: