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:
In Implementing Lean Software Development
, Mary and Tom
Poppendieck show how the seven principles of lean manufacturing can be applied
to optimize the whole IT value stream. These principles are:
- Eliminate waste. Lean thinking advocates regard any activity
that does not directly add value to the finished product as waste. The three
biggest sources of waste in software development are the addition of unrequired
features, project churn and crossing organizational boundaries (particularly
between stakeholders and development teams). To reduce waste it is critical
that development teams be allowed to self organize and operate in a manner that
reflects the work they’re trying to accomplish. Walker Royce argues in “Improving Software Economics” that the primary benefit of modern iterative/agile
techniques is the reduction of scrap and rework late in the lifecycle.
- Build in quality. Your process should not allow defects to
occur in the first place, but when this isn’t possible you should work in such
a way that you do a bit of work, validate it, fix any issues that you find, and
then iterate. Inspecting after the fact,
and queuing up defects to be fixed at some time in the future, isn’t as
effective. Agile practices which build
quality into your process include test driven development (TDD) and non-solo
development practices such as pair programming and modeling with others.
- Create knowledge. Planning is useful, but learning is essential.
You want to promote strategies, such as iterative development, that help teams
discover what stakeholders really want and act on that knowledge. It’s also
important for a team to regularly reflect on what they’re doing and then act to
improve their approach.
- Defer commitment. It’s not necessary to start software
development by defining a complete specification, and in fact that appears to
be a questionable strategy at best. You can support the business effectively
through flexible architectures that are change tolerant and by scheduling
irreversible decisions to the last possible moment. Frequently, deferring
commitment requires the ability to closely couple end-to-end business scenarios
to capabilities developed in multiple applications by multiple projects.
- Deliver quickly. It is possible to deliver high-quality
systems quickly. By limiting the work of a team to its capacity, which is
reflected by the team’s velocity (this is the number of “points” of
functionality which a team delivers each iteration), you can establish a
reliable and repeatable flow of work. An effective organization doesn’t demand
teams do more than they are capable of, but instead asks them to self-organize
and determine what they can accomplish. Constraining these teams to delivering potentially
shippable solutions on a regular basis motivates them to stay focused on
continuously adding value.
- Respect people.
The Poppendiecks also observe that sustainable advantage is gained from
engaged, thinking people. The implication is that you need a lean governance
strategy that focuses on motivating and enabling IT teams—not on controlling
- Optimize the whole. If you want to be effective at a solution you
must look at the bigger picture. You need to understand the high-level business
processes that individual projects support—processes that often cross multiple
systems. You need to manage programs of interrelated systems so you can deliver
a complete product to your stakeholders. Measurements should address how well
you’re delivering business value, because that is the sole reason for your IT
Lean thinking is important for scaling agile in several ways:
- Lean provides an explanation for why many of the agile
practices work. For example, Agile
Modeling’s practices of light weight, initial requirements envisioning followed
by iteration modeling and just-in-time (JIT) model storming work because they
reflect deferment of commitment regarding what needs to be built until it’s
actually needed, and the practices help eliminate waste because you’re only modeling
what needs to be built.
Lean offers insight into strategies for improving your
software process. For example, by
understanding the source of waste in IT you can begin to identify it and then
Lean principles provide a philosophical foundation for
scaling agile approaches.
- It provides techniques for identifying waste. Value stream mapping, a technique common within the lean
community whereby you model a process and then identify how much time is spent
on value-added work versus wait time, helps calculate overall time efficiency
of what you’re doing. Value stream maps are
a straightforward way to illuminate your IT processes, providing insight into
where significant problems exist. I’ve
created value stream maps with several customers around the world where we
analyzed their existing processes which some of their more traditional staff
believed worked well only to discover they had efficiency ratings of
20-30%. You can’t fix problems which you
are blind to.
One of the scaling factors
called out in the 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.
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.
Rolf Nelson recently recorded a short (5 min) podcast about IBM Rational
(RTC). RTC is a complete agile collaborative development
environment providing agile planning, source code management, work item
management, build management, and project health, along with integrated
reporting and process support. I've worked with RTC for a couple of years now and have been truly impressed with it. What should be of interest to many people is the Express-C version which is a free, fully-featured, 10-license version of RTC which can be easily downloaded from www.jazz.net
The SEMAT vision
has recently been posted online. SEMAT is short for Software Engineering and Method and Theory (SEMAT) and I am one of several signatories and a provider of input into the effort.
There are several reasons why I'm involved with SEMAT:
- The industry clearly needs something like this. Ivar Jacobson has been writing and speaking for awhile now about how our industry behaves in a similar manner to the fashion industry
-- we lurch from one cool idea (the fashion) to another and few of us
observe that the current fashion is often just a rehash of fashion(s) from the
- The right people are involved. The SEMAT initiative has
attracted a wide range of industry experts, including both the old
guard, the new "agile guard", and people in between. Arguably we may
be short a few people, the data community isn't well represented and
I'm not sure we have the systems community covered well, but we can
address those challenges in time.
We'll achieve something. We may not pull of the entire vision, but we
are going to produce something of value and I hope that it has a
positive impact on the industry. Time will tell.
I have several thoughts about the SEMAT vision
which I'd like to share with you:
- The vision is coherent. A lot of reasoned effort went into it's development as you can see when you read it.
- It will be a challenge to identify a non-trivial kernel. Even developing a kernel language will be hard as people will often stick to their preferred terms. For example, is it an iteration, a sprint, or a time box?
- Practitioners may not notice. It will also be a significant challenge to get practitioners interested in the SEMAT effort and more importantly to leverage the material. For example, the patterns community has a long history of producing great work which for the most part is ignored by the vast majority of practitioners, with the exception of a handful of the hundreds of patterns out there. So, although SEMAT is likely to produce some great ideas, will anyone care?
- Academics may not notice. I suspect that this will be less of a problem than practitioners not noticing, but it's still a possibility.
- Position papers from many of the signatories, including myself, will soon be published at the SEMAT site. Several non-signatories have been invited to submit papers as well.
- A workshop is being held in the third week of March in Zurich. At this workshop the people who published position papers will flesh out our ideas.
- I'll blog about these things as they occur.
Just like there are 5Ps of marketing, there are also “5 Ps” of IT:
- People. People and the way they work together have a greater effect on the outcomes of a project than the processes they’re following or the products (tools and technologies) that they’re using. People issues include having visible executive sponsorship, building an environment of trust, empowering staff, focusing on leadership as well as management, recognizing that the primary gating factor when improving processes is people’s ability to absorb change, and promoting a cross-discipline strategy at both the team and individual levels.
- Principles/philosophies. We’ve found both internally within IBM as well as with many of our customers that there is a need to define a common set of principles to provide a consistent foundation to enable effective teamwork and continuous process improvement. These principles help to guide people’s decisions when their processes and practices don’t directly address the situation which they find themselves in.
- Practices/patterns. A practice is a self-contained, deployable component of a process. You might find the IBM Practices interesting.
- Products. This includes the technologies – such as databases, application servers, networks, and client platforms – and tools such as integrated development environments, testing tools, and project planning tools used to create solutions for stakeholders.
- Processes. The previous 4Ps do not exist in a vacuum, we need some sort of glue to help piece all of this together. Minimally this glue is a lifecycle although more often than not it is a full process or method.
My experience is that to be successful at software process improvement (SPI)
across your entire IT department that you must address these 5Ps. How you address each issue, and to what extent, will vary based on your situation.
My January 2010 DDJ Agile Update, Tragic Mistakes When Adopting Test Driven Development (TDD)
, is now online. In the article I summarize what I consider to be common, and tragic, mistakes that I'm seeing organizations make when they attempt to adopt TDD.
These mistakes include:
The article also goes into potential benefits of TDD as well as potential challenges that you're face when adopting it.
As you may know I write the agile update newsletter for Dr. Dobb's Journal (DDJ)
. One of the things that I do for DDJ is run the "State of the IT Union" surveys to find out what IT professionals are actually doing in practice. I invite you to fill out the January 2010 edition of the survey at http://www.surveymonkey.com/s/StateOfITUnion
. The survey should take you about 5-7 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 ten copies of "The Art of Scalability: Scalable Web Architecture, Processes, and Organizations for the Modern Enterprise" by Martin Abbott and Michael Fisher published in December 2009 by Addison Wesley.
The results of this survey will be summarized in a forthcoming newsletter, most likely my March 2010 agile update. Furthermore, 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/
so 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 this resource.
On Tuesday, Dec 1, 2009 Philippe Kruchten
, Bruce MacIsaac
, and myself participated on two virtual panels about the future of the Unified Process (we did two to support callers from around the globe) for the Global Rational User's Group (GRUG)
. During the panel sessions we discussed a bit of the history of the Unified Process, some of the misconceptions people have with it, some of the common mistakes people made implementing it (instantiating it to be documentation heavy and/or serial) due to those misconceptions, how it can be very agile if you choose to instantiate it that way, the OpenUP
, the AUP
, how UP relates to the IBM Practices
, and other topics.
The links to the recordings are:
Hope you find it interesting. As I've written in the past, the RUP can be as agile as you want to make it. Furthermore, there are a lot of really good ideas in the RUP that the agile community can and should choose to mine, although sadly I see far too many teams doing things the hard way and reinventing the process wheel on their own. I hope they're enjoying themselves, because it clearly isn't a very efficient way for them to go about process improvement.