Which delivery framework?

Should your business run Agile or Waterfall (sequential projects)? Quite often the answer isn’t black and white, and should be answered based on the characteristics of the problem / project/ situation being tackled.

Dave Snowden created excellent Cynefin framework in 1999 while he worked at IBM. I was lucky enough to meet Dave briefly at the IBM Technical Council in 1999.

The framework helps organisations understand scenarios in the world and how best to handle them / map them to frameworks.

Sketch of the Cynefin framework, by Edwin Stoop

Scenarios can be broken into one of the 4 domains. Until we decide on the domain we are in a state of disorder.

Complicated domains are not “simple” to do, but have certainty to complete their goal. Experts are available to provide insight and knowledge, removing uncertainty. Documentation is available and requirements can be determined up front with minimal risk of change during delivery. A service provider delivering “off the shelf” third party products exists in this domain – for example installing access control hardware. Waterfall is better suited to this domain.

Complex is where the problem is clearly full on uncertainty. No one has done what we’re doing before – no experts can be brought in to tell us what to do. We must work to remove uncertainty through exploration (sense / probe). Software development is typically in this domain. Agile is better suited to Complex domains.

Simple domain are highly scripted, well established and can be performed using best practices. They have little to no uncertainty. A highly repeatable sales process would fall into this domain.

Chaos is out of scope in this discussion, but does come into play with support triage / bug handling in the software / service environments.

Often organisations find themselves with complicated and complex projects in parallel or related to each other, which is fine and natural. Sometimes large customers don’t want to work in Agile frameworks, so it’s necessary to wrap internal Agile processes with waterfall like wrappers (though not recommended!).

The important thing is how the company chooses their core framework. What framework should be used to direct their ethics, their culture and way of working with customers? That’s really up to the board to determine, but in my opinion Agile leads to far more positive work environments where staff feel valued and excited about their work; customers are happier and more likely to be advocates, shouting about your team from the roof tops.

So long, and thanks for all the fish

Two weeks ago I was removed from the board of a software company I had spent 6 years building, through long days of blood, sweat, tears and personal sacrifice. I created 3 enterprise level, unique products that were selling well.

I’m OK with the end. It’s time to move on. But it’s hard to say goodbye to code, systems and a great team I’ve put so much of myself into.

So what went wrong?

Ultimately, the end came about due to a fundamental culture mismatch causing a dispute between myself and one of the other directors – let’s call him C (there were 3 of us, always bad news). The second director in the middle (let’s call him B) was – though very adept – often changing his mind when discussing things with others around him. He had a low opinion of himself, and often didn’t trust his own instincts and views. Combined with the personal friendship and the hostile communication techniques from C, B just towed the line of C. So that’s bad news for me – any dispute would be 2 vs 1.

So what was the dispute?

I came from a software architecture background, and from the start in 2013 we worked using Agile methodologies. With 1 developer, there was only so much you could adopt without it being a little silly – I was product owner, scrum master, developers etc, so much of the machinery of Agile frameworks wasn’t of use. The important thing was knowing what to work on next and working in a time boxed way, and working closely with the customer.

I was big on transparency (release notes, being honest about bugs etc) and delivering what the customer wanted over what was agreed up front.

As the team grew in the last 2 years we extended the Agile approach, but lost our foundation in the Agile Scrum framework. In hindsight I should have re-grounded us at that point as an Agile company, and all the re-affirmations to our culture that needed.

At the start of this period C came on board full time, after waiting for the products to be sufficiently finished in relative low risk safety of his existing employment. He came from a consultancy and hardware installation background, where services are black boxes taken from the shelf and installed. He had never heard of Agile, and worked using Waterfall / sequential delivery techniques (as is right in that problem domain).

We should have discussed this then – should the company be Agile? What is Agile? etc etc. That never happened – I’ll take the blame on that one. Instead C took 12 months working on a pointless pitch deck (we had expired our EIS qualification by that point) where he eco-chambered his own beliefs into pretty presentations, backed up by Gartner and industry leading statements from other service providers (note, not software developers).

A year ago (October 2018) an argument came up in the office where I stated we were a software company delivering software products. C believed we were a consultancy first, who happened to do software products. I walked away grumbling, but I should have pushed for resolution on that fundamental (and very damaging) differences in direction – more importantly a change to the companies previous direction.

C continued to push the consultancy / services angle, stating in the last 6 months that the Sale was the single most important thing for the company.

Crucially, B and C failed to attend any internal meetings, Sprint Planning or otherwise – since it’s not a software company, why bother?

Many disagreements occurred between myself and C, where he continued to sell things we simply didn’t do, moving into new markets continuously, putting pressure on our tiny support and delivery capabilities. He had no appreciation for the time and effort my team put into software development, frequently sent rude, belittling emails (just do it) – basically acting like the atypical nightmare boss. Bear in mind I was a fellow Director. He refused to engage in tabled meetings, ignored emails or flat our lied to customers or my team (many written examples, all ignored by B). Of course, simple incompetence can look like a lie, but I’ll give him the benefit of the doubt here. When he did attend a meeting, it often broke down into C shouting abuse at me or attempting to “trip me up” and humiliate me. Often work had to be prioritised based on these tantrums.

Enter the last straw. After many disagreements separately, I was engaged in an open conversation with a customer. Though I’d spoken to this customer on a weekly basis, his expectations always seemed on the high side. I advised that there will be bugs as they were an early adopter, and we’re working hard to address the issues (which he knew). Enter C, telling me to stop talking to the customer (as Head of Development!). This was because he had withheld that the customer was an early adopter, leading to the unusually high expectations. Suddenly it made sense.

Another argument kicked off, where I suggested the company needed to split into consultancy and software, so the toxic combination of these conflicting cultures could be resolved. As a minimum I suggested the following as a company manifesto of conduct (this never got hashed out, so apologies if its a bit messy).

  • We are polite and respectful to each other. 
  • We listen and value each other’s opinions. 
  • We interact with honesty, transparency and integrity. 
  • We treat each other as equals, regardless of our position. 
  • We lead by example. 
  • We encourage and build each other up. 
  • We work to foster a positive working atmosphere.
  • When we provide critique, we do so positively and constructively. 
  • We sell to need, but sell often. 
  • Existing customers are more important than sales. 
  • Staff and their well being are more important than existing customers. 
  • Internal meetings are more important than customer meetings.
  • We deliver what the customer wants, continuously. 
  • We foster transparent, friendly relationships with our customers to better capture feedback. 
  • We follow the Agile development disciplines and project delivery techniques. 
  • We accept it’s OK to fail. We learn, we resolve and we improve.

2 weeks of no communication (emails ignored, messages ignored, phone calls ignored) I’m called to a meeting by a third party.

I had turned up to the meeting with handouts to discuss culture, the manifesto and direction, and how we could promote better team work at the board level.

B and C are there, and I’m told by the third party that they had voted me out of the board. They utter not a word for the duration of the meeting. A hostile take over basically, rather than actually have a conversation about a reasonable manifesto. Complete madness.

I think C expected me to stick around as an employee, but that wasn’t going to happen. I did the right thing and handed in my resignation, effective immediately. I was calm and walked out without shaking any hands (C actually offered his hand, unbelievable). I could have done this differently and had them for unfair dismissal, but the outcome would have been the same. More importantly and I was able to leave with my dignity and move on; you can’t put a price on that.

And so here I am. Culture mismatch and my own shortcomings recognising the importance of alignment early on.

The developers have all left with me. I’m proud of the team and the products I built, and wish them all good luck in their future.

I wish B and C luck. Running a software company using Waterfall / sequential development driven by sales and specs rather than what the customer wants is going to end in tears, but I’ll let them find that out themselves.

I owe them that much.