Submissions for some of the key agile-related industry conferences are presently under review. I've read quite of few of these, and I've noticed that this year there are a number of submissions on the subject of how to manage non-functional requirements on agile software development projects. All offer different recommendations, but they have one thing in common: Each proposal is described as if it were The Answer to The Problem with non-functional requirements on agile projects. Is there really a single problem — The Problem? And if there is really a single answer — The Answer — then why so many different recommendations?
The truth is there isn't a one-size-fits-all answer. Those who recommend these various solutions are not wrong, and they are not trying to trick you. Each has achieved good results using whatever approach he/she is promoting. If they are wrong about anything, it's the assumption that their way is the only way. All the approaches have merit, and all have potential risks for a project. In keeping with the principle of people over process, it's up to you to understand the implications and make a reasoned choice. All the various conference talks, workshops, training courses, vendor products, and consulting advice are fine. Each will work, provided it is applied in an appropriate context and provided the team takes the potential downside risk into account.
Have you ever heard anyone say, "No matter what we try, nothing ever really changes?" I have. I've heard it enough that I had to wonder why. There are quite a few Magic Processes around that promise to solve all the problems of organizations that depend on software delivery to support their business. Proponents of each one are dead-certain their way is the only right way. All the others are wrong. It occurs to me that they are very much like the blind men who tried to describe an elephant. Their perception of just what problems organizations are facing and just how to address those problems are rather narrowly limited. There may be a second factor, as well: Any business enterprise or government agency is an organization of human beings. Process improvement frameworks and other types of Magic Bullets tend to treat human beings as if they were interchangeable machine parts. What if human organizations turn out to be somewhat more complex, and complex in different ways, than complicated mechanisms? Maybe we need an approach to organizational change that takes that into consideration.
If we "solve" a problem by painting over it rather than digging down to the root cause, we may institutionalize and "lock in" sub-optimal processes and practices, thus making it more difficult to achieve improvements of larger scope in future. This article explores that issue by by examining elements of software development that we consider "norms," identifying challenges that organizations are having in implementing these norms, seeing what they've done to meet the challenges, and then asking whether they have really solved the root cause of the problem or if they have merely implemented a tactical work-around for the problem. I call the challenges pain and the tactical work-arounds pain-killers. When the work-arounds become institutionalized and permanent, I think of it as a form of addiction. Just as the human body can become acclimated to pain-killers such that one experiences discomfort without the drugs, an organization can become acclimated to tactical work-arounds such that people start to think of the work-arounds as the "right way" to do things. The farther an organization goes down that path, the harder it is for them to get clean.
The Iron Triangle is not a dinner bell calling you to an all-you-can-eat smorgasbord. It never has been. Yet, it seems that most IT managers believe if they can just ring that triangle loud enough and long enough, they can get an arbitrary amount of scope completed on a fixed schedule with fixed resources. That won't change overnight. The belief in fixed Scope, Schedule, and Resources is a myth; myths are part of culture; cultural change is slow; and myths are among the last vestiges of an old culture to fade away. This article explains why schedule shifts and Death Marches are not the solution, and presents a practical approach for managing variable Scope.
A frequently-asked question these days is how the traditional, specialized roles conventionally associated with software development projects will change as organizations move toward an agile software development model. What is different, on an agile project, about roles like Business Analyst, QA Tester, DBA, network specialist, and so forth? What proportions of various specialists does a "typical" agile project need? Is there an optimum balance? I think these are the wrong questions. The question isn't how the old roles will change, but whether we need so many different specialized roles at all. I have an answer to propose, but I don't think it is an answer that will please everyone, or one that everyone will even accept.
Any software development project involves the development not only of user-defined features but also technical infrastructure, testing frameworks, and so forth. Agile project teams create user stories to track the development of the user-defined features. They should also create technical stories for the necessary technical development so the customer can see all the work involved in his/her project, in the interest of transparency. Unfortunately, some agile teams do not wish to present the customer with technical stories for one reason or another. Yet, they still have to explain why time was spent doing work not described in the user stories. They call it stolen time for lack of another category in which to track the time, but this creates another problem: How do they charge the customer for technical tasks that are necessary to complete the user stories? Sometimes the answer is billable stolen time, a contrivance that can lead customers to feel as if they are being charged for work that may not be directly related to the development of features, and that is not being tracked and reported in clear terms. In effect this violates the agile principle of transparency and can lead to serious problems with the customer relationship. This article follows a hypothetical development project in two ways: Once with technical tasks hidden under the heading of billable stolen time, and again with full transparency.
Many organizations that attempt to institutionalize agile or lean methods end up with a hybrid process that is not quite either. In the attempt to achieve the best of both lean and agile, they craft a process that cancels out the best and leaves them with the worst of both. It is such a common pattern that instructors of agile process courses often cite it as an example of what can go wrong when the purpose and proper application of agile and lean practices are not well understood. Agile consultant Kane Mar describes this process as an anti-pattern and names it the Staggered Iterative Waterfall 
. In this article, I explore some of the reasons why organizations slip into this anti-pattern despite their best intentions.
Enablement is one of the most powerful and most essential elements in successful Agile software development. Agile teams are largely self-organizing and self-managing. An enabled team makes many of the tactical decisions about a project autonomously. As we extend Agile practices to large IT organizations, one of the inhibitors is the difficulty traditional project managers have in letting go of old notions of "control" and letting their Agile teams work. In this article, I cite a military exercise called Millennium Challenge 02 that illustrates the importance of enablement for success in any situation that is inherently unpredictable and risky — a category that includes both warfare and software development.
When adaptive development was a new idea, it was applied to IT projects in a rather limited way. Today, the approach is far more mature, and can be used on many more IT initiatives. This article offers guidelines for choosing either an adaptive or a predictive approach based on the characteristics of any given project.
At the same time that IT organizations are learning to integrate Agile development practices with their other methodologies, companies are implementing statistical process control methods to improve the quality of their business processes. Six Sigma is the latest process control method to become widely used. How can the trend toward Agile development and the trend toward use of Six Sigma complement one another?
Originally associated with adaptive or Agile development, test-driven development (TDD) has become the method of choice for software engineers regardless of the development process followed on any given project. TDD at the unit and integration test levels is commonplace. This article considers the advantages of applying TDD at the level of functional testing, including simplification of project methodology, reduction of paperwork, and reduction of defects. A set of presentation slides is also available.
There is a lot to learn these days, and thousands of books to help us learn it all. But not all books are equally good. This article offers some tips for reading between the lines in book reviews and marketing blurbs to help you identify books that can help you learn about unfamiliar subjects.
How are RUP and XP similar or different? Are they equally suitable for Agile software development?
Thinking like a businessperson is fully consistent with Agile thinking.
How the concept of "reuse" has changed over the years, and how Agile development practices have influenced thinking about it.
How do we "sell" Agile software development to our organizations? Should we even try?