DAD in Brussels, June 19-21

Mark will be delivering the 3-day Disciplined Agile Delivery Experience workshop in Brussels on June 19 through 21.  There are still spots available for the workshop, so sign up here.  This workshop is a great opportunity to learn the fundamentals of DAD.

The workshop is not technical and is suitable for all team members. Many group exercises reinforce the principles learned. The workshop is also valuable for management tasked with moving from traditional approaches to agile.

Elizabeth Woodword on DAD

Elizabeth Woodward, co-author of one of my favorite books on scaling agile, A Practical Guide to Distributed Scrum, recently posted a video on Youtube entitled Disciplined Agile Delivery – The Shirt, the Summary .  I worked with Elizabeth at IBM when she led IBM’s internal agile educational support effort and actively worked with teams to help them to adopt and tailor disciplined agile strategies.  As you can read in her own book, she has deep expertise in successfully applying agile at scale.

In the video, which I had no idea that she was going to create, she shares her thoughts about why you should consider DAD.  She describes the value of the explicit inclusion of Inception activities, extending Scrum to describe a truly hybrid approach, and the explicit inclusion of transition activities.  The video is a little less than six minutes in length and I suspect you’ll find it a good use of your time.

As the title implies, she also has a few nice things to say about the “fabulous” DAD shirt we sent her.  Luckily, due to training from my wife, The Lovely Beverley, I knew enough to order a woman’s version for her.  Context counts! 

What Happens When People Don’t Agree?

I was recently asked the question “What happens when the Product Owner and the Architecture Owner don’t agree?” and realized this is an issue for everyone on DAD teams in general.  Here’s my advice:

1. Talk it out.  People aren’t always going to agree, and that can often be a very good thing.  So talk it out amongst yourselves and explore why you don’t agree on an issue.  Very often someone else has a different point of view that you weren’t aware of, hence the need for a discussion.
2. Recognize that people have certain rights and responsibilities.  One of the reasons why DAD defines rights and responsibilities for various roles, which we adapted from source methods such as Scrum and Agile Modeling, is to help distinguish the decision rights of people in those roles.  For example Product Owners have the right to prioritize the work but do not have the right to dictate technical decisions.  Similarly, the Architecture Owner is responsible for guiding the team through technical decisions but does not have the right to set work priority.  An implication is that although the AO might not agree with some of the prioritization decisions being made by the PO they still need to respect those decisions.
3. Talk it out.  It’s better to talk an issue through and communicate the reasons behind a decision than to simply dictate it.

Call For Papers: Disciplined Agile Delivery for the Enterprise – Cutter IT Journal June 2013

Call for Papers: Cutter IT Journal
Guest Editor: Scott Ambler
Abstract deadline: 1 April 2013
Article deadline: 3 May 2013

Disciplined Agile Delivery in the Enterprise

Recently there have been rumblings within the industry along the lines of “what’s next after agile?” and “what does the post-agile landscape look like?” These rumblings reflect the challenges organizations face when adopting agile within an enterprise environment. Although popular, Scrum only provides a small kernel upon which to build an agile strategy, leaving you with the heavy lifting of tailoring an end-to-end agile strategy that reflects the realities of your environment. Worse yet, the simplistic strategies promoted by agile purists sow seeds of confusion and doubt amongst people still struggling to adopt an agile mindset. Beliefs that agile requires small co-located teams, downplays architecture, delivers no documentation, doesn’t work in regulatory situations, doesn’t support governance, are common. Yet those beliefs don’t reflect reality — disciplined agile teams are in fact succeeding in these situations.

Organizations that are successful at adopting and applying agile techniques effectively are going beyond Scrum and Extreme Programming (XP), and adopting a truly disciplined approach. This approach is captured in the Disciplined Agile Delivery (DAD) process decision framework. The framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven and enterprise aware, and provides a foundation from which to scale agile. DAD adopts strategies from Scrum, XP, Agile Modeling, Agile Data, Kanban, DevOps, and many more, providing advice on how to apply these techniques together in an effective manner which reflects the situation faced by the team — one process size does not fit all.

An upcoming issue of Cutter IT Journal will address the benefits, challenges and implications of adopting and applying disciplined agile strategies for enterprise software delivery.

Topics may include (but are not limited to the following) with regard to adopting a disciplined agile approach:

• How can a DAD project be successfully initiated?
• What challenges might an enterprise face in applying a DAD approach?
• What does a full agile delivery lifecycle look like in practice?
• What does it mean to apply a “hybrid agile” approach? e.g. think beyond the “Scrum+XP” box.
• In what situations would DAD not be the optimal approach to software/IT solution delivery?
• How do “enterprise aware” teams work with enterprise architects, reuse engineers, portfolio managers, and other enterprise professionals in practice?
• What cultural roadblocks might hinder the use of DAD and how can they be overcome?
• How are architecture issues addressed on a DAD project?
• How does the role of Product Owner change for large and complex agile projects?
• What roles and team structures are you actually implementing on DAD teams? Do you have business analysts, architects/architecture owners, independent testers? When do you need, or not need, such roles?
• How are you applying disciplined agile strategies to large teams/programmes?
• How are you applying disciplined agile strategies to geographically distributed teams?
• How are you applying disciplined agile strategies in regulatory compliance situations; in CMMI environments; in outsourcing/offshoring situations?

TO SUBMIT AN ARTICLE IDEA
Please respond to Scott Ambler, sambler[at]cutter[dot]com, with a copy to itjournal[at]cutter[dot]com, no later than 1 April 2013 and include an extended abstract and a short article outline showing major discussion points.

ARTICLE DEADLINE
Accepted articles are due by 1 May 2013.

EDITORIAL GUIDELINES
Most Cutter IT Journal articles are approximately 2,500-3,000 words long, plus whatever graphics are appropriate. If you have any other questions, please do not hesitate to contact CITJ’s Group Publisher, Christine Generali at cgenerali[at]cutter[dot]com or the Guest Editor, Scott Ambler, at sambler[at]cutter[dot]com. Editorial guidelines are available online

COPYRIGHT
When you submit an article to Cutter Consortium, you warrant that you (or your employer) are the sole owner of the article and that you have full power and authority to copyright it and publish it. Also, the article you submit to Cutter must be an original; not previously published elsewhere.  Articles published in the journal must meet certain criteria relating to audience, technical content, and presentation. In the unlikely occurrence that, upon selection and editorial review, your completed article does not meet with these requirements, Cutter Consortium reserves the right to decline the publishing of your article in the journal.  For more information on Cutter’s copyright policy.
AUDIENCE
Typical readers of CITJ range from CIOs and vice presidents of software organizations to IT managers, directors, project leaders, and very senior technical staff. Most work in fairly large organizations: Fortune 500 IT shops, large computer vendors, and government agencies. 48% of our readership is outside of the US (15% from Canada, 14% Europe, 5% Australia/NZ, 14% elsewhere). Please avoid introductory-level, tutorial coverage of a topic. Assume you’re writing for someone  who has been in the industry for 10 to 20 years, is very busy, and very impatient.  Assume he or she will be asking, “What’s the point? What do I do with this information?” Apply the “So what?” test to everything you write.

PROMOTIONAL OPPORTUNITIES
We are pleased to offer Journal authors a year’s complimentary subscription and five copies of the issue in which they are published. In addition, we occasionally pull excerpts, along with the author’s bio, to include in our bi-weekly Cutter Edge e-mail bulletin, which reaches another 8,000 readers. We’d also be pleased to quote you, or passages from your article, in Cutter press releases. If you plan to be speaking at industry conferences, we can arrange to make copies of your article or the entire issue available for attendees of those speaking engagements — furthering your own promotional efforts.

ABOUT CUTTER IT JOURNAL
No other journal brings together so many cutting-edge thinkers, and lets them speak so bluntly and frankly. We strive to maintain the Journal’s reputation as the “Harvard Business Review of IT.” Our goal is to present well-grounded opinion (based on real, accountable experiences), research, and animated debate about each topic the Journal explores.

Scaling Agile: The Software Development Context Framework

The Software Development Context Framework (SDCF) defines how to select and tailor a situation-dependent strategy for software development.  The SDCF is used to provide context for organizing your people, process, and tools for a software-based solution delivery team.   Figure 1 below depicts how several selection factors drive the choice and tailoring of your team organization (people), delivery process,  and tooling configuration.  Of course initial selection is just the first step, you will also need to tailor these choices to reflect the situation that you face – hence the scaling factors.

Figure 1. Strategy selection and tailoring.

Selecting A Base Strategy for People, Process, and Tools

