Alignment

I’ve spent a lot of time thinking about alignment recently.  Over the years I have learnt that if we are not aligned, ideas fail no matter how good an idea is.

Testing

There was a time not that long ago where automated testing was not the norm.  I was fortunate enough to work for several years in the mid-2000s on a system covered with a fully automated test suite that deployed to production every 2 weeks or less.  It was, in retrospect, an incredible software development environment.

When I moved on from there, I joined a C# development company.  I wrote tests with my code.  I soon discovered that no one else in my team did.  They were mildly amused with the idea.  That was what manual testers were for.  Over time, as they were not invested in tests, if they touched code that was tested, the tests would break, but they would not fix them as they didn’t even run them so never knew they were broken.  We set up a CI server to compile and run the tests. Even then, the tests would still be broken by another developer and not fixed as the culture was not one that watched for red builds.

I learnt that if we are not aligned in our expectations we can waste a lot of time and still fail.  This makes adopting testing hard if everyone is not aligned.

It could take just one person not to care about red builds and broken tests to break everything – unless the team or the organisation corrects that behaviour.  In an aligned team that takes CI and testing seriously, hopefully that will not happen.

I’ve also seen a testing culture across multiple teams respond to new developers who did not test by showing them the way and giving strong feedback when they continued to avoid testing.  I have experienced that when the alignment and culture is well embedded, self-correction will occur.

Scrum

I worked in an organisation where I helped adopt Scrum to good effect.  If people are aligned to try and adopt and to openly discuss the issues, then we can be successful.  My experience in that case was that the most vocal sceptics became the most vocal advocates.

I moved at one point to another organisation which was kind of doing Scrum. No one was particularly worried about their process.  They did it. That was all.  I learnt if you are the only one who cares about trying to do something well, then there isn’t much point.  If no one else is aligned with doing something well, then as soon as your energy drops, no one else will pick up the slack. (I wrote about this in The Same Things Do Not Always Work.)

I learnt that if we are not aligned in our expectations I can waste a lot of my time and still fail.  This makes adopting Scrum and agile hard if everyone is not aligned.

It could take just one person to make Scrum very painful to adopt, particularly if that person is one with influence.  The team or the organisation needs to correct the behaviour to allow success.  In an aligned Scrum team that behaviour is harder to not confront, so hopefully one person is not able to do that.  In an un-aligned Scrum team, it can become a mess.

Agile Aligned

I have worked in an organisation that was highly aligned on agile software development ideas.  It was a pleasure to work there. The cultural expectation was “we do agile” and we argued about the nuances, not the should we do this thing at all.  This alignment was not just in the way we built software but also the way we interacted and were managed / autonomous.  This alignment made a huge difference to the quality of conversations around the problems we had to solve and how we worked.  Our core values and principles came from approximately the same place so the practices we advocated were based in those.

Alignment was clearly beneficial to the success and enjoyment of working together.

A Cycle

I’ve been through different parts of the cycle of discovery, adoption and mainstreaming of these ideas in different organisations.  I’ve been through where they have not worked, or they have not been personally worth it, and I’ve backed away and refocused.  And I’ve also been at the end where this is how we work and have seen the clear benefit of the alignment.

As we try new ways of working we keep on going through this cycle.  As we learn new product methodologies, new ways of managing / working with people, as we learn how much autonomy is a good thing for a given set of people, as we learn to experiment – and learn which things we need to learn and which things we know already (so why are we relearning them?), as we scale, we go through this cycle.

Sometimes an idea, principle or practice might be too soon for this group of people as no one else will help drive it, or sometimes it might be just the right time and we can make progress, or maybe it is the right time, but we are struggling as some might be disrupting.

Good pains or bad pains

Adopting new ideas often results in growing pains.  Aligning to working through those pains is important.  If not, we will likely fail.  If we are all aligned in our values and principles, maybe this alignment will be easier to achieve.

