Agility@Scale: Strategies for Scaling Agile Software Development

This article has been replaced by an official "Disciplined Agile Manifesto".

 

The text of the original article remains below.

---------------------------------------------------------------------------------------

I've recently been working with Mark Lines of UPMentors and we've had some interesting discussions around evolving the Agile Manifesto which I thought I would share here to obtain feedback.  Note that this is not any sort of official position of IBM, nothing in my blog is by the way (unless explicitly stated so), nor is it some sort of devious plot to take over the agile world (although if we did have some sort of devious plot, we'd make the exact same claim).  What we hope to accomplish is to put some ideas out there in the hopes of getting an interesting conversation going.

Over the past decade we’ve applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so.  What we’ve learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations which we have applied agile and lean strategies in.  We believe that the changes we’re suggesting are straightforward:

1. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, we suggest that it should focus on solution delivery.
2. Where the original focused on customers, a word that for too many people appears to imply only the end users, we suggest that it focus on the full range of stakeholders instead.
3. Where the original manifesto focused on development teams, we suggest that the overall IT ecosystem and its improvement be taken into consideration.
4. Where the original manifesto focused on the understanding of, and observations about, software development at the time there has been some very interesting work done within the lean community since then (and to be fair there was very interesting work done within that community long before the Agile Manifesto was written).  We believe that the Agile Manifesto can benefit from lean principles.

Our suggested rewording of the Agile Manifesto follows, with our suggested changes in italics.

Updating the Values of the Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working solutions over comprehensive documentation
3. Stakeholder collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Updating the Principles behind the Agile Manifesto

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder’s competitive advantage.
3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Stakeholders and developers must work together daily throughout the project.
5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
7. Quantified business value is the primary measure of progress.
8. Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams. 

We’re agile – things evolve, including manifestos.  Looking forward to your feedback (add a comment).

 

Updates Since this Was First Published:

• February 2011: At the 10th Anniversary of the Agile Manifesto get together several people, including myself, brought up the idea of updating the Agile Manifesto.  Unfortunately the decision by the original writers of the manifesto was to adopt a very strict, non-agile change management approach where any changes to the manifesto would need the approval of all 17 of them.  So, pretty much zero chance of there ever being any changes (hence the lack of changes so far). 
• June 2012: This extension to the manifesto was retitled "A Disciplined Agile Manifesto" and published as in the book Disciplined Agile Delivery written by myself and Mark Lines.
• November 2012: Mark and I formed Scott Ambler+Associates.
• February 2013: The Disciplined Agile Consortium (DAC) is formed.  The mission of DAC is to evolve and support the Disciplined Agile Delivery (DAD) framework.
• April 2014: Official Disciplined Agile Manifesto posted on the Disciplined Agile Delivery (DAD) site.

Further reading:

• The Declaration of Interdependence (some other thoughts about, arguably, evolving the manifesto)
• Examining the Agile Manifesto
• Disciplined Agile Delivery website

 

 

 

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:

• High-level use cases (or user stories). The most detail that I would capture right now would be point form notes for some of the more complex use cases, but the majority just might have a name. The details are best captured on a just-in-time (JIT) basis during construction.
• User interface flow diagram. This provides an overview of screens and reports and how they're inter-related. You just need the major screens and reports for now.
• User interface sketches. You'll likely want to sketch out a few of the critical screens and reports to give your stakeholders a good gut feeling that you understand what they need. Sketches, not detailed screen specifications, are what's needed at this point in time.
• Domain model. A high-level domain model, perhaps using UML or a data modeling notation, which shows major business entities and the relationships between them, can also be incredibly valuable. Listing responsibilities, both data attributes and behaviors, can be left until later iterations.
• Process diagrams. A high-level process diagram, plus a few diagrams overviewing some of the critical processes, are likely needed to understand the business flow.
• Use-case diagram. Instead of a high-level process diagram you might want to do a high-level use case diagram instead. This is a matter of preference, I likely wouldn't do both.
• Glossary definitions. You might want to start identify key business terms now, although I wouldn't put much effort into settling on exact definitions. I've seen too many teams run aground on "analysis paralysis" because they try to define exact terminology before moving forward. Don't fall into this trap.

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.


Further reading:

• Agile Requirements: Collaborative, Contextual, and Correct Webcast
• Rational Requirements Composer
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)
• Agile Requirements Modeling
• Requirements Envisioning: An Agile Best Practice
• Examining the Big Requirements Up Front (BRUF) Approach
• DDJ's 2008 Modeling and Documentation Survey, which found that agile teams are more likely to model than traditional teams

