This post is, as the title suggests, about agile. More specifically it’s about a journey I made to rediscover what agile actually means to me. My need for rediscovery started while I was co-presenting a four-hour tutorial on Agile Testing at the TestNet autumn event recently. As one of my co-presenters was opening with an explanation of agile I felt the following smoldering unease creeping up inside of me.

“We’re talking about agile sure enough, but why is it I mostly hear Scrum, Lean and Kanban content passing by. How agile is that? And if it is not how bad is that?”

This post will therefore take you along the route I took to rediscover agile. It will contain some information on agile, and is a sort of personal recap. It is not intended as a complete and detailed overview of the agile approach and all of its derived methods and practices. Where ever I mention them however I will try to add a link to guide you to more information or interesting blogs. So feel free to use it, if nothing else, as your (re) introduction to agile if you like.

My original journey to agile started in 2007 and I will start once more at what was then my starting point. One of my colleagues came back from EuroSTAR 2007 and was enthusiastically talking about this new thing: Agile! I had heard about it before but had never really dug into it before. So like then I will go to where agile had taken off: the declaration of the Agile Manifesto in 2001. Seventeen people came together in a ski lodge and drew up a manifesto with the four following lines and guideline:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

This probably still is the best known part of agile there is. No self-respecting course will bypass these lines and not show them and declare them the essence of agile. Personally I think the manifesto, once read, makes sense to almost everybody who has been in IT for more than a couple of years. Their strength lies in stating something people sense but not always come to formulate themselves.

A lot of courses on agile do not go beyond this and do not also show the additional: “Principles behind the Agile Manifesto”. They jump straight to one of the methods and often enough without mentioning the principles at all. In my opinion this does not do justice to the manifesto as a whole. Therefore let’s have a look at these twelve principles. The seventeen authors of the manifest, who are also hardly ever mentioned, are part of the second part of this small series of post on agile. The third part will be on other prominent authors, like Lisa Crispin, and popular methodologies.

The Principles

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

As many of us have probably experienced, changes in requirements during development and even late in development is not new to software development. To accept and embrace these changes is certainly less common. This is one of the items that differentiates agile from other approaches. Other (more traditional) approaches either deny the existence of such possibilities, are unable to cope with them or try their utmost to abolish them.

• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

All software projects aim to deliver working software. The difference here is that agile projects aim to deliver more than once and to do so within a (far) shorter time span.

• Business people and developers must work together daily throughout the project.

Two elements in this principle provide direction into how business people and developers should work together. Those are to do it daily and to do it throughout the project. This combination I believe is typical to good software development in any approach. A lot of the other approaches have formalized so much however that to do so amounts in a breach of process, plan or protocol.

• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

In management theories this concept has been around for decades. For some reason however the application of these theories seems not so common place in the software development world. In this respect this principle sets the right mindset in creating self steering, responsible and trusted teams.

• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

This is a radical break to what is, or I rather would hope, was considered standard in software development. Still a lot of developers, testers and even more so managers and stakeholders consider it impossible to do without upfront and approved documentation. “How else would you know what to do.” Reality is that documentation hardly ever completely describes what the customer wants. Let alone that it completely describes how to build it. I can personally not think of a faster way to retrieve or confirm information then by asking the informant directly. And if anything needs to be recorded you can do that while talking together, in the code or on paper later.

• Working software is the primary measure of progress.

There is beauty in this principles simplicity. As a tester however I think it’s a bit to simple. What does that mean “working software”? Does the code run, does it pass all checks or is it tested also and do the customers find the value in product that they were looking for. The intent of this principle is good, but it needs enhancement on the concept of what working means in your context and to whom.

• Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I can only adhere to and promote this. I do realize however that it often is not on the mind of project managers. PM’s regularly still steer their projects on cost, time and scope using unfounded estimates that still have to be kept even when pushes personnel to their limits and over.

• Continuous attention to technical excellence and good design enhances agility.

I suppose this applies as an enhancement to all software development and therefore also to agile. If it actually enhances agility I am not so sure. The need for short sprints, iterations, cycles, or what you call them seems to work counterproductive here. (At least for the developers and architects I know.)

• Simplicity–the art of maximizing the amount of work not done–is essential.

