TDD: Testing Adapters for Abstract Classes

Abstract classes in languages like Java or C# serve two purposes: they create polymorphism in design, and they are a convenient place to put behavior that is common to all derived classes, avoiding redundancy.

But if all behavior in TDD needs to be tested, and if instance behavior implemented in abstract classes cannot be tested (because they cannot be instantiated), then how can we adhere to our process? Continue reading “TDD: Testing Adapters for Abstract Classes”

The high cost of certification

The certifying bodies who control their IP have incentives to keep costs high. They do this by having a limited supply of trainers, using small classroom size techniques, and providing more training on their frameworks than we’ve found necessary. This extra focus on the framework takes away from the skills people have to learn to be effective. Continue reading “The high cost of certification”

The Lean-Agile Manifesto

Originally published October 20, 2017

Context / Intent for Article

I have seen the Agile movement grow from when we new a fraction of what we have now and didn’t have a name for the overall approach. XP and Scrum were gaining ground. We talked about the value of co-location, self-organization, quick feedback and deliveries. Different people had different approach (there were Scrum and XP ‘wars’ during this time) and the Agile moniker was created with the Agile manifesto. Given that Agile, at the time, was focused on teams and didn’t require much management involvement (other than to let the teams self-organize and to not interrupt them) the Agile Manifesto reflected this.

As Agile moved to multiple teams, it was natural to try to expand Agile via current existing Agile methods. So Scrum-of-Scrums was born. Unfortunately, inter-team dynamics are not the same as intrateam dynamics and this method usually only worked in few situations where it was applied. Continue reading “The Lean-Agile Manifesto”

Sustainable TDD: Part 3

TDD depends on a strong connection between the automation of the test suite and the system itself. The suite should record the specification that is implemented in the system, and the connection allows this to be confirmed at any point.

The problem is automated tests pass by default. So, if errors creep into the test code that breaks the connection to the system (the tests are not really doing anything) they would still pass under most circumstances. Continue reading “Sustainable TDD: Part 3”

Sustainable TDD: Part 2

Project managers have to balance resources. Spending them on one thing means not spending them on another. So, when the team adopts TDD, it is understandable that attention is paid to the level of resource needed to sustain it over time.

It’s not uncommon for project managers to notice, as the project grows, that the creation of tests and their maintenance seems to be an increasingly large drain on resources. Team leads may note that the suite of tests is actually larger than the production code base, sometimes far, far larger. Continue reading “Sustainable TDD: Part 2”

FLEX: FLow for Enterprise Transformation

Goal: Achieve business agility: The quick realization of business value predictably, sustainably and with high quality

Why: The purpose of an organization is to provide value to the customers and a great working environment so that their employees can manifest a sense of purpose and be acknowledged for that

What: Achieve flow in the organization using Flow and Lean-Thinking, culture, organizational development, human behavior, laws of software development, effective leadership and management

How: Provide a starting framework to an organization that has been tuned for the organization and a method to improve it on an ongoing basis

Continue reading “FLEX: FLow for Enterprise Transformation”

Introduction to FLEX webinar tomorrow 9am pacific.

FLEX leaps beyond the normal frameworks of today that are somewhat preset in how they work.

There are three mindshifts in FLEX:
1) our goal is business agility – the quick realization of value predictably, sustainably and with high quality
2) people do need a set place to start but it can be based on their needs, not a preset approach that makes selling courses easier
3) we must focus on the work by attending to flow using Flow and Lean thinking

FLEX’s approach is simple:
1) see where you want to go
2) see what’s in your way
3) create a roadmap to help alleviate these challenges
4) start working
5) improve your explicit workflow, policies, practices as you go

It’s a myth that you need a one-size fits all approach that preset frameworks provide for consistency. FLEX is as well documented as SAFe but is documented as a live document which is literally updated by the consultant using it to guide you.

Check it out at


What We Can Learn From Mob Programming

Originally published Dec, 12, 2017

First, full disclosure. I have never used or even seen mob programming.  When its creator, Woody Zuill, first mentioned it to me I was intrigued but wasn’t sure it would work efficiently. But, knowing Woody, I didn’t doubt it worked. Just figured only for small, independent teams.  After talking to him recently I have changed my mind. This blog is my understanding of mob-programming now, inspired by Woody’s insights. Attribute anything valuable about mob-programming to Woody, anything incorrect to me.

