After my positive experiences with Extreme Programming in the 90s, I became curious about similar sounding approaches such as Scrum, Crystal, and DSDM. Digging into them, I distilled the common characteristics of these new methodologies: preferring adaptive planning to predictive planning, and treating people as more important to success than what process was used. In time these approaches gathered under the banner of agile software development, (and I revised the article) but I still find the perspective in this article a good way to understand the essence of agility.

Agile methods are solidly in the mainstream, but that popularity hasn't been without its problems. Organizational leaders are complaining that they’re not getting the benefits they expected. This article presents a fluency model that will help you get the most out of agile ideas. Fluency evolves through four distinct zones, each with its own benefits, required proficiencies, and key metrics.

As XP and other Agile methods gain popularity, questions are beginning to surface regarding how to scale XP beyond teams of 10-12 people. In mid February 2003 a workshop dedicated to the subject was held in Banff Alberta Canada. In this article we report on the keynote speeches from Ken Schwaber, and Martin Fowler, as well as other leading practitioners.

I hated carrots when I was growing up, hating the smell and texture of the things. But after I left home and started to cook for myself I started to like them. Nothing changed about the carrots, nor did my taste buds get a radical overhaul, the difference was in the cooking. My mother, like so many English people of her generation, wasn't a great cook - particularly of vegetables. Her approach was to boil carrots for twenty minutes or more. I since learned that if you cook them properly, carrots are a totally different experience.

This isn't a site about cooking, but about software development. But I find that often a technique or tool is like the poor carrot - blamed for being awful when the real problem is that the technique is being done incorrectly.

When people use the term 'software architect' they are using a metaphor from building construction to help people understand the architect's role.Ironically in doing this they misunderstand the actual role of a building architect.

There are various schemes of Code Ownership that I've come across. I put them into three broad categories:

Daniel Terhorst-North's recent blog post on software craftsmanship has unleashed a lot of blog discussions (which I summarize below, if you're interested). There's a lot in there, but one of his themes particularly resonated with me, hence this post.

Cycle Time is a measure of how long it takes to get a new feature in a software system from idea to running in production. In Agile circles, we try to minimize cycle time. We do this by defining and implementing very small features and minimizing delays in the development process. Although the rough notion of cycle time, and the importance of reducing it, is common, there is a lot of variations on how cycle time is measured.

Is it worth the effort to design software well?

One of two SoftwareDevelopmentAttitudes. The directing attitude says that since most developers aren't that good (it's rumored that almost 50% are below average) we need to direct the way they do things. This direction is to prevent them from causing harm to the system they are working on. Typically this attitude manifests itself in designs and tools that prevent developers from doing certain things, limiting what they can do to keep them away from complex areas.

One of two SoftwareDevelopmentAttitudes.The enabling attitude takes the view that developers are responsible professionals and so should be given the freedom to do whatever they need to do. Designs that follow this attitude should make things easy to use well but should assume that developers know what they are doing and thus not try hard to prevent something being used badly. As such these tools can be misused, but take the attitude that users should know better, and if they don't they deserve all they get.

A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is.

One of my favorite soundbites is: if it hurts, do it more often. It has the happy property of seeming nonsensical on the surface, but yielding some valuable meaning when you dig deeper

A maturity model is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance. In many circles maturity models have gained a bad reputation, but although they can easily be misused, in proper hands they can be helpful.

As regular readers of my work may know, I'm very suspicious of using metaphors of other professions to reason about software development. In particular, I believe the engineering metaphor has done our profession damage - in that it has encouraged the notion of separating design from construction.

As I was hanging around our London office, this issue came up in the context of Lean Manufacturing, a metaphor that's used quite often in agile circles - particularly by the Poppendiecks. If I don't like metaphoric reasoning from civil engineering, do I like it more from lean manufacturing?

