Currently there is a lot of discussion ongoing on the causes of failing agile teams. After watching these discussions for quite a while now, here is my view of the topic. The brief quint-essence is: If you’re doing crap, it doesn’t care whether you call it Agile or not – you’re just doing crap. If you’re doing a good job, it doesn’t care whether you call it Agile or not either – you’re just doing a good job. About a year ago I started to take a look on how Agile Software Development is done, especially under the circumstances of testing on Agile Teams. Since I realized that my company was struggling with delivery based on waterfall projects and non-cross-functional teams, Agile seemed to be a solution worthwhile to take a look on. Since introducing change in working habits is a large effort and I was not in a key position to introduce this, I started especially focused on the mind-set behind Agile Software Development and the sucess aspects of it. Incrementally I achieved to introduce changes based on the practices from XP – but for several reasons I was confident, that I could not introduce all aspects of it. Today I would say that I did not take the courage to just change stuff and come up with the success story afterwards.

The changes I started to introduce in my company where tiny. We were suffering from shell-scripted test automation, that was very interface-sensitive. A change in one of our software components could lead to a full regression test result disaster, our testing team being unable to give the stamp of approval on it safely. Manual testing was no practical option, since it would have lead to many weeks of efforts for that, but the bugfixes we had on our desk were critical for our customer. My team decided to reimplement test automation with a new approach and we decided to use FIT for it.

The next six weeks were spent focussing on the highest priority business use cases. We were able to build a new framework for testing on it. While I was reading The Art of Agile Development from James Shore and Shane Warden, I brought in many aspects of the practices and underlying principles and values into my team. Though we were not implementing the full set of practices, we were quite successful over the next few months and finally finished our energized efforts with a test framework, so that we were able to run our group during vacational time with just 1.5 persons, while we were unable to hold the pace one year before with 10 persons.

In the meantime one of my colleagues as well introduced a testing framework based on FIT but with a different approach. While my team used Java, his used Python. While my team focused on the readability of the tests from a business perspective reducing all visible test data to the necessary level of detail, his team put every little detail for the tests in there – whether they contributed to the expected results or not. From organizational point of view it was decided, that we needed to focus on just one programming for easier job advertisements. We came up with the solution to use Java as programming language, since most of our developers have either a Java background or are Java Developers. We started to move the previous Python classes to Java, without having the people introduced to Java beforehand. I did not that hard participate in the migration of the classes and see today that there is bunch of technical debt introduced. From my point of view there are two flaws that result from neglecting the craftsman aspect of our work: the table structure and the Java class code.

While I had read the book on FIT before starting to do anything, my colleague just started. Since he did not get the recommendations from people who have invented the framework and the problems they see on several topics, the tables are interconnected and while reading them I get a brain-twister. The second problem was, that we were forced to stick to the wrong table layout while getting the fixture code from Python to Java. As well since the people doing the work were new to Java, they did not come up with Pair Programming, Unit-Tests for the fixture code and no reusable design in the mind. Getting the toolset now ready for the next customer, will be an immense amount of work, if we agree to stick to the table layout, from my point of view.

The conclusion from that lesson for me is, that Robert C. Martin is of course right. With proper introduction to Java, JUnit and FIT the solution would be better today. We did not say, we were implementing Agile. We just focused on the parts of Agile, that helped us very much. The first approach from my side was a success, because we were simply doing a good job with future opportunities in mind and did just the necessary stuff skipping most of the YAGNI implementations. We were not doing Agile, we were not calling it Agile, we were just doing a good job. On the second step, we were not doing Agile, either. We were not calling it Agile, either. We were just doing a bad job, not paying attention to the skill-set of the people doing the implementation, not looking over the code before or even directly after submitting, no Pair Programming. We were doing a bad job, that’s it.

As stated intially, it does not matter, whether you do a good job and call it Agile or not, or whether you do crap and call it Agile or not. In either case you either succeed or fail, no matter what name you give that child.

Further reading:

• From Agile Development to the New Software Engineering (Column by Alistair Cockburn)

• How to Fail with Agile (article by Clinton Keith and Mike Cohn)

• Why can’t people deliver? (blog entry by Alistair Cockburn)

• Quintessence: The fifth element for the Agile Manifesto (blog entry by Robert C. Martin)

• Testers: The Hidden Resource (blog entry by Lisa Crispin)

• The Decline and Fall of Agile (blog entry by James Shore)

• Dirty Rotten ScrumDrels (blog entry by Robert C. Martin)

Lately I exchanged some thought with Alistair Cockburn on his new side over e-mail. Therein I introduced him to some thoughts that raised in my mind while reading through Agile Software Development – The Cooperative Game and Extreme Programming Explained and he told me to try the terms out for a while. Therefore I decided to introduce the thinking behind it for everyone. To introduce you in the topic I will first explore some definitions from the Extreme Programming (XP) and Agile world and try to relate them to the thoughts from the Cooperative Game.

Extreme Programming

This chapter describes the initial thoughts from Kent Beck on the relationship between practices, principles and values in XP. The initial of view of Kent are complemented with the thoughts from James Shore.

