Critical Non Essentials in Software Teams

In his book about how he transformed England into favourites for and eventual winners of the Rugby World Cup in 2003, Sir Clive Woodwood cited the significance of Critical Non Essentials in the journey.

He recognised that in order to take on the traditional super powers of the southern hemisphere, he needed to create a winning culture in the squad and at the heart of this was an approach which left no stone unturned. The recent success of Team Sky in road cycling also has a similar philosophy at its heart, with Dave Brailsford pursuing "marginal gains" in order to set his team above the peloton.

Fundamentally, both of these successful leaders at the highest level understand that within elite sport, there is a fine line between winning and losing. With many teams and squads having access to the same resources and techniques, it can be the smallest details which set you apart and ultimately turn your team into the highest of high performing teams.

Reading Woodwood's book, the idea of Critical Non Essentials immediately struck a chord with me and I started to search out areas in my professional working environment which could benefit. Roll forward 10 years and they are back on my radar as I look to create a culture of excellence within our software development team. As a city, Edinburgh is full of cool and exciting technology companies and the best developers will gravitate towards those with the best reputation and so it's vitally important that our engineering culture is spot on.

Of course creating a high performing development team can't just be based upon these Non Essentials. To be the best, we need to focus on the absolute core elements of top technical teams. Things such as continuous integration, peer reviews, automated tests and agile practices can often be mistaken as non-essential but for us, we couldn't be effective without them. Indeed, this exact point was made on a recent Money Dashboard podcast by Adrian Hristov (@adrianhristov). However, as the market matures and many of these "essential" practices become commonplace, it is your CNE's which will set you apart.

So what sort of things can be classified as Critical Non Essentials in a software team? Well, in a nutshell it's about making the work environment as good as it can be for each team member and aspiring to be best in class. Recent examples which have been implemented which may fall into the CNE bracket include:

- proper monitor risers rather than coding reference books and optical mice for entire team
- new seating plan to ensure all developers sit together and close to the task board
- magnetic white boards to run an effective task board and magnetic board rubber
- team chosen avatars for the task board
- closing off all old/invalid issues in your bug tracking system
- offsite technical team meetings
- external facing technical blog to give the team an opportunity to showcase their knowledge

Does this make you think world class developer setup?

When growing a team, the importance of these small details is compounded. as new joiners will come in without any of the baggage (good or bad) of existing team members. Although they'll have gone through a hiring process, had the chance to ask questions and listen to your pitch about your culture, these first days are the time to give credibility to your words. I made sure a recent new start in the team received all the best equipment we had available even though it meant it left our CEO a monitor stand less!

For a team or organisation in its formative stages, I can understand that a culture built on "shabby chic" can help bring a team together: the "Crazy Gang" mentality if you like. However, as your team matures and expands, your levels of performance need to scale too and to enable this it's important to do things properly and not cut corners. As a leader, harnessing a culture of Critical Non Essentials is one way that can help you ensure that your team can maximise its potential and edge you ahead of the competition. 

Domestic User Stories

After an afternoon at work, talking over the difficulties of working with user stories and acceptance criteria, I found myself discussing the same principles at home.

Julia: We're going away tomorrow, I'm not feeling well and there's lots still to be done
Richard: Well, I can do some stuff. The suitcase?
Julia: Not really, you'll only do it wrong. I'm the best at packing the suitcase
Richard: I can do it, Actually, do we even need to pack everything in the one suitcase?
Julia: Eh?
Richard: What's the user story here? We need to pack a single suitcase of clothes? No, We need to pack our clothes in suitcases. No actually, We need to transport clothes to our destination so that we have clothes to wear when we get there.
Julia: What are you talking about? When you pack the suitcase, you do it wrong.
Richard: As long as I get the clothes to our destination, the story is complete. I've done what is required. Surely it doesn't matter how I do it?
Julia. You use more space if you don't pack it neatly.
Richard: Does that matter? As long as I meet the requirements of the stated user story. I can just stuff it all in.
Julia: You're annoying me now. Just pack the suitcase and make sure that when the clothes are unpacked, they don't need to be ironed.
Richard; Aha! Some acceptance criteria!! So, as long as I transport the clothes to our destination and they don't need to be ironed, you don't mind how I do it?
Julia: Does it mean I don't have to continue this conversation?
Richard: Yup.
Julia: Then yes.
Richard: Great, I'm off to pack the suitcase.

At the time of writing, Julia and I are happily married.

Choosing to develop Android first

I was going to write this post shortly after our new native Android app hit the store at the end of May but decided to hold fire and let the dust settle so I could hopefully add some insight as to whether it was a good idea or not. While I covered the reasons for choosing Android first briefly in this article, I felt it warranted a bigger discussion.

The backdrop to this post was that at Money Dashboard we wanted to deliver a brand new native app on both the Android and iOS platform to replace a native wrapper around our responsive web application. Although the exact feature set was not clear from the start, there were some core functionality that we knew had to be included and so we set about developing this. Initially, we started to develop on both platforms at the same time splitting our resources evenly with Android only ever slightly ahead.

As the product began to take shape and decisions around what we wanted to include, so began the debate as to which platform to deliver on first. Initially, there was an understandable desire to release both apps at the same time but after careful consideration we desired against this. We wanted to gauge feedback from users and refine a single platform before taking those lessons and applying them to the second platform. There were real concerns that if we just developed the same app on 2 platforms, not only would it be longer before we would be able to get feedback, bugs would most likely appear on both and could result in poor reviews and a mad dash to get fixes out on both.

iOS or Android?

