Disciplined Agile

by
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog

RSS

Recent Posts

Disciplined Agile Principle: Optimize Flow

Disciplined Agile Principle: Enterprise Awareness

Disciplined Agile Principle: Choice is Good

Disciplined Agile Principle: Pragmatism

Disciplined Agile Principle: Be Awesome!

Disciplined Agile Principle: Optimize Flow

Categories: Fundamentals, Principle

Optimize Flow

One of the seven principles behind Disciplined Agile (DA) is Optimize Flow.  Your organization is a complex adaptive system (CAS) of interacting teams and groups that individually evolve continuously and affect each other as they do. The challenge that we face is how do we ensure that these collaborating teams do so in such a way as to effectively implement our organization’s value streams? How do we ensure that these teams are well aligned, remained well aligned, and better yet improve their alignment over time?

The implication is that as an organization we need to optimize our overall workflow. The DA toolkit supports a large number of strategies to do so:

  1. Deliver continuously at a sustainable pace. The Disciplined Agile Manifesto advises teams to deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. This philosophy is one of four, in this case Deliver, promoted by the Heart of Agile. Similarly it is one of four philosophies of Modern Agile, in this case Deliver Value Continuously, and it is a fundamental strategy of Disciplined DevOps. Since 2001 agilists have shown that it is possible to deliver high-quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Enabling these teams to delivering potentially shippable solutions on demand motivates them to stay focused on continuously adding value.
  2. Optimize the whole. Disciplined agilists work in an “enterprise aware” manner – they realize that their team is one of many teams within their organization and as a result they should work in such a way as to do what is best for the overall organization and not just what is convenient for them. More importantly they strive to streamline the overall process, to optimize the whole as the lean canon advises us to do. This includes finding ways to reduce the overall cycle time, the total time from the beginning to the end of the process to provide value to a customer, is a key part of doing so.
  3. Make work flow. The 14th principle of the DA Manifesto is to visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum. This strategy enables teams to identify and then remove bottlenecks quickly and is adopted straight out of Kanban.
  4. Eliminate wasteLean thinking advocates regard any activity that does not directly add value to the finished product as waste. Waste includes time waiting for others to get something done, creation of unnecessary work artifacts or product features, and collaboration churn resulting from crossing organizational boundaries. To reduce waste it is critical that teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish.
  5. Improve continuously. As a leader you want to promote a culture of continuous improvement, including the sharing of skills and knowledge between people and teams, within your organization. This is seen as a fundamental philosophy of agile – The 12th principle behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly” and both Improve and Reflect are principles of the Heart of Agile. A key technique that supports continuous improvement is “double-loop learning” that promotes the idea that you modify your approach based on what you learn from your experiences.
  6. Experiment to learn. Probably the most significant impact of Eric Ries’ work in Lean Startup is the popularization of the experimentation mindset, the application of fundamental concepts of the scientific method to business. This mindset can be applied to process improvement following what Ries calls a validated learning strategy. From a process point of view, the strategy is to first identify an improvement hypothesis along the lines of “We think doing X will improve Y”. Second, run a short experiment by trying it out in a controlled manner, with measurements in place to see the effect of the change. Third, observe what happens to determine the efficacy of X and whether you need to evolve X and run a follow up experiment (double-loop learning). An experimentation mindset reinforces and often speeds up the strategy of continuous learning. As we pointed out earlier, to enable an experimentation mindset within your organization as a leader you must establish a safe environment where experimentation is encouraged and rewarded.
  7. Measure what counts. When it comes to measurement, context counts. What are you hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and more importantly how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that your measurement strategy must be flexible and fit for purpose, and it will vary across teams.
  8. Prefer long-lived stable teams. A very common trend in the agile community is the movement away from projects, and the project management mindset in general, to long-lived teams. Such teams evolve over time, people occasionally join the team and people occasionally leave the team, but the team itself may run for years. For example, Microsoft has had a team developing and sustaining Microsoft Word since 1981 with no end in sight.  It’s important to note that this move away from project management in the agile community is not a move away from management but instead from the inherent risks and overhead of projects.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

