Agility@Scale: Strategies for Scaling Agile Software Development

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.

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.

1. You adopt "standard" agile discipline.   Aspects of agile which require discipline include adopting practices such as test-driven development (TDD), active stakeholder participation, working collaboratively, shortening the feedback cycle, and many more.  These strategies are a great start to becoming disciplined IT professionals. 
2. You take a goal-driven approach.  When we first started working on the DAD framework I didn't want to create yet another prescriptive framework, particularly given Rational's track record with the Rational Unified Process (RUP) framework.  Rational has been pilloried for years for the prescriptive nature of RUP, which is unfortunate because there are a lot of great ideas in RUP that agile teams can benefit from, some of which we adopted in DAD and many of which are being actively reinvented with the agile community even as you read this. Furthermore, there are many prescriptive elements of the Scrum method that can get teams in trouble.  For example, Scrum prescribes that you hold a daily stand up meeting, often called a Scrum meeting, where everyone should answer three questions.  That's a great approach for teams new to agile, but it proves problematic in many situations due to it's prescriptive nature. Do you really need to do this once a day?  I've been on teams where we held coordination meetings twice a day and others only once a week.  Do you really need to stand up?  I've been on geographically distrubited agile teams where many of us were sitting down during coordination calls.  Do you really need to answer three questions, two of which are clearly focused on status regardless of claims otherwise?  I've been on lean teams where we met around our Kanban board and focused on potential blockers.  The answers to these questions depends on the context of the situation you find yourself in.  The challenge, at least from the point of view of a process framework, is how do you avoid falling into the trap of being overly prescriptive.  The strategy we adopted in DAD is to take a goal-driven approach.  The observation is that regardless of the situation you find yourself in there are common goals your team will need to fulfill.  For example, at the beginning of a project common goals include developing an initial plan, initially exploring the scope, initially identifying a technical strategy, and securing initial funding (amongst others).  Throughout construction you should coordinate your activities, improve the quality of your ecosystem, and produce a potentially consumable solution on a regular basis (more on this below).  So, instead of prescribing a daily stand up meeting the DAD framework instead indicates you should coordinate your activities, and gives several options for doing so (one of which is a Scrum meeting).  More importantly DAD describes the advantages and disadvantages of your options so that you can make the choice that's best suited for the situation your team finds itself in (see this blog posting for a detailed example of the types of tables included in the DAD book to help you through such process tailoring decisions).  In short, our experience is that it requires discipline to take a goal driven approach to agile delivery over the prescriptive strategies in other agile processes. 
3. You take a context-driven approach.  There are many tailoring factors, which I describe in the Software Development Context Framework (SDCF), which you need to consider when making process, tooling, and team structure decisions.  For example, a large team will adopt a different collection of practices and tools than a small team.  A geographically distributed team will adopt a different strategy than a team that is co-located.  You get the idea.  Other tailoring factors include compliance, team culture, organization culture, technical complexity, domain complexity, and project type.  It requires discipline to recognize the context of the situation you find yourself in and then act accordingly.
4. You deliver potentially consumable solutions.  One of the observations that we made early in the development of the DAD framework was that disciplined agile teams produce potentially consumable solutions, not just potentially shippable software.  Although delivery of high-quality, working software is important it is even more important that we deliver high-quality working solutions to our stakeholders. For example, not only are we writing software but we may also be updating the hardware on which it runs, writing supporting documentation, evolving the business processes around the usage of the system, and even evolving the organizational structure of the people working with the system.  In other words, disciplined agilists focus on solutions over software.  Furthermore, "potentially shippable" isn't sufficient: not only should it be shippable but it should also be usable and should be something people want to use.  In other words it should be consumable (a concept DAD adopted from IBM's Outside In Development).  Minimally IT professionals should have the skills and desire to produce good software, but what they really need are the skills and desire to provide good solutions. We need strong technical skills, but we also need strong "soft skills" such as user interface design and process design to name just two. The incremental delivery of potentially consumable solutions on an incremental basis requires discipline to do successfully.  DAD teams focus on repeatable results not repeatable processes.
5. You are enterprise aware.   Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you will need to act accordingly. It takes discipline to work with enterprise professionals such as enterprise architects, data admistrators, portfolio managers, or IT governance people who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a DevOps manner throughout the lifecycle, particularly when they may not be motivated to do so.  It requires discipline to accept and potentially enhance existing corporate development conventions (programming guidelines, data guidelines, UI guidelines, ...).  It requires discipline to accept that your organization has an existing technology roadmap that you should be leveraging, building out, and in some cases improving as you go.  In short, enterprise awareness requires a level of discipline not typically seen on many agile teams.
6. You adopt a full delivery lifecycle.  Empirically it is very easy to observe that at the beginning of an agile project there are some activities that you need to perform to initiate the project.  Similarly at the end of the project there are activities that you need to perform to release the solution into production or the marketplace.  The DAD process framework addresses the effort required for the full delivery effort, including project initiation, construction, and deployment.  Our experience is that it requires discipline on the part of IT professionals to include explicit phases for Inception/Initation, Construction, and Transition/Deployment and more importantly to focus the appropriate amount of effort on each.  One danger of explicit phases is that you run the risk of taking what's known as a Water-Scrum-Fall approach, a term coined by Dave West the person who wrote the forward for the DAD book, where you take an overly heavy/traditional approach to inception and transition in combination with a lighter agile approach to construction.  Water-Scrum-Fall occurs because many organizations haven't made a full transition to agile, often because they think it's only applicable to construction.  Our experience is that you can be very agile in your approach to inception and transition, experience we've built into the DAD framework.  Having said that it clearly requires discipline to keep inception activities short and similarly it requires discipline to reduce the "transition phase" to an activity. 
7. You adopt a wider range of roles.  An interesting side effect of adopting a full delivery lifecycle is that you also need to adopt a more robust set of roles.  For example, the Scrum method suggests three roles - Scrum Master, Product Owner, and Team Member - a reflection of the Scrum lifecycle's construction focus.  DAD suggests three primary roles - Team Lead, Product Owner, Team Member, Architecture Owner, and Stakeholder - as well as five secondary roles which may appear at scale.   
8. You embrace agile governance.  Governance establishes chains of responsibil­ity, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department.  It requires discipline to adopt an agile approach to governance, and that's something built right into the DAD framework.

