Scrum at Home – Agile for kids

There was a discussion recently that I participated in where someone asked if you could run Scrum at home for your children. There were a lot of interesting comments and a lot of good observations, generally the consensus was that Scrum was not suitable because most of the tasks for a child are specific to that child. But I shall explore in a bit more detail because I felt that the discussion missed the most crucial question that a coach should always ask.

What problem are you trying to solve?

Now I cannot speak for the people in that discussion so I shall speak based on my own observations and experiences.

Generally in agile we are about finding better ways to give your customer what they really want.  But in the case of Agile for kids the goal isn’t what they produce it is far more about the learning on the journey. I want my children to learn to be self-organising, pro-active, quality conscious, results focused (not done until it is done), to learn to prioritise, to learn to communicate, in some cases cooperation and teamwork.  The tasks/stories are merely tools for that learning.

This is a  variation on the traditional expectation of mastery purpose and autonomy.  If the tasks are household chores then it may be a stretch to hope a teenager will have an implicit desire to master the skill of mowing a lawn, purpose too, may be a hard one to cover on a week to week basis.  Autonomy on the other hand may well be a motivator. There was no real shared vision.

How to motivate?

So if we accept that the motivators that we generally promote don’t apply then we need an alternative.  In my case I chose a reward based system, it feels a little like an easy out, but for my example it worked and this is one area that I would be very keen to hear other ideas.  Kids are difficult to organise, they have a very specific and well honed sense of what is fair – and often it is irrational, this was most definitely an experiment that could go badly wrong.

The constraints and selected framework

I chose a combination of Scrum and KanBan, partly because I know Scrum well but mainly because I felt that the problem lent itself to that solution. The stories would be a combination of household chores and homework tasks.

We chose a 2 week sprint model because most chores have expiry dates and were repetitive, and if I’m honest I took a few liberties with the KanBan board and the tasks.

Mom took on the role of Product Owner, Dad as Scrum Master, and the kids as the team.

We began with a kickoff meeting where we discussed which stories we wanted to be done, this conversation was a mix of the jobs we wanted help with, what we felt the children were capable of and some suggestions from them as to what they felt that they could contribute.  We produced a list of tasks, setting table for dinner, clearing the table and stacking the dishwasher, making beds on a morning, cleaning bedrooms, cleaning other rooms, mowing the lawn etc etc.  Not glamouros but you get the idea. 

For each story we refined it, we discussed a definition of done and we specified acceptance criteria, it was a discussion with all of us: did cleaning a room include dusting, or just tidying and vacuuming?  Taking our the recycling had a specific date, but many of the other tasks had no expiry other than the end of the sprint. 

We then agreed relative size points for the various tasks, one task was fairly easy so got low points another wastime consuming or was undesirable so got more points, we managed to reach an agreement on the relative size of all tasks but agreed that we would re-visit if we felt these were wrong later.

And then on to the reward, we agreed with the kids that we would link pocket money to the board, each story point would equate to an amount of money, pocket money would be paid at the end of the sprint but only and very clearly only for done tasks.  We later modified this to being paid when a card reached the done column, primarily as I wanted to teach the children of the importance of completing stories and of prioritising those nearer to beng done.

With the acceptance criteria agreed we created a board, that had 4 columns (and a separate backlog). Columns were:

ToDo, Doing, Verify and Done.

At the sprint planning we would discuss which tasks the children wanted to take on, and whether they felt they could achieve them all.  Some tasks were clearly specific to one child because of clear ownership or because the task was age or capability specific, but some were joint tasks e.g. cleaning the playroom, and some were for anyone. 

All tasks went in the ToDo column and the kids were encouraged to move cards to doing when they started the task and to verify when they thought they were done. We encouraged them at breakfast to indicate what they would achieve for the day. 

We also encouraged them to write new cards for homework tasks or personal initiatives, although these were not assigned points. Merely to help them visualise their work.