Posted on: October 16, 2019 12:00 AM | Permalink | Comments (1)

Disciplined Agile Principle: Enterprise Awareness

Categories: Fundamentals, Principle

Enterprise awareness is one of the key principles behind Disciplined Agile (DA).  The observation is that DA teams work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems currently in production and minimally your solution shouldn’t impact them.  Better yet your solution will hopefully leverage existing functionality and data available in production.   You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa.  Your organization may be working towards business or technical visions which your team should contribute to.  A governance strategy exists which hopefully enhances what your team is doing.

WHAT IT MEANS TO BE ENTERPRISE AWARE

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization. Disciplined agile professionals will:

  • Work closely with enterprise professionals. This includes working closely with enterprise technical architects and reuse engineers to leverage and enhance the existing and “to be” technical infrastructure; enterprise architects and portfolio managers to fit into the overall business ecosystem; senior managers who should be governing the various teams appropriately; operations staff to support your organization’s overall development and operations (DevOps) efforts; data administrators to access and improve existing data sources; IT development support people to understand and follow enterprise IT guidance; and business experts who share their market insights, sales forecasts, service forecasts, and other important concerns. In other words, teams should adopt a “whole enterprise” mindset.
  • Adopt and follow enterprise guidance. Your organization may have, or hopes to one day have, a range of standards and guidelines (guidance) that it wants delivery teams to adopt and follow. This may include guidance for coding, user interface development, security, and data conventions to name a few. Following common guidance increases the consistency and maintainability of your solutions, and thus your overall quality.
  • Leverage enterprise assets. There may be many enterprise assets, or at least there should be, which you can use and evolve. Disciplined agile teams strive to work to a common infrastructure; for example, they use the enterprise-approved technologies and data sources whenever possible, and better yet they work to the “to be” vision for your infrastructure. If your organization uses a disciplined architecture-centric approach to building enterprise software, there will be a growing library of service-based components to reuse and improve upon for the benefit of all current and future solutions. To do this DA teams will collaborate with enterprise professionals throughout the lifecycle and particularly during Inception during envisioning efforts. Figure 1 summarizes the Inception phase goal Align with Enterprise Direction which summarizes the strategies you may choose to follow. Read Disciplined Agilists Take a Goal-Driven Approach for more information on DA’s goal-driven strategy.

Figure 1. Inception Goal: Align with Enterprise Direction.

Align with Enterprise Direction

 

  • Enhance your organizational ecosystem. The solution being delivered by a DA team should minimally fit into the existing organizational ecosystem – the business processes and systems supporting them – it should better yet enhance that ecosystem. To do this, the first step is to leverage existing enterprise assets wherever possible as described above, often working with enterprise architects or other enterprise professionals to do so. A Disciplined Agile Delivery (DAD) team, one that is focused on software development, will also work with operations and support staff closely throughout the lifecycle to ensure that they understand the current state and direction of the organizational ecosystem. DAD teams will often be supported by an additional independent test team that will perform production integration testing (amongst other things) to ensure that your solution works within the target production environment which it will face at deployment time. Furthermore, experienced DAD teams will even fix problems that they run into via proven refactoring techniques. Figure 2 summarizes the general goal Leverage and Enhance Existing Infrastructure which summarizes strategies for how DAD teams may accomplish this.

Figure 2. General Goal: Leverage and Enhance Existing Infrastructure.

