The problem with Scrum

You keep using that word. I do not think it means what you think it means – Inigo Montoya, The Princess Bride

I’ve been pondering a problem with Scrum and agile in general for a while now.  Why do so many people use these named processes that encapsulate agile ideas as swear words?

Others seem to have been pondering this too with Ebenezer Ikonne writing his thoughts at https://eikonne.wordpress.com/2015/12/30/the-traditions-of-men/ and Ron Jefferies at http://ronjeffries.com/articles/015-10/xtian/.  These are worth reading.

If you’re doing Scrum or XP or being agile or doing some other process / philosophy that focuses on quickly learning what to do and executing on it and then checking to see what to change and readjusting continuously – it can have awesome results. So why do so many people use these named processes that encapsulate these ideas as a swear words?

A Problem

Scrum has been a highly successful marketing success. Everyone is doing it. That is part of the problem. It is accessible as it is “just some practices”. But it isn’t just some practices. And huge numbers of adopters are getting that wrong.

This has resulted in Scrum and agile being about control to many that have experienced it.

I have two friends whose formative experience of Scrum was an implementation that literally created waterfall documents in sprints for several months. To them – this is what Scrum was about. Their opinions have changed since, but this was their formative experience of Scrum. If they hadn’t since had good experiences – or good conversations about why this isn’t what it is about – then that would be how Scrum would be for them.

As Sarah Mei puts it:

how can we reclaim autonomy and control over our work in an industry where “agile” is most often a tool of top-down corporate control? – Sarah Mei [1]

It is hard to refute someone’s personal experience. This is what it means to them.

Words have power. And when you let them mean something to people – that is what they start to mean. As Ron Jeffries puts it:

 Agile is what people who call themselves Agile do.

It seems to me often that every good idea gets watered down and ultimately perverted. “Agile” is no exception. There are many bad things done in the name of “Agile”, and many more quite inadequate things. – Ron Jeffries [2]

It turns out the personal experience of people is a powerful factor in determining what people think. It doesn’t matter if what they experienced was completely not agile or not Scrum to those that understand and experience agile or Scrum in a positive way. Their experience was done in the name of Scrum / agile – and in many ways that’s just how it is.

You’re Doing It Wrong

There is a trite saying that I heard early in my Scrum days – “Scrum does not fail. You fail at Scrum.” It is so easy to say you’re doing it wrong. You’re not being agile.

Software development is hard. And as can be seen by the rise of Safe, DAD, Mom, Pop, LeSS – people who are unable to bring the existing lightweight – but easy to misinterpret – processes to bear are reaching for other silver bullets to help.

 “@twykowski: There are more companies trying to scale Scrum than to do Scrum right.” Yes, isn’t it curious? – Peter Hundermark [3]

An early idea that I read about was the metaphor of Scrum an abstract class. All implementers of Scrum will need to do it within their context and by definition that will be slightly different. So if you’re doing it differently to someone else, this is by design. But the abstract ideas and principles and practices should manifest in the same way.

Could you do it better?

Perhaps.   Has everyone read the Scrum Guide / Agile Manifesto?  Does everyone have an equal say – particularly in debating whether something that is being done is true to the principles and values from there?  Strong debate on how to do the work grounded in achieving the same principles and aligned with the same values will make the team stronger.  And they will then buy into how the work is done when they are empowered to do it well and improve.

Does it actually matter?

Maybe? Maybe not?

I used to be a Scrum zealot. It worked well for the implementation that I was doing. We were highly successful in the things we did and I learnt a lot.

I used to think that Agile was a thing, and that everyone should do it. I guess I kind of still do think that, for values of “Agile”. But the term is so watered down that it scarcely matters. – Ron Jeffries [4]

Then I joined a company that was doing Scrum and it was a mess.  The spell was broken.

Then I joined a company that didn’t do Scrum and we used bits and pieces and things were better than when we started. This was a Good Thing.

Mostly, what matters is operating your work and your life so as to maximize whatever you consider to be happiness. – Ron Jeffries [4]

Stop worrying

I’ve mostly stopped worrying about the name of the process that I use. I’ve moved back to values and principles.  Most of the bad things done in the name of Scrum and agile are due to lack of understanding of these values and principles.