1. Initial requirements envisioning.  Disciplined agile teams invest time at the beginning of the project to identify the high-level scope in a light-weight, collaborative manner.  This includes common operations requirements such as the need to backup and restore data sources, to instrument the solution so that it can be monitored in real time by operations staff, or to architect the solution in a modular manner to enable easier deployment. 
2. Initial architecture envisioning. Disciplined agile teams will also identify a viable architectural strategy which reflects the requirements of their stakeholders and your organization’s overall architectural strategy (hence the need to work closely with your enterprise architects and operations staff).  One goal is to ensure that the team is building (or buying) a solution which will work well with the existing operational infrastructure and to begin negotiating any infrastructural changes (such as deploying new technologies) early in the project.   Another goal is to ensure that operations-oriented requirements are addressed by the architecture from the very start. 
3. Initial release planning.  As part of release planning the disciplined agile team works closely with their operations group to identify potential release windows to aim for, any release blackout periods to avoid, and the need for operations-oriented milestone reviews later in the lifecycle (if appropriate).
4. Active stakeholder participation.  Disciplined agile teams work closely with their stakeholders, including both operations and support staff, all the way through the lifecycle to ensure that their evolving needs are understood.   
5. Continuous integration (CI).  This is a common technical agile practice where the solution is built/compiled, regression tested, and maybe even run through code analysis tools.  CI promotes greater quality which in turn enables easier releases into production.  
6. Parallel independent testing. For enterprise-class development or at scale, particularly when the domain or technology is very complex or in regulatory environments, disciplined agile team will find they need to support their whole team testing efforts with an independent test team running in parallel to the development team.  These testing issues often include validation of non-functional requirements – such as security, performance, and availability concerns – and around production system integration.  All of these issues are of clear importance for operations departments.   
7. Continuous deployment.  With this practice you automate the promotion of your working solution between environments.  By automating as much of the deployment effort as possible, and by running it often, the development team increases the chance of a successful deployment and thereby reduces the risk to the operations environment. Note that deployment into production is generally not automatic, as this is an important decision to be made by your operations/release manager(s). 
8. Continuous documentation.  With this practice supporting documentation, including operations and support documentation, is evolved throughout the lifecycle in concert with the development of new functionality. 
9. Production release planning.  This is the subset of your release planning efforts which focuses on the activities required to deploy into production. 
10. Production readiness reviews.  There should be at least one review, performed by the person(s) responsible for your operations environment, before the solution is deployed into production.  The more critical the system, the more product readiness reviews may be required. 
11. End-of-lifecycle testing.  Minimally you will need to run your full automated regression test suite against your baselined code once construction ends.  There may also be manual acceptance reviews or testing to be performed, and any appropriate fixing and retesting required to ensure that the solution is truly ready for production. 

•  People are assigned to a single team
•  Development teams have easy access to business expertise
• Development teams are organized for agile delivery (not traditional)
• Your organization has an agile support group/community of excellence
• Your organization is explicitly addressing barriers to agility
• There is executive sponsorship for agile
• Agile teams are measured on value creation
• Your organization's IT governance strategy includes an agile path
  

• What are the challenges typically faced by Disciplined Agile Development teams as they begin to transition their working solutions into production?
• How best could this gap between Development and Operations be closed so that they worked collaboratively rather than in silos?
  
• If this DevOps gap was decreased or even closed, what would the measurable value be to Agile projects and their business stakeholders?