Leverage and Enhance Existing Infrastructure

 

  • Adopt a DevOps Culture. DAD teams will work with operations and support staff closely throughout the lifecycle, particularly the closer you get to releasing into production. DevOps culture and strategies are baked right into DA.
  • Share learnings. Disciplined Agile teams are learning oriented, and one way to learn is to hear about the experiences of others. The implication is that DA teams must also be prepared to share their own learnings with other teams. To do this organizations might choose to support agile discussion forums, informal presentations, training sessions delivered by senior team members, and internal conferences to name a few strategies.
  • Adopt appropriate governance strategies. Effective governance strategies should enhance that which is being governed. An appropriate approach to governing agile delivery projects, and we suspect other types of efforts, is based on motivating and then enabling people to do what is right for your organization. What is right will of course vary, but this typically includes motivating teams to take advantage of, and to evolve, existing corporate assets following common guidelines to increase consistency, and working towards a shared vision for your organization. Appropriate governance is based on trust and collaboration. Appropriate governance strategies should enhance the ability of DA teams to deliver business value to their stakeholders in a cost effective and timely manner. Unfortunately many existing IT governance strategies are based on a command-and-control, bureaucratic approach which often proves ineffective in practice. Our book, Choose Your WoW!, explores appropriate governance, the impact of traditional governance strategies, and how to adopt an appropriate governance strategy in detail. The article Adopting Agile Governance Requires Discipline also provides greater insight.
  • Open and honest monitoring. Although agile approaches are based on trust, smart governance strategies are based on a “trust but verify and then guide” mindset. An important aspect of appropriate governance is the monitoring of project teams through various means. One strategy is for anyone interested in the current status of a DA team to attend their daily coordination meeting and listen in, a strategy promoted by the Scrum community. Although it’s a great strategy we highly recommend, it unfortunately doesn’t scale very well because the senior managers responsible for governance are often busy people with many efforts to govern, not just your team. Hence the need for more sophisticated strategies such as an “development intelligence” approach supported via automated dashboards.

WHY IS ENTERPRISE AWARENESS IMPORTANT?

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 reflect 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

CHALLENGES TO ENTERPRISE AWARENESS

Unfortunately there are two main challenges to supporting enterprise awareness on agile teams. First is the cultural challenge within the agile community that some “agile purists” perceive this as unnecessary overhead. Reasons for this misunderstanding include a lack of understanding of the overall enterprise picture or some agilists who have previous experiences with enterprise professionals who struggle to work in an agile manner. This points to the second challenge that enterprise professionals often don’t understand how to work effectively with agile teams. Sometimes this is because the agile teams they’ve been working with until now haven’t been sufficiently disciplined to work with them effectively, but more often than not it’s because they still choose to follow older, more traditional approaches to their craft.  With Disciplined Agile we are actively working on describing an agile/lean workflow for enterprise IT.

These challenges are cultural in nature, and thus difficult to overcome. Agilists and enterprise professionals need to respect one another and strive to learn more about what the other group is trying to accomplish. They must strive to work with one another and thus learn from each other. Furthermore, they must build a culture of shared commitment and responsibility to the organization. Not only is this possible it is highly desirable.

SUMMARY

Disciplined agile teams and more importantly DA practitioners are enterprise aware. They recognize that enterprise aware strategies improve their ability to provide value to their stakeholders both within the scope of a solution as well as at the organizational level. To coin an environmental cliché: Disciplined agilists act locally and think globally.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

Posted on: October 14, 2019 12:00 AM | Permalink | Comments (3)

Disciplined Agile Principle: Choice is Good

Categories: Fundamentals, Principle