To me, it is important to know why we’re doing practices and where they come from. So rather than Scrum, Agile, XP – I’m more interested in Feedback and Simplicity, Humanity and Reflection. I still value the structure of Scrum / XP – with iterations, POs, SMs, retrospectives – but I value more understanding from the values and principles that they are derived from.  And I’m happy to let those specific practices go, if the values and principles that underly them are still important and optimised for.

Positive Sharing

Lets positively share more of what works well for you – in your context – and WHY it works.

Lets stop spending time trying to negatively pull down what you think others are saying you should do.

As Ron Jeffries posits

More and more, I try just to talk about the specific things I do, without proper names. Maybe that’s best. – Ron Jeffries [2]

This is a good thought.

It might also be an idea to not give your thing a name 😉

 

[1] https://devmynd.com/blog/2015-11-30-managers-developers-and-the-in-between-p1/

[2] http://ronjeffries.com/articles/015-10/xtian/

[3] https://twitter.com/PeterHundermark/status/677205905276932096

[4] http://ronjeffries.com/articles/015-12/agile-or-not/

 

Advertisements

What Scrum has taught me about how to write good code

Every developer aspires to write good code.  Nowadays everyone is talking about clean code.  If you ask any developer most likely they will tell you that their code is good and/or clean code.

What makes a piece of code good?  Is it code that passes all the tests?  If it passes the tests, must it be correct?  Is code that meets the end user requirements good?  The story is done, so we can do the next one – surely that is good?  Is code that is layered good?  If all the methods are less than 10 lines and all classes less than 100 lines, is it good?

The biggest problem with “good code” is that all code is subjective.  And you only learn how crap it was after you’ve lived with it for a year or two…  then it becomes a pain if you didn’t write “good” code…  and most likely the person who wrote it isn’t on the project any more.  And maybe they aren’t in the company any more.  But they probably were very opinionated as to what good code was when it was being written.

Small pieces
Scrum taught me to value small pieces.  Small pieces lead you to composition of objects – breaking the system down into smaller objects that combine to become a greater whole.  Each part is very easily understandable.  Each part is very easily testable.  Each part is really very small.

This realisation can come from forcing yourself to focus on testability – which forces composition – which forces you to notice that you have lots of smaller things which are much simpler and far easier to understand.  And hence they are easier to maintain.  And the complexity of any single thing goes down.  Cohesion and coupling become clear.  Separation of concerns becomes a primary concern and it becomes easier to see.

Small things are good.  Small things optimise for simplicity and understandably.

Many pieces
This does come with the problem that you now have lots of little bits.  Now you need to understand how they fit together.  This could be conceptually intimidating if you try to hold it all in your head at once.  Concerns arise about what if it doesn’t all integrate correctly.

But you no longer need to hold it all in your head.  Smaller units of code combine into a single cohesive thing that has a well-defined interface and now you worry less about all the little things – you just worry about how you use the outside interface.  This is very similar to a backlog which can at times represent lots of potential stories but the ones further away are stored as epics.  The detail is only needed when you need to look more closely – and then you unpack them – just in time.

Trusted pieces
You land up with small things doing very clearly defined things that are easy to understand.  And you trust that they work as the tests specify how they should work and they still pass.  The more your system holds together like this along with keeping to small object graphs – the less the concern of integration becomes as your tests tell you how the code should work.  And you gain more trust in your system.

You do need to ensure that the implementations of the same interfaces behave similarly.  If you’re mocking an interface for testing things there could be a misrepresentation between the mock and reality.  But that is a code implementation / design problem that we already have.  Failing at that and having things unexpectedly coupled in odd ways that aren’t represented by tests / mocks is possible.  But you should understand both sides of the interface that you’re using in order to change the code around it.  That isn’t a new idea.

Knowing what you intend to do
Which leads me to knowing what you intend to do!  Doing TDD challenges you to really decide what you’re doing before you start.  It challenges you to be really in control of your code base – even the stuff you didn’t write where it influences you.  And that is a great thing.  Being in control of your code base means that the integration problem won’t happen as you really understand how it fits together on both sides of the interface before you modify it.

Small graphs = small messes
Developing using TDD and breaking things small also leads you to small graphs.  Small graphs help you to potentially make lots of small messes instead of a few large graphs and one very large, interconnected ball of mud.  Small messes can be individually fixed in a contained way.  Large messes are far more difficult to fix.

