Practically Agile

As a coach it is very easy to get wrapped up in theory rather than practice, the topic itself is challenging because it is so simple to understand but so difficult to execute. We see so many Agile Transformations fail, so many poor implementations of Kanban or Scrum and at times it feels great other time so futile, the concepts are neither complex, nor new, but they are very difficult to implement effectively and in a lasting manner.

Successful Agile Software Development is in my opinion based on three similar but intertwining thought processes and if any one is absent the strength of the whole is significantly diminished.

  • Systems Thinking
  • Community Context
  • Reflective Practice and Application

Sometimes we get focused too heavily on the principles and the values but the Manifesto begins with what I think is a statement more important than the rest.

Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.

At the very heart the manifesto is about getting better at delivering software.

We are uncovering better ways” – it is a journey of discovery, we do not have all the answers.  “by doing it and by helping others do it” – It is not just theory, and we share our successes with others so they can benefit from our past successes and failures.

Systems Thinking

It sounds grand and perhaps I would be better served coming up with a less grandiose title but essentially the issue here is that YOU are not the center of the universe. You could mean you personally, or your team.

Systems Thinking = YOU are not the center of the universe

The goal is effective Agile Software Development, solving a problem for a user, with software.  Our system is the whole process from identifying a need, through to the delivery of a solution, and that solution being used to satisfy a need.

Our system is not coding; it is not moving a card from one column to the next.

Having great code on a branch that will not get to the user for months or years (if ever) is not satisfying customers, however proud you are of it. The same is true for designs or perfect architecture for features not needed .

Transformation failures

In my experience I would attribute a significant majority of unsuccessful transformations (and many business failures) as a result of a failure by members of the team to grasp that they are contributors to a larger system, it sounds insensitive, but you are just a link in a chain, a cog in the machine. Focusing too much on one small part is not helping the organisation or the system as a whole.

And yet we expend a lot of effort on improving local efficiency, and at the same time failing to grasp that your efficiency is irrelevant without context.  By focusing on your own local efficiency is at best doing nothing for the larger system and at worst making the larger system less efficient – by not focusing on what is needed.  The obsession with coding efficiency in particular kills a great many software products. I see teams actually proud of a growing pile of stories in need of testing, or a team dedicated to front end UI proud of having endless features complete against mocks and how the back end teams can’t keep up. Sadly these teams seem oblivious to the fact that they are not adding value to the system.

Community Context

Systems thinking refers to the context and the domain but within that is a team – often many teams. The teams are a collection of individuals – all distinct and all different, and your ability to work together (or not) can determine how well you are able to produce software. Teams that bond and grow together achieve amazing things, teams that fail to establish trust can and do churn without making much progress.

An understanding that software development is about people first and foremost, may sound an odd statement when media presents it as a lonely and socially awkward enterprise. But all aspects are about interactions, within the team, with users, with stakeholders, with other teams, the list goes on, but effective communication drives software development.

Those that master the understanding that product creation is a people centered activity and overwhelmingly a team activity will thrive, we build cross functional teams in the belief that self-organisation and motivated groups produce great software – and they do.

It can be tough adjusting from thinking about you as an individual to you as a member of a larger community, but when we can act in a way that best serves our community rather than ourselves we start to become a high performing team, it is worth noting that you do not create a high performing team by simply grouping a number of high performing individuals, often that is a disaster.  High performing teams arise when we learn that we are more that the sum of our parts.

The second part of this is that part of being in a community is sharing knowledge and offering support. The manifesto calls out that part of being agile is not just doing it but helping others do it.  We find ways to grow as individuals and together.

Reflective Practice and Application

Finally and this is the pillar that binds it together and makes it so strong.  We take time to reflect often, so much so that we become skilled in self-reflection and in giving feedback to others to aid their self-reflection.

I believe every team – not just technical teams should take a break and reflect regularly, no matter what you do, you can improve, but you need an environment conducive for that thought process. An hour away from your normal environment may end up being the most productive hour of your week if you can learn to reflect effectively.

Facilitating Retrospectives

Facilitating retrospectives is a difficult skill, getting past the noise to get at the real issues can be difficult and takes skill and practice, but both the facilitator and teams get better at this over time, especially if they reflect on how to improve this skill.

As a group and individually we should take time to identify learning opportunities, we continually observe ourselves and our teams looking for ways to improve. We learn to give and receive feedback in a way that helps us grow – not to diminish us.

We challenge our thinking, we question our beliefs and we look for ways to grow.

We learn how to experiment in structured ways trying new things and observing, we learn the value of metrics and measurements, both in our team and our products.

But the learning and reflection is for nothing if we do not apply what we learn, the application becomes yet another skill we can develop, may of us can become analytical and observant but continue to do the same things despite what we see.

If you always do what you’ve always done, you’ll always get what you always got

Learning to apply our observations and reflections in a structured an effective way is another challenge, and bringing this back full circle to systems thinking we should focus on the area that is holding us back the most and deal with that alone, and then repeat the process.

5-focusing-steps-113297

Trying to fix too many things or focus on too much at once can lead to confusion and particularly if you are measuring impact of changes if you change more than one thing it can be very difficult to know which one had impact.

Summary

All three of these thought processes overlap, intertwine and often depend on each other, but when bound together are extremely strong, and we can and will get better at delivering software and helping others to do it.

 

Practicing what you preach

For this blog post I’d like to make a change from my usual style and share a personal experience.

For the last few months I have taken on the role of Product Owner for a new product our company is developing. It is a bit of a change for the company as they have limited experience in developing their own products, most of the work is typically implementing work on behalf of clients where much of the product development is obfuscated from us.

It is also a big change for me. I have been coaching Product Ownership for a fairly long time now. I previously lead the company’s Product Ownership Chapter and I run a local Product Ownership Meet-Up event each month and I frequently teach Product Ownership and Story Writing workshops.
You might say I am becoming an expert in the theory of Product Ownership. So I could be forgiven for thinking I would find it easy. It is also not my first rodeo, I have been a Product Owner of sorts previously for both hardware and software products .

