Disciplined Agile

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.

One of the strengths of the Disciplined Agile (DA) toolkit is that it promotes the philosophy that teams must be enterprise aware.  But what does this really mean and why is it important?  Two very good questions that I address in this posting.

For the purpose of our discussion we will focus on five levels of awareness that people may exhibit:

1. Individual awareness.  From this viewpoint it’s all about how someone can change themselves by gaining new skills, insights, experiences, and so on.
2. Team Awareness.  Here the focus is on the team can learn and improve together.  This has been a primary philosophy of the agile community for quite some time, mostly to our benefit but also to our detriment.  Solutions are developed by teams, so by promoting a greater focus on the team agilists are able to improve their overall productivity a bit.  But, if the efforts of that team aren’t well aligned with the overall goals of the organization then dysfunctions will occur.  For example, agile delivery teams that are merely team  aware may end up introducing new technologies that their operations groups aren’t willing or able to support in production.  Or they may reinvent existing functionality.  Or they may create yet another data source even though the data already exists elsewhere.  Or they may develop to their own conventions that don’t reflect the way other teams work.  Or they may learn that a certain technique or strategy works well for them, but they don’t share this learning outside of the team.
3. Departmental Awareness.  People consider the needs of their department, not just their team.  In this case developers are focused on improving the overall process, perhaps by adopting more of a DevOps mindset instead of simply a development mindset.
4. Enterprise Awareness.  People are motivated to consider the overall needs of their organization, to ensure that what they’re doing contributes positively to the goals of the organization and not just to the suboptimal goals of their team.  This is an example of the lean principle of optimizing the whole, in this case the organization, over local optimization at within just the team.
5. Community Awareness.  People consider the needs of their community, doing what they can to give back by sharing knowledge, by striving to learn themselves, and by striving to help others who might not necessarily be in their organization or even known to them.  

Of course, a given individual is very likely operating from several viewpoints at once.

Agile has done a great job of helping the IT profession refocus from individual to team awareness.  But if we want to be effective as professionals we at least need to promote the philosophy of enterprise awareness, so that we’re optimizing the work that we do for our organization.  Agile teams that are enterprise aware will work closely with enterprise professionals, such as enterprise architects and operations staff, to ensure that they are leveraging and better yet enhancing the existing infrastructure.  Their architectures will their organization’s technical roadmap and similarly the scope of their effort will reflect their organization’s business roadmap.  They will follow existing development guidelines and enhance them where appropriate.

By working in an enterprise aware manner DA teams enjoy:

• Higher levels of productivity because they are less likely to reinvent the wheel
• Quicker times to deployment/market because they have less work to do
• Higher return on investment (ROI) because they have less work to do
• Higher levels of quality through following common conventions and reuse

A stakeholder is someone who is materially impacted by the outcome of the solution.  In this regard, the stakeholder is clearly more than an end-user: A stakeholder could be a direct user, indirect user, manager of users, senior manager, operations staff member, the “gold owner” who funds the project, support (help desk) staff member, auditors, your program/portfolio manager, developers working on other systems that integrate or interact with the one under development, maintenance professionals potentially affected by the development and/or deployment of a software project.  To simplify the definition of stakeholders, we’ve adopted Outside In Software Development’s four stakeholder categories:

1. End users.  These are the people who will use your system, often to fulfill the goals of your principals.  They typically want systems which are usable and enable them to do their jobs more effectively.
2. Principals.  These are the decision makers who ultimately pay for and then put your system to use.  This includes gold owners, senior business management, and purchasers of the commercial systems.
3. Partners.  These people make the system work in production.  This includes operations staff, support staff, trainers, legal experts, installers, application hosting companies, and application developers on external systems which integrate with yours.
4. Insiders. These are members of the development team and people who provide technical and business services to your team.  This includes enterprise architects, database administrators, security experts, network experts, toolsmiths, marketing experts, and sales staff.

So why does DAD use the term stakeholder instead of customer?  Although customer is a perfectly good term, it’s very popular with agile adherents, we’ve found that many agile teams will inadvertently limit themselves to considering just end users and principals to be their customers and miss the partner stakeholders and sometimes even the insider stakeholders.  Granted, you’ll often work with some insider stakeholders as a matter of course throughout the project so it’s hard to miss these people, although both of us have seen core agile teams neglect working with their organization’s enterprise architects in the name of “having the courage to worry about tomorrow’s problem tomorrow.”  Our experience is that although the term stakeholder is a bit more formal than the term customer, in practice it seems to lead agile teams to a more mature strategy.

One challenge with the term stakeholder, which customer also suffers from, is that it reinforces the “them vs. us” mentality prevalent in many IT departments.  When we use terms such as “the stakeholders” or “the customers” or “the business” they imply that we see ourselves as a group set apart from them.  The reality is that it isn’t the business, it’s our business, that we’re all in this together.  It’s important to be careful with terminology.

