Category Archives: Philosophies

Agile is supposed to be easy, right?

The Agile manifesto is only 4 lines, there are only 12 principles for agile software and the original Scrum Guide was less than 20 pages, so how hard can Agile be?

 

Chess has only a couple of dozen basic moves so how hard can it be to get to checkmate?

 

 

How many times have you heard?

  • All you need to be Agile is to get the team doing a few funky ceremonies

Or the approach to evolving a team from forming to performing:

  • If the team isn’t performing after a month then the manager is not effective.

Despite the apparent simplicity of Agile, transforming to Agile is hard and the learning curve is very steep.  Depending on the team and the individuals, a transformation from waterfall to a high performing Agile team can take anywhere from 6 months to a year or more.  That’s not to say that they won’t be productive over that period of time.  In fact, they will start delivering business value at the end of the first iteration, but the team will be in constant growth and development over that period of time because not only do the people have to learn a new process, they also need to learn a new way of thinking as well as a new way of working as a team.

1.0 A new process

Aside from being excited to work with the thought leaders in the agile world, the reason I joined with SA+A is because of the Discipline Agile Delivery (DAD) decision framework and the way it captured all the tough stuff that I had been wrestling with for years.  With many years of experience building agile teams, I considered myself somewhat of an expert with answers to a lot of the difficult questions.  When I reviewed the DAD framework I realized that the answers I had gained from my own personal experience would not apply in all circumstances or for all teams.  Context counts.  The DAD Agile/Basic and Lean/Advanced project lifecycles have three phases: inception, construction and transition.  Each phase has a collection of process goals, and each goal encompasses several process decision points.  And, each decision point has a collection of options to choose from.  These process goals, decision points and options have been empirically assembled by analyzing many agile teams to see what makes an agile team successful.  This framework gives a team the ability to define a process that works for them.  Is this difficult to do?  Absolutely!  Defining a process to use is always difficult. BUT…..  The framework provides some guidance. Each goal option has default options that the team can use to get started and the options are listed in preference order so the team can easily pick an initial option.  As the team evolves and matures they can chose the more advanced options and evolve and mature their process.  Does the framework include all possible options?  Definitely not, but the options are certainly extensive.  The framework has evolved over time and continues to evolve as the coaches and thought leaders gain more experience and work with more diverse teams.

No matter which lifecycle the team has chosen to use; whether the team is using classic Scrum (Basic/Agile) or Kanban (Advanced/Lean) or a tailored process created using a framework such as DAD, the team is going to need practice and discipline to get it right.  That means, executing the lifecycle, doing periodic retrospectives, updating the process and then repeating again and again until they get it right.  Changing behaviors is hard and the team will struggle to be successful.

2.0 A new way of thinking

No matter how you cut it, transforming to Agile is a cultural change and culture changes are hard.  Not only is it hard for those who want to make the change but almost inevitably there will be pockets of resistance from people are happy with “the way we’ve always done it”.  Unfortunately, political infighting is the biggest risk to innovation. It is going to happen, you may as well brace yourself for it.