The question for me about mob programming has always been – how big can you go with it?  I have known that paired programming was good (having done that).  Of course, people ask the same thing about that as well – how can two people doing the same thing be effective?  Of course, that’s a misunderstanding – they are not doing the same thing – they are working together. So, we already know that micro-mob programming (a mob of 2) works.  But what’s the upper limit?  How would you discover that?

In the conversation I just had Woody told me:

With some questions it’s very useful to identify an “opposite” question.  This can lead us to finding more meaningful questions. He said the first question he was ever asked while speaking about Mob Programming was “how can you be productive with five people sitting at one computer?“

The reverse question he came up with was “how can we be productive if we separate the people who should be working together?“ The purpose of asking the reverse question is to show that there are more possibilities in the questions we could ask, and in particular when the original question is not easily answerable. This led him to a slightly better question, which is “What are the things that destroy productivity?”   And of course, productivity is probably not a good thing to strive for, and he usually prefers to talk about effectiveness.

So what destroys productivity (or effectiveness)?

  1. Hand-offs
  2. Waiting
  3. Meetings
  4. Unfinished code that you’re not actively working on
  5. Unclear understanding between team members
  6. Delayed feedback on errors you’ve made
  7. Integration problems

There are probably other things not listed. Woody tells me these things don’t happen when you do mob programming.  While I have not seen it, I believe this to be true because Woody is a very trusted source whose only agenda is helping people. It also makes total sense when I stop to think about it.  Furthermore, when I look at teams whose individuals don’t work together I see these things taking up about 80% of their capacity. So even if mob-programming is a bit less efficient because of more people working together than is needed, the elimination of 80% of what teams normally do probably more than compensates for that.  It also produces higher quality code and a broader understanding of how it was built – meaning the team won’t run into the constraint of only one person knowing how it was written.

So how many is too many? I like the observation – “In theory, theory and practice are the same, but in practice they are different.”  So I’m not looking for a theoretical limit.  The real question is when are people not contributing?  Contributing doesn’t mean just doing the work but includes learning since that, as we mentioned, improves the people and the organization. Woody, of course, has thought this through. This is one of the great things about him – he’s not trying to promote or defend anything – he’s just looking for what works. So, the solution is easy – just people the option of self-selecting out when they feel they are not making a contribution. They will still be close by when needed.

There is another aspect to mob programming.  It sounds like fun.  So give it a try and pick a number you feel comfortable with.  Then try a little bigger (remember, people can self-select out).  Having fun has clear personal value, but also clear business value.

Al Shalloway
CEO, Net Objectives

Postscript: I talked to Woody at the Deliver Agile conference in Nashville this week. Here’s another point on mob-programming. It’s all about flow and true value delivery. When I consider that most organizations are running at around 5% efficiency (not a typo – five per cent) then mob-programming, even if it were a slight waste with 5 folks around at once, would be a massive improvement).

Sustainable TDD: Part 1

TDD is typically part of an agile process. This means that we embrace change, that new requirements flow into the team’s work either on a time-boxed pulse, or through some kind of pull system (like Kanban). In TDD, a new requirement always starts out as a new, failing test or “specification.” We write the test to express the requirement before it has been fulfilled.

Then, work is done in the system to make this new test pass. Over time, however, developers begin to experience the syndrome where making the new test pass makes older tests fail. Those tests must be maintained (you cannot leave tests “in the red”) which burdens the team. This problem tends to get worse over time. Continue reading “Sustainable TDD: Part 1”

Lean-Agile Newsletter – April 30, 2019

Net Objectives

I have been doing Agile for over 20 years. I see a new path forward, however. One that includes the entire value stream (from concept to consumption) and one that integrates many ideas on the technical side throughout the value stream. This newsletter focuses on two things:

  1. What’s the next thing after Agile (or, if you prefer, what is Agile morphing into?)
  2. How to improve your technical agility

For those who want to see what’s coming in Agile at scale

For those wanting to see what’s coming in technical agility

A side note for those considering or wanting to improve SAFe. As a former contributor to SAFe, an SPCT and Gold partner, I know how to make SAFe better. If you’re considering doing SAFe or want to see how to improve it, see Part IX: Using FLEX to both enhance and simplify SAFe.

As always, happy to chat with you about your challenges and how we can help.

Al Shalloway, CEO, Net Objectives

SAFe® is a registered trademark of Scaled Agile, Inc.


Don’t see an offering in your area? Let us know so that we can see about scheduling one nearby!


Online Courses

Here are online courses and workshops being offered now on Net Objectives University.