When you begin a project you need to identify who will be on the team, how they will work together, and what tools they’re going to use.  These decisions will be driven by factors such as the skill and culture of the people who will potentially be on the team, your organizational culture and policies, the nature of the problem being addressed, and business constraints such as time to market and budget.  Different situations will warrant different solutions to these three factors.

When it comes to team organization you have several issues to consider.  Will the team be composed mostly of specialists such as business analysts, developers, testers, designers and so on or will team members be more along the lines of T-skilled generalizing specialists?   How large will the team need to be?  Where will you find these people?   Will they be located in the same place or spread out?  Will they work for a single organization or several?  The choices you make will be driven by the situation that you face.

Similarly you have several process-related issues to consider?  What paradigm is most appropriate?  For example will you take an agile approach?  A lean approach?  A traditional approach?  An iterative approach?  A hybrid of two or more?  Will your team be able to follow a light, goal-driven process or a prescriptive one?  Will your process be constrained by compliance to frameworks such as CMMI or ISO standards?

When it comes to tooling there is a myriad of options and it seems as if everyone has an opinion as to which tools are best.  However, my experience is that there are several key issues to consider when choosing tools.  Will you adopt open source tools, commercial tools, or a combination thereof?  Will your tools be integrated or stand alone?  Do you prefer to obtain tools from a single source whenever possible, with the potential for better integration and support, or will you strive for best of breed tools regardless of vendor?  Will you host your own tool environment or will it be hosted externally via a SAAS-style approach?  If hosted externally, where will your intellectual property (IP), such as source code, be hosted?

Figure 2 summarizes five selection factors that I recommend you consider when making these people, process, and tool decisions:

1. Team skills.  The people on a team must have the skills, or must gain the skills, that befit the role they play on that team.  For example, developers on an agile team may need to have test-driven-development (TDD) skills, people-oriented collaboration/communication skills, continuous integration (CI) skills, model storming skills, team-based planning skills, and so on.  Developers on traditional teams may be more focused on programming skills for a specific technology platform.
2. Team culture.  People who are collaborative and team-focused in nature are better suited for agile/lean environments whereas people who like to work alone are better suited for traditional approaches. Similarly people who are open and flexible in their approach are better suited for agile or lean strategies.
3. Organizational culture.  Your organization’s culture may vary from that of the team you are putting together, something that is particularly true when you are first learning about new ways of working.  An organizational culture that is very flexible and collaborative will mean that it is easier to take an agile or lean approach, wherease a more rigid, command-and-control culture will make it difficult to do so.
4. Nature of the problem.  Although some people want to believe that some types of problem can only be solved in one manner that doesn’t seem to be the case in practice.  For example, it’s possible to take an agile or a traditional approach, to data warehousing projects, to web site projects, to mainframe-based projects, and even to embedded software development.  My experience is that the real issue is how decomposable the potential solution is.  For example, it’s possible to decompose a data warehouse into many small releases if you choose.  Same thing can be said of a web site as well as the other types of projects listed earlier.  But, it isn’t very easy to decompose an airplane into several working parts.  Either airplane is complete or it isn’t.  Yes, it’s still possible to apply agile techniques to such a project but the team will never be truly agile, just as agile as it can be given the constraints of the problem.
5. Business constraints.  The way that the business constrains the endeavor, such as insisting on a certain (always agressive) delivery date, an approach to managing the budget (often a fixed price/bid), and how available business people will be throughout the project certainly has an affect on the process you adopt and the type of people that you include on the team.  It may even influence what tools you use.

Figure 2. Selection factors.

In a future blog posting I will take you through how to apply these selection factors in greater detail.

Scaling Your Strategy for People, Process, and Tools

Figure 3 summarizes the six scaling factors, indicating the range of each factor.  On the left-hand side is the simple extreme and on the right-hand side the challenging extreme.  In my various IT surveys over the years I have found evidence that organizations are applying agile at all levels of scale, most recently in the 2012 Agility at Scale survey.

Figure 3. Scaling factors.

Let’s examine each scaling factor one at a time:

