RSS

Monthly Archives: January 2014

Our Most Effective and Least Adopted Practice

27 Jan

Test Driven Development is one of the most effective practices from the agile community of practices, and also one of the least practiced regularly.  Why is that?  Why, 15 years after it’s introduction to the world via Kent Beck’s eXtreme Programming Explained, is one of the least adopted practices in the community?

Test Driven Development is One of the Most Effective, Yet Least Adopted Practices in the Agile Community

After years of practicing it and teaching it to others I have a few ideas on the subject.

First of all, Test Driven Development takes time to master.  It is conceptually simple, however, practicing test driven development on existing code, not written for tests tends to be very difficult.  And for some reason, even though there are some really great, and simple, techniques out there for working with legacy code (most prominently Michael Feathers’ book by the same title), people tend to be unaware or unpracticed with the well-known and well-documented techniques.  This means there is a skill-gap in using test driven development for existing, untested, code bases.

Most Developers are Unaware or Unpracticed at TDD Techniques for Code Not Written With Testing In Mind (Legacy Code)

Then there is the problem of the current way TDD is taught in the community.  We, the coaching community usually teach TDD on toy applications built for a classroom situation.  And students leave the classroom having learned the basic skills of TDD on greenfield applications and unable to apply them in their daily lives with aging code and tight deadlines.  The techniques of working with existing code are usually considered advanced and not broached until teams become practiced with the basics of TDD.  Unfortunately most teams don’t become practiced in TDD because they cannot apply what they’ve learned in class to most of their regular work.  Finally, although there are a few workshops out there where coaches teach TDD on their clients’ live code, they are by far and large the minority.

Most Students Leave TDD Training With The Ability to Practice TDD on Greenfield Applications Yet Their Day-To-Day Work Is On Legacy Code

For those lucky few, that learn TDD in a class, have follow-up coaching afterwards as they begin to master TDD in the few cases where it is possible, and advance enough to learn how to work with legacy code effectively there is one last hurdle. You need to make TDD a daily habit.  And making TDD a daily habit is easier said than done.  Even well practiced developers, who have been doing this for years, spend roughly 40% of their time writing tests and 60% of their time writing production code.  For those new to TDD, if they want to create such a habit, they will need to spend the majority of their time writing tests, not production code, to make things stick.  Add to that the existing deadlines.  Add to that managers that might become worried as velocity drops.  And, add to that, our own critics in our head that start to get worried that we are spending much of our time writing tests. To make TDD a habit, given such a large step size, we need an immense amount of personal and team motivation to make it part of our day to day lives.

Making TDD a Habit Requires Sustained High Levels of Motivation

Finally, if you learn TDD, get coaching to apply it to your existing code, are excited enough to sustain the levels of motivation needed to make it a habit, you have one final hurdle.  You are dependent on the rest of the team.  TDD is a brittle practice.  That is, we all need to be practicing TDD on the team to succeed.  If I write a test, and someone else breaks that test and does not fix it, then the TDD habit isn’t going to last.  Also, if I am the only one writing tests on the codebase, and my colleagues aren’t, we won’t ever reap one of the great benefits of TDD – a safety-net of tests that enables us to refactor regularly and changes the cost of change curve for our project so that is affordable to make changes late in the game.

TDD Is Fragile – Success Relies On the Whole Team Practicing

With all this stacked against us: a big learning curve, ineffective training techniques, a need for sustained levels of high motivation, and fragility, it is no wonder most of us in the Agile community do not practice TDD. We need a new approach to learning and practicing this most valuable of skills.

We Need a New Approach to Learning TDD

I’m not writing this blog as a lament; I’ve been working on parts of the puzzle for a few years and the last piece is now sliding in place:

Training: TDD is a difficult skill.  Teaching it effectively even more so.  We need to reconsider how we train TDD.  The current method has proven ineffective. We need to either go back to the old XP immersion classes which jam-packed a team into a shared workspace for 2-weeks of intense work, or we need to start teaching legacy code techniques at first encounter – preferably on live code – so students can transition to daily work after class.

Teach Legacy Code Techniques In Introductory TDD Classes