Practices

The XP practices build up a key set of actions to follow in order to get into the XP way of thinking. Practices are the entry point for teams new to XP. They build the first insights on how work is being done in the XP way of thinking. Practices are clear, so that everyone knows if they are followed. Practices are situated in that they just tell you what to do in a particular circumstance. They are not applyable in the rest of your life. In the second edition of Extreme Programming Explained Kent distinguishes between two levels of practices: the Primary and the Corollary.

The Primary Practices are introduced to get started right from scratch. These build up practices everyone should be able to start with right now without any dependence – beside the will to apply them. Among these practices there are advises like Sit Together, Whole Team, Pair Programming, Slack, Ten-Minute Build and Continuous Integration – just to name a few. The Corollary ones build up practices which might be difficult to implement without following the Primary ones. Among these there are Team Continuity, Code and Tests, Single Code Base or Daily Deployment.

Principles

As Mr. Beck describes in a wonderful picture, since practices and values are an ocean apart, principles build the bridge between them. The principles make the clear practices relate to the universal values. Principles make the XP team realise, why they are doing a particular practice and lead to the higher-level, universal values behind these. Among the XP principles there are Humanity, Mutual Benefit, Reflection, Flow, Quality or Baby Steps – just to name some examples.

Values

Values form the universal underlying part of the practices. XP values Communication, Simplicity, Feedback, Courage and Respect. The underlying value of communication, courage, respect and feedback highly motivate to apply sitting the whole team together as near as possible for example. The principle of humanity demands this. Without the values behind the practices, the latter would be tedious activities fulfilled just since it is denoted somewhere. Values form the motivating factor of the XP practices, while principles give reasons to apply them.

Agile

As Robert C. Martin wrote on Object Mentor summarizes how XP relates to the four Agile values and the twelve principles mentioned in the Agile Manifesto. Alistair Cockburn writes, that the people who signed the Agile Manifesto did not dare to go deeper into the materia and try to agree on common practices. Robert C. Martin perfectly describes, why the XP practices meet the Agile values and principles, but XP is just one of several applications of the Agile values and principles turned into practices.

The Cooperative Game

Alistair Cockburn introduces in the Cooperative Game the ShuHaRi levels of skillset development. The small words Shu, Ha and Ri are taken from the Aikido domain and Alistair maps them to the skillset in software development.

Shu

Shu means to keep, protect or maintain.

In the Aikido domain the Shu level is related to a student just beginning to learn the techniques. Therefore the Shu level is the entry point for new skills to learn. The student is taught to apply the techniques by copying them and follow the teacher’s advises by his words. The protection on the Shu level is to avoid early distraction of the student by the several existing techniques around. The student shall be able to focus on practical advises – on practices.

Ha

Ha means to detach and means that the student breaks free from the traditions.

After following the practices, the student starts to question the practices rather than doing just repetetive activities. At this second level it is realised what the underlying purpose of the initial teachings is. In the human grow-up process this stage could be compared to the puberty of teenagers, who start to question the practices they initially just copied from their parents and other children in their surrounding environment.

Ri

Ri means to go beyond or transcend.

On the third and last stage the student adapts the previously learned practices to meet his own style. While applying the principles she just became aware of, the underlying values are realised and followed.

Conclusion

Basically my current picture of Agile, XP and ShuHaRi consists of practices to follow on the Shu entry level of skillset development. When trying to get an Agile mindset, you need to start with particular practices on the Shu level. Since you just start to get into it, you need to learn the practices by the word in order to not get distracted by your previous working-habits and values.

On the Ha level there are principles which give you the reasons for particular practices. When the applications of the underlying practices got firm into your mindset, you will begin to question particular activities. You will only get to realise the underlying principles, if you have followed the practices on the Shu level long and thorough enough. This is the point in time when adaptation has taken roots. You should be now in place to see the larger picture behind your working-habits and be able to begin to change some of the details and try to fit variations of the practices to your particular circumstances. You should be able to start adaptation. For this phase to start it is essential to have followed the practices by the book – as strinkingly denoted in How To Fail With Agile.

After realizing what does work and what not through adaptation, you will be able to see the universal parts of your new skills. On the Ri level you will start implementing the values naturally without even thinking about them.

To conclude my proposal, the Ha level of skillset development builds a bridge between the Shu and the Ri level. On the Shu level you follow the practices by the book, on the Ha level you start to realise the underlying principles of the particular methodology you’re following and on the Ri level you see the whole world in values and start adapting your own style. This is the quintessence.

Outlook

Since I have a strong background in software testing, personally I would like to try to define practices on the Shu level, principles on the Ha level and values on the Ri level for software testers. Elisabeth Hendrickson, Lisa Crispin and Brian Marick did very good thoughts on the theses topics, but I have not seen the ideas structured as I tried to sketch here. If my proposal turns out to be valueable, this might become future work for Agilists.

Since I asked Alistair Cockburn to do a review of the text, he already was able to add a note on his blog on it. Thanks Alistair.