Category Archives: Uncategorized

Follow the Energy

At Industrial Logic we have a diverse team that is distributed globally. We are all very experienced software and agile practitioners that have been around the block several times with helping teams and organizations vastly improve the way they work together to build software.

Last week we were away for our annual in-person meetup/retreat and it was phenomenal. I’m writing this on the last leg of a 30 hour trip back home to Cairo and I’ve never been so energized. The next few blog posts will contain many things I’ve learned and relearned.

What I’d like to discuss today is something truly marvelous. It is the idea of “following the energy” instead of following a strict agenda and timeline. If it sounds a little un-professional and un-businesslike to you, it did to many of us. But boy did it make a difference in our results.

Stated simply “follow the energy” means follow your own energy and that of the group. When you are tired, rest. When you’re not feeling it on one topic or task, go do another. When you need to nap, by all means, go ahead and nap.

What this enabled us to do was to bring our WHOLE SELVES to everything we worked on. That means we were fresher, more engaged, and much better able to work as a team. The results were amazing – we completed tasks as a team and took them to completion regularly. And the quality of those tasks were much higher than we would have gotten if we were working on it because we had assigned something to be done.

Now don’t get me wrong, this wasn’t a free-for-all. We had well-defined tasks and we had them prioritized. We didn’t go work on task #10 before we were done with task #1. But what we DID do is agree as a group what we would be working on. And we had a few things that we were doing in parallel. So that if your energy ebbed on one task, you were able to move to another. And if you needed some time to decompress and do something else, it was absolutely safe and ENCOURAGED to do so until you had your energy back and were ready and eager to dive back in.

So, “follow the energy” is one of our new team agreements and we will continue to work that way as a team. I expect we’ll have better results and enjoy doing so much more than we have in the past.

Leave a comment

Posted by on January 12, 2014 in Uncategorized


Use the Product to Build the Team

Most people use the software development team to build the software product.  And that makes a lot of sense.  Begin with the end in mind – focus on the product and make sure that is clear to the team – and they will build it well.  Unfortunately, and unexpectedly, this is painful and ineffective.  I have never seen a team reach high performance by doing that.

Instead, all of the teams that I have witnessed achieve high performance have done something differently.  They focused on the individuals and their interactions; the focused on the team and how they work.  The fact that they had a shared goal – the product – was the mechanism used to Build the Team.  When the team was built – the software was built as a by-product of the focus on the team.

So focus on building the team.  Use the product as a way to build a high performance team.  Do THAT and you will get a great product.  Every.  Single.  Time.

– Thanks Tim and Ashley!

Leave a comment

Posted by on January 10, 2014 in Uncategorized



How Do We Manage Changing Priorities?

There are generally two parts to changing priorities: 1) how they fit within the mission of the team and the project – that is are they really changes that need to be made, and 2) the ability for the team(s) to respond to this vision.

For the first part to be even possible, there must be a clear direction and alignment of the team around the purpose and goals for their project.  That is called the mission in chartering as used by Industrial Logic.  Or, as the shared task, as defined by Christopher Avery.  No matter what you call it, everyone needs to be aware of where we are going together.  With that knowledge, they can review their current backlog of work, change priorities appropriately, and say NO to things that no longer fit in this shared understanding.

The second part, is the technical ability for the team to choose very thin vertical slices of functionality and take those to completion.  Saying vertical slices is easy.  To be able to do them effectively pulls in almost every major skill from the agile toolbox:  writing effective user stories, test driven development, behaviour driven development, working effectively with legacy code, and perhaps continuous deployment.

There are several areas that will affect the ability to manage changing priorities effectively:

1)     Degree of alignment within the entire team.  This serves as the backdrop for all the work we do in the future.

2)     An effective product management group that is engaged with the team.  Product owners must be skilled at creating effective user stories and working well with the rest of the team.

3)    Visibility of current state is important to be able to make decisions about when to change priorities.  This is as easy as saying we will post our work regularly on physical information radiators.  The difficulty is in building the habit that comes through repetition and creating a safe culture that encourages sharing even bad news early.  Tools may or may not be considered at this point depending on the needs of the teams on the ground.

4)    Reduce work in progress and prefer finishing to starting.  This is difficult and also needs a habit.

If you have these two major areas, then you will be able to recognize and respond to change effectively.

1 Comment

Posted by on January 9, 2014 in Uncategorized


Tags: ,

Two Birds with One (Safety) Stone

We recently received a health bonus at Industrial Logic.  Each employee was given $500 to spend on his or her health with two conditions: a) we spend the money by the end of 2013, and b) we report back to the rest of the company on what we spent and why.

At first I was a bit skeptical.  I’m in my mid-forties and have been steadily getting out of shape over the past 5 years.  And I’ve got many failed experiences with diets and exercise programs, although I know it can be done.  More specifically, I had built a running habit that I kept for 15 years and used to have a much better diet – so I knew I could do it even though I have failed to do so over the past few years.

Also, I know what doesn’t work for me.  Gadgets don’t work – I’ve got many unused gadgets.  Gyms don’t work, I’m self-conscious at gyms and don’t really like taking the time to go to one far away.  Diets don’t work, I always yo-yo back.