A common comment is: if Scrum shows up problems, do we abandon Scrum?   Or do we fix the problems that are shown up.

As we pick up new ideas, this pattern emerges again and again.  Is the idea the problem or are we failing to solve the problems that are being exposed?

The more, the harder

It is far easier for a single team to be aligned.  Alignment can always be helped through retrospectives.  This assumes that you’re aligned that retrospectives are useful and that everyone is working together to make them work.  Otherwise they might be potentially wasteful and negative.  Potentially one person could make a retrospective useless.

As the number of people grows that need to be aligned, alignment becomes harder.  As does the probability that there will be at least one person who might be disrupting – proving the exception to the alignment.

My current running hypothesis is that it can take just a few unaligned people to disrupt the adoption of any valuable idea – unless the team(s) or the organisation corrects the behaviour.  Strong alignment comes with a strong capability of team(s) to self-correct individuals who are trying to disrupt that alignment.

As the number of people involved grows how do we keep aligning across teams at the right level?  Could it be possible to structure things such that the number of people that need to align are fewer?  Would this make alignment simpler?  And what would it mean for the organisation at an even higher level?

Certainly it seems beneficial to build a robust, aligned culture that self corrects to stop the power of one from breaking it.

Alignment is hard.  People are hard.  But achieving alignment can be really worth it.

Advertisements

Why do some decisions fail?

Gladys has just received a notification from her company’s security guild that they will be adopting a tool to manage application secrets.  She is happy that someone has made the hard decision.  She will happily use it when she next needs to deal with secrets in the applications she works.

Zanele has just received a notification that to enhance pairing all developers are required to use emacs with the same environment settings.  Zanele is incensed with the decision.

Gladys may have actually forgotten what the decision was by the time she actually needs to use it.  Hopefully she’ll remember that there is a solution and ask.

Zanele is likely to ignore the decision for as long as possible.  She will resent the decision.  She will complain about how management force developers to do things.  Maybe she will check out what is available on the job market tonight.

Two stories, both fictional, but they both speak true.  What is the difference?  Why can some decisions that come from elsewhere be happily embraced while others really not?

Gladys is not being expected to change what she does.  She is just happy that someone has made a decision about something that she may not be doing yet or that she does not do frequently.  Gladys is not invested in the solution that is being presented.  Fundamentally she doesn’t really care though she is happy to be provided with a solution.

Zanele cares very deeply about using vim and has honed 10 years of skill using it.  Her setup is exactly as she wants it and all the hot keys are mapped like she wants them.  She has no desire or reason to change but she is being told to.  She has not been given a voice in the conversation in deciding the solution that fundamentally changes what she does on a day to day basis for a problem she may or may not be aware of.

Instinctively Gladys understands that the solution presented is needed.  It hasn’t been explained in detail (or it might have been) but her response is based on a belief that the request is reasonable.

Zanele has been given a solution to a problem.  She does not like the solution and perhaps she can see other ways to solve the problem.  She resents the solution and does not feel it is reasonable.

Making a decision around what Zanele actually does on a day to day basis without consulting or including her in the problem solving is a recipe for push back.  “Making” the decision was not hard.  We’ll just tell all the developers to change what they do.  Getting acceptance that the decision was a good idea – is something completely different and may turn a “good” decision on paper into a failed decision in reality.

The scenarios that play out are different and these examples may be simplistic but the majority of frustration I see is when autonomy of how I do my work is taken away from me.  Ironically, the more autonomy I have about the way that I work, the touchier I may be about what I expect to be in control of and influence.

Make decisions I don’t care about without me

Gladys didn’t care about the decision hence she was happy it was made.  (Someone had to make it.  Thankfully it wasn’t me.)

Include me in decisions I do care about

If Zanele were involved in the decision-making process it is possible that she would agree that the solution presented was the best possible outcome.  Alternatively, she might have provided some other options.  Being involved with the conversation would have given her insight and understanding.  The outcome of the decision might be the same but the emotional response to the decision may be completely different if she is involved.