Before you criticize someone, walk a mile in their shoes. That way, you’ll be a mile from them, and you’ll have their shoes.

Jack Handey

It’ll be easy he said…

Maybe it is because I have been coaching for quite a while now, but the transition back has been far harder than I expected. I am (too) impatient to see progress, I am finding it irritating to write stories for things that I find obvious or repetitive. I found myself tempted to make unilateral decisions rather than involve the team; I wanted to get involved in technical decisions; initially I hadn’t made time to create personas;  I was using expediency as a very poor excuse for not doing activities that I believe add value. (all things I used to coach against). In short I am a bad bad man, and a hypocrite too.

roadmap

We did however create a pretty good Story Map and Road Map, the team got together with some subject matter experts and over a few good discussion and we developed a pretty good understanding of our road-map and high level priorities, still at a high level but with enough understanding to make prioritization decisions. We have got in the habit of writing enough stories for the next week or two and there are a good set of wireframes to enable us to start getting feedback on our designs before we commit to the code. We have found a great balance between getting knowledge value, and then delivering working value.

As the product has progressed we have maintained the Road Map turned it into a living user story map and used it for forecasting and release projections and planning, such a simple tool but so effective for enhancing communication. It’s simplicity served us well, communication became very easy internally and externally, and when when we needed to the forecast was very straight forward – and informative.

user-story-mapping

Delivery Pipeline

The aspect I am most pleased with is that one of our first priorities was setting up a delivery pipeline alongside the first stories so now every commit we are able to deploy directly to an environment reflective of our customer (no mocks) and a releasable package is created after every check-in.  I cannot understate the significance of this and how this one decision has made almost every other aspect of the delivery process easier.

There are certainly things we could be doing better, but overall I am very pleased with what we have done and I am really impressed with the team, they are an exceptional team that makes my job easy. But most of all I feel I have a much better appreciation for some of the issues that Product Owners are facing and I am reminded what a challenging and important role it is in shaping a product, conversely my hope is that I have made the team’s job easier, being on hand to clarify my understanding of customer needs, making design decisions promptly and making clear the priorities. The joy of being part of a team is that we each contribute something vital to the success and we only succeed together.

I have worked to get and interpret valuable feedback from customers and stakeholders, and as ever this is a challenging task. It would be easy to pass on every request and turn it in to a story, but this is OUR product and our role is to interpret requests in the context of our vision, and the reality is that we reject more suggestions than we adopt, every person you ask has a different and often conflicting opinion of what is needed and that filtering process is challenging and daunting, I hope I have shielded the team from the frustrations that entails. But for product owners out there this filtering is one of the hardest but most important parts of the role.

leap faith

Challenges

The role itself is paradoxical at times, some days it feels like there is little to do, but everyone else is busy, other days you are making decisions that will determine whether the product will be a success or not.

Early on in the process it was hard to convey credibility, I am no SME in the domain and our teams are not used to decisions being made in-house, my vision was questioned, it took a lot of will to maintain my course and build trust, I had a rocky couple of months. I controversially chose to go against some of the key stakeholders and not implement some features they wanted, I was vindicated later, but I knew this was a risk and could easily have gone the other way.

This is the hardest aspect of the job especially when you want this to be a team activity and for the team to share responsibility and credit, but the reality is that the role of the PO is to get feedback from the stakeholders and the team, and then make a decision, that decision can be lonely as there is a lot of subjectivity and rarely a consensus.

Product development is very different to project delivery it is much more fluid and we have evolved a lot over the last 6 months the product has grown and improved and now we have two releases under our belt and a happy customer it is an exciting time for us.

DevOps-cycle-Extended

DevOps

I cannot overstate how happy I am with the team or how successful I feel this has gone, I feel like a minor player in such a great team – which I hope is reflective of how well we have worked together and that it means I played my role effectively – although I am pretty sure I was the bottleneck more often than I would have liked.

I will say that we got lucky with the first customer and the support of stakeholders and the team have made it very easy for me.  But the one thing that has made this most successful in my mind was the decision to deploy the very first story to a production like environment – that one decision set the stage for a smooth progression and confidence with every subsequent story. I’d encourage that to be the first decision any new team makes.

I was doing a demo the other day and as I was presenting I am thinking (with a disappointing amount of surprise) “Wow – what an amazing product this is” it looks as good as any product out there. Somehow being involved in the process meant I didn’t take the time to sit back and see what we had achieved until that moment.

This is only the first major release and we have many more to come as the product evolves and customer numbers grow. Naturally there are still a few quirks to iron out.

It is my hope that I have learned a lot from this project and be able to use the experience to be a better coach, I’ll be more able to empathize and advise with Product Owners and perhaps be more confident that when challenged I can still apply some of that theory and speak with confidence when I am coaching others.

I hope you will forgive the obvious pride at being part of this team, but aside from that it has served as a reminder to me how difficult being a Product Owner is and how much software is a team sport and the whole team should take pride in the outcome, without any one of us it would not have been successful.

 

Feedback is not a passive activity

In Lean manufacturing setting up feedback loops is considered a critical part of the operation, so much so there is a term for this – Andon – a system to notify management, maintenance, and other workers of a quality or process problem.

download (1)

The principle is that it gives the worker the ability, and moreover the empowerment, to stop production when a defect is found, and immediately call for assistance.  Workers are encouraged to use this feedback mechanism freely. Common reasons for manual activation of the Andon are part shortage (dependency), defect created or found, stoppage, or the existence of a safety problem. Work is generally stopped until a solution has been found.

Loosely translated an Andon is a Paper Lantern – To shine a light on a problem.

andon