[Read More]

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:

• The Discipline of Agile
• Measured Capability Improvement Framework (MCIF)
• Repeatable Results Over Repeatable Processes

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]

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:

• Lean Development Governance
• Examining the Agile Manifesto
• Norm Kerth's Retrospectives Home Page
• Measured Capability Improvement Framework (MCIF)

[Read More]

When you are first adopting agile techniques in your organization a common strategy is to run one or more pilot projects.  When organizing these projects you typically do as much as you can to make them successful, such as finding:

1. Projects where the stakeholders are willing to actively work with you.
2. IT people who are flexible, willing to try new things, and willing to collaborate with one another.
3. IT people who are generalizing specialists, or at least willing to become so.
4. Finding a project which is of medium complexity (therefore it's "real" in the sense that it's significant to your organization) but not one where it can make or break your organization (therefore it's safe to experiment with).

In North America we refer to this as "cherry picking" because you're picking the cherry/best situation that you can find.

Some thoughts:

1. Being agile may not have been the primary determinant of success.  You set up an environment where you have a good relationship with your stakeholders, where you have good people who want to work together, and the project is challenging but not impossible.  Oh, and by the way you adopted a few agile techniques as well.  Sounds to me that situation you could have adopted a few not-so-agile techniques instead and still succeed.  Although my various project success surveys, see my IT surveys page for details, have shown time and again that agile project teams are more successful than traditional project teams I haven't been able to tease out (yet) whether this success is attributable to agile or just attributable to improved project initiation efforts.
   
2. When adopting agile/lean widely across your organization, you can't cherry pick any more.  For the past few years I've been working with IT organizations that are in the process of adopting agile/lean strategies across their entire organization, not just across a few pilot projects.  What these organizations are finding is that they need to find ways to adopt agile where the business isn't as willing to work with IT, where some of the people aren't so flexible or collaborative, where some of the people are narrowly specialized and not as willing to expand their skills, or where the project exhibits scaling factors which motivates you to tailor your agile approach.  It's harder to succeed with agile in these situations because they're not as "cherry" as what you've experienced previously.  Luckily, if you've been successful previously then you now have some agile experienced people, you have successes to reference, and you've likely overcome some problems even in the cherry situations which you have learned from.  So, your cherry successes will hopefully improve your ability to succeed even in "non cherry" situations.
   
3. You need to work smarter, not harder. If the source of your success was actually from improved project initiation practices and not from agile, then recognize that and act accordingly.  Realistically part of your success was from that and part was from agile, and the organizations that adopt a measured improvement approach potentially have the data to determine which practices lead to success and which didn't.  Without the metrics you're effectively flying blind when it comes to deciding how to improve.  There is clearly a mandate for smarter work practices within IT, within your organization as a whole for that matter.
   

If you want to gain more insight into some of the issues that you'll face when adopting agile across your organization, I suspect that you'll find my recent paper Scaling Agile: An Executive Guide to be interesting.  I've got a more detailed paper in the works, so stay tuned to this blog.

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:

• Agile Criteria
• Agile Manifesto
• Rational's Agile Software Development Home Page (for webcasts, whitepapers, ...)

[Read More]

I'm often asked by customers for case studies of successful agile adoptions or agile projects in general. This is definitely a valid request, and yes, such case studies exist. But I'm often concerned that the people making these requests don't appreciate the implications of what they're asking for. My concerns with case studies are:

1. The juicy information is rarely included. The information that you really want to find out, such as what went wrong and why it went wrong, is rarely discussed. If problems, oops I mean "challenges", are discussed at all they're typically glossed over in favor of focusing in on the positives. Although many people want to write up the juicy bits this information is invariably edited out through the company's vetting process. In short, my advice is to take case studies with a grain of salt.
2. Some case studies are more fiction than fact. Although this isn't a problem with IBM case studies due to the governance efforts of my good friends in IBM's legal department (we love you folks, really) it can be an issue with some case studies.
3. The case study may no longer be true today. Stuff happens. Perhaps the case study was mostly true at the time it was written, but now that time has passed problems have appeared that weren't apparent earlier, thus the effort wasn't as nearly as successful as it was written up. For example, a few years ago I ran into the manager of a team that I had read about in one case study, only to find out that once the study was published the key team members left the company to become consultants in that subject area. Having lost these people, who were all very highly skilled, his system proved to be unmaintainable by the rest of his staff who weren't so highly skilled and had to be rewritten. Over time the success story turned into an abject failure.
4. Waiting for case studies puts you in the position of follower. For every case study that gets written, dozens, if not hundreds of similar efforts didn't get written up. Writing case studies is hard, takes time, and the writer seldom gets much benefit from doing so. The lag time between the project completing and the case study being published can be many, many months and sometimes years. The implication is that by the time you wait for several case studies that are similar to your situation you've pretty much lost all opportunity for competitive advantage and are now merely trying to catch up to the organizations who are clearly ahead of you (the writers of the case studies).
5. What has the requester given back to the community? I often hear people lament that there isn't enough case studies, or isn't something close enough to their situation. Yet, when I ask them how many case studies they've written and the answer is usually none. If you want to get you also need to give. ;-)

So, next time you think you need a case study before making a decision, recognize that you may be paying a fairly high opportunity cost for information that is questionable at best.
Further reading:

• Where's the proof that agile methods work?
• Rational's Agile Home Page

[Read More]

Test-driven development (TDD) is a common agile programming technique which has both specification and validation aspects. With TDD, you specify your software in detail on a just-in-time (JIT) basis via executable tests that are run in a regression manner to confirm that the system works to your current understanding of what your stakeholders require.

TDD is the combination of test-first development (TFD) and refactoring. With TFD, you write a single test (at either the requirements level with customer/acceptance tests or the design level with developer tests) and then you write just enough software to fulfill that test. Refactoring is a technique where you make a small change to your existing code to improve its design without changing its semantics.

TDD offers several benefits:1. It enables you to take small, safe steps during development, increasing programmer productivity.2. It increases quality. Agile developers are doing more testing, and doing it more often, than ever before. We're also fixing the problems that we find right on the spot.3. It helps to push validation activities early in the lifecycle, decreasing the average cost to fix defects (which rises exponentially the longer it takes you to detect them).4. Through single sourcing information, by treating tests as both specifications and as tests, we reduce the work required, increasing productivity.5. We leave behind valuable, up-to-date, detailed specifications for the people who come after us. Have you ever met a maintenance programmer who wouldn't want a full regression test suite for the code that they're working with?

But TDD isn't perfect. Although TDD is great at specifying code at a fine-grain level, tests simply don't scale to address higher level business process and architectural issues. Agile Model Driven Development (AMDD) enables you to scale TDD through initial envisioning of the requirements and architecture as well as just-in-time (JIT) modeling at the beginning and during construction iterations. To scale requirements-level TDD, you must recognize that customer tests are very good at specifying the details, but not so good at providing overall context. High-level business process models, conceptual domain models, and use cases are good at doing so, and these work products are often created as part of your initial requirements envisioning and iteration modeling activities. Similarly, to scale design-level TDD you must recognize that developer tests are very finely grained but once again do not provide overall context. High-level architecture sketches created during envisioning activities help set your initial technical direction. During each construction iteration, you'll do more detailed design modeling to think through critical issues before you implement them via TDD.

You also need to scale the validation aspects of TDD. TDD is in effect an approach to confirmatory testing where you validate the system to the level of your understanding of the requirements. The fundamental challenge with confirmatory testing, and hence TDD, is that it assumes that stakeholders actually know and can describe their requirements. Therefore you need to add investigative testing practices which explore issues that your stakeholders may not have thought of, such as usability issues, system integration issues, production performance issues, security issues, and a multitude of others.

For further reading, I suggest:1. My article "Introduction to TFD/TDD" at http://www.agiledata.org/essays/tdd.html which overviews TDD.2. My February 2008 column in Dr. Dobb's Journal entitled "Scaling TDD" at http://www.ddj.com/architect/205207998 which explores this issue in detail. 3. Andrew Glover's article "In pursuit of code quality: Adventures in behavior-driven development" at http://www.ibm.com/developerworks/java/library/j-cq09187/ which describes a new-and-improved take on TDD called BDD.[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]

1. Does the team regularly produce value for their stakeholders?
2. Does the team validate its own work to the best of its ability?
3. Are stakeholders actively involved?
4. Is the team self organizing?
5. Does the team strive to improve their process?

Some interesting results include:

• 94% of teams which are claiming to be agile are providing value to stakeholders on a regular basis.  
• 87% of teams which are claiming to be agile are validating their own work.  
• 95% of teams which are claiming to be agile are working closely with stakeholders.  
• 56% of teams which are claiming to be agile are self organizing. 
• 88% of teams which are claiming to be agile are improving the process that they follow throughout the lifecycle.  
• Teams which are claiming to be agile often aren't.  53% of "agile teams" meet the five criteria, although 72% meet all but the self-organization criteria.
• Teams which are moving towards agile but aren't there yet are reasonably close.  39% of those teams meet all five criteria and 63% meet all but self-organization.

• Whenever someone claims to be on an agile team you may want to explore that claim a bit deeper.
• The low level of self organization may be an indicator of cultural challenges with organizations in that their project managers aren't giving up sufficient control.  The Agility at Scale survey in November 2009 found that 59% of respondents who indicated that their organization hadn't adopted agile techniques yet that a rigid culture was hampering their efforts.  The IT Governance and Project Management survey in July 2009 discovered that "questionable behaviors", many of which were ethically questionable (I'm being polite), were far too common within IT project management.
• Although "agile teams" may not be as agile as they claim, they're still doing better than traditional V-model teams, as revealed (again) by the 2010 IT Project Success survey.
• If there was some sort of consensus within the agile community as to the criteria for determining whether a team is agile, I highly suspect that the agileness ratings would increase over time.  What gets measured often improves.
• However, how agile you are isn't anywhere near as important as getting better at what you're doing.  So perhaps I'm barking up the wrong tree on this issue.  ;-) 

The Scrum community has adopted a different set of terms than the other agile methodologies. This is done on purpose to help people realize that Agile approaches are different than traditional approaches, which can help in their adoption, but it can also hinder people's understanding because some of the terminology is not only non-standard it really doesn't make much sense. Because of this I'm often asked by people that I'm coaching to convert back and forth between terms, and recently wrote a detailed article on the subject. The following summarizes the mapping:

• Daily Scrum Meeting ==> Daily Stand-up Meeting
• Product Backlog ==> Work Item List
• Scrum Master ==> Team Lead or Team Coach
• Sprint ==> Iteration or Time Box

For more details read my article Translating Scrum Terminology which includes explanations of a wider range of Scrum terms and discussions of why some of them really are questionable.


Further reading:

• Translating Scrum Terminology
• Implementing Scrum Site
• Scaling Scrum
• Roles on Agile Teams

[Read More]

A common question that I keep running into with customers is whether you can take an agile approach to service oriented architecture (SOA). The quick answer is yes, because Agile is orthogonal to the implementation technologies used. You can take an agile approach developing COBOL applications running on mainframes, fat-client Java applications, multi-tier J2EE applications, and yes, even services. Granted, it's easier to do with some technologies than others, either because of the nature of the technology or because of the supporting tools.

The long answer is "yes, but". You don't adopt an SOA approach for the sheer joy of doing so, instead you very likely want to improve the level of reuse within your organization. To succeed at SOA-driven reuse you need an enterprise focus, something that doesn't appear to be very common on many agile teams. Therein lies the challenge. Several strategies for improving your chances with Agile SOA, and SOA in general, follows:1. Invest in some initial enterprise architecture modeling. You don't need to identify all of the details up front, that would take too long and actually put the effort at risk, but you do need to set a starting point to guide development teams. Identifying the technical architecture is critical, and identifying a few basic services which would provide immediate business value to one or more teams is critical. Involve people from several application project teams to ensure that you get a wide range of input. See http://www.agiledata.org/essays/enterpriseArchitecture.html for a streamlined approach to enterprise architecture modeling. Creating big, detailed models often proves to be a waste of time because development teams are rarely motivated to read mounds of documentation.2. Build out the initial infrastructure on a real application development project. This proves that your SOA strategy actually works and puts the technical foundation in place for future teams. During this period you'll be tempted to try to support several development teams, which is feasible but dramatically increases your risk. It's also tempting to focus simply on getting the infrastructure in place without delivering any business functionality, but this risks producing an ivory-tower architecture that nobody is interested in.3. Spread the service architects out onto application development teams. The people that formulated and then proved your SOA should be actively involved on the development teams that are working with it to ensure that the teams use it appropriately and to ensure that the architects get concrete feedback which they can use to evolve the architecture. When working on agile teams, these people will need to work in a collaborative and evolutionary approach just like other team members.4. Fund reuse separately. I've lost track of the number of organizations that I've run into that fail at reuse because their development teams never have the resources to develop reusable assets. That's simply the nature of the beast -- project teams will always be more interested in addressing their own specific requirements than they are in investing the time and effort to make something reusable. The real problem here is that you expect them to act differently. A better strategy is to have a separate reuse engineering team that has the resources to monitor existing projects to look for potentially reusable assets. When they find said assets this team does the work to harvest the asset, to reengineer it to make it reusable, and then to integrate back into the original source project. The goal is to make it as painless as possible to produce reusable assets such as services. If you expect project teams to do this work out of the goodness of their hearts then you're effectively punishing them when they do the right thing. That's not a very good governance strategy, IMHO.5. The reuse team now owns the asset. Any reusable asset, including services, will need to be maintained, evolved over time, and supported. This isn't free nor is it viable for project teams to do so.

If you're interested, I provide agile strategies for both enterprise architecture and strategic reuse in the book "Enterprise Unified Process". Although written under the assumption that you're taking a RUP-based approach to development, the reality is that the EUP can extend any evolutionary/agile software development process so that it addresses the larger-scale needs of modern IT organizations.

- Scott[Read More]

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]

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.

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:

1. "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.
2. 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.
3. 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)