When we describe DAD we remind people that it is not another agile method as we clearly have enough of those already.  Rather, DAD is a process decision framework that enables better decision making when customizing approaches for adopting agile within the context of your organization and projects.  Popular agile methods can be quite prescriptive.  Sometimes their agile rules – work collocated in one room, use teams less than nine people, or don’t do fixed price projects – are not practical.  Rather than discounting such projects as not agile, why not take a pragmatic approach to dealing with these realities while striving to still be as agile as possible?  DAD provides the guidance that enables you to easily tailor, and later evolve, your agile approach to effectively address the context of the situation that you find yourself in.  Hence the term process decision framework.

Another way to look at DAD is that is “pragmatic agile”.  In their book The Pragmatic Programmer, Andrew Hunt and David Thomas describe the need for programmers to be inquisitive, critical thinkers who are realistic and jack-of-all-trades (what we call generalizing specialists).  These qualities are consistent with those we describe for all team members on DAD projects.  This pragmatism reflects the need for agilists to abandon dogmatic, purist approaches to implementing agile and recognize the need to adapt for the complexities of most enterprise projects.  We often encounter management that is frustrated with agile teams that ignore organizational standards and resist compliance with any sort of governance that seeks measure things such as the health, risks, and return on investment for these agile projects.  In return, agile teams often say that management just doesn’t get it.  Surely there is a compromise here.  Management needs to understand that they need to adapt their approach to governing agile projects and agile teams need to be flexible in dealing with the realities of building software solutions for the enterprise.

Why is DAD pragmatic agile?  We feel that it is pragmatic to:

• Take a goal-driven approach which describes the agile strategies available to you, the advantages of disadvantages of each, and when to consider using each one.
• Invest a small amount of time prior to beginning construction to get going in the right direction.  We frame this endeavour in terms of the goals described below in the Inception phase section of Figure 1.
• Plan to spend some time after completing the construction of the solution to properly deploy it to your stakeholders.  This is described via a goal-driven strategie as shown in the Transition phase section of Figure 1
• Do some lookahead planning and modeling, often referred to as backlog grooming, on a just-in-time basis to be more effective when implementing work items during each iteration
• Leverage the existing organizational ecosystem to reuse existing services, patterns, templates, code, guidelines and other assets
• Govern the project teams in an agile manner
• Encourage project specific process improvement through self-organization within the constraints that make sense for the organization
• Adapt the types and formality of work products produced for the context of the projects

We have seen that DAD is certainly resonating with companies that have been struggling to create their own flavour of agile with Scrum, Extreme Programming (XP), and other approaches.  This roll-your-own approach can be difficult and expensive for companies to develop and then maintain.  DAD provides a complete and flexible framework that enterprises have been looking for, enabling them to get on with the actual job of delivering business value to their stakeholders.

How do we apply the toolkit to make better decisions and be pragmatic?  DAD is goal-driven.  Figure 1 shows the goals that are consistent with any type of software development effort regardless of type,  whether it be custom development or implementing a package for instance.

Figure 1.  The Process Goals of Disciplined Agile Delivery.

Figure 2 shows an example of a process goal diagram to show how to fulfill a particular goal.  To address the Explore The Initial Scope process goal we need to consider various issues or factors in order to be most effective for the context that we find ourselves in.  This goal is an important part of the Inception phase so that we can move towards obtaining stakeholder consensus that it makes sense to move into the Construction phase and begin building the solution.  For each issue there are a number of choices.  Some choices, such as work item stack, are bolded and italicized indicate good choices as a place to start for a typical DAD project.  Some issues show an arrow beside the options which is an indication that the choices at the top are typically the most effective and the better alternatives to strive for.  A typical project will make hundreds of process decisions and these diagrams can be used to ensure that the various options are considered.  An example of a decision might be what view type might I use to depict my scope?  DAD recommends starting with a combination of usage modeling, domain modeling, and non-functional requirements.  For usage modeling, user stories is the most popular agile approach, but you could also create use case diagrams or personas as needed.  The DAD book describes each of the alternatives, as well as their advantages and disadvantages of each.  In this way, DAD helps us make better decisions.

Figure 2.  Process Goal Diagram: Explore the Initial Scope.

Is pragmatic agile an excuse for taking shortcuts?  Although the DAD philosophy seeks to be as agile as possible, it is not an excuse for being lazy.  We use the term disciplined for a reason.  We often see organizations that are struggling with Scrum, and the root cause turns out to be that the teams are skipping some of the core Scrum practices.  For instance they may have decided that they have a good process and no longer need to do retrospectives.  In situations like these, the teams have abandoned one or more of the goals of a DAD project.  Referring back to Table 1, we can see that an ongoing goal is to Improve team process and environment.  Another example might be that the team does not do regular, end-of-iteration demonstrations.  Here they are not fulling the goal of Produce a potentially consumable solution.  Perhaps the teams says that they always have working software, but how do we know it is consumable?  Who as seen it?  Have the operations and support staff seen it?  Are end users actually eager to work with it?

As you can see, we can refer to the goals table and ask ourselves, “how are we fulfilling each of these goals?”.  Using this goals driven approach can help to ensure that you do not have gaps in your approach to implementing pragmatic agile.