In a previous role, I was hired to “Improve Delivery Flow” (ref Team Topologies) across an org of about ~400, with an emphasis on process improvements, platform capabilities and debt-recovery work.
Delivery in the company slowed down over the years and they needed to find a way to unblock and speed it up to the “good old days”. Anecdotal observations showed that:
To improve something, one must first measure it, and we found that DORA is incomplete as it focuses too much on CD and not enough on teams getting shit done. SPACE as a framework proved valuable but needed to be interpreted for our needs. We landed on:
We encouraged product, platform, and sub-speciality (aka practice) teams to calibrate their improvement projects to the above measurements working towards the following north star metrics: Year 1:
Year 2
This led to projects such as:
This approach is sub-optimal as it causes invisible* side-effects, which slow down the overall delivery of the team;
There may be valid scenarios where teams share subject-matter experts (problem space or module) or specialists (like quality assistance) across the work. Even here, there are problems because ;
A natural consequence is that these teams tend to be VERY busy while not producing much.
Solutions to consider:
Other observations:
*The idea of a Kanban board is to make these things visible so people can manage the flow and prevent flow impediments early. The team has numerous kanban boards, which means they cannot identify these flow problems effectively. Each cohesive team should ideally have one Kanban board and one only.
Further reading:
The key to success is working with the team over time through continuous feedback loops to identify and implement improvements.
Before even looking at mechanisms to make teams “faster”, the starting point is proper team formation.
Russell Ackoff did an excellent talk on system-thinking, which summarises how I approach teams formation and management.
A few notes:
Have a look at Google Project Aristotle and the Liftoff book.
The best software is the software that we don’t build while still bringing the value to our customers. To achieve this requires close collaboration between product, experience and engineering to find those magical solutions the customer problems. Techniques that have served me well are things like (in order of breath):
Examples where my colleagues and I did this:
The name of the game here is to eliminate waste. To eliminate waste teams need time to find and remove wasteful activities, which means that they need to reduce the active work-hours for the teams to create time for improvement.
The seven forms of waste in Lean Software Development is an excellent place to start (one of those “unnecessary features” fall into Effectiveness above).
Tip: Detecting and fixing these different types of waste isn’t as easy as reading the book and then magically doing it the next day. Experiment with various hypotheses, measures, and solutions. Allow yourself to try out things that feel wrong!
Some areas to look at with supporting data where I can still remember (not an exhaustive list):
An option but often not feasible because of financial and productivity reasons.
On the productivity side, I would avoid having more than nine people on a shared codebase. Numerous studies show that teams of 9+ produce less with higher defects numbers on shared codebases.
]]>Martin Fowler went further to classify the different causes of Technical Debt into a very helpful quadrant. For me, this quadrant is a very complete classification of the things that cause disorder within a software system.
“A particular benefit of the debt metaphor is that it’s very handy for communicating to non-technical people.” - Martin Fowler
The important keyword for me here is “metaphor”. Metaphors only serve as symbolic description of what something is and shouldn’t be used as a literal interpretation. Metaphors (like most models) are abstractions and aim to highlight certain characteristics or behaviours through analogy.
In the instance of Technical Debt the metaphor is intended to highlight the compounding effect of that disorder (entropy) has within a system. This effect applies equally to all states of disorder whether it is just a mess or deliberate prudent technical debt.
There are two problems with the wide use of this metaphor:
(It is worth mentioning that synonyms to entropy are deterioration, degeneration, crumbling, decline, degradation, decomposition, breaking down, collapse.)
Solution: See software as an depreciating asset
I propose another approach where we rely less on an incomplete metaphor. By addressing the problem directly.
Software is an asset and in the US custom software is even classified as a fixed asset (here and here). An asset’s value is determined by the condition in which that asset exists and its value depreciates as it falls into disrepair.
In Mythical Man Month, Fred Brooks said of entropy “All repairs tend to destroy the structure, to increase the entropy and disorder of the system. Less and less effort is spent on fixing the original design flaws; more and more is spent on fixing flaws introduced by earlier fixes.”
From an asset perspective refactoring synonymous to upkeep (maintenance). As with upkeep, through refactoring we avoid having the system fall into disorder. Our system’s usefulness and value depreciates as it falls into disrepair. This state of disorder behaves similarly to financial debt in that it compounds. This lack of upkeep causes a compounded increase in the cost of further development and fixes within the codebase.
A further merit is that software IS an asset as we can use established reasoning about asset freely. We don’t have to rely on flaky financial markets analogies anymore.
We shouldn’t forget about the merit of the Technical Debt metaphor as well. When you talk to non-technical people just say that the lack of upkeep has a compounding effect and only when they really struggle to understand should you use the “Debt” metaphor.
Aside, I see immense value in the Technical Debt quadrant and simply propose that we call it something more appropriate such as the “Entropy Quadrant” or even more evocative the “Deterioration Quadrant”.
]]>I decided to write this blog post in the hope of enticing other coaching across the globe to share in this experience. Additionally I wouldn’t mind finding myself in a coaching circle with other developer/technical coaches.
Sam and Karen from Growing Agile came up with the idea of running a virtual coaching circle. The plan was to have discussions with the goal of gaining and sharing insights of different coaching related topics.
They invited Sandy and Rachael from Nomad8, and Jacques and I from nReality to the first experimental round.
We ran 90 minutes sessions every two weeks where each session was facilitated by a different coach.
With the exception of the final session which was a retrospective, each coach had the opportunity to pose questions to the group. This was done a week or two in advance of each session in order to give the group enough time to prepare.
90 minutes is not much time, but it was enough to give wach participant the opportunity to present their answers and discuss others’ answers.
All sessions were held over Hangouts and we followed this protocol:
The previous circle that we ran was themed around running and building your own coaching business. We formed trust within the group very quickly and were surprisingly open with our businesses. This was probably because we were in different countries and cities, and do not work on the same subject matter.
I anticipate that each circle will be different dependant on the types of people involved and their willingness to discuss certain content.
Here is a list of the material we covered:
Please send me a mail if you’d like to be invited to the Slack group where we organise the session circles.
I am personally very interested in being a participant in a coaching circle themed around Developer/Technical coaching. So let me know at martin[at]nreality[dot]com if you are keen.
]]>In retrospect this experience accelerated my learning dramatically and because of that I want to share this story with you.
Rewind to the 80’s…
I wrote my first code on the Macintosh II when I was 9 years old. It was awesome! I wish I could say the rest was history, but it wasn’t. Around the same time Adobe released Photoshop 2 which was the first to support colour (I can’t remember if I ever used v.1). I was hooked and spent most of my computer time designing graphics.
Fast forward to 1995 when we bought our first PC. Shortly afterwards we got internet and it blew my mind. I spent most of my time on IRC, playing games (Q2 and C&C) and messing around with basic hacks. Around 1996 I downloaded my first MP3 (Prodigy - Voodoo People) and decided that I must have my own MP3 site.
I ended up designing and authoring a new site for Moshmetalz MP3. The original webmaster and I ran the site for about 18 months when I decided to go to the UK for a working holiday where I got my first job as a web author using Coldfusion.
The rest is history.
I have been coding for most of my life and hope to do so for as long as I can. As I get older keeping my skills relevant is becoming an increasing challenge.
During my 10 years as a .NET developer I’ve had the the fortune on extremely interesting projects from doing the seat calculation for the South African National/Provincial elections through to doing insanely high speed message processing and data analytics for the Johannesburg Stock Exchange.
So why did I stop being a .NET developer? Here are 6 reasons:
Starting with with ALT.NET movement around 2005, the .NET community has made massive strides in the last 10 years. Unfortunately, the community is still filled with countless “Drag ’n drop” developers.
It is hard to avoid teams like that.
I always found it very hard to seek out interesting .NET projects. The typical .NET project usually involves management software, accounting, or data capture. Worst of all these projects usually take place in those typical corporates with under hierarchical and authoritative management, restrictive policies and cubicle farms where the you wear the standard issue blue shirt and brown chino’s. Aaarggh!
This holds equally true for Java, COBOL and NATURAL developers by the way.
With each new release of the .NEW framework (err .NET) I got less and less excited by the features. As I explained to my wife: “I was just getting a new and improved hammer every year and at the end it was still just a hammer.”
Being the lover of new toys, I had to start mastering other tools.
There was also diminishing returns in deepening my knowledge of the platform. As my knowledge of the platform deepened I had to invest more time to learn increasingly smaller minutiae.
By forcing myself to learn other platforms, I’ve become the perpetual n00b. With that I get to experience all the excitement I had when I wrote my first programs. This also comes with the angst of being unsure how well I’m doing. (A good thing :-D )
The cool thing about different platforms is how each platform and its community approaches things uniquely. To name a few differences:
What this taught me:
In summary, I believe this improved my ability as a developer because I make better technology choices and this allows me to take different.
In 2001 I decided to start coaching teams after playing roles including Team Lead, Solutions Architect, and even Enterprise Architect. My goal as a coach is to help teams become more effective across all activities in the software development lifecycle.
Being a polyglot allows me to jump in and pair program with almost any developer. It also comes with the added benefit of sharing “cross-platform” insight especially in age-old debates like the Java vs C#, Windows vs Unix or whatever else.
At this stage of my career it is more important that my knowledge is broad, than deep and specialised.
PS. It helps that I still spend half of my time building real world systems :-).
Becoming a polyglot and build real-world systems on a variety of platforms has been deeply rewarding and I believe it has made more rounded as a developer.
I love the craft and it brings me deep joy.
]]>Once the dust settled we had a focussed retrospective during which we mapped out the good and bad events leading up to- and after the migration (a.k.a. “the bang”).
Three very interesting things came to the fore:
This is not an isolated event.
As I’ve working with teams to improve their effectiveness, I noticed that teams occasionally regress to their old ways when they are faced with challenging circumstances such as:
These are usually situations where the team has no choice but to “get shit done” with limited time and resources. (Not the most ideal circumstances if you consider the project management triangle)
The worrying thing is that teams often drop process fidelity to handle these situations. Some of the things I’ve seen teams do include:
This is usually because of a combination of things;
The result was that the teams became less coordinated and less effective during crisis situations. This leads to poor quality, long hours and even more crisis.
We always used to encourage teams to hang onto their practices during these crisis situations and it always seemed to fall on deaf ears. We concluded that this was because they haven’t truly integrated the new practices and that it will be better next time.
We were wrong… Well at least partly wrong.
So back to the team in question.
During the retrospective one of the team members observed that they became reactive where they needed to become more proactive. Another team member observed that they gave up on “Agile” (ouch).
In other words their processes were not capable of supporting them during a crisis situation. In other words the rules seem to change. Based on the theme coming from the retrospective we explore two things
In a way this is similar to the concept of DefCon wherein which the US military alertness and ability to deploy increases with higher conditions of risk.
We listed out two categories “Early warning” and “Crisis practices”.
One of the goals with DefCon is that the team want to avoid it if they can. In order to do so they created a list of warning signs that would help them identify that a crisis is probable (risks) or imminent (issues):
Once these start manifesting then any team member can propose that the team is facing a DefCon situation. The team then activates DefCon based on a quorum vote.
Hopefully the early warning system will allow them to avoid crisis.
To handle crisis more effectively the team proposed an augmented process. These rules have will still be tested and refined with every consecutive crisis.
These changes are all about increasing focus at the cost of the long term effectiveness, without being negligent.
To reiterate this is an experiment and the jury is still out. The goal is for the team to increase focus when a crisis occurs.
During recent conversations @jacdevos was telling me about the Software G-Forces that Kent Beck spoke of in 2011. This came to mind during our retrospective and I explained the concept to the team. In short the concept is that the application of practices change dependent on the rate at which you deploy (G-Force). For example: Branching impeded teams if they deploy daily, but becomes a necessity if they deploy yearly.
This concept applies here to some extent.
]]>We decided to make the outcomes public in order to elicit feeback from the community. Please feel free to provide suggestions. Hopefully you’ll also be able to use some of these ideas in your own ventures.
Jacques and I originally created nReality to be a home for entrepreneurial software developers who want to maximise the value they bring to people through consulting and development services. Using these services as a vehicle we want to experiment in building new knowledge and software products that can spin off into new businesses. Like BirdLasser and DevGuild.
In order to achieve this goal one of our core values is “Our culture and philosophy is the culmination of each individual”. This means we have to continuously adapt (and improve) our business plan as we go along. This blog post reflects our current understanding.
To quote Jacques: “We are building the company that we would want to work for”.
We’ve learnt a lot from our successes and failures over the last three years. Out of our experiences we discovered that we are most successful in helping companies bring awesome products to the market. We do this through coaching teams or building the products ourselves.
Yesterday, we refined our elevator pitch to reflect this niche:
nReality is a consultancy that help companies bring valuable software products to market through coaching and development services. Our key differentiator is our focus on the entire software lifecycle and not just individual practices such as project management or testing.
We created our value system 3 years ago and have been updating it as time progressed. One of the biggest updates came later that year after we read “Delivering Happiness” which talks about how the Zappos’ value system is instrumental in catalysing their culture. A key takeaway was how you should be able to tell stories of how the value system was put into practice.
Interestingly we realised that we do not always manage to live up to some of the values - like “balanced lifestyle”, but striving to achieve them alway pull us back on course. We did not update the values during the session, but identified some duplication which we will iron out over time.
Ethics and integrity are implicit.
It is worthwhile to quickly say who our team is:
Everyone reviewed and edited this post with me.
This is a very rough draft of our current thinking.
We draw a lot of inspiration from Crisp DNA. Our company operates as a collective working together to;
This outlines some of the decisions we regarding our operation plan:
nReality members must get approval from the collective for:
This issue typically, manifests by a high rate of features that are rejected during acceptance testing. When this happens teams typically rally and say that they need more detailed and explicit specifications/stories. In the instances that the teams end up creating more detailed stories, they typically find that the problem doesn’t go away.
This is because the problem does not lie with the specs, but rather the communication of the feature. The spec is merely a mechanism that the Product Owner (PO) uses to communicate their requirements. So it isn’t that we need better specs it is that we need better communication.
When we started looking at communication between role players we found that in all cases the PO communicated what they wanted.
Nothing wrong! Right?
No! Most PO’s typically rely on their intuition to communicating what they think the solution is as opposed to what the problem is. That is the software development equivalent of diagnosing yourself and telling your doctor that you need a kidney transplant!
More subtly, developers don’t really know what features are important because they don’t know what value the requirements add to the business. So not only do we build the wrong features but we end up building things that have little value.
So how do we fix it?
The PO should communicate their problem and more importantly they should communicate how we would know when the problem was solved. This is very hard though, because for the first time the PO has to take time a think deeply about the problem and the related test.
As a developer your best tool to guide them is to behave like a 5-year old and keep on asking the PO why they want something.
This line of questioning should be structured to get to the money!
All systems exist to either increase revenue or increase profitability (typically through increased efficiency). So structure the questions to guide the PO toward they money.
Example (what-driven):
PO > We a report to track inventory!
Dev > What should the report contain
PO > Current stock levels of inventory in our warehouse.
Example (why-driven):
PO > I want a report to track inventory!
Dev > Why?
PO > I need to the report so that I can assess when I need
to order new stock or cancel existing orders depending
on market demand.
Dev > Why is that important?
PO > Too much stock means that the stock can perish and too
little stock means that we can satisfy demand.
Dev > You know we can build a "job" that send you an
notification once we hit certain thresholds and it will
probably cost less than the report.
Do an experiment with a friend:
1) Why do we need to authenticate ourself in an online store
if we don't do so in physical stores?
2) What value is there in creating a maintenance screen for
most lookup data in the system, especially things like
countries and cities.
This is also not easy because the PO may end up saying “Why? Well, simple, it is your job!”.
This may become a hard conversation if you are dealing with a hostile Product Owner. Irrespective I typically use the above examples as a thought experiment to show them that we can come up with better and more cost-effective solutions if we analyse the problem together.
Once you established what the problem is and how it relates to money, you should proceed to the test. In this instance you should investigate what the desired outcome is given different pre-conditions.
The scenario format “Given… when… then…” works very well for this.
I’ll explore good tests for another blog post.
This tool has helped many of the teams I work with become more effective in analysing requirements.
In fact, many of these teams abandoned traditional documentation completely and spend most of their energy getting to grips with the problem.
Beyond hype and dogma: How South African teams increased their value
During this session Martin will share stories on how different South African teams improved their value through applying lean and agile thinking, processes and techniques.
These teams are from different sectors, sizes and culture including education, legal, finance and property investment. The session will also look at the challenges that these teams faced.
Some of the stakeholders including CIO’s and Development Managers in the respective businesses will also be in the session to share their experiences first-hand.
]]>