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

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

Agile Bootcamp public training completed!

Another 2-day course completed by Kaizania, Agile Bootcamp, last week in Centurion…

This was again a fantastic group of people, seems like the people who attend Agile training are always open-minded, eager to learn and active particants!

The companies represented, NuPay – JunkMail – Telamenta – Investec, made for good variety in opinions, experiences and organisational size and complexity!

We deviated a little bit from our previous course outline which was focused around Scrum, to a course outline focusing on laying the foundation of Agile first – Flexible Production Era (download the whitepaper here).

Then we covered Scrum, history and principles of Scrum, Scrum framework and all the roles, ceremonies and artefacts in detail.

Different to our previous courses, we introduced Kanban to the delegates as an Agile solution to service support development organisations and teams. We did this by playing a great game to illustrate Kanban and the financial effect thereof… What was nice to see was the teams actually embracing the concepts and principles discussed earlier from Lean, especially avoidance of waste!

Overall, a great success and a fantastic opportunity to spend time with eager Agilists!

Kaizania likes to think that we not only train and coach folks on our training courses, but that we also treat them a little bit… and we can truly say we did, what a fantastic venue for training at KleinKaap, and the food was fantastic!

A venue with style, warm and friendly service and absolutely great food! Well done all at KleinKaap!

Here is some feedback from JunkMail who were on the course:

“I found the course to be highly informative and enlightening with regards to a better PM approach, handling the demands of modern online business development. The course was very well presented and kept the flow going strong, making for a mentally sparking and invigorating experience.

I am confident that this will assist us significantly in our development team to minimise development time and maximise accountability among developers for their various tasks. The reduction in project specifications time is also a huge bonus to us.

Well done guys! I would recommend Kaizania training in a heartbeat.”

- Douglas Bailey, Internal Development Manager, JunkMail Publishing Group

Next course is planned, not yet confirmed, for mid-September… may you be interested, please send a mail to agile@kaizania.co.za or phone Arrie on 083 700 2181 and we can place your name and preferred dates on a list, which will help Kaizania to try and accommodate all as best as we possibly could!

Watch this space – Kaizania White Papers on the way

In helping organizations take full benefit of Flexible Production Era work practices, Kaizania is continually seeing how much organizations need to change in order to achieve the full benefit. Every now and then we summarize our learnings in a white paper.

It is that time again and here is an overview of white papers we are currently producing. We will post them soon as we are done, so watch this space!

Service Support and Kanban

IT departments everywhere are under continuing pressure to deliver excellent customer service to their customers – whether these be internal and/or external customers. The cornerstone of most organization’s approach to deliver has thus far been the combination of ITIL and a Help Desk system. The following are still significant problem areas not well covered by ITIL and a Help Desk system, which are very well addressed by introducing Kanban:

• Task visibility
  What is in progress? Information is available on Help Desk systems but there is no one single, public, visually rich view of what the work and service status is at any one time.

• Knowledge transfer
  Reducing knowledge “single points of failure” is a challenge – how to go about it? ITIL does not provide any real guidelines in terms of work practices to promote knowledge transfer

• Self organization and tasks
  How are tasks assigned to teams and individuals? Is there significant management overhead? How can a work environment be created where support teams have clear goals and self-organize to reach these goals?

• Continuous improvement
  How is a continuous improvement culture introduced, nurtured and soon turned into an ingrained habit for service teams?

• Process bottlenecks
  What is impacting a service team’s ability to reduce cycle time i.e. resolve service calls better and faster? Kanban makes it very clear and visible where process bottlenecks are occurring, and makes it very clear when and how service teams must act in order to resolve and permanently remove these bottlenecks.

We will introduce an integrated ITIL, Help Desk application and Kanban approach to delivering excellent customer service in one of our next White Papers.

Project and Portfolio Management in Service Organizations

The way in which IT projects and project portfolios are managed in service companies needs to change so much it is daunting.  The key problems with how service organizations currently work are:

1. Apparent control of risk and soundness of the project business case through significant upfront requirements gathering, detail task breakdowns and time and cost estimations – just a pity these detail plans are at best 50% correct – so much waste to maintain the comforting illusion of a perfect plan.
2. Inability to get a pilot off the ground – with so much upfront effort it is terribly difficult to be quick and exploit opportunities – innovators feel like they are working in mud….
3. Ensuring the “perfect plan” succeeds actually creates huge obstacles to learning and improving what is delivered – think change control board…. – must we really make it sooo difficult to ensure the best possible product or system is built in the shortest possible time, adapting as we learn more on exactly what we want and exactly how we build it?
4. “Efficient” resource allocation as project “teams” are continually broken up and formed – just a pity that writing software is akin to a team writing an epic poem under direction of the customer, requiring intimate knowledge of the subject matter, the capability of each team member, commitment and passion. It is very, very tough to do this with a new team every few months, or even every 2^nd day. Why not let the same team write more than one epic poem together? Surely they improve their creative ability over time….

We will summarize our views of the road ahead in one of our next white papers.

Kaizania – changing the way we manage projects, portfolios and creative people; bit by bit, day by day

Daily Stand-up – 3 questions or not?

Over the years using and implementing Scrum in organisations, I struggled sometimes with the value of the daily-standup…

Why did I struggle?

- The teams started off excited and it worked, however, as the adrenalin rush dissappeared, the daily stand-up became a drag, something they had to do with no excitement and not a lot of communication or team co-ordination

- By asking every member to come to the front and answer the 3 questions, there was no cohesive drive towards completing stories from the top ( prioritised ), people were all over the board and it was difficult to see what is what

- The communication as a team was not good, there was no hype, there was no excitement and no drive towards a mutually accountable goal at all…

The Solution

Well, this may go against the books and theory, however, it works for my teams…

I changed to ‘walking the board’, and a lot of Scrum practitioners are now doing the same…

I asked the team to communicate and co-ordinate collectively on each story, one at a time, from the top ( highest priority ) and talk through each story as a team…

The Result

It worked! I managed to solve 2 problems with this…

Problem 1: No effective communication and co-ordination as a team

Problem 2: Working all over the board, instead of delivering stories as a team from the highest priority first!

By walking-the-board we manage to solve both… the teams are now excited, they communication extremely well, the focus together as a team on their mutually accountable goal and the best is that suddenly they are holding each other accountable for that goal…

Since, I have used this regularly when I encounter the above mentioned problems… walking the board provides a Scrum Master or Coach with a method to mature an Agile team very fast…

Please go to http://agile-commentary.blogspot.com/2009/04/walking-board.html for another Agilist who did the same…

Kind regards

Arrie van der Dussen

Agile Business Manager

Kaizania

agile@kaizania.co.za