Sounds great in principle, any worker is empowered to give feedback to management if they have concerns over safety quality or even a weakness in a process, but for it to become culture it needs to be adopted in a no-blame manner and used frequently, lack of utilization of an Andon is a serious problem and is addressed in Lean.

If a feedback mechanism is not triggered regularly then the settings are considered too loose.  The threshold for triggering an Andon would continually be made tighter and tighter, quality is expected to be higher, time for a task is squeezed and so on until there is an increase in frequency of Andon being used.

The aim is to get a regular feedback of actionable information, too little and the feedback loop has failed, too much and you cannot see the problem so it needs tuning and adjusting slowly.

What does that mean to us in a non-manufacturing environment?

We have got pretty good at retrospectives and giving feedback locally, but feedback to management is largely absent.

devops

The difficulty in many organizations is that senior management hide behind an open door policy.  “Employees can talk to me any time, my door is always open”. It is very easy to pretend you are open to feedback but much harder to actually be open.

“Employees can talk to me at any time, my door is always open”

– the unapproachable manager

In many cases the open door is actually an invisible barricade: fear of retribution, fear of not being supported, fear of being ignored, fear of the messenger being shot.  In many cases the fear is justified,  but even when it isn’t, it doesn’t make the fear any less real to those with genuine feedback to share.

Creating Feedback Loops

Just like with Andon, this is feedback that should be sought and encouraged and your measure should be how frequently you are given constructive feedback from your employees, if you are challenged regularly and respond to it regularly then it is working, but if you are not getting regular feedback (from those outside your inner circle) then it is likely your “open door”  is not that open.

opendoor

Has someone in the last week given you critical feedback without being asked?

If on the occasions you do explicitly ask for feedback are you bombarded with hostile questions? Do the questions catch you by surprise? Do people seem dis-satisfied with your responses? Do you only ask for feedback when people quit? If yes then perhaps you are not asking for feedback often enough, or are not responding to the feedback you are getting.

Feedback is not passive

Feedback is generally not passive, you need to invite it, create forums where feedback is invited and expected, be open to the feedback and when you are not willing to change be prepared to explain yourself, and be prepared to repeat yourself.

It really comes down to whether you truly are a feedback culture, if you are you have to work for it.

 

 

 

 

 

 

 

 

Are you working too much?

Would it surprise you to learn that the person in your team or company that regularly works 60 hours a week (and makes sure everyone knows it) is very likely the least productive person on the team?

The person working 60 hours is likely the least productive person on the team.

And I don’t simply mean that productivity diminishes after 40 hours, I mean absolute total productive output is less from someone working 60 hours compared to someone working less than 40.  The reality is that you would actually get more done by NOT working that time than you will working those extra hours.

This is a hard pill to swallow in a culture where ‘working hard’ is seen as a virtue, and the more hours I work the more virtuous I am. Long hours are often assumed to show commitment, dedication, loyalty. Maybe they do, but they don’t show productivity. If your company values those things above actual productivity then so be it, but understanding that it is about those attributes rather than productivity is a rather brutal fact to face. However, if you want to produce more and maintain high quality then you need to work less hours.

Parkinson’s Law

I am likely to offend a few hardworking people with this but my assessment of the findings of these studies is that is is a subconscious manifestation of Parkinson’s law. “Work expands so as to fill the time available for its completion” If I expect to work 60 hours then I’ll make my work last 60 hours.

parkinson 2

Not just a European thing.

Europeans have a reputation for favoring reduced working hours and I’m sure it is an ongoing frustration to those in America that despite typically working more hours, American companies are consistently similarly or less productive than their European or Japanese counterparts despite the longer working hours and less vacation.
Interestingly, the study I’m quoting was actually a 12 year study by the Ford Motor Company of production in the USA.

Henry Ford… again.

Before I go into the study in more detail I’d like to go back in time and talk about the history of working hours and in particular Henry Ford.

If we go back 150 years there were campaigns all over the world to reduce the working week from 16 hour days, 6 days a week – 96 hours was considered a normal working week for many. Forward thinkers pushed for limiting the working day to 10 hours with breaks for food – a radical concept at the time.

MayDay

Over time much of this became law despite fierce objection from industry, and by 1914 a normal working week was 9 hour days, 6 days a week.  The pressure until then mostly came from humanitarian motives and agendas, and perhaps because of that, businesses took steps to prevent it taking hold, reducing pay in line with reduced hours so a reduction of 20% of hours came with a reduction of 20% in wages, this undermined the whole movement.

But then came Henry Ford. Ford created the 5 day working week, and a limit of 40 hours, but best of all he did it for profit and not for social good.  At the time his factories worked 6 days and 9 hours a day (54 hours per week) just like everyone else, but he reduced working hours by 25% and instead of cutting wages he doubled them.

The productivity increases resulting from reducing hours were so significant that Henry Ford was attacked by the Wall Street Journal “To double the minimum wage, without regard to length of service, is to apply Biblical or spiritual principles where they do not belong.” going on to say “in his social endeavor he has committed blunders, if not crimes. They may return to plague him and the industry he represents, as well as organized society.”

51098603-f186b080bc53f64bbbd46208f7dec61a538631e4-s1200
Henry Ford may have paid his workers a good wage, but it wasn’t out of charity — it was a good business decision that some say helped the middle class take off.

As you can imagine his competition was not happy either, paying more for “less hours” was maddening, but what really made them mad was that productivity jumped up massively. People simply couldn’t get their heads around the idea that less hours  increased overall productivity.  Slowly the competition copied Ford and got the same results, productivity went up for less hours, and eventually this carried across to office workers too. But even with those startling results and seemingly unquestionable evidence we stubbornly cling to the notion that more work is more productive.

I have written more about Henry Ford here.

Back to the present.

Last time the proposed reduction in hours was met with hostility but eventually it was seen as beneficial to everyone, especially the business owners that fought so hard against it.  Once again studies show that reducing hours will increase overall productivity, and once again industry is pushing back on it in the face of the evidence. Challenging established culture with only facts is apparently not an easy battle.

