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

Exceptional Teams need Exceptional Practices

The November SUGSA event featured Austin Fagan talking about what makes an exceptional team.  A collection of exceptional people doesn’t necessarily make an exceptional team – and Austin posited that the usage of exceptional practices is what can turn a collection of individuals into an exceptional team.

Having experienced a team that is definitely more than the sum of the individuals – I can emote to the sentiment.  And equivalently having worked with some exceptional individuals in the distant past – there wasn’t a great deal of real team work.  Collaboration and other solid development practices make a huge difference.

The evening included a sequence of “does your team do X” slides – sit down if no, stand up if yes.  I was glad that I could at least stay standing for many of the soft skills – empowered team, collaborating, working as a unit, etc.  But sadly as always the practices of software development like pairing or TDD are lacking in adoption in my personal experience.

The evening proceeded with a session where we broke into groups and then discussed a topic.  We landed with pairing and were looking at issues around what is stopping you from starting to pair today as well as how do you keep pairing when you have started.

Pairing
Pairing is an interesting thing to me in terms of adoption but it was refreshing having the conversation with some people who are dedicated agile people all coming to the same conclusion.  Our summary was something along the lines of  “It could be awesome, we don’t really know, so we should try it to find out”.

The standard pros came up – continuous knowledge sharing, no dependencies on a single person, continuous code review (or at least code discussion/justification which should make better code and sanity checking of code), potentially more productivity (can’t work avoid on the internet in a pair as easily).

The standard cons also came up – it wastes time, you need to synchronise office hours for pairs, some developers can only work alone, how do you know it works, we’re changing the way you work while having no evidence that it really does work.

Evidence please…
Sadly in the world of development practices there isn’t a lot of evidence in the public domain for software practices such as pairing – just a lot of anecdote that it is the Agile Way.  I believe there is some evidence on code reviews – which lends some credit to pairing being beneficial – but not much that anyone sites emphatically to prove that pairing delivers better software, faster, more bug free, or some other quantitative measure in comparison to not pairing, or pairing just some of the time.  Though I suspect in the world of delivering business software not too many are going to provide the data for the experiments.  I know there is some evidence for certain design practices – such as DDD – to spread the logic and hence the complexity across all the objects hence reducing the maximum complexity of any one object.

Pairing adoption is a tough one.  I never did much pairing in my time as a developer or architect.  I now wonder if I should go back to learn how so that I can be more emphatic about it one way or another.  In fact, I’ve never experience anyone really pairing – by the definition of doing it all day, 1 machine between 2 people, writing code (and tests).  Obviously developers pair in order to solve hard problems sometimes, or when there is a slog of work to get through which is more effective with one person typing and one person following the documentation for implementation (read really big CRUD screen), or when their machine is acting up and there is nothing else to do. But I haven’t worked with any developer who actively wanted to pair on a regular continuous basis.  I’ve met many who vehemently dislike the idea.  And some who’ve tried it and discarded it.

Pairing Adoption
We dug into this a bit and all agreed the biggest issue around pairing is “What is pairing” – what are the pairing patterns – and how do you do it right.  I’ve recently read this InfoQ article which talks to pairing as a pattern.  It is an interesting read if you’re trying to think through the options – but it’s by no means the answer.

Doing it wrong is going to be detrimental to your ability to adopt pairing as it’ll give those who “know” it isn’t going to work more ammunition to inspect and adapt away from pairing.  The key things seem to be training and experience – working with an experienced pair programmer to understand how it works.  That is a tough one as I suspect it’ll take a reasonable amount of time immersed in the performance of pairing to learn what the steps are automatically. Pairing seems to be one of those things, like TDD, that possibly is a performance art that one can only learn properly by seeing it working properly in order to reach those “Ahah!” moments.

TDD
TDD on the other hand – or at least automated testing – is a lot easier to sell in terms of why to do something like it.  I’ve spent a bunch of time pondering pairing and TDD and other practices.  Pairing as described above I find harder to sell. TDD on the other hand – or BDD, test first – even test last – I’m more than confident to sing the praises and provide the high level problems that we’re solving.  I want to be able to release without doing a full manual regression test over the next month – how do I do this?  I’d like to be able to do a quality release every 2 weeks – how do I do this?

I worked on system that we released every 2 weeks to production that had no testers and a full suite of automated tests – it was incredibly successful at deploying often.  At this organisation I mostly did test last but it was always very valuable doing the testing.  I would do it test first if I were to do it again as I think it might be faster than test last and the capability to test your design as you write it seems appealing.  I did a little bit of test first at the start of my time at my current organisation as it allowed me to determine how I wanted to call the code and that defined how I built the outer bits.  That was very valuable.  It didn’t last though due to my lack of dedication and shifting roles – though the original tests that I wrote were still being used to refactor that code 2 years later and saving the developer’s bacon.

Automated testing adoption
The key failure that I’ve been finding in adopting automated testing – TDD or otherwise – has been in the lots of little gotchas when the system isn’t as testable as you’d like.  In the organisation where I was successful with this we were using Perl and could simply modify functions on the fly in tests.  It was awesome, but really dodgy from a purist computer scientist point of view.  In .NET this is harder.   And if you don’t plan for testing in your architecture up front, retrofitting it is a pain.

Fundamentally my experience with automated testing is that developers can be convinced of the value and can get excited about getting it done and including it into every build.  But each time you hit another large wall in the way of getting a new type of problem solved in a sustainable and non-fragile way the closer the enthusiasm comes to falling away.  The frustration seeps in and the dedication seeps out.  That is sad.  And it is what makes TDD and any type of automated testing hard to sustain.

Are we doomed to fail at these practices?
I don’t think we’re doomed to fail at these practices.  But I do think that we need to think long and hard as to why we’re doing some of them so that we can continue to keep the enthusiasm and dedication up in doing them.

Fundamentally the software developers I’ve worked with over the years – myself included – have a lot to learn about how to make these practices really work for them and the organisations they work for.  I’m hoping someday I’ll have learnt some more and will then be able to help others to understand and justify to themselves why these are awesome practices.  I’m looking forward to that day – as then I should be working with exceptional practices in exceptional teams hopefully also with really exceptional people.  And it will be beautiful.