Welcome to the Disciplined Agile Delivery (DAD) community website! You can follow us by signing up on the sidebar. If you support DAD and would like to contribute to this blog please let us know. Of course you can leave a comment about any post without being a contributor.

Extending the Agile Manifesto

April 10, 2014 2 comments

We have just published a Disciplined Agile Manifesto, an extension to the original Agile Manifesto.

Why have we done this? Since 2001 we’ve applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so.  What we’ve learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations in which we have applied agile and lean strategies.  Because the original authors of the Agile Manifesto have made it clear that they intend to keep their Manifesto static we have decided to move forward on our own with this extension.

We believe that the changes we’re suggesting are straightforward:

  1. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, the DAD framework suggests that we should focus on solution delivery.
  2. Where the original focused on customers, a word that for too many people appears to imply only end users, the DAD framework suggests that it focus on the full range of stakeholders instead.
  3. Where the original manifesto focused on development teams, the DAD framework suggests that the overall IT ecosystem and its improvement be explicitly taken into consideration.
  4. The original manifesto focused on the understanding of, and observations about, software development at the time.  Since then there has been some very interesting work done within the lean community since then (and to be fair there was very interesting work done within that community long before the Agile Manifesto was written).  This manifesto incorporates lean principles, in particular considering the whole, visualizing workflow, and minimizing work in progress (WIP).

For earlier versions of the Disciplined Agile Manifesto, see Reworking the Agile Manifesto on IBM Developerworks and the book Disciplined Agile Delivery.

 

Categories: DAD discussions

Effective Daily Stand Up Meetings

April 2, 2014 1 comment

Standup

A few weeks ago one of my customers asked me for advice about daily standup meetings (also called Scrum meetings, morning meetings, or better yet coordination meetings).  Her feeling was that her teams could become more disciplined in their approach to coordination meetings so she asked if it would be possible to see how teams in other companies run their meetings.  I indicated that there are a lot of good videos on YouTube and that I would write something up soon in a blog posting.  So here goes.

  1. Put your meeting strategy on the wall.  Put the rules (see below) on the wall in the space where you hold your coordination meetings.  If you have virtual meetings online, capture them there (in a wiki for example).  We call things like this information radiators in agile.
  2. Coach people.  It takes time to build up effective meeting skills.  At first you’ll want to coach people publicly within the team so that everyone can learn.  After awhile, if someone is still struggling (perhaps they’re often late to the meeting or aren’t sufficiently focused) you may want to coach them privately.
  3. Call it a coordination meeting.  Terms such as “stand up meeting” or “Scrum meeting” aren’t very clear, but “coordination meeting” is.  By using clear terminology you make your expectations regarding the purpose of the meeting crystal clear, thereby reducing the chance for confusion.
  4. Set some rules.  As a team, discuss what how you intend to run these meetings.  Potential rules you should consider adopting include:
  • Arrive on time.  ‘Nuff said.
  • One person talks at a time.  There shouldn’t be side conversations going on, not only is that disrespectful it results in those people being distracted from coordinating with the rest of the team.
  • Come prepared.  As a meeting participant you need to know how you’re going to answer each question before you get into the meeting.
  • Define what you want to discuss.  There are many different questions or issues that you can discuss in coordination meetings.  Scrum suggests “What did you do yesterday?”, “What will you do today?”, and “What’s blocking you?”.  Other questions could be “What did you learn today?”, “What will potentially block you?”, “What value did you deliver since the last meeting?” and many others. 
  • Someone different leads each day.  A common strategy is to rotate the responsibility of running coordination meetings between team members.  This is a great learning experience for some people and certainly helps everyone to recognize how these meetings could be run more effectively.
  • Stay focused.  The goal is to coordinate as a team, and the easiest way to do so is for everyone to focus on that goal.  So stay off your phone, don’t be reading email, don’t be holding side conversations, and only focus on the issues/questions you’ve agreed to as a team.
  • Stand at first.  Having people stand up tends to keep meetings short but can prove to be artificial (I’ve been on coordination calls where people working from home or other locations have been asked to stand, yikes). 
  • Coordinate around a task board.  When you gather around a task board much of the status information that you may want to communicate to the meeting is provided by the task board itself.  This provides opportunity to streamline your meeting process.

Here’s a few interesting videos that I found on YouTube:

  1. How to Hold a Daily Standup. This short video provides several good tips for holding a standard “Scrum meeting”.  It suggests that people answer the three standard Scrum questions so take that advice with a grain of salt.  And the background music is a bit cheesy although fun.
  2. Agile Simulation Part 20: The Daily Standup.  This video is interesting because it starts with a dysfunctional version of the meeting and then shows an effective one.  The common mistakes the video shows include running it like a status meeting instead of a coordination meeting; people coming to the meeting unprepared; discussing inappropriate issues during the meeting; showing up late to the meeting; having side conversations; one person was basically checked out and was lying down on a bean bag chair; and a non-team member started driving the conversation at one point.
  3. How a Lean Thinking Company Runs a Morning Meeting. This video overviews the approach taken by an organization’s leadership team to their morning meeting.  They look at their task board, a whiteboard with stickies.  They’ve tailored their meeting to reflect the needs of what they need to coordinate, and in the video they discuss how they came to putting this meeting together.  It’s interesting to note that they are in multiple locations, so they video conference daily.
  4. Lean, the Morning Meeting at Fastcap. This is another non-software development example.  This team explicitly changes the leader of the morning meeting each day to help them grow their skills.  One of the things I like about this video is that their focus is to share critical information with each other.  This includes mistakes, learnings, and any improvements that they made.  The overriding goal is to focus on learning, team building, and to celebrate their successes.
  5. Dodgy Scrum StandUp. This video was purposely put together to show many of the bad habits that people may exhibit during daily stand ups.  These bad habits included not staying on topic; getting into details that most people don’t need to hear; and asking questions around implementation details instead of taking the discussion offline.  One person even threw something at another person, thereby distracting the group.  Another person showed up late, disrupting the discussion.  The team also didn’t refer to their task board (I assume that it was the task board behind people on the left hand side of the screen).

 

 

 

 

 

 

 

 

 

 

 



Categories: People, Practices

Improve Retrospectives with Process Goals

March 6, 2014 1 comment

Retrospectives are a great way for teams to explore potential improvements to the way that they work.  A team will get together, discuss what is working well for them, what is not working so well, and hopefully identify ways that they could improve.  It’s this last activity that can be challenging.  You may know that your team is facing a problem but you might not understand your options.  For example, perhaps your team is struggling with the way that it is being funded.  The current funding mechanism is to estimate the cost up front and then allocate these funds to your team.  This motivates your team to be wary of changing requirements due to the fear of going over budget, something that decreases your ability to produce a solution that meets the true needs of your stakeholders.  You have suggested to management several times that a time and materials (T&M) approach would be more appropriate, but you have gotten nowhere with that conversation.  

This is where DAD’s process goal-driven approach can help out.  In this case the goal Secure Funding provides some insight.  The process goal diagram, see below, along with the supporting descriptions of each technique, their advantages and disadvantages, and advice for when the technique is applicable can help your team to understand their options and hopefully argue for a better funding strategy.  Although a T&M approach might not be palatable to your financial team right now, perhaps they would be willing to consider a stage gate approach to funding.  Or, perhaps they would be open to a T&M approach but they just don’t understand the tradeoffs between T&M and fixed cost.  With DAD’s goal-driven approach the team can arm itself with the arguments that it needs to have a knowledgeable conversation with the actual decision makers.

Goal  Inception  Secure Funding

Of course this is just one example.  The DAD framework addresses a range of goals pertinent to successful agile solution delivery, all of which can provide team’s insight into potential process improvement options.  Knowing your options is an easy way to up your game during retrospectives. 

Categories: Goal-Driven

Does your team own its process or merely rent it?

March 3, 2014 9 comments

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.

Move Closer to a Deployable Release

February 22, 2014 1 comment

