Friday, 2 September 2016

Fostering awareness, discussion and accountability in real time

If we were aware of the invisible stuff going on around us we'd be more more connected and more responsive to our ecosystem. 

I was about to tackle the implementation of another meaningful metric that would help us determine the effectiveness of our style of working when this thought popped into my mind. Perhaps the thought arrived because of pain points that had been expressed in our retrospectives and my one-on-ones. It often wasn't so much a failure in how we'd agreed to work, but how it actually played out.

I think I've observed something similar watching a game of soccer. One player executes a stale strategy and passes the ball to set up a goal.  He is expecting a team member to be there to complete the play. Instead the ball finds itself in no man's land and ultimately far away from the desired victorious outcome.

If the standup represents the pep and strategy talk before a game (and at half time), what represents the on-the-field cohesion that needs to happen during play? With those thoughts in mind I decided to focus on expressing the "right now" on our health radiator in the office to generate awareness of a game already in play. It seemed like a good experiment.

It's not always that easy to see what's going on in a software development ecosystem. You turn your head and notice two people pairing a piece of work, another is sifting over some code on their own and the other is navigating through one of our systems. And that's not to mention the other 2 working remotely. What are they really doing and how does it involve me?

The activity stream experiment takes a shot at starting to better articulate what the team is doing as the team is doing it. This initial version reflects the mechanics of how we work more than it reflects higher level goals. In a future version I look forward to radiating the higher level goals being realised via each of our activities too.

Above is an example of a line in our activity stream. Hein is reminded because he moved his task to 'For dev today' on our agile board that he has committed to some work.

It feels worth mentioning that an agile team already benefits from principles that foster awareness, communication, realignment, joint purpose and many "team is more than the sum of individuals" ideas. We hope this experiment builds upon on this solid base. What follows are some outcomes of the activity stream addition.


As soon as we put up the activity stream people started talking about the work being done as it was happening. This in itself feels like a victory. Beforehand we often weren't sure what each team member (or pair) was doing so there was no way to initiate a targeted discussion.

How we work discussions

There has been a renewed discussion around 'how we work'. In a way that I think compliments and even feeds the retrospective. Every now and then the activity monitor would phrase something in a way that someone wasn't expecting. The team could then either reinforce why we work in a certain way or choose to make a change.

For example, the stream highlighted that we weren't correctly setting the 'reported by' field when capturing tasks on behalf of our clients. The above example was reading "Greg captured ZRS-107 reported by Greg" when it certainly wasn't reported by Greg.

We also noticed that quite frequently we'd assign a tester without first demoing or discussing the functionality with them, which would sometimes result in a broken production line. In the example above Hein would only find out by looking at our Work in Flight board that he was testing LABS-278.

As mentioned, these inefficiencies are picked up and discussed via other means in a healthy Agile process (like retrospectives and standups) but the phrasing in the activity stream made the team more aware of what is supposed to be happening as they work.


Perhaps seeing your mug shot pop up with a well phrased version of what you're about to do will foster a sense of ownership as well as reinforce both required team interactions and the context of the Tranzact dev production line.

In this example it is clear Greg has started fixing TFN-712 after it failed Brigitte's testing. The phrasing emphasises ownership, required team interactions, what sparked the activity and what is being done to move forward. The phrasing also holds that this particular activity was the result of a previous undesirable outcome.

Colours and Gesture Icons

We've used colours and gesture icons to highlight celebration worthy and undesirable activities.

The thought was that we could help make more important moments stand out from the crowd.

Next Steps

I feel the activity stream experiment has added value to to the team and it has encouraged me to work towards radiating the higher level goals associated these "how we work" phrasings. A real time reminder of why you're working on something feels very powerful. 

We are also hoping to incorporate more data sources. The activity stream currently only hooks into Jira Cloud. We are keen to expand this to include our Devops platform, support platform, calendars and other tools.

Under the hood

To implement the activity stream we code specific handlers (that generate phrasings) and match them with a pattern of change in the Jira log. Where there isn't a specific handler a generic one will construct something less specific that still expresses what's happening.  

For example "Jonty demoed and code reviewed LABS-359 with Hein" is generated via a specific handler linked to the Change of the Status field from "Dev Complete" to "Ready for QA" . 