When a card was complete they would move it to Verify and ask the Product owner (Mom) to sign it off, mom would go with them to check against the Acceptance criteria and anything that fell short would be bounced back. I am glossing over the screams of how unfair that was, although perhaps I shouldn’t because of all the things I learnt from this experiment it was how important this particular aspect of it was. Being able to say – “but you agreed this last week” took the wind out of the sails of most of the objections, they still sulked but there was much more acceptance that the parents decision was fair because the rules were agreed with the kids in advance.

So task complete, pocket money paid, happy kids, happy parents, card could be torn up or saved for the next sprint.

At the end of the sprint we reviewed what had been done or not done, and even kept a velocity of sorts. A little competition between the kids. We also held a sort-of retrospective where we discussed what could be improved, although this was a harder concept for the children to understand especially the younger one. We discussed workload, priorities and conflicts – “I did more than my share” some cards were ignored because they felt it wasn’t worth the effort. And so on. 

But we found that the experiment was for the most part a roaring success, the kids even started asking if there were extra jobs they could do.  For joint tasks they used peer pressure to get them all contributing. Rather than having to remind them to do jobs they were reminding us to verify, as I mentioned there was less conflict over what a job entailed.

Problems with the experiment

There were two fundamental problems, the first was the reward mechanism, financial rewards don’t work very well for kids. My 8 year old would see a toy he wanted and when he had completed enough cards for that item, he would stop doing his cards, he didn’t seem to be able to get the concept of saving up for the future. This is something that I think is a reflection of his age, but it made for inconsistent results.

The second was outside interference, at first it was funny but we had a lot of negative feedback, some via the kids. I didn’t understand it, but it was enough to undermine the experiment. The objections were mainly around the reward mechanism.

The third less significant issue was there was a time overhead each sprint and it was not always easy with a busy family schedule to organise this. Although that as always is a question or priorities.

Summary

Overall, I thought it was a great idea, it certainly isn’t Scrum (and I would never claim it was) but it was Scrum-like and the routine worked well for kids. I felt that the kids learnt a lot from it and I certainly learnt a lot. But parenting is hard in general, it is difficult to know whether you are doing the right thing.

I saw them much more self-aware, motivated, it helped communication, and framed boundaries. The kids enjoyed the responsibility and the autonomy. 

But in a lot of ways it was harder for me. As it was a mix of parenting and coaching, I found I needed to overstep my normal bounds of coaching and oddly I felt uncertain of how I should behave.

Ultimately we stopped the experiment, but I still feel it was a valuable learning experience and I would like to repeat it in the future. I would need to re-think the motivation aspect as that was really the weakest part.

However, I would heartily recommend it to anyone with older children, and I’d love to discuss ideas on how better to motivate.

Agile for the real world.

I have once again this weekend been drawn in to reading articles and discussions on LinkedIn, mainly discussing how Scrum=Bad, KanBan=Good, or KanBan=Bad and ScrumBan=Good, and a variety of similar content that frankly is just noise to 99% of the people involved in Agile Software delivery. The reality is that most software professionals really don’t care.

Did I really say that?

It might be a little ironic and I might just be adding more to the noise but I’d just like to bring us down to earth a little.

My experience of Software delivery has been mostly large corporations and the Civil Service, and what I can say with a good deal of confidence is that the staff involved in software delivery want Agile, no question, they are overwhelmingly in favour. I suspect that a step back to Waterfall would see hands go up in horror and a great deal of frustration and maybe even many people leaving in protest.

But I see it as the difference between learning to drive and understanding how an engine works. Most, and that is a sweeping generalisation, but most of the teams I have worked with want me to teach them how to drive, they want to use the skills they learn and to be taught how to teach themselves. What they are not interested in, initially at least, is the mechanics of the car. When they become proficient that may change they may believe that for particular types of driving a different vehicle may be appropriate, but initially simply learning to drive and practicing the basics is as much as is needed and they are happy to have a car suggested to them.

