Back to Basics, Back to Class.

I was asked by a client to put together a talk / training that we can give to newbies to the organisation that give a flavour of what Agile* is about. Now I didn’t want to just do the standard Agile 101 we see everywhere, which seems to mostly go….

“This is Scrum, this is XP, oh and in passing there’s this thing called Kanban, but as its hard don’t worry about that. Here’s some roles and ceremonies, you’ll need some user stories and a great big ordered and prioritised backlog, and here a couple of quotes by Darwin and off you go”.

.. or a some variation on this theme.

I must admit seeing this type of standard course is frustrating as all that is happening is that we are just sticking a load of pre-prepared thoughts / recipes in a bag and giving it out to people and expecting them to actually understand how it all works under the covers, it’s a bit like giving me a Haynes manual and asking me to fix a car, no chance.

It’s the good old cooks and chefs scenario again.

So I thought to myself there has to be a way to come up with perhaps a simple distilled version of what’s going on under the covers, the way we tell little white lies to children because explaining something fully is just too hard for them right now. For example we tell kids that a rainbow is simply the sun shining through rain, which is kind of true but not really the complete picture.

How hard can it be I thought, to come up with say 6-10 maxims and guess what it’s really hard. In my mind everything is so incredibly interconnected that being able to disconnect concepts and decide what is or isn’t important is really hard.

I have probably had 20 plus false starts at writing this and I wasn’t really getting anywhere quick, but last week I went to another client’s site to give a week-long Scrum training course for graduates and things became clearer.

These guys had already done the out of the box Scrum 101 with a standard course provider as well as a number of other courses and this week was to be a bit more of a hands-on pulling it all together and doing a bit of embedding.

Now we all had a great fun week and other than their course the grads had little or no experience of “Agile”, they have keen minds and are good at asking probing questions to understand how things work. So what fell out of the week was a list of key ideas, concepts and themes that I constantly came back to in those 5 days to explain “how” things worked.

Basically these were the things that I found most useful to explain to a naive audience, whilst this is not “the” list of agile basics, but it certainly is” a list”.

The list was:

Rapid Feedback.
Collaboration.
Value.
Visibility.
Self-Organisation.
Adapt.
PSI ( Potential Shippable Product Increment) – ( It was based on scrum after all )
Batch Sizes.
Stop Starting, Start Finishing.
Context.
Communication.

You can also see that we used INVEST¹ to help to structure our stories and show the guys that they were empowered to negotiate with the Product Owner (PO) on what will actually be delivered.

To briefly expand on these points and what we by them in that context, unsurprisingly many of them interlink and support each other.

At the end of each section I’ll add the main takeaway that we gave to the graduates.

Rapid Feedback.

One of the reasons Scrum has short time boxes is to facilitate rapid feedback on what we have just built from the PO and /or the Customer, this allows us to make sure what we have built is what was expected. Not waiting until the end of the sprint to show what you have built is good practice, so as soon as you have something to show let the PO see it, get feedback get validation.

Feedback happens on multiple different levels, so it’s not just feedback from the PO or Customer. It’s feedback between QA(test) and developer, between developers through peer review or pairing, from Security, Architecture or even from the Scrum Master as to the team on the process.

One good thing about Scrum is that the ceremonies provide a frame work that promote the gathering of feedback, Daily Stand-ups, Retrospectives, Sprint Review and Sprint planning all drive rapid feedback loops.

Takeaway: It’s a bit hard to have too much feedback.

Collaboration / Self Organisation / Communication.

I’m lumping these three together as they really are inseparable, close and frequent collaboration, which in itself requires communication, forms the basis of self-organised teams and this was constantly emphasised to the guys.

Again the Scrum framework drives this aspect of agile very nicely and encourages collaboration and self-organisation in the early “forming” ² stages of the team.

Ultimately this all feeds down from motivation, under the Autonomy arm of the Autonomy, Mastery and Purpose thinking on motivation³ and leads us eventually to the use of command intent to drive agile at scale, so it’s a good thing to drum in early and enforce.

Takeaway: Having well a well motivated and organised product team is an absolute must to delivering great products.

Value.

As we started to use INVEST one of the interesting things that came our of it was the notion of value, what does value mean?

For the sake of the training and in the context of teaching something vaguely Scrumish we kind of passed over on the underlying value of the stories that we were bringing into the sprint and how these supported product and business strategies. The fact that the stories were driving the “right” value was assumed and the grads were simply told that the Product Owner was the sole arbiter of what value is.

Obviously value is a big concern in the “real world” and a subject covered else where

Value in this case was simply used to emphasise that we needed to deliver value within a sprint and that the cost of building / coding the product was inherent in the overall cast of delivering the product.

Value was a useful way of emphasising to the teams the commitment to the sprint goal and to each other.

Takeaway: The focus should always be on delivering value

Visibility.

I find visibility to be inseparable from transparency as you can’t really have one without the other, if you are doing it properly

Visibility came up a number of times in the course in multiple ways.

Visibility of the “what, whys and who’s “of our product, so we can build a common shared understanding.
Visibility of the “how” we are going to develop the product, so we all know what our technical direction of travel and have a chance to influence it.
Visibility of what we are working on right now, so we know who is working on what and when will it be completed

The first visibility came through the product owner, having a great product owner, who is available to team cannot be underestimates, we had both.

As for the other two, as the grads had already been on their Scrum course we expected that at sprint planning they would break their work down into tasks and from this validate how the work that was to be done and ultimately their commitment to the sprint goal through estimates.

It also allows them to make sure they are not taking great big floaty icebergs of stories that they have no chance of finishing into the sprint, stop starting start finishing..

However early on it became clear that the grads were simply working on “stuff” and the boards simply did not reflect the work that they were doing and how they were tracking.

