The System Rules

I have worked in numerous companies and roles over the past 15+ years.  Culture and behaviour are a symptom of the system. 

I will level with you; I do not like job roles or titles they are symptom of the system.  More specifically I now consider myself a problem solver – even though this is a role, whether that be Front End, Back End, DevOps, QA, BA, PM, coach, leader, mentor, etc.  I will do any role that needs fulfilling to ship valuable working software to the customer.  I have got areas of specialism, areas I am ok at and areas where I need to read and learn.  However, on a personal note I love learning new technology and techniques.

Back to the system, if you create a system with job roles – more specifically the trend that I see now is the split between Front End vs. Back End & the new Full Stack role and the more traditional QA engineer or DevOps engineer.  That is the system, people’s behaviours will start to align with the roles.  For example – ask a DevOps engineer to do some React or Angular in this system and the likely hood is that you will get push back.  That is not my role, I’m employed as a DevOps engineer and all I do is Terraform and AWS! 

Delivering working software does not occur in a silo of work, do Front End then Back End – at any point you could be a stakeholder, PM, PO, BA, Front End, Back End, QA, DevOps, Release Engineer, etc. 

My experience of highly successful teams – read delivering valuable software to customers, with short lead times. Is that most team members will be needed to fulfill any role while delivering software. 

Having push back just creates queues and expands lead times.  Oh, the Front End dev’s just finished the UI, but the Back End component isn’t ready.  Software sits there waiting in a queue before the Back End work is done.  Queues kill flow.

A Slicing Journey

I first came across the idea of story slicing at Agile North when Seb Rose ran a workshop about it.  Our primary goal was to slice a story for a twitter clone from memory this was the ability to post a tweet of 120 chars.  I recall during the exercise we never quite sliced thinly enough, with Seb always challenging us to slice thinner.  Eventually the initial slice was just a web page with a text box to enter some text no restrictions.  I thought at the time this slice was way too thin, with little or no value – I really struggled to understand slicing so aggressively. 
I’ve tried over the last 4 or 5 years to understand slicing and apply it more in my every day to work.  Some environments allow this, and some don’t.
The example that I’ve come up across recently is getting the product information for a product on an ecommerce site from a different place.  This is my attempt at slicing it thinly:
  1. Pick a single product
  2. Feature switch getting the title for the view from existing location to be hard coded in the view
  3. Push back the hard coding back through the architecture – i.e. this might be calling a api to retrieve the data
  4. Manually enter the title in to the product store & retrieve from there

Each slice should be deployed and monitored.  There are other tasks contained in each of these thin slices – like monitoring and setting up deployment pipelines potentially.  However, these steps shouldn’t take that long.
By slicing this thinly you can learn about your architecture and get the walking skelton in place relatively quickly.  Therefore, understanding if you have any issues with the path you are taking. 
You could then expand this out to another product or build out some other capability.

The take home is try to half what you do now, then once you get good at that, half it again.  You should aim to get something delivered every day which extends your understanding of the problem domain.

Playing By the Rules

I’ve been trying to reflect on some of the recent successes we’ve had at work.  These successes where highlighted in a recent retrospective we ran last week.  Increased teamwork/collaboration, and improved built in quality to a certain degree. 

How over the last couple of months has the team seen such a rapid improvement?

The answer is pretty simple really – we have been playing by the “rules” outlined in eXtreme Programming & SCRUM (to a certain degree):

  • Pairing
  • Test Driven Development
  • Planning Poker
  • Retrospection
  • Daily Stand Up’s
  • Continuous Integration (to some degree)
  • Reflecting on Agile In A Flash cards 
  • Watching Clean Coders

As one of the Agile In A Flash cards said the other day – we have been playing by the rules, which is something we must keep doing until as a team we are more mature.  Once more mature we can start to review the “rules” and adapt them to our situation if they do not fit.  Hopefully this will allow us to further satisfy the needs of our customers.  In my opinion the most important part of software development. 

As a team we probably need to refine our pairing, and having properly defined roles during pairing.  How to ensure that both driver and navigator are working together.  A common problem is the navigator is distracted.  We could simply do the write a failing test then swap, scenario which I have seen work well at XPMan.  Another way is to use the Pomodoro Technique.  As I’m writing this it’s probably the case that as a team we should decide on a way to pair and follow this for a couple of weeks an retrospect on it!

Test Driven Development is another area that we need to get better at, but I think we know what we need to do – we just need to start doing it!

As you can see there is still much to do, a recent mind map highlighted just how far our team has to go.  Some of this is in relation to rules we’ve not implemented and some of this is just to enusre we keep applying the “rules”

What’s in a Role Anyway?

We recently had a discussion about what the state of the development community at the moment. I’ve also had a blog post with a comment, where I stated is there a need for a BA!? This centred mainly around the make up of the team and who or what key skills you need in a team. As I’ve become accustomed to being just a developer over the past couple of years which has included either of the following: writing code, or supporting production code. Although this has been my primary role over the last couple of years I’ve come to realise – probably since discussing and studying Agile & XP especially that this is simply cannot be the case anymore.

The main reason for this is due to the fact that XP & SCRUM just has a concept of a team – this includes everyone who is needed to deliver a product or rather something of value to the customer. The idea that when the time comes to deliver everyone needs to be able to help to deliver the product – this is mainly because there is not one person responsible for the delivery – the team is responsible. So this means that if there are tests to complete before the iteration completion date and no development work – then everyone needs to “muck in” to complete the tests.

This leads to teams of individuals with multiple skillsets – as an individual you might for one day have your developer “hat” on – the next day your “hat” is firmly in the “test” ring. Traditional role definitions are probably not well used here and are probably redundant. You are essentially just a team member who has more experience in development than testing, BUT you must be able to help with testing if the needs arise. If there is a bottle neck you must be able to relieve the pressure on the bottle neck – otherwise the “team” will not deliver.

This ability to learn different skills leads me to another important asset of any team member – you must be willing to learn. I think Agile especially encourages this, since everything is an experiment? I was listening to a Podcast with Lisa Crispin and a couple of her final thoughts centred on the need to learn and willingness to learn. It must have struck a chord – because I was skiing at the time! I believe these are key skills for anybody working within in an Agile team.

For me this leads to a couple of core things to look for in team members:

  • Willingness to learn
  • Ability to adapt to the needs of the team