So how do we know what decisions people don’t care about?

I don’t think we can know what decisions people will care about and hence it is very difficult to know that any specific decision is going to get push back.  A reasonable baseline may be that if you are going to impact what someone actually does, and they actually have to change their current behaviour and actions from existing ones, they are probably going to have an opinion on it.  Even more so, it will fail if those who need to implement the change do not think the problem is worth solving.

The first step is awareness.  In my early days of doing things more collaboratively, I was often reminded by a colleague “have you asked the team” for a decision that I thought was simple and obvious.  Sometimes we just are conditioned to making the obvious decisions even when they impact others far more than ourselves.  (I think I am better at this now…)

Once we are trying to be aware that decisions influence what people do, we should deliberately structure things that allow people to opt in to the conversation about what they care about and out of what they do not care about.  We need to foster a culture where expectation around autonomy and being involved matches with actually being involved.

The decision could be easy.  Achieving adoption might be less so.  Changing what people do is hard.  Being aware of that is useful.

There is much more to be said here.  This is just one aspect, but it is one that has struck me time and again that is too often not acknowledged.  If we start with actively respecting the people impacted by the decision, maybe things would be a little better for everyone overall.

Personal Responsibility

Last week I was able to attend Agile Africa 2015. The most inspiring talk, amongst the many great talks and conversations, was Kent Beck’s closing keynote. He talked about the engineering culture at Facebook and its key overriding value of taking personal responsibility.

At Facebook as Kent Beck described it
The task you pick up is your responsibility to get right. All parts of it. Even when it is the first task you do when joining. There is no one else other than the developer who is responsible for the decisions required to get it done. If you deploy a bug, someone else may see it and will fix it. And they will give you feedback. Everyone is responsible.

When joining Facebook, developers join Facebook Engineering. Developers are not hired into a specific team at Facebook. In the first weeks the new hire chooses which team they will join. They are personally responsible for the choice to ensure that they join the right team and make the most impact in the organisation.

This is a culture that trusts you to know what you should be doing. If you get it wrong, you will receive feedback.

A culture
A culture of high focus on impact guides developers to prioritise their time effectively.

A culture of clear, direct and immediate feedback makes sure that there is a feedback loop on responsibility.

A culture of P50 goals drives improvement and striving for new thinking. P50 goals are goals that you aim to hit with 50% probability. Spread them around so that all the 50% probability isn’t in one area – otherwise no goals may be achieved at all! [1]

This is a culture of high responsibility, but associated with that must be very high trust. And it has scaled to thousands of developers.

Not Agile
Facebook does not claim to be Agile. There are pockets where there are lots of tests. There are even larger pockets where there are none.

What? The inventor of XP works at a non-Agile organisation? What does that mean? Is Agile dead?

Very agile
However Kent Beck has seen FB turn on a dime. FB is highly successful. Engineers enjoy working there – at least Kent seems to enjoy it immensely. It sounds like a very agile organisation.

Personal Responsibility
The key is leveraging personal responsibility. It is what Kent says he was getting at when he wrote the XP book.

High personal responsibility leads to developers needing coping mechanisms so that they don’t mess up. If you mess up, you own the mess – 100%. If you mess up too much, you won’t last long. If someone sees your mess, they will fix it – because they too are responsible – and you will get clear, direct and immediate feedback to act on for the future.

Personal Responsibility drives behaviours. It may lead you to TDD. It may lead you to lots of acceptance testing. It may lead you to implementing lots of metrics or monitoring a lot and responding as soon as errors are detected. All of these help a developer keep a handle on their work and hence help them to be responsible. There are no ‘the system is the fault’ types of answers to failure.

Personal responsibility leads to developers having to take control of the code base they are working on. It leads to developers being more confident of their work. If they are not, they fail. They will receive clear, direct and immediate feedback. And they must take responsibility for the problem.