One of the most difficult things for many people to understand about agile methods is the people orientation of agile. Those who are interested in agile processes all agree that process is a second-order effect on project success. The first value of the agile manifesto is that Individuals and Interactions are more valuable than Process and Tools.

When people think of code reviews, they usually think in terms of an explicit step in a development team's workflow. These days the Pre-Integration Review, carried out on a Pull Request is the most common mechanism for a code review, to the point that many people witlessly consider that not using pull requests removes all opportunities for doing code review. Such a narrow view of code reviews doesn't just ignore a host of explicit mechanisms for review, it more importantly neglects probably the most powerful code review technique - that of perpetual refinement done by the entire team.

You're sitting in a meeting, contemplating the code that your team has been working on for the last couple of years. You've come to the decision that the best thing you can do now is to throw away all that code, and rebuild on a totally new architecture. How does that make you feel about that doomed code, about the time you spent working on it, about the decisions you made all that time ago?

For nth, and I'm sure not last time, I'm sliding into a conversation about defining practices, labeling some of them as “best”, and probably the C-word (certification). It's a familiar discussion, and although we've barely started it, I can predict much of where it will go. It's driven by a perfectly reasonable desire to identify who are the better software developers, and how existing developers can improve their abilities.

SEMAT (Software Engineering Method and Theory) is an effort initiated by Ivar Jacobson, Bertrand Meyer, and Richard Soley. Its stated aim is to “refound software engineering based on a solid theory, proven principles and best practices”. Like many notorious people in the software world I was invited to participate. Thus far I've declined and feel the need to explain why.

Shu-Ha-Ri is a way of thinking about how you learn a technique. The name comes from Japanese martial arts (particularly Aikido), and Alistair Cockburn introduced it as a way of thinking about learning techniques and methodologies for software development.

Throughout my career, people have compared software development to “traditional” engineering, usually in a way to scold software developers for not doing a proper job. As someone who got his degree in Electronic Engineering, this resonated with me early in my career. But this way of thinking is flawed because most people have the wrong impression of how engineering works in practice.

Many debates in software development are underpinned by whether the speaker has a DirectingAttitude or an EnablingAttitude. These different attitudes affect choices over languages, designs, tools, processes, and lots more.

From time to time people question whether a particular specialty can be used incremental way: “You can't do (security | user interface design | databases | internationalization | * ) with an agile project because this aspect has to be done up front.”

This is the month for review of the IEEE's Software Engineering Book of Knowledge. This is an attempt to define the body of knowledge of our profession, in a way that can lay the groundwork for a licensed profession.

Timeboxed Iterations are a way to divide and schedule up the work on a project, particularly associated with agile software projects. The team breaks down the visible features of the software into User Stories, and breaks down time into fixed periods (e.g. one week), called iterations. They then schedule the stories by allocating them to the iterations. Stories are roughly estimated so that the team can figure out how many stories fit in an iteration.

One of the steady themes I've seen throughout my career is that of the nature and importance of software development. A few years ago a prospect told one of our salespeople that “software is like sewage pipes, I want it to work reliably and I don't want to know about the details”. This is the kind of approach that Nicholas Carr talked about in IT Doesn't Matter. On a contrasting note we've done work for many businesses where IT has been a clearer strategic enabler to their business, allowing them to enter new markets or significantly increase their market share. So is IT a utility, like sewage pipes, or a strategic asset?

In the software world, “waterfall” is commonly used to describe a style of software process, one that contrasts with the ideas of iterative, or agile styles. Like many well-known terms in software it's meaning is ill-defined and origins are obscure - but I find its essential theme is breaking down a large effort into phases based on activity.

CHAOS report says only 34% of projects succeed.

The Standish Group's CHAOS report has been talking of billions of wasted dollars on IT projects for many years. The 34% success rate is actually a improvement over 2001's figure of 28%. But what do we really mean by 'failure'?

Yagni originally is an acronym that stands for “You Aren't Gonna Need It”. It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because “you aren't gonna need it”.