In order to deliver the right content swiftly you should refrain from adding self thought up features or so-called enhancements. Unless the stakeholders or users are informed before and see them as adding additional value. Otherwise these items are likely to go in unnoticed, undocumented and untested. With all the risks that come with that. As to minimizing the work on agreed upon requirements I applaud the intent, but I think most developers start of to do their best and refactor when they see possibilities. In that sense it is wisely mentioned but if it really brings benefits in practice I have doubts about. (But I will get to this when I go into Lean later.)

• The best architectures, requirements, and designs emerge from self-organizing teams.

I totally agree with the idea behind this principle. Self-organizing teams are a good breeding ground for this. It should however not limit them to seek and accept expert input if this brings even better results.

• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The best way to handle your faults, or any experience, is to reflect and learn. This applies to teams as much as to individuals.

This concludes the first part in which I have travelled along the Manifesto and its twelve principles. I will continue (next week) with some info about the authors. Which is actually new to me as well, so that will be a journey into largely undiscovered country.

Ezelsbruggetje

Something intended to assist the memory, as a verse, acronym or formula.
“Ezelsbruggetje” is a Dutch word that roughly translates to Donkeys Bridge.
Its meaning however is similar to Mnemonic

Up until the Rapid Software Testing class in early June I was not really actively using mnemonics for testing. Come to think of it I am not even sure if , being a non-native English speaker,  I actually connected mnemonics to its equivalent Dutch word “ezelsbruggetje”. During Rapid Software Testing I got intrigued with the concept of using it for testing and after some intensified practical use I am growing more and more fond of the use of mnemonics. So much so that a week ago I came up with one myself.

It started when I was driving home after an Intervision session that I had organized at work and was kind of contemplating on how my testing skills are evolving in and outside of work. Eventually I concluded that the best things, for me, only come together if I work within a team-spirited group of people. I do not use the word team here on purpose, because I do not mean to talk about formally organized teams but any group of people coming together with a mutual and positive sense of  purpose and interests.

My Mnemonic

The next day I introduced my mnemonic to a colleague and besides the grin it produced he explained that he thought the idea was pretty good and the acronym would make sure it stuck. So now a another couple of days have passed and since I couldn’t find any similar mnemonic for teams I thought of sharing it with you.

Pirosmani-Donkey Bridge-The State Museum of Fine Arts of Georgia, Tbilisi

Skill – The ability to function within a group

For some people acting within a group comes natural but the rest of us can sharpen their skills by following courses, reading books or training. Following a training on effective communication or group dynamics can be very helpful here.

Experience – The amount of time actively spent as a member of a variety of groups

Skill can get you a long way, but in my opinion there is no substitute to actual use of your ideas and abilities in practice. Participation in different groups with different contexts is a good way to gain experience.

Knowledge – All facts, truths, descriptions or information that adds value to a specific group at a specific time

Different contexts requires different knowledge as the value of that  knowledge depends on its usefulness in that specific context. Understanding, or if it is not so obvious asking about the context in which you are in helps you to choose which knowledge you have adds value to the performance of your group. Off course having an extensive knowledge base is what can give you an advantage. Recently several good blog posts were published on education that can help you:

• So you think you can test – by Huib Schoots
• Alternative Paths for Self Education in Software Testing – by Markus Gärtner
• Good start for a junior tester – by Simon ‘Peter’ Schrijver

Service orientation – Willingness to use and share skill, experience and knowledge with others

Say you gained insight in effective communication, have been a member of dozens of teams and have learned your trade to the best of your ability. This all only benefits you and your team members if you are willing (and able) to use and share this with your team.

To do so there are two major hurdles to be taken. The first one is that you must want to share. I can think of a number of contexts where if you are any good in  the first three attributes this can give you a sort of informal power. If this is the case you will have to either overcome the fear of losing power or be able to see that this power is hollow and easily surpassed with the esteem you can get by sharing.

The second hurdle is of  a more personal nature. From personal experience I know that to use and share, or to help others do this, often sounds easier in theory than it is in practice. To do so you need to get out of your, figurative, cubicle, expose yourself and lose the fear of making mistakes in front of a group. So this takes guts and is more difficult for some than it is for others.

As a note it is probably wise to assure that, before you jump the hurdles,  your team is what I call a team spirited group and not only a group of people assigned to each other  by function, project or location with no other reference to each other

So if your context is open for it, the next time you apply or hire for a job think of my team mnemonic.

Skill
Experience
Knowledge
Service Orientation