Prioritise scope - don't cut it

In an agile project a lot of effort is spent in managing the scope of a release. But managing scope is not the same as cutting it. Managing scope includes adding and substituting work as well as removing it. Whereas cutting scope is an irreversible activity and hence a form of premature optimisation. (As experienced programmers know well, premature optimisation is the root of much evil.) Scope cutting fails to differentiate between "we don't think that this is important enough to do" and "we don't think that this is important enough to do now", and it promotes a binary view of the project (activities are "in scope" or "not in scope") that doesn't fit with the style of nimble decision making - and remaking - that agile processes allow.
Reflection: Do you keep track of the stories or features that are managed out of a release? Why? Would past scope management affect the planning for future iterations or releases?

Clearing out my backlog

I recently realised that I am trying to carry too much of a personal backlog: my head won't fit any more draft blog posts, code snippets, open source thoughts, or potential problem-solutions. So in accordance with the Lean Principles I decided to cut out some unneccessary work in progress. The first step is to get some of my "great unwritten blog posts" out into the open, and I may (or may not) revisit these ideas in the future...

Agile is not careless: one of the criticisms levelled at agile software development is that there isn't enough emphasis on planning. But agile teams are not careless: we do plan and replan frequently, in a low ceremony manner that values "the planning activity" more than "having a plan (and sticking to it)". A software team which does no documentation is not doing XP, and a team which does no replanning is not being agile.

Don't just throw people at the problem: throwing a team of good people at a problem and hoping that they will succeed in spite of any obstacles is far too wasteful. It's much better to proactively identify and overcome obstacles with some thoughtful agile project management instead.

Does testing need more domain-level scripting languages?: if FIT enables application test-scripting in a generic fashion, then what could be done with more specific domain-level scripting languages - especially if they incorporated some of these ideas on Situated Software?

Comparing agile methods to the CMM: rather than comparing agility and discipline (repeat after me, XP without discipline is a recipe for failure) I see it as an apples-and-oranges comparison between repeatable outcomes and repeatable processes...

The environment matters: According to this BBC News report cluttered desks make workers ill. And I thought that there were already enough reasons to pay attention to the work environment, given the morale and productivity-sapping effects of cube farms, open plan prairies, poor (or non-existent) air conditioning, cramped seating, and the like...

Think your design is good? The bar is higher now

This post to a forum on Artima.com illustrates how the application of Test-Driven Development techniques leads to better code. Michael Feathers wrote: Pick a class, any class, and try to instantiate it in a test harness. I used to think that my earlier designs were good until I started to apply that test. We can talk about coupling and encapsulation and all those nice pretty things, but put your money where your mouth is. Can you make this class work outside the application?
Reflection: if you can't make this class work outside the application then what are the reasons? How much work would it take to disentangle the class from this specific application?

A time to act and a time to think

Uncle Petros and Goldbach's Conjecture contains a passage that relates how for a mathematician to spend time away from the problem at hand is essential. Mentally to digest the work accomplished and process its results at an unconscious level requires leisure as well as exertion. In other words making progress requires more than the "application of perspiration" to the problem at hand. The spark of insight may come from "inside events", "outside events", or "other people" (for example a dream, the observation of an apple falling from a tree, or a chance conversation).
Professional mathematicians work in a way that reflects the nature of thought-work but unfortunately software teams often don't. To be most productive a developer requires time away from a keyboard and monitor, quietly reflecting or talking with colleagues. It can be hard for a client / sales / management representative to see the value being created in this time, but allowing developers the thinking time they need leads to higher quality work.
Reflection: What are the barriers to thought-time in your organisation? What forces or events caused those barriers to be erected? Can these forces be overcome in other ways?
(Thanks to Dave Farley for the conversation that stimulated this posting.)

Mistaken about mistakes

Broken build rituals are one way to instil good habits in a team that uses Continuous Integration. But the fact of the matter is that people make mistakes: it's part of what makes us human, as many authors and playwrights have explored. (You could argue that making mistakes is necessary to our development: my kids certainly learnt to walk by repeatedly falling over and then trying not to do so next time.*)
Seeking out the reasons why and how we make mistakes after we make them is hard to do. It requires humility and courage, attitudes that are hard to adopt if we are smarting from self-realisation or suffering from embarassment or guilt. But while we may feel that our mistakes are ours alone, it often turns out that the systems and processes within which we work have an enormous influence.
This is the ground occupied by Systems Thinking. Deming and others have made systemic examinations of the culture(s) of work, and describe ways by which our effectiveness can be improved by considering "the bigger picture". This article in particular really strikes a chord: Transformation of an organization, from one that resembles the "win-lose" environment of the "prevailing style of management" to one that is Deming-based ("win-win"), has been shown repeatedly to require systemic change. Vital to this transformation is "better thinking" by individuals in these organizations about systems, variation, knowledge, and psychology.

*Follow up: I just read this conversation with Luke Hohmann in which he says Humans are failure machines. We're not success machines. We're failure machines. We fail all the time. And it's only through processing the feedback of our failure that we learn how to correct for them and do better. That is why it is important to stick with the choices you make and understand how well they worked.

What agile means to me: what I do and who I am

My previous post was a bit of April Fool-ishness. But it made me consider a serious question: why am I such an advocate of Agile software development, and what would it take to make me change my opinion?
I think that there is both a simple and a complex answer.
The simple answer is that, in my experience, Agile software development works. I have been involved in many different projects, each of which had their own style, and those that were agile produced the best results, i.e. the most frequent delivery of working software with real business value. However my experience is just that, and my (re)collection of past events is not the same as anyone else's. As Mr Ed acerbically points out just because XP has worked for me this doesn't mean that XP will work for you. (His argument that because XP has not worked for him it can't work for anyone else is quite ridiculous though.)
The complex answer is that the values espoused in the Agile Manifesto (and by XP in particular) resonate with me at an emotional level: XP ain't out there, it's in here. My personal values certainly include feedback, communication, courage and simplicity and I enjoy working with others who feel the same. I find it both unpleasant and difficult to leave part of my self at the door as I arrive at work, something I know I have to do when working in a non-agile team. I work best in an environment where people treat others as they themselves would like to be treated, away from the arrogance of "architects" who feel that coding is for "monkeys", and away from the unthinking bullying style of management that is the opposite of leadership. What I do at work is more than manipulating symbols on a computer screen. Being who I am is about collaborating with others to solve practical problems (and expressing those solutions in a well-factored, readable, and test-exercised software system). It's quite a standard to live up to, but that is what being part of an agile project means to me.

Ok I admit it, Agile methods don't work

How could I (and many others) have been so mistaken? With hindsight it's obvious that a team could never collaborate to create working software without a plan to to tell them what to do and when to do it.Or without a complete set of Requirements Specification documentation, contractually approved by the customer in advance of any actual development. And how did I possibly think anything could be released without a long test-and-fix cycle first? It makes me shiver to think how dangerously irresponsible I was. But that's all behind me now: from here on I will only work in a CMM Level 5-certified environment.

Not ;-)