Grasping Agility: “Done” & the Sisyphusian Condition


It’s a good feeling to be done with something,  but more than just a good feeling, it’s an essential feeling.

The problem with Agile adoption is that getting to truly “done” from wherever we started is often an astonishingly difficult thing to do. For decades software hasn’t needed to actually be done, ever really. Part of this is the nature of software, “finished” is just with a stage, a version, a patch, a piece of the whole larger thing we are building. Software is nearly always going to be Sisyphean.

Our initial reaction to this, as an industry, was to apply what we knew about project management to the problem: stages, waterfall, assembly line thinking. Software is typically too far into the realm of the Complex to work with such processes, and adding time to the mix just exacerbates the problem. Waterfall added a wonderful bureaucracy to software development that not only set goals so far out into the future that they were almost pointless, but gave us a way to avoid responsibility for what we did.

The idea that a developer can write barely functional code, and know that it will take so long to wind it’s way through the bureaucracy of off-shored test, that he may never have to deal with the fallout of his poor quality seems to me to be one of the most absurd aspects of the software industry. Yet, nearly every where I go when I bring this topic up most people will agree that they have experienced such a thing, as I have.

Is the developer a bad person for doing such a thing? Maybe, but probably not. When that developer never believes that the software will ever see the light of day, or if it does get release, matter to anyone, what motivation is there to do a good job? Even the best among us can’t stay motivated to excel at a project that we perceive to be never ending, and meaningless. Motivating the creative human is a complex thing, and something others can tell you about far better then I, but I can wrap this blog post up and bring us back to Done.

There’s a lot to Scrum that isn’t immediately obvious. One of these concepts that I believe may be the most important aspect for keeping ourselves and our teams productive is the Timebox, a device commonly used to override the negative effects of Sisyphean tasks, like chores around the house or building software. There are a lot of timeboxes in Scrum, the easiest to identify is the hard 15 minute limit on the daily Standup meeting, but to me the more important timebox is the Sprint itself.

A sprint is 2 weeks with a definite start, a set of clearly understood goals, and a clearly defined set of technical aspects that are expected to be finished at the end of that 2 weeks. When a team understands the work they are doing confidently enough that they can commit to finishing it in two weeks, we can fight the Sisyphusian condition.

In 2 weeks we will be Done. Our job is to do these things that we have committed to, then we are finished. That stone doesn’t roll very back down the hill when we stumble because we are periodically building walls behind it. Sure we move a little more slowly, but we progress, we finish. That’s a very motivating thing, being done.

However, if we aren’t completely finishing demonstrable features, which means tested, integrated, deployed, everything, we run the risk of letting that stone roll all the way back down the mountain. Maybe because of technical debt, or simply a bug we missed at the start of the project, the potential cost of undoing an old mistake far outweighs the cost of doing it right today.

How we go about defining the work to enable teams to do this is another topic, when it comes to this blog post I am done.

Caleb Brown

Caleb Brown is an Agile trainer, organizational coach, and Certified Scrum Professional with a focus on the the “People Side” of software. While practices and technology are part of what enable organizations to succeed with Agile, Caleb likes to concentrate on using the cultural piece supported by whatever practice, process, framework, or technology is needed to be successful. Having worked on the technical side of the software industry since 1999, and as CollabNet’s Product Owner and Master ScrumWorks Trainer since 2007, Caleb has gained deep insight into the inherent challenges with Agile adoption. His trainings and expertise in helping global organizations understand where process ends and tooling picks up, is well respected and highly sought after.

Tagged with: , , , , ,
Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *