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:
How Do You Explore Your Initial Architecture Strategy?
Each group was given one of three initial architecture strategies to discuss:
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.
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).
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:
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.
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.
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.
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.
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:
How Do You Evolve Your Architecture?
Each group was given one of four architecture evolution strategies to explore:
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:
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).
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…”.
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. So, in the spirit of blatant self promotion, I wanted to let people know that the Disciplined Agile Consortium offers training in Agile Architecture, including:
Furthermore, feel free to reach out to me at Disciplined-Agile.com if you’d like some help bringing agile architecture or more broadly Disciplined Agile (DA) strategies into your organization.
In the following table we list the advantages, disadvantages, and considerations (when does the strategy makes sense) to compare whether a software architect should write code or not. You may recognize this approach from our book Disciplined Agile Delivery.
In the Disciplined Agile (DA) toolkit we’ve made it very clear that we expect Architecture Owners to be actively involved with the development of the solution. On Disciplined Agile teams the Architecture Owner is effectively a team member with additional responsibilities around leading the team through architecture decisions, in coaching them on architecture skills, and in working closely with your Enterprise Architecture team (if any) to ensure their development team understands and is working towards your organization’s technical roadmap.
We’re often told that it isn’t realistic to expect architects to write code. Invariably this is coming from people who are currently working in traditional IT organizations that have very well-defined roles, IT organizations that more often than not are struggling to be effective. Our response is always the same – Really? Are development teams following your architectural strategy? Are they eager to work with you, or are they forced to work with you? This generally leads to a discussion that reveals that things aren’t going so well for these architects in practice, and sometimes leads to a positive discussion as to how we can move towards a more effective approach for them. They kind of approach described in the Disciplined Agile (DA) toolkit.
Recently on the Disciplined Agile Delivery LinkedIn discussion group we talked about how people in an existing traditional role fit into a disciplined agile team. The challenge is that in organizations new to agile will have people who take on traditional roles such as business analyst, programmer, solution architecture, tester, project manager and so on. Yet DAD has roles such as team member, team lead, architecture owner, and so on that are different from traditional roles. Clearly this is a “DAD adoption” challenge that we need to overcome.
At first you will build cross functional agile teams with the people you have available to you. Agile teams are whole teams, which means that the team has sufficient skills to get the job done. The implication is that you’ll initially build a team from the analysts, programmers, testers, … that are available and are willing to join the team. As they say, you go to war with the army that you have. At first an analyst is likely to focus on analysis activities, a programmer on programming activities, and so on because that’s what they know how to do. Because they are working closely with one another in a iterative, incremental, and collaborative manner they quickly start to pick up skills from one another. Over time these people who were originally specialized in one aspect of solution delivery become T-skilled generalizing specialists with a wider range of abilities. This enables them to collaborate more easily and be more effective as IT professionals.
An interesting side effect of this is that as your team becomes more experienced in working in an agile way, and as team members gain a wider range of skills, the conversation shifts from “I’m a tester, so I’m responsible for testing” to “as a team how are we going to approach testing X?” In other words, you start to focus on performing valuable activities instead of the roles responsible for doing so. This is an important shift in mindset on your agile transformation journey.
The Team Lead Role in an organization that is performing Software Development using DAD is the most influential role and the role can be both challenging and fun. You do not need to be a technical expert to be a very effective Team Lead however like most professions having a strong technical background will definitely help you to connect better with the Team Members.
Here are 12 Habits from veteran Scrummasters applying Scrum. These habits have been adapted to apply directly to DAD so they can be applied to various approaches under the DA umbrella.
1. Be disciplined in how you perform your duties. Without a doubt you must be disciplined to be a great Team Lead because your goal is to enable your team to achieve consistent, predictable results. Achieving this goal is nearly impossible if the Team Lead is not disciplined. One way to be disciplined is to establish and stick to a daily routine (think checklist) that you follow in performing Team Lead duties. An example is reviewing metrics, such as a burndown chart, daily and making adjustments in real time (such as changing the owner on a task) to the assigned work items.
2. Make decisions that are consistent with Agile Values and are Risk and Value Driven. A Team Lead needs to have a solid and broad understanding of Agile approaches and how various approaches work together to benefit the organization as a whole. Decision making based upon Agile Principles, which make real time changes in both requirements as well as techniques to construct and test software products is fundamentally different than decision making based upon a prescriptive process which requires following a predetermined approach.
Think about the captain of a ship who slows speed and changes course frequently during a voyage and the result is they ship arrives 12 hours late at next port. Was this ship captain careless? Or did he avoid an oncoming hurricane that would have put the entire crew and cargo at risk and did he also communicate his intentions to the appropriate parties to ensure that the facilities at the port could accommodate the change in schedule with minimal impact? Your Team Lead is like the ship captain; he or she knows how to make good real time decisions that balance all the competing priorities but still keeps the ship and its contents protected because he is both Risk and Value Driven and he is empowered to make decisions in real time.
Please note: a disciplined Team Lead is not a cowboy. Instead, they are an innovator that will gladly question why something needs to be done, look at all options and make recommendations or decisions on how to proceed based upon the feedback from the Team Members, Product Owner, Stakeholder, and Architecture Owner.
3. Start and finish the daily coordination meeting at the same time every day. A well run coordination meeting can finish in 15 minutes. The Team Lead should ensure that the coordination meeting does not digress into long discussions. A great phrase to encourage your team to use is “I am available after daily meeting to discuss this topic in detail”.
4. Communicate updates from other parts of the organization and upcoming deadlines. The coordination meeting is a great way to provide instructions and updates from management as well as upcoming deadlines. You can even summarize emails that have already been sent out to reinforce key topics such as if there are new coding standards or techniques the company is encouraging to increase the quality of the products.
5. Visualize the workflow to help achieve a smooth flow of delivery. The Team Lead needs to drive adoption of this practice and should check for all the following: New work (stories or defects) assigned to your team since the last coordination meeting, work that is not properly planned out (missing tasks or tasks missing owners), blocks preventing Team Members from proceeding. Tools can help view these details quickly but if you do not have a tool that can display this information you can solicit this input from your team. During the coordination meeting you may not have time to capture all the details when you find something that needs investigation so make a note to yourself and follow up after the meeting. Visualizing the workflow is a great way to uncover work in progress (WIP) that is stalled and limiting WIP is as an essential component of Lean Principles.
6. Demo early and demo often. DAD teams typically perform a demo to key stakeholders at the end of each construction iteration. However, there is no reason why you cannot hold a demo during the construction iteration if the product is complete and stable enough to show to a key stakeholder. Showing early demos is another way to encourage active stakeholder participation.
7. Coach don’t direct. If you find yourself doing most of the talking or worse if people are talking at you and not the team, make adjustments. You are serving the Team, not the other way around. DAD Teams are self-aware and having a leader that dominants the conversation and direction for the team could be limiting factor if Team Members are not comfortable making decisions without having to consult the Team Lead.
8. Be a beacon of encouragement and positive energy. This concept supports the DAD principle that people are the primary determinant of success for IT Delivery Projects. As a Team Lead you are a leader and if you want your team to be confident and show poise even under pressure from the schedule or production support problems you need to lead by example. Be calm, cool and collective and maintain a focus on quality work and make the right decisions that will provide business value. This can be difficult to do in a lot of circumstances but your goal should be to provide the best value you can with your team in the time you have available. If there are cultural and political hurdles that are materially affecting your Team’s ability to produce solutions that high quality and value for the business then raise these concerns with management and get them addresses. You may not always achieve the outcome you had hoped to achieve but if your Team knows you are going to bat for them they will support you and your efforts to meet the goals despite these challenges.
9. Train a backup Team Lead. A key principle of DAD process framework is to be learning oriented. This implies that training needs to be a priority in for your organization to reap the full benefits of DAD. The day you are out sick the your team should not notice because you have a fully trained back up Team Lead to run the daily meeting and handle all Team Lead responsibilities. A best practice is to perform training in private with team members who want to pursue this opportunity. Let them know you will help them and encourage them. Remember your role as Team Lead includes serving the Team, there is no better way to serve the team than to make sure they don’t get stalled just because your are not available.
10. Understand all the ways to bring work into an iteration as well as take work out of an iteration. One of the four values of the Agile Manifesto is Responding to change over following a plan. The DA toolkit endorses this statement. As a Team Lead applying this practice you need to understand that if your team gets ahead of their work schedule they should know to contact the Product Owner and sign up for new assignments from the ranked stack of work items. Likewise if a Team Member is behind and will not finish you need to know how to track work that is not finished and to make sure that the Product Owner is informed so they can set proper expectations. If you have part way completed software products that need to be taken out of a release be prepared to back out code/comment out code/disable features as needed. If you have a good working relationship with your Product Owner then removing work from an Iteration should not be particularly difficult especially when the Product Owner is comfortable that your team will also pull work into an Iteration when they finish work early.
11. Master the art of story decomposition – There is no better way to set your team up for success than to ensure that stories your team is assigned to an Iteration are small enough that they can be released (not just constructed) within an Iteration. This area of expertise is one of the hardest to master. Imagine the Product Owner saying I cannot make a smaller story out of a two-way data exchange such as a consumer credit exchange between two systems. The Product Owner can argue that this story cannot be broken down any further because doing so would not provide any business value. An appropriate response from the Team Lead would be that the Team has estimated the story point of 5 points to do the complete process and you only have 3 points to assign to the team. The Team Lead can break this story down into sending and receiving and processing the consumer credit information and they could ask the Product Owner which business scenario they would like to have delivered first: sending the customer information to the credit provider or processing the results from the credit provider? If the Product Owner says both then the Team Lead can explain that you will not work on this story and instead will find another 3 point story if the Product Owner does not feel that creating 2 separate stories is appropriate. In this scenario the Team Lead is providing a good option to the Product Owner while simultaneously staying committed to following good planning practices. DAD Teams and Team members are self-disciplined because they only commit to as much work as they can accomplish.
12. Foster an environment where the Team takes credit for victory and accepts responsibility for mistakes. As Team Lead you can set the tone to ensure that blaming individuals for mistakes is not accepted. Instead, find out what actions the Team could have performed to prevent the mistake. If you are following the recommendations of the DA toolkit to have team members be generalizing specialists then you will find that team members are much more likely to provide honest feedback that can correct past mistakes. When Team Members understand that they can be completely open about what needs to change to improve processes you will see them demonstrate ownership and innovate in ways you cannot imagine. The sum of the parts is truly greater than the whole in a well run DAD Team.
Summary: An Excellent Team Lead is like a shepherd for the DAD Team that is guiding the team to achieve their Iteration Goals through performing and often repetitive set of responsibilities that will uncover areas of concern that require action and decisions making. By putting themselves in a position to make real time decisions the Team Lead can help to achieve making business value by helping the Team be effective and efficient. The Product Owner will realize the benefit from a well run Team because they will see products being delivered consistently. A Disciplined Team Lead is able to contribute to crafting and supporting the rules that govern the Software Development process in their organization and also knows when to bend and break the rules in order to help his team achieve and realize maximum business value in the form of deployed and functional working software products while simultaneously spending the least amount of time and effort to complete these products.
This article was written by Craig Dewalt for the Disciplined Agile blog.