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.
Agility@Scale: Strategies for Scaling Agile Software Development
ScottAmbler 120000HESD Tags:  agility-at-scale disciplined-agile-deliver... agile e-book sdcf 11,449 Visits
ScottAmbler 120000HESD Tags:  culture disciplined-agile-deliver... antipattern agileadopt repeatability 7 Comments 11,432 Visits
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.
I'd like to leave you with this parting thought: Bureaucracy is bureaucracy and discipline is discipline, please don't confuse the two.[Read More]
ScottAmbler 120000HESD Tags:  business-analysis agility-at-scale scaling-agile domain-complexity agile sdcf 10,930 Visits
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,.
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.
ScottAmbler 120000HESD Tags:  goverance agility-at-scale lean agileexec whitepaper 10,580 Visits
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.
ScottAmbler 120000HESD Tags:  agileadopt disciplined-agile-deliver... training 1 Comment 10,347 Visits
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.
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.
ScottAmbler 120000HESD Tags:  modeling agility-at-scale agileadopt requirements 8 Comments 10,041 Visits
Contrary to popular belief, agile development teams do in fact model and yes, they even do some up front requirements and architecture modeling. Two of the best practices of Agile Modeling are Requirements Envisioning and Architecture Envisioning where you spend a bit of time at the beginning of the project doing enough initial modeling to get you going in the right direction. The strategy is to take advantage of modeling, which is to communicate and think things through without taking on the risks associated with detailed specifications written early in the lifecycle. In this blog posting I will focus on requirements envisioning, in a future posting I'll cover architecture envisioning.
The goal of initial requirements envisioning is to identify the scope of your effort. You need to do just enough modeling early in the project to come to stakeholder concurrence and answer questions such as what you're going to build, roughly how long it's going to take (give a range), and roughly how much it's likely to cost (once again, give a range). If you can get the right people together in the room, which can sometimes be a logistics challenge but not one that you couldn't choose to overcome, there are very few systems (I suspect less than 5%) that you couldn't initially scope out in a few days or a week. I also suspect that most of the remaining systems could be scoped out with less than 2 weeks of modeling, and if not then I'd take that as an indication that you're taking on too large of a project. I'm not saying that you'll be able to create big detailed specifications during this period, and quite frankly given the problems associated with "Big Requirements Up Front (BRUF)" you really don't want to, but I am saying that you could gain a pretty good understanding of what you need to do. The details, which you'll eventually need, can be elicited throughout the lifecycle when you actually need the information. A common saying in the agile community is that requirements analysis is so important for us that we do it every single day, not just during an initial phase. I'll discuss just in time (JIT) approaches to requirements modeling in a future posting.
To envision the requirements for a business application, you might want to consider creating the following models:
For small teams simple tools such as whiteboards and paper are usually sufficient for requirements envisioning. But what happens at scale? What if you're working on a large agile team, say of 50 people, 200 people (IBM has delivered software into the marketplace with agile teams of this size), or even 500 people (IBM currently has teams of this size applying agile techniques)? What if your team is distributed? Even if you have people working on different floors of the same building, let alone working from home or working in different cities or countries, then you're distributed (see my postings about distributed agile development). Suddenly whiteboards and paper-based tools (index cards, sticky notes, ...) aren't sufficient. You're still likely to use these sorts of tools in modeling sessions with stakeholders, but because of one or more scaling factors you need to capture your requirements models electronically.
In January Theresa Kratschmer and I gave a webcast entitled Agile Requirements: Collaborative, Contextual, and Correct which overviewed agile approaches to requirements elicitation and management, including requirements envisioning. We also showed how Rational Requirements Composer (RRC) can be used to electronically capture critical requirements information, enabling you to address the needs of large and/or distributed agile teams, while still remaining lightweight and flexible. I suspect that you'll find the webcast to be very illuminating and RRC something that you want to take a look at (the link leads to a trial version). Of course RRC can be used in other situations as well, but that's not what I'm focused on right now.
Teams which find themselves in regulatory environments will likely need to do more than just use RRC, as might very large teams. Regulatory compliance often requires more complex requirements documentation, which in turn requires more sophisticated tools such as DOORS or Requisite Pro, and I would consider using those tools in the types of situations that warrant it. One of the things that people often struggle to understand about agile approaches is that you need to tailor your strategy to reflect the situation at handle. One process size does not fit all, so you will end up using different tools and creating different artifacts to different extents in different situations. Repeatable results, not repeatable processes, is the rule of the day.
ScottAmbler 120000HESD Tags:  gdd scaling-agile agility-at-scale distributed teams 1 Comment 9,907 Visits
A common misunderstanding about agile software development is that it’s only for co-located teams. Things are definitely easier for co-located teams, and as I found with both the Dr. Dobb’s 2007 and 2008 Agile Adoption surveys (www.ambysoft.com/surveys/) co-located agile teams appear to have a higher success rate than distributed teams, Having said that, many organizations are in fact succeeding at distributed agile development.Modified by ScottAmbler
I’d like to share some strategies that I’m seeing work in practice, and in this blog posting summarizes generic strategies for distributed teams whether or not they’re agile. These strategies are:1. Do some up front planning. Distributed development is higher risk than co-located development, and one way to address that risk is to think things through. That doesn’t mean that you need to create a monolithic, 1000+ task Gantt chart, but it does mean that you should identify your major dependencies and milestone dates. Effective teams do this planning with the distributed developers actively involved (they are part of the team after all), they strive to consider all associated costs, and in particular they don’t overlook the low probability/high impact risks which often prove to be project killers.
2. Organize the team effectively. Once of the practices of Lean Development Governance (https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-ldg) is to organize your team structure around either your architecture or the lines of business (LOB) supported by the programme that you’re working on. Ideally each sub-team should be responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams. In other words, maximize the responsibilities of the “offshore” team(s) as much as possible. A very common mistake is to organize the subteams around job specialties – for example the architects are in Toronto, the developers in Mumbai, and the testers in Singapore – because to support this team structure you have to create a phenomenal amount of documentation to support communication between the teams.
3. Do some up front modeling. The implication of organizing your team around the architecture (or LOB) is that you also need to do a bit of architecture envisioning up front. Your architecture efforts should provide guidance regarding the shared infrastructure as well as critical development conventions such as coding guidelines and data naming conventions. Architecture envisioning is also a good idea for co-located agile teams too. See http://www.agilemodeling.com/essays/initialArchitectureModeling.htm for strategies to get the benefits of architecture modeling without the costs of needless documentation.
4. Recognize that communication is critical. GDD puts many barriers to communication in place, increasing overall project risk. To overcome these risks you will first need to be aware of them and act accordingly, and second, you’ll need to write more documentation than you would likely prefer. The risks associated with long-distance communication include cultural differences, time-zone differences, and the challenges with written documentation (which is the least effective way to communicate information). I make it a habit of asking open-ended questions so that I can determine whether or not the other people understand the topic under conversation. Particularly I will never ask a yes/no style of question because the simple answer of yes can mean a range of things depending on the culture. It may mean “Yes, I heard you”, “Yes, I understand what you’re saying”, or “Yes, I understand and agree with you”. When you’re dealing with people at other locations it’s good practice to ask them to summarize the conversation in writing, in particular to identify key action items and ownership of them, to ensure that everyone agrees with what was discussed. A good approach is to have the team lead on other end to do the summary so that they own it going forward.
5. Put a good technical infrastructure in place. Automate, automate, automate. In a GDD environment you need to work with collaborative multi-site tools such as ClearCase, ClearQuest, and Jazz Rational Team Concert (www.jazz.net) which enable you to share and evolve your work products (i.e. test scripts, code, documents) effectively.
In my next posting I'll describe a collection of agile-specific strategies for distributed software development teams.[Read More]
ScottAmbler 120000HESD Tags:  agile enterprise-agile disciplined-agile-deliver... 3 Comments 9,327 Visits
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:
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.
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]