The key to success?

I've been during last week in Tampere for the Nääsvillen Oliopäivät, or OO Days. The conference has been good, excellent talks during mornings (Alistair Cockburn, Pekka Abrahamsson and Jim Coplien) but way too many sales speeches in the afternoons, and no OO at all!

Alistair's keynote was about the few foundations that he founds crucial for software development and about properties of a successful teams. The first foundation he highlighted is that software development is a craft (quite surprisingly I had a conversation on the same topic with my friends Ari Tanninen and Marko Taipale while driving to Tampere the morning before the presentation). As a craft it has to be learnt, and about learning Alistair used a Japanese concept called Shu Ha Ri. It says that there are three stages in learning:

- Shu (traditional wisdom): you learn the basics of a technique, applying its rules blindly
- Ha (breaking with tradition): you reflect on the technique, finding exceptions to its rules and reflecting on them
- Ri (transcendence): everything is now natural, there's no need to think about the rules

I see that as really actual, and especially I see two big pitfalls coming out from that: people in Shu never leaving that stage and people in Shu trying acting as they would be in Ri without having the right knowledge and understanding.

For example, it's a very well known fact that the majority of projects using scrum fail. There's a good literature about that, and usually the causes are: teams sticking to what the book says, without adapting the scrum framework to their own needs (Shu people sticking there) or teams trying adapting the framework to their needs to early, when they don't yet understand it (Shu people acting as Ri).

After that and all the other talks my personal conclusion is that the key to success is not in tools, frameworks, processes and such. It's in people. And it can be summarized in one simple rule:

THINK!

Discipline and agile

Discipline

Most of the people while reading this word would think about the military discipline and never associate that with agile. It's quite funny that for many people being agile is mostly lacking discipline, while in my opinion it's impossible being successful in the agile world without discipline.

In the old days life in a software project was ruled by The Gantt, a simple diagram illustrating the start and end date of every activity in a project. Those dates were thought in the design phase of the project and defined by different people (usually the analysts) than the ones that were implementing the actual software. Developers were receiving a long and detailed frozen specification document from analysts and were then supposed to handover to a testing department the software they've realized.

Now let's think about the agile world as seen by someone used to work in the waterfall way: there are no separate phases (analysis, development, testing...) but just a small requirement gathering at the beginning of the project, maybe there aren't even strongly defined release dates, there's not even a project manager telling people what to do next: it sounds really awful! "How can those people work in that way? That's anarchy! They can just do whatever they want. How can they even know if they're on track?!?".

And now is when the discipline part plays an essential role!

The Manifesto for Agile Software Development says that working software is more valuable than comprehensive documentation, so an agile project doesn't have any big specification document or such, instead there's a list of feature the project should provide. A team without discipline could then think that instead of realizing those features one at a time they could go on in the old way and start doing horizontal development: "let's now start building the persistence layer, then let's add a business layer on top of it" and so on, maybe even parallelizing those developments without any kind of integration until everything is almost done. This would make impossible showing anything to the customer until the end, because everything would be 90% done. How can that team be sure that they're developing what the customer really wants?

A disciplined team would do something different: estimating the complexity of all the features and then start working on one of those at a time, maybe the project's most important, and implement it completely (from GUI to persistence for example). The team would then show the implemented features to the customer as soon as possible, in order to get feedbacks that would allow them to know if they're moving in the right direction or not. Knowing how complex a feature is and how much time did it take to realize if the project is on track, is falling behind or even if it's going better than expected. Making the daily work visible, maybe using a burndown chart, will immediately show how the things are going, allowing the team to take actions if things are not proceeding so well, but it requires a strong discipline (keeping always up to date the scrum board or kanban board for example), even if it would be easy sometimes to cheat and say that something not done is done "because there's time tomorrow to finish it".