Disciplined Agile

A few people have commented that Disciplined Agile Delivery (DAD) promotes a wide range of practices, which they like because it makes their options explicit but which they also potentially dislike because there’s so many practices to choose from.  This then leads to the question of why do we need so many practices?  First, there are a lot of practices out there to begin with and our philosophy is to help people know that they have options and help them to select the right ones.  Second, our experience is that for a practice to be easily consumable it should be:

1. Small.  Small practices are generally more straightforward than larger practices.  As a result they’re easier to understand and to adopt.
2. Cohesive.  A good practice addresses one issue and one issue only.
3. Loosely coupled.  Good practices, like good software modules, have minimal dependencies on other practices.

Practices that are small, cohesive, and loosely coupled are easier to configure into more interesting solutions.  For example, the practice of test-first programming (TFP) is combined with refactoring to form test-driven development (TDD).  The practice of (writing) executable specifications can be combined with TDD, or TFP for that matter, to give you behavior driven development (BDD) or acceptance test-driven development (ATDD).  The combination of iteration modeling, model storming, look-ahead modeling, and BDD can give you a strategy for addressing emergent requirements and design during an iteration.

Of these three aspects, we’ve found that coupling has the greatest impact on your ability to tailor your approach to meet the unique situation you find yourself in.  Just like highly coupled software is difficult to maintain and enhance, processes built from highly-coupled practices are too.  For example, consider the way that Scrum describes product backlogs.  A product backlog is one of several strategies that agile teams may use to manage their work.  In the case of Scrum, the strategy is to prioritize requirements by business value and then focus on implementing the highest priority work at all times.   Unfortunately Scrum has coupled many important practices to the product backlog concept.  For example, initial requirements modeling is often referred to as populating the backlog.  Prioritization of new requirements and exploring upcoming requirements is referred to as grooming the backlog.   There are several potential problems to consider:

1. The term “populating the backlog” masks the fact that not only are you writing initial functional requirements (for example user stories or features) as part of your initial requirements modeling efforts you’re also sketching things (processes, screens, data structures, …), identifying non-functional requirements, holding modeling sessions, and many other things.
2. It makes it harder for people new to agile to understand how it works.  Think of it like this, what’s a more descriptive term, “populating the backlog” or “initial requirements modeling”?
3. It makes it harder to combine practices.  If you wanted to swap out the product backlog for something a bit more sophisticated, such as a work item list, or something leaner like a work item pool, what do you do with the practices coupled to product backlog?  Do you  rework “backlog grooming” to be “work item list grooming”?  Do you rework “populating the backlog” to be “populating the work item pool”?  Even if these things are easy to do, seems like needless effort to me.

In conclusion, we have found that adopting small, cohesive, and loosely coupled practices enables you to adopt and tailor a process strategy that better reflects the context of the situation that you face.    Not only is high cohesion and loose coupling great strategies for software, their great strategies for software process too.

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.

When a disciplined agile project or product team starts one of the process goals which they will likely need to address is Explore Initial Scope.  This is sometimes referred to as initially populating the backlog in the Scrum community, but as you’ll soon see there is far more to it than just doing that.  This is an important goal for several reasons.  First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding.  Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost.  Having an understanding of the scope of your effort is important input into answering those sorts of questions.

The process goal diagram for Explore Scope is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

Let’s consider each process intent/decision point:

• Choose the level of detail.  How much effort should you put into capturing the requirements, if any at all.  A small co-located team may find that capturing user stories on index cards to be sufficient, whereas a team that is geographically distributed across several locations will find that it needs to capture point-form notes about each story using an electronic tool, and a team in a life-critical regulatory environment may need to capture even more detail to the point of doing big requirements up front (BRUF).
• Explore usage. Although much ado has been made of user stories, and they can be applied quite effectively in a range of situations, the fact is that they’re only one of several options for your team to explore usage of the solution (scenarios, personas, and use cases being other options).
• Explore the domain. Some teams will choose to do some domain modeling via a data model or class diagram, as well as address other views as appropriate.
• Explore the process. Many teams will discover that they need to explore the overall workflow, or business process, supported by their solution so as to help them better understand their usage requirements.
• Explore user interface (UI) needs. Many agile teams will also choose to create user interface prototypes, either low-fidelity UI prototypes using paper or even high-fidelity UI prototypes using a prototyping tool or code, particularly when they face a complex domain.
• Explore general requirements.  There are several types of functional requirements modeling techniques that can be valuable that don’t fit well into the previous categories.
• Explore non-functional requirements.  How will non-functional requirements pertaining to availablity, security, performance, and many other issues be addressed?  Teams in straightforward situations may find that capturing them as technical stories may be sufficient.  Teams facing technical complexity, and sometimes even domain complexity, soon discover that they need a more sophisticated strategy.
• Apply modeling strategy(ies).  How will your team go about working with stakeholders to elicit/discover their perceived needs?  Will they hold informal modeling sessions in an agile modeling space?  Will they hold formal modeling sessions, perhaps following a Joint Application Design (JAD) strategy?  Will they interview people one-on-one?  Combinations thereof?
• Choose a work item management strategy.  Early in the project you will want to determine how you intend to address changing stakeholder needs throughout the project as this will affect how you address the other process issues in this list.  For example, do you intend to adopt Scrum’s value-driven product backlog strategy, DAD’s risk-value driven work item list, a lean work item pool strategy (as followed by DAD’s lean lifecycle), or even a formal approach?  A team in a strict regulatory environment may be required to have a more formal approach to change management than a team without this restriction.