XP has been pointing at personal responsibility. It also seems that personal responsibility can point straight back at XP as one of the possible outcomes of dialling personal responsibility to the extreme.

Personally responsible
Personal responsibility touches at the heart of much of great software development. It feels like it should be a core value to optimise around. I certainly am going to be thinking harder on what it means in everything I do.

If you weren’t there – watch out for the videos when they are out. It was a really inspiring (and funny) talk.

If you have seen the talk, let me know what you’re thinking as it would be interesting to hear what others will do around this.

 

[1] More on P50 goals in Growing Agile’s latest newsletter at http://eepurl.com/bxmJFb.

Mastery

I’ve been meaning to come back to this topic for a while – closing the loop on Daniel Pink’s Autonomy, Mastery and Purpose theme from his book Drive.  Now that I’m doing it I’ve realised that I need to think more deeply on what Mastery means when you extract that from Purpose.  Mastery can be a Purpose, but for many their Purpose isn’t Mastery.

Now that I’m nicely tongue tied let me dig into what Mastery is – closely tied, but not the same as – Autonomy and Purpose.  All three add up to a powerful motivational combination.

Mastery is a mind-set

Daniel Pink talks about two mind-sets.  One mind-set views intelligence as innate and hence finite per individual and the other mind-set views it as something that grows over time – as you learn and acquire knowledge.  Pink discusses research showing that people who view the world as a place in which they can grow their knowledge and experience will come up with more creative solutions to problems.  Their failure to solve a problem will not be because they are incapable of solving the problem rather that they haven’t learnt enough to engage with the problem and they will keep trying to solve the problem for longer.  They view their inability to solve the problem an external one – more learning – not an internal one of – I’m not capable of this.  This might be an oversimplification, but that’s the idea.

Mastery embraces this growth mind-set.  With a focus on getting better, you will get better.

Pain and the impossible

By definition when striving for mastery you will leave the safe place you’re in and expose yourself to failure.  That failure will hopefully bring learning but it can also bring pain and frustration.  Striving for mastery can be hard.

The other problem with mastery is that it is a potentially unattainable goal.  However if you strive for it, you may hopefully keep on inching closer, bit by bit, edging asymptotically towards mastery.

Engagement is a Good Thing

Engagement at work is valuable for enjoyment of your work.  It is also valuable for your organisation.  The more engaged you are, the more productive you will hopefully be.

Mastery at one’s work encourages individuals to become highly engaged in what they are trying to do and to strive to get better and better.  Mastery gives a focus on the long term engagement of individuals in their work.  This is a good thing.

What about the short term?

There is an often use term of “getting into the zone” or maybe “getting into a groove”.  Those are the times when you are working effectively and efficiently and enjoying yourself while doing it.  Pink discusses research showing that people who are in flow – or in the zone – are highly productive and thus we should attempt to optimise for flow moments.  Flow is the short term bursts of doing great work.

Flow is thought to be most achievable when someone has clear goals defined, quick feedback on those goals, and a slightly challenging problem in front of them.  (Doesn’t that shout TDD to you?)

Individual Mastery

Mastery for the individual is a personal choice.  Switch on and engage. Read, attend community gatherings, talk to people, learn.  It isn’t hard to engage.  This is your choice and isn’t limited by your organisation as it can all be done outside of work.

However your organisation should support you.  They should want you to be awesome at your job.   That should make it easier to get started.  A mastery focus will bleed into all of your work and you can only get better at your job and grow as a person.

The limitation here will always be how much autonomy does your organisation / team allow you to have to be a master at work.  And how much you care to try.  It is up to you.

Team Mastery

Scrum encourages teams to be masters.  That is the whole point of self-organising teams.  Activities like pairing and TDD help flow through providing lots of small short term goals with high feedback. Retrospectives allow for space to explore together how the team is performing and jointly decide what next to try in order to get better.  When a team gets this right they can be highly effective.

