Modified by ScottAmbler
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.
In November 2011 Paul Gorans, the Accelerated Solution Delivery (ASD) practice lead in IBM GBS, and I ran an agile adoption survey
. The survey explored a range of issue, including the factors that appear to be associated with the success and failure of agile project teams. Paul wrote up his thoughts in his Agile State of the Art Survey
article on ibm.com and I did the same for Dr Dobb's Journal in Agile Success Factors
. This blog posting summarizes the results of the survey.
Factors which appear to accelerate agile adoption include:
- 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
Factors which appear to decelerate agile adoption include:
- Agile teams are measured using traditional metrics
Modified by ScottAmbler
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:
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.
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.
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.
I recently wrote a detailed article about Large Agile Teams that was a detailed walkthrough of how to structure agile teams of various sizes. I suspect that this is the most comprehensive online discussion of this topic. The article addressed the following topics:
Organizing Agile Teams. The article starts with a summary of the results of some industry research that I've done regarding the size of agile teams, showing that agile techniques are in fact being successfully applied on a variety of team sizes. It then goes into detail describing the organization structure of agile teams at various sizes. The article starts with a discussion of small agile teams, covering the common rhetoric of how to organize such a team and then making observations about what actually happens in practice. It then walks through two approaches to organizing medium sized teams of 15 to 50 people - a structure for a single team and a structure for a team of teams. Finally, it walks through how to organize a large agile program of 50+ people, focusing a fair bit on the need for a leadership team to coordinate the overall activities within the program. This advice is similar to what is seen in the SAFe framework although proves to be a bit more flexible and pragmatic in practice.
Supporting Large Agile Teams. The leadership structure to support a large agile team is reasonably straightforward once you understand the issues that such a team faces. In this section the article overviews the need for three important sub teams within your overall leadership team: The Product Delivery Team, The Product Management Team, and The Architecture Team. It also describes the need for an optional Independent Testing/Integration Team, something misleadingly labeled an integration team in SAFe, that reflects some of the known agile testing and quality practices that I've been writing about for several years.
Organizing subteams. The article includes a detailed discussion for how to organize the work addressed by agile sub teams within a large agile program. These strategies include feature teams, component teams, and internal open source teams. As you would expect with the Disciplined Agile Delivery (DAD) framework, the article clearly summarizes the advantages and disadvantages of each approach on provides guidance for when (not) to apply each one. I suspect you'll find this portion of the article to be one of the most coherent discussions of the Feature vs. Component team debate.
Tailoring agile practices. The article provides a detailed overview of how the various DAD process goals are tailored to address the issues faced by large teams. This advice includes: Do a bit more up-front requirements exploration; Do a bit more up-front architectural modelling; Do a bit more initial planning; Adopt more sophisticated coordination activities; Adopt more sophisticated testing strategies; and Integrate regularly. My hope is that you find this part of the article very illuminating regarding how the DAD framework provides flexible and lightweight advice for tailoring your approach to address the context of the situation that you face.
Other Resources. The article ends with a collection of links to other resources on this topic.
I welcome any feedback that you may have about Large Agile Teams.
My new white paper, Disciplined Agile Delivery: An Introduction
, is now available free of charge from IBM.com. The paper overviews the Disciplined Agile Delivery (DAD) process framework, a hybrid comprised of strategies from Scrum, XP, Agile Modeling, and other agile methods which is people first, learning oriented, and enterprise aware. DAD is the basis from which you can scale agile.
- 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.
For some reason, it seems as if everyone's grandfather at one point in time recommended to use the right tools for the job. That's practical wisdom from my point of view, one that is certainly an issue for agile development.
One of the primary messages, I hope, of the Agile Scaling Model (ASM)
is that context counts. Although the focus of the ASM is on describing a contextual framework for tailoring your process to meet the needs of the situation that you find yourself in, it's also applicable to your tooling selection. For example, the tool choices of a co-located team will be much different than that of a geographically distributed team. A co-located team will likely use a whiteboard
or paper for their agile modeling
efforts, whereas distributed team members may need to capture their diagrams using a more sophisticated tool such as Rational Requirements Composer (RRC)
so that their work can be shared electronically. Having said that, RRC would be overkill for a co-located team (unless they had regulatory compliance issues). Different teams, different situations, therefore different tooling choices.
One of the concerns that I run into from customers is that some of our legacy products don't support agile very well. Once again, it's a matter of context because many of our legacy products reflect the realities faced by more traditional teams. The challenge occurs when you try to take a legacy product which is well suited for traditional development, such as Rational ClearCase
, and try to apply it on agile projects. Although ClearCase makes sense in certain scaling situations, particularly very large teams that are geographically distributed, you'd be better advised to use something like Rational Team Concert (RTC)
for configuration management on most agile teams (note that RTC does far more than just SCM).
So, if you're taking an agile approach you should consider Rational tools such as RTC, RRC, Rational BuildForge
, Rational AppScan
, and others which support agile
development. Granted, some you would only use at scale -- for example Buildforge is a good option in really complex environments, but if you don't face that complexity then you'll likely find that RTC's build engine is sufficient. Similarly, if you're taking a traditional approach to development then you'll likely consider products such as ClearCase, Appscan, RTC, and Rational Software Architect (RSA)
instead. Different situations, different tooling choices.
What's even more confusing is that some products support a range of process paradigms. For example, RTC supports agile, lean, iterative, and traditional approaches to development. The same can be said of Appscan and several other products. Notice how I listed RTC and Appscan for both agile and traditional development above.
So, if anyone tells you that Rational tools don't support agile development don't believe them. Ask them which tools that they're talking about, and ask them if they're aware of the Rational products that do support agile development. Context counts.
Modified by ScottAmbler
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.
Modified by ScottAmbler
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:
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.
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.
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.
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.
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.
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.
Timo Tenhunen has recently published his master's thesis, Challenges in Scaling Agile Software Development
, and has been kind enough to make it available online. I suspect you'll find it to be an interesting read.
People who are new to agile are often confused about how agile teams address architecture, but luckily we're seeing more discussion around agile architecture
now in the community so this problem is slowly being addressed from what I can tell. But, what I'm not seeing enough discussion about, at least not yet, is how is enterprise architecture addressed in the overall agile ecosystem. So I thought I'd share some thoughts on the subject, based on both my experiences over the years (see the recommended resources at the bottom of this posting) as well as on an enterprise architecture survey
which I ran in January/February 2010.
My belief is that effective enterprise architecture, particularly in an agile environment, is:
- 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.
- 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.
- 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.
- 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.
- 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.
The Agile Scaling Model (ASM)
calls out addressing enterprise disciplines, such as enterprise architecture, as one of eight scaling factors which may apply to a given project. The interesting thing about this scaling factor is that it's the only one where things get potentially easier for development teams when we move from the simple approach, having a project focus, to the more complex approach, where we have an enterprise focus. By having a common infrastructure to build to, common guidelines to follow, and valuable artifacts to reuse project teams can benefit greatly. So, I guess my advice is to seriously consider adding enterprise disciplines to your agile strategy.Recommended Resources:
My new paper Scaling Agile: An Executive Guide
is now available. As the title suggests the paper overviews how to scale agile strategies to meet your organization's unique needs. The executive summary:
Agile software development is a highly collaborative, quality-focused approach to software and systems delivery, which emphasizes potentially shippable working solutions produced at regular intervals for review and course correction. Built upon the shoulders of iterative development techniques, and standing in stark contrast to traditional serial or sequential software engineering methods, agile software delivery techniques hold such promise that IBM has begun to adopt agile processes throughout its Software Group, an organization with over 25,000 developers. But how can practices originally designed for small teams (10-12) be “scaled up” for significantly larger operations? The answer is what IBM calls “agility@scale.”
There are two primary aspects of scaling agile techniques that you need to consider. First is scaling agile techniques at the project level to address the unique challenges individual project teams face. This is the focus of the Agile Scaling Model (ASM).
Second is scaling your agile strategy across your entire IT department, as appropriate. It is fairly straightforward to apply agile on a handful of projects, but it can be very difficult to evolve your organizational culture and structure to fully adopt the agile way of working.
The Agile Scaling Model (ASM) defines a roadmap for effective adoption and tailoring of agile strategies to meet the unique challenges faced by a software and systems delivery team. Teams must first adopt a disciplined delivery lifecycle
that scales mainstream agile construction techniques to address the full delivery process, from project initiation to deployment into production. Then teams must determine which agile scaling factors
– team size, geographical distribution, regulatory compliance, domain complexity, organizational distribution, technical complexity, organizational complexity, or enterprise discipline, if any — are applicable to a project team and then tailor their adopted strategies accordingly to address their specific range of complexities.
When scaling agile strategies across your entire IT organization you must effectively address five strategic categories — the Five Ps of IT
: People, principles, practices, process, and products (i.e., technology and tooling). Depending on your organizational environment the level of focus on each area will vary. What we are finding within many organizations, including IBM, is that the primary gating factor for scaling agile across your entire organization is your organization’s ability to absorb change.
When you are first adopting agile techniques in your organization a common strategy is to run one or more pilot projects. When organizing these projects you typically do as much as you can to make them successful, such as finding:
- Projects where the stakeholders are willing to actively work with you.
- IT people who are flexible, willing to try new things, and willing to collaborate with one another.
- IT people who are generalizing specialists, or at least willing to become so.
- Finding a project which is of medium complexity (therefore it's "real" in the sense that it's significant to your organization) but not one where it can make or break your organization (therefore it's safe to experiment with).
In North America we refer to this as "cherry picking" because you're picking the cherry/best situation that you can find.
- Being agile may not have been the primary determinant of success. You set up an environment where you have a good relationship with your stakeholders, where you have good people who want to work together, and the project is challenging but not impossible. Oh, and by the way you adopted a few agile techniques as well. Sounds to me that situation you could have adopted a few not-so-agile techniques instead and still succeed. Although my various project success surveys, see my IT surveys page for details, have shown time and again that agile project teams are more successful than traditional project teams I haven't been able to tease out (yet) whether this success is attributable to agile or just attributable to improved project initiation efforts.
- When adopting agile/lean widely across your organization, you can't cherry pick any more. For the past few years I've been working with IT organizations that are in the process of adopting agile/lean strategies across their entire organization, not just across a few pilot projects. What these organizations are finding is that they need to find ways to adopt agile where the business isn't as willing to work with IT, where some of the people aren't so flexible or collaborative, where some of the people are narrowly specialized and not as willing to expand their skills, or where the project exhibits scaling factors which motivates you to tailor your agile approach. It's harder to succeed with agile in these situations because they're not as "cherry" as what you've experienced previously. Luckily, if you've been successful previously then you now have some agile experienced people, you have successes to reference, and you've likely overcome some problems even in the cherry situations which you have learned from. So, your cherry successes will hopefully improve your ability to succeed even in "non cherry" situations.
- You need to work smarter, not harder. If the source of your success was actually from improved project initiation practices and not from agile, then recognize that and act accordingly. Realistically part of your success was from that and part was from agile, and the organizations that adopt a measured improvement approach potentially have the data to determine which practices lead to success and which didn't. Without the metrics you're effectively flying blind when it comes to deciding how to improve. There is clearly a mandate for smarter work practices within IT, within your organization as a whole for that matter.
If you want to gain more insight into some of the issues that you'll face when adopting agile across your organization, I suspect that you'll find my recent paper Scaling Agile: An Executive Guide
to be interesting. I've got a more detailed paper in the works, so stay tuned to this blog.
Modified by ScottAmbler
An imporant step in scaling your agile strategy is to adopt a Disciplined Agile Delivery (DAD)
approach instead of one which is just focused on agile construction. One aspect of adopting a DAD approach it to mature your focus from just producing software to instead providing a solution which meets the needs of its stakeholders within the appropriate economic, cultural, and technical constraints. The fundamental observation is that as IT professionals we do far more than just develop software. Yes, this is clearly important, but in addressing the needs of our stakeholders we will often:
Provide new or upgraded hardware
Change the business/operational processes which stakeholders follow
Change the organizational structure in which our stakeholders work
Update supporting documentation
And yes, develop high-quality 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. 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 shift to a solution-oriented focus from a software-oriented focus requires your agile teams to address some of the software-oriented prejudices which crept into the Agile Manifesto
. The people who wrote the manifesto (which I fully endorse) were for the most part software developers, consultants, and in many cases both. It is little wonder that this group would allow a bias towards software development creep into the language of their manifesto.
activities are evolutionary (iterative and incremental) and highly collaborative in nature. Initially requirements are explored at a high level via requirements envisioning
at the beginning of the project and the details are explored on a just-in-time (JIT) basis via iteration modeling
and model storming
activities. The way that you perform these agile practices, and the extent to which you do so, depends on the situation in which a project team finds itself. The Agile Scaling Model (ASM)
is a contextual framework for effective adoption and tailoring of agile practices to meet the unique challenges faced by a system delivery team of any size. To see how this works, let's apply the concepts of the ASM to see how we would scale our agile approach to requirements.
First, let's consider how a small, co-located team would work. The first two categories of the ASM are core agile development and disciplined agile delivery
, the focus of both are small co-located teams in a fairly straightforward situation. In these situations simple techniques such as user stories
written on index cards and sketches on whiteboards
work very well, so the best advice that I can give is to stick with them. Some teams will take a test-driven development
(TDD) approach where they capture their requirements and design in the form of executable specifications
, although this sort of strategy isn't as common as it should be (yet!), likely because of the greater skill and discipline that it requires. Traditionalists often balk at this approach, believing that they need to document the requirements in some manner. But, for a small co-located team working in a collaborative manner, requirements documentation proves to be little more than busy work, often doing nothing more than justifying the existence of a business analyst who hasn't made the jump to agile yet. Don't get me wrong, there are good reasons to write some requirements documentation, and we'll see this in a minute, but you should always question any request for written specifications and try to find more effective ways to address the actual goal(s) motivating the request. Never forget that written documentation
is the least effective communication
option available to you.
Although inclusive tools
such as whiteboards and paper work well for requirements, for development activities you will need electronic tools. You will either put together an environment from point-specific tools or adopt something more sophisticated such as IBM Rational Team Concert (RTC)
which is already fully integrated and instrumented. RTC is a commercial tool, but luckily you can download a 10-license environment free of charge, which is just perfect for a small team. Larger teams, of course, will need to purchase licenses. One of the things that a disciplined agile delivery approach adds to core agile development is it addresses the full delivery life cycle, which is important because it explicitly includes pre-construction activities such as requirements envisioning. The first step in scaling agile techniques is to adopt a full delivery life cycle which covers the full range of activities required to initiate a project, produce the solution, and then release to solution to your end users.
More interesting is the third category of the ASM, Agility@Scale, and how its eight agile scaling factors
affect the way that you tailor your process and tooling strategy. Let's explore how each one could potentially affect your agile requirements strategy:
- Geographical distribution. The majority of agile teams are distributed in some manner -- some people are working in cubicles or private offices, on different floors, in different buildings, or even in different countries -- and when this happens your communication and coordination risks goes up. To counter this risk you will need to perform a bit more requirements envisioning up front to help ensure that everyone is working to the same vision, although this doesn't imply that you need to write detailed requirements speculations which would dramatically increase the risk to your project. Remember, agilists do just barely enough modeling and are prepared to iteratively elicit the details when they need to do so. The more distributed the team is the more likely they will need to adopt software-based requirements modeling tools such as IBM Rational Requirements Composer (RRC) which supports streamlined, agile requirements elicitation throughout the delivery life cycle. Index cards and whiteboards are great, but they're difficult to see if you're outside the room where they're posted. I've written a fair bit about distributed agile development in this blog.
- Team size. Some organizations, including IBM, are successfully applying agile techniques with teams of hundreds of people. A team of one hundred people will naturally work much differently than a team of ten people, or of one thousand people. Large teams are organized into collections of smaller teams, and the requirements for the overall project must be divvied up somehow between those teams. The implications are that as the team size grows you will need to invest a bit more time in initial requirements envisioning, and in initial architecture envisioning for that matter; you will need to use more sophisticated tools; and may need to use more sophisticated modeling techniques such as use cases and functional user interface prototypes. See large agile teams for more advice.
- Compliance requirement. When regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable you are likely going to be required to capture requirements specifications in some manner and to enact traceability between those requirements. However, I highly recommend that you read the actual regulations yourself and don't let bureaucrats interpret them for you (doesn't it always seem that their interpretation always results in an onerous, documentation heavy solution?) because I have yet to run into a regulation which required you to work in an ineffective manner. Managing your requirements as work items in RTC can often more than meet your regulatory requirements for documentation and traceability, although you may want to consider a tool such as IBM Rational RequisitePro for complex regulatory situations.
- Domain complexity. The manner in which you elicit requirements for a data entry application or an informational web site will likely be much simpler than for a bio-chemical process monitoring or air traffic control system. More complex domains will require greater emphasis on exploration and experimentation, including but not limited to prototyping, modeling, and simulation. Although user stories may be effective as a primary requirements artifact in simple domains, in more complex domains you are likely to find that you need to drive your requirements effort with more sophisticated modeling techniques.
- Organization distribution. Sometimes a project team includes members from different divisions, different partner companies, or from external services firms. In these cases, particularly where the work is strictly organized between the various organizations (perhaps for security concerns), you may need a more sophisticated approach to managing the requirements. RTC enables you to organize the requirements between teams, and then to automatically track progress in real time via the RTC project dashboard.
- Technical complexity. The technical complexity of a solution can vary widely, from a single platform silo application to a multi-platform application working with legacy systems and data to a full-blown systems engineering effort. Complex technical domains, just like complex business domains, require more complex strategies for requirements elicitation and management. The requirements for your legacy systems are likely to have been captured using tools and techniques appropriate for that platform, for example the requirements for your COBOL application may have been captured using data flow diagrams and data models, whereas the requirements for your Java legacy application where captured using UML diagrams. The subteam working on the COBOL system might be using IBM Rational Application Developer (RAD) and RTC for Z whereas the Java subteam may use Eclipse with RTC. Because systems engineering projects can stretch on for years, particularly when the hardware is being developed in parallel to the software, sophisticated tooling such as IBM Rational DOORS is often used in these situations. For more information about systems engineering, see the IBM Rational Harmony process.
- Organizational complexity. Your approach to requirements elicitation and management will be affected by a host of organizational complexities, including your corporate culture. When the culture is flexible and collaborative you can be very agile in your approach to requirements, but as it becomes more rigid you become more constrained in what is considered acceptable and thus take on greater project risk. For example, many organizations still struggle with their approach to funding projects, often demanding that the project team provides an "accurate" estimate up front to which they will be held to. This in turn motivates risky behavior on the part of the development, including a "big requirements up front (BRUF)" approach where a detailed requirements speculation is developed early in the project. This is just one example of how questionable corporate culture can impact the way in which an agile team works.
- Enterprise discipline. Some organizations have enterprise-level disciplines, such as enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management in place. These disciplines can easily be agile and from what I can tell the more successful efforts appear to lean more towards the agile end of the spectrum rather than the traditional end. Having an enterprise business modeling effort underway will affect your project-level requirements strategy -- you'll be able to leverage existing models, have access to people who understand the domain at an enterprise level, and will likely need to map your project efforts back to your enterprise models. The enterprise modelers will likely be using tools such as IBM Rational System Architect or IBM Websphere Business Modeler.
It is important to note that the way that you tailor the agile practices that you follow, and the tools that you use, will reflect the situation that you find yourself in. In other words, you need to right size your process and the Agile Scaling Model (ASM) provides the context to help you do so. As you saw above, in simpler situations you will use the simpler tools and techniques which are commonly promoted within the core agile development community. But, when things become a bit more complex and one or more of the scaling factors applies you need to modify your approach -- just don't forget that you should strive to be as agile as you can be given the situation that you find yourself in.
In the early days of agile, the applications where agile development was applied were smaller in scope and relatively straightforward. Today, the picture has changed significantly and organizations want to apply agile development to a broader set of projects. Agile hence needs to adapt to deal with the many business, organization, and technical complexities today’s software development organizations are facing. This is what Agility@Scale is all about – explicitly addressing the complexities which disciplined agile delivery teams face in the real world.These agile scaling factors which we've found to be important are:
- Team size. Mainstream agile processes work very well for smaller teams of ten to fifteen people, but what if the team is much larger? What if it’s fifty people? One hundred people? One thousand people? Paper-based, face-to-face strategies start to fall apart as the team size grows.
- Geographical distribution. What happens when the team is distributed, perhaps on floors within the same building, different locations within the same city, or even in different countries? Suddenly effective collaboration becomes more challenging and disconnects are more likely to occur.
- Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable? These issues bring requirements of their own that may be imposed from outside your organization in addition to the customer-driven product requirements.
- Enterprise discipline. Most organizations want to leverage common infrastructure platforms to lower cost, reduce time to market, and to improve consistency. To accomplish this they need effective enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These disciplines must work in concert with, and better yet enhance, your disciplined agile delivery processes.
- Organizational complexity. Your existing organization structure and culture may reflect traditional values, increasing the complexity of adopting and scaling agile strategies within your organization. To make matters worse different subgroups within your organization may have different visions as to how they should work. Individually the strategies can be quite effective, but as a whole they simply don’t work together effectively.
- Organization distribution. Sometimes a project team includes members from different divisions, different partner companies, or from external services firms. This lack of organizational cohesion can greatly increase the risk to your project.
- Technical complexity. Some applications are more complex than others. It’s fairly straightforward to achieve high-levels of quality if you’re building a new system from scratch, but not so easy if you’re working with existing legacy systems and legacy data sources which are less than perfect. It’s straightforward to build a system using a single platform, not so easy if you’re building a system running on several platforms or built using several disparate technologies. Sometimes the nature of the problem that your team is trying to address is very complex in its own right.
Each factor has a range of complexities, and each team will have a different combination and therefore will need a process, team structure, and tooling environment tailored to meet their unique situation. Further reading: