Category: Scrum

A tale of two Scrums

I have been very fond of Scrum and a strong advocate for it since my first introduction to it about 12 years ago. But in recent years I have not been exposed to it so much, my current organization favors more of a Kanban approach to software delivery.

However, this last few months I have been working with a new client who is using Scrum. I was invited to join their Scrum training this last week. And Oh my! As I was listening this quote sprang to mind.

“It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of light, it was the season of darkness, it was the spring of hope, it was the winter of despair.”

Charles Dickens

This is where I get confused. I would appreciate comments from my friends in the Scrum community to help me rationalize whether I have drifted from the Scrum mindset or if I simply got exposed to an example of a dogmatic interpretation of Scrum.

The Daily Scrum

The trainer was talking about the Daily Scrum and how to keep it short. She suggested that – paraphrasing a little “the product owner being there was not only optional, but undesirable.  The Product Owner being there encourages questions and conversation. Conversation and questions are bad, and a reflection that the Sprint planning was not comprehensive enough. If there is ambiguity in a story or the need for a question we should learn to get better at our planning.”

I was a little in shock.  My advice is generally the complete opposite, that conversation is good, it is desirable and should be encouraged. I encourage the PO to be with the team all the time for questions. I will often encourage teams which have good interactions with the Product Owner to reduce the detail in stories and rely on the conversation more, for me it is the outcome that matters and not perfect planning.  Over the years I have correlated the amount of text on the story card to inversely be a measure of the maturity of the team. (assuming they are producing value)

I was dying to jump in and disagree, but this was someone else’s training and I was there as a guest. But I did begin to question whether what was being said was a misinterpretation or have I misinterpreted and my move away from Scrum has resulted in practices which conflict with the Scrum philosophy. 

The agile mindset

On the flip side and the other side of that quote I began with… I was on the training with the Product Owner from the team I am currently working with and I was astonished at how quickly he has grasped an agile mindset and how comfortably he has taken to thinking in an agile way. It took me a lot of time and effort to achieve the comfort level he is at.
We have been planning an MVP and he has been simply brilliant, the conversation is about balancing value and necessity and it is impressive how easy it has been to navigate the usual pitfalls. Sometimes you get really lucky with your team, and the job is so much easier when there is an agile mindset at play.

I’d love to hear your thoughts on the Scrum question, let me know…

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.

 

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.

 

 

 

Applying the Theory of Constraints to Agile Software Delivery

In ‘Agile’ circles there are certain topics that come up frequently, such as Kanban and Scrum, so much so that we often forget that Agile is a mindset rather than a small subset of methodologies.

As the saying goes there are a great many ways to skin a cat, but limiting ourselves to only a few may constrain us from opportunities to improve.  The Theory of Constraints is one of these overlooked options.

The Theory of Constraints (TOC) is often assumed to only apply to industry and manufacturing, which is very sad. TOC is in my opinion the very example of an Agile mindset applied to industry and the techniques can be applied very effectively to Agile Software Delivery.

TOC5

Some common applications of TOC

  • Ongoing Improvements
  • Improve flow
  • Incremental delivery
  • Smaller batches of work
  • Reduced Work in Progress
  • Focus on maximizing customer value
  • Reduce firefighting
  • Reduce inventory of undelivered ‘finished’ work
  • Reduce speculative work
  • Reduce reaction time – ability to pivot sooner
  • Identify potential productivity improvements
  • Expose underutilized capacity
  • Identify skills shortages
  • Identify blocker clusters
  • Identifying new markets or new ways to engage with your market
  • Using cost of delay principles to prioritize work

TOC1

System Thinking

TOC starts and ends with system level thinking, your organization as a whole, not just your team, the whole market, not just your current customers or your current market. TOC requires you to look up and around rather than just looking down.

The Theory of constraints uses the term ‘theory’ in the scientific sense, it is a well defined set of practices that have proven to be very successful when applied appropriately.

The guiding principle is that improvements to anywhere that isn’t your bottleneck is worthless. Think of adding a third row of seats to a car that only ever has one passenger. and that improvements to your bottleneck improve your entire system as a whole so should not be measured in isolation.

This can often feel confusing and counter intuitive, it can sometimes result in decisions that increase local costs and even reduce local efficiencies.  Say shipping by air may seem far more costly per item, but results in an increase in sales that far out strip the increase in costs.  Shipping got less efficient and costs went up, profit per unit went down. All seemingly unwise decisions when considered in isolation.  But the result was that sales went up and so profits increased faster than sales.

And that is the heart of the problem, most organizations create silos and fail to consider the impact of opportunity cost on the organization as a whole. This mindset leaves the shipping department seeking to reduce costs without considering the impact on sales.

In IT this may be seen as saving money by sharing an expert between two teams which means their utilization is high (they are perceived as efficient) but they are not fulfilling their purpose in a timely way to their teams which actually costs the company far more in opportunity cost.  Sadly opportunity cost does not show on a balance sheet and so cannot be seen unless you look for it, and understand the significance of it’s impact.

Having dedicated resources with built in slack often causes traditional managers and PMs to have kittens, they cannot bear the thought of costly resources being underutilised, they only focus on cost, not on the value that people bring and that thinking could be crippling your organisation.

TOC3

Contrary to popular belief your company’s goal is not to keep all workers busy all the time,  it is to be the most profitable it can be now and in the future.  That means effective use of people and not maximum use of people. The two are not the same and until that is understood your company’s profits will suffer.

In agile we suggest dedicated teams and to minimize multi-tasking, limit WiP and so on, this often leads to under utilized resources(people) but far more value to the customer and generally more profits.

Dependent Events

Another key principle is the impact of statistical variation on dependent events.  That is a bit of a mouthful but basically it means that in any given time period, output from a person or a machine varies, neither people nor machines are consistent, we have good days and bad days, some tasks take longer than others, we encounter problems and so on.

The results is that variation in output of one item in a chain impacts on the next and so on, and the longer the chain the more stages are impacted and the more variation disrupts the flow.

This is hard to explain without a demonstration and few people get it until they see it for themselves. Goldratt explained it really well with a game in the book The Goal, but sufficie to say balance is a fallacy.

Balancing the items in a chain (people, processes or machines) does not solve the problem, TOC explores techniques for managing flow to mitigate these problems.

Agile teams apply many of the flow management techniques TOC advocates – training T-shaped people, reducing hand-offs, buffering work, smaller stories, more paths through the system, continuous delivery. These are all techniques that come directly from the Theory of Constraints and have been adopted by Agile development teams.

littles-law-queue

Summary

You would be surprised at how many good ‘Agile’ ideas have come from the Theory of Constraints and yet we continue to consider it to be for industry rather than software. Think how much more we could be missing by not applying the thinking processes.

I’ll try to cover some of the aspects of the Theory of Constraints in future articles with some ideas of how they can be applied to software development.

It is not how big it is…

A question I have been asked a number of times is how do we “Scale Agile”?   There has been so much discussion of scaling frameworks such as LeSS, and SaFe, or Nexus or D.A.D. or even the Spotify model, that we have become conditioned to assume that these are the solution to any scaling or indeed any ‘Agile’ problem.

But as with so many situations and so many problems, deciding on a solution before fully considering the question at hand, leads to an outcome that is likely the wrong one and potentially unexpected and undesirable results.

What are you scaling?

Most of the Scaling frameworks deal with organizing and communicating between multiple teams all of which are working on a single product.  But that is not always the case, there is no ‘Normal’ and every organisation is different, some will have many teams and just one product, and some will have many teams and many products, and then there are the multitude of variations in between.

slide1

Many teams, Many products

But if the scaling agile frameworks cover the situation of many teams  and one product what of the remaining situations?  My instinctive response is to wonder whether this is actually an agile scaling question at all. It feels more a question of organisation scaling rather than agile scaling. That may feel like I am splitting hairs but I wonder if we are jumping to finding a solution to a problem that is neither new nor necessarily agile specific.

slide2

If our organisation is simply growing and we have more teams working on more products and there is little or no dependencies between the various teams then there is no scaling in the sense that these frameworks relate to.  The agile frameworks provide a structure for shared communication and consistency of purpose, and there is an overhead for ensuring a common vision and a consistency of direction. All very important when there is strong dependencies and interactions between the teams.

But if you are able to organize your teams with autonomy of purpose, and are able to minimize the coupling and dependencies then are you really scaling or are you simply growing?  The organisation that are multiple teams working on one product are genuinely candidates for scaling and so I will purposefully ignore them for the purposes of this post.

More teams does not mean you need a bureaucratic layer

The difference is that we don’t need huge amounts of overhead or a layer of bureaucracy, if we simply have a larger number of autonomous teams, then we are able to maintain a flat structure but simply grow and duplicate.  Naturally there are elements of the organisation that will need to ‘scale’ to deal with the growing number of teams and people but this is not agile scaling of the teams themselves.

What about dependencies between teams

In some cases there will be teams that have dependencies on another team, but it may be possible to organize your products such that whilst dependencies occur, the dependent team becomes a (very important) stakeholder in the other product, and so there may be a case for prioritizing stories that support the dependency. However,  there is not a tight coupling between these teams, they can still each be run almost entirely independently of each other.

Now this proposal is not entirely without overhead especially when there are teams that are inter-dependent. Identifying the boundaries between products may require some thought and effort. Coordinating the dependencies and ensuring they are given the appropriate priority will require some additional communication.

What about scaling on a small scale?

So that covers many teams and one product and many teams and many products, but what about a few teams and one product? This is actually the situation I consider most difficult.

slide3

But these problems are likely not enough of a problem to warrant the large overhead of structure that a scaling framework imposes.  Once again this seems to be more of a question of organisation than scaling, sure there is an element of scaling, but not so much that we need a heavyweight solution.

For this situation we may be able to make it work with something as simple as a few shared meetings (Scrum of Scrums) combined planning or refining session and a structured approach to delivery.  Organisation, and dare I say it, the true sense of management – not throwing around orders, but coordinating, enabling communication, promoting transparency and creating a clear direction.

The Product Owner may also be able to think about stories in a context that works well with a multi team view. It may be that it is a single large product but could  we divide by feature areas, or logical vertical slices of work.  Yes there may be situations where there is overlap but it may be that we are able to write stories or share stories between the teams that intentionally minimize conflict.  There are some elements that will require special consideration, such as UX which must be considered across the entire product and should be consistent, but that is not true for all stories.

But please do not underestimate the overhead of multiple teams – even just two, it is significant and can cripple the product delivery if not implemented well. You may need to lose some of the freedom of small teams, a shared definition of done, possible a common cadence, common deployment environments etc.  And there is a greater need for trust in an environment that is less conducive to trust. It is not possible to be involved in all decisions in a multi team setup. There will be compromises and conflicts. So much so that in many situations you would be far better to consider extending the timescale and managing with one team.

Summary

  • The first (many teams and 1 product) is well documented in the various Scaling Frameworks, I am not suggesting implementing them will be easy but they are well documented and there are many experts.
  • The second – many teams, many products – is a question of organisation rather than scaling, so should be no harder than you have found it so far, it is repeating the same albeit with a few complications at an organisational level.
  • But the last group fall in to a gap between the two extremes.  If I have say two or three or even 4 or 5 teams working on one product, I will still have the usual communication difficulties, the need for consistency of direction becomes ever more important and we have a situation where teams can be highly dependent on each other.

It may sound like I am discouraging using the Scaled Frameworks, and I suppose in a sense I am, but not because I disagree with their use, but because they all carry with them quite significant overhead of effort and cost and in a lot of situations there is no benefit and may even be a severe detriment. If you can solve the problem with a little bit of organisation, rather than adding layers of overhead and bureaucracy, surely that is better?

Naturally every situation is different, consider each independently, but please don’t assume because you have multiple teams you need a scaling framework.

 

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.”

Were Pirates Agile?

A good friend of mine has been watching Black Sails and he commented at how similar the structure was to a Scrum team and so I did a little research just to see what parallels can be drawn from a a band of pirates and an Agile team.

image

They are self-organising and self-managing

A pirate crew was very much a self-organising structure, all crew members got an equal say in decisions. Officers were generally elected including the Captain and the Officers. Almost all decisions were made by way of voting or the crew voted to delegate decisions to an individual.  The crews were generally cross-functional, some specialist skills were in short supply so people with those skills were highly valued but generally crews were expected to pitch in and perform multiple roles.

They had a Product Owner

A captain was elected and his role was to set vision and direction, to be a single voice and he became ultimately responsible for the success or failure of the project, he would choose the next target or destinatation and would decide how to respond to navigation hazards that could be planned around. There were some perks associated with the job but generally loot was divided equally amongst the crew, a Captain may get 1.5 or 2 shares. Successful Captains would likely be re-elected unsuccessful ones may not be so fortunate.  There was a distinct lack of authority in this role outside of navigation and strategic decisions.

They had a Scrum Master or Team Coach

Crews would elect a QuarterMaster, their job was to ensure the ship ran well, he understood the process and would do his best to coach the crew into keeping a ship running well. But the quartermaster did not have authority over the crew beyond this.  Pirate crews were made up of runaway slaves, deserters from armies and ships or fortune seekers, many were not skilled sailors or fighters and most had a very strong aversion to authority and discipline.  Quartermasters were first and foremost coaches. They would encourage the crew to learn the necessary skills and to keep the workflow effective.  Quartermasters were likely seasoned sailors with lots of experience and the ability to understand how a ship works and how to coach the crew to do it. But unlike the Navy where discipline could be used to enforce order a pirate crew didn’t do this. If a quartermaster struck a sailor they risked being marooned as a consequence.

image

The crew had individual responsibilities

All crew members had responsibilities and were held accountable by their peers, all understood that the crew stood or fell on it’s own so anyone not pulling their weight or letting the crew down was a liability. Whilst there were officers the officers were organisational necessities not authority figures, it was about communication not control. Discipline was most definitely not enforced by officers.

But the best parallel is that they had working agreements

The pirate code – perhaps the earliest documented team working agreement?  Each crew had and documented their code and held the other members of their crew accountable to it. The code contained how decisions were made, what decisions were delegated. How loot was divided. How the team interacted with each other. It was clear that in most cases it was a flat structure and that roles were temporary and were elected.

Pirates were generally forbidden from stealing, destruction, sexual assault, fighting, desertion, gambling or breaking up the pirate band. Some even mandated an early bed time!

Definition of done

This one in particular amused me, but the pirate code contained a definition of done for a Pirate.  If a pirate earned 1000 pound then he may retire. If the pirate lost a limb they could leave the crew and would be given 800 pounds. (400 pounds if it was just a hand).

 

So are pirate crews agile?   yes they Arrrgh !

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

 

 

 

 

STL Agile Open Space 2016 – Self-organising teams

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

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

Self-organising teams

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

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

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

Can there really be self-organising teams

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

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

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

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

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

The Role of the Scrum Master  
   

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

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

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

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

 

 

Why do we use WiP limits?

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

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

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

Limiting WiP

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

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

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

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

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

Why do we limit WiP?

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

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

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

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

Limiting WiP and WiP limits

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

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

Other forms of WiP limit

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

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

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

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

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

Example of how to choose a WiP limit in a workflow

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

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

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

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

Summary

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

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