But too often I see this as not happening in teams.  People feel pressurised to deliver – right or wrong – and too often no one is brave enough to do the cleanest, most correct thing that needs to be done because it might cost too much, or it might be politically unsafe, or they are completely unempowered to solve the elephant in the room or any other myriad of reasons.

In order for a team to take the most advantage of the space that Scrum provides them to be a master, there must already be a majority of individuals in the team who already want to be masters and drive each other to get better and better.  Without that, the team has the finite mind-set that assumes the problem is too large for them and they will not come up with the really creative solutions to move forward.

And me?

Personally I’ve recently had my best flow moments doing TDD.  Both pairing and on my own.  I continuously know what is next to do and continuously get feedback on what I’m doing.

I’m on a drive for mastery.  I think in the last year I’ve made some great progress.  But there is a still lot to learn.  I’m looking forward to it.

That said, perhaps I should attempt to separate my view of mastery as my purpose and maybe I could derive even more drive as a result.  That’s something to experiment with.

Passion Required

The baseline assumption in Scrum is that everyone involved is willing and keen to do a good job with the work in front of them to the best of their ability.  In the organisations that I’ve worked this is mostly true.  But I don’t think it is enough for an awesome team.  Passion is still required.

Passion is required to be awesome
I’ve worked with several different teams and people doing agile types of things in the last couple of years.  The benefit of moving jobs is increased exposure to the diverse ideas and interpretations of Scrum and agility in general.  With that exposure I’ve seen that many teams are completely happy with what they are doing.  They appear to believe they are good enough for the situation they are in.  Others think they are already doing awesome things.  Or they think that it is impossible to do more awesome things based on their special circumstances.

The significantly better teams are those that contain people who are truly passionate about making a difference in the way they work.  They engage and don’t just shrug things off as the way they are.

Too many teams lack passion.  Too many teams fall short of the awesome they could be.

Sometimes awesome isn’t required
Some teams appear to believe they are good enough for the situation they are in.  Sometimes this could be true.  When mediocre is good enough – for the team members, the PO, the customers paying for the software – then it becomes hard to drive improvement as there is no pressure to change or get better.  They are good enough.

Sometimes passion isn’t desired
When awesome isn’t required – passion can be a disruptive influence.  The passionate ones can be the disrupters, breaking the status quo.  They push for things they believe will make the processes and delivery of software and business value better.  But these aren’t necessarily exposed by the pressures of the environment.  They aren’t being acknowledged by the team jointly.  They are just exposed by the desire to get better at what you do.  And it is possible that in the scenario they are now in – they might not work the same.  In these scenarios group buy in is hard to attain – particularly from those who like the status quo.  You need to pick the battles for the things that that majority will buy in to – where the team will actually acknowledge the pain.  And slowly grow the knowledge that there are other ways to do things.

Perhaps the people who are passionate about being awesome will naturally either change their organisation or change their organisation – hopefully for one that does need passionate people whose drive is to be awesome at what they do.

But what if awesome is desired?
What if there isn’t much passion? How do you enable a team to be passionate?

I expect that an organisation can provide a space for motivation – through things like autonomy, mastery and purpose.  These seem to be things that will drive and unlock passion.  But it will always be an individual action.  The individual has to take the step to want to learn more, want to get better – and can see that there are other ways of doing things that are worth trying.  I do imagine being surrounded by a team of passionate people could help ignite passion in others.  But it still will always be an individual choice to engage.