One of the process goals that a disciplined agile team will want to address during construction is Move Closer to a Deployable Release.  Ideally, in each construction iteration a team will move closer to having a version of their solution that provides sufficient functionality to its stakeholders.  This implies that the solution is a minimally viable product (MVP) that adds greater business value than its cost to develop and deploy.  Realistically it isn’t a perfect world and sometimes a team will run into a bit of trouble resulting in an iteration where they may not have moved closer to something deployable but hopefully they’ve at least learned from their experiences.

Move closer to a deployable release is an important process goal for several reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution).  This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy.  Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.

The process goal diagram Move Closer to a Deployable Release 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.

Goal - Construction - Move Closer to Deployable Release

Let’s consider each process factor:

  • Deployment Strategy.  Deployment can be a struggle for teams new to agile.  Many teams will start by aiming to deploy their solution into production more regularly, perhaps every few months instead of every six to twelve months.  Then they will start deploying working builds internally at the end of each iteration, perhaps into demo or testing environments.  Finally they will hopefully evolve into a continuous deployment (CD) strategy.
  • Asset Management.  The issue here is how your team will manage the various artifacts, including code, which they use and create while building a solution.  Sadly we’ve found that some teams still struggle with basic configuration management control.  Although they may have their source code under fairly sophisticated control other artifacts such as supporting documentation often aren’t.
  • Documentation Strategy.  Supporting documentation, such as user guides and system overviews, are part of the overall solution that the team is working on.  The DAD framework leverages strategies from Agile Modeling to address this process factor.  Your team may choose to leave such documentation to the end of the lifecycle or to write documentation throughout the lifecycle.
  • Deployment Planning.  There are several techniques that you may want to consider for deployment planning, an important aspect of your overall DevOps strategy.  Although some teams may begin such planning with their operations/release engineers late in the lifecycle, many will instead plan throughout the lifecycle.  The DAD framework recognizes operations staff as key stakeholders, people whom you will actively work with to plan and then deploy your solution.
  • Validation.  DAD captures the fact that there are many ways that you can choose to validate your work, including a range of agile quality techniques (TDD, CI, ATDD/BDD) and even a few that are not-so-agile (end-of-lifecycle testing, manual testing, parallel independent testing).  The DAD framework purposely includes these not-so-agile strategies because in some situations, particularly at scale, they may in fact be your best options.  Furthermore, your team may be in the early stages of becoming agile and as a result then not-so-agile strategies may be the best they are currently capable of doing.
  • Verification.  DAD also recommends that you consider verification strategies to help increase the quality of your work. These strategies include reviews, non-solo development strategies such as pair programming and modeling with others (which are effectively continuous reviews), and including code analysis tools in your CI strategy.

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

We’re firm believers 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 DAD process decision framework provides this guidance.

Identifying your Initial Technical Strategy

February 10, 2014 4 comments

When a disciplined agile project or product team starts, one of the process goals which they will likely need to address is Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. This is an important process goal for several reasons. First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into construction.  A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle.  Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources, that they can potentially leverage while producing the new solution desired by their stakeholders.  By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse.  You will do this by working with your organization’s enterprise architects, if you have any.  This is an aspect of DAD’s philosophy of working in an enterprise aware manner.

The process goal diagram for Identify Initial Technical Strategy 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.

Goal - Inception - Identify Initial Technical Strategy

Let’s consider each process factor:

  • Level of detail.  How much effort should you put into capturing your architectural strategy, if any at all.  A small co-located team may find that a high-level overview captured using whiteboard sketches is sufficient.  A team that is geographically distributed across several locations will find that it needs to at least take digital snapshots of the sketches and share them (perhaps via a wiki) or even capture the diagrams using a drawing tool such as Visio or OmniGraffle.  They may also find that they need to define the details of the interfaces to major components and services, a strategy often referred to as design by contract.  A team in a life-critical regulatory environment may choose to capture more details, even to the point of doing big design up front (BDUF).
  • View types.  Solution/application architectures are typically explored via several views, and there are architectural modeling frameworks such as TOGAF, Zachman Framework (ZF), and Kruchten’s 4+1 approach that focus on defining potential views.  The DAD framework calls out several common views, including Technical, user interface (UI), and Business and suggests that your team address the views that are applicable to the situation you find yourself in. Technical aspects of your architecture may be captured via free form, layered architecture diagrams, network diagrams, or UML deployment diagrams.  You may explore the user interface architecture via a UI flow diagram or wireframe model.  Business or domain aspects may be explored via conceptual domain models or high-level process models.
  • Modeling strategy.  How will your team go about formulating their architecture?  Will they hold informal modeling sessions in an agile modeling space or formal modeling sessions Joint Application Design (JAD) strategy?  Or both?  Will they identify a single technical strategy or several options which they will hope to explore and eventually choose from (or combine ideas from)?
  • Delivery strategy.  Will the team be building a solution from scratch?  Will they be evolving an existing solution?  Will they be evolving a purchased, commercial off the shelf (COTS) package?  Combinations thereof?

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