While "Jonty updated assignee to Hein Nel on LABS-361" is a generic handler where Jonty is making the change, 'assignee' is the changed field and Hein Nel is the new value of the changed field.

If you would like more information about the architecture, or a link to the code repo, give me a shout.

Saturday, 7 May 2016

Best OSs and Devices of 2015

I have often found the lack of commitment from reviewers of devices and software frustrating. Sometimes you just want someone to say this is one is clearly the best of the pack. I understand why this doesn't happen. Real life is rarely that simple. Things shine in certain use cases while other things perform better in others.  I think there is another evil but necessary force at play. Reviewers don't want to alienate their readership. Brand loyalty in the tech space is an incredible thing to witness. Imagine a tech site - known for providing unbiased reviews - writes an article that unequivocally states that vanilla Android is superior to iOS. They'd probably lose a large percentage of their readership and end up being an Android fan site instead of something actually useful.

So I thought since I have relatively little to lose and because I have no reputation as a reviewer and I am the proud owner of Microsoft, Google and Apple stuff that I'd write a piece that dares to be clearly opinionated, that picks a side each time and tries to leave the words 'it depends' out of the equation and just gets on with stating the obvious.

Best Phone - iPhone 6s

2015 was the year of 3D touch. Apple launched 3D touch with the iPhone 6s and Apple nailed it. Yes, perhap it is gimmicky but I find it almost addictively fun. I feel like a little kid turning over rocks at the beach looking for things to excite me. 3D touch is a new way to interact with the square rectangle and I believe just for that the iPhone 6s deserves to be the best phone of 2015. I believe Apple does one more thing better than anyone else with their iPhone range. They make the device look good and they make the software look good and - this is the real crunch - they make the device and the software look good together. Android stands no chance. Google can't even get this right with their own Nexus range and Microsoft seems to be deliberately trying to make devices that look boring because they're not sure they want to be making phones at all.

Best Mobile OS - Android (but only of the unmutilated variety)

Google has been making a concerted effort to bring simplicity and uniformity to Android. The arrival of Material design and a reduction of obviously exposed features make Android and its ecosystem an absolute pleasure to use. This work has closed the gap from a usability and 'this is actually quite pretty' perspective. iOS used to lead here. What is left are two great OSs but Google shines in a couple of areas that give it the edge. 

Google Now really does surface useful things about your current world and context and you can access them one swipe to the left on the home screen. 

Google's voice recognition is in a different league to Siri. I'd say 'Ok google' almost understands me more frequently than my close friends. I haven't spent enough time with Cortana but it's not really a contender as it only works in like 2 countries in the whole wide world. 

And then there are widgets. Yes in the wrong hands widgets look really ugly on your home screen. But I'm going to make the assumption that for those folk they don't really mind anyway. For the rest of us, it is more than possible, thanks to material design to arrange your widgets so they look pretty. And yes widgets are an improvement over an icon. As an aside, Windows mobile does this in a pretty neat way by turning the icon into a widget and would probably be superior to Android if there were any actual Apps to use in the Windows mobile ecosystem. 

Android also allows apps to really run in the background which means your email, news feed, photos, cloud storage has already synced with your device when you open those apps. iOS says it does this but in 2016 some apps that really shouldn't still load stale content and then, like a naughty school kid, awkwardly get on with updating content.  For a long while the problem was that with great flexibility came great power... consumption. In 2015 Android launched Doze which provides a framework for managing power consumption of background services based on context. So now, when my phone isn't being used, background services can run less frequently. And it really works.

For power users Android still lets you get away with more than either iOS or Windows mobile. It's just that now if you're not a power user everything is as simple as iOS or Windows mobile.

A parting thought: As soon as you move away from a device running Vanilla Android (Nexus or.. um.. Nexus) iOS wins again. Consistency of experience is a big deal and almost every Android device manufacturer just doesn't get it.

Best Portable Computer - Surface Pro 4

Microsoft have pulled off some real magic with the Surface Pro 4. 

It runs a laptop grade Skylake i7-U CPU with 16GB of RAM and 1 terabyte of storage in a package that weighs 785g. The internals are not comparable to the iPad. They're not comparable to the Macbook air or Macbook (M processor). They're not even comparable to the Macbook Pro which runs an older generation of Intel's U class mobile processors. 