Passionate about agile?
At the agile coaching retreat (http://sugsa.org.za/agile-coach-retreat/) in November I proposed an open space on developer skills in agile software development.  The end result of that conversation was – go and find the passionate people and harness them to grow a critical mass – at least in the environment you are in.  As without the passion and desire you will often be wasting your time.  Passion is key to trying hard to learn and get better at something.

And me?
What I’d really love to do is start a team where a key hiring / entry requirement for everyone was the passion to do agile software development right.  I think that would be a recipe for true awesomeness.

Purpose

When you get up in the morning and go to work – what is the point?  Is it just to pay the bills?  Or to get the children to school on time?  Do you have a purpose?

Are there driving reasons why you are doing the job that you are currently doing?  Are you motivated around a goal? Either for yourself, with your team or your organisation?

The core motivators discussed in Daniel Pink’s book Drive are autonomy, mastery and purpose.  I’ve previously blogged on autonomy.  This time around I wanted to throw some thoughts about around Purpose – in a Scrum team, in an organisation and how do these align with individual purpose.

Goals and Visions

Does Scrum allow the team to have a purpose?  The quick answer is – yes – with sprint goals, release goals and a product vision.  These catch phrases help guide the team and the product to attain a fixed focused goal.  Within that goal how we get there is not clearly defined – but we can question what we’re doing in this sprint as to whether it helps us to achieve the vision or goals.

A team may loose a sense of purpose if the goal or vision isn’t clearly defined.  Or if the current goal doesn’t align with the bigger goals or vision.  But at that point possibly the team isn’t achieving the intent of Scrum.

In Scrum we’re encouraged to question why.  To understand the business goal of the story.  To understand the purpose.  Purpose gives focus.  Focus is good.

Organisational Purpose

In Drive, Pink uses the term of “not only for profit” organisation.  I like it.  In too many organisations the sole purpose seems to be to make more money for the shareholders or owners.  Is there something more than this?  How can an organisation provide an employee with a purpose that really motivates?

The example in the book of TOMS donating a pair of shoes to someone in the 3rd world for each pair of shoes purchased is interesting.  Where’s the profit going? Are they a charity?  Neither – they motivate us to buy from them because of the intrinsic value of what they will do when you do.  The same goes for people buying “green” or “organic” – they are motivated by what that means to them.  Working for such an organisation may give you higher personal satisfaction and purpose.

Similarly working for an organisation whose goal is to change the world – Microsoft, Google, Amazon, Twitter, Facebook – their services are influencing millions of lives.  Or working for a start-up that disrupts an industry and grows into a similar place or niche.  Working for such organisations may give you great purpose and satisfaction.

Open source and crowd sourced initiatives like Wikipedia show that doing something just for profit isn’t the only motivator to individuals.

Most organisations need to make profit in order to exist and pay their employees.  Combining that with a purpose that the employees can become motivated around could be far better for the longevity of the organisation.

Individual Purpose

So back to why do you get up in the morning?  I suspect most people would answer because it is their job.  Some people would say because I love my job.  Others might talk about learning things, learning from people, growing knowledge, growing mastery, growing something bigger than themselves, changing the world in some way, enjoying working with the people, the vibe – team or company, loving what the company does – products or more than that – giving to charity, involving the community or helping to grow a community, the lifestyle perks – flex time, leave, autonomy.  I’m not sure many will actually be motivated with the purpose of making the shareholders richer, but there might be some.

And me?

It would be awesome if we all thought the product that we worked on was the best application that everyone in the world should be using.  I’ve been there and it was inspiring and motivating (and possibly a little delusional :D).  But other things now inspire me instead.  I’m inspired by obtaining mastery.  I want to learn how to get teams to become agile – in code as well as process.  Thus far I think I have already had some small successes in mastering process.  I hope as a team member again I can achieve agility in code.  I do know that I need autonomy in order to achieve that.  I want to strive for mastery while I learn how to deliver better software.   My current purpose is simply to make elegant working software that achieves something like the Beck curve.  This is the unicorn that I’m currently chasing.

A closing thought

It would be awesome if your purpose aligns perfectly with the product and organisation’s long term plan.  But if it only aligns for a while – you’ll do better things and everyone will benefit.

Find a purpose for why you are where you are and you’ll do great things – at least until things change.  Then find your purpose again.  And you’ll find a large part of your drive.

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.