We’re firm believers 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 DAD process decision framework provides this guidance.

Successful Agile Software Development Requires a Hybrid Approach

February 5, 2014 3 comments

Hybrid

Disciplined Agile Delivery (DAD) is a hybrid framework that builds upon the solid foundation of other methods and software process frameworks.  The DAD framework adopts practices and strategies from existing sources and provides advice for when and how to apply them together.  In one sense methods such as Scrum, Extreme Programming (XP), Kanban, and Agile Modeling (AM) provide the process bricks and DAD the mortar to fit the bricks together effectively.

The DAD framework adopts strategies from the following sources:

  • Scrum.  The Scrum method focuses on team leadership and requirements change management during the construction portion of the delivery lifecycle.  Scrum captures some really great ideas that have become commonly adopted by agile teams.
  • Extreme Programming (XP). XP is an agile method that focuses primarily on construction-oriented practices such as continuous integration (CI), test-driven development (TDD), pair programming, sustainable pace, small releases, simple design, and many others.  Although XP’s practices appear straightforward on the surface, many of them require significant technical skill and discipline on the part of practitioners.
  • Lean software development.  Practitioners of agile development are increasing looking to adapt ideas from lean thinking.  Lean software development is based on seven principles: Eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in, and see the whole.
  • Kanban.  Kanban is a method for managing knowledge work with an emphasis on just-in-time delivery while not overloading the team members. In this approach, the process, from definition of a task to its delivery to the customer, is visualized and team members pull work from a queue or work item pool.
  • Unified Process (UP).  The UP is an iterative and incremental process framework for software development.  Although often instantiated as a heavy-weight approach, it has in fact been instantiated in a very light weight and agile manner, particularly in the form of Agile Unified Process (AUP) or OpenUP.  The DAD framework adopts and enhances several critical governance strategies from the UP.
  • Agile Modeling (AM).  AM is a practice-based methodology for effective modeling and documentation of software-based system. AM was purposely architected to be a source of strategies which can be tailored into other base processes, something the DAD framework takes explicit advantage of.   AM strategies adopted by DAD include initial requirements and architecture envisioning, just in time (JIT) model storming, continuous documentation, and several others.
  • Agile Data.  The Agile Data (AD) method defines a collection of strategies that IT professionals can apply in a wide variety of situations to work together effectively on the data aspects of software systems. Practices for evolutionary/agile database development include database refactoring, database regression testing, agile data modeling, and continuous database integration.
  • Enterprise methods. DAD is starting to adopt strategies from enterprise IT methods such as Scaled Agile Framework (SAFe) and Enterprise Unified Process (EUP).  These strategies address enterprise architecture, product management, portfolio management, operations and support, release management and other important IT disciplines. These strategies reflect the DAD philosophy of enterprise awareness.
  • Other methods.  DAD adopts techniques and practices from other methods such as Dynamic System Development Method (DSDM), Feature Driven Development (FDD), Evo, Outside-In Development (OID), and Crystal Clear.
  • Agile development practices.  There are many practices that are not specific to agile methods that have been developed within the agile community, and DAD leverages many of them.

One of the great advantages of agile and lean software development is the wealth of practices, techniques, and strategies available to you.  This is also one of its greatest challenges because without something like the DAD framework it’s difficult to know what to choose and how to fit them together.

Categories: DAD discussions, Hybrid, RUP, Scrum
Follow

Get every new post delivered to your Inbox.

Join 480 other followers