You will never know it all
Scrum and agile ideas embrace the fact that you won’t know enough to start with.  TDD enables safely not knowing enough.  It allows you to learn and refactor the system in safe small steps as your knowledge grows.  Refactoring saves us from having to have that perfect good code up front.  Refactoring allows that code to change and become completely different good code – more closely fitting to the actual current purpose – over the years.  Refactoring is what keeps the code base fluid and alive and closer to the reality of what the requirements are actually right now – not how they have been hacked on from the design created from the little that was known two years ago.  But refactoring can’t be safely achieved without tests around the code to be refactored.

Value Driven Development
When doing Scrum you move from Shu to Ha when you really understand the values and principles of Scrum.  When you understand them and really get them you can experiment with things based on those values and principles instead of blindly following what the Scrum guide says.  But if you still don’t actually understand you will probably get burnt (and blame it on Scrum).

This is similarly useful when writing code.  Understand the values you are trying to live by and optimise for them.  Reflect when you fail to achieve them in order to get better.  Write code with your eyes wide open so that you always know why you are doing what you are doing.

Optimise for something
I suspect many OO developers start out optimising for encapsulation and hiding behaviour.  Only optimising for that can lead to tightly coupled, large graphs and a ball of mud.

Scrum suggests deploying working software every 2 weeks.  How can you do that? Perhaps automation is required to give us the feedback as to the state of the code so that it can go live.  So optimise for testability that can be automated.

If I optimise for testability or reducing the risk of change it may lead to a less tightly coupled system and smaller messes.  I might discover things about composing objects and the SOLID principles.

If I optimise for knowing my software is working 100% or a fast feedback loop on changes that I make to my code then I might want to use TDD to enable that.

If I optimise for maintainability it might lead to more readable code and smaller functions and classes.  That might lead again to a less tightly coupled system and smaller messes.  I also will probably want to optimise for testability so I can get faster feedback about the impact of changes that I’m making in code that I’m unfamiliar with.

If I optimise for changeable or fluid software I may want to make things smaller and less coupled, I may be want to do TDD so I can get feedback on the effect of my changes as I make them.

If I optimise for the simplest thing that works, I may learn a lot about how code could be designed.

If I challenge myself as a developer as to what I’m optimising on – and know that this is a good thing – then I can consciously experiment and learn how to write the best code I can for the value that I am trying to optimise for.

Where does this come from?
This all might be obvious to many of you.  But to me, thinking hard about how to do better code, I’ve had interesting conversations and thoughts driven by a more agile mind-set over the last couple of years.  Several of those ideas were more clearly crystallised when attending an agile developer course with Aslam Khan and KRS late last year and experiments before and since.

I think “good” for me is becoming more defined – in a different way – from say 5 years ago.  I wrote fine code.  I could solve anything given enough time and relevant hacks if needed.  But eventually projects would get messy.  And frustrating.  And change would be unsafe.  And it would become harder to change.

A couple of years ago I stopped coding for my job.  I led an agile transition implementing Scrum.  I learnt a lot about Scrum.  And so I’ve relearnt how I should code with an agile mind-set first and foremost.  Now I’m practicing to actually understand how to implement those ideas.  And it is awesome.

I feel far safer now.  I feel more in control of the code base.  I feel safer to change.

Scrum taught me the wisdom to break things up small and to understand what you’re really doing.  XP translates that to the code level and gets you in control of your code base.

All of this leads to a far clearer understanding of why any line of code is there – where it is and why it should or should not be somewhere else.  The code is cleaner.  Hopefully it is good code.  Hopefully it is clean code.  But most of all – hopefully it will be easy to change to be cleaner or better as the design changes.  And I’ll reflect and learn why if I fail – so I can actively do better code next time.

Hopefully I’ll also learn a lot from all the great coders out there on how they too are doing better code.

The same things don’t always work

Over my years of getting to know Scrum and the agile way of working, I have experimented with a lot of things.  I have found things that didn’t work and I have found things that did.  I’ve kept the things that did work and tweaked them as needed.  They were good tools for me and informed my thinking around how I succeeded using Scrum.

Then I moved jobs.  I took my toolset with me.  And I tried to use my same logic and thinking.  And people heard my words and too often for my liking interpreted them to mean something completely different.  It was very educational and taught me very strongly that The Same Things Do Not Always Work.