1. Team size.  Teams can range in size from two people to twenty to two hundred or more.  Larger teams are typically formed to address more complex problems, and as a result large teams take on the challenges of greater domain complexity and/or greater technical complexity as described below.  Team size tends to directly affect how you organize the team and how you coordinate within the team.  For example, a team of 200 will be organized into subteams and a leadership team will be required for coordination (we described this in detail in Chapter 5 of the DAD book).  A team of 50 will also be organized into subteams, although coordination will likely be simpler and possibly handled by a daily coordination meeting of representatives from each subteam (a techniques referred to as  a Scrum of Scrums).  It is fairly straightforward to coordinate the activities of a team of 10 people.
2. Geographic distribution.  Agile teams may be co-located, with the team members and key stakeholders in the same room, they may be on the same floor in a single building, on multiple floors, some may work in different buildings, some may work from home, and some may even work in different countries.  A popular misconception is that agile teams need to be co-located, a misconception that I have shown via several surveys over the years to be false.  Granted, it’s a very good idea to get people working as closely as possible, but it doesn’t happen as often as we’d like.  Similar to large teams, coordination of team members throughout the project become more difficult and as a result more sophisticated coordination is required.  A greater investment in initial modeling and planning, but not much more, is required during Inception to mitigate the communication risks associated with distribution.  To increase chance of project success you will need to fly people around at key points in the project, something many organizations are loathe to do because it’s easy to measure travel costs but difficult to quantify the benefit of face-to-face collaboration.
3. Organizational distribution.  This refers to the concept of involving people from several organizations on the project.  The easiest situation to be in is to have all of your team members from the same group/division within a single organization.  It’s a little harder when people from several groups are involved.  Hiring contractors adds to the complexity.  Outsourcing a portion of the work to an external service provider is harder yet.  Outsourcing to several vendors harder yet.  Outsourcing to one or more service providers with a very different culture than your own harder yet.  Organizationally distributed projects tend to take on the challenges associated with large teams and geographically distributed teams.  When outsourcing is involved they take on the risks associated with procurement and then the governance of the outsourced effort.
4. Compliance.  There are two forms of compliance.  Generally the simpler form of compliance is self-imposed, perhaps your organization chooses to be CMMI or ISO compliant.  The second, and potentially harder, form of compliance is regulatory compliances.  A team may need to conform to financial regulations, privacy regulations, or even life-critical regulations.  Although every regulation has different requirements, from a process point of view they typically require extra documentation (but keep it light), reviews (keep them streamlined), and sometimes a documented process (we suggest DAD).
5. Domain complexity.  The complexity of the domain, or the problem space, being tackled by a team can vary widely.  An informational website site, such as this one, is fairly straightforward.  An e-commerce site is more difficult.  An air traffic control system even more difficult.  The greater the domain complexity that you face the more you want to invest in up-front modeling and planning.  Not much more, mind you, but still more.  Similarly as domain complexity rises it motivates greater sophistication in your agile testing strategy.  As domain complexity increases it puts a greater burden on your Product Owner, requiring more sophsticated agile modeling skills and potentially the support of agile business analysts.
6. Technical complexity.  Disicplined agile teams will face varying levels of technical complexity.  On the simple end of the spectrum you’ll have the development of a brand-new, stand-alone application built with new technologies.  Things get more difficult if you need to take advantage of existing services or data sources.  Things get more difficult if you need to support several technology platforms.  Things get more difficult if you need to implement using several languages.  Things are more difficult yet if you need to refactor existing infrastructure (including legacy data sources).  As with domain complexity, the greater the technical complexity the greater the need for a bit more up-front modeling and more sophisticated testing throughout the lifecycle.  Greater techncial complexity puts a burden on your Architecture Owner, requiring great agile architecture and agile design skills of them.

In future postings I will explore the selection process and the implications of each scaling factor in greater detail.

Some Background

Where do these ideas come from?  The primary source is something called the Agile Scaling Model (ASM) which I led the development of while working for IBM.  In parallel to my work on the ASM Philippe Kruchten was working on something he calls “situational agility”, the heart of which was eight (8) factors often referred to as the “Octopus model”.  In the Autumn of 2012 I began thinking about how to combine and evolve these two frameworks into one, something I originally called the Process Context Framework (PCF).  I moved away from that name because the framework was clearly applicable to more than just software process, hence adopted the name Software Development Context Framework (SDCF) which is inclusive of people, process, and tools.

Disciplined Agile Certification Launches Today

The Disciplined Agile Consortium is proud to announce the launch of our certification programme for practitioners of Disciplined Agile Delivery (DAD).  DAC is offering three practitioner certifications:

1. Disciplined Agile Yellow Belt. This beginner certification indicates to colleagues and employers that you are eager to learn Disciplined Agile Delivery (DAD) strategies that enable you to increase your skills and abilities as a software professional.
2. Disciplined Agile Green Belt. This intermediate certification indicates that you are experienced at DAD and are on your way to becoming a generalizing specialist. You have the potential to be a “junior coach” under the guidance of a senior coach (someone who is likely a Disciplined Agile Black Belt).
3. Disciplined Agile Black Belt. This expert certification indicates that you are a trusted expert with significant proficiency at DAD. You can coach other people in disciplined agile strategies and advise organizations in the adoption and tailoring of the DAD framework.

When we developed this certification programme it was driven by six principles:

1. Certifications must provide value. First and foremost, a certification must provide value to the person being certified. This value comes from learning new and valuable strategies during the process of earning the certification as well as greater employability resulting from the certification. Of course there are always limits to the value of any certification.
2. Certifications must be earned. The effort required to earn the certification must be commensurate with the value provided. For example, it is easy to earn a Disciplined Agile Yellow Belt because the yellow belt is an indication that someone has basic knowledge of Disciplined Agile Delivery (DAD) and wishes to learn more. A Disciplined Agile Green Belt is harder to earn because it is an indication of both knowledge and experience. A Disciplined Agile Black Belt is very difficult to earn because it’s an indication of expertise and competence.
3. Certifications must be respectable. We believe that the Disciplined Agile certifications are respectable for several reasons. First, the fact that you have to do some work to earn them is a welcome difference from other agile certifications. Second, we’re aligning with other respectable certification programmes and are requesting participation in one or more of those programmes as part of Green and Black belt certification.
4. Certifications must be focused. The focus of this programme is on disciplined agile approaches to IT solution delivery. Disciplined agile certifications are an indication of knowledge and experience in disciplined agile methods.
5. Certification is part of your learning process. Disciplined professionals view certification as part of their learning process. Certification, and learning in general, is not an event but instead an ongoing effort. The implication is that once you have earned your certification you must continue working to keep your skills up to date.
6. Certified professionals have a responsibility to share knowledge. Not only have we adopted the concept of earning belts from martial arts we have also adopted the mindset that people have a responsibility to help teach and nurture people with lower belts to learn new skills and knowledge. The act of teaching and sharing information often leads one to a greater understanding and appreciation of the topic, and thus helps the teacher as well as the student to learn.

Differentiate yourself in the marketplace. Certification in Disciplined Agile Delivery (DAD) means something to clients and employers because it needs to be earned. Certification in DAD tells the marketplace you understand how to deliver an agile solution from end-to-end with experience in enterprise-class development.

Scaling Agile: Start With a Disciplined Foundation

One of the claims that we make in the Disciplined Agile Delivery (DAD) book is that DAD provides a solid foundation from which to scale agile.  In this blog posting I thought I would expand upon that idea.

Figure 1 overviews the basic strategy that I led the development of when I was with IBM Rational.  The fundamental observation was that many organizations were struggling with how to scale agile methods, in particular Scrum.  We felt that the first step was to identify how to successfully develop a solution from end-to-end.  Although mainstream agile methods clearly provided a lot of great strategies, there really wasn’t any sort of glue beyond consultantware (e.g. hire me and I’ll show you how to do it) putting it all together.  This is where the DAD framework comes in, but that’s only a start as you also need to tailor your approach to reflect the context in which you find yourself.

Figure 1: DAD provides a foundation for agility at scale.

First, let’s examine how the DAD framework provides a better foundation for scaling agile:

1. Risk and value driven lifecycle.  Scrum has what is called a value driven lifecycle.  Work is prioritized by value to the business and is performed in priority order.  This is a pretty good approach, but it’s possible to do better.  Disciplined agile teams recognize that it’s a pretty good idea to tackle the riskier work early in an endeavor in order to help eliminate some or all of the risk.  Some people like to refer to this as an aspect of “failing fast” although we like to put it in terms of  succeeding early.  A risk-value approach to work prioritization, and better yet explicit risk-based milestones (such as reaching stakeholder agreement early and proving the architecture with working code early), can increase your chance of project success.
2. Self organization with effective governance.  There has been much ado made over the strategy of self organizing teams with the agile community and rightfully so as it is an effective strategy.  But, agile project teams don’t work in a vacuum but instead work within the scope and constraints of a larger, organizational ecosystem.   Instead of optimizing the project part as many agile methods imply that you should do in DAD we recommend that you adopt an effective governance strategy that guides and enables agile teams.
3. Delivery of consumable solutions over construction of working software.  There are two issues here, a delivery focus over a construction focus and a solution focus over a software focus.  First, disciplined agile teams recognize that there is some up-front project initiation/inception work that occurs early in a project.   DAD also recognizes that there is often some deployment/transition effort that occurs towards the end of a project.  The end result is that DAD promotes the idea that you need to adopt a full delivery lifecycle, not just a construction-focused lifecycle, if you’re to successfully avoid common mistakes such as a Water-Scrum-Fall approach.  Futhermore, because DAD isn’t prescriptive it suggests several versions (agile, lean, continuous delivery) of the lifecycle.  Second, agile teams do far more than produce software.  We create supporting documentation.  The software runs on hardware that may need to be upgraded and/or redeployed.  We potentially change the business process around the usage of the system we’re producing.  We may even affect changes to the organization structure of the people using the system.  In short, it is blatantly obvious that we’re not just producing “potentially shippable software” but instead are producing “potentially shippable solutions”.  Moreover, producing something that is just “potentially shippable” isn’t what our stakeholders actually want.  What they really desire is something that’s consumable, something that they can easily understand and adopt to help them achieve their goals.  The rhetoric “potentially shippable software” plays well to some developers, but it isn’t a sufficient goal.
4. Enterprise awareness over team awareness.  I alluded to this in point #2.  Disciplined agile teams recognize that they work in a larger organizational ecosystem.  This enterprise awareness  motivates them to leverage existing assets; enhance existing assets; work closely with enterprise professionals such as enterprise architects, reuse engineers, portfolio managers, and data adminstrators; and produce solutions that reflect the technology and business roadmaps of your organization.  Done right this increases a team’s ability to deliver.
5. Context-sensitive and goal driven over prescriptive.  One process size does not fit all.  It’s comfortable to think that prescriptive strategies such as managing changing requirements in the form of a product backlog, holding a daily meeting where everyone answers three questions, having a single source of requirements and thereby a neck to wring, and other ideas will get the job done.  But we all know that this isn’t true.  There are many strategies for managing requirements change, there are different ways to coordinate within a team, there are different ways to explore stakeholder needs, and so on.  Each of these strategies has advantages and disadvantages and each has a range of situations where they are appropriate.  A strategy that works for a small co-located team will put a large geographically distributed team at risk.  A strategy that works well in a non-regulatory environment may result in people’s deaths in a regulatory one (or more likely fines because hopefully you’ll be caught before you ship).  So, if you want to build an effective team you need to be able to select the right strategy for the situation you find yourself in.  DAD describes a straightforward, easy to consume strategy that is goal-driven.  This strategy has a visual component, the goals diagrams which summarize the fundamental process decision points, and a textual component (goals tables) which capture the details.

Now let’s examine what it means to scale agile.  When many people hear “scaling” they often think about large teams that may be geographically distributed in some way.  This clearly happens, and people are clearly succeeding at applying agile in these sorts of situations (see some of the more recent evidence I’ve gathered that agile scales, as well as some of the older evidence), but there’s often more to scaling than this.  Organizations are also applying agile in compliance situations, either regulatory compliance that is imposed upon them or self selected compliance (such as CMMI and ISO).  They are also applying agile in a range of problem and solution complexities, and even when multiple organizations are involved (as in outsourcing).  As Figure 1 indicates, there are several scaling factors which you need to consider when tailoring your agile strategy.

So how does DAD provide a foundation from which to scale agile?  When one considers how scaling factors can potentially affect your strategy it becomes a lot clearer.  Consider some examples:

• Geographic distribution.  When a team is geographically distributed they will likely need to to a bit more requirements envisioning up front (but not too much more), a bit more architecture envisioning up front (but not too much more), a bit more release planning up front (but not too much more), and so on.  In other words you clearly need to tailor your inception efforts.  The way the team coordinates will change (your 15 minute stand up meeting becomes one or more conference calls), the way that you coordinate requirements changes (you’re likely to have several product owners that need to negotiate dependencies), and the way that you coordinate architectural issues changes (your architecture owners will need to coordinate somehow).  In short, you need strategies that are a bit more sophisticated than having a discussion standing up around a whiteboard with some sticky notes on it.  By the way, I’ve found in several surveys over the years that the majority of agile teams are geographically distributed in some way.
• Compliance.  A few years ago I worked with an agile team that was working on FDA-compliant software.  Because of the need to be FDA compliant, they were working on a key software component of a life-critical solution, their approach to documentation, reviews, and testing was a bit more sophisticated than what you would find in a non-compliancy situation.  They needed a defined process (an early version of DAD) that met the documentation and quality constraints of FDA regulations.  This meant more documentation than most agile teams would normally create, more formal reviews, the inclusion of an independent test team on top of their whole team testing efforts, and documented proof thereof.  The point is that they were still doing documentation, reviews, and testing (amongst other activities) but doing so in a different way than if they didn’t need to be compliant.
• Technical complexity.   As technical complexity rises the sophistication of the techniques, and sometimes the tooling, needed to deal with that complexity increases.  For example, if you’re building a brand new, stand alone application your team is in a position to write clean code, create a clean UI, and create clean data storage that is fully tested from the outset.  If you’re working with a legacy system the code… may not be so clean.  It may not have a full regression test suite (making continuous integration challenging).  You may need to fix these assets, thereby requiring a more sophisticated approach to refactoring, testing, debugging, and so on than what you’re used to.  Once again, this scaling factor will affect your strategy.

The good news is that there is a growing collection of techniques for scaling agile projects.  This includes Dean Leffingwell’s Scaled Agile Framework (SAFe) as well as the continuing writings of Craig Larman and Bas Vodde.  In future blog postings we’ll discuss the scaling factors in greater detail as well as how DAD and SAFe fit together.

Contextualization of Software Development Workshop

On Saturday, February 9 a group of people got together in Whistler British Columbia to discuss the importance of context as it pertains to software development.  The workshop was organized by the good folk at Software Development Experts (once again, thank you very much).  We shared some very important insights and had some very informative discussions.

The morning began with a kick-off from Carson Holmes.  I gave a talk summarizing the work around context frameworks, including Philippe Kruchten’s Situational Agility and the work I did at IBM around the Agile Scaling Model.  My talk summarized what we’re calling the Process Context Framework (PCF), something I will blog about soon.  Philippe then summarized his recent work on cognitive biases which explains why people, including software professionals, make suboptimal decisions and more importantly how we can avoid doing so.  Mark Kennaley overviewed the theory behind Software Development Practice Advisor and demoed some of its capabilities.  This is a product that I’ve been very interested in for some time as it’s an expert system that supports better process-oriented decisions around software development that is based on true empiricism.  Steve Adolph shared his work around how software development teams collaborate successfully, including empirical observations from is grounded-theory based work for his PHd.  Julian Holmes led us through an exercise around the contextualization of 400 agile/lean practices.  Mark and Carson ended the workshop by leading the group through a discussion of how we can work together effectively.

We had very interesting discussions throughout the day.  Disciplined Agile Delivery (DAD) was discussed at several points throughout the day.  In my presentation I briefly overviewed DAD’s goal-driven approach as I believe it is a perfect example of how to instantiate contextualization of software development.  Mark Kennaley discussed how DAD is supported as a first-class citizen in Advisor in his presentation.  For the handful of people who didn’t yet have the DAD book we gave them copies signed by Mark Lines and myself.

On Sunday many of us hit the slopes at Blackcombe/Whistler.  Below is a picture of several of us at near the top of Whistler.  More of the group went skiing than just the people appearing in the picture.

The Workshop Attendees

Back row:

• Adam Murray (A.R. Murray)
• Carson Holmes (Software Development Experts)
• Steve Adolph

Middle row:

• Sheynal Saujani (Scott Ambler + Associates)
• Doug Stewart (Blueprint)
• Mark Lines (Scott Ambler + Associates)
• Ricardo Garcia (Costco)
• Arun Zachariah (Capgemini)
• Rolf Reitzig (Ascendent Technology)
• Scott Ambler (Scott Ambler + Associates)
• Philippe Kruchten (University of British Columbia)
• Chris Armstrong (Armstrong Process Group)
• Mark Kennaley (Software Development Experts)

Front row:

• Julian Holmes (Agilementors)
• Cecile Peraire (Carnegie Mellon University)
• Geri Schneider-Winters (Wyyzzk)
• Tom Weinberger (Citicorp)
• Hadar Ziv
• Mike Bonar