Agile and Agile Testing

Kaizania was invited to speak to a group of testers at Standard Bank recently on Agile and Agile Testing.

This was a really pleasant experience and the conversations we’ve had during the open session confirmed that Agile is an absolute need these days and not just something nice to attempt.

We all know that the role of the tester within Agile is very much neglected, however, we do determine that Agile is all about Quality and the different way to look at Quality.

In Agile we look at quality as Business Value Delivered over Total Cost and that there is absolutely NO TRADE-OFF to quality.

Anything not producing quality and value to your customer is believed to be waste. Who are the best people to assist you in determining waste? The Agile Tester is playing a big role in assisting you for sure!

In Agile we believe that quality is to be delivered by adopting a ‘whole team approach’, where the complete team, customer and developers are mutually accountable for quality.

This presentation provides an overview to how we got to what we call Agile and how Agile and Quality link to Agile Testing…

Download the presentation here: Kaizania: Agile and Agile Testing

Innovation vs Invention

While reading a recent post called  ‘Innovation as the lifeblood of any industry‘, it got me thinking… what is the difference between innovation and invention…

One always receive an overload of information on ‘Organisational Innovation’ etc, yet, while training and coaching organisations in South Africa on Agile as the best way to create an environment of invention, it seems like people confuse innovation with invention…

So here we go on the terminology ( from Dictionary.com )

‘Invention’
– an act or instance of creating or producing by exercise of the imagination

‘Innovation’
– the act of innovating; introduction of new things or methods

So, the difference is quite clear then…

In a Kaizania Whitepaper on the 3 eras of Work, we make the case for Agile in the Software Development world, which basically is that software development is all about invention, and to invent one need to create a culture of learning and acknowledge that people invent new things as only people can imagine and dream…that is the essence of Agile ( also read ‘Losing the Agile plot’ ).

So, the real difference between Innovation and Invention is that any organisation would need to build a culture of learning first in order for their people to invent, only then can they Innovate or introduce new things or methods.

On the other hand, can any organisation invent without innovating first?

Think about it, if Innovation is the introduction of new things or methods, then one would have to innovate and introduce new methods, like Agile, to enable the necessary culture of learning to enable Invention…

All this said, is this a case of which came first, the chicken or the egg?

Does it really matter?

I honestly don’t think so. What matters is to acknowledge that technology is not the problem, but people and how we interact with each other in order to innovate or invent…

The essence of Agile is to create an organisational culture of learning in order to invent, or create an ‘edge’… thats what it is all about…

As an organisation, ask yourself: Does my approach and process hinder learning or enabling learning?

Dependant on your honest answer, either innovate or invent, does not matter, just do whatever you have to do in order to enable learning!

Arrie van der Dussen

Agile Coach
Kaizania

DIY vs Shu-Ha-Ri

Over the past  years I have implemented and assisted many organisations with their own agile adoptions as an Agile coach, but also witnessed a lot of abused and misunderstood Agile implementations…

This caused me to actively get involved in evangelising Agile, the essence of Agile, Scrum, Kanban and to actively get the Agile industry and interested parties together to learn from each other… this culminated this week in the creation of Agile South Africa ( www.agilesa.co.za )

The concept is to create an environment to actively evangelise true Agile, to provide a forum for Agile DIY organisations to understand where they go wrong, to bring keen Agilists and people dipping their toes into Agile together to learn from each other…

But lets get back to the issue at hand – DIY Agile implementations vs Shu-Ha-Ri

Shu-Ha-Ri - stages of learning that lead to mastery

I have posted something similar before on the importance of Agile coaching, but found this fantastic article by Alan Atlas – DIY vs Shu-Ha-Ri

Read this great article….

Losing the Agile plot…

What is the essence of Agile?

This is the question any individual, team or organisation thinking of adopting agile needs to be able to answer first!

Too many agile implementations are based on tools and recipes, yes; Scrum / XP/ Kanban are agile tools. On their own, they won’t make you agile and focusing on the recipes and processes they prescribe on its own won’t bring you to the goal of extreme business value.

Coaching many teams and many organisations in South Africa and listening to the comments when training numerous organisations on Agile, it is clear to me as an Agile coach that individuals and organisations want the benefits of Agile, however, still want to grab a silver bullet like Scrum or XP or DSDM etc.

Agile tools won’t make you Agile, they are not silver bullets, they are purely tools to assist your agile implementation in a structured, well organised manner.

To really understand the issue at hand, we first need to admit that the problem we are faced today is people and not technology.

Once you admit this, then you can take the first step towards realising the benefits gained from an Agile approach.

A lot has been written on ‘Cargo-Cult Scrum’, I would like to take it further and name it ‘Cargo-Cult Agile’. This is where organisations or teams reach for Agile tools and hope that by following the simple rules and processes prescribed by that tool, that they will experience rapid benefits.

