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.


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.


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.


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

Interesting Times – A Positive Story

In June 2010 I took over a project with a reasonable amount of trepidation.  There were a couple of reasons for my reservations.  Not the least of which was my search for what I wanted to be doing and taking this on would be a commitment that I wasn’t sure I wanted to make.  I made the commitment and over a year later I’m incredibly happy with what we have achieved.

When I took over the project several other project managers with far more experience had not succeeded in making a real success of the project.  Technically it wasn’t beautiful. After having taken on a large client performance issues had arisen which had taken several months to fully bed down.  I was taking it over at the tail end of this.  And there were other issues that had led to the client being at a low point in the trust of the team.  Though they had great faith in certain individuals but that was part of the problem.

The first thing we started doing was introducing Scrum.  This exposed a couple of problems:

  1. The team “knew how to do it all” already.  (They didn’t)
  2. Some individuals couldn’t break anything down beyond 3 days – and objected to questions around this.
  3. It was almost impossible to lock down scope for a week – let alone 2 weeks so sprints were difficult.  There was a lot of smoke but few real fires to put out.
  4. It wasn’t clear what exactly needed doing to deliver a quality release.
  5. We couldn’t deliver a quality release due to lingering quality issues from an earlier period.
  6. We had no PO.
  7. The client had experienced working with me on another Scrum project and initially assumed that it was me that was important – not the process.  They were impatient for success.

Our first big release after the performance issues were fixed was a disaster.  1 month of work to “finish” the last parts of a module generated 2 months of work to get it really done.  This was largely due to those who in theory knew what needed to be done didn’t actually know what needed to be done – both in the team and at the client.

Jump forward 6 months. Some things changed.  Some people changed.  I took on the role of SM and PO in order to force the backlog generation and to get a handle on the chaos.  We made a quality release.  The team was much more enthusiastic and fired up.  And for the rest of the year we’ve gone from strength to strength.

How was this possible?

a. My management supported me.  I beat the PO drum over and over and over again.  We needed one.  I would do it in order to achieve a manageable backlog, but we needed one from the client.  In February – after this first quality release – we had our PO and this has taken us from strength to strength and proven the value of having a known backlog to groom and work on.

b. We focused on what we knew we had to do and made sure the client knew what we had to do.  We embraced change, but made sure that the client understood change wasn’t free, dates or other scope could be affected.  We were completely transparent with this.

c. The new team became a real team and the team started to deliver greater than the sum of the individuals.

d. We removed the ambiguity.  Initially this was by going a bit more big design up front in order to force the client to stop randomly changing direction and blaming the lack of delivery on the team.  This is something we’re now looking at changing in order to remove some of the waste around this.

e. The team had quality issues that they worked hard at resolving – through bug analysis and retrospecting every time there was a problem.

Moving forward we started unit testing properly.  We haven’t conquered everything in the system to be unit testable, but we’ve made a good start and keep on opening up new things to try or fix.  But the team is positive.  They have tackled quality in deployments and come up with solutions to ensure we don’t miss things.  They have been proactive and keen to get better.  The team takes pride in solving the issues that are raised up in retrospectives.

We have been able to move to 2 week sprints.  We have been able to manage support in an effective way and reduce it to a minimum as much as possible.  We have a full time PO and we can plan reliable deliverables with known scope given enough detail and time.  We have become solidly predictable with high quality.

Fast forward to last week. I’ve just come out of a client visit. They are keen to keep pushing the envelope – to become better, faster, more agile, more productive.  They are keen to try more frequent deployments and to force the team to think about how to achieve that.  They want the flexibility and the ability to get software live faster safely if needed.  They are keen for the problems with deploying more often to rise up so that we can confront them.  They trust that we want to do better.  And they want to not limit us from getting better.  And they know that if we get better we’ll get faster, once we’ve learnt how do to some of these things – like being able to deploy every month.  Hence maybe needing a full test suite and investing in that.  That trade-off will be interesting to see how it comes to a head.

We’re also looking at making ourselves more effective by embracing change more – not worrying as much about specs and sign off which were all needed to rebuild the trust – but to start being more agile in requirements generation together as a team with the PO.  Of course with embracing more ambiguity comes less rigid date based plans but deploying often will help us not need that at all.

This is all quite a step from where we started over a year ago.  We now have a client encouraging and supporting the team to look at how better to be agile – to solve some of their real world problems that they are seeing.  They trust that we can achieve more than we’ve already achieved.

There are interesting times ahead for this team.  It is a pity I won’t be around to see this next year.  But I’ll be watching from the side-lines cheering them on to be more agile and to push the envelope of their capabilities.