Context is King.
If you’ve built up context around certain ways of working then people know how you got there as they were there with you.  They understand.  They emote.  And when you bring those ideas fully formed into another organisation that have strangely not lived in your head for the last couple of years, they don’t necessarily immediately understand or emote.  And this isn’t their fault…

My failure has been in not understanding that my tool set held the tools that I had decided upon by applying the principles that I understood and in order to use the same tools at a new organisation I had to first back away a little and bring out the principles again to see if those same tools would still uphold those principles in this new organisation.

A simple example: Ship when you’re ready
For more than a year I had been working with a team delivering software which was officially shipped on days that weren’t the sprint boundary.  The team were fine with this.  We always aimed to finish before the sprint that we shipped in.  If we could plan it on the boundary we would, but sometimes it didn’t work out that way – and it didn’t matter.  We were completely fine shipping when we were ready – instead of waiting for an arbitrary date boundary for the sprint end.  Everyone was good.  It worked well.  It felt obvious.

Obviously if there was a large amount of work to do and you asked the team to commit, they can’t commit to earlier than a sprint length.  But – if we’re done, we’ll ship – why wait?

And then it didn’t work…
Fast forward to a new organisation.  We have some work to complete.  We have a ship date.  So we discuss and using the previous pattern from my tool set I suggest – if we’re ready we’ll ship.  If we’re not, we won’t.  Somehow this was interpreted down the lines as: we are going to change the sprint length to 1 week and people will deliver by the deadline or else.

What was the simple “if we’re ready we do it, if we’re not, we don’t” turned into an angsty changing the sprint cadence rush to complete.  But that was the organisation’s interpretation of what was, for me, a clear and obvious way of working.

Which made me think
When going into a new organisation – go back to basics.  Say no to all the broken rules – until you know which ones you can safely break without someone abusing the situation.

Another example: Velocity
For several years I had been using velocity and planning stories in a reasonably reliable fashion. The teams I had worked with weren’t highly passionate about velocity but were focused on the work at hand and usually knew what the next sprint or two held and were willing to push their capacity to try and achieve more points in a sustainable way.  The combination of measurement (to aid planning – and replanning every sprint) with knowing what you’re doing for the short term helped ensure that the team was both productive and reasonably predictable.  This was great for building trust with stakeholders who had legitimate concerns about delivery in the past and it also enabled us to go a faster.

And then it felt pointless…
Fast forward to a new organisation. No sizing. No sprints. So I enthusiastically said we should try a little Scrum.  So now we do a little Scrum.  But we don’t use the velocity or plan beyond the current sprint.  And it works.  And no one actually is worried.  And the stakeholders are okay with everything.  And everything is roses.  So why measure?  And why plan?  When you can be agile and make it up each sprint – because the work is still known in a reasonable fashion.  And we’re as successful as is required of us.

The tool set that I brought with me didn’t result in the changes that I anticipated and in fact possible adds little value right now. I suspect many reasons for that.

Which made me think
Scrum isn’t just a framework.  Context remains King.  You can’t just walk in and apply your learning from another context to the new one without understanding the context and working with the people who are in it.  That doesn’t mean you can’t ask questions and make suggestions – but do just that – rather than judging too early.   Agile is about principles – these lead you to the learning and the tool set.  Always go back to the principles and the spirit and validate – particularly when approaching a new team or new organisation with your existing experience.  Unless, of course, you have the remit to cause revolutionary change.  In which case, go wild!

And there is a point
My failures over the last year have fuelled much introspection and learning.  I’ve opened myself up to question myself around my understanding of Scrum and agile.  And I’ve seen very clearly how no one size fits all.  I have found this a powerful learning experience.  Seeing what you know does work not working any more deepens ones understanding of what it is that you’re really doing.  I’m thankful for these new experiences that have allowed me to grow a deeper understanding of what has worked by understanding why it hasn’t worked as well.

I now hope I keep remembering to not apply my tool set too soon in the future in the hopes that I’ll more effectively apply it with a deeper understanding of the actual context.  Or perhaps I’ll find a more universal tool set to apply.

Getting low priority work Done

Scrum is great at getting an organisation to prioritise.  The Product Owner is responsible but clearly they need to get some level of buy in from other stakeholders a bit as well.  Having a prioritised backlog is a key component for successful Scrum.  It allows the team to focus on the real business needs of the organisation.  This is awesome.

Prioritised backlog

But when we start to aggressively question ROI on every single change that we make we often deprioritise work that actually does need doing.  Work that is more intangible often doesn’t get done.  Work that is low priority but provides the polish that is necessary to be truly proud of the work doesn’t get done.  Often these are the bugs that can be argued as features that really should be killed – but they never are and hence hang around – for good reason.  They actually are things that we missed or things that we could tweak that would make the solution a more professional one.  But because the current priority is The Next New Epic they don’t stack up in the prioritised backlog.  So they go unattended.

Why have you still not done this obvious stuff?

This generally goes on for a while and then a stakeholder gets irritated and asks why these issues are still not fixed.  The answer is simple – they haven’t got to the top of the backlog priority.  And then the interesting discussions start coming out.

Now we’re thinking

Suggestions arise such as – let the team take in say 15% of their time as low priority items that had been around for a while.  Or, let one person work on low priority items each sprint.  These suggestions are great as they show a commitment to getting some of this work that should be being done, done.  Perhaps the PO should have been prioritising a bit more.

But

  • 15%?  That is difficult to actually quantify isn’t it?  Unless we count it in number of days. And it rather defeats the point of the blackbox of the sprint.
  • 1 person planned with known assigned work during a sprint?   That impacts the rest of the team as it will need testing and deploying and potentially interact with their planned work.

These don’t feel like collective ownership solutions.

Some scenarios

I’ve seen different scenarios play out in solving this – some more team oriented than others

  • X% time – essentially reduce the velocity to give time for picking up the low priority work
  • Fixed chunk per sprint – take Y stories / X points in the sprint
  • Give it to the support guy – if you have a rotating support person on your team – either they do support or they do low priority work when there is none.
  • Give it to the support team – if your organisation has multiple teams and one rotates onto support – let that team pick up these items.
  • Do dedicated sprints for low priority items.
  • Just prioritise it like backlog always is prioritised.

I’d much rather see the PO plan the work.  Potentially with the team taking 1 story per sprint to deal with it.  Maybe put it at the end of the sprint’s backlog so that if anything falls out of the sprint, this work does.  Then at least they can plan and prioritise it and work collectively.  And share the responsibility of getting the work done.  Kind of like Scrum intends!

I personally prefer the approach of incrementally dealing with a bucket load of work.  For things like technical debt (which some of this may be) or low priority work or minor/trivial bugs – I’d rather see a product owner prioritising a small number of these into every sprint so that the product is continuously being improved.  But sometimes that is harder to sell – particularly when you’re doing date based releases and you approach the deadline.

You do however need to tend and care for your system and for your users to make sure that you are slowly making progress about the stuff they care about – even if it isn’t the thing that will make the next big impact on the bottom line of the company selling the software.

Has it happened to you?  It would be interesting to hear other people’s experiences with this.  How have you solved it?  As I suspect this is quite a common scenario.

Dealing with Bugs

The below diagram is the basic flow that I generally adhere to when talking about when should a bug get fixed or not. This is pretty obvious – and far easier to draw than to write out.

Bug flowchart

There are of course some subtleties – the devil often being in those details.

Analysis – this is all about analysis.  Sometimes it is easier to do.  Sometimes someone needs to do some digging to work out the details.  That doesn’t change the decision flow – just that you might need to do more work to get to the decision.

Bug definition – internal issues generally really are bugs as there is usually higher communication around what features and changes are and how to handle those within the team.  For external issues they could be changes, features or plain old bugs.  I assume that that analysis is already done or becomes clear during the process.  No matter what type of issue it is – they are all subject to the same decisions.  It is often easier to put a feature/change straight onto the backlog for later planning.

The problems with not fixing bugs now:

  • One small bug not fixed now isn’t a problem. 100 is.  Don’t naively grow the debt by only looking at the current issue in isolation.
  • Not fixing 10 bugs may signify a more rapid decline in not fixing other issues as it gets easier and easier to justify not fixing something.
  • Not fixing an issue now may underlie a bigger problem.
  • Hanging on to issues that you choose not to fix immediately grows the backlog with low priority issues.  Generally these low priority issues never get prioritised because… they’re low priority!  Be aware of simply growing a long list of things to remember that you’ll always ignore.
  • Make sure that if you decide not to fix something that it doesn’t keep coming back.  This is even more pertinent if the team find it and the PO decides to fix it later or never but then when someone else finds it nearer your release date – for instance in a hardening sprint – and now it needs fixing.  This shows a problem with the initial decision and will cause frustration for all.