With agreement reached to focus on a single platform, the decision was simply which one first? There has been quite a bit of airtime given to this topic and much of it seems to favour delivering an iOS app first as highlighted in the following articles.


iOS first and Android much much later

The fallacy of Android first

Why Android first is a myth


For us however, we took the opposite approach and decided to push forward with Android based upon the following key reasons:

• We had more resources available to us for developing an Android app. We didn't require any new hardware (Android Studio on Windows) and almost all of the project team had Android devices. Furnishing the entire team with a Mac Mini each would have been a significant up front cost as would obtaining a set of test devices. 
• We run our continuous integration in the cloud and configuring a build agent for Android development was very straight forward. Our cloud environment did not have support for OSX and a local build agent for iOS would be required. 
• The development team were comfortable working in Java with many having used it at university or in previous employment. Objective C & Swift were brand new and with a steep learning curve for the team. 
• The Google Play submission process is significantly faster than that of Apple with the ability to submit a new version of an app into the store within hours as against a process which can sometimes take 7 days or more.
• Google Play has a nicely integrated beta facility which is easy to distribute your app to a defined group for early adopters (those who expressed an interest in our beta release were mainly Android users). 

Obviously there are also downsides to developing on Android, most notably the testing difficulties associated with the considerable fragmentation of the Android market. This article has a nice graphic illustrating the extent of the fragmentation and although we were under no illusions that we wouldn't be able to test every device/OS combination, we drew some comfort from our analytics which suggested our userbase was concentrated around a much smaller set of devices than we might have feared. As it stands, we are still a bit blind to how our Android app performs on many devices and although there are solutions out there such as Xamarin's Test Cloud which allow you to test on real devices, the cost can be a prohibitive factor. 

Conclusions

So, with the Android in the Play store and iOS nearly complete, the question is was it the right call? Well, after a soft launch of our Android app, inevitably we began to get some feedback from users and also became aware of some crashes. As a result, we were able to release a new version within 5 days of launch and another some 14 days after that - the key being that we were able to turn around those fixes in a matter of hours. This was a big win for Android as far as I was concerned and validation of our approach. We also managed to take some learnings from the Android app and roll them into our iOS app, notably an enhanced transactions screen which, although not specific to developing a particular platform first, was a clear benefit from not releasing both together.

Running software projects as marathons

As a runner of distance events, I get quite a lot of time to ponder and after reading this interesting blog post from Mark Ridley, on what technology can learn from sports, it got me thinking about running and software.

It's not uncommon to hear people refer to projects as marathons and this is typically in relation to the gruelling nature of the event itself and while I understand this, I think there are actually more parallels to be drawn from the training required to complete the marathon distance.

Now, let's start with some important differences between a software development project and a marathon. I often hear people say they could never run a marathon. I rarely hear people say that they couldn't complete a project. Also, software development is rarely an individual pursuit, whereas a running and training for a marathon is often a solitary affair. But that's enough about the differences, bear with me and let me explain where the similarities lie.

My current training plan for the Chicago Marathon is about 16 weeks (4 months) which is certainly inline with many software projects I've been involved with. And if you think of your product as your race fitness, then you define your race up front and then construct a plan to build to that level and then "release" your product on race day. Your plan will be dictated to by how much time you can dedicate to it in much the same way that a software project will be constrained by how much resource you can commit. And also, chances are you will be building your software incrementally which fits with training plans which are typically constructed into weekly chunks with each block building your fitness further. Still, with me? Great. So if we can all agree that projects are marathon training plans, then what methodology are they using? Are they agile? Well on the face of it, training plans could be considered very waterfall. A big design up front and an immovable release date. I know I've written out my entire 16 week training plan weeks before starting and so I know exactly what training session i'll be doing on the Tuesday in week 8. You'll be “shipping” on race day, with whatever “product” you have built during the training plan.

However, it's worth mentioning that the goal can be flexible depending on your progress throughout the plan. So, although you wanted your product to be a 4 hour marathon, injury may mean you have to ship a 4:30 marathon. This is a really important point with software projects in that the value of shipping is often underestimated. Projects can run over and late as teams try to polish and cram in extra features/bug fixes but in reality, more value would typically be generated by having a slightly less feature rich product out in the market. In saying that, psychologically, shipping a product which is less than what was hoped for is tough to accept. When I ran my first marathon, I had set out with an A, B and C goals (3.30, 3.45 and 4.00) with my C goal essentially being my MVP. I found it difficult to adjust my expectations from a 3.30 to a 4 hour marathon despite the stark reality that a 3;30 was just not possible given the time and resources available to me. So, in the interests of stretching the analogy further, what other similarities are there to be drawn with software projects. When it comes to testing, some of the better training plans have frequent tests scheduled in. These come in the form of races to gauge your fitness at regular intervals across the plan which will provide feedback as to whether you need to adjust your plan. The weekly training blocks are just like an iteration or sprint. At the end of your sprint, you should have completed the training runs which you have committed to. A definition of done? How does, all training runs completed and you are not "broken" i.e. injury free and able to start the next training block.

While the analogy isn't bomb proof, as someone who spends a significant amount of my time training for marathons or working with software development projects, I can certainly appreciate the similarities between them. One of the big differences I guess is that as an amateur runner, I'm pretty much my own stakeholder, my own product owner and my own developer of my "product" and so I can be in control of what training plan and how much I do in any given week. Still, I choose to try and stick to the commitment and deliver the best product (race time) I can which opens up a whole conversation about what motivates us. But that's for another day.

Done is better than perfect

This image really resonates with me. Not only is it a principle that I strongly believe in, but I think the image illustrates that the delta between the two can be quite marginal.