Studies repeatedly show that long hours (40+ hour) results in reduced productivity, reduced quality and a less healthy lifestyle, and yet society still perceives the number of hours worked as a measure of hard work.
It is as if we see more value in the hours worked than the output of their labour.  Someone that works 30 hours and produces 30 widgets  is seen as less valuable than someone that works 60 hours and produces 25 widgets, because he works so much harder.

In our culture we see more value in the hours worked than we do in the output of our labour.

In our culture we see more value in the hours worked than we do in the output of our labour.

How did we get into such a mindset and how do we challenge that way of thinking.  Surely we should reward the more productive and effective person? But we don’t, we reward the inefficient, we lift up Jane for being here at 7:30  PM finishing up her work and we criticize Anne who got all her work done and left at 4.

Part of the problem, especially in knowledge work, is that productivity is not easy to measure, just like quality and mistakes are hard to quantify.  So rather than focusing on what is important we focus on what is easiest to measure – number of hours in the office, it is ironic that in our laziness in finding effective measures we end up working longer hours.

So what about overtime?

There is more bad news in the 12 year study by Ford they found that overtime (over 40 hours) results in reduced productivity in the long term.  40 hours is the very limit of maximum total productivity for a manual worker, this applies in both the short and long term.

Short term (less than 3 weeks) there are productivity gains for working beyond 40 hours, but after 3 weeks those gains disappear and actually reduce productivity afterwards. Even just 2 weeks of overtime and then stopping results in more loss in recovery than the gain made in the short term boost.

In other words, yes you can make a short-term gain using overtime to meet a deadline, but it will cost you more than you gain over the following weeks. So use it wisely and expect a recovery period.

Bad news for knowledge workers

For knowledge workers the news is worse still, the point of peak productivity is under 35 hours, and any hours above that are actually damaging, quality is markedly worse, mistakes and resulting corrections mean that productivity reduces dramatically when knowledge workers work beyond 35 hours, primarily because fatigue, stress and concentration have a profound impact on the quality rather than the quantity of work. We simply cannot be creative when tired, we struggle to solve problems come up with ideas or compose constructive discourse and debate, we are actually very likely making things worse not better and the clean up cost for knowledge work – bad decisions, introduced bugs, stifled creativity is far more damaging than not being there.

Worse news for Lawyers

Lawyers are typically in an unfortunately situation where they bill by the hour rather than by quality or even quantity of work. They are essentially encouraged by their business model to be unproductive (not consciously, it is just a product of the business model). Essentially a 60 hours week for them is the result of rewarding bad behavior, if you pay for time then they will take more time, pay for productivity and we become more productive. We also reward with status the hard working person that is willing to sacrifice his weekend for the appearance of working harder. More encouragement of bad behavior.

In ‘bill by the hour‘ work environments it is a challenge to change the model, productivity is very hard to measure – even if we see stress, mistakes and problems taking longer to solve. So it is hard to convince clients that working less is more productive, especially when it means charging more, and it becomes even harder when we can’t even convince ourselves because this notion is so culturally ingrained in us.

What now?

It is pretty simple really if you want to maximize the productivity of your teams, then reduce their maximum working hours to less than 32 hours (without reducing pay).  They will work harder and more effectively for five 6-hours days than they will for 8 or 10-hour days. Your overall productivity will be higher.

Or work 8-hours, 4-days a week and you will find your teams will be more focused, more energized and and noticeably more creative.  They will be happier, harder working and make less mistakes.  They WILL get more done and it will be higher quality and more creative. They will also be refreshed have a happier home life.

Or we can ignore the brutal facts and continue to pretend that working long hours is a good thing, and praising the guy that works 60 hours a week and yet produces less than a part-time worker.

Note: my wife finds this particularly amusing as I work long hours and when I’m not working I’m blogging and when I’m not blogging I’m working on my game or running meet ups – there is a significant degree of hypocrisy and self-denial at play here.

Summary

Let’s not underestimate the difficulty here, this is a complex topic, and it is unlikely to be accepted any time soon, there is a lot of resistance – and that resistance is not based on facts or data.  There are numerous studies on this topic, all with the same findings.  Oddly enough despite the strong resistance to this idea, I couldn’t find a single study that didn’t find that overall productivity went down when hours went above 35-40 hours.  There were even some studies that showed that regularly working 60 hours resulted in the same number of mistakes and level of performance as being drunk.

(If you see a study that contradicts this please share it, I spent quite a few hours on this but couldn’t fine one – and no, the contradiction has not escaped me.)

Decision Makers

Decision makers typically work longer hours and it is effectively their money, asking them to pay more for the perception of ‘less‘ work is never going to be an easy decision.  We come from a puritan culture where we make a cultural assessment of someone based on effort not outcome. Deep-down we know this is not objective, I think we know this is wrong, but culture is not based in logic and changing culture will take more than facts and figures. It needs someone like Henry Ford to lead the way again.

References:

https://cs.stanford.edu/people/eroberts/cs201/projects/crunchmode/econ-crunch-mode.html

https://www.igda.org/page/crunchsixlessons

For the public good…

I am continually fascinated by the notion of self-organising teams, how they motivate themselves and how you can create an environment that is conducive to self-motivation.

Unfortunately my experience is that self-management works for the minority and is highly rewarding and highly effective, but it does not work for all. Bystander Syndrome is prevalent and too often the plants do not get watered. Why don’t developers water the plants?

So, recently I ran an experiment and discussion on the general low involvement and engagement of extra-curricular activities. In particular events that are considered to be core to the effective working of the company but are not explicitly part of your core objectives.

The premise of the experiment is that we have become more focused on benefit to ourselves or benefit to our local teams, rather than the benefit to the wider organisation.