Points for bugs – if I plan a bug for a future release I generally consider it a change and want it to be sized.  We’re sizing the effort for the release so we might as well get as much data as possible.  If you’re fixing the bug before the release then at most size it to determine how much you can take into the sprint but don’t take points for it as the number of bugs you’re creating is part of your velocity and the real velocity should drop due to work that isn’t properly done being done again.  The team should acknowledge that.

Learn from the feedback – as in any agile environment – look at what is happening and try to retrospect on why the issue happened and how we could avoid it happening in the future.  What documentation or details could have been shared with the client so that they could have known that what they were asking for isn’t a bug?  What did we miss in our own process that caused it to be a bug?  Sometimes it is too easy to say it was some once off thing but many once off things could also have the same root cause – or the same solution.  Dig a little deeper if everyone simply thinks – well that was due to this one deployment specific issue that now we’ve gone through – it will never happen again.  Because it probably will happen again – in some other form.

Autonomy

A while back I blogged on Drive.  I’ve been meaning to revisit each theme with some observations but I’m only getting round to the first one now.

In Drive, autonomy surrounds the what, when, how and who of your working environment.  In order to get high productivity, you need to allow people do the work in the way that they want to do it.

The focus on drive is on individual motivation.  Does this also equate to team motivation – or do these two compete on some levels?


Individual Autonomy

Individual autonomy seems obvious.  If I have the freedom to do what I want, when I want to, however I want to then I will hopefully be motivated to do it well.  If I also get to choose who I do it with (or don’t do it with) this makes me happy.

The downside of autonomy is that without purpose it may lead to not being motivated on the goals of the organisation but potentially more on the personal goals of the individual.  That lack of focus may cause friction in an organisation and potentially a backlash against giving people autonomy – simply because if we reduce the autonomy we reduce the waste of doing the wrong thing.

The solution is clear – find purpose and enthuse people with mastery over their work.  Without that there is risk that the autonomy means that I feel okay to be unproductive when I don’t have the motivation and drive that I need.


Team Autonomy

Scrum teams should be largely autonomous.  That is what self-organisation is all about.  But some of what makes a team potentially contradicts the individual’s autonomy.  Is this a contradiction?  Or do we just widen the scope and focus on the team as the individual?

What

A Scrum team gets to choose what it works on – by pulling from the backlog – and how much it works on – by limiting the number of stories in the sprint.  Obviously the constraints are limited to what is on the backlog.  This ensures the focus is on the organisation’s goals while limiting the autonomy over what.

A Scrum team also gets to determine retrospective actions that it takes into a sprint.  This allows the team some choice as to what to work on – alongside the constraint of the backlog.

Individuals in the team get to choose what to work on – though preferably the next highest priority story on the board.  The tasks within the story are not allocated so team members may choose what to work on – as long as it contributes to the completion of the story.

When

I suspect most collocated Scrum teams don’t get as much say over when they do the work.  The goal of collocation is to enable the team to work as a cohesive unit.  The individuals usually get less of an option of doing 24 hours of solid work and taking the next 2 working days off – as they need to decide to do that as a team.  The “when” is determined by the working agreements of the team.

Everyone should be working during the time of the stand-up – or come up with a working agreement of how else to deal with that.  The same would occur with sprint planning, reviews and retrospectives.  These activities are team activities that the team can decide when to do them as a group.  The individual has to work with what the team decides.

Activities like pairing also reduce the autonomy of when an individual can work as they need to work with their pair at the same time – otherwise it isn’t pairing 🙂

Individual autonomy around when to do the work can contradict the team’s need for when the team needs to work together.  This can be solved with working agreements, but those working agreements are team decided artefacts so clearly there is compromise and the autonomy of the individual may take more of a back seat to the autonomy of the team.

How

A scrum team is always responsible for how the work gets done.  This is clear.  The only conflict that can exist is when individuals have differences of opinion on how the work should get done in the team.  But this is more a general team dysfunction than an autonomy issue.