One of the seven principles behind the Disciplined Agile (DA) toolkit is Choice is Good. Let’s assume for a minute that your organization has multiple teams working in a range of situations, which in fact is the norm for all but the smallest of companies. How do you define a process that applies to each and every situation that covers the range of issues faced by each team? How do you keep it up to date as each team learns and evolves their approach? The answer is that you can’t, documenting such a process is exponentially expensive. But does that mean you need to inflict the same, prescriptive process on everyone? When you do that you’ll inflict process dissonance on your teams, decreasing their ability to be effective and increasing the chance that they invest resources in making it look as if they’re following the process when in reality they’re not. Or, does this mean that you just have a “process free-for-all” and tell all your teams to figure it out on their own? Although this can work it tends to be very expensive and time consuming in practice – even with coaching each team is forced to invent or discover the practices and strategies that have been around for years, sometimes decades. Luckily, the Disciplined Agile toolkit provides a better way.

Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA toolkit presents people with choices through the application of process goal diagrams, see the figure below for an example of options for addressing changing stakeholder needs throughout solution delivery. The rounded rectangle indicates the name of the process goal, as in this case, or the process blade/area.  The square rectangles indicate process decision points, issues that you need to consider in your way of working (WoW).  The lists to the right of the process decision points are options, typically practices or strategies that your team may choose to adopt.  When there is an arrow beside the list that is an indication that the strategies towards the top of the list are generally more effective than the strategies towards the bottom of the list.  When a strategy is bolded it is an indication that it is a likely choice for a team that is new to agile, that is addressing a fairly straightforward problem, and that is near located (working on the same floor of a single building).  If that's not your situation then you may find you need to make other choices. Please read Disciplined Agilists Take a Goal-Driven Approach for more information on DA’s goal-driven strategy.

Figure. The goal diagram for Addressing Changing Stakeholder Needs.

Address Changing Stakeholder Needs

The idea of goal diagrams is to make important decision points explicit, such as when to accept changes, and then present teams with their options and the tradeoffs surrounding those options. This enables teams to make better process choices given the situation that they face. To make these choices, teams need to know:what each option is, the tradeoffs associated with each one, and in what situations the option is and isn’t applicable. DA takes a similar, goal/choice-driven approach to IT process areas such as Data Management and Reuse Engineering as well as enterprise process areas such as Enterprise Architecture and People Management (often called Human Resources or Talent Management).

This choice-driven strategy is a middle way. At one extreme you have prescriptive methods, which have their place, such as Scrum and SAFe which tell you the one way to do things. Regardless of what the detractors of these methods will tell you these prescriptive strategies do in fact work quite well in some situations, and as long as you find yourself in that situation they’ll work well for you. However, if you’re not in the situation where a prescriptive method fits then it will likely do more harm than good. At the other extreme are experimental methods such as Spotify that tell you to experiment and learn as you go. This works well in practice but can be very expensive and time consuming and can lead to significant inconsistencies between teams which hampers your overall organizational process. Spotify had the luxury of evolving their process within the context of a product company, common architecture, no technical debt, and a culture that they could grow rather than change.  DA sits between these two extremes – by taking this process goal driven approach it provides process commonality between teams that is required at the organizational level yet provides teams with the flexibility required to tailor and evolve their internal processes to address the context of the situation that they face. Teams can choose from known strategies the likely options to then experiment with, increasing the chance that they find something that works for them in practice. At a minimum, it at least makes it clear that they have choices, that there is more than the one way described by the prescriptive methods.

There is a catchy phrase in the agile world called “fail fast” or better yet “learn fast.” As described earlier leadership should encourage experimentation early in the interest of learning and improving as quickly as possible. However, we would suggest that by referencing the proven strategies in Disciplined Agile you will make better choices for your context, speeding up the learning process and failing less.  We have developed a technique called Guided Continuous Improvement (GCI) that describes how to do this very thing.  I will blog about GCI in future postings and we will soon have PMI-certified workshops that teach GCI.

 

 

 

Posted on: October 09, 2019 12:00 AM | Permalink | Comments (3)

Disciplined Agile Principle: Pragmatism

PragmatismOne of the seven principles behind Disciplined Agile (DA) is Pragmatism. People are often surprised when we suggest that mainstream methods such as Scrum and Extreme Programming (XP) are prescriptive. But they are indeed.  Scrum prescribes a daily stand-up meeting (Scrum) no longer than fifteen minutes to which all team members must attend, that teams must have a retrospective at the end of each iteration (Sprint), and that team size should not be more than nine people.  These are all great ideas, but they don't apply to all situations.  Similarly, Extreme Programming mandates pair programming (two people sharing one keyboard) and Test-Driven Development (TDD). 

