Painting Over the Rust

Having Story Cards and Stand-Ups doesn’t make you Agile.

It is with a heavy heart that i watch the team descend into the latest form of chaos. Looking down on it now, i can see how we arrived here. One of the developers used the phrase “painting over the rust” to describe his dissatisfaction with the architectural decisions being made early on in the project. He was right, however what he didn’t know, was he was right on a number of levels.

I’ve struggled for some time with not being able to intelligently articulate what Agile software delivery is exactly. I hear lots of people repeating the the same old mantras, but for me, they lacked depth. Reciting the Agile manifesto to my grandmother isn’t going to help her understand what Agile software delivery is. I reason that if I don’t feel Able to describe it t my grandmother, how could i ever manage to explain it to the upper echelons of the executive?

Its not Agile, its fragile.

So the team has a story wall, and swim lanes and cards. Pretty standard stuff (actually the wall is further segmented by geographical location, because the team is split across two sites). Estimation is done planning poker style and points are points, pink elephants if you like, not days, or elapsed time (although we have worked out how much a point cost).

The team knows how many points we can get through the production line, and is comfortable managing the loss in throughput from context switching or working on new technologies etc.

We have a team made up of DEV pairs, QAs and BAs, and they understand what Agile software delivery is. They understand why we pair program. The developers are using TDD and we automate as much as we can using Continuous Integration. We have stand ups, retrospectives, iteration kick off meetings and showcases. We have brown bags and we use collaboration tools. We as a software delivery team have made the paradigm shift. But its still all buggered, why? Effectively, all we have done is painted over the rust.
The rust in our case is, (unfortunately) the executive. They don’t get it. Worse, yet i don’t think the product owners don’t get it, and in some cases i even wonder if the project managers get it. So what can we do?

We could shield the business from our internal workings. Let them treat us like a black box. They request function x, and we return a cost and an estimated delivery date. That way, they don’t have to get it, they don’t have to understand it, nothing changes for them, and the delivery team carries on irrespective. They then don’t need to learn about points or swim lanes or story cards or any other aspect of Agile. But the rust is still there, under the shiny new Agile paint, and its not going to go away, and left untreated it could get worse.

In the real world, there are only two real ways to treat rust. Cut it out, or blast it away. You can then replace the resultant hole with shiny new metal.Once the new metal is in place, its a good idea to apply a liberal coating of rust inhibitor.

Painting Over the Rust

Having Story Cards and Stand-Ups doesn’t make you Agile.

It is with a heavy heart that i watch the team descend into the latest form of chaos. Looking down on it now, i can see how we arrived here. One of the developers used the phrase “painting over the rust” to describe his dissatisfaction with the architectural decisions being made early on in the project. He was right, however what he didn’t know, was he was right on a number of levels.

I’ve struggled for some time with not being able to intelligently articulate what Agile software delivery is exactly. I hear lots of people repeating the the same old mantras, but for me, they lacked depth. Reciting the Agile manifesto to my grandmother isn’t going to help her understand what Agile software delivery is. I reason that if I don’t feel Able to describe it t my grandmother, how could i ever manage to explain it to the upper echelons of the executive?

Its not Agile, its fragile.

So the team has a story wall, and swim lanes and cards. Pretty standard stuff (actually the wall is further segmented by geographical location, because the team is split across two sites). Estimation is done planning poker style and points are points, pink elephants if you like, not days, or elapsed time (although we have worked out how much a point cost).

The team knows how many points we can get through the production line, and is comfortable managing the loss in throughput from context switching or working on new technologies etc.

We have a team made up of DEV pairs, QAs and BAs, and they understand what Agile software delivery is. They understand why we pair program. The developers are using TDD and we automate as much as we can using Continuous Integration. We have stand ups, retrospectives, iteration kick off meetings and showcases. We have brown bags and we use collaboration tools. We as a software delivery team have made the paradigm shift. But its still all buggered, why? Effectively, all we have done is painted over the rust.
The rust in our case is, (unfortunately) the executive. They don’t get it. Worse, yet i don’t think the product owners don’t get it, and in some cases i even wonder if the project managers get it. So what can we do?

We could shield the business from our internal workings. Let them treat us like a black box. They request function x, and we return a cost and an estimated delivery date. That way, they don’t have to get it, they don’t have to understand it, nothing changes for them, and the delivery team carries on irrespective. They then don’t need to learn about points or swim lanes or story cards or any other aspect of Agile. But the rust is still there, under the shiny new Agile paint, and its not going to go away, and left untreated it could get worse.

In the real world, there are only two real ways to treat rust. Cut it out, or blast it away. You can then replace the resultant hole with shiny new metal.Once the new metal is in place, its a good idea to apply a liberal coating of rust inhibitor.