Then the organisation or team fails and keep failing and eventually they blame Agile, however, they never addressed the essence of Agile!

The problem we face is people, not technology!

Most organisations or teams implementing Agile have some debt to pay before they can even think of reaping Agile benefits, yet, most of the time, this debt is ignored and it’s an elephant in the room no-one wants to talk about, yet, everyone knows its there. Easier to ignore, than to admit the elephant is taking up all the space you need to be truly Agile…

So, when I talk about debt to be paid, what am I referring to?

3 types of debt:

Knowledge debt:

Agile is built around teams, yet teams can only perform as fast as the slowest member. The knowledge gap between individuals making up a team needs to be addressed and fast. This is where Agile tools do play a role with ceremonies like planning as a team, daily co-ordination meetings, reviews and retrospectives. Yet, by having these ceremonies without the true context of paying your knowledge debt, these ceremonies are again an empty shell without real value.

Technical debt:

The first thing to an Agile implementation is that Quality is non-negotiable. This usually sounds fantastic and provides everyone with a warm and fuzzy feeling; from now on we are only going to deliver high quality products and faster as we are now agile…

In reality the opposite is true, we work towards quality, but we deliver slower and this is due to technical debt…

Because of the quality standard which we will not negotiate on, there is no room for quick and dirty development, let’s face it, it is the quick and dirty development without proper refactoring which caused the technical debt in the first place…

An organisation or team would need to understand that they would need an aggressive approach to pay their technical debt as quick as possible. This will cause a dip in productivity during the first period, but the productivity will increase exponentially after a short time…

If there is no aggressive approach to paying technical debt, you will not produce higher quality faster and sustainably and then you will blame Agile…

Requirements debt:

Over time many organisation build up requirements debt. Requirements debt is all those things we never have time for, or the bug list we never get time to get through, or the loooonnnggg list of customer requirements we just don’t get to deliver.

Paying this debt is extremely important; this is why you want to embrace agile, isn’t it?

However, one cannot pay requirement debt effectively if one does not pay both knowledge and technical debt first. In other words, if you pay knowledge and technical debt, then you will be able to pay your requirements debt as your bug list will reduce and not grow as fast as it did, you will therefore have time to deliver customer requirements, you will deliver faster yet your quality will not reduce etc…

Summary:

Any agile implementation is not about tools and recipes and process, it’s about people and the way they communicate and collaborate, paying your debt and most of all establishing a culture or habit of always looking for ways to reduce waste and improve as a team and organisation.

This takes courage, great communication, fantastic collaboration, trust between all involved, loads of effective feedback, a habit of breaking everything down to its simplest form and an approach of testing yourself and the way you work against the agile principles!

So, what is the essence of Agile then?

The essence of Agile in short is to do whatever it takes to establish an effective learning culture and to adopt an effective approach and implement complimentary tools to support continuous learning on your projects and within your organisation.

Accept the essence of Agile first, then the rest will fall into place and you will not lose the agile plot by focusing on tools, ceremonies, artefacts etc, but rather embrace all that to support your culture of learning in order to effectively deliver extreme business value!

Regards

Arrie van der Dussen

Agile Business Manager / Agile Coach

Kaizania

agile@kaizania.co.za

Commercial Software development: The Agile Challenge

Developing custom applications using the Agile framework has proven itself to increase productivity and ensure that the business gets what adds most business value sooner rather than later.  The increased collaboration between the development team and business, together with the attention given to the prioritization of the work also reduces stress and allows business to take responsibility for , and feel in control of their destiny… a far cry from the experience in the waterfall world.

The Agile way of working allows increased transparency and really works well where the team is part of the organization for whom they are building the solution, but in a world where too many software projects have failed, there is a big challenge when a business wants to outsource development to a third party software developer using Agile methods.  The biggest problem is answering the following two questions:

• How much will it cost?
• How long will it take?

The correct Agile answer to the first question is:

It will cost less than predicted by the waterfall approach, and less than what it will cost as predicted by the time and materials based estimate, and you will pay just for what you need, built in the most efficient way possible and you can stop the moment when the needs are met.

The correct Agile answer to the second question is:

It will take less time than predicted by the waterfall approach, and less than what it will take as predicted by the time and materials based estimate, and you will get just what the business needs at the right level of quality, and you can stop the moment when the needs are met.

The reason why it is faster (and cheaper) is based on the following:

• All parties equally motivated to get it right – partnership
• Just in time Requirements
• Focus on Business value and priorities
• Open Communication and Transparency
• Productivity that leverage recent learning
• Process with flexibility and just enough formality (Lean)

Regards

Ben Cilliers

General Manager / Director
Kaizania