We are not suggesting that prescription is a bad thing, we’re merely stating that it does exist.  Many agile purists are quite fanatical about following specific methods strictly.  In fact, we have met many who say that to “do agile right” you need to have 5-9 people in a room, with the business (Product Owner) present at all times.  The team should not be disturbed by people outside the team, and should be 100% dedicated to the project.  However, in many established enterprises such ideal conditions rarely exist.  The reality is that we have to deal with many suboptimal situations, such as distributed teams, large team sizes, outsourcing, multiple team coordination, and part-time availability of stakeholders.

The DA toolkit recognizes these realities and rather than saying “we can’t be agile” in these situations we instead say “let’s be as effective as we can be.” Instead of prescribing “best practices” DA instead provides strategies for maximizing the benefits of agile despite certain necessary compromises being made. As such, DA is pragmatic, not purist in its guidance – DA provides guardrails helping you to make better process choices, not strict rules that may not even be applicable given the context that you face.

 

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

Posted on: October 07, 2019 12:00 AM | Permalink | Comments (3)

Disciplined Agile Principle: Be Awesome!

Categories: Fundamentals, Principle

Be Awesome!One of the seven principles behind Disciplined Agile (DA) is Be Awesome.  Who doesn’t want to be awesome? Who doesn’t want to be part of an awesome team doing awesome things while working for an awesome organization? We all want these things. Recently Josh Kerievsky has popularized the concept that Modern Agile teams make people awesome, and of course it isn’t much of a leap that we want awesome teams and awesome organizations too. Similarly, in their work on Lean Software Development the Poppendiecks observe that sustainable advantage is gained from engaged, thinking people. Helping people to be awesome is important because, as Richard Branson of the Virgin Group says, “Take care of your employees and they’ll take care of your business.”

There are several things that you as an individual can do to be awesome:

  • Act in such a way that you earn the respect and trust of your colleagues – be reliable, be honest, be open, and treat them with respect.
  • Willingly collaborate with others. Share information with them when asked, even if it is a work in progress. Offer help when it’s needed and just as important reach out for help yourself.
  • Be an active learner. Seek to master your craft, always being on the lookout for opportunities to experiment and learn. Go beyond your specialty and learn about the broader software process and business environment. By becoming a T-skilled “generalizing specialist” you will be able to better appreciate where others are coming from and thereby interact with them more effectively.

Awesome teams are built around motivated individuals who are given the environment and support required to fulfill their objectives. A 2015 study at Google found that successful teams provide psychological safety for team members, that team members are able to depend on one another, there is structure and clarity around roles and responsibilities, and people are doing work that is both meaningful and impactful to them. Awesome teams have a very good working relationship with their stakeholders, collaborating with them to ensure that what they do is what the stakeholders actually need. Finally, awesome teams are whole – they are cross functional, having the skills, resources, and authority required to be successful and team members themselves tend to be cross-functional generalizing specialists.

Awesome teams also choose to build quality in from the very beginning. Lean tells us that your process should not allow defects to occur in the first place, but when this isn’t possible (yet) you should work in such a way that you do a bit of work, validate it, fix any issues that you find, and then iterate. The Agile Manifesto is clear that continuous attention to technical excellence and good design enhances agility.

As a leader, you can enable your staff to be awesome individuals working on awesome teams through providing them with the authority and resources required for them to do their jobs, by building a safe culture and environment (see next principle), and by motivating them to excel. As Dan Pink points out, people are motivated by being provided with the autonomy to do their work, having opportunities to master their craft, and to do something that has purpose. What would you rather have, staff who are motivated or demotivated?

 

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

Posted on: October 04, 2019 12:00 AM | Permalink | Comments (3)
ADVERTISEMENTS

No matter how much cats fight, there always seem to be plenty of kittens.

- Abraham Lincoln

ADVERTISEMENT

Sponsors

Vendor Events

See all Vendor Events