Recently I have been working very closely with three development teams and indirectly with others, and of those teams I’d estimate that maybe 10% have an active interest in the mechanics of Agile Software delivery as a topic and probably less than half of those would give two hoots which flavour of Agile we follow, so long as we follow the principles – most see the framework as a tool like any other it is about getting the job done right. But 100% want to be shown how to use Agile techniques to improve their way of working, but they rely on an expert to guide them. They wouldn’t hesitate to tell me if they thought it wasn’t working.

Most have had no prior Agile experience other than minimal training. Many have been in Agile workplaces in the past but if I am brutally honest they seem to have been poor implementations, a few had good experiences and a very few have been exposed to more than one variation of Agile frameworks.

In the real world a development team wants to build software, perhaps a little over simplistic but a coder wants to code and a tester wants to test. Now I can encourage them to co-locate, cross-skill and try to mix things up, they can use Agile to improve and most have an inherent desire to be Agile and improve. I can show them how to use TDD or BDD, I can encourage them to Pair Program, and they will be enthusiastic and supportive. Most will join in Retrospectives with relish and find true value in Stand-ups, most see the value in Sprint Reviews and the closer engagement with Customers – Why?

Why? Because they are embedded in a framework that works for them, they see positive results and they like what they see. But that doesn’t translate to wanting to have a discussion on the finer points of Agile frameworks. Most don’t see value in a debate on the differences between Scrum and Kanban.

As an example: I have read a lot about #NoEstimates recently and I find it interesting, there are others in my organisation that I could discuss it with and share ideas. But honestly I suspect the teams I work with really don’t care, they use Story Points and T-Shirt sizing because I showed them how and because it works, they see the value. Would they change to NoEstimates – maybe, probably! if I encouraged them to, but the likelihood of the suggestion coming from the teams is low, and it is unlikely to have support or interest of the majority. Certainly not enough of them would have sufficient interest and understanding to make it an inclusive discussion.

However, The same was true of Pair Programming, initially I met quite a bit of resistance from the teams, one guy in particular was very much opposed and resisted, but I encouraged the teams to try it out for a Sprint and then another, and now it is a regular part of their routine and the biggest opponent is now the strongest advocate.

You may be thinking that these teams were not very Agile, or they are not sufficiently mature, but that simply isn’t the case. It just isn’t their primary area of interest. While I am reading about Agile techniques they are reading Tech journals or exploring new tools. As an agile practitioner these details and nuances matter to me, but to a software developer they are just another framework, another tool in their toolkit. The teams may be self-organising but sometimes it needs an outside catalyst to encourage them to push their boundaries.

My point is that software delivery is the goal, the Agile Methodology of choice is just a tool selected to do the job, don’t expect a horde of zealots raising pitchforks and screaming “Scrum”, or “KanBan” any more than they would demand TFS or Jira or any other tool. At least not until they have used it enough to be proficient. That debate is reserved for the agile practitioners.

I have seen Scrum adopted well and adopted poorly, the same with Kanban, neither is a silver bullet, and one is not better than the other (In my opinion). Again in my opinion, when I hear complaints about scrum it is generally because it is not Scrum, but an unchanged organisation that has applied scrum titles, or a cargo cult that follows the schedule without understanding the purpose. And sadly the current trend of handing out certificates to anyone that has done a half-day training course demeans the framework. Too many people see Scrum as a means of control rather than a framework of support, and sadly that is the weak underbelly of Scrum, the framework can be used to create self-organisation but can just as easily be used to stifle it if you have the wrong mindset.

Agile is a mindset much more than a process, the framework is simply scaffolding, but if your mindset is wrong the implementation will be wrong.

I love Scrum, I think it has so much promise and when used well I think it can be hugely effective, in most situations it would still be my starting point with organisations new to Agile, especially when management is not fully engaged. One of the likely intended side-effects of Scrum is that it becomes a tool to regulate the rest of the organisation and create stability for the teams to grow, it creates a protective bubble to enable agility to develop.  

