A tale of two engineers.

There are two ships traveling a busy shipping route, each ship has a complex engine and the engineering team has a chief engineer. Both ships are a similar age and size.

The first ship has a very busy chief engineer running this way and that, fixing any and every problem that comes up, he knows every inch of the engine and many parts of it are custom made by him. He is dirty and oily and hard working, whenever there is a problem – and there are many problems – he is on hand to fix it. He is dedicated and hard working, he works long hours and is always ready and willing to get his hands dirty. Without him the ship couldn’t function.

The second chief engineer has spent his time not fixing things, if a part is unreliable he has replaced it, if a component is troublesome it is gone. If there is a problem he ensures one of his team fixes it (with guidance initially) and will encourage them to spread the knowledge so that after a while he rarely if ever gets his hands dirty. He is rarely dirty or oily and it is a very rare situation to see him fixing anything. On many voyages he can seemingly sit there with his feet up doing very little in maintaining the ship and can use his time on other productive activities. Frankly if he missed a voyage the ship would probably run just fine without him.

Now which in your opinion is the better chief engineer?  I know which one I would rather have on my team.

It is often said that the goal of a good Scrum Master is to make themselves redundant, I take exception to this a little I think as in the tale above it is possible to create a situation where you are not necessarily needed all the time. But I wonder how long a team would last as a top-performing team if the Scrum Master was taken away, perhaps in the short term no one would notice, but growing and shaping and coaching a team takes time and effort, but slipping back into bad habits can happen quickly. Creating a situation where the Scrum Master has time to do other things is a good thing and a reflection of success not a sign he is not needed. A Scrum Master that is essential to a team is one that has failed, in fact if ever you feel you have an employee you are overly dependent on you have a serious issue.

How many top athletes would say “I’ve reached me peak I no longer need my coach”? My guess is that if they feel they have reached their peak they will seek out a new coach that can push those limits further.

A good coach or Scrum Master guides the team to independence, and then pushes their limits further.  They may be more useful elsewhere but that is very different from becoming redundant.

Advertisements

It’s my way or the highway…

The last few months have been pretty busy for me and so I have dropped out of the online community for a while. Over the Christmas break I had some free time and so I ventured back in, caught up on some reading and tried to get a feel for the common issues of the day.

What I found was post after post condemning just about all things ‘Agile’    

“Ban the use of Story points”

“Agile is dead”

“Scrum/KanBan should be sent to the scrap heap”

“We don’t need: Scrum Master/Product Owner/Agile Coach/QA” 

There were some even suggesting that Agile had run it’s course and we should go back to Waterfall.

I found all this very disheartening, on one hand most of these were from people presenting a new idea or new techniques, and it is sad to say but in our culture it seems the only way we seem to know how to sell something is by presenting everything else as bad or with Click Bait statements, we all want to get noticed.  But when did ‘Agile’ become so black and white?

For me Agile has always been first and foremost about inspecting and improving – finding better ways.  But that doesn’t automatically make anything that differs from your approach Bad.  And it certainly doesn’t make everything New to be Good.

There is not one Right Way.

In almost every case the examples/justifications were examples of poor implementations of Scrum/Kanban; incorrect use of Story Points; or a person being ineffective in a role, or in some cases there were teams that had matured to a point where they were no longer getting benefit from a tool or a role.

But not one of those examples makes the tool or the role Bad.   In each and every case the team should inspect and adapt, and identify improvements.  If one team decides that Story Points do not add value for them, that is great, that team has found a better way that they can deliver software.

But that doesn’t mean that other teams that find them effective are automatically doing it wrong. If you find you can use a tool effectively and it works for you, then use it. Just keep inspecting and improving.  If a tool doesn’t work for you or you find an alternative tool that works that is great too. But try to understand why you are using a tool, what is your desired outcome and is there a better way for you.

As an anecdote, I was using a drill to make holes to hang shelves, I carefully marked and measured and then drilled. A friend was with me and he picked up a cross-head screwdriver lined it up on the wall and hit it hard, punching a hole in the plasterboard wall, far quicker than I was doing with the drill.  The technique was great for him in that situation, but when faced with wood or brick it was not suitable, and in both cases I still needed to measure and mark.  

Tools are context AND user specific, what works for one user in one situation does not automatically work for all users in all situations.

The same goes for the roles argument, I agree that there are some teams that have the versatility, the right mix of people and the capability to work effectively without one or all of the roles, but that doesn’t mean they are an ideal we should all strive for. Many teams find they are far more effective with those roles, and I would consider that to be just as much an ideal state as the other. If your team is effective and improving then you are demonstrating an Agile mindset.  Our goal should be to improve how we deliver software, not strive for someone else’s idea of utopia. Concentrate on improving YOUR team rather than mimicking another team in a different situation.

Declaring your way the only way is not demonstrating an Agile Mindset.

Explain the benefits, do not attack the alternatives

If you find a way that you feel works well and you want to share it, then explain what problem it solved and why you felt it improved the way your team worked, share that example, but please don’t do so by declaring all other tools WRONG.  What is right for you may not be right for everyone. You will just sound like a Snake Oil salesman.

Don’t reinvent the wheel

Having said all that we don’t need to reinvent the wheel and discover everything ourselves. We can benefit from other people’s experience and advice.

Both Scrum and Kanban and any of the tools mentioned can be badly applied, but when implemented with the guidance of someone with a genuine Agile Mindset (rather than a blind by the book interpretation) they can be excellent foundations from which you can evolve, by inspecting and improving, they are not the end point but a safe and structured starting point.

The same applies to the named roles, having someone with an Agile Mindset that can help create a foundation of understanding of the roles and when and where they add value can provide a structure and consistency that allows you to grow from a starting point that has proven to be effective for many.

Do not stand still.

But most of all, whether it be Story Points or the need for a QA, inspect regularly, assess what problem you are trying to solve in terms of outcomes, if you feel a change will show improvement then experiment and review.  Small changes are generally preferred, it is easier to see the impact and easier to undo if the results are not what was expected. Understand what you are changing and why so that you can properly assess whether the change was beneficial.

I have seen teams conclude a Scrum Master/QA/Product Owner is not necessary after all they can cover the role themselves (usually as the result of cost saving measures or because they are presented with a false notion that good teams don’t need help). Sometimes this works, but more often the responsibilities are performed less effectively when distributed among the team and so the net result is a reduction in the effectiveness of the team.

There are certain expertise and mindsets that often come with a role that is not fully appreciated until it is gone. This generally and understandably gets neglected when it isn’t the core responsibility of the team members.

Let the team decide

If a team feels they need a change I’d have far more confidence than if the decision was made by someone with little or no exposure to the team, or on the back of reading a blog suggesting “good teams don’t use Scrum Masters/Story Points/Scrum/etc.”

Why Scrum so often fails

I should start out by saying that I am a big fan of Scrum, I think those that devised the framework possessed an agile mindset but also were mindful of human nature. They created a framework that had in built checks and balances and prescribed solutions to many of the most common problems. They also had an understanding of system level thinking – I’ll come back to that later.

The core of the system though are the core roles Scrum Master, Product Owner and Development Team. This triad is what makes Scrum so successful (when it works) and in my opinion it is the absence of this triad that is the root cause of the majority of the unsuccessful adoptions.

It is all about the mindset

However, I don’t think it is the role that defines this triad but the perceived mindset behind the role.  Having a team that possesses a strong member with an Agile mindset, and the knowledge and skills to support it and the opportunity to focus on it; having a strong team member with a Customer mindset, a desire to engage the customer and ensure they get what they really want, and finally a cross functional development team with a strong Production mindset – that of delivering a well designed, high quality and maintainable product.

Scrum assigns named roles because they believe this give the best chance of having those mindsets on the team. But sadly it doesn’t guarantee them.  There are far too many Scrum Masters that understand the rules, but do not have an agile mindset so create cargo cults and many product owners that build what they want not what the customer wants.  And many development teams that over-architect, over-engineer or pay lip service to quality maintenance and even design.

scrum-master

The flip side is that you can create Agile teams without team coaches and without customer representation, sometimes they are very successful. But my assertion would be that on those teams there is someone with an Agile Mindset and calls out the team when they deviate, there is someone or multiple people that make the customer voice heard and engage them often and there is a cross functional team dedicated to building the product right.

In essence I am saying that Scrum fails when those in the named roles fail to live up to the role. And that in cases where a role isn’t named someone or more than one steps-up into that role. But in either case if those mindsets are not present on the team it is a recipe for failure.

Agile is a Mindset not a Rule-set

Scrum fails in essence because we assume a Role is the same as a Mindset. In this case Correlation does not imply causation. There are many great Scrum Masters and Coaches out there who posses an Agile Mindset, but sadly there are also a great many that lack it and see the role as the application of a rule-set rather than the application of a mindset.

System Level Thinking

This failure of mindset extends to the tired old conversation of Scrum Masters (and coaches) making themselves redundant on a team.  There is a lot of talk about whether or not a Scrum Master(or Product Owner – or QA or designer etc etc) would be fully utilized on a team.  Utilization of resources is a point of frustration for me (Note my deliberate use of the word resources). If you are concerned about maximizing utilization of someone then you are failing to see them as a person or see the value they provide and they have been reduced to counting the number of hours they occupy a seat.

A coach does not become redundant on a team when the team performs their tasks for them, a coach becomes redundant on a team when the team develops an Agile mindset and has the skills and knowledge to apply it without the coach’s help (and even then I see value in a diverse perspective). Utilization should not even be a consideration, value to the system should be the consideration. The same applies to the other roles – PO, designer, QA etc.

It is all in the name

Naming roles on a team is a risk, as I have described above if you get the wrong person it can undermine the balance, there is also a risk of knowledge siloing, and perceived expectations and divisions of labour when you name a role by areas of responsibility.

But far, far more damaging in my opinion is giving names that imply authority. Any type of named leadership role embedded on a team (Manager, Tech Lead, Team Leader, Architecture Lead) immediately stifles opinion and inclusion and undermines self-organisation on a team. Where roles like Scrum Master and PO stifle horizontal knowledge sharing, hierarchy stifles everything – so in my opinion this is far worse.  If someone possesses a greater technical understanding there is no need to anoint leadership, it should be self-evident, and if it is not evident to the others on the team then likely the leadership title will subvert rather than support.  Equally A self-organising team should not need a team leader or manager.

Ultimately it comes down to balance.

If you believe a team will be able to balance the three essential mind-sets without named horizontal roles, then the roles are unnecessary.  If not (and I would err on the side of caution) then named roles give the highest probability of achieving this balance – especially if you have confidence in your hiring team that they are hiring for mindset rather than certifications. Those in the named roles should be sharing the mind-set as much as the knowledge.

But I if you feel there is a need for named leadership roles on a “self-organizing” team, ask yourself why you don’t trust the team to self-organize?

And finally if at any point decisions are getting made based on utilization of staff, in isolation and without consideration to the value they bring to the team. Then read the book “The Goal” by Eliyahu M. Goldratt.  It will help understand that a focus on perceived local efficiencies and a desire for maximum utilization can actually be damaging to the larger system. Or read my post on efficiency

churchill

 

 

 

 

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_off_all_things-305021

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

  1. Coaching on Agile Methods
  2. Coaching teams that have identified a need for support in certain areas
  3. Helping teams identify areas where they need support
  4. 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.

 

 

 

 

 

 

 

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.

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.