It has a touchscreen like an iPad and a detachable keyboard so you can use it like an iPad. Windows 10 has done a good enough job of making the touch experience usable for most touch use case scenarios (web browsing, reading, video watching, writing). Basically as soon as soon as you detach your keyboard you're in consumption mode (unless you're writing) and that's really all you use an iPad for anyway. App developers seem to have cottoned on to this and you'll find all the big name consumption services in the Windows app store (Kindle, Netflix, TED etc.). And of course there is Chrome for web browsing.

The Surface Pro 4 ships with the surface Pen which is surprisingly useful for... Well, drawing things. And not blocking my presence in a meeting with an upright laptop thing (because I'm drawing - doodles - and not typing). 

The Surface Pro 4 fixed the final flaw in Microsoft's transformer by designing a laptop grade keyboard and multi touch trackpad. The mind boggles why it took them this long, but it is done.

The surface dock provides a very slick transformation into a full desktop experience. One click of the surface dock connector and all my desktop size peripherals come to life and the Surface itself transforms appropriately.

Windows Hello is an understated feature that delights me every day. The Surface really knows who I am. As I sit down (even in the dark) it says Welcome Greg and logs me right in. Without me even having to touch it. It does this in a way that is apparently secure (some 3D modeling of my head and facial features) using multiple cameras and an IR blaster.

The Surface Pro 4 is also a precision crafted beautiful thing. Microsoft's design language flows very elegantly from the Surface through to the Windows 10 OS.

Does the Surface Pro 4 try to do too much and end up being shitty at a lot of things? The answer is honestly no. It's doing them all and it's doing them well.

The Surface Pro 4 is an iPad and it's a Macbook Pro in a device half the weight of a Macbook Air. It's honestly remarkable. Nothing comes close.

Monday, 8 February 2016

Good Management - Discussion by Scenario

I have spent the last 6 years or so learning how to enable a team. It's been a slow journey and if I were kind to myself I'd say it was slow because my most natural inclination lies with the code rather than the relationships of those around me. In truth it is more a journey in being vulnerable and getting the ego out the way, which is taking time, but it's making space for learnings that are quite life changing. I am still very much a novice of management (of any sort) but perhaps there is something for you to take away from my stories.

I think being a good manager requires keeping a lot of external pressures in balance that are often contradictory, subjective and unclear. Being a good manager often requires making the correct quick decision based on your knowledge of the situation and how the people involved will respond best to an intervention. Sometimes being a good manager means empowering others and taking a step back but on the flip side doing nothing because it’s all so unclear is paramount to not doing your job.

To add more on top of that as a manager you have to fight against your learned childhood habits and fears to react disproportionately in some situations and this is probably one of the hardest parts of the job. You also have to realise that other people will naturally overreact in some scenarios and you need to magically weave your way through this minefield in order to achieve optimum happiness and output from your team.

These rather subjective areas of management make me quite tempted to ignore them. In fact, distancing myself from things that make me uneasy is one of my learned childhood habits.  Alas, my scapegoat reaction doesn’t make the problems and excitements of enabling a team less real.

In this post I run through some scenarios from my very real world and discuss what a lead developer, manager, CEO, agile coach, scrum master, facilitator might do to deal with them. For each scenario, I’ll set up a situation and outline some possible approaches to handling the situation.

I have made an assumption that management is a concept that each one of us takes up, be it to manage our internal worlds or move a project forward or to help a team improve. For this reason I have been quite lax on associating roles with the scenarios that we run through. It by no means follows to say there shouldn't be roles in team.

This post may have benefit for someone trying to get a team past the headwinds of initial agile adoption and it will be a useful reminder of some of the challenges that face us each day, in life and at work.

In a roundabout way the topics, scenarios and stories that follow document some of the journey of ego reduction and making space for vulnerability that Tranzact and I have taken. The journey ultimately resulted in us adopting an agile process which then substantially fast tracked our progress.

Expressing vulnerability puts it on the backlog   

Vulnerability and Ego are hard to get right in practise and was probably the step that took Tranzact the longest in its journey to improvement. The scenarios that follow are probably obvious but perhaps we can just take a moment to acknowledge how hard it can be to do the right thing.
I’m frustrated and worried with a relationship I have with a client that is possibly going to increase the chances of a failed product. We’re struggling to follow up with each other. We're both bad finishers. We’re bad at pinning down a requirement together. I react by distancing when they don't listen to what I say.
What do I do?
  1. Use the team as a platform to express my disdain with how our client is failing to help us build the right product. 
  2. I don’t tell anyone and make excuses later.
  3. Talk about my client relationship issues openly and constructively with the team, being vulnerable about my shortcomings.
  4. Make the tough choice that the client is probably not a good fit for the company and motivate for the product to be cancelled.
I don’t think I have ever managed to talk openly and constructively with the team before doing a little of the others first. Our natural silence or misdirection leaves the product in a tenuous position and it robs us of the ability to learn and improve. The benefits of letting your guard down, being vulnerable and allowing the people on your team to help you can be enormous. Perhaps the product should be cancelled, perhaps you need some tips to help get you on the right track, perhaps someone is better suited to handling the relationship.
Harry mentions a potential stumbling block I hadn’t considered. Our operating system upgrade isn’t compatible with the version of the database software we’re using.
  1. Tell Harry that database software upgrade will happen at the same time, even though it wasn’t in the plan yet.
  2. Acknowledge you hadn’t noticed the incompatibility and praise Harry in the next stand-up meeting for saving your ass.
Without the acknowledgement Harry’s contribution has effectively been stolen and it’s gone unrecognised. Contributions that continuously go unrecognised will probably stop arriving. Harry will feel devalued as he feels the rest of the team already have the answers he’s brining. If we don’t manage to be vulnerable for a moment to acknowledge Harry's contributions, the opportunity for building trust and encouraging natural teamwork is lost.
Our client calls in and asks me if things are good with the thing I promised to work on over the weekend (but forgot about).
  1. Pretend we’ve done the work. And frantically sort it out.
  2. Pretend there was an impediment or make some other mostly invalid excuse.
  3. Acknowledge we committed to something we haven't done and apologise and make the best plan together to mitigate the situation.
Holding on to your ego in 1 and 2 doesn’t allow the team to adjust to its strengths. The team becomes reactive (or you become reactive). Perhaps there wasn’t actually a need for you to have committed to those changes in the first place. If you said you’d do the work over the weekend just to show off, you’ve probably subtly set a standard in the team that commitments don’t need to be met.

The benefits of keeping the ego in check, letting your guard down and being vulnerable are tremendous but often incredibly hard.

How do we make vulnerability easier for our teams?

Creating a safe place for team members to take a journey towards expressing vulnerability can be tricky.  

Without a doubt expressing your own vulnerability will help people around you feel safer to express their own. We've also found expressing the things we're really good at and celebrating our wins has helped us be OK when we have to acknowledge something we suck at. Phrasing helps (even when its to yourself). For example: "We really kick ass at dev ops, but we're pretty bad at making sure our users actually use the stuff we release". Our weakness "making sure people actually use our stuff" seems just a bit easier to own now. Having an agile framework that we understand and value to work within has also helped the team put aside time to have harder conversations.

My list needs to be longer but this is what I've got so far! I'd love to have conversations about making it more complete.
  • Be vulnerable 
  • Radiate individual and team superpowers
  • Adopt a process
  • Foster team identity
  • Collect metrics
  • Celebrate wins

Radiate team superpowers

Know and acknowledge your limits - bring in a specialist when needed

I've previously documented Tranzact's journey towards adopting an agile process and coming to terms with some of our bad developer habits. This journey was really one of reducing my typical developer ego and learning to be vulnerable.
In the early days, with no formal process, new projects coming online, dropped balls and failing communication Tranzact were starting to feel some pain. What did we do?
  1. Change nothing
  2. DIY
  3. Adopt a standard
  4. Bring in an expert.
In the beginning our fear of the world changing around us kept us from making any change. We just kept doing things the way we had been doing it. Later our developer egos got in the way and we developed our own issue tracking system and release process. Eventually we adopted an agile process, but only after nudging from clients and feeling enough pain that we were almost forced to make a change.

We switched away from our own issue tracking tool to one that helped us follow the 'Scrum' steps I’d found in a short online course. The team was mildly optimistic but also sceptical that all this would make things better because in the moment there was just extra pain. The tool we’d adopted needed configuration. Switching to it complicated our automated releases. And it didn’t have some of the features our home grown software had. The team was seeking answers to their whys and no one, including myself had the answers.

Tranzact could have avoided a long, risky journey of discovery of how to operate as a team if we’d been able to acknowledge that we’re not the best at everything and asked for help. Bringing in an expert saved us from probably never discovering the true value that can be achieved by working effectively together.

Have you been part of a similar journey?

Make sure individuals and the team understand why work is being done

A couple of years back I asked the team if they had moments when they didn’t know what they were supposed to do to do their job or didn’t know what was expected of them. Without hesitation every person put up their hand.
What do you feel when you get this news?
  1. It’s a fast paced world. Who has time for clarity on whats and whys. We’re just trying to keep our head above water.
  2. Believe the team is self organising and hence its not my responsibility to help them understand what is expected.
  3. Worried! The team should always have some clarity of what is expected of them. 
  4. It's fine. Low clarity breeds creativity 
In our more recent years Tranzact has gotten good following the agile process. We stand up, retro, plan, pair, review, measure. The team typically know how to keep busy this way. Tasks get moved up the backlog, get actioned and get out the door. This way the process allows everyone to feel held, feel safe and empowered with something to do. It’s a good runway.

We found that the the process itself didn’t necessarily help us hit our targets and this was mostly because those targets weren't particularly clear. We were moving things off the backlog and this worked great for operational issues because people were jumping up and down asking us to make their very real and current pains go away but that even short term product build goals often suffered.

I have made the mistake of not planning even one 'why' up for awhile and we’ve really only started radiating our goals in the last few months. The cost of not thinking 'why' is actually higher than I initially imagined. We may have been building slightly the wrong things but it also meant the team wasn't empowered with purpose. Churning yet another bug or small operational enhancement off the backlog feels empty compared to working towards something bigger. A team empowered with higher level purpose will hopefully be in a position to feel motivated and take more ownership.

Some project goals at Tranzact


Side effects of not understanding why

  • Lack of purpose
  • Lost opportunities for learning and motivation
  • Lack of ownership
  • Invalid feedback
  • Building the wrong thing

The feedback from the team a few years back has come to mean option number 3 for me. In fact in hindsight the fact that the team so readily put their hands up meant in those moments we probably had a failure at a number of levels.
  • The runway (day to day operations) weren't clear. 
  • The project goals weren't clear. 
  • People’s roles and responsibilities were muddy.
  • Tranzact’s medium and long term goals weren't defined.

In order to create goal clarity at Tranzact we are playing with a couple of techniques and frameworks. I hope to get a post up soon with our learnings there and I'll update with a link here.

Once our goals are clearer we hope to be in a position to celebrate our victories (because we finally know what victory looks like) and have critical conversations about missed goals or other noticeable inefficiencies because of the same reason. We'd like to know where we are going!

Don't micro manage by taking over delegated goals

Our journey of ego reduction, vulnerability and an effort to connect to the reasons we do stuff has left Tranzact in a much better place than we were, but it is amazing how easy it is to damage a good thing.

I have a horrible tendency of stealing ownership and in the process creating large amounts of work for myself and disabling perfectly capable ‘owners’ from doing their job. 

Here’s a scenario 
Alex is running with a new feature but I notice something hasn’t been followed up on as soon as I would have liked. What do I do?
  1. Personally follow up with the client and pass feedback on to Alex
  2. Remind the Alex to follow up with the client.
  3. Let the Alex fail to follow up if it is safe and have a conversation if goals are missed as a result.
  4. Open communication channels to allow Alex to talk about his approach.
  5. Relinquish the Alex from his duties as he’s clearly going to
There are countless examples of my bad behaviour scattered through any given week in Tranzact’s history. I will frequently choose 1 or 2. I believe that every time I do this I'm:

Stealing ownership. Alex, armed with responsibility and a clear goal can figure out how to achieve his goals in his own, potentially better, way and if he fails he has an opportunity to learn. My micro management moment also creates work for myself. In the case of 1) The people I follow up will naturally start talking to me rather than Alex and there is a risk Alex will be cut out of the solution. In the case of 2) I am now an inefficient middle man as Alex will rely on me to be his task management system. Thus,

