Agile has twelve Principles and the tenth one I find as probably the most profound. I have seen many teams struggling to understand this Principle. This Principle has some very generic words and some words which suggest certain aspects.
First of all it states ‘work’ and does not specify ‘stories’ or ‘requirements’ which a team is supposed to work on. Work is a very generic term and can be applied to anything that one is doing. Secondly it states ‘amount of work’ which means there has to be some estimate of work available. So it is not work that is not sized. And the next word is ‘maximizing’ – which means it is not a definite limit or number but kind of relative to the work itself. Finally it is an art and not science!
I tried to ponder upon this and thought of few instances where I myself had difficulty managing my time and work and thought why not try this Principle! I found it really makes a lot of sense. Some times we feel that as coaches this Principle applies to only requirements of a product and keep focusing on teams’ work in terms of requirements. But that is not all there is to this Principle. It can be applied to almost any work that one does. And work can be: stories being developed, bugs being fixed, enablers, impediments being solved, improvement opportunities being worked on and so on.
And not all work may be measurable. So how do I know the ‘amount of work’ on hand? And some of them can be never ending – say self-organization, commitment and so on. As a coach if I am working on improving the commitment of a team or the way they do estimations or applying INVEST to stories – all these are long term activities and one cannot say I am done with this and let me move on to the next. So identifying ‘work not done’ itself is a challenging task if one needs to maximize it.
I have tried to use this Principle in some aspects and have also coached few others.
For eg. while coaching teams that are new to Agile, the principle of simplicity can be applied as follows:
First focus on making the team understand the ceremonies and start using them then focus on time boxing the ceremonies. There again pick couple of them and then work on the rest. And then pick visibility or collaboration and all these are long term activities and breaking them and picking simple small steps at a time would make it easier for teams to adopt as well.
Improving collaboration in a team is again work that cannot be so easily fragmented. Maybe initially focus on few fun activities per month and then introduce activities that are a bit more serious and so on. I have actually tried this in a few teams and found it works very well. The catch here is that a coach should be with the team for a longer period of time. ‘Amount’ of work in this case can be arrived at using duration of sessions, complexity of activities, fun part in the activities and so on.
Similarly this Principle can be applied to many other kinds of work that we do as coaches and the same applies to a Scrum Master or a Product Owner or team members as well. I look forward to your experiences and valuable suggestions on this blog.