Building habits: the latest research on making practices into habits gives us new ways to be more effective in transforming the way we work.  One very effective technique is to take ridiculously small steps to reduce the levels of motivation needed and build the habit first.  Once the habit is there, then we can layer-on sophistication and complexity.  Specifically to TDD, we need to find the smallest possible step – an MVP of TDD training – that we use to build our habit first.

Design and Use an MVP of TDD Training

TDD fragility: Because TDD needs the whole team to work together effectively, we need to create a culture that encourages individuals on a team to write tests regularly.  The work I’ve been doing with Steve Peha on agreements-based culture is an effective way to make that a reality.

Leverage Agreement Based Culture Techniques To Get Full Team Participation

By putting those four techniques together we can, as a community, start benefitting from our most effective technical practice.

 
Leave a comment

Posted by on January 27, 2014 in Culture, TDD, Teams

 

Tags: ,

Safety – Easier Said Than Done

19 Jan

Safety.  Number two on Maslow’s Hierarchy of Needs – right after eating and breathing.

Safety.  The primary focus of Alcoa’s famous rise from the ashes.

Safety.  The gateway to excellence in software development.

(Lack of) Safety.  The first of the four invisible impediments to high performance teams.

Safety.  Something that is completely internal.  Some people feel safe in a burning building.  Others are afraid to walk across a busy street.  In the last year, our focus at Industrial Logic has been safety as a gateway to excellence.  And the more we explore, the more it resonates.  The more it is surprisingly true.

For me, I’ve had a really long weekend.  I made a mistake at work that upset one of my colleagues and may have negatively affected our standing with a client.  Bummer.  It happens.  But it was the weekend.  And I’m 10 timezones away so it has taken three days for us to get together and talk about the problem.

However, since Friday morning I’ve been stressed.  I haven’t been able to focus.  And I have used a huge amount of energy to continue doing work that needs to be done for an upcoming deadline.  If I weren’t feeling so unsafe, I’d have been able to focus and would have been done by now.

And the interesting thing is, I know rationally there is nothing to worry about and even if there was there is very little I can do at this moment.  But my rational mind doesn’t mean very much to my emotional fear.

So, the question is, how do you feel safe?  How do you readily get from feeling emotionally unsafe to relative safety?  For me, it has always been (relatively) straight-forward: I man-up and face my fear.  If I’ve upset someone I pick up the phone and have a conversation.  If I’ve broken something, I do my best to fix it.  And so on and so forth.

But what works for one person, doesn’t always work for another.  And what about when you find yourself in my position this weekend when something isn’t immediately fixable or that person isn’t available for a conversation?

That’s what I’ll be focusing on over the next two weeks.  I’ll be reading up.  Having conversations with people who know this much better than I do.  And learning to more effectively create safety for myself and share what I learn with others.

Because Safety really is important to our work together.  And without it things break down and we become so much less effective than we can be.

 
Leave a comment

Posted by on January 19, 2014 in Uncategorized

 

Tags: , , ,

The Four Invisible Impediments

15 Jan

There are 4 common blockers to achieving high performance:

  • Lack of Safety,
  • Lack of Respect,
  • Lack of Ownership,
  • Lack of Intention

Each of these key ideas can be stated simply:

SAFETY

The extent to which I feel I can be myself in my work; say what I need to say; do what I need to do; and be accepted for who I am.

RESPECT

The extent to which I regard others as human beings and not as “types” or “things” that are keeping me from getting what I want.

OWNERSHIP

The extent to which I acknowledge that I am responsible for my results and my experience; I do not find fault, nor lay blame; nor do I act solely out of obligation.

INTENTION

The extent to which I am clear—with myself and others—about the results I want to create and how I want to create them.

Notice that each of these ideas is 100% internal.  The extent to which I am clear.  The extent to which I regard others.  And so on.  One of our biggest mistakes is externalizing our safety, respect, ownership, and intention.  Once we internalize them and consciously choose them, we are in the a much more effective position as an individual, and as a member of a team.

You can read more at http://cultureengine.net.

 
4 Comments

Posted by on January 15, 2014 in Uncategorized

 

Follow the Energy

12 Jan

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

10 Jan

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

 

Tags:

How Do We Manage Changing Priorities?

09 Jan

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

02 Jan

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.

 
2 Comments

Posted by on January 2, 2014 in Uncategorized