So all the obvious routes have already been tried and didn’t work for me.  And I just don’t have the motivation or belief that trying the same thing again will work this time around.  So what can I do differently?

Well – I know that if I can build a habit – like the one that I broke with running – then it really becomes easy.  But how?

A bunch of internet searches and a cool TedX video later and I’ve got a plan that I’m working on for health and fitness.  Then I started thinking about all the great ways that this idea – of getting really good at building habits – can help us do a better job at helping our clients get the most out of our products and services.

At Industrial Logic, we’ve been working steadily on creating an Anzen culture – a culture of safety – for our clients and ourselves. One of those ways has been validated learning – i.e. making sure all of our offerings not only deliver valuable content, but result in observable behavior change.  Which is where all the habit work comes in – the best way we know to make behavior changes stick is to form a habit.  And by leveraging the latest in behavioral science, we can really make things safer – and better – for everyone.


Posted by on January 2, 2014 in Uncategorized


Inverting Traditional Approaches to Teaching TDD: A Ridiculously Small Step to Build the Habit

Recently I had a conversation with Ingmar van Dijk who is one of the most talented technical coaches out there, and we were discussing how we can do best for our clients in our testing and refactoring classes.  More specifically, we had agreed that most of our clients are not working on green-field codebases and although learning testing and refactoring skills is a good first step, it is not enough to really tackle the hard problems.

We were discussing how mastering TDD, and making it an everyday habit was a multi-month process for both of us from the moment we were introduced to it, until the time we had the skills and abilities to actually perform TDD on all our code.

And we agreed that this probably one of the major reasons that the technical practices like TDD and BDD are not as widespread in the community.  They are difficult and that impedes them “catching on”.

Ingmar had suggested the idea that we start with the skills needed for working with legacy code FIRST, and then perhaps go back to the intricacies of TDD and refactoring later.  It seems like putting the cart before the horse….   But after a couple of weeks away from the conversation I think he is right.

Think about it – one of the reasons we don’t build a habit is that we don’t have the ability to do TDD on all our code after we are introduced to it.  So it is hard to pick one regular trigger.  But what if we learned a few micro-skills that would allow us to work with existing code first.  And then AFTER we built the habit of writing (very simple) tests for our code before we touched anything, THEN we came back to honing our TDD skills.

This would mean, we would start with:

1) Breaking dependencies in existing code,

2) Creating characterization tests,

3) Build the code in a test-after method regularly.

Then, after the habit is built for testing all code that we work on, we go back to test-first development and refactoring and refine our skills?


Posted by on December 29, 2013 in Uncategorized


Tags: , ,

Test Driven Development and Habits

Habit-forming is my new (short-term?) obsession.  And I’m looking back at some of the practices in agile development and what I can learn from the habit=f(motivation, ability, trigger) equation.

Technical practices – test first development, refactoring, requirements driven development, etc…,  are some of the most valuable practices in our toolbox, yet, unfortunately are the least commonly practiced.  We all know that they are difficult – but is that enough to keep us from doing what we know to be the right thing to do?

The motivation is usually there to certain degrees.  In fact, looking back, the most successful teams are those in crisis and they have really serious motivation to help them go through the huge learning curve (i.e. ability in habit-speak).

And the triggers are pretty simple – write a test before you write code.  Write an acceptance test before you start the iteration.

The real problem here is the ability – it is a really high bar.  If we remember that ability needed and motivation required are proportional – then we need to bring the ability needed down so that you don’t need great motivation.  Here’s what we’ve tried so far:

  • immersion classes (in the early days of eXtreme Programming)
  • training classes
  • eLearning (such as Industrial Logic’s technical albums)
  • mentoring
  • coaching
  • pair programming
  • katas
  • etc…

But the fact is, those things reduced the hurdle, but evidence shows it is still too high.  So, I’ve been thinking, “what ridiculously small steps can we take to help people build the habit first?”.

And since I am currently writing in ridiculously small steps to build my own blogging habit, then I’m not going to worry too much that I don’t have the answer now.  But I think I have a really good question.  And I’ll let my subconscious work on it for a bit and blog ideas as they come up.

But please, if you think this is worthwhile – think along with me.  What ridiculously small steps can we take to make the technical practices habits with more teams and individuals?

Leave a comment

Posted by on December 27, 2013 in Uncategorized


Tags: , ,

An Experiment in Habit-Building

I have a theory that I want to test out and would like to invite you to come along for the ride.  I want to blog more regularly.  In fact, I want to create a habit of blogging – I have wanted to do such a thing for multiple years (maybe you have too?).

The theory is based on someone else’s theory on habit building: Habit = f(Motivation, Ability, Triggers).  What’s cool, is that Motivation and Ability are proportional.  That is, if you are trying to build a habit for doing something trivial, then you need very little motivation; all you really need is a trigger.

So, how do you do something trivial?  Take a ridiculously small step.  Ridiculously small is in meditating for 2 breaths, doing 2 pushups, or ….  Or writing 2 paragraphs and blogging them.  Just two paragraphs.  No reviews.  No agonizing on whether this is the right thing to say or how dumb I’ll look to the reader.

So here we go.  This is the first such blog.  And my trigger will be writing before I go to bed.  That’s it.

Leave a comment

Posted by on December 26, 2013 in Uncategorized


Tags: , ,