img_0447

For those out there ready to point out that an experiment requiring voluntary attendance already excludes those that are more focused on themselves – you got me!
I stacked the deck in favour of the more social minded of the organisation.

Some examples:

Our organisation is very much built around self-organisation and we are expected to manage our own time and priorities.  However, we have a number of activities that are ‘global’ in scope: some where the time spent is voluntary and expected to be worked above and around billable time.  Or facilitating other team’s retrospectives which is billable time but can conflict with your primary team priorities. Even our Guilds, which are groups of people based around a single focus or competency have an implied ongoing commitment to attend regularly.  Finally, “Lunch and Learns” or bookclubs where there is opportunity to share ideas and learn from colleagues, which is a core cultural goal of the organisation but is done as part of your personal development and on your own time.

All of these activities could be considered to be valuable to the organisation and in most cases to you personally (directly or indirectly), but all require an investment of time and effort. My observation is that in many cases the involvement is diminishing either proportionally or absolutely as we grow. Attendance at lunchtime events seems to be diminishing, involvement in volunteer groups like guilds is a challenge to the organisers and maintaining membership is probably the number one challenge.

The goal of the discussion was to identify ideas for how we maintain or stimulate these activities and how to involve a wider audience, preferably without putting a greater burden on a few (and often the same few people), and without directing people to attend, which is counter to our culture.

The Game….

We played a game loosely based on the ‘Public Good Game’ We set up two relatively large groups. All participants were given $10 each and the game is played in rounds.
Each round players can contribute as much or as little as they like to ‘a pot’ but the total contributions will be combined and then a pre-determined bonus would be added to it. One team got a 30% bonus the other team a 40% bonus.

Round 1

All players were asked to choose how much to contribute, in the 30% team the contributions were visible, in the 40% team the contributions were secret.

If you apply pure logic, the maximum gain is obtained by everyone contributing fully, that way everyone gains a lot.  But an individual can work out that by opting out and reducing their individual contribution they can benefit at the expense of others.

Subsequent rounds…

Over the course of a number of rounds as more and more people realise that others are not contributing fully, they will either call the others out for not contributing, OR they too opt out and eventually those that are still contributing receive back less than they contribute and at that point system fails as everyone eventually opts out.

End Game

What we found was that the transparent team reminded each other and kept the focus on the public benefit and maintained a better contribution level, the secret contributions team had two or three participants who were able to benefit considerably at the expense of others  by not contributing (leeching from the pot). There was sufficient reward to keep the others motivated although that was diminishing each round.  Overall it was the transparent team that benefitted more, but both teams missed out on a huge amount of potential benefit by a focus on personal gain.

Conclusion

In the recap there was a suggestion that it was unclear whether the goal of the game was for collective gain or individual gain – e.g. How did we measure the winner?

But the reality is that this is the same quandary that we face in our day to day life,  are we working for the benefit of ourselves or our team or our company?  All our choices for extra-curricular activities are an investment of our own time and effort and we are motivated either for personal gain (what is in it for me?) or collective gain (How would me attending benefit my team/company?)

Discussion

Many of the arguments we heard were around billing, and utilisation. There seems to be a reluctance to use personal time for ‘extra-curricular’ learning, which implies that there is a perceived lack of sufficient personal benefit from involvement in these activities.

In other cases such as facilitation and helping other teams people are balancing time spent with their local team against involvement in activities that benefit a wider group.  The question is… Which is more important?

The challenge for us then is how to change priorities such that activities that benefit the company as a whole are perceived as valuable (not necessarily more valuable but valuable enough to make that effort), or to highlight the benefits to us as individuals resulting from a greater involvement in company wide activities.

The conversation that followed created some great ideas, as well as highlighting some of the concerns.


The Dunbar number

Dunbar’s number is a suggested cognitive limit to the number of people with whom one can maintain stable social relationships.

Dunbar’s number on Wikipedia

Dunbar has a theory that as groups exceed a certain number approximately 150 people their sense of community diminishes and the group becomes less effective, less cohesive and it is more difficult to self-organise.

Many of the issues raised could be interpreted to have their root in the Dunbar number.  As we grow we don’t personally know the other people that are presenting at LnLs or the others that are attending the guild meetings. This lack of personal attachment results in a diminished sense of interest, ownership and responsibility, skipping is downplayed as it is only letting down people you don’t know, or an assumption that others will attend.

Ideas for increased engagement

  • Offer food
  • Educate people on calendar etiquette, e.g. show up if you accept
  • Increase advertising/promotion of events and activities
  • Write up a “What you missed” summary for those that didn’t attend
  • Leaders show support by attending,
  • Reward directly or indirectly those that present and/or attend
  • Make clear the purpose or learning goals of events
  • Introduce compulsory lunch breaks, or compulsory attendance
  • Highlight the understanding/visibility of what happens when you don’t step up
  • Identify Champions to help organise and promote these activities
  • Have fixed times/days for lunchtime activities to regulate number and ensure quality.
  • Invite only those from a sub-group (accept Dunbar’s Number and work with it).

Our goal with this experiment was to gain ideas and gain a better understanding of the problem and to share these concerns with a wider audience, we were not aiming for a solution to the problem just a start to the conversation.

Feedback?

Any more thoughts or ideas on this would be greatly appreciated

 

 

The Zone of Acceptance

One of the challenges of an Agile Coach, or anyone in a management or leadership role is establishing what I have seen referred to as the “zone of acceptance” for individual team members.

The Zone of Acceptance is a term for the tasks an individual sees as something they are prepared to do as part of their job.  This can relate to tasks, overtime, meeting attendance and more.

In a traditional model where work is explicitly assigned, this took the form of a team member saying “that’s not my job” when asked to do something on the periphery of their role. E.g. being asked to write documentation or attend a meeting outside core hours.  This is a direct confrontation that can be handled directly, the team member can be coached to broaden the scope of their ‘zone of acceptance’ and have it explained that sometimes responsibilities extend beyond core hours and core responsibilities.