• Context counts - The Agile Scaling Model
• People first - People, and the way they interact with each other, are the primary determinant of success for a solution delivery project.
• Learning-oriented - The DAD process framework promotes the ideas that team members should collaborate closely and learn from each other, that the team should invest effort to learn from their experiences and evolve their approach, and that individuals should do so as well.
• Hybrid - DAD adopts and tailors strategies from Scrum, XP, Agile Modeling, UP, Kanban, and many others. It addresses many of the issues Mark Kennaley discusses in SDLC 3.0.
  
• IT solution focused - DAD teams produce potentially consumable solutions every construction iteration.  This extends Scrum's "potentially shippable" strategy to explicitly address usability/consumability plus the fact that we're really delivering full solutions not just software.
• Goal-driven delivery life cycle - The DAD lifecycle is focused on delivery, not just construction.  Furthermore it is goals-driven, the DAD process framework suggests various strategies to fulfill those goals but does not prescribe specific practices.
  
• Risk and value driven - The DAD lifecycle is risk and value driven.  It extends Scrum's value-driven lifecycle which produces potentially shippable software each sprint/iteration so that it explicitly includes light-weight milesstones such as ensuring stakeholder consensus as to the scope of the project early in the lifecycle, proving the architecture with working code early in the lifecycle, ensuring sufficient functionality exists before transition, and ensuring production readiness before actual release of the solution.
  
• Enterprise aware - The DAD process framework promotes the ideas that DAD teams should work closely with their enterprise architecture groups to ensure they leverage and evolve the existing infrastructure, adopt and follow corporate guidelines, and work to the overall organizational vision.  DAD teams are self organizing with appropriate governance.

• The history of agile
• Some of the challenges surrounding traditional development
• Some of the basics of agile, such as increased collaboration with stakeholders and on delivery of consumable solutions
• The benefits of agile, including increased quality, time to value, stakeholder satisfaction, and ROI
• Domains where agile is being applied successfully
• What IBM agility@scale is all about
• How some of the scaling factors change the way that you'll work and approach tooling
  
• Rational Team Concert (RTC), what it is and why you'd be interested in it
• Benefits that customers are seeing with RTC
• How you can download a fully-functional version of RTC for a team of up to 10, with no time limit, free of charge

1. Day. A typical day begins with a short coordination meeting, called a Scrum meeting in the Scrum method. After the daily coordination meeting the team collaborates throughout most of the day to perform their work. The day concludes with a working build, hopefully you had several working builds throughout the day, which depending on your situation may require a bit of stabilization work to achieve.
2. Iteration. DAD construction iterations begin with an iteration planning session (coordinate) where the team identifies a detailed task list of what needs to be done that iteration. Note that iteration modeling is often part of this effort. Throughout the iteration they collaborate to perform the implementation work. They conclude the iteration by producing a potentially consumable solution, a demo of that solution to key stakeholders, and a retrospective to identify potential improvements in the way that they work.
3. Release. The DAD lifecycle calls out three explicit phases - Inception, Construction, and Transition – which map directly to coordinate, collaborate, and conclude respectfully.

• Coordinate maps to plan
• Collaborate maps to do
• Conclude maps to check and act

There is a fair bit of rhetoric surrounding agile methods, some of which we subscribe to and some of which we don’t. We’d like to briefly examine the rhetoric which we’ve found to be the most misleading for people trying to be effective at adopting agile techniques. The following list is in the format X but Y, where X is the rhetoric and Y is the strategy promoted by the Disciplined Agile Delivery (DAD) process framework. This includes:

1. Requirements evolve throughout the lifecycle BUT the scope should still be agreed to at the beginning of the project. There has to be an initial vision for a project, a vision which your stakeholders should help define and then agree to, and to come to that vision you will need to perform some initial requirements envisioning. A list of high level features is part of this initial vision. Yes, the details are very likely to evolve over time but the fundamental goals of your project and scope of your effort needs to be defined early in your project. In a very small minority of situations you may not be able to get the right people together, either physically or virtually, to define the initial vision – this should be seen as a significant project risk.
2. Simple designs are best BUT the architecture should be thought out early in the lifecycle. Too many developers interpret the advice to focus on simple designs to mean that they should build everything from scratch. Yet more often than not the simplest design is to take advantage of what is already there, and the best way to do that is to work closely with people who understand your existing technical infrastructure. Investing in a little bit of architectural envisioning early in the lifecycle enables your team to identify existing enterprise assets that you can leverage, to identify your architectural options, and to select what appears to be the best option available to you. The details will still emerge over time, and some decisions will be deferred until a later date when it’s more appropriate to make them, but the bottom line is that disciplined agilists think before they act.
3. Teams should be self organizing BUT they are still constrained (and enhanced) by your organizational ecosystem. Intellectual workers, including IT professionals, are most effective when they have a say in what work they do and how they do it. IT professionals can improve their productivity by following common conventions, leveraging and building out a common “dev-ops” infrastructure, building towards a common vision, and by working to common business and technical visions.  In short, disciplined agile professionals are "enterprise aware".
4. Delivery teams don’t need prescriptive process definitions BUT they do need some high-level guidance to help organize their work. Individual IT professionals are typically highly-skilled and highly-educated people often with years of experience, and teams of such people clearly have a wide range of knowledge. As a result of this knowledge it is incredibly rare for such people to read detailed procedures for how to do their work. However, they often still require some high-level advice to help them to organize their work effectively. Teams can often benefit from techniques and patterns used by other teams and this knowledge sharing should be encouraged.
5. IT professionals know what to do BUT they’re still not process experts. A decade ago the strategy was to provide detailed process advice to teams, but recently the pendulum has swung the other way to provide little or no defined process at all. Over the last few years there’s been a trend within the agile community to advise teams to define their own process so that it’s tailored to their own unique situation. While this clearly strokes people’s egos, it’s relatively poor advice for several reasons. First, although every team is in a unique situation there is significant commonality so having at least a high-level process framework from which to start makes sense. Second, although these teams have a wide range of knowledge it might not be complete, nor consistent, nor is it clear what the trade-offs are of combining all the really good techniques that people know about. There is significant benefit in having a flexible process framework such as DAD which shows how everything fits together.
6. IT professionals should validate their own work to the best of their ability BUT they likely aren’t testing experts so therefore need help picking up the appropriate skills. The mantra in the agile community is to test often and test early, and better yet to test first. As a result agile teams have adopted a “whole team” approach where the development team does its own testing. This works when there are people on the team with sufficient testing skills and more importantly can transfer those skills to others. Minimally you will need to embed testers into your delivery teams, but you should also consider explicit training and mentoring of everyone on the team in testing and quality skills.  You may find my agile testing and quality strategies article to be an interesting read.
7. Disciplined agile teams work in an iterative manner BUT still follow a lifecycle which is serial over time. On any given day people on a DAD project team may be performing analysis, testing, design, programming, deployment, or a myriad of other activities and iterating back and forth between them. But, the DAD lifecycle includes three distinct phases which are performed in order. So, DAD is both iterative in the small but serial in the large.

IBM Rational recently published an update to my Agility@Scale e-book, which can be downloaded free of charge.  The e-book is a 21 page, 2.3 meg PDF (sorry about the size, guess the graphics did it) .   It overviews the Agile Scaling Model (ASM) (which has since been replaced by the Software Development Context Framework (SDCF) ), Disciplined Agile Delivery (DAD), the scaling factors of agility at scale, and ends with some advice for becoming as agile as you can be.  In short it's a light-weight coverage of some of the things I've been writing about in this blog the past couple of years.  Could be a good thing to share with the decision makers in your organization if they're considering adoption agile strategies.

• Pre-production system integration testing.  Does the solution work within your overall organizational ecosystem?  Importantly, if this is one of several teams currently developing new solutions, does this team's solution work with what will be in production (including the work in progress of other teams) when they go to release?  In mid-to-large organizations the only economical way to do this sort of testing is via an independent, centralized team.
• Usability testing.  Although it's possible to do usability testing on the development team, the reality is that usability testing is a specialized skill that few people have (although could pick up via non-solo development).  Furthermore, particularly for solutions with many potential users, you may want to invest in a usability testing lab.  This is a centralized resource, or an outsourced resource these days, which is shared across many teams.
• Security testing.  Security testing is also a specialized skill, albeit one well supported with sophisticated security testing tools such as the Rational Appscan suite which can be included in your continuous integration (CI) strategy.  Many organizations will centralize their security testing efforts.
• Exploratory testing.  The fundamental goal of exploratory testing is to discover where the solution breaks, as opposed to confirmatory testing which focuses on showing that the solution conforms to the requirements (this is the type of testing the development team typically focuses on).  Exploratory testing is also a skill, a good one which everyone should strive to pick up, but exploratory testers are often few in number in many organizations.  So, to leverage their skills effectively you may want to have some of them on the independent test team while they mentor others while doing so.
• Non-functional testing. Non-functional requirements have a tendency to fall through the cracks on some development teams.  Knowing this the independent test team will often "test to the risk" and focus on non-functional issues.
• And much more.  The above points are just exemplars, not an exact list.  Please follow some of the links above for greater detail.