Some consequences of of micro management

  • Depriving people of opportunities to learn
  • Limiting the chances that goals will be met using people’s own strengths.
  • Responsibility is clouded and we’re often tackling the what instead of the why.
  • Creating work for myself. 
  • Generate inefficiency

Don’t let team tensions go unresolved

Over the years Tranzact has grown to become a diverse collection of individuals from different backgrounds. Naturally we’ve had tensions and personality clashes. I am conflict averse and this has meant it's been incredibly difficult for me to actively get involved to help people resolve their differences so they can get back to working symbiotically.
Here are some voiced Tensions from Tranzact’s world. Anonymised.
  • Bob mentions he likes working on Project X over Project Y because Harry is better at making it clear what he needs to do. 
  • Larry mentions he’s not too sure about Bob because he’s unfocused and takes risks.
  • Bob mentions Chris can be daft sometimes, suggesting he’s not good at his job even though there is evidence this isn’t true.
  • Mike says Larry’s work ethic seems to be  slipping and he doesn’t trust his check ins.
What about non verbal observations and feedback?
  • Jo often arrives late for meetings.
  • Larry never seems to pair program with Bob, no one says anything but the stats don’t lie.
  • Mike and Bob almost always review each other's code.
  • Chris often interjects with lively but off topic banter and seems to break the focus of the rest of team.