Who

Clearly a Scrum team doesn’t get to decide who they work with on a daily basis.  They are a team and should be working together.  If there is a team dysfunction then the team make-up may change to resolve the issue.  The general concept of teams disbanding and swarming into teams on the fly to solve problems isn’t a goal of Scrum.  Scrum promotes team cohesion by having the goal of not changing the team make-up.  So the individual has less choice over who they work with on a daily basis.

However the individuals do get a choice over who to pair with and who to help and work closely with.  But the goal of a team would for all individuals to be comfortable in doing this with all the other team members.

There are mechanisms that can be put into place to increase a team’s autonomy around whom they work with.  If they are involved with the hiring process – either with interviews or meeting the candidates – they can make active choices about the people they work with.  I have read an article around teams allowed to make the choice to request a team member to leave via a voting mechanism – a kind of Scrum Survivor.  It is also possible that over the longer term you might want to allow teams to disband and reform when a project is coming to an end to increase the autonomy of who the individuals work with.  That does come with the risk redoing the forming / storming / norming / performing cycle.  But it could be interesting to see the outcome.

Team autonomy

Clearly teams can be autonomous – and should be in Scrum.  Some of what a team is does however conflict a little with individual autonomy.  Find the right team members and this won’t be a problem.  Find the wrong ones and there may be conflict instead of the necessary compromise to make any team awesomely motivated and driven.


On a personal note

In the organisations that I’ve worked I’ve generally had a good amount of autonomy.  And with that I’ve felt a high level of responsibility.

I have found that often the what is relatively high level and the how has lots of freedom.  The who is always constrained by the organisation’s operational abilities – such as how they are allocating people – to clients or to projects that are internal.  In internal development on a project or product there is generally a higher degree of mobility between projects – as it is all accounting – but if there is a single product there may be a smaller degree of mobility across different types of work.  In outsource coding organisations there is often a higher mobility in different types of work (given the constraints of work coming to an end) but less mobility simply when you want to move.

When you work is always determined by the organisation’s culture.  If you need to log hours that influences the when as well as work becomes accounting based and not outcomes based.  My experience of the organisations I have worked with the when has always been good – other than any after-hours support that may occur in a given organisation.


Is autonomy important?

Autonomy is a key ingredient.  But when the other ingredients are missing – particularly purpose – then autonomy can become a double edged sword – providing productivity but also reducing it when the focus is in another direction other than the direction the organisation needs to move.

Scrum teams do not contradict individual autonomy.  The autonomy of the team should be respected.  Individuals should compromise with the team in order to ensure they retain sufficient autonomy while ensuring the team is a cohesive working unit that is greater than the sum of the individuals.

Incremental Play

Incremental Change, Working Product

In our recent trip to New Zealand we stayed with a friend in Wellington who has two children near my girl’s ages.  They had a lovely train set which my girls loved.  However the first couple of times they set up the train set they mostly built it in a straight line and then got frustrated when they couldn’t make it loop back on itself and complete the track.

I watched this a couple of times and then, as daddy is an engineer, I landed up helping them build the track one morning.

The key problem is that there are a number of pieces in the set, but it isn’t clear what configurations are supported in order to ensure a closed track.  So I thought I’d try Scrum to solve the problem.

Short iterations

I did not timebox.  That would have been far too geeky.  But we did start by making the simplest possible thing that would work as a closed track.  That was a 4 piece circle.

Working product

I demonstrated this to my stakeholders / product owner (my children) but they weren’t too impressed with my track.  So we iterated – and built it out.  And built it out some more.

Each time we expanded by breaking the track, but fixed it quickly by doing the least work required to create a better, larger, cooler track.

Review

Each time we had a working track the girls would drive the trains along the tracks and test out the ideas and make suggestions for what needed to be included.  The tunnel, the bridge, more side tracks, etc.

Scrum Works!?!

By keeping the track functional as much as possible the girls were able to play at quick, regular intervals all through the process – on many different tracks.  By doing the simplest thing possible we could expand it, inspect and adapt and have a closed working track that maximised the use of all the train set by the time we had finished building it out – which was the business goal for my stakeholders / product owner.

It was SO COOL!!!

I might need to try the lego thing now 😉