However, when you move to agile it becomes much harder to deal with. We introduce the concept of self-management and self-organization, there is no longer an external person pushing you to extend your boundaries.

change

What is my Zone of Acceptance?

In my house I will sometimes come home to find the kitchen bin full or overflowing, if I ask why it has been left like that my wife will in a ‘matter of fact’ tone reply – “That’s your job!”  I don’t doubt that it is, at some point we agreed a division of responsibilities – , the responsibility is clear.

But conversely my behavior in a different situation is far harder to manage. My wife may ask me to change our child’s nappy (or diaper as my wife calls it), I will generally willingly comply, but I rarely volunteer.  I would never say it is not my job, but by subtly avoiding doing it I am implicitly saying that.  She can ask on a regular basis but that in itself undermines the equality and self-organizing nature of marriage, she shouldn’t need to ask. We have an understanding that generally works and in this case the reality is that she is not asking me to take the responsibility, nor is she demanding assistance, but my help is certainly appreciated.  What I need is to broaden my ‘zone of acceptance’ and to be more proactive in my support. We are a team.

That is not my job

The same becomes true in an Agile team, if I were to hear someone say ‘that’s not my job’ or “I’ll hand that over the wall to a tester” or similar comments, they can be directly challenged, and the coach or the other team members can act accordingly. But far more common is seeing the team members forming natural silos for work, an often agreed line in the sand where work is divided and not challenged.  They will avoid tasks they are not interested in or don’t see as their role, find excuses for working on tasks they see as theirs and in some extreme cases work on something outside the board to avoid picking up a card that doesn’t fall into their zone of acceptance.  This behavior may not even be visible, a team can actually become very productive in the short-term by forming mini-silos, but that doesn’t make it right or healthy in the long run.

I see the role of a Coach (or any Agile minded team member) to challenge these silos, to encourage team members to broaden their zone of acceptance, and to get the team to inwardly think that it is their responsibility to get involved in Story writing, and coding and testing and to be active in all meetings, to volunteer to write documentation and present the Demo, and to challenge those that don’t become active members of the team.

“But I’m a tester I don’t know how to code” – is a common argument. My response – “So what!” a lot of coders I know would benefit very much from having a tester on their shoulder asking if they had considered this case or that case, challenging the use of TDD and actively engaging in what and why things are being coded even if they don’t understand the code syntax itself.  And perhaps more controversially the opposite is true, having a developer sit on the shoulder of a tester and see what and how and why certain tests are performed can help improve the way a developer writes code. I think we can make passable testers of most developers and vice versa, teams should want to challenge boundaries. In the long term I’d suggest those roles should become indistinguishable from each other and in an ideal world they would be one and the same – a team member who would do what they could and what was needed.

Jack of all trades

By this I am by no means suggesting that we create a team of jack of all trades – I am actually very much against that, expertise should be encouraged and my view is that testing; coding and design etc. are very different skills and expertise in each should be valued. But my view is that the comparison of skills needed to get a user story to ‘done’ will often form a huge amount of overlap and likely a combined involvement.

purple jigsaw

If each user story represents a piece in a puzzle, chances are that there are a few parts that will require a specialist in ‘Blue’ or expertise in ‘Red’ skills, but the majority of the work is shades of ‘purple’ something that does not require particular expertise  and could be achieved by anyone on the team or through a mix of people. We often use edge cases as examples so we can dodge the normal cases, when we see that we should call it out.

How do we expand the Zone of Acceptance?

But now what? We understand the problem, we know it is hard to spot and hard to challenge, so how on earth do we expand the zone of acceptance?

The first step is nearly always acknowledging there is a problem. Discuss it with the team – maybe as part of a retrospective and see if they recognize it as a problem too.
Let the team find ways to solve the problem. Once they see themselves as a team it becomes easier as they will be seeking ways to help each other rather than looking for the easy way out for themselves.

One team I work with identified this problem for themselves and their solution was to put a sign on their task board that said: “Have I done this before?” And another sign that said “Is this on the critical path?”

have I done this before

The idea was that when selecting a story the team member would stop and think:

  • First whether they were taking a task that someone else could take and learn – or maybe they could pair and teach someone else to share their knowledge;
  • Secondly “Is this the next highest priority or am I taking an easy option?  Some team members will cherry pick from the backlog rather than taking the highest priority item.

By having a written reminder it can become a challenge at stand up. The team members can call out each other if they see either of these behaviors.

Great Team Players

This barely touches the surface of this particular problem, but there should be a desire by the individuals on a team to (sensibly) broaden their zone of acceptance, for the focus to shift from what is the next best(or easiest) task for me to what is the next best task for the team – and even better what is most valuable for the customer.  And more significantly for this to be supported and encouraged by the team and the organization as a whole. Too often the organization rewards ‘star developers‘ rather than great team players, that message reinforces bad behavior and can be extremely corrosive to the organization over time.

Mindset or method?

Straw poll:

Should we teach practices and methods in the belief that an Agile mindset will evolve from the good practices?

or

Should we teach an Agile Mindset in the hope that with an Agile Mindset good practices will emerge?

Related image

I know of a few Scrum Masters and a few Agile Coaches in each camp, and some that feel very strongly on this topic. And of course the choice lies at the heart of most Agile Transformations and the outcome will therefore be far reaching.

Method over Mindset

Around 10 or 11 years ago I was introduced to a new way of managing projects and a new software tool for doing it. I was trained in how to use the software, but not in the theory behind the tool.

We are what we repeatedly do. Excellence, then is not an act but a habit.

– Aristotle

The tool was amazing, it really blew my mind. As a Project Management tool/method it made more sense than anything I had used previously and I loved it, I happily used the tool and got good results. But despite having the tool I never learned the theory and didn’t even know where to look to find out more.  No lack of interest or enthusiasm but I was content to use the methods and it helped in my current situation but I was never able to make the leap to more than a method despite my enthusiasm.