I wanted to share two important observations about this goal.  First, this goal, along with Identify Architecture Strategy, Coordinate Activities, and Accelerate Value Delivery seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  As you saw in the discussion of the process issues, the process tailoring decisions that you make regarding this goal will vary greatly based on the various scaling factors.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should choose their own way of working, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DA tool kit provides this guidance.

Related Reading

• Guided Continuous Improvement (GCI)
• Choosing Your WoW: The Situation Context Framework (SCF)

One of the key characteristics of Disciplined Agile (DA) is that it is goal driven rather than prescriptive.   This simplifies process tailoring, simplifies identifying potential process improvements, reduces the prescription inherent in other software methods, and enables scaling.  One of the process goals identified by the DA toolkit is Coordinate Activities, one of the ongoing goals throughout the delivery effort.  The fundamental question that this goal addresses is what options do individuals on an agile team have to coordinate their work with other people that they are involved with?  Note that this work may not occur completely within the team, that team members may find that they need to coordinate with people external to their team.

The process goal diagram for Coordinate Activities is shown below.  The rounded rectangle indicates the goal, the squared rectangles indicate issues or process factors that you may need to consider, and the lists in the right hand column represent potential strategies or practices that you may choose to adopt to address those issues.  The lists with an arrow to the left are ordered, indicating that in general the options at the top of the list are more preferable from an agile point of view than the options towards the bottom.  The highlighted options (bolded and italicized) indicate default starting points for teams looking for a good place to start but who don’t want to invest a lot of time in process tailoring right now.  Each of these practices/strategies has advantages and disadvantages, and none are perfect in all situations, which is why it is important to understand the options you have available to you.

An interesting thing about this process goal diagram is that it makes it very clear that there might be a bit more to coordination on an agile team than just holding a short meeting every day.  For example, people may share information within the team, and with people external to the team, via conversations, reviews, and non-solo development techniques such as pair programming or modeling with others.  Another interesting thing is that to avoid the problem of method branding we use descriptive terms such as Coordination Meeting instead of Scrum Meeting or Daily Scrum.

Several of the issues are team focused, in particular Artifact Ownership and Coordinate Within Team.  Several reflect the fact that DA teams are enterprise aware and thus describe strategies to coordinate with others external to the team.  For example, your team may need to coordinate with your organization’s enterprise architects and operations staff, potentially adopting some of the strategies captured by Coordinate Across IT (and you are also likely to do so via Share Information strategies).  If your organization has a release organization then your team may need to adopt one or more Coordinate Release Schedule strategies (or, if there’s no release team then your team will still need to coordinate releases with other delivery teams, and with your operations team, somehow).

Several issues address scaling factors.  For example, large teams (often called programmes) will find that they need to adopt strategies called out by Coordinate Within Program.  Teams that are geographically distributed or organizationally distributed will need to consider strategies from Coordinate Between Locations.  Naturally if you don’t face a scaling issue such as geographic distribution then the issue Coordinate Between Locations isn’t something you need to consider.

I wanted to share two important observations about this goal.  First, this goal, along with Explore Scope, Identify Architecture Strategy, and Accelerate Value Delivery seem to take the brunt of your process tailoring efforts when working at scale.  It really does seem to be one of those Pareto situations where 20% addresses 80% of the work, more on this in a future blog posting.  Second, as with all process goal diagrams, the one above doesn’t provide an exhaustive list of options although it does provide a pretty good start.

I’m a firm believer that a team should tailor their strategy, including their team structure, their work environment, and their process, to reflect the situation that they find themselves in.  When it comes to process tailoring, process goal diagrams not only help teams to identify the issues they need to consider they also summarize potential options available to them.  Agile teams with a minimal bit of process guidance such as this are in a much better situation to tailor their approach that teams that are trying to figure it out on their own.  The DA toolkit provides this guidance.

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.