1. Something's Gotta Give: Argues for a flexibly approach to funding, schedule, and/or scope.
2. Agile on a Fixed Budget: Describes in detail how to take a fixed-price approach on agile projects.
3. 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.
4. 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.
5. Reducing the Risk of Fixed-Price Projects: Describes viable strategies for addressing some of the problems resulting from the decision of fixed-price projects.
6. Strategies for Funding Software Development Projects: Describes several variations on the strategies described above.
7. 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).

[Read More]

I just wanted to share with you the Manifesto for Software Craftsmanship which extends the Agile Manifesto. The Manifesto for Software Craftsmanship states:As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration, but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
I view this manifesto as an important step in the maturation of software development. More on this in a future blog posting.[Read More]

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:

• Lean Development Governance
• Cultural Impedance Mismatch
• Measured Capability Improvement Framework (MCIF)
• The Discipline of Aglie

[Read More]

•  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
  

There is a distinct rhythm, or cadence, at different levels of the agile process. We call this the agile 3C rhythm, for coordinate, collaborate, and conclude (which is sometimes called stabilize). The agile 3C rhythm occurs at three levels in Disciplined Agile Delivery (DAD):

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

The agile 3C rhythm is similar conceptually to Deming’s Plan, Do, Check, Act (PDCA) cycle:

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

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

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

• Examining the Agile Manifesto 
• Reworking the Agile Manifesto for Enterprise Agile
• Scaling Agile: Start with a Disciplined Foundation
• Scaling Agile: The Software Development Context Framework
• Disciplined Agile Delivery (DAD) home page
• Generalizing Specialists: Improving Your IT Skills

Just like there are 5Ps of marketing, there are also “5 Ps” of IT:

1. 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.
2. 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.
3. Practices/patterns. A practice is a self-contained, deployable component of a process.  You might find the IBM Practices interesting.
4. 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.
5. 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:

• Not providing sufficient training, education, and mentoring
• Not supporting pair programming
• Not reducing the creation of non-executable detailed speculations early in the project
• Not reducing the confirmatory testing being done by their independent QA/testing team
• Completely reducing initial requirements envisioning and architecture envisioning
• Completely reducing parallel independent testing

The article also goes into potential benefits of TDD as well as potential challenges that you're face when adopting it.