In a team that is open to vulnerability that has a lot of trust there is a high opportunity to resolve these tensions easily. The level of team trust and vulnerability required increases with each intervention that follows.
  • Don’t worry, Larry was having a tough day, the comments were probably harmless.
  • Protect the team culture by moving someone incompatible out of the team.
  • In a safe 1 on 1 space, ask if a deeper discussion would be useful.
  • Organise team discussions covering topics like respect, disruptions, focus, quality (or whatever tensions are brewing) and let the team build awareness.
  • Create safe spaces where the team learn about each other's strengths and weaknesses without feeling judged. Trust is built by honest conversations about habits and conflicts.
Even though unresolved tension is bad, In my experience one of the other damaging things I’ve done in the past is to interject in a controlling way without understanding exactly why there is a problem. A non critical, inquisitive opening in a high trust team will probably result in the right discussion rather than one filled with my preconceptions.

Summing it up

Tranzact and I are still working hard. The improvements are definitely coming faster than they did in the early days, but we've still got lots to do. We've learned that you need to continuously identify areas of improvement and then commit to working on them in clear and measurable ways.

I did a talk on this content to a wonderful group of Agilists in Cape Town last week. The slides for that are here.

Saturday, 31 October 2015

When we Mob, Pair or Solo Program

In 2010 it would be a rare sight to see two programmers sitting together solving a problem at Tranzact. Only in times of distress would someone shuffle in next to another team member to work through something new or challenging. I wouldn't say we were a collection of non communicators but like many computer programmers, we were naturally more connected with our screens and our inner worlds than we were with each other or our clients. Not because we didn't want collaboration in the office or that we didn't want to build a great product for our client. The idea just didn't come naturally to us and we didn't have the skills to make it happen effectively.