It is a little beside the point but the tool was Critical Chain for Project Management and before I was introduced to Agile I thought this was the best option out there for Waterfall projects (probably still is). Sadly despite it being so great, it was still based on the assumption that the end state was known at the start of the project, which for me is the ultimate failure of Waterfall thinking, and my primary reason for moving to Agile.

Only much later did I discover the theory behind the tool was The Theory of Constraints and the 5 focusing steps, IF only I had been shown that and I feel my enlightenment would have come much sooner.  But a method without understanding the theory leaves you unable to adapt and improve, I was limited to the context in which I was shown.

What is more I had a co-worker that struggled with the concept of slack and wanted to follow the method apart from that one aspect – the lack of understanding left him unable to differentiate between a necessary aspect of the method and an arbitrary one, and ultimately for him the tool didn’t work because he rejected the necessity for slack.

A lack of understanding of the theory leaves you unable to differentiate between a necessary aspect of a method and an arbitrary one.

– John Yorke

1cf58fa9895dafded2997558ab348190

Method over Mindset, the Return on Investment

Another consideration is that teaching theory takes considerably longer and has a much lower conversion rate. That is to say that I could teach the Scrum framework fairly quickly – a matter of days, and be pretty confident that the instructions are clear and ‘could’ be followed effectively. To take that same group and to teach them the theory to the point of understanding the why behind each of the practices could take weeks or months, and likely longer before they are fully understood. It is also possible that some will never grasp the theory but are still perfectly capable of being good team players.

Continuous improvement is better than delayed perfection

– Mark Twain

Many organizations are interested in the short-term results rather than long-term understanding and so there is a desire to do the least for the most impact. So we see the evolution of phrases like ‘Scrum-but’ as a means to discourage deviation from the defined framework. Our goal becomes to repeat, rather than understand.

Mindset over Method

cropped-serres-view-4.jpg

If you want to build a ship, don’t drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea!

– Antoine de Saint-Exupéry

The flip side of this is the desire to teach/show the impact of having an Agile Mindset and then having the individuals identify a solution using that knowledge.

Clearly this is a much greater challenge, even those with an Agile Mindset will initially lack any practical applications to draw upon, even the most Agile of mindsets is limited to what they have experienced or read about, and contriving a new bespoke process to your environment may ultimately be the most desirable solution. However, it is impeded by the ability to share that vision and understanding with others, and limited by your understanding, ability and creativity.   And frankly do we really think that we are able to come up with a better framework than Kanban or Scrum on our first pass at an Agile Transformation?

A middle ground?

As you have probably guessed I am not a fan of either approach. I believe that most people will not become Agile overnight and even the most eager of minds will take time to absorb and understand the implications and possibilities of Agile.

I further believe that teaching Scrum as a closed framework that must not ever be deviated from is not the solution. Instead I would compare it to learning any new skill, we teach good practices and when you have mastered them you are ready to move on, we may teach a variety of good practices so you have some comprehension of the possibilities available, that way you do not limit your thinking so just one solution.

But we learn to master the basics, and we learn to question ‘why?’ when we feel we have mastered the basics and we understand why, only then we are in a position to start to evolve.

Applying Lean and XP and Kanban to the Scrum framework can let you grow in understanding within a safe set of guidelines. And when you understand the mindset enough to comprehend the limitations then maybe you are ready to craft your own solution.

If you can’t explain it to a six year old, you don’t understand it yourself.

― Albert Einstein

 

Why I recommend Scrum

Personally I love Scrum as a foundation for a transformation to Agile for those undertaking software development projects, not because I believe it is better than Kanban or other tools, but because to succeed with Kanban you need a level of self-discipline and understanding that is often absent for those new to Agile, and it becomes far to easy to gold plate or run long.

Scrum adds some safety nets and feedback loops that counter many of the usual “human nature” problems that arise from teams new to self-organization. Self-organization is a skill we need to learn and develop like any other. Scrum is so simple to learn, and easy to follow (if you are willing) and once you understand the Agile mindset it is a great framework for evolving into a great Agile team. But like any tool if used inappropriately you can make a mess. But any change requires a good guide.

That being said for support or reactive work Kanban is ideal as the discipline generally comes from outside. It is never a one size fits all.

Leadership

Method without mindset can only take you so far

Teaching the mechanics without teaching the theory is only half the task and whilst it is sufficient for many consultants to get paid, what they leave behind is a culture unable to improve, and without improvement entropy will set in.  I believe both some guidance on the mindset and instruction in some methods are both necessary for a successful Agile Transformation, along with a healthy amount of enthusiasm and patience from those leading the transformation.

 

 

 

WiP Limits and Velocity

I recently presented at a conference on the topic of Work in Progress (WiP) limits, and in particular Little’s law.  As part of I gave a demonstration and from it drew the conclusion that WiP limits have no direct bearing on velocity.

This caused some controversy so I’ll try to explain again here.

little

Applying Little’s Law

Mathematically speaking we can increase the speed with which we get served in two ways:

  1. We reduce the number of people in the queue (We limit WiP)  or
  2. We increase the speed each person is served (We increase Throughput – in this case by adding more people, or installing faster equipment)

Note:  When mathematically applying Little’s law the pre-condition is that the variables are independent, the assumption is that number of people in the queue does not impact on how quickly the server works.  This works in mathematics, but maybe not so much with people in reality.

The principle is that WiP and Throughput are two independent variables and changing one does not change the other, only cycle time is impacted.

The wider impact of WiP limits

Of course the goal of my talk was to illustrate that whilst you may feel you are getting more done by not limiting your WiP, and having a whole bunch of work in progress this has no bearing on your actual throughput which is governed by your bottle neck.