Its very hard to manage work that you can’t see and to make sure we are all on the same page when it comes to the way we are building the product. Actually this is one of the big problems we see when we work with new teams, in that they are not used to using information radiators like Scrum or Kanban boards.

Indeed a lot of early benefit can be very simply obtained by simply making what’s invisible, visible.

They eventually got this, through the pain of a lack of coordination which lead to either things not getting done correctly or at all and in one case the duplicating of work . By the end of the week they were really updating the board well, moving work between status’s and actually adding avatars so we know who was working on what.

A good example of making things visible was during sprint planning when we used planning poker to make outlier scores visible, this promotes a conversation and drives common shared understanding.

Takeaway: Being open & transparent about what we do builds trust, drives collaboration and ultimately motivation as well as facilitating fast feedback.

Adapt (ability).

As we all know stuff happens, which is why we focus on planning and not plans, this was actually a very important concept to get across.

We needed them to understand that most knowledge work takes place as part of a complex adaptive system and that there will always be unanticipated issues, problems or changes to what we are building that emerge simply as a natural part of the process we go though.

Clearly this all comes from Cynefin⁴ and whilst this was mentioned, we didn’t give any specific Cynefin content, although maybe an hour on it wouldn’t have hurt, perhaps next time.

We simply wanted to get over that in order to cope with the inevitable we have to be as adaptable as possible, which means not creating big detailed plans upfront and keeping our options open as long as possible.

We were lucky or perhaps unlucky depending on how you see it, in that there were some significant problems early on with the development pipeline that we had been given. This caused us to have to rearrange what we were to do on the fly, but my colleague and I both have a fair bit of experience of this kind of thing and so were able to adapt and this made a great example of adaptability for the grads.

.. and not a little panic for us!

Takeaway: Don’t waste time trying to nail it down, its more important ot get going and adapt as the feedback comes your way.

PSI ( Potential Shippable Product Increment).

Scrum tells us that at the end of a sprint we should have a potentially shippable product increment, its kind of a big deal as it’s the whole point of doing a sprint, to build something that we could give to somebody and they could use it and derive some value by using it.

I find that developers at time’s forget this very simple fact, so let’s be honest here the main reason we are here is to build stuff for our employer and by doing so in some way add value to our organisation.

If we are not doing that then we might as well all go home.

Clearly by building great software, that our customers love will by default add value and drive the bottom line, so it should be a win-win.

We used PSI to get this across, in that at the end of a sprint we need to be delivering something that the PO could be give to a customers and they could get value our of using it, which is return gives value to our organisations ( and we keep on having a job ).

Takeaway: Drive a sense of commitment and urgency within the team and despite what the Devs will tell you, this isn’t a bad thing.

Batch (Story )Sizes.

I wish I had £1 for every time I’ve wittered on about batch sizes and I’m fairly sure people are sick of me going on too!

This is not something that is specific to Scrum, but it’s a fairly embedded concept these days. Having work that can be completed within a sprint is rather important to being able to deliver a PSI, hit a sprint goal, get feedback or actually pretty much everything we are talking about.

Like estimating there is no magic sauce to being able to do this, just experience and knowledge and I find that many new teams struggle here for a while, but if you can make people aware of the issue then its something that you can be mindful of.and look out for.

I tend to use a rule of thumb here, which is to try to make a story deliverable inside a week, this is obviously context specific and not always possible, but its a decent enough goal.

Takeaway: Have work that you can see moving across the board between standups, this drives a sense of commitment and actually finishing things is quite motivational, remember you can negotiate the sprint goal.

Stop Starting, Start Finishing.

Mentioned above frequently because it is one of the problems that we see with scrum quite frequently, teams agree a sprint goal and then start work on all of the stories, at once and finish nothing.

It ends up a bit like the charge of the light brigade a great big rush for the end, stories abreast only to end up in messy failure. When we get to the end of the sprint we have lots in flight but ultimately nothing completed and nothing to show, no PSI, no made sprint goal, lower moral and motivation, grumpy product owner, not good!.

So within a sprint we were asking the grads to order the stories in priority order and attack them with a view to completing items one at a time if possible, so limiting the amount of work in progress at any one time within the sprint, very Scrumban.

This also links through to batch sizes above, having smaller pieces of work that pass the INVEST test helps us to deliver on our sprint goals and add value.

Takeaway: simples … stop starting, start finishng

Context.

This is last, but ultimately its probably the most important lesson I felt we got across.

Understanding that what you are doing now is appropriate to now alone and cannot be replicated in a different context as a guaranteed recipe for future success is highly important to understand, again this is Cynefin speaking.

You can argue that a technique used in a similar context may have a reasonable probability of success, but there is never a guarantee, having the right solution for your context is the right way to go about it.

You cannot distil a direct link between cause and effect in a complex system, except in the full glory of hind-sight, as complex systems are not causal they are dispositional.

So what the hell does all this mean, don’t put your eggs in one basket and assume something will work just because it worked before, whether this is a coding practice, the way we capture requirements, facilitate retrospectives, anything at all, because if you do you will getting bitten at some point.

Now don’r get me wrong, experience and knowledge play a big part in all of this, it may well get you most of the way there and in certain circumstances it may be all you need, just be mindful that things may not be quite as straight forward as you think initially.

Remember, you adapt to your context by having good people, with a great understanding of the underlying principles and theory, the problem domain and the art of the possible working in well motivated teams.

Takeway: Don’t assume that just because it worked before means it will work again, the best you can do is understand the here and now, work out where you want to go and get going.

And that was that, just a quick note for the grads, don’t take what we did with you as gospel, it’s there to give you a taste of what may be, but use the above as rules a thumb and do lost of learning, you journey starts now.

*I’m using Agile here in a holistic sense to indicate the whole of Agile / Lean (Kanban)