Today we try to take the time to learn these collaborative skills and one of our focuses has been to look at how we can code well together. We have introduced both pair and mob programming and we use them for various types of work.

Mob Programming
Martin Cronje from nReality introduced us to mob programming earlier this year. When you 'mob' the whole team works with a single computer and a single keyboard. Everyone contributes and takes turns typing. This 3 minute video shows a typical day of mob programming. We use the technique for things we think are best solved as a collective like:
  • Learning and mastering skills together
  • Transferring business knowledge 
  • Working through complex problems
  • Working through code that may have high regression
Apparently some teams experience enough increase in value that they mob program everything. Mob programming definitively results in high quality work that is aligned to business value. The team learns frequently and deeply. There is little time spent aligning team goals because everyone is working on the same thing. For the same reason there are no key person issues. When someone goes on leave things keep going along as usual. It is much easier to build and deploy a single piece of work without a change in focus. 

A lot of benefits but the cost is that input into your code base only occurs from only a single keyboard. Also its pretty intensive. For these reasons, and because we still have a way to go before we'll focus on a single goal like a great sports team, we don't mob program everything. 

Pair Programming
We typically pair program for similar reasons to the mob exercise and only distinguish the two because pair programming happens at someone's desk while mob programming happens at our meeting table.

For both we take 10min turns at the keyboard. The person typing is not allowed to go ahead with any work unless they have buy-in from someone else.