The roles are changing from traditional roles (such as: developer, business analyst (BA), system analyst (SA), quality assurance (QA) and project manager (PM), to new unfamiliar roles (such as: product owner (PO), team lead (TL), architecture owner (AO) and team member).  The traditional roles may be deeply embedded in your HR hiring and performance review processes. Transitioning to the new roles will require a realignment of skills and abilities that is bound to cause great consternation amongst the team members.  Often this is a very difficult transition for project managers, in particular, because they find that a lot of the traditional tasks (i.e. work breakdown structures, planning, estimating, etc.) are now the responsibility of the whole team.

The team needs to start thinking in smaller deliverable pieces.  The concept of delivering a complete system from known specifications at the beginning of the project has been the fallacy of traditional development.  The cost of delaying delivery to the very end of the project and the lack of ability to meet actual customer needs can be eliminated by delivering minimum functionality early and augmenting with new and improved functionality iteration after iteration in close collaboration with the end customer.  But moving to this model of continuously delivering can be a tough adjustment for developers.  Even (or maybe especially) for seasoned developers, the concept of starting to build and deliver not knowing all the detailed specifications up front can be very unsettling. Getting comfortable with this model takes time and experience before developers cease to fall back on old behaviors.

One of the pillars of agile is complete transparency with the business and the stakeholders into the team, the process they are using and the delivery of the business functionality.  With the business embedded in the team on a day to day basis and iteration reviews to demonstration and approve all the deliverables from each iteration, there is no hiding problems when they occur and no hiding late deliveries or failed iterations.  On the flip side, the business is there to celebrate the wins and recognize the deliveries at the end of each iterations and they are part of determining the velocity of the team and adjusting the schedule to match the velocity.

The new way of thinking also requires new tools.  Tools that can build dashboards to automate and display the development intelligence metrics that provide transparency into the team’s performance.  Tools that automate configuration management, continuous integration and continuous integration as well as automated testing.  All of these endeavors are hard and required skilled individuals to lead; none of these comes for free.

3. A new way of working with others

More people skills are required by everyone.  People are now going to be working much closer together physically and will be interacting and collaborating on a much more frequent basis.  Experience working together (often for many years) may give an advantage to some team members, however, they still need to learn how to work together as a team.

3.1 Team Development Phases

Tuckman’s team development model includes the phases: forming, storming, norming, and performing. These phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.  The number of iterations required to move through the phases will vary by team depending on factors such as: company culture, skills, experience, familiarity with each other, leadership (or lack thereof), external influences and coaching etc. Teams may also plateau in a phase before entering the next phase.

Agile teams will go through the four Tuckman phases:

  1. Forming. All teams will go through the forming phase. Typically this take 4 to 6 iterations for the team to: understand the lifecycle process, understand how to work together, understand what the team goal is, and most importantly to get comfortable enough with each other to risk the possibility of conflict.  During this phase, the team’s velocity will vary considerably especially for the expected failed iterations although there should generally be a trend upward in the velocity.  Retrospectives in this phase tend to be very cordial and factual because everyone is avoiding conflict.
  2. Storming. The storming phase can be very upsetting to both the team members and team managers. Often managers will step in to solve the storming issues without realizing that it is a necessary phase for the team to work through on their own.  Conflict, disagreements and personality clashes must get resolved before the team can move to the next phase.  Unfortunately, this phase is a make or break phase and it is hard to predict just how many iterations it will take but it is not usual to expect 3 or 4 pretty rough iterations.  Some teams will completely disintegrate during this phase and it is certainly not unusual to have a decrease in velocity during this phase.  Some members of the team may find they have basic incompatibilities and need to move to another team and this change in team membership can revert the team back to the forming phase.  The retrospectives tend to be very interesting and intense during this phase as they deal with the inter-personal issues of the team.  You can pretty much expect that there are going to be some hurt feelings no matter how safe an environment you have.
  3. Norming. The norming phase is when the team comes back together stronger and more cohesive for having weathered the storming phase. They have resolved their issues and have developed a new synergy where the team just “works well together” and it is fun to be part of the team. The team velocity should trend upward and then level off as the team hits its capacity consistently.  With the new-found synergy of the team, the retrospectives can focus on process improvement and optimizing the operation of the team with the hope of transitioning to the performing phase.
  4. Performing. The performing phase is the goal for all teams but very few actually get to this phase. Not all teams can get to the high level of performance of a Special Ops team where each member knows exactly what their team mates are doing and what they need to do to work as a cohesive unit.  A team in performing phase no longer needs a coach or supervision but can operate autonomously and efficiently.

3.2 Team changes everything

With self-organizing teams, decisions are now made at the team level rather than at the PM or manager levels.  This can be a difficult transition for both the team members and the managers.  Team members are often use to others making the decisions for them and wait for decisions or are reluctant to make decisions.  Managers often feel disempowered when decisions are no longer in their hands because the decisions are made by the team.

The team still has the responsibility to do the traditional activities such as; analysis, design, development testing and deployment.  However, under the new model, the team also takes on the inception responsibilities of: developing user stories, sizing the stories, estimating the stories, creating the product and architectural vision, and developing the release plan.   During construction the team also has to: plan the iteration, do look ahead planning, and have an iteration review (i.e. demo) with the stakeholders.  To keep the team working together they need to have the daily coordination meeting (i.e. Scrum) and to keep the team growing and evolving of course they need to do the retrospective at the end of each iteration.

Thinking, analyzing, planning and building just-in-time is a new way of thinking for a traditional team.  The inception phase in particular can be a difficult adjustment.  Designers and developers are used to doing all the analysis and design upfront.  Doing just enough analysis to be confident of a solution and then writing the user stories to do the work and build the plan is a difficult transition.  Writing user stories so they can get started and learn as they go is a very difficult transition.  Building just the simplest framework and then adding required features and functionality as needed requires practice, training and reinforcement.

There is much more focus on delivering quality because the team is responsible for development, delivery as well as product support.

4.0 The Bottom Line

Chess has only a couple of dozen basic moves and so it is simple to learn the basics.  However, after 3 moves there can be several billion moves available making it so complex that it can take a lifetime to master.  Transforming to Agile is a lot like that.  It looks very simple on the surface but under the covers it can get very complex very quickly.  That’s where the value of a good coach comes in.  You need a coach who brings a lot of experience to the table who will be open and honest with you about what needs to be done and how to get a successful transformation.

The Disciplined Agile Portfolio Management Mindset

Mindset

IT Portfolio Management addresses how an IT organization goes about identifying, prioritizing, organizing, and governing their various IT endeavors.  Disciplined Agile Portfolio Management seeks to do this in a lightweight and streamlined manner that maximizes the creation of business value in a long-term sustainable manner. IT endeavors typically include solution delivery initiatives/projects, stable product development teams, business experiments (along the lines of a lean startup strategy), and the operation of existing IT-based solutions.

Being agile, having an agile mindset, is foundational to working in an agile manner. The Disciplined Agile Manifesto and the principles of lean software development provide an important start at this mindset. In this blog we explore similar agile philosophies that are specific to successful portfolio management. These philosophies are:

  1. Keep it simple. Keep your portfolio management activities as streamlined and lightweight as can be. Your goal should be to focus on making good decisions and providing guidance to people, not on maintaining extensive documentation or reviewing documentation. You still may choose to maintain artifacts such as a portfolio roadmap and portfolio budget, but those too should be as lightweight and concise as possible.
  2. Focus on value over cost. Shifting your mindset from “what is this going to cost?” to “what value will this generate?” is critical to your success because it helps you to focus making better IT investments. You want to invest in IT endeavors that enhance your organization’s ability to produce value for your customers. This in turn provides the profits required for further investment.
  3. Reduce the cost of delay. One of the strategies for maximizing stakeholder value is to invest in developing functionality that will provide value to the organization soonest.   For example, if you delay developing functionality that will generate annual revenue of $10 million for six months you have an effective cost of delay of $5 million because you missed out on half a year of revenue.   Disciplined agile portfolio managers consider the cost of developing a solution, the cost of delay that results from putting off said development, and the revenue generated (or cost savings) when calculating the overall value of a solution.
  4. Invest in streamlining the creation of value. Not only do we want to produce value for our customers, we also want to be good at doing so. The implication is that we sometimes need to invest in ourselves through process or environment improvements.
  5. Prefer stable teams over project teams. Although portfolio management is often believed to be the oversight of project teams, it really is more about the coordination and oversight of teams in general. In Disciplined Agile we recognize that an initiative is seldom finished at the end of a “project”. There are usually subsequent changes required over time requiring future releases of the solution. The agile community has discovered that long-lived stable teams, whose membership evolves over time, have significant advantages over short-lived project teams. A significant productivity improvement occurs when IT organizations shift away from the project mindset of bringing people to the work and instead decide to bring work to the people (the stable teams).
  6. Align teams to value streams. These stable teams should be aligned long-term to value streams or lines of business (LOBs). High performing agile teams reliably deliver value frequently to their business stakeholders. As a result the business learns to trust the teams aligned to their areas. This positive feedback cycle maximizes the effectiveness of your agile teams. Additionally, over time they learn more about the business adding to their effectiveness.
  7. Enable diversity. Every person, every team, and every organization is unique. Every team faces a unique situation that evolves over time. The implication is that teams must be allowed to organize themselves and to tailor their process to meet the context of the situation that they face. This is why the Disciplined Agile framework focuses on providing, and comparing and contrasting, a wealth of process choices. The implication for portfolio managers is that they need to be flexible in their approach. They will work differently with each team because each team works differently, yet they must still provide good guidance to these teams and monitor the effectiveness of each team appropriately.
  8. Trust but verify. Effective governance is based on enabling and then trusting your teams to do the right thing. However, effective teams monitor themselves through the use of automated dashboard technology and close collaboration, and the metrics that teams collect should be made visible to senior management and other stakeholders so that they may monitor what is happening.
  9. Govern by risk not by artifacts. Traditional governance often focuses on the review of common artifacts such as requirement documents, architecture models, and test results. Because it is relatively easy for teams to create the documentation that you want to see, in practice there is very little governance value in reviewing these artifacts. Agile governance instead focuses on addressing common risks such as ensuring there is an agree to vision for what the team should accomplish, that the architectural strategy has been proven to be viable early in the lifecycle, and that the team has produced sufficient business value for their stakeholders.
  10. Rolling wave over annual planning. Annual planning often begins in earnest mid-year which means that prioritized initiatives may not be actually delivered for up to 18 months in the following year. This is not business agility. Make your planning a continuous “rolling wave” activity year round with more detail devoted to planning initiatives no longer than 6 months out. Initiatives planned beyond 6 months should be described at a very high level.
  11. Prefer small initiatives over large initiatives. It is a proven fact that the larger the initiative the greater the chance of failure. Smaller initiatives are easier to plan and are lower risk to execute. Keep your initiatives small to allow for more frequent delivery of value with less investment in work in progress (WIP).
  12. Invest in quality. Ensuring that IT delivery teams produce new business value for your organization is clearly important. But so is ensuring that you will still be able to continue doing so a few years from now. To ensure the long-term sustainability of your IT teams you must allow them to make investments in quality. These investments include building high quality assets in the first place but also fixing low quality assets, what agilists refer to as paying down technical debt, as well.
  13. Optimize the whole. Disciplined agilists are enterprise aware. We choose to optimize the whole instead of locally optimizing a single activity. The implication is that you cannot consider portfolio management on its own but instead must consider it in the context of the other parts of your organization that it affects. A strategy that may make things easier to manage your portfolio, such as having a single way to fund IT delivery teams, may make it easier for your portfolio management efforts but could inflict undue costs and bureaucracy on the teams that you’re funding. For example, does it really make sense for a team asking for $50,000 in funding to go through the same level of rigor as a team asking for $5,000,000? Likely not. Context counts.

Our experience is that the philosophies describe above enable portfolio managers to be more effective in practice. We hope you have found this blog of value and we welcome your feedback.

 

The Principles of Lean Software Development

Principles - canstockphoto18364473 small

In Implementing Lean Software Development, Mary and Tom Poppendieck show how the seven principles of lean manufacturing can be applied to optimize the whole IT value stream. These principles are:

  1. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. The three biggest sources of waste in software development are the addition of unrequired features, project churn and crossing organizational boundaries (particularly between stakeholders and development teams). To reduce waste it is critical that development teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish. Walker Royce argues in “Improving Software Economics” that the primary benefit of modern iterative/agile techniques is the reduction of scrap and rework late in the lifecycle.
  2. Build in quality.  Your process should not allow defects to occur in the first place, but when this isn’t possible 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.  Inspecting after the fact, and queuing up defects to be fixed at some time in the future, isn’t as effective.  Agile practices which build quality into your process include test driven development (TDD) and non-solo development practices such as pair programming and modeling with others.
  3. Create knowledge.  Planning is useful, but learning is essential. You want to promote strategies, such as iterative development, that help teams discover what stakeholders really want and act on that knowledge. It’s also important for a team to regularly reflect on what they’re doing and then act to improve their approach.
  4. Defer commitment.  It’s not necessary to start software development by defining a complete specification, and in fact that appears to be a questionable strategy at best. You can support the business effectively through flexible architectures that are change tolerant and by scheduling irreversible decisions to the last possible moment. Frequently, deferring commitment to the last most responsible moment requires the ability to closely couple end-to-end business scenarios to capabilities developed in multiple applications by multiple projects.
  5. Deliver quickly.  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. Constraining these teams to delivering potentially shippable solutions on a regular basis motivates them to stay focused on continuously adding value.
  6. Respect people. The Poppendiecks also observe that sustainable advantage is gained from engaged, thinking people. The implication is that you need a lean approach to IT governance that focuses on motivating and enabling IT teams—not on controlling them.
  7. Optimize the whole.  If you want to be effective at a solution you must look at the bigger picture. You need to understand the high-level business processes that individual projects support—processes that often cross multiple systems. You need to manage programs of interrelated systems so you can deliver a complete product to your stakeholders. Measurements should address how well you’re delivering business value, because that is the sole reason for your IT department.

Should Software Architects Write Code?

Source code
One of the age-old debates in the software world is whether software architects need to write code.  We suspect that as an industry we’ll never reach consensus on this topic. Here are our thoughts on the subject.

Short Answer:

Hell yes!

Detailed Answer:

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.

Strategy Advantages Disadvantages Considerations
Software architects also develop
  • Helps to keep the architects grounded
  • Developers are more likely to respect the architects and follow their advice
  • Architects are able to create working examples of their strategies, increasing the usefulness to developers
  • More people with architecture skills are needed to support your development teams (arguably a good thing)
  • Apply when you have an ample supply of people with architecture skills, or at least are willing to invest in developing sufficient people
  • Apply when it is critical that developers build well-architected solutions
Software architects don’t develop
  • Architects can focus on architecture
  • Architects can support multiple delivery teams
  • Developers are far less likely to follow the advice of such architects, effectively forgoing any benefit the architects could have brought to your organization
  • The architects are forced to create less-effective artifacts such as white papers and models, as compared with working reference architectures, due to lack of coding skills
  • When you have very few people in your organization with architecture skills
  • The software architects should pair with others so as to transfer their architecture skills to them, thereby growing the pool of software architects and thus making it more viable to allow the software architects to code

In the Disciplined Agile framework 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 framework.

 

Additional Reading:

 

Potentially Shippable Software Isn’t Sufficient: The Glass of Water Analogy

Waterglass

At the end of July I spoke at the Agile 2014 conference in Orlando about what it means to be an agile enterprise.  Part way through that presentation I spoke about the differences between producing potentially shippable software, one of the mantras of the Scrum community, and potentially consumable solutions as promoted by DAD.  To do this I walked people through what I call the glass of water analogy.  Here’s how it went:

I had a glass of drinking water.  I took a sip from the glass to verify that the water was clean and the right temperature for drinking.  The water was very refreshing and was something that I thought others would enjoy.  It was my opinion that this glass of water was potentially shippable.  I took another sip and then offered the water to the audience, there was over 200 people in the room, yet nobody was willing to drink from my glass.  Shocking! I even singled someone out and tried to bully him into drinking my water (oops, I mean I aggressively marketed the wonderfulness of the water to him).  Still, nobody wanted to drink the water.   I took another sip and verified that it was in fact still refreshing.  It was clear to me that my glass of water was potentially shippable.  I could very easily have walked over to anyone in the room and they could easily have drunk from the glass.  But everyone chose not to.  It was potentially shippable from my point of view, but from the point of view of every single audience member it wasn’t consumable.  In a venue where drinks are easily available, not a single person was willing to drink from my water glass (I assume due to a fear of catching my cooties).  Had the venue been different, perhaps a desert with no other sources of drinkable liquids,  someone might have been interested.

The point is that creating potentially shippable software isn’t sufficient.  It needs to be something that people actually want to use, to consume.  It must be a true solution that adds real value for them given their current situation.  Cootie-laden water isn’t attractive when other drinks are readily available.  Similarly, software that is difficult to use compared to other options, that isn’t well supported as other options, or that doesn’t enhance the way that people want to work isn’t going to be very attractive either.

Disciplined agilists focus on producing potentially consumable solutions.  High-quality software is clearly part of this, but that software needs to be usable and something that people want to use.  It needs to be supported with sufficient documentation.  It needs to be supported with adequate hardware.  It may even be part of an overall change to the business process and even organizational structure of the people using that software.  

“Potentially shippable software” is a wonderful slogan, but we need to do a lot better than that. 

Does your team own its process or merely rent it?

Process ownership

An important philosophy within both the agile and lean communities is that a team should own its process. In fact, one of the principles behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” The idea is that teams should be empowered to tailor their approach, including both their team structure and the process that they follow, to meet the unique needs of the situation that they find themselves in. Teams that own their process will tailor it over time as they learn how to work together, adopting new techniques and tweaking existing ones to increase their effectiveness.

As with most philosophies this one is easy to proselytize but not so easy to actually adopt. When it comes to process improvement, teams will exhibit a range of behavior in practice. Some teams see process as a problem and actively seek to ignore process-related issues. Some teams are ambivalent towards process improvement and generally stick with what they’ve been told to do. And some teams see process improvement as an opportunity to become more effective both as a team and as individuals. This range of behaviors isn’t surprising from a psychology point of view although it can be a bit disappointing from an agile or lean point of view. It has led me to think that perhaps some teams choose to “own” their process but many more still seem to prefer to simple rent it.

The behaviors of people who rent something are generally different than those who own something. Take flats for example. When you rent a flat (called an apartment in North America) you might do a bit of cosmetic work, such as painting and hanging curtains, to make it suitable for your needs. But people rarely put much more effort than that into tailoring their rental flat because they don’t want to invest money in something that isn’t theirs, even though they may live in the flat for several years. It isn’t perfect but it’s good enough. When you own a flat (called a condo in North America) you are much more likely to tailor it to meet your needs. Painting and window dressings are a good start, but you may also choose to renovate the kitchen and bathroom, update the flooring, and even reconfigure the layout by knocking down or moving some walls. One of the reasons why you choose to own a flat is so that you can modify it to meet your specific needs and taste.

You can observe similar behaviors when it comes to software process. Teams that are merely “process renters” will invest a bit of time to adopt a process, perhaps taking a two-day course where they’re taught a few basic concepts. They may make a few initial tailorings of the process, adopt some new role names, and even rework their workspace to better fit the situation that they face. From then on they do little to change the way that they work together. They rarely hold process improvement sessions such as retrospectives, and if they do they typically adopt changes that require minimal effort. Harder improvements, particularly those requiring new skills that require time and effort to learn, are put off to some point in the distant future which never seems to come. Such behavior may be a sign that this “team” is not even be a team at all, but instead a group of individuals who are marginally working together on the same solution. They adopt the trappings of the method, perhaps they spout new terminology and hold the right meetings, but few meaningful changes are actually made.

Process owners behave much differently. Teams that own their process will regularly reflect on how well they’re working and actively seek to get better. They experiment with new techniques and some teams will even measure how successful they are implementing the change. Teams that are process owners will often get coaching to help them improve, both at the individual and at the team level. Process owners strive to understand their process options, even the ones that are not perfectly agile or lean, and choose the ones that are best for the situation they find themselves in.

The Disciplined Agile Delivery (DAD) framework is geared for teams that want to own their process. The DAD framework is process goal-driven, not prescriptive, making your process choices explicit and more importantly providing guidance for selecting the options that make the most sense for your team. This guidance helps your team to get going in the right direction and provides options when you realize that you need to improve. DAD also supports multiple lifecycles because we realize that teams find themselves in a range of situations – sometimes a Scrum-based lifecycle makes sense, sometimes a lean lifecycle is a better fit, sometimes a continuous delivery approach is best, and sometimes you find yourself in a situation where an exploratory (or “Lean Startup”) lifecycle is the way to go.

You have choices, and DAD helps guide you to making the choices that are right for you in your given context. By providing process guidance DAD enables your team to more easily own its own process and thereby increase the benefit of following agile or lean approaches.

If the Requirements Aren’t Changing Your Team is Likely in Trouble

I often run into people who are concerned about changing requirements, or evolving requirements if you like that term better, on software development projects (or product teams as the case may be). This is typically a reflection of their training and background in traditional software development strategies where changing requirements are usually perceived as a problem.

In agile we consider changing requirements to be a good thing and we even embrace the idea that this will happen.  In fact, one philosophy of Disciplined Agile Delivery (DAD) is that changing requirements are a sign of a healthy relationship with your stakeholders. Changing requirements indicate that:

  • Your stakeholders are interested in what you’re working on
  • Your stakeholders are thinking about what you’re producing
  • There are feedback mechanisms in place that enable your stakeholders to change their requirements
  • It is easy (hopefully) for stakeholders to change their requirements as their understanding of their needs evolve

So how do you support changing requirements in practice?  The Disciplined Agile Delivery (DAD) framework includes the “Address Changing Stakeholder Needs” goal which guides you through understanding and selecting the right strategy for prioritizing requirements changes as they occur throughout the lifecycle.  These strategies include, but aren’t limited to Scrum’s Product Backlog Strategy, a more disciplined Work Item List strategy, or a lean Options Pool strategy.  In regulatory situations you may even want to consider a formal change management strategy.  DAD’s process goal-driven approach enables disciplined agile teams to tailor their strategy to meet the situation that they find themselves in, avoiding the challenges seen with methods such as Scrum that prescribe a single strategy (in this case Product Backlogs) that don’t work in all situations.

And of course, to minimize the pain of changing requirements you will need to adopt disciplined development practices such as:

  • Writing high-quality code;
  • Refactoring your work to keep it of high quality;
  • Continuous integration;
  • and even acceptance test-driven development (ATTD)/behavior driven development (BDD).