Agile, Lean, Kanban, SCRUM, Continuous delivery have become buzzwords in the last few years. As always, when there is value behind an idea, people jump on the bandwagon and advertise themselves as experts in those ideas.

There are sales guys (no offence to people working in sales), who understand the idea and re-brand their services and products using the Agile principles as selling points. They know that customers like to hear certain buzzwords (collaboration, lean, customer value, empowerment, etc.) and they sell with these words without knowing much or without being interested in the outcome. But there are more people, full of enthusiasm for Agile, that want to share their experience and make organisations more successful.

And that enthusiasm is what I experienced at the LAST conference. Most of the presentations I attended were truly about sharing knowledge, pitching new ideas, emphasising lean/agile values. They were not about selling X software products or about offering coaching services. The people I met showed true interest. The whole conference had a “community gathering” feeling about it. The sponsors (like Elabor8) truly believe that they can “optimise the value of technology investment” or “align strategy and development so that releases deliver the most valuable features in your roadmap”.

One of the many reasons I like to be part of the Agile community in Melbourne, because it’s not about selling, it’s about sharing.

Why do you like to keep in touch with the people promoting agile / lean / etc. practices?

I’ve started my first project as an SCRUM master / iteration manager. With the help of lot of experienced people I ran an inception workshop (read more in an upcoming article) and started the solution selection with the team. However we had a lot of tasks on our wall that were not really providing business value. We had to gather information on certain solutions and prepare for the actual implementation. While we tried to write the cards in the usual “As a … I want to … So that…” format, the stories didn’t directly add business value (“As a user I want to know what is the best hardware so that I can achieve the business goals” just doesn’t cut it).

Then after reading some Agile literature, realised that we are creating spikes. Nothing wrong with them, they are necessary for projects (especially at the start). Here are a few definitions of spikes from the Internet:

“Spikes are a type of story that are used for activities such as research, design, exploration and even prototyping. The purpose of a spike is to gain the knowledge necessary to reduce the risk of a technical approach, better understand a requirement, or increase the reliability of a story estimate.” – Scaled Agile Framework, http://scaledagileframework.com/spikes/

“A story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve a technical question or a design problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog.” – The Agile Dictionary, http://agiledictionary.com/209/spike/

However, a technical task is not a spike – although quite often handled as one. Converting data or preparing an interface or developing a code will add business value – even if often it is not as clear.

What is your opinion: where does a task like ‘setting up infrastructure’ belong? Is it a task for a user story? Is it a spike? Should an activity like this be on the wall? Would like to hear your thoughts.