1. The developers still do the majority of the testing.  Just because there's an independent test team it doesn't imply that they are the ones doing all the testing.  In fact, nothing could be further from the truth.  They should be doing the minority of the testing effort, albeit the more difficult forms of it.
2. An independent test team will support multiple dev teams.  For example, a test team of 5-6 people could support several development teams totalling 70 to 80 people.  I typically look for a 15:1 or 20:1 ratio of developers to independent testers, hopefully even higher than that.
3. You need to consider better tooling.  Although the development team will still be using common agile testing tools such as the xUnit and FIT frameworks the independent test team (ITT) will need more sophisticated tooling.  First, the ITT will need to be able to report defects back to the team easily.  When the development team is using a Jazz-based tool such as Rational Team Concert (RTC) then this can easily be done using either RTC (the web interface may be sufficient) or another Jazz-enabled product such as Rational Quality Manager (RQM).  Second, the ITT will likely need more sophisticated testing tools, such as Rational Appscan for static and dynamic security testing and Rational Performance Tester (RPT) for performance testing (just two of several software quality management tools you should consider).
4. Independent testing is economical. Although I listed several tools in my previous point (hey, I do work for a vendor after all) an "unfortunate" implication of my advice (unfortunate for IBM at least) is that you can reduce the number of licenses that you require and still get this critical testing done by centralizing their use.
5. It may be a bit more complicated in regulatory environments.  In a strict regulatory environment the independent test team may need to repeat, or at least validate, the testing efforts of the development team.  In regulatory environments my fundamental advice is always this -- Have practical people, including yourself, read and interpret the regulations.  If you leave it to the bureaucrats you'll get a bureaucratic solution.
6. This is an important scaling technique.  Parallel independent testing, when done in an agile manner, is an important technique which you should consider when scaling agile strategies to meet the uniques needs of the situation that you find yourself in. 

One of the scaling factors called out in the Software Development Context Framework (SDCF) is domain complexity.  The general idea is that agile teams will find themselves in different situations where some teams are developing fairly straightforward solutions, such as an informational website, whereas others are addressing very complex domains, such as building an air-traffic control system (ATCS).  Clearly the team building an ATCS will work in a more sophisticated manner than the one building an informational website.  I don't know whether agile techniques have been applied in the development of an ATCS, although I have to think that agile's greater focus on quality and working collaboratively with stakeholders would be very attractive to ATCS delivery teams, I do know that agile is being applied in other complex environments: The 2009 Agility at Scale Survey found that 18% of respondents indicated that their organizations had success at what they perceived to be very complex problem domains,.

Increased domain complexity may affect your strategy in the following ways:

1. Reaching initial stakeholder consensus becomes difficult.  One of the risk reduction techniques called out in Disciplined Agile Delivery (DAD) is to come to (sufficient) stakeholder consensus at the beginning of the project during the Inception phase (called Sprint 0 in Scrum or Iteration 0 in other agile methods).  Stakeholder consensus, or perhaps "near concensus" or "reasonable agreement" are better terms, can be difficult to come to the more complex the problem domain is because the stakeholders may not fully understand the implications of what they're making decisions about and because there is likely a greater range of stakeholders with differing goals and opinions.  The implication is that your project initiation efforts may stretch out, increasing the chance that you'll fall back on the old habits of big requirements up front (BRUF) and incur the costs and risks associated with doing so. 
2. Increased prototyping during inception.   It is very common for disciplined agile teams to do some light-weight requirements envisioning during inception to identify the scope of what they're doing and to help come to stakeholder consensus.  The greater the complexity of the domain, and particularly the less your team understands about the domain, the more likely it is that you'll benefit from doing some user interface (UI) prototyping to explore the requirements.  UI prototyping is an important requirements exploration technique regardless of paradigm, and it is something that you should consider doing during both initial requirements envisioning as well as throughout the lifecycle to explore detailed issues on a just in time (JIT) manner.
3. Holding "all-hands reviews".    One strategy for getting feedback from a wide range of people is to hold an "all hands review" where you invite a large group of people who aren't working on a regular basis with your team to review your work to date.  This should be done occasionally throughout the project to validate that the input that you're getting from your stakeholder represenatives/product owners truly reflects the needs of the stakeholders which they represent.  The 2010 How Agile Are You? Survey found that 42% of "agile teams" reported running such reviews.
4. Increased requirements exploration.  Simple modeling techniques work for simple domains.  Complex domains call for more complex strategies for exploring requirements.  The implication is that you may want to move to usage scenarios or use cases from the simpler format of user stories to capture critical nuances more effectively.  A common misunderstanding about agile is that you have to take a "user story driven approach" to development.  This is an effective strategy in many situations, but it isn't a requirement for being agile.
5. The use of simulation.  You may want to take your prototyping efforts one step further and simulate the solution.  This can be done via concrete, functional prototypes, via simulation software, via play acting, or other strategies.
6. Addition of agile business analysts to the team.  Analysis is so important to agile teams we do it every day.  In situations where the domain is complex, or at least portions of the domain is complex, it can make sense to have someone who specializes in exploring the domain so as to increase the chance that your team gets it right.  This is what an agile business analyst can do.  There are a few caveats.  First, even though the domain is complex you should still keep your agile analysis efforts as light, collaborative, and evolutionary as possible.  Second, this isn't a reason to organize your team as a collection of specialists and thereby increase overall risk to your project.  The agile analyst may be brought on because their specialized skills are required, but the majority of the people on the team should still strive to be generalizing specialists.  This is also true of the agile analyst because their may not be eight hours a day of valuable business analysis work on the team, and you don't want the BA filling in their time with needless busy work.

