You are currently browsing the monthly archive for October 2009.
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
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
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
Well well well… this is probably the hottest issue to any agile implementation… most certainly the issue causing the most debate, emotions and pure frustration to any agile team!
Can one convince a team or individual to adopt points over hours, or hours over points?
Well, as an Agile coach I made the massive mistake of thinking that one could!
A few years on, I can now say, one can’t, there will always be a counter-argument to any argument you make… teams and individuals have been conditioned throughout the years NOT to think relative, but in hours… that is just the nature of the beast…
I found the best way to deal with this, in training and in coaching, is to divide the teams into two camps, points and hours, give them reading materials and articles, and let them present the case for either story points or hours… they will debate this one for hours, but its worth the time spent!
However, make sure they at least try relative estimation with Story Points, or let at least ONE team do that… once teams grasp the concept of relative estimation over ‘accurate’ hours, then the benefits will show and most teams will make the mindset change, not to say that one don’t get high-performing agile teams using hours… it’s a preference!
This works really well, and it stays true to what an Agile coach is supposed to do… present the issue, ask some provoking questions and provide the environment for the teams to actively and effectively communicate…
All this said, here is a fantastic article covering both Story points and Hours… http://www.infoq.com/news/2009/09/story-points-versus-hours
Note that we will be covering this subject in detail and in a fun way in our course, Agile Bootcamp planned for 7-8 October 2009! For more information, visit http://www.kaizania.co.za/agile/agile_bootcamp_registration.php
Innovation vs Invention
October 29, 2009 in Agile Commentary, Scrum Coaching, Scrum Implementation | Tags: adopting agile, agile values, coaching, consulting, implementing agile, implementing scrum, what is scrum? | by thinkingagile | Leave a comment
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