So It saddens me when I see Scrum being seen as a barrier to agility. When ScrumMasters are wolves in sheep’ clothing and simply managers or PMs assuming a title and then undermining the framework, because they don’t understand the essence of the role. Where cargo cults masquerade as agile teams, and when they fail they blame Scrum.

My dad used to say that a “bad workman blames his tools” this was never more true than with Scrum. As a tool in the right hands it can be fantastic, in the wrong hands it becomes a fine quality chisel being used as a crowbar.  

The debate will continue and sadly because of its early success in widespread adoption Scrum has had many poor implementations and so is in danger of bad press which could ultimately spell it’s doom. Far too many experienced agile practitioners are advocating against Scrum based on bad experiences, but I for one believe that as a framework Scrum is good, but sadly there are too many cargo cults giving it a bad name. 

How We’re Using Blocker Clustering to Improve

I have just heard of this for the first time today and I think it is such a good idea. I am a firm believer that metrics can be used to help and this is a great example of where focused metrics can show the true impact of what might otherwise be perceived as a minor problem.

I also don’t see this as limited to KanBan either, it would work just as well on a Scrum Board, and a moment or two identifying the impact of impediments is time well spent.

Can I also add that impediments are not limited to blockers: extra work, anything slowing you down, lack of tools or other resources etc also counts as an impediment.

Matt Philip's Blog

IMAG4924I’ve been helping a team at Asynchrony improve using blocker clustering, a technique popularized by Klaus Leopold and Troy Magennis (presentation, blog post) that leverages a kanban system to identify and quantify the things that block work from flowing. It’s premised on the idea that blockers are not isolated events but have systematic causes, and that by clustering them by cause (and quantifying their cost), we can improve our work and make delivery more predictable.

The team recently concluded a four-week period in which they collected blocker data. At the outset of the experiment, here’s what I asked a couple of the team leaders to do:

  • Talk with your teammates about the experiment
  • Define “block” for your team
  • Minimally instrument your kanban system to gather data, including the block reason and duration

The first two were relatively simple: The team was up for it, and they defined “blocker” as anything that prevented someone from doing…

View original post 427 more words

A man walks in to a bar…

I heard a riddle the other day that seemed so appropriate to use as a story writing analogy that I had to share.

A man walks in to a bar and asks the barman for a glass of water,

The barman reaches down pulls out a shotgun and blasts a hole in the wall just to the left of the customer’s head,

The customer, says thank you, leaves a tip on the bar and walks out.

Why did he leave a tip?

The answer is that he had the hiccups. This makes for an amusing riddle but at the heart of this riddle is the very essence of story writing.

The customer has a need, in this case it is to be rid of hiccups, but rather than expressing his need, he phrases his requirement in the form of one possible solution. There is nothing really wrong in what he has proposed but by presenting a solution rather than a need he has limited the potential solutions and limited the scope of the solution provider – the barman.  The customer may simply have been thirsty and just also happened to have hiccups, in which case the solution provided did not meet his immediate needs and may well have caused other problems – for example if he had a sensitive disposition.

The barman on the other hand is either a very good or a very bad solution provider, he has ignored the customer’s request, or possibly delved deeper, he has used other means to extract the true needs and requirements and provided what he believes to be a better solution, and judging by the tip, he got it right. 

The lesson from this though is that the best user stories express needs rather than solutions, and the best solution providers explore various options, they ask questions and make assessments based on other factors and only propose solutions after they have understood the underlying need being addressed.  Sometimes a solution may create conversation but often a suggested solution limits creativity.  

And for me one of the great things about Agile is that very often a customer may not know what solution they want until it is proposed to them.

A user story need not be specific, nor detailed, it is best described as the basis for a conversation. The need should be explored before a solution is provided to reduce the desire to shape a need to fit a solution.

If and when a story is presented to you in the form of a solution, then explore deeper, try to get to the heart of what they are trying to achieve, it may be that their proposed solution is the best one, but without understanding the need you can never be sure.