The important thing is to recognize that the strategies which work well when you're dealing with a simple domain will not work well for a complex domain.  Conversely, techniques oriented towards exploring complex domains will often be overkill for simple domains.  Process and tooling flexiblity is key to your success.

There are several potential technical complexities which a Disciplined Agile Delivery (DAD) team may face:

1. New technology platforms.  Your team may choose to work with a technology platform which is either new to the team or sometimes even new to the industry.  In the past few years new technology platforms include the Android operating system, Apple’s iPad platform, and various cloud computing (http://www.ibm.com/ibm/cloud/) platforms.  Working with these platforms may require you to adopt new development tools and techniques, not to mention the need to train and mentor your staff in their usage.  Furthermore, your team may need to allocate time for architectural spikes to explore how to use the new technology and to prove the overall architecture with working code early in the project lifecycle (this is a DAD milestone).   
2. Multiple technology platforms.  IT solutions often run on multiple platforms.  For example, a system’s user interface (UI) could run in a browser, access business logic implemented using J2EE on Websphere which in turn invokes web services implemented in COBOL running on a Z-series mainframe, and stores data in an Oracle database, a DB2 database, and in several XML files.  Implementing new business functionality, or updating existing functionality, could require changes made on several of these platforms in parallel.  The implication is that you’ll need to adopt tools and strategies which enable your team to develop, test, and deploy functionality on all of these platforms.  Testing and debugging in particular will become more difficult as the number of technology platforms increases, potentially requiring you to adopt the practice of parallel independent testing.  The Agility at Scale survey found that 34% of respondents indicated that their agile teams were working with multiple technology platforms.
   
3. Legacy data.  IT solutions should leverage existing, legacy data wherever possible to reduce the number of data sources and thereby increase data quality within your organization.  Also, using existing data sources can potentially speed up development, assuming your team has a good relationship with the owners of the legacy data sources (sadly, this often isn’t the case as the Data Management Survey found).  Working with legacy data sources may require improved database regression testing, practices, database refactoring practices, and agile approaches to data administration. The Agility at Scale survey found that 42% of respondents indicated that their agile teams were working with legacy data sources (personally, I’m shocked that this figure is so low, and fear that many agile teams are contributing to data quality problems within their organization as a result).
   
4. Legacy systems.  There are several potential challenges with legacy systems.  First, the code quality may not be the best either because it was never really that good to begin with or because it’s degraded over the years as multiple people worked with it.  You know you’ve got a quality problem if you’re either afraid to update the code or if when you do so you have to spend a lot of time debugging and then fixing problems revealed when doing the update.  If the legacy system is a true asset for your organization you will want to pay off some of this technical debt by refactoring the code to make it of higher quality.  Second, you may not have a full regression test suite in place, making it difficult to find problems when you do update the code let alone when you refactor it.  Third, your development tools for your legacy code may be a bit behind the times.  For example, I often run across mainframe COBOL developers still working with basic code editors instead of modern IDEs such as Rational Developer for System Z.   Some of the strategies to deal effectively with legacy systems are to adopt a modern development toolset if you haven’t already done so (better yet, if possible adopt a common IDE across platforms and thereby reduce overall licensing and support costs) and to adopt agile practices such as static code analysis, dynamic software analysis, and continuous integration (CI).  The Agile Project Initiation Survey found that 57% of respondents were integrating their new code with legacy systems and 51% were evolving legacy systems.
5. Commercial off-the-shelf (COTS) solutions.  COTS solutions, also called package applications, can add in a few complexities for agile teams.  The packages rarely come with regression test suites, they often have rules about what you can modify and what you shouldn’t (rules that are ignored at your peril), and they’re often architected with the assumption that they’re the center of the architectural universe (which is a valid assumption if they’re the only major system within your organization).  As I describe in my article Agile Package Implementations it is possible to take an agile approach to COTS implementations, although it may require a significant paradigm shift for the people involved. The Agility at Scale survey found that 15% of respondents indicated that their agile teams were working with COTS solutions.  
6. System/embedded solutions.  For the sake of simplicity, if your team is developing a solution with both hardware and software aspects to it then you’re a systems project.  Embedded systems are a specialization where the system has a few dedicated functions often with real-time constraints.  Bottom line is that systems/embedded projects are typically more challenging than software-only projects – it gets really interesting when laws of physics starts to kick in, such as when you’re building satellites or space probes.  I highly suggest Bruce Douglass’s book Real-Time Agility if you are interested in taking an agile approach to systems/embedded solution delivery.
   

I'm happy to announce that A Practical Guide to Distributed Scrum by Elizabeth Woodward, Steffan Surdek, and Matthew Ganis is now in print.  I've been talking this book up in presentations and with customers the past few months and promised that I would let everyone know once it was available.  I was one of several people who wrote forewords for the book, Ken Schwaber, Roman Pichler, and Matthew Wang also did so, and I've modified my foreword below to help you to understand a bit better what the book is about.

If you’re thinking about buying this book, you’re probably trying to answer one or more of the following questions: “What will I learn?”, “Should I spend my hard earned money on this book?”, “Will it be worth my valuable time to read it?”, and “Is this a book that I’ll refer to again and again?” To help you answer these questions, I thought I’d list a few user stories which I believe this book clearly fulfills:
As a reader I want:

• a book that is well-written and understandable real-world examples that I can relate to
• quotes from actual people doing this in the field
• to understand the challenges that I’ll face with distributed agile development

As someone new to agile I want to:

• learn the fundamentals of Scrum
• understand the fundamentals of agile delivery
• learn about what actually works in practice
• discover how extend Scrum into an agile delivery process

As an experienced agile practitioner I want to learn:

• how to scale agile approaches for distributed teams
• how to overcome the challenges faced by distributed teams
• how to tailor existing agile practices to reflect the realities of distribution
• bout “new” agile practices which we might need to adopt
• techniques so that distributed team members can communicate effectively
• how to extend Scrum with proven techniques from Extreme Programming, Agile Modeling, and other agile methods
• how to address architectural issues on a distributed agile team
• how agile teams address documentation
• how agile teams can interact effectively with non-agile teams

As a Scrum Master I want to learn how to:

• lead a distributed agile team
• facilitate a distributed “Scrum of Scrums”
• facilitate the successful initiation of a distributed agile project
• facilitate communication and collaboration between distributed team members

As a Product Owner I want to learn:

• how to manage a product backlog on a distributed team
• about different categories of stakeholders whom I will need to represent
• about techniques to understand and capture the goals of those stakeholders
• how to manage requirements with other product owners on other sub-teams
• what to do during an end-of-sprint review
• how I can streamline things for the delivery team that I’m working with

As an agile skeptic I want to:

• see examples of how agile works in practice
• hear about the challenges faced by agile teams
• hear about where agile strategies don’t work well and what to do about it

I work with organizations around the world helping them to scale agile strategies to meet their real-world needs. Although this book is focused on providing strategies for dealing with geographical distribution, it also covers many of the issues that you’ll run into with large teams, complex problem domains and complex technical domains. An important aspect of scaling agile techniques is to first recognize that’s there’s more to scalability than dealing with large teams, something which this book clearly demonstrates.

At the risk of sounding a bit corny, I’ve eagerly awaited the publication of this book for some time. I’ve known two of the authors, Elizabeth and Matt, for several years and have had the pleasure of working with them and learning from them as a result. Along with hundreds of other IBMers I watched this book get written and provided input where I could.  The reason why I’m so excited about it is that I’ve wanted something that I could refer the customers to that I work with and honestly say, “yes, we know that this works because this is what we do in practice”.

IBM is doing some very interesting work when it comes to scaling agile. We haven’t published enough externally, in my opinion, due to a preference for actively sharing our experiences internally. This book collects many of our experiences into a coherent whole and more importantly shares them outside the IBM process ecosystem. Bottom line is that I think that you’ll get a lot out of this book.

Related Reading:

• Software Development Context Framework
• Geographically Distributed Agile Teams

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 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 governance strategy 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.

1. Lean provides an explanation for why many of the agile practices work.  For example, Agile Modeling’s practices of light weight, initial requirements envisioning followed by iteration modeling and just-in-time (JIT) model storming work because they reflect deferment of commitment regarding what needs to be built until it’s actually needed, and the practices help eliminate waste because you’re only modeling what needs to be built.
2. Lean offers insight into strategies for improving your software process.  For example, by understanding the source of waste in IT you can begin to identify it and then eliminate it. 
3. Lean principles provide a philosophical foundation for scaling agile approaches.   
4. It provides techniques for identifying waste.  Value stream mapping, a technique common within the lean community whereby you model a process and then identify how much time is spent on value-added work versus wait time, helps calculate overall time efficiency of what you’re doing.  Value stream maps are a straightforward way to illuminate your IT processes, providing insight into where significant problems exist.  I’ve created value stream maps with several customers around the world where we analyzed their existing processes which some of their more traditional staff believed worked well only to discover they had efficiency ratings of 20-30%.  You can’t fix problems which you are blind to.

One of the scaling factors called out in the Software Development Context Framework is “geographic distribution".   As with the other scaling factors the level of geographic distribution is a range, with co-located teams at one extreme and far-located at the other.  When your team is co-located the developers and the primary stakeholders are all situated in the same work room.  If you have some team members in cubicles or in separate offices then you're slightly distributed, if you're working on different floors in the same building you're a bit more distributed, if you're working in different buildings within the same geographic area (perhaps your team is spread across different office buildings in the same city or some people work from home some days) then your team is more distributed, if people are working in different cities in the same country you're more distributed, and finally if people are working in different cities around the globe you're even more distributed (I call this far located).

As your team becomes more distributed your project risk increases for several reasons:

1. Communication challenges.  The most effective means of communication between two people is face-to-face around a shared sketching space such as a whiteboard, and that requires you to be in the same room together.  As you become more distributed you begin to rely on less effective communication strategies.
2. Temporal challenges.  When people are in different time zones it becomes harder to find common working times, increasing the communication challenges.  One potential benefit, however, is the opportunity to do "follow-the-sun" development where a team does some work during their workday, hands off the work to another team in a significantly different time zone, who picks up the work and continues with it.  This strategy of course requires a high degree of sophistication and discipline on the part of everyone involved, but offers the potential to reduce overall calendar time.
3. Cultural challenges.  As the team becomes more distributed the cultural challenges between sites typically increases.  Different cultures have different work ethics, treat intellectual property differently, have different ideas about commitment, have different holidays, different approaches to things, and so on.

As you would imagine, because the project risk increases the more distributed your team is, the lower the average success rates of agile projects decrease as they become more distributed.  The 2008 IT Project Success Survey found that co-located agile teams has an average success rate of 79%, that near located teams (members were in same geographic area) had a success rate of 73%, and that far-located agile teams had a success rate of 55%.  The success rate decreases similarly for project teams following other paradigms.

The practices that you adopt, and the way that you tailor the agile practices which you follow, will vary based on the level of geographic distribution of your team.  For example, a co-located team will likely do initial architecture envisioning on a whiteboard and keep it at a fairly high-level.  A far-located team will hopefully choose to fly in key team members at the beginning of the project, at least the architecture owners on the various sub-teams, to do the architecture envisioning together.  They will likely go into greater detail because they will want to identify, to the best of their ability, the interfaces of the various subsystems or components which they'll be building.  

Interestingly, the Agility at Scale 2009 survey found that it was quite common for agile teams to be geographically distributed in some manner:

• 45% of respondents indicated that some of their agile teams were co-located
• 60% of respondents indicated that some of their agile teams had team members spread out through the same building
• 30% of respondents indicated that some of their agile teams were working from home
• 21% of respondents indicated that some of their agile teams had people working in different offices in the same city
• 47% of respondents indicated that some of their agile teams had team members that were far located

The bottom line is that some organizations, including IBM, have been very successful applying agile techniques on geographically distributed teams. In fact, agile GDD is far more common than mainstream agile discussion seem to let on. 

Recommended Resources:

• A Practical Guide to Distributed Scrum
• Software Development Context Framework
• Geographically Distributed Agile Teams

1. Business driven.  Minimally your EA effort should be driven by your business, not by your IT department.  Better yet it should be business owned, although this can be a challenge in many organizations because business executives usually aren't well versed in EA and view it as an IT function.  Yes, IT is clearly an important part of EA but it's not the entirety of EA nor is it the most critical part.  In many organizations the IT department initiates EA programs, typically because the business doesn't know to do so, but they should quickly find a way to educate the business in the need to own your organization's EA efforts.
   
2. Evolutionary. Your enterprise architecture should evolve over time, being developed iteratively and introduced incrementally over time.  An evolutionary approach enables you act on the concrete feedback that you receive when you try to actually implement it, thereby enabling you to steer its development successfully.
   
3. Collaborative. The EA survey clearly pointed to "people issues" being critical determinants of success, and of failure, of EA programs.  My experience is that the best enterprise architects, just like the best application architects, work closely with the intended audience of their work, both on the business side of things as well as on the IT side.  They will "roll up their sleeves" and become active members of development teams, often in the role of Architecture Owner on agile teams or Architect on more traditional teams.  Their mission is to ensure that the development teams that they work with leverage the EA, to mentor developers in architecture skills, and to identify what works and what doesn't in practice so that they can evolve the EA accordingly.  Enterprise architects, architects in general, who don't participate actively on development teams (holding architecture reviews isn't active participation) run the risk of being thought of as "ivory tower" and thus easy to ignore.
   
4. Focused on producing valuable artifacts.  The most valuable artifacts are useful to the intended audience, are light weight, and ideally are executable.  Many EA programs run aground when the enterprise architects focus on artifacts that they've always wanted but that development teams really aren't very excited about -- yes, it might be interesting to have a comprehensive comparison of cloud technologies versus mainframe technologies, but a collection of reusable services would be fare more interesting to them.  A detailed enterprise data model indicating suggested data attributes would be intellectually interesting to develop, but a list of legacy data sources with a high-level description of their contents would be immediately valuable to many development teams.  A detailed model depicting desired web services would be useful, but an actual collection of working services that I can reuse now would be even better.
   
5. An explicit part of development.  In Disciplined Agile Delivery (DAD) architectural activities are an explicit part of the overall delivery process.  Part of the architectural advice is that delivery teams should work closely with their organization's enterprise architects so that they can leverage the common infrastructure, and sometimes to help build it out, effectively.  Disciplined agile teams realize that they can benefit greatly by doing so. 
   

• Agile Architecture: Strategies for Scaling Agile
• Agile Enterprise Architecture
• The Architecture Owner Role: How Architects Fit in on Agile Teams
• Enterprise Architecture: Reality over Rhetoric
• Enterprise Architecture Survey Results