Solo Programming
We code things solo if we feel we can't extract enough value from a pair or mob programming exercise for the type work required. Typically these tasks are well understood both from a business value and technical perspective.

A developer working on a task solo will end with a functionality demo and test and a code review. We do this to inject some mob and pair programming benefits (like increased quality and consistency) into our solo programming tasks.

For our team, some solo work is important as it provides a space for the more introverted of us to re-energise in our natural comfort zone and think introspectively for awhile.

In summary
Introducing more collaboration into the writing and testing of code has benefited our team in a number of ways. 

We've managed to introduce pair and mob programming without reducing our output even though we have some technical and business knowledge gaps to fill across the team. Admittedly we solo code a large amount of our work but I think it's quite telling that working together comes at no output cost right from the start.

Tuesday, 15 September 2015

A team in search of a process

This is a short story covering some aspects of Tranzact's evolution as we've grown from a 1 developer company to a team of 9 over the last few years. If you're mostly a developer and you've started a company or you have a team to manage perhaps you'll be able to relate to some of this story.

Tranzact was a small 2 person 1 project company in 2007. I had one focus and almost no communication points. I could work from wherever I liked. I have memories of me and my laptop going on various holidays and getaways. Together we wrote beautiful code in very beautiful settings. Mostly we annoyed my friends who wanted no reminder of work. We annoyed them frequently because we could go on pretty much any adventure. I was living the dream.

Today Tranzact is still small but we're now 9 people who manage 4 projects. We have many communication and focus points and it's no longer simple. In most ways it's more rewarding being part of a team but we realised we needed to focus on how we work together. We had heard people talk about development process. Some of us had even learned about development process. So we decided we needed a process.

Strangely I'd heard of CMMI* in our early stages. I don't think I knew we were soundly at Level 1.

Our first take was to do what developers naturally do. Forget everything we may have learned and build our process from the ground up. Without asking anyone. We ended up with our own task management software, role names and process flow.

The home baked issue tracking software

What we built was completely our own and that was very rewarding. Everyone in our small team contributed to how we build software in some way. Hein and I created the task management software. Warren got build automation up and running. We all sat down and documented our company values. At one point we even had a daily status update. Later, thanks to the help of one of our new clients, we came up with roles and a weekly cycle in order to have touch points for all the steps we needed to build and deploy our software.

What we created was quite pretty but also often inefficient and ineffective.

Building our process from the ground up.

The "from the ground up" exercise taught us that spending time with our challenges can be useful. We started to understand problems that were previously invisible. We learned how to work together. However there were still signs of trouble. Warren would often ask, 'What exactly are my responsibilities here?' and I would have no clear answer. We had moved offices to Cape Town but Hein remained in Joburg and he would comment that he felt like he wasn't part of the team. We had reached a point where we felt inadequate to come up with solutions for our troubles and decided to adopt an existing process rather than learn every lesson ourselves.

Being naturally logical and technically minded I spent some time with engineering strong, design first approaches like IDesign but felt that our problems were less about how we designed and built and more about how the team needed to work together. The next stop was Agile. Agile development seemed much more focused on solving people problems and provided a simple framework for managing all those communication points we previously tried to invent ourselves. After some quick courses on the mechanics of an agile process we committed firmly to the change. We stopped using our own issue tracking tool and adopted a tool that could easily adapt and most importantly could easily express the new process.

As soon as we formally adopted Agile and the new issue tracking tool, things got worse. We struggled with little glitches the new issue tracking had that our home grown beauty handled perfectly. We lost some elegant integrations we'd done with our build automation tool. We struggled with doing things just because "The process says we must" especially with all the downside. Many members of the team wanted to go back to the old way we were doing things. We pushed on.

Things started to get better. We started to realise some of the promised benefits and the pain of doing things differently subsided. It turned out that we still needed to learn every lesson but what we had adopted was much more than just a new process. It was an approach that allowed us to learn and improve quickly. In fact it goes a step further and mandates continuous improvement by building it into the process. It is the beginning of our new journey.

This blog itself is a new journey. I hope to write about our experiences and learnings - technical, process, business and people related - on a semi regular basis. I hope that the process of writing down my thoughts will cement the lessons and I also hope that our stories may be of use and spark interesting discussion.

*Image referenced from CMMI wiki