Modificado em por ScottAmbler
A fair question to ask is why should your organization consider adopting the Disciplined Agile Delivery (DAD) process framework. I believe that there are several clear benefits to doing so:
DAD shows how agile techniques fit together. DAD is a hybrid that adopts strategies from a variety of sources, including Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Outside In Development (OID) and many more. More importantly DAD's process-goal driven approach shows how this all fits together, providing advice for when (and when not) to use each technique and the advantages and disadvantages of doing so. In doing so DAD enables you to streamline your efforts to tailor agile to reflect the context of the situation you find yourself in. Furthermore, it provides this advice in the context of a full agile delivery lifecycle, explicitly showing how to initiate a project, construct a solution, and then deploy into production. Instead of starting with a small agile method such as Scrum and doing all the work to figure out how to tailor ideas from other methods to actually make it work, why not start with a framework that's already done all that work for you?
DAD isn't prescriptive. DAD is far less prescriptive than other agile methods. For example, where Scrum prescribes a single strategy for managing changing requirements, a strategy called a Product Backlog, DAD suggests several strategies and provides advice for choosing the right one. Where other agile methods define a single lifecycle, DAD instead describes several lifecycles (an agile Scrum-based one, a lean lifecycle, and a continuous delivery lifecycle to name just three) and once again describes how to choose the right one for your situation. Your agile team is in a unique situation, and as a result needs a flexible process framework that provides coherent, easy-to-follow tailoring advice. Isn't it better to adopt strategies that reflect the context that you actually face?
DAD explicitly addresses architecture. Even after a decade of agile software development it still seems that the topic of how agile teams address architecture is a mystery for many people. As a result DAD builds agile architecture strategies right in, starting with initial architecture envisioning, to proving the architecture with working code, to evolutionary design strategies during construction.
DAD explicitly addresses DevOps. DevOps is the art of combining development and operations approaches in such a way as to streamline your overall efforts. DAD "bakes in" DevOps through explicit support for common DevOps practices as well as its robust stakeholder definition which explicitly includes operations and support people.
DAD explicitly addresses governance. Although governance is often considered a dirty word within some agile circles, the reality is that software development teams can and should be governed. Sadly, many agile teams have traditional governance strategies inflicted upon them, strategies which invariably increase schedule, cost and risk on the project. But is doesn't have to be this way. It is possible, and very desirable to adopt agile goverance strategies, strategies which are built right into the DAD framework.
DAD explicitly addresses many other important development activities. Architecture, DevOps, and governance are just the tip of the iceberg. DAD also shows how critical activities such as analysis, design, testing, quality, technical writing, and many more are addressed in an agile and streamlined manner throughout the delivery lifecycle. As described earlier, this is done in a non-prescriptive and tailorable manner, thereby removing a lot of the mystery regarding how this agile stuff all fits together into a coherent whole.
DAD is solution focused, not software focused. Although the rhetoric around "potentially shippable software" resonates well with developers it observably and empirically misses the mark. DAD promotes the more robust idea of "potentially consumable solutions". Yes, shipping is nice but shipping something that people actually want to use/buy, something that is consumable, is much nicer. Yes, software is part of the equation but that software runs on hardware, we often also need to develop supporting documentation, we often evolve the business process, and even evolve the organization structure around the usage of the system. In other words, we're really producing solutions, not just software. Isn't it better to adopt rhetoric that actually reflects what we're doing in practice?
DAD promotes enterprise awareness over team awareness. One of the great benefits of an agile approach to software development is its focus on the team. This can also be a bit of a problem, because a team-focused strategy can result in suboptimal decisions for your overall organization. DAD promotes the idea that disciplined agilists should be enterprise aware, working towards common business and technical goals while leveraging and enhancing the existing infrastructure whenever possible.
DAD provides a foundation from which to scale. The starting point for scaling agile is to understand how agile strategies fit together from project initiation to delivery into production. If you don't know how to succeed with agile in a straightforward situation then it will prove very difficult to do so in an agility @ scale situation. DAD not only provides this tailorable foundation from which to scale agile it also takes a robust view of what it means to scale agile (hint: large or distributed teams are only a start).
DAD provides a basis for enterprise agile. As organizations move towards a true "enterprise agile" approach they often find that they need to adopt either DAD as a foundation or invest a fair bit of effort inventing something similar. They are also starting to adopt strategies from the SAFe framework, or reinventing such, as well as ideas from sources such as Enterprise Unified Process (EUP) (sadly, poorly named in hindsight), ITIL, and even CoBIT. More on this in a future blog posting.
In short, DAD provides a lot of proven advice culled from years of experience applying agile software techniques in enterprise-class environments. Instead of figuring all of this stuff out on your own, why not jump ahead and leverage the hard-won lessons learned from other organizations that have already dealt with the challenges that you're struggling with today?
The primary shortcoming of the DAD framework is it makes it very clear that software development, oops I mean solution delivery, is quite complex in practice. As IT practitioners we inherently know this, but it seems that we need to be reminded of this fact every so often. DAD doesn't provide a simplistic, feel-good strategy that you can learn in a few hours of training. Instead it defines a coherent, tailorable strategy that reflects the realities of enterprise IT.
There is a wealth of information at DAD posted at the Disciplined Agile Delivery (DAD) web site and great discussions occuring on the DAD LinkedIn discussion forum. For those of you interested in agile certification, the Disciplined Agile Consortium site will prove valuable too, in particular the list of upcoming DAD workshops provided by several IBM partners. And of course the book Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise (IBM Press, 2012) written by Mark Lines and myself is a very good read.
You are invited to participate in my 2010 IT Project Success survey (http://www.surveymonkey.com/s/StateOfITUnion
The goal of this survey series is to find out how we define IT project
success in practice and how successful our projects actually are. The
survey should take you about 5 minutes to complete, and your privacy will
be completely protected.
At the end of the survey you will be given
the chance to be entered into a draw for one of 10 copies of Reflections on
Management: How to Manage Your Software Projects, Your Teams, Your Boss,
and Yourself by Watts Humphrey and William R. Thomas published in April 2010
by Addison Wesley. I'm reading it right now and it's a really great
This is an open survey, so the source data (without
identifying information to protect your privacy), a summary slide deck, and
the original source questions will be posted at www.ambysoft.com/surveys/
that others may analyze the data for their own purposes. Data
from previous surveys have been used by university students and
professors for their research papers, and hopefully the same will be true of
the data from this survey. The results from several other surveys
are already posted there, so please feel free to take advantage of
Thank you very much for taking your valuable time to
fill out this survey.
Modificado em por 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.
A common goal of IT governance is to determine the productivity of various techniques, tools, and people as part of the overall effort to improve said productivity. If you can easily measure productivity you can easily identify what is working for you in given situations, or what is not working for you, and adjust accordingly. A common question that customers ask me is how do you measure productivity on agile teams. Although you could use traditional strategies such as function point (FP) counting, or another similar strategy, this can require a lot of effort in practice. Remember that we don't only want to measure productivity, we want to do so easily. Ideally it would be nice to do so using information already being generated by the team and therefore we won't add any additional bureaucratic overhead.
A common metric captured by agile teams is their velocity. Velocity is an agile measure of how much work a team can do during a given iteration. At the beginning of an iteration a team will estimate the work that they're about to do in terms of points. At the beginning of a project the team will formulate a point system, which typically takes a few iterations to stabilize, so that they can consistently estimate the work each iteration. Although the point system is arbitrary, my team might estimate that a given work item is two points worth of effort whereas your team might think that it's seven points of effort, the important thing is that it's consistent. So if there is another work item requiring similar effort, my team should estimate that it's two points and your team seven points. With a consistent point system in place, each team can accurately estimate the amount of work that they can do in the current iteration by assuming that they can achieve the same amount of work as last iteration (an XP concept called "yesterday's weather"). So, if my team delivered 27 points of functionality last iteration we would reasonably assume that we can do the same this iteration.
So, is it possible to use velocity as a measure of productivity? The answer is not directly. For example, we have two teams, A and B, each of 5 people and each working on a web site and each having two-week long iterations. Team A reports a velocity of 17 points for their current iteration and team B a velocity of 51 points. They're both comprised of 5 people, therefore team B must be three times (51/17) as productive as team A. No! You can't compare the velocity of the two teams because they're measuring in different units. Team A is reporting in their points and B in their points, so you can't compare them directly, The traditional strategy would be to ask the teams to use the same unit of points, which might be a viable strategy with two teams although likely not if you have twenty agile teams and particularly not if you have two hundred teams. Regardless of the number of teams that you have it would minimally require some coordination to normalize the units and perhaps even some training and development and support of velocity calculation guidelines. Sounds like unnecessary bureaucracy that I would prefer to avoid. Worse yet, so-called "consistent" measurements such as FPs are anything but because there's always some sort of fudge factor involved in the process which will vary by individual estimator.
An easier solution exists. Instead of comparing velocities you instead calculate the acceleration of each team. For example, consider the reported velocities of each team below. Team A's velocity is increasing over time whereas team B's velocity is trending downwards. All things being equal, you can assume that team A's productivity is increasing whereas B's is decreasing. Of course it's not wise to manage simply by the numbers, so instead of assuming what is going on I would rather go and talk with the people on the two teams. Doing so I might find out that team A has adopted quality-oriented practices such as continuous integration and static code analysis which team B has not, indicating that I might want to help team B adopt these practices and hopefully increase their productivity.
Team A: 17 18 17 18 19 20 21 22 22 ...Team B: 51 49 50 47 48 45 44 44 41 ...
There are several advantages to using acceleration as an indicator of productivity over traditional techniques such as FP counting:1. It's easy to calculate
. For example, the acceleration of team A from iteration 1 to iteration 6 is (20-17)/17 = 0.176 whereas for team B it is (45-51)/51 = -.118. Of course, you don't need to calculate the acceleration over such a long period of time, you could do it iteration by iteration, although I find that doing it over several iterations gives a more accurate value. You'll need to experiment to determine what works for you.2. It is inexpensive
. Acceleration is based on information already being collected by the team, their velocity, so there is no extra work to be done by the team. 3. It is unlikely to be gamed
. Teams aren't motivated to fake their velocity because it provides them with important information required to manage themselves effectively. 4. It is easy to automate
. For example, Rational Team Concert (RTC)
calculates velocity automatically from its work item list (an extension of Scrum's product backlog) and does trend reporting via it's web-based project reporting functionality, providing a visual representation of the team's acceleration (or deceleration as the case may be).5. It offers the opportunity for more effective governance
. This approach reflects three of the practices of Lean Development Governance
: Simple and Relevant Metrics, Continuous Project Monitoring, and Integrated Lifecycle Environment.6. You can easily adjust for changing team size
. If the size of a team varies over time, and it will, this metric falls apart the way that I've described it. To address this issue you need to normalize it by dividing by the number of people on the team to get the average acceleration per team member.7. You can easily monetize this metric
. By knowing the acceleration of the project team and knowing how much they're spending each iteration, you can estimate the amount of money you're saving through process improvement. For example, if you're spending $100,000 per iteration and your acceleration is 2%, your cost savings is $2,000 per iteration.
Of course, nothing is perfect, and there are a few potential disadvantages:1. It is an indirect measure of productivity
. Truth be told velocity really is a productivity measure, it's just that because it's measured in different units it's difficult to compare between teams. Acceleration is merely an indicator of the change in productivity.2. You actually need to measure what you're interested in
. When you step back and think about it, you're not really interested in measuring your productivity, regardless of what the metrics wonks have been telling you the past few decades. In this case what you really want to know is your change in productivity because your real goal is to improve your productivity over time, which is what acceleration actually measures.3. Management must be flexible
. For this to be acceptable senior management must be willing to think outside the "traditional metrics box". Using a non-standard, simple metric to calculate productivity? Preposterous! Directly measuring what you're truly interested in instead of calculating trends over long periods of time? Doubly preposterous!4. Your existing measurement program may be questioned
. Once management learns how easy it can be to obtain metrics which enables them to truly govern software development projects they may begin to question the investment that they've made in the past in overly complex and expensive metrics schemes. This can be dangerous for the metrics professionals in your organization, particularly if your metrics group doesn't have valid measurements around the value of their own work. Ummmmm....5. The terminology sounds scientific
. Terms such as velocity and acceleration can motivate some of us to start believing that we understand the "laws of IT physics", something which I doubt very highly that as an industry we understand. All it would take is for someone to start throwing around terms like "standard theory" and "unified model" and we'd really be in trouble. Wait a minute..... ;-)
In summary, measuring the acceleration of development teams is an easy to collect, straightforward measure of team productivity. I hope that I've given you some food for thought, and would be eager to hear about your experiences applying this metric in practice.
I'm happy to announce that IBM Rational's RP252 Advanced Disciplined Agile Delivery (DAD) workshop
is now available. This is a 3-day, hands-on workshop which teaches students the fundamentals of Disciplined Agile Delivery (DAD)
. This workshop is offered both publicly and privately.
An inhibitor that I run into again and again within organizations that are still in the process of adopting agile development techniques is something that I call the "We're Special" anti-pattern. The people involved believe that their situation is special, that some unique factor in their environment makes it all but impossible to adopt agile techniques, and therefore they need to continue to work in the manner that they've always worked, regardless of the obvious inefficiencies of doing so.
An organization suffers from this agile adoption anti-pattern when they start giving domain-based or technology-based excuses for why they can't become more agile. For example, I've heard bank employees claim that "Agile works fine for building web sites, but we're building financial systems therefore agile won't work for us", telecom employees claim "Agile works fine for building financial systems, but we're building embedded systems therefore agile won't work for us", and government employees claim "Agile works fine for embedded systems, but we're building web sites therefore agile won't work for us." Needless to say I often struggle to not roll my eyes.
The reality is that the business domain that you're working in doesn't dictate your ability to adopt agile strategies. I've seen very successful agile projects in banks, insurance companies, manufacturing companies, retail companies, pharmacueticals (yes, life critical applications), telecoms, and government agencies. I've also met people working in those domains claim that they're special because of the inherent challenges of the domain.
Similarly, technology isn't an issue. I've seen project teams that were successful at applying agile approaches using Java, VB, COBOL, C, Linux, Windows, System Z, on PCs, and so on. Granted, some technology platforms suffer from a plethora of "agile tooling", PL/1 comes to mind and I'm sure that there's a few more niche platforms where this is the case, but with a little online searching it's often possible to find good open source tools out there (or what's stopping you from starting such a project?).
The primary issues around agile adoption are cultural in nature. Can you become more flexible in your thinking? Can you become more disciplined (agile requires greater levels of discipline than traditional approaches)? Can you build a collaborative environment with your business stakeholders? Can you move away from bureaucratic processes to ones which focus on adding real value? Can you invest in your IT staff to give them modern development skills required for test-driven development (TDD), continuous integration, and agile database techniques (to name a few)? Addressing the "people issues", the cultural issues, is the hard part of moving towards agile.
If you're looking for valid excuses for why your organization can't move to agile, here's some valid adoption inhibitors that I see in organizations all the time:
- Our project management office (PMO) has been trained and certified in traditional strategies and struggles to come to grips with agile project management techniques
- We don't have the funding to train, educate, and mentor people in agile techniques
- Middle management is threatened by agile strategies because their role clearly needs to change
- Senior technical staff, in particular our architects, don't accept the need to roll up their sleeves and be actively involved on project teams
- Our IT governance effort is not itself being governed effectively and is all but out of control, focusing on bureaucracy instead of enabling development teams to succeed
- Our data management group insists on working in a serial and documentation heavy manner
- Our QA/testing group insists on detailed requirement specifications
- Our staff is overly specialized, resulting in numerous hand-offs between analysts, developers, architects, testers, and so on
The above list is just the tip of the iceberg. The point is that the real problems that you face are cultural in nature, not domain-based nor technology-based. It is possible to overcome these inhibitors to success, but you need to understand that you're suffering from them, what the implications are, and how to overcome them. This is one of the facets of the Health Assessment portion of our new Measured Capability Improvement Framework (MCIF) service, the goal of which is to help organizations improve their internal IT processes. Although MCIF isn't specifically about becoming more agile, the reality is that there are a lot of great agile practices out there, and some of them are good options for your organization. Assuming of course you get over your misconception that you're special for some reason and instead accept the need that you've got some hard slogging ahead of you to improve your IT game.Further reading:
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
A few days later someone asked a series of questions that I thought would make an interesting blog posting, so here goes:How much of IBM's projects (in percentage) are agile at the moment?
I don’t have exact numbers, but I believe that 90%+ of our teams in SWG are applying agile techniques in practical ways that make sense for their projects. The primary goal is to be effective – in frequent releases, higher quality, and happy customers – not just agile. By the way, there is roughly 30,000 developers in SWG.Can all of IBM's projects work with an agile methodology?
It’s certainly possible, but it may not always make sense. Products that are in maintenance mode with few bugs or feature requirements may not benefit as much from agile practices -- those teams will likely continue to do whatever it is that they have been doing. Having said that, it's still highly desirable to apply agile techniques on maintenance projects.
Also, agile methods can be harder to use on some projects than others, for example, around hardware development. As a general rule, I believe that the majority of software projects can benefit from agile techniques. The primary determinant of whether a team can adopt agile techniques is culture and skill – not team size, the domain, or the degree of geographic distribution. That notion surprises many people who think that large agile teams
or geographically distributed agile teams
can’t succeed in adopting agile practices.Are agile projects sub-parts of large waterfall projects?
In some cases, that may happen. I’m sure it’s also true in reverse. We see many customers who are migrating from waterfall projects to a more agile way of doing things, and they often start this migration with smaller sub-projects. At IBM, we have tens of thousands of developers worldwide on hundreds of teams, so we have examples of pretty much any combination of agile, iterative, and traditional practices that you can imagine. There’s definitely not one size that fits all, which is a key aspect of the Disciplined Agile Delivery (DAD)
process framework.What do you think the impact of these numbers will be on the PM community?
The IBM PM community is embracing agile. And the reality is that a majority of development organizations around the world are moving to agile now as well (as much as 80% in some of the recent studies I’ve seen). I look forward to the increased adoption of agile methods by the PM community in general. The fact that PMI now offers an Agile Certified Practitioner training program certainly underscores the fact that agile practices are being adopted widely in the mainstream which is a great thing to see.
Modificado em por 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.
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:
Modificado em por 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.
When it comes to testing on agile projects it is common practice for agile teams to adopt a "whole team testing
" approach where the team itself does its own testing. To accomplish this agile teams will often embed testers in the development team. Programmers will work closely with the testers, often via non-solo development
strategies such as pair programming, to pick up their valuable testing skills. The testers will in turn pick up new skills from the programmers, and in effect both groups will move away from being just specialists (testers or programmers) to being what's called generalizing specialists
. Whole team testing can be very different from traditional approaches where programmers may do some testing, often unit testing of their own code, and then throw it over the wall to testers and quality assurance (QA) professionals for verification and validation.
The types of testing that the parallel independent test team performs may include:
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.
. 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 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.
I'd like to leave you with several important thoughts:
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.
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.
- 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).
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.
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.
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.
There seems to be a lot of misunderstanding around the topic of "Agile RUP", so I thought I'd put in my $0.02 on the subject. I suspect that some of the misunderstanding stems from lack of knowledge about RUP, either because the person either hasn't looked at RUP and is simply parroting the misinformation they heard from other people or because they've seen or been involved with questionable implmentations of RUP in the past. For the first problem I suggest reading "Agility and Discipline Made Easy" by Per Kroll and Bruce MacIsaac because it gives a pretty good overview of applying RUP in an Agile manner.
The second problem is a bit more challenging to overcome because of the very nature of RUP. RUP isn't a software process, it's actually a software process framework from which you instantiate software processes. Big difference. You select, and tailor where appropriate, the process elements appropriate to your situation. Unfortunately many organizations appear to have struggled with this concept. A common anti-pattern which are organizations that look at the RUP and say "there's a lot of really good stuff here" (absolutely true) and then conclude "we need to do it all" (yikes). That's the equivalent of going to a buffet and trying to eat all of the food in it, very clearly a bad dietary strategy. Just like you need to pick and choose only the food that you should eat, hopefully being mature enough to choose food that is good for you, you need to pick the appropriate process elements which are good for you. This requires significant experience and process knowledge to do effectively because software development is a complex endeavor and the best approach for one situation may be completely different for another situation. A second anti-pattern is when organizations assign their existing process engineers, who are often used to document-heavy serial processes, and ask them to tailor the RUP. It isn't surprising that they often produce a document-heavy and serial version of the RUP (at that point I would argue that it's no longer RUP).
The point is that these problems are self-inflicted, that these organizations could just as easily have chosen to instantiate the RUP in a light and effective manner, and better yet in a truly agile manner. In practice the RUP can be as agile as you want it to be, but you need to choose to work this way.
Some important observations:1. RUP socialized many of the concepts that Agile was built on. Although the concept of iterative development was around long before RUP, for many organizations RUP made the concept palatable through its mature approach (particularly when compared to some of the RAD/Spiral strategies at the time). In many organizations RUP also socialized testing throughout the entire lifecycle, delivery of working software each iteration, and collaborating closely with stakeholders throughout the project (to name but a few). These ideas seem straightfoward today, and they've been taken to even greater extremes in some cases , but back in the mid-90s this was pretty heady stuff for the vast majority of practitioners within the IT community. 2. RUP has adopted many of the "new" agile techniques. RUP is a process framework containing a wealth of IT practices, including both agile and traditional practices (and a lot in between). RUP continues to evolve, capturing industry best practices from many sources. So naturally RUP has adopted many agile concepts such as test-driven development (TDD), continuous integration, embracing change, and others. Check it out and see for yourself.3. RUP is as agile, or non-agile, as you want to make it. I've said it before and I'll say it again -- the RUP is a process framework from which you instantiate processes. You've got complete control over how agile the RUP is.4. RUP contains many of critical techniques for scaling agile. In a previous blog posting I overviewed the issues around scaling, not only is team size an issue but so is geographical distribution, regulatory compliance, application complexity, legacy systems/policies, governance, and organizational distribution.
I'm sure some people are reading this and thinking to themselves "of course this is what Scott is going to say, that's his job." Well, think what you want, but I was writing about how to take an agile approach several years before joining IBM. In fact, I believe that I'm the first to do so, writing about it in print in my Software Development column back in 2001 and more importantly in my book Agile Modeling: Effective Practices for XP and UP in 2002. And, if you go poking around the web a bit, you'll see a lot other have written about this too, including Craig Larman, Ivar Jacobson, Bob Martin, Gary Evans, Doug Rosenberg and many more.
I'd like to leave you with a sound bite: "The RUP done right is Agile. The RUP done wrong is just plain wrong."[Read More
One of the scaling factors
called out in the Agile Scaling Model (ASM)
is “regulatory compliance”. This name is a bit of a misnomer because this scaling factor really addresses two issues: complying to regulations imposed upon you from external sources and choosing to adhere to internal regulations willingly adopted by your organization. It is relatively common for agile teams to find themselves in such situations. For example, in the 2009 Agile Practices Survey
one third of respondents said that they were applying agile on projects where one or more industry regulations applied.
First let’s consider external regulatory compliance. In these situations you may face the need to undergo an audit by an external regulatory body with consequences for non-compliance ranging from anywhere to a warning to a fine or even to legal action. Sometimes even a warning may be a grave thing. A few years ago I was working with a pharmaceutical company which had discovered that a warning from the FDA for non-compliance with their CFR 21 Part 11 regulation, when reported in major newspapers, resulted on average in a half-billion dollar loss to their market capitalization as the result of a dip in their stock price. There are financial regulations such as Sarbanes-Oxley and Basel II, informational regulations such as HIPAA which focuses on health information privacy, technical regulations such as ISO 27002 for security practices, and even life-critical regulations such as some of the FDA regulations.
External regulations are typically managed by a government organization or industry watchdog will range in complexity and can have a myriad of effects on project teams. For example, you may need to be able to prove that you had a documented process and that you followed it appropriately; you may need to produce extra artifacts, or more detailed artifacts, than you normally would; you may need to add extra features to your solution, such as tracking financial information, that you wouldn’t have normally implemented; you may need to produce specific reports to be submitted to the regulatory body; or you may even need to submit your team to audits, sometimes scheduled and sometimes not, to ensure regulatory compliance. Interestingly, even though many of those requirements go against the agile grain, the 2009 Agility at Scale Survey
found that organizations were successfully applying agile techniques while still conforming to external regulations. So yes, it is possible to scale your agile strategy to address regulatory compliance.
Second, let’s consider compliance to internally adopted, or sometimes even developed, “regulations” which you will be potentially evaluated/appraised against. Perfect examples of these are process improvement frameworks such as CMMI and ISO 900x. Similar to external regulations, the 2009 Agility at Scale Survey
found that some agile teams are succeeding in situations where they have chosen to adopt such frameworks. It’s important to note that frameworks such as CMMI aren’t primarily about ensuring the compliance of development teams to a standard process, regardless of what CMMI detractors may claim, but instead about process improvement. Process improvement at the IT department (or beyond) is an enterprise discipline issue from the point of view of ASM, implying that frameworks such as CMMI affect more than one scaling factor.
When you find yourself in a regulatory situation, whether those regulations are imposed or willingly adopted, the best advice that I can give is to read the regulations and develop a strategy to conform to them in the most agile manner possible. If you let bureaucrats interpret the regulations you’ll likely end up with a bureaucratic strategy, but if you instead choose to take a pragmatic approach you will very likely end up with a very practical strategy. Part of that strategy is to treat the regulatory representative(s) within your organization as important stakeholders whom you interact with regularly throughout the project.
One of the scaling factors
of the Agile Scaling Model (ASM)
is technical complexity.
The fundamental observation is that the underlying technology of solutions varies and as a result your approach to developing a solution will also need to vary.
It’s fairly straightforward to achieve high-levels of quality if you’re building a new system from scratch on a known technology platform, but not so easy when there are several technologies, the technologies are not well known, or legacy assets are involved.
There are several potential technical complexities which a Disciplined Agile Delivery (DAD) team may face:
- 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).
- 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.
- 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).
- 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.
- 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.
- 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.
The technical complexity faced by a project team is contextual – Working with four technology platforms is straightforward for someone used to dealing with seven, but difficult for someone used to dealing with just one. Recommended Reading:
Yesterday I was involved with a workshop around agile development at scale. At one point in the conversation we started talking about the relationship between cost and quality. Some of the people in the workshop were relatively new to agile and still believed the traditional theory that to build in high quality it costs more, sometimes substantially more. This does appear to be true on traditional waterfall projects, but some people were making the mistake that this was an "natural law of IT" which also must apply to agile project teams. I naturally jumped on that idea and described how agile developers have found that writing high quality code leads to lower development costs and shorter time to value, in direct contradiction to traditional theory. A few people struggled with the idea for a bit, and one was pretty adamant that in some cases the need for very high quality does in fact lead to greater cost and time. He talked about his experiences on large-scale Rational Unified Process(RUP)
projects and in particular how some URPS (usability, reliability, performance, and supportability) requirements can increase your cost. At this point Per Kroll, co-author of Agility and Discipline Made Easy: Practices from OpenUP and RUP
, jumped into the conversation and pointed out although higher quality does lead to lower cost in most cases, using Toyota's lean approach to manufacturing as an example, that the agile community didn't completely have the relationship between quality and cost completely correct. My spidey sense told me that a learning opportunity was coming my way.
Per and I had an offline discussion about this to explore what he'd been observing in practice. In most situation it appears to be the case that higher quality does in fact lead to lower costs and shorter time for delivery, something that Per and I had observed numerous times. This happens because high quality code is much easier to understand and evolve than low quality code -- the agile community has found that it is very inexpensive to write high quality code by following practices such as continuous integration
, developer regression testing [or better yet test-driven development(TDD)
], static code analysis
, following common development conventions, and agile modeling strategies
. When you "bake in" quality from the start through applying these techniques, instead of apply traditional techniques such as reviews
and end-of-lifecycle testing (which is still valid for agile projects, but should not be your primary approach to testing) which have long feedback cycles
and therefore prove costly in practice. But, as we've learned time and again, when you find yourself in more complex situations of Agility@Scale sometimes the mainstream agile strategies fall down. For example, in situations where the regulatory compliance scaling factor is applicable, particularly regulations around protecting human life (i.e. the FDA's CFR 21 Part 11), you find that some of the URPS requirements require a greater investment in quality which can increase overall development cost and time. This is particularly true when you need to start meeting 4-nines requirements (i.e. the system needs to be available 99.99% of the time) let alone 5-nines requirements or more. The cost of thorough testing and inspection can rise substantially in these sorts of situations.
In conclusion, it does seem to be true in the majority of situations, which is what the level 1 rhetoric focuses on, that higher quality leads to lower development costs. But at scale this doesn't always seem to hold true.
PS -- Sorry for the corny title, but a couple of days ago at the Rational Software Conference I had the pleasure of interviewing Jamie Hyneman and Adam Savage from the Discovery Channel's Mythbuster's show as part of the conference keynote. They're great guys, BTW, who have had a really positive impact on motivating children to be interested in science (apparently kids like to see stuff get blown up, go figure).[Read More
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:
- 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.
- 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.
- 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".
- 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.
- 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.
- 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.
- 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.
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:
It's customary to start a blog by describing the vision for it. Although this vision will undoubtedly evolve over time, it's always good to put a stake in the ground to get things started. Agile software development is clearly taking off and in my opinion is becoming the dominant development paradigm. Furthermore it appears that Agile approaches enjoy a higher success rate, providing better value for your IT investment, than do traditional approaches. Although organizations are succeeding at simpler projects with agile, many are struggling when applying Agile in more complex situations. They're finding that the "Agile rhetoric" doesn't always live up to its promises once you move into these complex situations. My goal with this blog is to share strategies for applying Agile techniques at scale.
When applying Agile strategies at scale you are likely to run into one or more of the following complexity factors:1. Geographical distribution. Is your team, including stakeholders, in different locations? Even being in different cubicles within the same building can erect barriers to communication, let alone being in different cities or even on different continents.2. Regulatory compliance. Regulations, including the Sarbanes-Oxley act, BASEL-II, and FDA statutes, to name a few, can increase the documentation and process burden on your projects. Complying to these regulations while still remaining as agile as possible can be a challenge.3. Entrenched policies, people, and processes. Most agile teams need to work within the scope of a larger organization, and that larger organization isn't always perfectly agile. Hopefully that will change in time, but we still need to get the job done right now. Your existing culture and organization can really hinder your ability to scale agile approaches, then a few "simple" changes can really help your efforts.4. Legacy systems. Although the politically correct term would be "proven assets" the reality is that it can be very difficult to leverage existing code and data sources due to quality problems. The code may not be well written, documented, or even have tests in place, yet that doesn't mean that your agile team should rewrite everything from scratch. Some legacy data sources are questionable at best, or the owners of those data sources difficult to work with, yet that doesn't given an agile team license to create yet another database.5. Organizational distribution. When your teams are made up of people working for different divisions, or if you have people from different companies (such as contractors, partners, or consultants), then your management complexity rises.6. Degree of governance. If you have one or more IT projects then you have an IT governance process in place. How formal it is, how explicit it is, and how effective it is will be up to you. IBM has been doing a lot of work in this topic over the past few years, and just recently Per Kroll and I have done some work around Lean Governance strategies. 7. Team size. Large teams will be organized differently than small teams, and they'll work differently too.8. System complexity. The more complex the system the greater the need for a viable architectural strategy. An interesting feature of the Rational Unified Process (RUP) is that it's Elaboration phase's primary goal is to prove the architecture via the creation of an end-to-end, working skeleton of the system. This risk-reduction technique is clearly a concept which Extreme Programming (XP) and Scrum teams can clearly benefit from.
It is definitely possible to scale Agile software development to meet the real-world complexities faced by modern organizations. Based on my experiences, I believe that over the next few years we'll discover that Agile scales better than traditional approaches. Many people have already discovered this, but as an industry I believe that there isn't yet sufficient evidence to state this as more than opinion. My goal with this blog is to provide advice for scaling Agile so as to increase your chances of success.
So, it looks like I have my work cut out for me. My strategy will be to address common questions which I get when working with customers and with internal IBM development teams. I have the privilege to work with a variety of software development teams worldwide, helping them to become more agile. They're all struggling with the same basic issues although don't recognize it because they're too focused on their own situation. So hopefully I'll be able to spread the word about what's actually working in practice.
I hope that you stay tuned.
- Scott[Read More
The popular Agile literature can often seam naive when it comes to how Agilists work with project stakeholders:- Extreme Programming (XP) has a practice called On-Site Customer where one or more people work closely with your team to provide information and to make decisions in a timely manner.- Scrum has the role of Product Owner who is the one single person that the development team goes to for decisions about requirements. - Agile Modeling (AM) has the practice of Active Stakeholder Participation which extends On-Site Customer to get the stakeholder(s) actively involved with the modeling effort through the use of inclusive tools and techniques.
These are great strategies for small, co-located teams doing straightforward development, but they quickly fall apart at scale. This occurs for several reasons:1. Stakeholders are a diverse group. Your stakeholders include end users, business management, project funders, enterprise architects, operations staff, support staff, other system development teams, and many others. Different people have different, and often contradictory, requirements and they certainly have different priorities. It's questionable whether a single person, or a handful of persons, can adequately represent this diverse group.2. One person becomes a bottleneck. Even with a small co-located team this is a problem, let alone one that is geographically distributed or one that is very large. There's no way that a single person can be available 24/7 in a responsive manner to support distributed teams.3. It's a difficult role. The Product Owner/Customer (POC) is responsible for representing the business to the development team. They're making important decisions on a regular basis, decisions which they'll be held accountable for.4. One person becomes a serious project risk. Not only is it questionable whether a single person can fairly represent all stakeholders, even if they could what happens if you lose that person? They effectively become a single point of failure for your team.
To scale this role, consider the following strategies:1. Recognize the true scope of the POC role. Not only are they stakeholder proxies they also are a development team representative to the stakeholder community as a whole. As stakeholder proxies they'll make decisions and prioritize the work, they'll run requirements elicitation sessions, they'll negotiate priorities, and they'll put the development team in contact with stakeholders who have expertise in specific aspects of the domain. As team representatives they'll often demo the current version of the system to other stakeholders, communicate the status of the project to people, and respond to various requests for information from the stakeholders.2. Have multiple people in it. A single POC works well for small, co-located teams developing simple software. At scale you'll soon discover that you need multiple people in this role so that they don't become a bottleneck. For distributed teams it's common to see each subteam have one or more POCs who are managed by a primary/chief POC. The primary POC typically works on the coordinating team with the chief architect (I'll talk about this role in a future blog posting) and the program manager (also a topic for a future blog posting).3. Train them in business analysis skills. The person(s) in the POC role need good business analysis skills. If fact, it's common for people who were formerly BAs for traditional teams to step into the POC role, particularly with BAs who originally come from the business side of your organization. This strategy has its advantages and disadvantages. As a BA they've likely got solid business knowledge but their instincts may motivate them to take a documentation-driven approach to providing information to the development team instead of a collaboration-based approach. Be careful.4. Consider the full system development lifecycle. There's far more to the POC role than supporting the development team during Construction iterations. During "Iteration 0", the Inception phase for an Agile RUP project or the warm-up phase for an Eclipse Way project, the POC(s) will often lead the initial requirements envisioning efforts. The product backlog, or better yet your work item list, needs to come from somewhere after all. During the release iteration(s), the Transition phase for RUP or the End-Game phase for Eclipse Way, the POC(s) will focus on communicating the upcoming release to the stakeholder community, will be actively involved with any final user acceptance testing (UAT), and may even be involved with training end users.
In my January 2008 column in Dr Dobb's Journal, posted at http://www.ddj.com/architect/204801134 , I provide detailed advice about how to scale the way that you work with stakeholders on Agile projects by applying the practices of Agile Model Driven Development (AMDD). There's no magic solution, you just need to choose to organize yourself effectively. The good news is that you can easily work with stakeholders at scale.[Read More
And now, a brief message from our sponsor. ;-)
Just wanted to let you know that Agility@Scale will be a major theme at this year's IBM Rational Software Conference
being held in Orlando May 31 through to June 4. I'll be giving two presentations, Agility at Scale: Mitigating the Percieved Risks of Agile Adoption
and Distributed Agile Software Development: Best Practices
, facilitating a panel entitled Experience Reports from the Agile Trenches: What's Really Working, What's Not Working, and Why
, and running a half-day workshop entitled Become as Agile as You Need to Be: Scaling Agile Software Development to Meet Your Real-World Situation
. As usual, it will be a busy conference for me. ;-)
There are of course other sessions and workshops specific to agile topics. Some highlights include:
Of course there's a lot more going on at the conference when it comes to scaling agile software development than just these sessions, but I thought I'd give you a feel for what's going on. Hope to see you at the conference. There's a "March Madness" sale going on right now at the registration page
where if you purchase one pass you get the second for half price.Further reading:
I'm happy to announce Rational's Agility at Scale poster which is currently available free of charge from the Rational poster order page
Although I'm obviously biased as I was involved with its creation, the poster includes some really good information about how to scale agile software development practices effectively. It summarizes the scaling factors, such as large teams, distribution, regulatory compliance, application complexity, and so on that you should be concerned with. It also presents a full agile software development lifecycle that goes beyond the construction focused lifecycles of common "agile in the small" processes. It also summarizes the practices of lean development governance, giving you some insight into how to govern your IT environment more effectively.
I think it's a pretty good poster that's worth checking out. It's free, so it's hard to argue with the price. Most importantly, it would look pretty good hanging on your office wall.
I recently wrote an "e-book" for Internet Evolution overviewing agile software development at scale. The goal of the Agility at Scale: Become as Agile as You Can Be
ebook is to get people thinking outside of the box a bit when it comes to agile development strategies and see that they really are ready for primetime.
I recently did the voice over for our Rational.Everyware Agility@Scale whiteboard video
, which is a bit less than 4 minutes in length. As I narrate a whiteboard sketch evolves, sometimes using sticky-notes and index cards, to help explain what I'm talking about.
In the video, I describe:
- 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
So, it's basically a cool marketing video for a bunch of free stuff.
Modificado em por ScottAmbler
On April 25, 2013 I gave a webcast for the Global Rational User Community entitled Disciplined Agile Delivery: Going beyond Scrum . During the webcast a large number of questions were asked but unfortunately I couldn’t get to all of them. So I’ve taken the opportunity to write up the answers in this blog posting.
Fequently asked questions. Many of the questions are addressed in the DAD FAQ.
DAD elevator pitch - I will be starting work in a couple of weeks for a company that has just started its Agile journey this year by implementing Scrum. What would Scott put in an elevator chat as to why they should be moving towards DAD. The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable. There are clearly some interesting aspects to the DAD framework. DAD is a hybrid approach which extends Scrum with proven strategies from Agile Modeling (AM), Extreme Programming (XP), Unified Process (UP), Kanban, Lean Software Development, Outside In Development (OID) and several other methods. DAD is a non-proprietary, freely available framework. DAD extends the construction-focused lifecycle of Scrum to address the full, end-to-end delivery lifecycle from project initiation all the way to delivering the solution to its end users. It also supports lean and continuous delivery versions of the lifecycle: unlike other agile methods, DAD doesn’t prescribe a single lifecycle because it recognizes that one process size does not fit all. DAD includes advice about the technical practices such as those from Extreme Programming (XP) as well as the modeling, documentation, and governance strategies missing from both Scrum and XP. But, instead of the prescriptive approach seen in other agile methods, including Scrum, the DAD framework takes a goals-driven approach. In doing so DAD provides contextual advice regarding viable alternatives and their trade-offs, enabling you to tailor DAD to effectively address the situation in which you find yourself. By describing what works, what doesn’t work, and more importantly why, DAD helps you to increase your chance of adopting strategies that will work for you. The article Introduction to Disciplined Agile Delivery provides a more detailed description.
The book: Could you please repeat the name of the book that Scott is talking about? The book is Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise published by IBM Press, June 2012. The Disciplined Agile Delivery (DAD) website and the Disciplined Agile Consortium website are also good DAD resources.
The Surveys: Where is the data published about geographic distribution and effectiveness? All of my survey data, the original questions as asked, and my analysis can be downloaded free of charge from my IT Surveys page. If you ever see a request from me to fill out a survey, please take a few minutes and do so. I think you'll agree that my surveys page is in fact a very useful resource, so please contribute when you can.
Project success criteria: Where would a goal of defining success criteria fall? In the DAD book we describe how the success criteria for the project should be initially identified during Inception. Success criteria, like other things, could evolve throughout the project. You might find the IT Process Success Surveys to be of interest as several of them explored what success criteria projects actually have. Interestingly, its rarely “on time, on budget, to specification”.
Transitioning to DAD: How would you typically phase a DAD implementation, let's say in a project pilot where they haven't been exposed yet to Agile? Same question, any variance if the development team has already started Scrum? This is a fairly complex question to answer. The short story is that you need to invest some time to understand what your strengths and weaknesses are so that you can identify what you need to focus on. You will then likely need to pilot strategies/techniques which are new to your organization before rolling them out widely. You may also need to invest in training and coaching/mentoring depending on your needs. My company, Scott Ambler + Associates, offers these sorts of services and more for organizations interesting in adopting disciplined agile strategies.
Skills: I am aware that ideally developer should also be able to test but in reality theses are usually separate roles. Is it in line with your beliefs\suggestions? Many organizations that are new to agile still have roles that reflect their existing strategy. Non-agile approaches often have people in specific roles such as programmer, tester, designer, and so on. In DAD we promote a different set of agile roles that reflect agile thinking. The implication is that you’re going to have to help individuals transition over to the new way of thinking, something we cover in Chapter 4 of the DAD book. You might also find Mark Lines' blog, No role in DAD for an Analyst? to provide some insights into issues surrounding the transition from traditional to agile roles.
Teaming: What happens with the Product Owner and the Architecture Owner don’t Agree? See my blog What Happens When People Don’t Agree
Skillsets: Different people of the team have different skills, experience, and time horizons. We can't all be generalists, can we? There are several agile roles in DAD, each of which have different rights, responsibilities, and skillsets. So we’re not promoting the idea that everyone have the same skillset. However, we do promote the philosophy that people should strive to be T-skilled generalizing specialists so as to improve their productivity.
Teaming: What are your thoughts on team cohesion? Teams will gel over time. Being co-located helps. Having people who are dedicated 100% to the team helps. Building a team of people who want to be there helps. Self organization helps.
Tool support: Is there an RMC plug-in for DAD + Is there any software behind DAD... or some software that supports it... such as Jazz (RTC) for Agile/Scrum? Yes, IBM Rational does in fact have an RMC plug in for DAD. There is also a template for Microsoft TFS from RDA Corp, Software Development Expert’s Practices Advisor supports DAD comprehensively, and I’m currently working with MethodPark to do so too. Stay tuned to the Disciplined Agile Delivery website for information about tool support.
Governance: Regarding enterprise governance and enterprise IT, how do you start taking a culture that imposes common-process, common-tools, central (often outsourced) IT services, and heavyweight stage/gate across all organizations, and get that evolving toward a (still enterprise aware) lean/agile approach? This is a hard one. I’m often called into organizations to help with this very issue. The challenge is that you need to have a deep understanding of IT governance techniques as well as how to govern agile teams. Governance is something we discussed in detail in the DAD book as well as on the DAD site, see Adopting Agile Governance Requires Discipline.
Executable specifications: TDD was mentioned, can you comment on Behavior Driven Development (BDD) and any impact on this lifecycle? BDD is a slight nuance to acceptance test-driven development (ATDD). BDD/ATDD and TDD are both potential practices that you might choose to follow on a DAD team. I’ve written a fair bit about agile testing and quality strategies and about TDD in detail.
Architecture: When does the first version of architecture gets established and what would require to establish it? You typically start thinking about architecture early in a DAD project during Inception following a practice called architecture envisioning. I’ve also written a fair bit about agile architecture techniques and the potential misconceptions about agile architecture that you may find interesting.
Travel plans: Will you be coming to South Africa at some point? The good news is that Mark Lines, my co-author, will be in South Africa the week of May 20 in Joburg and the following week in Capetown. Contact us for details. I hope to be visiting SA later this year but exact dates haven’t been set yet. So, please stay tuned on Twitter at @scottwambler for further announcements.
Other travel plans: If you'd like me to speak at a local event, including corporate conferences or training events, please contact me.
The Disciplined Agile Consortium
recently launched a certification programme for practitioners of Disciplined Agile Delivery (DAD)
. There are three practitioner certifications
- 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.
- 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).
- 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.
As an aside, the Disciplined Agile Consortium is proud to have IBM Rational's Richard Knaster and Carson Holmes the president of the Global Rational User Group (GRUG) on our board of advisors.
Again and again I've seen IT organizations suffering from what I call the "Bureaucracy is Discipline" antipattern. For example, filling out forms and reviewing documents are both bureaucratic activities, neither of which require significant skill nor discipline to accomplish. However, agile practices such as developing potentially shippable software every iteration is easy to say but requires great discipline to accomplish. Respecting the decisions of your stakeholders, particularly those pertaining to requirements prioritization, is easy to talk about but proves to require great discipline in practice (particularly when you don't agree with a decision). It's easy to talk about taking a test-driven approach to development
, but in practice it requires significant skill and discipline to actually do.
A "process smell" which indicates that your organization is suffering from this antipattern is a focus on following repeatable processes instead of focusing on repeatable results. An example of repeatable processes is following the same route to work every day regardless of driving conditions. An example of repeatable results is getting to work on time every day, but being willing to change your route as required, bicycling into work instead of driving, taking public transit, and so on. Nobody really cares how you get to work each day (the process), what they really care about is that you got to work on time (the result). Sadly, we've been told for decades now that repeatable processes are critical to our success in IT, yet when you step back and think about that's really a reflection of a bureaucratic approach. On the other hand, a focus on repeatable results is a reflection of a more disciplined approach. Interestingly, the DDJ 2008 Process Framework survey
found that given the choice that people would much rather have repeatable results over repeatable processes
when it comes to IT.
Mistaking bureaucracy for discipline, or rigour if you prefer that term, is a reflection of the cultural damage that has occurred over the years in IT organizations as the result of traditional philosophies and techniques. Unfortunately, this mistaken belief is a significant inhibitor to software process improvement (SPI) efforts, in particular agile adoption efforts
, which must be addressed if you're to be successful. Overcoming this challenge will require a significant cultural shift in some organizations, and many people (particularly the bureaucrats) will find this uncomfortable.Further reading:
I'd like to leave you with this parting thought: Bureaucracy is bureaucracy and discipline is discipline, please don't confuse the two
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.
I recently recorded an audio podcast
about Collaborative Development and Operations (DevOps) and how it relates to Disciplined Agile Delivery (DAD)
. The podcast is 17 minutes long and covers a range of topics including:
- 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?
On a related note, IBM's Collaborative Development and Operations
landing page has some great resources if you're interested in how to implement.
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.
Although it might not be obvious, and important success factor in adopting agile techniques
is to be able to determine whether a team is agile or not. The challenge that many organizations face is that many teams will claim to be agile, yet management, who often has little or no experience with agile approaches, cannot tell which claims are true and which are over zealous (I'm being polite). The following are the criteria that I suggest you look for in a disciplined agile team:1. Produce working software on a regular basis
. This is one of the 12 principles behind the Agile Manifesto
, and in my experience is a critical differentiator between the teams that are agile and those that are merely claiming it. Ideally the team should produce potentially shippable software each iteration. That doesn't mean that they'll deploy the system into production, or the marketplace, each iteration but they could if required to do so. Typically the team will deploy into a pre-production testing environment or a demo enviroment at the end of each iteration (or more often for that matter).2. Do continuous regression testing, and better yet take a Test-Driven Development (TDD) approach
. Agile developers test their work to the best of their ability, minimally doing developer regression testing via a continuous integration (CI) strategy
and better yet do developer-level TDD
. This approach enables development teams to find defects early, thereby reducing the average cost of addressing the defects, it also helps them to deliver higher quality code and to move forward safely when adding or changing functionality.3. Work closely with their stakeholders, ideally on a daily basis
. A common practice of agile teams is to have an on-site customer or product owner who prioritizes requirements and provides information on a timely manner to the team. Disciplined agile teams take it one step further and follow the practice active stakeholder participation
where the stakeholders get actively involved with modeling and sometimes even development.4. Are self-organizing within a governance framework
. Agile teams are self-organizing, which means that the people doing the work determines how the work will be done, they're not told by a manager who may not even be directly involved with the work how it will be done. In other words the team does its own planning, including scheduling and estimation. Disciplined agile teams are self governing within an effective governance framework
.5. Regularly reflect on how they work together and then act to improve on their findings
. Most agile teams hold a short meeting at the end of each iteration to reflect upon how well things are working and how they could potentially improve the way that they are working together. Sometimes this is done in a more formalized manner in the form of a retrospective
, but often it's done informally. The team then acts on one or more of their suggested improvements the next iteration. Disciplined agile teams take this one step further and measure their software process improvement (SPI) progress over time: the act of taking these measures, perhaps via a product such as Rational Self Check
, helps to keep the team on track in their SPI efforts.
I have yet to discover an ad-hoc development team which met all five criteria, and most of them rarely meet two or three.Further reading:
When adopting agile software development
techniques across a large number of teams within your organization it is important to provide a definition for what agile software development is, in addition to criteria
for what it means to be agile. Many people will point to the four values of the Agile Manifesto
and claim that's a good definition. Well... it might be a good definition for the visionaries and early adopters among us, but for people on the right-hand side of the technology adoption chasm (the early majority, late majority and the laggards) this isn't enough. Don't get me wrong, I'm a firm believer in the agile values but I like to cast them as philosophies instead of as a definition.
At IBM Software Group, the definition of disciplined agile software delivery which we have been sharing with our customers is:Disciplined agile software delivery is an evolutionary (iterative and incremental) approach to delivery which regularly produces high quality software in a cost effective and timely manner. It is performed in a highly collaborative and self-organizing manner, with active stakeholder participation to ensure that the team understand and addresses the changing needs of its stakeholders. Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
I think that this is a pretty good definition, although I have no doubt that we'll evolve it over time.
I also suspect that the agile community will never settle on a common definition for what agile is and more than likely are smart enough not to even try. ;-)Further reading:
At IBM Rational we define disciplined agile delivery as:
Disciplined agile delivery is an evolutionary (iterative and incremental) approach which regularly produces high quality solutions in a cost effective and timely manner via a risk and value driven life cycle. It is performed in a highly collaborative, disciplined, and self-organizing manner within an appropriate governance framework, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders to maximize business value provided. Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
Let’s explore the key points in this definition:
- Full delivery life cycle. Disciplined agile delivery processes have life cycles which are serial in the large and iterative in the small. Minimally they have a release rhythm which recognizes the need for start up/inception activities, construction activities, and deployment/transition activities. Better yet, they include explicit phases as well. It is very important to note that these are not the traditional waterfall phases – requirements, analysis, design, and so on – but instead different “seasons” of a project. The point is that we need to look beyond agile software development and consider the full complexities of solution delivery. Adopting a full delivery life cycle, not just a construction life cycle, is arguably the “zeroth” agile scaling factor.
- Evolutionary. Agile strategies are both iterative and incremental in nature. Iterative means that you are working in a non-serial manner, on any given day you may do some requirements analysis, some testing, some programming, some design, some more testing, and so on. Incremental means that you add new functionality and working code to the most recent build, until such time as the stakeholder determines there is enough value to release the product.
- Regularly produces high quality solutions. Agilists are said to be quality focused. They prefer to test often and early, and the more disciplined ones even take a test-first approach where they will write a single test and the just enough production code to fulfill that test (then they iterate). Many agile developers have adopted the practice of refactoring, which is a technique where you make simple changes to your code or schema which improves its quality without changing its semantics. Adoption of these sorts of quality techniques seems to work – it appears that agile teams are more likely to deliver high quality systems than traditional teams (according to the DDJ 2008 Project Success survey). Within IBM we take it one step further and focus on consumability, which encompasses quality and other features such as ease of deployment and system performance. Furthermore, although some agile methods promote the concept of producing “potentially shippable software” on a regular basis, disciplined agile delivery teams produce solutions: a portion of which may be software, a portion of which may be hardware, and a portion of which will be the manner in which the system is used.
- Cost effective and timely manner. Agile teams prefer to implement functionality in priority order [http://www.agilemodeling.com/essays/prioritizedRequirements.htm], with the priority being defined by their stakeholders (or a representative thereof). Working in priority order enables agile teams to maximize the return on investment (ROI) because they are working on the high-value functionality as defined by their stakeholders, thereby increasing cost effectiveness. Agile teams also prefer to produce potentially shippable solutions each iteration (an iteration is a time-box, typically 2-4 weeks in length), enabling their stakeholders to determine when they wish to have a release delivered to them and thereby improving timeliness. Short iterations reduce the feedback cycle, improving the chance that agile teams will discover problems early (they “fail fast”) and thereby enable them to address the problems when they’re still reasonably inexpensive to do so. The DDJ 2008 Project Success survey found that agile teams are in fact more likely to deliver good ROI than traditional teams and more likely to deliver in a timely manner.
- Value driven life cycle. One result of building a potentially shippable solution every iteration is that agile teams produce concrete value in a consistent and visible manner throughout the life cycle.
- Risk and value driven life cycle. Core agile processes are very clear about the need to produce visible value in the form of working software on a regular basis throughout the life cycle. Disciplined agile delivery processes take it one step further and actively mitigate risk early in the life cycle – during project start up you should come to stakeholder concurrence regarding the project’s scope, thereby reducing significant business risk, and prove the architecture by building a working skeleton of your system, thereby significantly reducing technical risk. They also help with transition to agile, allowing traditional funding models to use these milestones before moving to the finer grained iteration based funding that agile allows.
- Highly collaborative. People build systems, and the primary determinant of success on a development project is the individuals and the way that they work together. Agile teams strive to work closely together and effectively as possible. This is a characteristic that applies to both engineers on the team, as well as their leadership.
- Disciplined. Agile software development requires greater discipline on the part of practitioners that what is typically required by traditional approaches.
- Self organizing. This means that the people who do the work also plan and estimate the work.
- Self-organization within an appropriate governance framework. Self-organization leads to more realistic plans and estimates which are more acceptable to the people implementing them. At the same time these self-organizing teams must work within an appropriate governance framework which reflects the needs of their overall organizational environment. An “appropriate governance framework” explicitly enables disciplined agile delivery teams to effectively leverage a common infrastructure, to follow organizational conventions, and to work towards organizational goals. The point is that project teams, regardless of the delivery paradigm they are following, need to work within the governance framework of their organization. More importantly, effective governance programs should make it desirable to do so. Our experience is that traditional, command-and-control approaches to governance where senior management explicitly tells teams what to do and how to do it don’t work very well with agile delivery teams. We’ve also found that lean development governance, an approach which is based on collaboration and enablement, is far more effective in practice. Good governance increases the chance that agile delivery teams will build systems which fit into your overall organizational environment, instead of yet another stand-alone system which increases your overall maintenance burden and data quality problems.
- Active stakeholder participation. Agile teams work closely with their stakeholders, who include end users, managers of end users, the people paying for the project, enterprise architects, support staff, operations stuff, and many more. Within IBM we distinguish between four categories of stakeholder: principles/sponsors, partners (business partners and others), end users, and insiders These stakeholders, or their representatives (product owners in Scrum, or on-site customers in Extreme Programming, or a resident stakeholder in scaling situations), are expected to provide information and make decisions in a timely manner.
- Changing needs of stakeholders. As a project progresses your stakeholders will gain a better understanding of what they want, particularly if you’re showing them working software on a regular basis, and will change their “requirements” as a result. Changes in the business environment, or changes in organization priority, will also motivate changes to the requirements. There is a clear need for agile requirements change management [http://www.agilemodeling.com/essays/changeManagement.htm] on modern IT projects.
- Repeatable results. Stakeholders are rarely interested in how you delivered a solution but instead in what you delivered. In particular, they are often interested in having a solution which meets their actual needs, in spending their money wisely, in a high-quality solution, and in something which is delivered in a timely manner. In other words, they’re interested in repeatable results, not repeatable processes.
- Right amount of ceremony for the situation. Agile approaches minimize ceremony in favor of delivering concrete value in the form of working software, but that doesn’t mean they do away with ceremony completely. Agile teams will still hold reviews, when it makes sense to do so. DDJ’s 2008 Modeling and Documentation Survey found that agile teams will still produce deliverable documentation, such as operations manuals and user manuals, and furthermore are just as likely to do so as traditional teams. The DDJ September 2009 State of the IT Union survey found that the quality of the documentation delivered by agile teams was just as good as that delivered by traditional teams, although iterative teams (e.g. RUP teams) did better than both agile and traditional.
Modificado em por ScottAmbler
This blog posting has been replaced by the more detailed article: Full Agile Delivery Lifecycles.
Thank you for your patience.
The basic idea behind DevOps
is that your development strategy and operations strategy should reflect one another, that you should strive to optimize the whole IT process. This implies that development teams should work closely with your operations staff to deliver new releases smoothly into production and that your operations staff should work closely with development teams to streamline critical production issues.
DevOps has its source in agile software development, and it is an explicit aspect of the Disciplined Agile Delivery (DAD)
process framework. As a result there is a collection of agile development strategies which enable effective DevOps throughout the agile delivery lifecycle. These strategies include:
- 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.
- 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.
- 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).
- 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.
- 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.
- 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.
- 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).
- 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.
- Production release planning. This is the subset of your release planning efforts which focuses on the activities required to deploy into production.
- 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.
- 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.
There’s more to it though than simply adopting some good practices. Your process must also embrace several supporting philosophies. The Disciplined Agile Delivery (DAD)
process framework not only adopts the practices listed above, and more, but it also promotes several philosophies which enable DevOps:
- Delivery teams should be enterprise aware, that they should work with people such as operations staff and enterprise architects to understand and work towards a common operational infrastructure for your organization.
- Operations and support people should be recognized as key stakeholders of the solution being worked on.
- The delivery team should focus on solutions over software. Software is clearly important, but we will often provide new or upgraded hardware, supporting documentation (including operations and support procedures), change the business/operational processes that stakeholders follow, and even help change the organizational structure in which our stakeholders work.
- Your process should include an explicit governance strategy. Effective governance strategies motivate and enable development teams to leverage and enhance the existing infrastructure, follow existing organizational conventions, and work closely with enterprise teams – all of which help to streamline operations and support of the delivered solutions.
For more detail about this topic, I think that you will find the article I wrote for the December 2011 issue of Cutter IT Journal entitled “Disciplined Agile Delivery and Collaborative DevOps
” to be of value.
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.
On Twitter one of the people that I follow recently tweeted in jest "I am waste". He had been tweeting about the problem that people will often pay consultants for their advice yet will not follow that advice once it's been provided (yet will often still keep paying for more advice). Perhaps in this situation his efforts were a waste, or perhaps the real issue was that the customer had a long learning process and hadn't yet come to the point where they were willing to act on the advice, we may never know. But I have to think that there are other situations where this person isn't a waste, regardless of his claims.
This got me thinking that something is a waste in one context yet in another context may be quite valuable. Or, as the old saying goes, one man's trash is another man's treasure.
For example, consider the following simple value stream:
[Activity A: 10 min] [Wait time: 20 min] [Activity B: 10 min]
Without considering the context, the wait time of 20 min represents 50% waste in the overall process that we should try to eliminate.
What if that wait time provides people with a much needed rest? With time to contemplate? With time to destress? Eliminating that wait time, or even reducing it, could result a degradation of performance. In this case, one person's waste (the wait time) is another person's treasure (rest time). The implication is that we need to work closely with the people intimately involved in a process if we're to help them to improve it.
I've been getting a lot of questions lately about applying the acceleration metric
in practice. So, here's some answers to frequently asked questions:
1. How do I monetize acceleration?
This is fairly straightforward to do. For example, assume your acceleration is 0.007 (0.7%), there are five people on the team, your annual burdened cost per person is $150,000, and you have two week iterations. All these numbers are made up, but you know how to calculate acceleration now and IT management had darn well better know the average burdened cost (salary plus overhead) of their staff. So, per iteration the average burdened cost per person must be $150,000/26 = $5,770. Productivity improvement per iteration for this team must be $5,770 * 5 * .007 = $202. If the acceleration stayed constant at 0.7% the overall productivity improvement for the year would be (1.007)^26 (assuming the team works all 52 weeks of the year) which would be 1.198 or 19.8%. This would be a savings of $148,500 (pretty much the equivalent of one new person). Of course a 20% productivity increase over an entire year is a really aggressive improvement, regardless of some of the claims made by the agile snake oil salesman out there, although at 10-15% increase is a reasonable expectation. What I'd really want to do is calculate the acceleration for the year by comparing the velocity from the beginning of the year to the end of the year (in Western cultures I'd want to avoid comparing iterations near to the holidays). So, if the team velocity the first week of February 2008 was 20 points, now the same team's velocity the first week of February 2009 was 23 points, that's an acceleration of (23-20)/20 = 15% over a one year period, for a savings of $112,500.
2. Is acceleration really unitless?
For the sake of comparison it is. The "units" are % change in points per iteration, or % change in points per time period depending on the way that you want to look at it. Because it's a percentage I can easily monetize it, as you see above, and use it as a basis of comparison.
3. How do I convince teams to share their data?
This can be difficult. Because acceleration is easy to calculate for agile teams, and because it's easy to use to compare teams (my team has .7% acceleration whereas other teams down the hall from mine have accelerations of .3% and -.2% of teams), people are concerned that this metric will be used against them. OK, to be fair, my team might be OK with this. ;-) Seriously though, this is a valid fear that will only be addressed by an effective governance program
based on enablement, collaboration, and trust instead of the traditional command-and-control approach. Management's track record regarding how they've used measurements in the past, and how they've governed in general, have a great effect on people's willingness to trust them with new metrics such as acceleration. The implication is that you need to build up trust, something that could take years if it's possible at all.
4. Why does this work for agile teams?
Agile teams are self organizing, and an implication of that is that they will be held accountable for their estimates. Because of this accountability, and because velocity is a vital input into their planning and estimation efforts, agile teams are motivated to calculate their velocity accurately and to track it over time. Because they're eager to get their velocity right, and because acceleration is based on velocity, there's an exceptionally good chance that it's accurate.
5. What about function points or similar productivity measures?
Function points can be calculated for projects being developed via an agile approach, or other approaches for that matter, but it's a very expensive endeavor compared to calculating acceleration (which is essentially free) and likely will be seen as a bureaucratic overhead by the development team. My rule of thumb is that if you're not being explicitly paid to count function points (for example the US DoD will often pay contracting companies to create estimates based on function point counts) then I wouldn't bother with them.
6. What about calculating acceleration for iterative project teams?
Iterative project teams, perhaps following Rational Unified Process (RUP)
, can choose to calculate and track their velocity and thereby their acceleration. The key is to allow the team to be self organizing and accountable for their estimates, which in turn motivates them to get their velocity right just like agile teams (RUP can be as agile as you want to make it, don't let anyone tell you differently).
7. What about calculating acceleration for traditional project teams?
In theory this should work, in practice it is incredibly unlikely. Traditional teams don't work in iterations where working software is produced on a regular basis, they're typically not self organizing, and therefore there really isn't any motivate to calculate velocity (even if they do, there is little motivation to get it right). Without knowing the velocity you can't calculate acceleration. If you can't trust the velocity estimate, and I certainly wouldn't trust a traditional team's velocity estimate, then you can't trust your acceleration calculation. So, my fall back position to calculate productivity improvement would be to do something like function point counting (which is expensive and difficult to compare between teams due to different fudge factors used by different FP counters) and then looking at change in FPs delivered over time.
8. How can I apply this across a department?
It is fairly straightforward to roll up the acceleration of project teams into an overall acceleration measure for a portfolio of teams simply by taking a weighted average based on team size. However, this is only applicable to teams that are in a position to report an accurate acceleration (the agile and iterative teams) and of course are willing to do so.
9. What does a negative acceleration tell me?
If the acceleration is negative then productivity on the team is going down, likely an indicator of quality and/or team work problems. However, you don't want to manage by the numbers so you should talk to the team to see what's actually going on.
10. What does a zero acceleration tell me?
This is an indication that the team's productivity is not increasing, and that perhaps they should consider doing retrospectives at the end of each iteration and then acting on the results from those retrospectives. Better yet they can "dial up" their process improvement efforts by adopting something along the lines of IBM Rational Self Check
As part of the Agile/Jazz event In Milwaukee on the 29th I'll be giving a talk about the realities of agile software development. The URL for the event is http://www.iconatg.com/lp/events/jazz/jazz_milwaukee.html and I hope to see you there.
- Scott[Read More
Modificado em por ScottAmbler
For several years now I've written various articles and newsletters on the topics of estimating and funding strategies for software development projects, and in particular for agile software development projects. Whenever I talk to people about agile software development, or coach them in how to succeed at it, some of the very first questions that I'll be asked, particularly by anyone in a management role, is how to fund agile software development projects. Apparently a lot of people think that you can only apply agile strategies on small, straightforward projects where it makes sense to do a time and materials (T&M) approach. In fact you can apply agile strategies in a much greater range of situations, as the various surveys
that myself and others are showing time and again. My goal with this blog posting is to summarize the various strategies for, and issues surrounding, the funding of agile software development projects.
There are three basic strategies for funding projects, although several variations
clearly exist. These strategies are:
- "Fixed price". At the beginning of the project develop, and then commit to, an initial estimate based on your up-front requirements and architecture modeling efforts. Hopefully this estimate is given as a range, studies have shown that up-front estimating techniques such as COCOMO II or function points are accurate within +/- 30% most of the time although my July 2009 State of the IT Union survey found that on average organizations are shooting for +/- 11% (their actuals come in at +/- 19% on average, but only after doing things such as dropping scope, changing the estimate, or changing the schedule). Fixed-price funding strategies are very risky in practice because they promote poor behavior on the part of development teams to overcome the risks foisted upon them as the result of this poor business decision. It is possible to do agile on a fixed budget but I really wouldn't recommend it (nor would I recommend it for traditional projects). If you're forced to take a fixed-price approach, and many teams are because the business hopes to reduce their financial risk via this approach not realizing that it actually increases their risk, then adopt strategies that reduce the risk.
- Stage gate. Estimate and then fund the project for given periods of time. For example, fund the project for a 3-month period then evaluate it's viability, providing funding for another period of time only to the extent that it makes sense. Note that stages don't have to be based on specific time periods, they could instead be based on goals such as to intiate the project, prove the architecture with working code, or to build a portion of the system. Disciplined agile methods such as Open Unified Process have built in stage-gate decision points which enable this sort of strategy. When the estimation technique is pragmatic, the best approaches are to have either the team itself provide an estimate for the next stage or to have an expert provide a good gut feel estimate (or better yet have the expert work with the team to develop the estimate). Complex approaches such as COCOMO II or SLIM are often little more than a process facade covering up the fact that software estimating is more of an art or a science, and prove to be costly and time consuming in practice.
- Time and materials (T&M). With this approach you pay as you go, requiring your management team to actually govern the project effectively. Many organizations believe a T&M strategy to be very risky, which it is when your IT governance strategy isn't very effective. An interesting variation, particularly in a situation where a service provider is doing the development, is an approach where a low rate is paid for their time which covers their basic costs, the cost of materials is paid out directly, and delivery bonuses are paid for working software. This spreads the risk between the customer/stakeholder and the service provider. The service provider has their costs covered but won't make a profit unless they consistently deliver quality software.
The point is that there are several strategies for funding agile software development projects, just like there are several strategies for funding traditional software development projects. My experience is that fixed-price funding strategies are incredibly poor practice which increases the risk of your software development projects dramatically. I recognize how hard it can be to change this desire on the part of our business stakeholders, but have also had success changing their minds. If you choose to perservere, which is a difficult decision to make, you can help your organization's decision makers to adopt more effective strategies. Like you they want to improve the effectiveness of your IT efforts.Further reading: (In recommended order)
- Something's Gotta Give: Argues for a flexibly approach to funding, schedule, and/or scope.
- Agile on a Fixed Budget: Describes in detail how to take a fixed-price approach on agile projects.
- The Dire Consequences of Fixed-Price IT Projects: Describes in detail the questionable behavior exhibited by IT teams when forced to take a fixed-price approach.
- Is Fixed-Price Software Development Unethical?: Questions the entire concept of fixed-price IT projects, overviewing some of the overwhelming evidence against this really poor practice.
- Reducing the Risk of Fixed-Price Projects: Describes viable strategies for addressing some of the problems resulting from the decision of fixed-price projects.
- Strategies for Funding Software Development Projects: Describes several variations on the strategies described above.
- Lies, Great Lies, and Software Development Project Plans: Summarizes some results from the July 2009 State of the IT Union survey which explored issues related to project funding (among many).
Modificado em por ScottAmbler
The following diagram summarizes a safe and proven strategy for scaling agile delivery strategies at the team level. There are three features of this strategy:
- Basic agile and lean methods. At the base are methods such as Scrum, Extreme Programming (XP), Agile Modeling, Kanban, Agile Data, and many others. These methods are the source of practices, principles, and strategies that are the bricks from which a team will build its process.
- Disciplined Agile Delivery (DAD). Building on mainstream methods is the DAD process decision framework, providing an end-to-end approach for agile software delivery. DAD provides the process mortar required to combine the process bricks, effectively doing the “heavy lifting” to describe how all of these great agile strategies fit together.
- Agility at scale. Teams operating at scale apply DAD in a context driven manner to address the scaling factors that they face. These teams may be large, they may be geographically distributed in some way, they may face compliance constraints, they may be addressing a complex domain or technical environment, or they may be organizationally distributed in some manner. And usually combinations thereof. Without the solid foundation provided by DAD, agility at scale is incredibly difficult to achieve.
To scale agile successfully you must be able to tailor your approach to reflect the context that you face. To do this you must understand what your process and organizational structure options are and what tradeoffs each of those options has. Unless you’re a process expert, this can be challenging. This is where DAD’s process goal strategy comes in. Instead of prescribing a single way to do things, as we see in methods such as Scrum and SAFe, DAD instead captures your options in terms of process goals and guides you through making the decisions that best address the situation that you find yourself in. An example of a process goal diagram, in this case for the Inception phase goal Explore Initial Scope, is shown below.
The critical thing is that with a goal-driven approach it becomes much easier to understand how to scale agile. Depending on the context of the situation that a team finds itself in you will address each goal differently. The strategy for a small, co-located team facing a fairly straightforward situation in a non-regulatory environment works well for that team, the same strategy prescribed to a team in a different situation would put that team at risk of failure. Instead of prescribing a single way of working that is optimized for a specific situation we need to instead allow, and better yet enable, teams to adopt strategies that reflect the context of the situation that they face.
We’ve found that four of the twenty-two process goals seem to take about 80% of the tailoring impact. These goals are:
- Explore Initial Scope. This is sometimes referred to as initially populating the backlog in the Scrum community, but there is far more to it than just doing that. This is an important goal for several reasons. First, your team needs to have at least a high level understanding of what they’re trying to achieve, they just don’t start coding. Second, in the vast majority of organizations IT delivery teams are asked fundamental questions such as what are you trying to achieve, how long will it take, and how much will it cost. Having an understanding of the scope of your effort is important input into answering those sorts of questions.
- Identify Initial Technical Strategy. This is sometimes referred to as initial architecture envisioning or simply initial architecture modeling. You want to address this process goal for several reasons . First, the team should think through, at least at a high level, their architecture so as to identify a viable strategy for moving forward into Construction. A little bit of up-front thinking can increase your effectiveness as a team by getting you going in a good direction early in the lifecycle. It can also help to avoid injection of unnecessary technical debt as a result. Second, the team should strive to identify the existing organizational assets, such as web services, frameworks, or legacy data sources that they can potentially leverage while producing the new solution desired by their stakeholders. By doing this you increase the chance of reuse, thereby avoiding adding technical debt into your organizational ecosystem, and more importantly you reduce the time and cost of delivering a new solution as the result of reuse. You will do this by working with your organization’s enterprise architects, if you have any. This is an aspect of DAD’s philosophy of working in an enterprise aware manner.
- Move Closer to a Deployable Release. This Construction phase process goal is important for three reasons. First, it encompasses the packaging aspects of solution development (other important development aspects are addressed by its sister goal Produce a Potentially Consumable Solution). This includes artifact/asset management options such as version control and configuration management as well as your team’s deployment strategy. Second, it provides deployment planning options, from not planning at all (yikes!) to planning late in the lifecycle to the more DevOps-friendly strategies of continuous planning and active stakeholder participation. Third, this goal covers critical validation and verification (V&V) strategies, many of which push testing and quality assurance “left in the lifecycle” so that they’re performed earlier and thereby reducing the average cost of fixing any defects.
- Coordinate Activities. Although it is nice to believe that all of the coordination required by an agile team can be handled with a 15 minute stand up meeting every day the truth is far from that. This process goal addresses strategies for coordinating the work within a team, coordinating with other development teams (if needed), coordinating with IT groups such as your Enterprise Architects or data management group, and coordinating between subteams a programme or portfolio.
For a more detailed discussion of how these four process goals are the key to scaling your agile software delivery process, please refer to the whitepaper Scaling Agile Software Development: Disciplined Agile Delivery at Scale.
Modificado em por 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.
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.
The ASM distinguishes between three scaling
- Core agile development. Core agile methods, such as Scrum and Agile Modeling, are self governing, have a value-driven system development lifecycle (SDLC), and address a portion of the development lifecycle. These methods, and their practices, such as daily stand up meetings and requirements envisioning, are optimized for small, co-located teams developing fairly straightforward systems.
- Disciplined agile delivery. Disciplined agile delivery processes, which include Dynamic System Development Method (DSDM) and Open Unified Process (OpenUP), go further by covering the full software development lifecycle from project inception to transitioning the system into your production environment (or into the marketplace as the case may be). Disciplined agile delivery processes are self organizing within an appropriate governance framework and take both a risk and value driven approach to the lifecycle. Like the core agile development category, this category is also focused on small, co-located teams delivering fairly straightforward systems. To address the full delivery lifecycle you need to combine practices from several core methods, or adopt a method which has already done so.
- Agility at Scale. This category focuses on disciplined agile delivery where one or more scaling factors are applicable. The eight scaling factors are team size, geographical distribution, regulatory compliance, organizational complexity, technical complexity, organizational distribution, domain complexity, and enterprise discipline. All of these scaling factors are ranges, and not all of them will likely be applicable to any given project, so you need to be flexible when scaling agile approaches to meet the needs of your unique situation. To address these scaling factors you will need to tailor your disciplined agile delivery practices and in some situations adopt a handful of new practices to address the additional risks that you face at scale.
The first step in scaling agile approaches is to move from partial methods to a full-fledged, disciplined agile delivery process. Mainstream agile development processes and practices, of which there are many, have certainly garnered a lot of attention in recent years. They’ve motivated the IT community to pause and consider new ways of working, and many organizations have adopted and been successful with them. However, these mainstream strategies (such as Extreme Programming (XP) or Scrum, which the ASM refers to as core agile development strategies) are never sufficient on their own; as a result organizations must combine and tailor them to address the full delivery life cycle. When doing so the smarter organizations also bring a bit more discipline to the table, even more so than what is required by core agile processes themselves, to address governance and risk.
The second step to scaling agile is to recognize your degree of complexity. A lot of the mainstream agile advice is oriented towards small, co-located teams developing relatively straightforward systems. But once your team grows, or becomes distributed, or you find yourself working on a system that isn’t so straightforward, you find that the mainstream agile advice doesn’t work quite so well – at least not without sometimes significant modification. Each of the scaling factors introduces their own risks, and when addressed effectively can actually reduce project risk, and for your project team to succeed you will want to identify the scaling factors applicable to the situation that you face and act accordingly. Unfortunately, this is a lot easier said (OK, in this case blogged about) than done.
IBM Rational advocates disciplined agile delivery as the minimum that your organization should consider if it wants to succeed with agile techniques. You may not be there yet, still in the learning stages. But our experience is that you will quickly discover how one or more of the scaling factors is applicable, and as a result need to change the way you work.
I was recently in Bangalore speaking at the Rational Software Conference, which was really well done this year, and visiting customers. In addition to discussing how to scale agile software development approaches, particularly when the team is distributed geographically and organizationally, I was also asked about what I thought about a software factory approach to development. My instinctual reaction was negative, software factories can result in lower overall productivity as the result of over specialization of staff (I prefer generalizing specialists
), too many hand-offs between these specialists (I find close collaboration to be far more effective), and too much bureaucratic overhead to coordinate these activities. I initially chalked it up to these people still believing that software development was mostly a science, or perhaps an engineering domain, whereas my experiences had made me come to believe that software development is really more art than it is a science. Yet, the consistent belief in this strategy by very smart and experienced people started me thinking about my position.
Just let me begin by saying that this blog posting isn't meant to be yet another round in the age old, and relatively inane, "art vs. science" debate within the software development community. That debate is a symptom of versusitis
, a dread disease which particularly plagues the IT industry and which can any of us at any time. There is no known cure, although the combination of experience, open-mindedness, and critical thought are the best inoculation against versusitis that we have so far. In that vein, let me explore the issues as I see them and I will let you think for yourself.
On the one hand software development has aspects of being an art for several reasons. First, the problem definition is never precise, nor accurate, and even when we have detailed specifications the requirements invariably evolve
anyway. The lack of defined, firm requirements requires us to be flexible and to adjust to the situation that we find ourselves in. Second, teams typically find themselves in unique situations, necessitating a unique process and tool environment to reflect this (assuming that you want to be effective, otherwise there's nothing stopping you from having a "repeatable process" and consistent tool environment). Third, software is built by people for people, requiring that the development team have the ability to build a system with a user interface which meets the unique needs of their end users. One has only to look at the myriad UI designs out there to see that surely there is a bit of art going on. Fourth, if software development wasn't at least partially art then why hasn't anyone succeeded at building tools which take requirements as inputs and produce a viable solution that we can easily deploy? It's been over four decades now, so there's been sufficient time and resources available to build such tooling. Fifth, regardless of how much of a scientific/business facade we put over it, our success rate at producing up front detailed cost estimates and schedules speak for itself (see Funding Agile Projects
for links to articles).
On the other hand software development has aspects of being a science for several reasons. First, some aspects of software development have in fact been automated to a significant extent. Second, there is some mathematical basis to certain aspects of software development (although in the case of data-oriented activities the importance of relational theory
often gets blown way out of proportion and I have yet to see a situation where formal methods proved to be of practical value).
What does this have to do with Agility@Scale. As you know, one of the agile scaling factors
is Organizational Complexity, and cultural issues are the hardest to overcome. Whether your organization believes that software development is mostly an art or mostly a science is a cultural issue which will be a major driver in you choice of methods and practices. Organizations which believe that software development is more of a science will prefer strategies such as software factories, model-driven architecture (MDA),
and master data management (MDM)
. And there is ample evidence to support the claims that some organizations are succeeding at these strategies. Although you may not agree with these strategies, you need to respect the fact that many organizations are making them work in their environments. Similarly, organizations which believe that software development is more of an art will find that agile and lean strategies are a better fit, and once again there is ample evidence that organizations are succeeding with these approaches (there's also evidence that agile projects are more successful
than traditional projects, on average). Once again, you may not agree with these strategies but you need to respect the fact that other people are making them work in practice.
Trying to apply agile approaches within an organization that believes software development is mostly a science will find it difficult at best, and will likely need to embark on a multi-year program to shift their culture (likely an expensive endeavor which won't be worth the investment). Similarly, trying to apply a software factory strategy in an organization that believes that software development is mostly an art will also run aground. The bottom line is that one size does not fit all, that one strategy is
not right for all situations and that you need to understand the trade-offs of various strategies, methodologies, techniques, and practices and apply them appropriately given the situation that you face. In other words, it depends! If you are embarking on a software process initiative, and you don't have the broad experience required to effective choose between strategies (very few organizations do, although many believe otherwise), then you should consider Measured Capability Improvement Framework (MCIF)
to help increase your chance of success.
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.
A common misunderstanding about agile software development approaches are that they're only applicable to small, co-located teams. Yes, it's much easier to be successful with small teams, and with co-located teams, and as a result agilists being smart people prefer to work this way. After all, why take on extra risk when you don't need to do so? But, sometimes reality gets in the way and you find yourself in a situation where you need a large team, or you need to distribute your team (see previous blog postings for strategies for distributed agile development), and you would still like to be as agile as possible. The good news is that it's still possible to be agile with a large team, although you will need to go beyond some of the popular "agile in the small" strategies to succeed.
Here are some disciplined agile strategies to succeed at large-team agile:
- Question the need for a large team. Many times an organization will believe that they need a large team because their process is overly complex, because they're still organized for waterfall development, or simply because that's what they're used to. I've seen teams of 80 people doing the work of 20 as the result of over-specialization of job roles and all the bureaucracy required to organize and validate their work.
- Do some initial envisioning. In order to succeed the team must work together towards the same goals. This is true for small teams but doubly true for larger ones -- without a common vision chaos will quickly ensue. You must gain this common vision on two fronts: you need a common business vision and a common technical vision. To gain the common business vision you must do some initial, high-level requirements envisioning and to gain the common technical vision some common architecture envisioning. This isn't to say that you need to take on the risk of detailed, up-front specifications but you must at least have a high-level understanding of the scope and technical solution in order to move forward effectively. So, expect to spend the first few weeks of your project doing this initial modeling.
- Divide and conquer. You never have a team of 200 people, instead you have a collection of subteams that add up to 200 people. This is called having a team of teams.
- Align team structure with architecture. The most effective way to organize the subteams is to have each one implement one or more components, and thereby to build your overall system as a "system of systems". This reduces the coordination required because the majority of the communication will be within the subteams themselves. You'll still need to coordinate the subteams, that will never go away, but you can reduce the overhead (and the risk) by being smart about the way that you organize the people. A common mistake is to organize around job function (e.g. having architects in Toronto, developers in Raleigh, testers in Bangalore, and so on). This increases communication overhead and risk because these people need to work together closely to get something built.
- Project management coordination. Each subteam will have a team lead/coach, and these people will need to coordinate their work. There is often an overall project manager who leads this group. To coordinate the work within their subteam the team lead/coach will often have a daily meeting, in the Scrum method this is called a scrum meeting, where people share their current status and identify any problems they may be running into. To scale this effectively the team lead/coach attends a daily team coordination meeting, a scrum of scrums, where the same sort of information is shared at the overall team level.
- Product owner coordination. Similarly, each subteam has a product ownder, also referred to as an "on-site customer", who is responsible for making decisions about the requirements and for providing information to the team in a timely manner. Sometimes a single product owner will work with several subteams. The product owners will get together at the beginning of the project to do some requirements envisioning to identify the initial scope and to start portioning the requirements between the subteams. Because the requirements between the subsystems are interrelated and should be reasonably consistent, the product owners will need to meet on a regular basis to share information, to negotiate priorities, and to resolve requirements-related disputes.
- Architecture coordination. Each subteam will have an architecture owner, often a senior technical person and sometimes also in the role of the team lead/coach. These architecture owners will get together at the beginning of the project to do some initial architecture envisioning, based on the requirements envisioning efforts of the product owners. They will identify the major subsystems, and their interfaces, enabling the effective organization of the team into smaller subteams corresponding to the architecture. They will also get together regularly to evolve the architecture and to resolve any major technical issues.
- System integration team. For complex systems, which is often what large teams work on, an effective system integration effort is critical to your success. Although this may be easy at first, as the overall system evolves the need for a subteam focused solely on this quickly becomes apparent. This not only supports the development efforts of the subteams, it also supports independent investigative testing.
- Independent testing team. An independent testing team is common on mid-to-large size agile projects to enhance the testing efforts of the development subteams. This testing team will work in parallel to the developers, they get a new build on a regular basis (minimally each iteration, although more often is desirable), which they test in more advanced ways than what is typical with Test-Driven Development (TDD). For example, they often validate non-functional, quality of service (QoS) type requirements as well as technical constraints, things that often aren't captured well via user stories. They'll also do investigative testing to try to break the system by using it in ways not thought of by the product owners.
- Some specialties reappear. On larger teams it can make sense to have some people be a bit more specialized than what we normally see on small agile teams. For example, it's common to see people in the role of agile DBA, tech writer, build master, or user experience (UE) professional. More complex systems often require people in these roles, although it still behooves these poeple to not be pure specialists but instead to be generalizing specialists with a wider range of skills. Also, recognize that the reintroduction of specialists can be a slippery slope back to the bureaucracy of traditional software development.
At Agile 2009 in August Sue McKinney, VP of Development Transformation with IBM Software Group, was interviewed by DZone's Nitin Bharti about IBM's experiences adopting agile techniques. There are over 25,000 developers within IBM Software Group alone. Follow the link to the interview
to view it online (there is also a text transcript posted there. There's some great insights into the realities of scaling agile in large teams, in distributed agile development, and in particular how to transform a large organization's development staff.
I'm happy to announce that a revised version of the Lean Development Governance
white paper which I co-wrote with Per Kroll is now available. This version of the paper reflects our learnings over the past few years helping organizations to improve their governance strategies.
There's a more detailed description of the paper here
During 2007 Per Kroll and myself invested a significant amount of time development a framework for lean development governance. This effort resulted in a series of three articles that were published in Rational Edge and a recently published white paper. The articles go into the various practices in detail whereas the paper provides an overview aimed at executives. I also recently did a webcast which is now available online. The URLs are at the bottom of this blog posting.
Development governance isn’t a sexy topic, but it critical to the success of any IT department. I like to compare traditional, command-and-control approaches to governance to herding cats – you do a bunch of busy work which seems like a great idea in theory, but in the end the cats will ignore your efforts and stay in the room. Yet getting cats out of a room is easy to accomplish, as long as you know what motivates cats. Simply wave some fish in front of their noses and you’ll find that you can lead them out of the room with no effort at all. Effective governance for lean development isn’t about command and control. Instead, the focus is on enabling the right behaviors and practices through collaborative and supportive techniques. It is far more effective to motivate people to do the right thing than it is to try to force them to do so.
This framework is based on the philosophical foundation provided by the 7 principles proposed in the book “Lean Software Development” by Mary and Tom Poppendieck. The 7 principles are:1. Eliminate Waste. The three biggest sources of waste in software development are the addition of extra features, churn, and crossing organizational boundaries. Crossing organizational boundaries can increase costs by 25% or more because they create buffers which slow down response time and interfere with communication. It is critical that development teams are allowed to organize themselves, and run themselves, in a manner which reflects the work that they’re trying to accomplish. 2. Build Quality In. If you routinely find problems with your verification process then your process must be defective. When it comes to governance, if you regularly find that developers are doing things that you don’t want them to do or are not doing things that they should be then your approach to governance must be at fault. The strategy is not to make governance yet another set of activities that you layer on top of your software process but instead should embed into your process to make it as easy as possible for developers to do the right thing. 3. Create Knowledge. Planning is useful, but learning is essential. 4. Defer Commitment. You do not need to start software development by defining a complete specification, but instead work iteratively. You can support the business effectively through flexible architectures that are change tolerant and by scheduling irreversible decisions to the last possible moment. This also requires the ability to closely couple end-to-end business scenarios to capabilities developed in potentially several different applications by different projects. 5. Deliver Fast. It is possible to deliver high-quality systems fast and in a timely manner. By limiting the work of a team to their capacity, by not trying to force them to do more than they are capable but instead ask them to self-organize and thereby determine what they can accomplish, you can establish a reliable and repeatable flow of work. 6. Respect People. Sustainable advantage is gained from engaged, thinking people. The implication is that you need a human resources strategy which is specific to IT, that you need to focus on enabling teams not on controlling them. 7. Optimize the Whole. If you want to govern your development efforts effectively you must look at the bigger picture, not just individual project teams. You need to understand the high-level business process which the individual systems support, processes which often cross multiple systems. You need to manage programs of interrelated systems so that you can deliver a complete product to your stakeholders. Measurements should address how well you’re delivering business value, because that is the raison d’etre of your IT department.
Based on our experiences, and guided by the 7 principles, Per Kroll and I identified 18 practices of lean development governance. We've organized these practices into 6 categories:1. The Roles & Responsibilities category: - Promote Self-Organizing Teams. The best people for planning work are the ones who are going to do it. - Align Team Structure With Architecture. The organization of your project team should reflect the desired architectural structure of the system you are building to streamline the activities of the team.
2. The Organization category: - Align HR Policies With IT Values. Hiring, retaining, and promoting technical staff requires different strategies compared to non-technical staff. - Align Stakeholder Policies With IT Values. Your stakeholders may not understand the implications of the decisions that they make, for example that requiring an “accurate” estimate at the beginning of a project can dramatically increase project risk instead of decrease it as intended.
3. The Processes category: - Adapt the Process. Because teams vary in size, distribution, purpose, criticality, need for oversight, and member skillset you must tailor the process to meet a team’s exact needs. - Continuous Improvement. You should strive to identify and act on lessons learned throughout the project, not just at the end. - Embedded Compliance. It is better to build compliance into your day-to-day process, instead of having a separate compliance process that often results in unnecessary overhead. - Iterative Development. An iterative approach to software delivery allows progressive development and disclosure of software components, with a reduction of overall failure risk, and provides an ability to make fine-grained adjustment and correction with minimal lost time for rework. - Risk-Based Milestones. You want to mitigate the risks of your project, in particular business and technical risks, early in the lifecycle. You do this by having throughout your project several milestones that teams work toward.
4. The Measures category: - Simple and Relevant Metrics. You should automate metrics collection as much as possible, minimize the number of metrics collected, and know why you’re collecting them. - Continuous Project Monitoring. Automated metrics gathering enables you to monitor projects and thereby identify potential issues so that you can collaborate closely with the project team to resolve problems early.
5. The Mission & Principles category: - Business-Driven Project Pipeline. You should invest in the projects that are well-aligned to the business direction, return definable value, and match well with the priorities of the enterprise. - Pragmatic Governance Body. Effective governance bodies focus on enabling development teams in a cost-effective and timely manner. They typically have a small core staff with a majority of members being representatives from the governed organizations. - Staged Program Delivery. Programs, which are collections of related projects, should be rolled out in increments over time. Instead of holding back a release to wait for a subproject, each individual subprojects must sign up to predetermined release date. If the subproject misses it skips to the next release, minimizing the impact to the customers of the program. - Scenario-Driven Development. By taking a scenario-driven approach, you can understand how people will actually use your system, thereby enabling you to build something that meets their actual needs. The whole cannot be defined without understanding the parts, and the parts cannot be defined in detail without understanding the whole.
6. The Polices & Standards category: - Valued Corporate Assets. Guidance, such as programming guidelines or database design conventions, and reusable assets such as frameworks and components, will be adopted if they are perceived to add value to developers. You want to make it as easy as possible for developers to comply to, and more importantly take advantage of, your corporate IT infrastructure. - Flexible Architectures. Architectures that are service-oriented, component-based, or object-oriented and implement common architectural and design patterns lend themselves to greater levels of consistency, reuse, enhanceability, and adaptability. - Integrated Lifecycle Environment. Automate as much of the “drudge work”, such as metrics gathering and system build, as possible. Your tools and processes should fit together effectively throughout the lifecycle.
The URLs for the 3 articles:Principles and Organizations: http://www.ibm.com/developerworks/rational/library/jun07/kroll/Processes and Measures: http://www.ibm.com/developerworks/rational/library/jul07/kroll_ambler/Roles and Policies: http://www.ibm.com/developerworks/rational/library/aug07/ambler_kroll/
The URL for the white paper:https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-ldg
The URL for the webcast:https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=dw-c-wcsdpr&S_PKG=112907C[Read More