When using Little’s Law in a controlled environment we can show that limiting WiP doesn’t impact throughput (unless we limit it to less then our bottleneck and starve it – say two servers and limiting the queue to 1 person). What limiting WiP does do is reduce cycle-time enabling you to be more flexible and more responsive and to have more reliable forecasts.

Work in Progress Limits will directly impact Cycle-time

Contradictory Claims

Unfortunately this contradicted one of my other claims in the presentation where I said that Limiting WiP helps increase throughput of the team.

The confusion of course is understandable, when using a mathematical example there is no cost for context switching and the example was to show the impact of WiP on a stable system isolating variables to demonstrate what happens.  The real world is far more complex and there are many more variables.

In the real world

Generally speaking the ability to focus on less things means less multi-tasking, reduced cycle time means you have less things on the go at once, and for less time. These help you be more productive and thus indirectly the throughput will go up, but this is a result of you being able to focus not as a direct impact of the WiP limits.

There are many indirect benefits of using WiP limits,  but Cycle-time is the prime beneficiary, the rest is a bonus or an indirect consequence.

 

 

 

Motor City – A Kanban Game : Overview

JSY_1323

Game Overview

The game is designed to reflect a simplified operating of a delivery pipeline for a car manufacturing plant.

The player accepts orders from customers, chooses which products to make and allocates resources and manages the plant to deliver cars to customers in the most effective way possible.

JSY_1267

Kanban

Each player manages a separate board representing a factory, the board is laid out as a Kanban board and the production is tracked as it moves across the board.

JSY_1279

Wip Limits

In the core game WiP limits are optional. Players may choose to apply WiP limits to manage flow, or just use their instincts.

If played for fun the WiP limits are not explicit, but if using this in a training environment I’d encourage explicit limits and for them to be strictly enforced to enable the class to evaluate the impact of WiP limits on the game.
I’d also suggest that each player experiment with different WiP limits to compare the impact with each other and discuss the results.

JSY_1276

Accepting Orders

At the start of a shift a player may choose to review and accept an order, once accepted an order must be delivered and if the player fails to complete an order they will be penalized.

Sourcing Materials

Each shift all players may choose to source materials for their production, this is done by selecting vehicle cards from the available selection, only 4 cards are visible and players may only choose from those available – this adds some competitiveness over resources, and an element of understanding your constraints and dependencies.

JSY_1264

Production

At the start of each hour within a shift one player rolls dice to determine the available production points for all players (all players get the same to make this game about the allocation of resources rather than the luck of the dice.

Each player is allocated a quantity of Manufacturing, Assembly and Quality production points which they can allocate over the course of the hour. Unused production points are discarded. The player also has the option to trade production points of one type for another but at a 4:1 ratio to indicate the impact of repurposing machines.

The vehicle cards are pulled through the system and production points are allocated as they progress through the system.

JSY_1305

Bottlenecks

There are a number of potential bottlenecks in the system and how you manage these will heavily impact the result of the game.

Game Success

Ultimately the winner will be the one that manages the production most effectively to meet their customers’ needs. It is hoped that applying Kanban and Theory of Constraints Practices will be rewarded, although there is an element of game mechanics and chance.


Purchasing the Game

The game is for sale at $120 + postage and is available now.  Game contains 4 game boards so is suitable for 4 players (or 4 pairs).

Please email me at john.yorke@yorkesoftware.com to arrange to buy the game.

Thank you for your support and encouragement.

JSY_1308

 

New Kanban Game Available

Around two years ago I was introduced to a Kanban board game which we used as part of a training program and I really enjoyed it, it was a great learning tool but it had three major drawbacks.

  1. First it was heavily scripted and so it was only suitable for a single play through, you couldn’t replay it and get more out of it.  It was not a game in that sense, it was much more of a training tool/prop.
  2. The second issue was that the exercise was taking 3 or more hours to run and whilst Kanban is a critical aspect of the training the return on investment was not sufficient.
  3. Finally it didn’t effectively address Little’s Law or the Theory of Constraints, there were aspects of that in the game but the heavy scripting meant that the learning was masked or even lost.

motorcity_Board-1

A New Kanban Game

It got me thinking and so I created a couple of workshop games that addressed this in more detail.   One of those workshop games was such good fun that I expanded it and combined it with training. For the last year or so I have been running workshops using it and continually looking to find improvements and modifications to make it more fun or to emphasize the learning aspects.

I have now presented this at a number of Lean/Agile conferences and have had a lot of great feedback, including a lot of encouragement to publish it as a board game.

Rulebook_cover

And so Herbie* – the affectionate name for the workshop game, became Motor City a Kanban based board game.  That is first and foremost fun to play and re-play, but the game is under-pinned with an understanding of Kanban, Little’s Law and the Theory of Constraints.  You can play the game without any knowledge of those and it will still be fun, but people that instinctively apply those practices or use them as a result of understanding will fare better playing the game.

*Herbie was named after the character from the book The Goal, by Eli Goldratt.

box_bottom

Game Prototype (Early Access)

The game is now in prototype, with a small number published for evaluation and for use in training and conferences, with the intent to publish the game more widely after getting feedback from the prototype.

motorcity_logo

To purchase the game…

The game is provisionally priced at $150 but for early access to the prototype it will be charged at $120
I’d love to hear of anyone that uses this as part of a training program or just as a fun game for your team to play.

If you would like a copy of the prototype board game for evaluation and feedback, please contact me.

Similarly if you are interested in training on the Theory of Constraints or Kanban and would like to use this game as part of that training, I would be happy to offer guidance on how to incorporate the training into a workshop.

Thank you

Thank you to those that have supported and encouraged me, I can assure you that board game design is far more complicated, costly and time-consuming than I ever imagined. In particular thank you to Toby Gerber who has helped with the graphic design and turning my ideas into reality, I could not have done it without him.

boxbase sm