All he does is state the obvious…

A few weeks into a new project and I was given the feedback that all I had been doing is stating the obvious and pointing out pretty much fundamental Agile principles and practices.

At first I was a little offended, I want to be adding value and so it was more than a little disappointing to hear what I felt like was a negative assessment of my work. And so I reflected on what I had been doing, partly to see how I could do better and partly to reassure myself that I was adding value in the right areas.

As I reflected I realised he was right. I had been stating the obvious, but what is not generally well known is that the obvious is not so obvious at all.

If there is one criticism that could be fairly leveled at me is that I let teams flounder too long before I step in. I have the belief that if a team solves it’s own problems without help they learn far more. If the team doesn’t appear to be seeing a solution I then move on to subtle hints – dropping seeds of ideas, and if I still feel they are not seeing things and I get to the point of ‘stating’ then it is because I don’t think the team is going to solve the problem without more pain than is appropriate for the situation.

In this case I had been challenging the team to produce working agreements and agree what their definition of done was. This is a scaled Agile project and my fear was that if the whole team did not agree ‘done’ together then one sub team’s ‘done’ would be imposed on all, or worse ‘done’ would be inconsistent between the teams. I also urged them to agree how they would integrate their work, I gave them advice on ‘Vertical Slicing’ and some advice on story writing, especially ensuring that the ‘value’ of a story was clear. All pretty obvious stuff – that is if you knew it already.

But these are new teams and some of the team are new to Agile, I suppose what is disappointing is that it was me that had to state the obvious, and not one of the more experienced team members. Self-organisation only works if the teams take the responsibility, and are then sufficiently motivated to deliver on that – more on that in my next post.

If my advice was so obvious why did it take an outside observer to see it? Why couldn’t the team see it for themselves? The answer of course is that solutions only become obvious when you see them, and it often takes an outside observer to point out what should have been obvious all along. All too often we see things as obvious after they have been pointed out to us or later feel they are so obvious we don’t say anything not realizing our team mates were struggling.

Realizing that common sense is not very common and what may seem obvious to one person may not be seen at all by another is actually one of the more difficult aspects of coaching. Sometimes I ask what seems like a basic or even stupid question because I sense others in the room may be unsure. Sometimes this makes me look like an idiot but sometimes it is clear that the stupid question was not so stupid. (And for the record sometimes I ask to promt conversation or clarification but often I simply don’t know and I figure that if I don’it know maybe I am not alone.

So please, state the obvious in your teams, especially if you feel it may not be so obvious to everyone else in the room.

Just what is an Agile Coach?

An Agile Coach is a relatively new job title, one that has become popular over the last 10 years or so and is a role that causes a great deal of confusion: what do they do? and how do you know if they are doing a good job?

It is also a title that covers a great many responsibilities, sometimes Agile Coaches will coach teams, sometimes they will coach organisations. For the latter I prefer other terms and so for the purposes of this article I will assume that the role is one aimed at coaching development teams within an organisation.

What the role is not…

An Agile Coach is not a manager,

although many Agile Coaches will have had experience as managers or at least have had backgrounds similar to other business leaders. An Agile Coach will generally have a broad history of working with people, and understand how to manage people – and how not to. In organisations with Agile Coaches they will often reduce the demand for managers or in some cases eliminate the need for managers entirely. But not by taking on their responsibilities, but by showing and enabling the teams to fulfill many of the responsibilities for themselves. This is generally much tougher than managing directly, as they must do it without authority. Much of an Agile Coaches responsibility will be in building teams and encouraging good working practices and collaboration with colleagues.

An Agile Coach is not a Project Manager,

although again they may have a degree of knowledge and experience in this area. An Agile Coach will be there to work with teams to deliver software, but an Agile Coach is much more likely to ask “Why?” than they are to ask “When?” A coach is far more interested in whether a team understands a priority than they are in ensuring a team meets a deadline.

An Agile Coach is not a lead developer,

although they may have once been one, sometimes they may pair with people on a team, coding or testing or designing, but they are not there to be productive but to enable the team to become more effective. Sometimes through advice sometimes by example and most often by enabling safe failure, a Coach will likely let you fail and then ask questions to help you understand why you failed.

An Agile Coach is not a facilitator,

although they may facilitate meetings and events. A facilitator will often be neutral and unobtrusive. A Coach should know when to prod, poke, be provocative and even contrary or when to stay silent. I know coaches that will deliberately and consciously stay silent during a meeting, noting for themselves what their advice would be but just watching to see if the team reach the same outcome. Other times, suggesting a false path to see if the team challenges them. Other times they may guide a team to an outcome if they feel the team will benefit and will be able to make similar choices in the future. Most often I find myself sowing seeds of ideas in the hope it will trigger the team to come up with a solution for themselves.

An Agile Coach is not a trainer,

although they will help you learn. An Agile Coach may at times teach in the conventional sense, but more often they will enable you to create opportunities to learn, and when they do training or seminars it will likely be composed of learning opportunities more so than lecturing from the front. A Coach will generally try not to tell you how to do something nor even show you how. Normally they will ask questions that encourage you to figure it out for yourself. This is not of course the only way to coach and sometimes it is more effective to show and then ask why you did something a certain way. But it will be rare that a Coach will tell you how to do something without ensuring you understand why you are doing it. As you can imagine this can be an area of frustration at times.

What are they then?

An Agile Coach is Experienced

An Agile Coach is generally someone that has been there and done it. There are a whole host of learning material on Agile Practices; delivering software; and managing people and businesses. But there is no substitute for someone that has done those things first hand, and better yet had difficulties or failed at doing some of those things. You will likely find that an Agile Coach has years of experience of delivering software in general, often having done a variety of roles.

I believe the reason for this is that in most situations where a coach adds value it is not a solution that is sought, but and understanding of the problem. Someone that possesses nothing but canned solutions to questions, hasn’t had the benefit of the journey to understanding that the question asked is rarely the question that needs answering.

To get there requires the ability to see beyond the question, and in my opinion at least, this comes far more from experience than teaching. I find some of the best lessons are in the form of fables and analogies. Because they are able to stir our own experiences to enable us to better understand why we do something rather than being presented with a solution.

Experience is the teacher of all things

– Julius Caesar

An Agile Coach has plenty of soft skills

the chief of which is empathy, which comes from experience. The ability to understand the perspective of a developer or QA or the other members of the team comes a lot from experience, which is why so many coaches started their careers in software delivery teams. But the role also requires communicating with management and customers and other teams which requires great communication skills and yet again can benefit from having been in a management role, or project lead, etc. The role may involve 1-1 coaching, mediating conflicts, giving difficult but constructive feedback, building relationships with teams and encouraging them to build relationships among themselves. Negotiation, selling, planning, listening, advising provoking and challenging. A great coach excels with soft skills. A few coaches have an abundance, most of us are skilled in some areas but are still growing and learning to develop these skills.

An Agile Coach is responsible

but not accountable, they are responsible for guiding the teams in Agile Principles and Practices, but priority is given to understanding why, over learning how. But they are not accountable for the teams following Agile principles, the teams themselves are. The coach can show the way but does not force you on to the path.

An Agile Coach needs to be humble

On the best days a coach is a force magnifier, they are able to show a team or an individual how to improve, but the coach will rarely be able to say “look at what I achieved” instead they will sometimes be able to say “Look what I helped achieve” but more usually watch from the sidelines as credit is given to the team or the individual. If you are looking for glory this is not the job for you. You are often even held in a negative light when you shine the spotlight on problems that were previously unseen. A thick skin is essential.

An Agile Coach needs to be hungry

Being Agile means always wanting to improve, and to do that requires a desire for learning, through experience and through other forms of learning, books, conferences, discussion groups. An Agile Coach that isn’t learning and pushing themselves will likely very quickly become ineffective.

An Agile Coach is open to new ideas

Agile is not a methodology, it is a desire and determination to find better ways to develop software and help others do it. An Agile coach should not be wedded to a framework, be it Scrum or Kanban or XP or any of the others, they are tools to reach an end. When we limit our scope to only one framework we cease to be an Agile Coach. We should be aware of the options and be open to new ideas. That doesn’t mean we don’t favour some over others, but we should have an acceptance that they are merely a tool to do a job. Each may have areas they are better suited, and perhaps with sufficient understanding it may be possible to combine ideas or cherry pick elements from other methods.

The benefits of an Agile Coach

An Agile Coach’s expertise is much broader than Agile methods, whilst at it’s core the impact can extend from teaching the basics of the various Agile methods through to expertise in the various roles in an agile organisation – such as Product Owner, or implementing XP practices, coaching organizations on Agile transformations or simply process improvement. But most Agile Coaches have expertise that goes much further and may well be skilled at coaching interpersonal issues, team building, management techniques, personal development, conflict resolution and most of what would be considered ‘management’ skills.

I would broadly break down the benefits of an Agile Coach in to four areas

Coaching on Agile Methods
Coaching teams that have identified a need for support in certain areas
Helping teams identify areas where they need support
Helping organizations identify ways they can improve teams at a macro level

The first two the teams are likely consciously aware of and so are able to identify the need and make the request. The latter two by their nature are likely areas that the teams are not aware they have an issue, or feel it is something they cannot change (in isolation or at all)

The four stages of competence:

Unconscious Incompetence: If you are unaware you lack a skill or are unaware of a deficiency you cannot ask for help. A coach should be able to observe and identify where you may have areas for improvement, it is common for us to be unaware of our bad habits or blinkered thinking, we get stuck down rabbit holes, sometimes this can be on an individual level and sometimes teams can be the same way. It generally takes someone from the outside to see the problem and help move it from unconscious incompetence to a conscious incompetence, once we are aware of a problem we can choose to do something about it.

Conscious Incompetence: If you are aware of a problem, you can take steps to improve. Sometimes you can do this on your own but sometimes it makes sense to ask for help, asking for a coach to help guide you, they may have past experience or suggestions or techniques to help. With effort you can generally move from conscious incompetence to conscious competence

Conscious Competence: At this stage – with some effort you have the skill or have obviated the defect, but it still requires effort. Now it is really a question of practicing the skill until you become proficient (unconsciously competent), the value of a coach here is not in the evolution of the skill or the breaking of a bad habit, it is in the observance of new bad habits forming and stopping them early.

Unconsciously Competent: As you improve one skill area and become unconsciously competent – you have a mastered a skill, you may discover more skills you lack, and the cycle repeats.

How to measure or for that matter manage an Agile Coach?

There are generally considered to be a number of situations where it is very difficult to measure and therefore difficult to manage someone:

Where the person’s expertise is broader or deeper than that of the person measuring them – essentially how can you assess performance if you cannot judge if it is good or bad and to what extent it is good or bad.
Where the person’s contribution is intangible.
Where the contribution is situational and variable, there is no yardstick. (Such as creative or innovative work.)

An Agile Coach falls into all of these categories.

There is no easy objective way to measure performance as there are no KPIs. The coach’s goal is to improve a team or an organisation, if the organisation/team improves – was that because of the coach or for other reasons? There is no objective way to tell.

At some point it becomes a question of trust, and subjective assessment.

If you have a problem and ask for help, a good Agile Coach will give you a solution, but a great Agile Coach will show you how to solve the problem for yourself.

Summary

Not all Agile Coaches are the same, and not all will possess all of the skills above. Each one will have different strengths and weaknesses and a lot will come down to how they interact with the team they are with. Like any profession there are some Coaches that are better than others. But in my view any team should be able to improve with the right coach, but not every coach is right for every team.

If you believe that you cannot improve with coaching (and some teams do claim this), then you are probably right, a mind so closed to the possibility of learning, or that someone else may see something you can’t, then maybe you cannot grow and you may be incapable of improvement. But consider that even the best sportsmen, and artists have coaches, the most successful business execs often have outside mentors. The limiting factor is not the coach it is your willingness to grow.

I’d also add that some coaches are better with teams at different stages of Agile maturity or the different stages of a team development, that does make one better than the other. I’ve seen some extremely experienced agile coaches that are so advanced in their understanding of Agile methods that they find it difficult to relate to teams that are at the start of the agile journey, they try to push the teams to new concepts before they are ready, rather than guiding them to their own growth.

In the same way not all Agile methods are right for all teams or organizations, understanding the strengths of your teams and the strengths of you coaches and finding a match may be the key to success. Some teams may require more time with them than others too, this is not necessarily a reflection on the ability of the team or the coach but on the skills being improved and the type of coaching that is happening. Sometimes a change of coach can stir things up and open new growth opportunities.

Overall I’d suggest that a coach is more guide than leader and asking one for advice is not a sign of weakness, it is a sign of strength. none of us know everything and the willingness to ask for help to learn is a crucial step to growth.

The effect of Bystander Syndrome on an Agile team

For those unfamiliar with the term, Bystander Syndrome is a condition where responsibility is diffused as a group becomes larger.

From Wikipedia:

The bystander effect, or bystander apathy, is a social psychological phenomenon that refers to cases in which individuals do not offer any means of help to a victim when other people are present. The probability of help is inversely related to the number of bystanders. In other words, the greater the number of bystanders, the less likely it is that any one of them will help. Several variables help to explain why the bystander effect occurs. These variables include: ambiguity, cohesiveness and diffusion of responsibility.

The larger the team the lower the sense of responsibility.

I have noticed a similar trend with self-organizing Agile teams, as the team becomes larger the individuals on the team appear to show signs of becoming less accountable and have less of a sense of responsibility for issues on the team. Dull or unpleasant tasks get ignored and deferred, whole team action items get ignored with the defense that they expected someone else to take it. With self-organizing teams there is no single person that is accountable for this and the accountability is so diffused that there is no sense of responsibility. Accountability is reduced proportionally to the size of the team.

But even when there are just two in the team there can be issues. I am sure every other married couple is perfect and this doesn’t apply to you, but there are many occasions where my wife and I each assume another will do a job, only to discover that neither of us has done it. “Did you pay the gas bill?” Some jobs have a tendency to fall between our fields of responsibility and get missed. As a result of this we now have a whiteboard in the kitchen and on a daily basis I can see the jobs I have been avoiding and hoping someone else will do.

My observations

Behavior changes depending on the circumstances and how clear the expectation of responsibility is. For example: If there was a system where the team needs to go and look at a queue of service issues they would be far less likely to look and take up the task, than if the issue was emailed to the entire team. And the larger the team, the less likely any one individual was to look.

What is particularly noticeable was when a single person was specifically named in an email and asked to look, the response rate would be much higher, and if someone came in person to ask a particular person the rate would be higher still. In essence the harder it becomes to avoid acceptance of responsibility the more responsibility we seem to accept. But it all seems to be subconscious. I would hazard a guess that the team were not overtly aware that they were dodging responsibility. In most cases each individually felt what they were doing was the most important task for them.

I am not a psychologist and these are just observations of a few teams in action, but much to my disappointment it appears to conflict with my notion that self-organized teams are the ideal.

Where no leader is assigned a hero emerges (or a martyr).

An exception to bystander syndrome seems to be an emergent hero, someone who sees the lack of responsibility and begins to fill the void. Often one member of the team would end up taking the defacto responsibility upon themselves, even though it should be a shared responsibility, this sometimes results in a variation of siloing. The consequence of this is that a hidden dependency occurs, and as there is no formal responsibility when that person is on leave the task gets forgotten or ignored. This may also result in negative behaviors such as informal internal hierarchies or power plays.

This situation also builds resentment, if the self anointed person is making decisions for the team the others may resent this “decision making without authority”, if the tasks are dull or menial then the self anointed martyr may resent feeling obliged to pick up the slack. Neither outcome is healthy and may require an outside impartial person to see and help overcome the resulting dysfunctions.

The value of visualizing your work

In Scrum we ‘forecast’ the work at the start of the Sprint and the tasks are added to the ToDo column on the board, with KanBan we have a prioritized backlog of ready items to take and we take the items from the ready queue (ideally in order). In both cases similar behaviours occur. Some team members have a greater sense of responsibility than others and so unpleasant work is not evenly distributed, the enthusiasts or martyrs take undesirable jobs. And if any work doesn’t get put on the board the team feels free to ignore it entirely. Which is why it is so crucial to create cards for all work needing to done by the team and clearly prioritize them, and why the use of a board becomes so valuable for self-organizing teams. It is a way to visualize our work, and by doing so we visualize and reinforce our responsibility. The board is pretty hard to ignore. In many respects the board become the boss. It tells you what to do, what is most important and which things need help.

Action Items from meetings

Ever noticed how in a meeting the whole room can agree that something needs to be done but when asked who will do it, the whole room goes silent. We suddenly become bystanders hoping that it is someone else’s problem, that someone else will volunteer. But as a self-organising team we are all equally responsible aren’t we?

This is a point of internal conflict for me, if an action item does not have an owner it often doesn’t get done, so it is normal practice to assign an owner. We make someone accountable before we leave the room, but by doing so we immediately absolve everyone else of responsibility. We create a silo, maybe it is just for that action item, but it is still a single point of failure. The creation of unnecessary silos is something that I don’t like on principle, but at the same time I am well aware that silos are the best way to get something done. When responsibility is clear the task is far more likely to get done.

My ideal would be to defer the decision on who will do a task until the task is started. When Fred – the team martyr – volunteers to take every action item, because the rest of the team suddenly find something fascinating on their phones or on the ceiling when it comes time to ask for a volunteer, we create a situation where he becomes a bottleneck, others could do the task, but feel they are unable to because it has been assigned. If the task does not make it to the board we may not even realize he is a bottleneck.

But deferring deciding who brings us back to a situation of a task falling through the gap. My preference is to assign a task for someone to create a card to put on the board for any action item. (I’m always looking for a better way.) It feels like the right sort of compromise, someone takes responsibility for getting the card to the board, so we can be confident it will get there, and once on the board and prioritized the teams understand the need to pull tasks in priority order. Leaving the decision of who will do it until the last responsible moment.

Team size

Independently and for reasons other than diffusion of responsibility, Parkinson (as in Parkinson’s Law), concluded mathematically that groups larger than 20 were ineffective and that the optimal max size for an effective group was 8 or less, which by happy coincidence is pretty close to the Scrum guide of a max of 9.

He was studying governments and leadership groups but the same principles apply to any group asked to make independent decisions and has shared responsibility and accountability. He found that the communication overhead of larger groups made decision making hard. He also noticed a tendency for the groups to focus time and energy on topics the whole team could understand. Which resulted in a bias towards triviality, the less complicated the topic the more you could become involved.

Smaller groups were generally more effective and better able to make decisions.

What exactly does a manager do?

Most of us have had managers at some point, and in business they are widely accepted as a necessary overhead. Mostly management is about organisation and communication. A manager is a single point for communicating downwards, they are a focal point for communicating upwards. They can be a decision maker, they can set priorities, they can remind us of responsibilities. They can remove obstacles. They can guide and support and resolve disagreements. Often they also do administration, and reporting. Set goals and ensure you are working on the right thing, are getting the training and support needed, and perhaps even ensuring you are happy in your work. Not much of that requires authority, it is mostly support.

For some of us we have been lucky. Occasionally I have had a boss that I have hardly noticed, he has given me space to do many of these responsibilities myself, only being there when absolutely needed. A boss can do this when he is confident that he can trust you, and that you are able to perform the role independently.

So if sometimes bosses can do this, why not all the time? Is the need for a manager a reflection that the team cannot function without her, or is it because she doesn’t trust the team? My guess is that sometimes it is one; sometimes the other and sometimes a bit of both.

How does it help us?

This is all very interesting but how does it help us? I think there are a few things we can learn. The first is that we are asking people to be both independent self-starters and great team players in the same breath. I am not sure those of us that have been in this space for a while can remember how tough these two skills are to learn and how often at first they feel like they conflict with each other.

Most people grow up with parents setting boundaries and stepping in when needed, or teachers setting clear guidelines. Most jobs have someone checking to ensure you are clear what you need to do and to ensure you are following through on your responsibilities. So taking that away with no support mechanism is risky. Even people used to making suggestions still expect someone else to decide. And worst of all most people grow up believing that making mistakes is a bad thing. You cannot expect people to unlearn these behaviours over night simply because we believe self-organised teams are great.

Ask someone if they would rather not have a boss and they will jump at the chance, that is until they realize that not having a boss means accepting all their boss’s responsibilities.

What we can learn from this?

If you can avoid it do not have teams greater that 8 people. Communication and decision making are significantly improved. Bystander syndrome is reduced and responsibility increased.
Ask yourself – do you really need a Manager, or a Team Lead or a Project Manager for this team? What role do they provide that the team alone cannot? If the reason is a question of trust or the skill level of the team, what can be done to resolve that? If a team ‘needs’ someone to manage them, I’d suggest this is a sign of other deeper issues.
Self-organizing teams require new and different skills, these are learnt skills and will take time to master. Provide support and guidance and let the team learn them. Be on the look out for emergent leaders or martyrs and help the team become aware of them too.
Visualizing work is one of the most powerful ways I have encountered for reinforcing awareness and acceptance of responsibilities. A kanban board is far more effective than any status report or project plan.
Mistakes are powerful learning tools. Help the team learn to fail safely. Hold regular retrospectives and celebrate the mistakes, find new and better ways to work as a team.

My final thought is that there are many things a team can do on their own, I believe that with the right support, training and experience a team can function almost independently. Certainly without the need for middle management or project management. But that doesn’t mean it will be easy, or that you can simply pull the manager and step back.

Scrum introduces a Scrum Master as a transitional role to guide the team towards independence, and Agile Coaches may do the same in other environments but more likely in a less structured manner, but in both cases the goal is to create independent self-organised and continually improving teams.

Building on the foundations of Joy

I have recently finished reading the book Joy Inc. by Richard Sheridan which is the story of a small software company that has been successful, most notably as being a great place to work. The CEO had come from a an extremely successful start to his career, he had been promoted up the greasy pole to VP of software for an established firm and he had become wealthy in the process. By most conventional accounts he was a success, but he wasn’t happy. He made a decision to change his work environment with a focus on creating a place that made him happy to come to work. This single minded goal eventually led to the forming of a software company – Menlo – with him as CEO where he could create a place of work that brought him ‘Joy’.

For those familiar with the work of Ayn Rand, I found a great many correlations between Richard Sheridan and Howard Roarke from ‘The Fountainhead’. Rich Sheridan had a very single minded vision and he chose the path his company would take without compromising on his views. The book portrays how he set the direction and imposed his plan of how things should be done, resulting in a company that has adopted many of the XP practices described by Kent Beck. The business has been successful and the workers are happy, Pair Programming, short iterations, innovative software solutions and a focus on quality. The workplace includes dogs and babies and sound like a fun environment. In many respects at first appearance this is a model that we could learn a lot from.

Rich Sheridan has demonstrated the effectiveness of using Agile Practices and that success doesn’t require death marches and unrealistic expectations. Rich has shown one way it can be done, and there is a lot to admire in how he has achieved it. There is certainly a lot to learn and I think there are a great many aspects of what he has done at Menlo that could be used as the foundations of creating a great company.

I don’t build in order to have clients, I have clients in order to build…

Ayn Rand

However, much as I admire Rich and see him as a modern day Howard Roark, it is because of that comparison that I also have a number of reservations. Rich himself refers to the book “Good to Great” and he acknowledges that he is not a Level 5 leader, this was an assessment I shared whilst reading the book. All his decisions were about creating Joy for himself, but there were dozens of examples in the book of absolutes, where his vision may not be compromised. I got the impression that he made all the decisions, he decided a process and it must be followed, if someone wanted something – such as the wonderful example of babies in the office – they asked him. The decision to allow babies in the office seems to be as much about wanting to be regarded as a great boss as anything else. That is not a bad thing but I am assessing this in terms of a model that can be replicated.

Rich is uncompromising in his objectivism and Ayn Rand would be proud. Which is only half a compliment, I always admired Howard Roark, for a while he was an inspiration for me, but at some point I realised that taking input from others didn’t automatically mean you were compromising your principles or were weak, we can learn and adapt and improve but still stay faithful to our principles.

Recruitment and single person decision making

His recruitment policy is a great example of what I see as this type of blinkered thinking. Rich has introduced a recruitment policy designed to prevent making mistakes in hiring. The problem is that his solution is to require two separate interview days, and then a 3-week trial, and after this they make a decision and the vast majority will be unsuccessful. Anyone else see the flaws in this?

To get hired you must give up 17 days for one interview. For most people with jobs that is not even close to being possible, and for an good candidate looking they will likely have multiple options open to them and this level of barriers to entry makes it highly unlikely that any good candidate would bother or be able to apply. Therefore he is limiting his recruitment to the unemployed and graduates that are able to meet his interview requirements. Now this pool will contain some good (if inexperienced) candidates, but the process has excluded so many other great candidates that I think it is an example of a process that has forgotten what the problem is that it is trying to solve. In this case I assume to hire great employees.

He clearly loves face to face communication and paper based systems and estimation using hours. Therefore everyone must comply, everyone must communicate face to face, they may only use paper based processes and must use hours for estimation. It is not that I am questioning whether the decisions are good or bad, clearly he is getting many right – he wouldn’t be successful otherwise, but it is a company built around a single individual. He is seemingly a strong CEO and charismatic leader, but that leads to an unsustainable business model, where does it leave Menlo when he moves on? What is his succession plan?

Using Agile practices doesn’t make you agile

Menlo use a variety of Agile practices, mostly from XP, but from the way the book describes it they are a set of rules fixed in stone, thou shalt do it this way…

The practices chosen are good practices, but I don’t think that Agile is about using best practices, I think it is about a mindset of improvement. Menlo had adopted a variety of practices that generally I support and endorse, but I didn’t get any sense that there was a culture of reflecting and improvement. Retrospectives did not seem to be part of the accepted practices at Menlo. This for me was the saddest omission, without retrospectives Agile is weak and ultimately cannot survive in the long run. Menlo seem to have adopted 11 of the 12 principles, but it is the 12th that I value most.

I so wanted to enjoy this book, it is one I had looked forward to reading for a while, but in the end I was left feeling that Menlo was actually on the wrong path. Not that using XP was wrong, but if you have a culture that is not always seeking to improve it will eventually fail.

I probably sound horribly hubristic, and I have not achieved the level of success Rich Sheridan has, so this may sound hollow. But Rich, please introduce retrospectives into your culture before it is too late and be prepared to let your teams guide you to improve, you may me amazed to find they have some great ideas. If you do I think you may find a way to improve on the Joy you have already found.

I think you are missing the point…

A brief story….

A team found that many of their impediments and problems with delivery were caused by a lack of access to IT operations or lack of responsiveness, they requested a member of the IT operations team be co-located with (and become part of) the delivery team. This was approved and trialled as an experiment.

From the perspective of the development team this was a major success, delivery times improved, delays were reduced and the major constraint to delivery was aleiviated. In short software projects were delivered sooner and with less complications, the overall cost of delivery went down dramatically.

However, the management team decided to remove the IT ops team member and retrurn them to their old team on the basis that they were not being fully utilized. The notion of a human resource not being fully utilized was too much for them to bear.

[Please note when I say utilization – that is on IT Ops tasks – they were using ‘slack time’ to support the team in other ways]

When I challenged this decision, I was told that they were unable to increase headcount for IT operations staff unless it could be demonstrated that existing resources were more than 100% utilized on IT Ops tasks over the course of a normal week. So anyone not 100% utilized was considered a problem for them and became a burden on other team members.

This same IT operations group has a huge backlog of work and lead times were extremely long, they were a major bottleneck for almost every aspect of the business operations. Sadly the management team did not see any correlation between the absence of slack time and the long lead times.

Too often the dependency on IT Operations and their perceived hindrance to business operations, leads to unnecessary conflicts and frustrations. Usually felt by the staff on the IT Ops teams. But it is because IT Operations are so important that they get this reputation.

How can you justify extra resource if you are not fully utilizing the ones you have?

I have no doubt this is a common story, “how can you justify extra resource if you are not fully utilizing the ones you have?” In principle this would appear to be a perfectly reasonable and logical statement, and I can understand why many management teams fall into this trap. But it is the wrong question.

What troubled me most was that we had demonstrated that the impact and delays suffered by the delivery team in just this one example were actually costing the organization so much that they could easily pay for 5 or more additional IT operations staff with the benefits gained. And more so that this situation could be repeated all over the business. The response from the IT Ops manager was that I was missing the point, and they couldn’t justify underutilizing staff. Their measure for success was maximizing utilization of staff, and not supporting business goals, like say profitability.

I see this mainly as a failure of the business, for not making clear to management where they contribute and how they impact on the larger business objectives. That combined with a manager that either doesn’t see or doesn’t challenge this omission leads to perpetuation of dysfunctional behaviour.

Managing resources effectively not efficiently

I apologize for comparing people to resources, but in this context it is applicable.

Could you imagine if that same principle was applied to other resources? Your PC would be taken away if you didn’t use it 40 hours a week, you would be forced sell your car because my guess is that you only use it 10% of the time. You would wear the same clothes every day. Cooking would be a nightmare if you could only have food where all ingredients took exactly the same amount of prep time and cooking time. I’m getting silly now but it is the same principle, by totally ignoring the reason why we have a resource and focusing entirely on maximizing it’s utilization we behave in really rather perverse and contrary ways.

In any other context the notion that anything less than 100% utilization prohibits buying a second item (regardless of how beneficial) is plain nuts.

Please do not misunderstand, I am not encouraging waste by this, I am encouraging understanding of how resources are being used. When you are meeting the business goals and your flow is optimized, that is the time to look at whether reducing waste is possible but to do so in a way that ensures that any reduction in waste is not hurting business goals. It may turn out that just like your car, the optimum utilization is less than 100% and availability and responsiveness are valued higher than utilisation.

Summary

In this situation, I am very proud to be “missing the point” and I wish far more managers would take the time to understand how their role impacts the larger business and perhaps they too will miss the point and start asking important questions. IT Operations in particular are the lifeblood of so many businesses and their actions can make or break a business, understanding all the areas of the business that IT operations supports and how the cost of delay is often significantly higher than the individual cost to operations of that task or that ‘resource’. The ability for IT operations to prioritize and react promptly to the needs of a business is a far better measurement than measuring utilization of staff.

I’d highly recommend that anyone in IT Operations reads the book The Phoenix Project by Gene Kim, and ensure that anyone that benefits from the service they provide also read it.

Understanding how you contribute to the goals of the business is so important, and if after that you truly believe that your role should be maximizing the utilization of resources and not supporting the business achieve it’s goals, then I would suggest it may be you that is missing the point.

STL Agile Open Space 2016 – Self-organising teams

I spent Friday at the St Louis – Agile Open Space 2016. [On Twitter see #stlopenspace ]

It was a fantastic day with a great group of friendly and enthusiastic people all eager to learn something new, I went along with a few of the other coaches from Asynchrony. All of us expecting something different from the event, being new to the area for me it was as much about meeting a few people as it was about learning, but it was such a good experience. And as it always seems to be the case, I learn a little and in doing so I discover how much more there is that I didn’t know that I didn’t know. The sheer wealth of my ignorance grows daily, but I learn something knew and I share what I can, and hopefully it balances eventually.

Self-organising teams

Did you know Dr Seuss was in favour of self organising teams?

There were a number of topics and discussions that drew my attention but the first that I want to share was a discussion on shelf-organising teams. A topic I am always very keen to discuss. The topic was raised by a Scrum Master whose team was moving in this direction and so she was asking for advice and to discuss experiences. Both internally to the team and how this would work with the rest of the organization.

The conversation was free flowing and we covered all sorts of aspects of the concept, as you can see from the post-it summary the conversation touched on whether a self-organising team should have a hiring budget and should be empowered to hire their own team, what the role of a Scrum Master should be in this environment. Even a somewhat controversial discussion on whether the team should be able to choose it’s own metrics and forcasting style when they are ‘consumed’ outside of the team.

Can there really be self-organising teams

The first discussion was one of hierarchy, there was an ‘acceptance’ for lack of a better word- by some of the group, that there is an actual or implied hierarchy and that a team has a manager or the PO or the Scrum Master, or the Team Lead is “in-charge” there was a variety of experiences and opinions on this. But we talked about what-if the team was truly self-organising, and if there was no hierarchy, could that and would that work. And how it could/would work.

I think we broadly agreed that there was no absolute need for hierarchy and a team could build a situation where there was shared responsibility and accountability (Yes I did manage to inject my favorite 5 dysfunctions of a team discussion to describe how you can build the layers of teamwork necessary to enable this to happen) I would say that we broadly agreed it was possible, but there remained a question of how practical or realistic this was in all cases.

We generally agreed that the team most of all needed a common goal, they also needed to have a level of competency, self-motivation, the ability to collaborate, and to have trust and respect for each other. We also broadly agreed that continuity of teams was important – teams that stay together longer are generally better, not a universal truth but as relationships are built over time it can be damaging to break up a good team.

Most people felt there were boundaries for how much empowerment a team could have in a pragmatic context. Growing teams, difficult personalities, changing products/projects and changing needs which impact team sizes. We talked about whether you could allow an organization to sort itself into teams and what the implications of this would be, especially in organizations where billing structures are based on team size or it is service driven.

The conclusion we drew was that a team should not be limited in what they consider possible for improvement, nothing should be off the table. If they believe they are better growing or shrinking or working a 30 hour working week, then any and all are reasonable proposals that a self-organising team could make. But we work in commercial environments and often a larger structure, we do not live in a bubble and for pragmatic reasons we must accept that there will be some boundaries imposed by the organization or indeed by law. But we should be pushing those boundaries and if we are told ‘No’ to something we genuinely believe would improve the team we should push those boundaries and challenge, ask why, and why again.

The Role of the Scrum Master

Does a Scrum Master or team coach fit in this context? This was a fun one to discuss, if you accept that there is no hierarchy and a Scrum Master is simply a role on team equal to any other, they are just one more specialty skill that a team can organize, they may choose whether they want or need a dedicated SM or shared SM or even need one at all, the same applies for a coach. However, there were some caveats here, a Scrum Master or Coach has a duality of purpose and whilst they are idealistically organized by the team, they also have an implied independent obligation to coach the team in to independence – and that probably includes independence from the Scrum Master. But again the choice is the team’s. A good Scrum Master will encourage the team to push boundaries and challenge themselves rather than using the Scrum Master as a crutch. We had a slight aside here where we discussed how a Coach or Scrum Master can grow emotionally attached to a team or teams and can find it difficult to detach themselves.

But in a Scrum team that is moving towards self-organization the role of the Scrum Master is clearer, they need to turn their focus away from the team, to step back and enable the team more independence, and create an environment where the team embraces responsibility and accountability, they are not only empowered but are encouraged to explore it. But at the same time the Scrum Master should turn their attention to the organization and protect the team, push for the team’s decisions to be respected and supported, coach the organization on the merits of empowering the team. Again this should be a role that lessens as the organization becomes accustomed to a reversal of hierarchy and lessen further when the organization begins to feel the benefit of the team organising itself.
Summary

This was just a few highlights of just one discussion of the day, I managed to attend 6 or 7 discussions or presentations and I may get time to write up some more of my notes in the coming week, but I hope this gives a flavour of the content and of the openness and enthusiasm of the participants and the shared knowledge and experience that was in one place. Companies and individuals sharing ideas and advice.

I thoroughly enjoyed my day and I’m looking forward to the next event.

Why do we use WiP limits?

I participated in a great discussion this week on the use of WiP limits. For those that don’t know, WiP stands for Work in Progress, and is a measure of how many activities you have started but not completed.

It is important to note that this is not a measure of how many tasks you are currently actively working on. If I started a task but have become blocked, so I start another then my Work in Progress is 2 – even though I am only actively working on one. WiP is a measure of how many started but incomplete tasks I have.

For example: call-waiting or being put on hold during a phone call: You are talking away and get another call so you switch to the second call without hanging up, and when you get another call you take that too, how many people can you have on hold at once? You are only working on one call at a time, although you must remember the content and context of all those other calls. For the people still on hold while you have all these conversations I expect they are wishing you had a WiP limit. Your WiP-Work In Progress is the sum of all active(incomplete) phone calls.

Limiting WiP

There are many reasons for limiting Work in Progress not least because I hate being put on hold. I will go in to some later and it is likely that if you follow any type of Agile framework you already limit WiP although you may not be consciously aware of it.

If you have a backlog, then you are limiting WiP. You are consciously choosing not to start new work immediately but are prioritising it and organising it to work on later. It is likely that you are informally limiting your WiP according to what you feel you or your team can manage at a given time. It is important to realise that this is a WiP limit even though it may not be conscious or scientific.

If you follow Scrum: WiP is consciously and explicitly limited at Sprint Planning, often by estimating effort, or counting stories or calculating story points. The limit is generally set based on Velocity – our average achieved over previous sprints. If on average we finish 10 stories a Sprint, or we average 35 points, then that average is generally taken as the starting point for our WiP limit, we may choose to push for a few more, or if we are expecting to be slower due to vacation time, or known issues we may choose to commit to less. But in Scrum we don’t usually refer to it as a WiP limit. But that is exactly what it is.

KanBan is actually very similar, if we on average are completing 10 stories a week, then it is likely that we will consciously or subconsciously limit ourselves to only take on 10 new stories within a week, although in the case of KanBan this is not done in a Big Bang explicit decision but gradually over the measured period and is more a consequence than a plan (A Pull rather than a Push). We pull stories when we are ready and we pull at the pace we are working at, that just happens to be 10.

Slightly off-topic, but one of the crucial differences between Scrum and KanBan is that Scrum is a ‘Push’ model and KanBan is a ‘Pull’ model. In Scrum we Push an amount of work to the board and spend the Sprint working to Remove(complete) it. With KanBan we are aiming for a more steady amount of Work in Progress and will pull new work as current work is completed, which creates a smoother flow, but conversely lacks a unified time based goal or target. But it is important to understand that both frameworks limit WiP and both focus on ‘completed’ work being the primary objective.

Why do we limit WiP?

I’d like to think it was obvious by now and I think the basic principle is, but there are nuances that may complicate things which may be where the cause for debate comes from.

At it’s simplistic level if I can only complete an average of 10 stories a week/sprint then starting an average of 20 a week without changing anything else is nuts, all that will happen is that on average 10 or more of those stories each week will remain incomplete and stay ‘in progress’ by the start of week 4 we will still have completed 30, but will have 50 now in progress. Chances are by now we will actually go slower because we will be distracted and falling over ourselves trying to juggle more than we can possibly achieve.

Think of all those people on hold, growing frustrated at being ignored, and you trying to remember all those conversations, the phone rings again, can you cope with another caller on hold?

We limit WiP because we understand that by working only on what we can achieve, we can focus and be more effective.

Limiting WiP and WiP limits

“Ah but you have talked about Limiting WiP but you haven’t mentioned WiP limits” I hear you say…

And this is where I think the conversation really stems from and where we get into nuances. KanBan began in manufacturing where work was passed from one workstation to another and there was a measurable flow through the system. Limiting the production on one workstation so that it maintained pace with the entire system limits waste. Having one hyper-performing efficient widget maker that can produce widgets 4 times faster than they can possibly be used is wasted effort. And the same applies to a software process, we use WiP limits to regulate one part of the flow to maintain pace with the flow as a whole, the goal is to visualise bottlenecks and by visualising bottlenecks we can take steps to increase the flow of the whole system.

Other forms of WiP limit

But WiP limits can take many forms and are applicable to almost all aspects of life. The most common example used is a highway, when a road gets busy it slows down, when it gets very busy it grinds to a halt. Limiting access actually speeds things up for everyone on the road, and ultimately more cars can get through far quicker.

But there are other less obvious WiP limits. A long-distance runner wants to increase her times, she starts fast but she runs out of energy and is slowing down near the end of the distance. By setting herself a slower time per mile early on (Pace is a form of WiP limit) she has a consistent speed and reserves energy so is able to run the full distance faster by slowing down during the early part of the race.

Are you dedicated to a single product/project? That is a very low WiP limit of 1 project.

Do you use a calendar and try not to book two meetings at the same time, that is a very tight 1 item at a time WiP limit.

What about a budget? Do you manage your finances as an individual or company. A budget is a WiP limit for your money, by limiting money spent on beer you have more available for clothes. By regulating your spending you can save for a holiday. By remaining in credit at the bank you do not have to pay interest and so on.

Example of how to choose a WiP limit in a workflow

In the case of the widget maker, if the system can only use 10 widgets a day then we may set his WiP limit to 10, when he gets to 10 he is free to go and help someone else. Suddenly rather than unused widgets we have an extra pair of hands to do other work. But hold on! these widgets are easy to make and only take a short while to do, we could probably limit WiP to a lower limit and jump on the workstation as an when needed to produce more. So how do we set the WiP limit? My advice is not very scientific at this point. Start by continue doing what you currently do and just watch, if your workstation/activity columns are sub divided in to doing and done, take a look on a regular basis and see where the biggest stacks are. If one column regularly has more cards on the done column than doing, it ‘may’ be a sign that you should reduce your WiP limit for that activity. Try it and see if it improves your flow.

The largest queues of done work are usually the area that needs limiting, but be aware of ‘bursts’ of activity, for example there may be a workstation that is only available for one day a week, in which case the queue for that workstation may need to be longer – or maybe you should be asking for more regular access to the workstation. But when imposing limits do it gradually and monitor to see if it improves the flow.

Anything in a done column is normally waste, if it is done and not in production that effort cost you money and is just sat there. Sometimes that makes sense but the car industry learned that complete cars sat in storage amounted to $millions of wasted investment, that components stockpiled in advance was essentially big piles of cash that could be used more effectively, we can learn the same.

What I am saying is that a WiP limit being reached is a conversation trigger, a long queue is a conversation trigger, and so on. With so many things in Agile we create early warning systems to create conversations and make decisions when it is necessary. We make small changes to the process and watch, we see what changes and if it is better we carry on, but look for another new small improvement.

Summary

WiP limits are not unique to KanBan, and like it or not you are already limiting your work and activities in all aspects of your daily life, you just perhaps didn’t realize it. In the context of a KanBan board we do not arbitrarily impose a WiP limit because we can or because it is fun. We impose a limit when we feel it adds value, normally where we see a queue of completed work growing faster than it is being consumed. We limit various stages of the work because our goal is the output of the system (the whole team) and not the perceived utilization of individuals. One team member being 100% occupied all day producing something that will sit untouched for a week is not efficient.

We are not trying to manage a system where our goal is to keep busy a group of individuals, our goal is to create a cooperative and coordinated team working towards a common purpose in the most effective way possible. A WiP limit is just one of many tools that can be used to enhance the prioritisation of work and focus the team on the true goal.

Reading a Cumulative Flow Diagram

This is a very brief introduction to Cumulative Flow Diagrams, at the end I have included a link to a more in-depth explanation.

A cumulative flow diagram is very simply a fancy way of showing the status of a TO Do list or in Agile terms: a backlog of work – but is in reality just some very basic information in a pretty graph format.

Take a simple To Do list. I have 10 tasks, they can be “To Do”, “In Progress” or “Done”

We represent this by turning these blocks 90 degrees clockwise and stacking them:

What does it tell you?

Ideally the graph will trend upwards, with the Done section ever increasing until all tasks are complete. The axis show number of items on the y, and time on the x

We are interested in how steep the done section is as this tells us our true progress and our task completion velocity (not to be confused with Story Point Velocity). In theory we should be able to draw a line based on the trend line to predict when the remaining tasks will be done. However…

We are also interested in the rate of increase in the ‘To Do’ section, if we are adding tasks to the list faster than we are completing them the list will never be completed. So we are watching for the ‘To Do’ to level off and eventually stop increasing or at least be slower than the done. Otherwise we will have to draw a metaphoric line in the sand and say this is all we will do. In the previous example we had a fixed task list, but normally we do not.

In Agile projects we often analyse requirements and write stories as we progress – “just in time”, stories are added all the time to cover the next few days or weeks ahead and so you will often see the To Do section rising in line with the Done, but at some point the project has to end and at that point we stop adding stories and will complete. This is likely the most efficient way to get work done but make forecasting difficult. Too much up front planning is likely wasteful.

Finally we come to the most important part of the graph, the “In Progress” section. It is a measure of efficiency of a team how few tasks are in progress at once, lean techniques will sometimes measure the average ‘flow time’ how long tasks are in progress or the ‘Mean cycle time’

Teams should be striving not only to get things done, but to limit the Work In Progress,

In this graph the team were taking on more tasks, they look busier, but as you can see from the Done section, the slope of the Done is more shallow, ‘Doing’ was as the expense of ‘Done’

If you look at the graph the average time to finish a task at the lower point was around a week, but then by week 4 tasks are taking an average of over 2 weeks, it might be that they are bigger tasks or it might be that they are multi-tasking which is slowing them down. Watch for teams that take on more ‘In Progress’ it is a sign of problems, the team should be consciously aware of how much ‘work in progress’ they have and that it is manageable.

The real world

Graphs like that are rarely seen, most projects have a change of scope and will fluctuate, below is a graph taken from a real team:

The first comment that needs to be made clear is that this graph shows all items in the To Do list, some are very small tasks, some are huge, the size is not reflected, only the quantity. A small 2 hour spike and a large 20 point story are measured the same.

In this example we have two ‘In Progress’ states, the first is Approved, this means the story has been written, broken down, refined and in some cases estimated by the team and Approved as being suitable to work on. The ‘Committed’ state is work that is currently being worked on by the team.

‘New’ is the To Do list, and as you can see it is steadily increasing, or was until recently and then it took a dip, the dip wasn’t reflected in either the In Progress or Done sections which means there were stories removed, likely they were not relevant to the goal at hand.

You can see from the graph that tasks started to get moved to Done after the first week or so and have steadily increased apart from about 50% of the way through the graph when there was a notable dip in the Done section. Under normal circumstances Done only ever goes up, so this is a cause for interest for someone reading the chart. It is likely that a story was either thought to be Done but wasn’t and was moved back, or the solution was deemed unwanted and removed, either way it deserves comment.

The ‘In Progress’ is fairly consistent, a few times the ‘committed’ is widening and this may warrant exploring why but generally it is pretty steady. The number of items “Approved” is very narrow and may be a reflection of a problem, if there are insufficient stories available for maintaining pace. It is important when doing “just in time” preparation to get the balance right between having enough to sustain pace and too much so that there is waste.

Summary

As you can see the graph, like most graphs doesn’t give all the details. What it does do it prompt the need to ask questions when it deviates from the norm. It is unlikely you can determine the answer to your questions from the graph, further information will generally be necessary, but it can help you form the right questions.

if you are interested in reading a more in depth description of how these diagrams work please ready this Blog

Is structure supportive or restrictive?

I have been engaged in a discussion along these lines with a colleague over the last few days, it is a subject we both are interested in and one that I have been very much on the fence.

I began from a position of a very strong belief that structure was beneficial and that it provides a scaffolding that enables teams to grow. But my colleague took the view that once in place the structure becomes at best a crutch and at worst a barrier to self-organisation and agility.

This conversation is the basis for the usual discussion on whether a Scrum Master is necessary or should they make themselves redundant. Or – Do we need a designated product owner or simply a better understanding of product ownership?

Even to the point of whether there are any designated roles within the team, do we need to identify Devs, Testers, QAs, UX, BAs etc etc or can we consider all “Team Members” that are ‘T’ shaped, that is to say that whilst they possess specialty skills they are first and foremost team players able to cover most of the core software delivery skills.

Baseball

I am (very)English, so my knowledge of baseball is minimal. But today I had someone explain the finer points of ERA and ERA+ and some of the other joys of the statistics of baseball. I can sense you preparing yawns at this point so I shall go no further. But the conversation progressed to “Designated Hitters” players who do not field, they have a specialist skill, or are able to stand in to save the pitcher from batting (another dedicated role?) I may have misunderstood this, but it was described as an “abomination to the sport” by someone that clearly believes that it is a sport where the players must participate beyond their specialty. The converse argument presumably is that if you have exceptionally skilled specialists why should they need to participate in other roles – the team is more effective as a whole by them specializing. Okay so I am stretching the analogy a little, but the argument holds.

Should we specialize

Specialism may aid the efficiency or the effectiveness of the team, but is it still a team sport and can a team ‘self-organize’ if there a members that can only fulfil a specialty role?

And let us suppose that we have two expert catchers, and they have no batting or fielding skills, there is no benefit to having both of them on the team. And what if our best catcher is also a good outfielder, do we use our second best catcher in the catcher position because he only has the one skill?

My view started with the opinion that the most effective teams I have worked with had both a Coach and a Product Owner, that specialism in those roles is necessary to achieve the focus necessary to be optimally effective, both individually and for the team. In the case of the coach his input magnifies the team at a higher rate than adding another team member and for most medium or larger teams the product ownership tasks are demanding and require one person to have a view on many aspects of it – albeit that the team can and should be involved as much as possible.

I stand by this position, if our only goal was the effectiveness of an average team in average circumstances.

The problem with this situation is that there is an implied hierarchy, and that the appointed people in those roles may not be the best choice, that members of the team if enabled may be able to take on some or even all of those responsibilities. Essentially those enabling roles also become limiting factors to growth.

So long as there is a coach there, some of the team will use them as a crutch, the implied hierarchy may disguise or suppress dysfunctions, the coach may be more valuable elsewhere or in another role but is constrained. The same for Product owner, they can easily become a bottleneck as much as a facilitator/enabler. And let’s be frank how often is the workload for a coach or a product owner approximately 1 full-time employee. Chances are one or the other or even both will be grossly over or underworked and consequently stressed or bored.

The teams will never become completely self organising in those situations. Not until enough of the team are skilled and effective in those roles and are able to internally organize themselves. And that can and will only happen if they are allowed to grow into that.

What to do?

But of course just starting on day one and say “go organize yourselves” would be madness in most circumstances, the skills are not off the shelf skills and generally come more from experience than teaching. But having guidelines or even common practice of teams of that structure creates an expectation of what ‘good’ looks like, and it becomes a self-perpetuating concept.

My belief and I am conscious I may be a minority here, is that we provide scaffolding, but from the outset make it clear that the end goal is independence from constraint, that the structure presented is to enable learning and will eventually be removed. That we take our ‘T’ piece team members and we encourage them to diversify further, to become capable and aware of more skills. We support specialism, specialty skills ARE valuable but all rounders are more valuable.

Say no to designated batters…

We don’t want designated batters, we are a team, and in a team we still function near to 100% if/when we lose a player. If that means we lose some specialists because we favor all rounders, perhaps that is a risk we have to take. I don’t believe this means that we compromise on quality, it just means being more open to learning other skills.

Coaches should focus as much on teaching and enabling independence as they do on effectiveness. The pragmatist in me still believes that we are a long way from this ideal, and that in most cases the teams will likely organize themselves with designated product owners, QA, UX and Devs, as inevitably there will be some people that are more skilled than others, but I would like to see us blurring those lines to the point where it is difficult for an outsider to recognize.

The teams will likely still desire coaching and support in difficult situations, I am still of the opinion that we all benefit from coaching (even/especially the coaches), but if this can be owned by the team and it can be their choice as to who and how performs the roles we will be much closer to the goal of self-organization.

A lofty goal and one that will likely have a few hiccups along the way, but I am beginning to believe that we can use the scaffolding of structure to be a stepping stone to self-organization.

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.