Test Driven Developement

TDD, ATDD, BDD… were all pretty much alphabet soup.
These acronyms were flung around with the accusatory context that they weren’t being done.  People actually started developing ADD 🙂
Test Driven Development, Acceptance Test Driven Development, even  Behavior Driven Development.  I’ll cover some of the TDD aspects today.
I never liked coming in saying nothing was being done.  Maybe it’s just my style, but if a child is learning how to walk – it doesn’t do much good to simply yell “right foot – no, NO, you’re doing it all wrong”.   Instead it is far more effective to stand beside them, share in the moment with encouragement and recognize their wins.  Capitalize and keep moving with small improvements to become better and sustainable.

 In teaching TDD – there are just the three steps –

1) create a small test.
2) create the code to pass it.
3) Refactor the code/test.
This works at the unit-test level, the test case/functional level, even an automation level.  Is this all you need?  of course not.
But starting somewhere means something actionable and not just a complaint hanging in the air over a team to be lost in the nether.
I liked the many levels of insight and wisdom that Kent Beck had in his book (below) on why we want to do it this way.
Write the test first.
We are breaking it up into smaller pieces…. If the test is hard to write – then maybe the architecture should change.
we converge on the expectation. The test once created is run and expected to fail.
we know what it takes to pass.
we are not afraid of seeing an expected failure.. we learn to explore them. fix them
Write the code to pass.
We refactor if needed.
Get rid of duplicate code.
We have had a small success.. easier to move on AND we learned something.
We move on to the next small test.  If the test doesn’t pass then there isn’t much required in order to get it working again.
Also called ‘moving to the green’. – (red would be fail)
I also like a three pronged approach.  Coming at any problem from multiple, supporting lines of attack, usually assures a solution.

1) Just don’t throw a book at someone – help them to practice it.

There are some really good books and depending upon the level of the tester or developer.  I liked the Wesley Signature series.

There is no problem making the topic a book club, lunch-n-learn or a topic at the Community of Practice.  In stressing actionable, try actually suggestions from the team on where/when to DO it. Emphasize the action and not the complaint.  Perhaps it depends how receptive everyone is IF we are breaking bad habits, right? Don’t look back at all the legacy code.  Start today and move forward.  Today’s features and Today’s backlog items.  Time spent converting is not always fruitful.  To convert legacy code you may actually be trying to replicate bad architecture, and none of which gets you to the features your customers may want today. If you have a story that takes you into legacy land – that is the time to improve it.  Bring it up to our definition and expectations for done in alignment with backlog priorities.


(this should be number 1) right?)  For instance – Are the testers having a whiteboard at the beginning of the story on how it will be tested so that developers are on the same convergent expectation for what being done will look like.  Are there overlapping or redundant areas of test coverage between what we will do for unit and functional tests?  Are tests finished before the code – and code will get them to pass? Is anybody waiting? (a bad sign – there is always something that needs to be done or could be improved)  Can test automation be useful is creating example data in a developers environment so they can run and see the tests pass themselves? Can test automation created to prevent the excessively long hardening periods our organization has? Here we have code, test cases, test automation all developed at the same time. The proverbial vertical slice that is focused on delivering the story.  Do teams still put in unit tests as an afterthought?… the coverage is there, just not the correct sequence. Develop the unit tests first and watch their impact on how the architecture emerges.  Something very difficult to pass should tell us something.  By the way, consider using the unit tests for integration points and not always just trying for coverage.  Also accept that 100% coverage is very difficult and while the teams balances appropriately, list how you will cover exceptions.

3)Keep it simple but improving

What do the teams have today that we can leverage and improve.  Are we re-using tests, unit tests, code example libraries, test cases or test automation? Are we creating a thousand point and click here… or did we need just a few of those ‘beginner/training/ cases and most require some knowledge of the system and hit the bias paths and main workflows?  We are considering tactics and strategies on how to test the work. Without making the test harness a product itself (unless that IS your product … Selenium, Cucumber, etc.)  Testing augments the quality of the product the customer gets. The working deliverable is created more efficiently, making the team agile and faster in delivering it.
Celebrate the leaders, early adopters and achievements with recognition.  Scrum masters might even ask the team if they completed the tests first.   Think of easy metrics to make efforts visible and that point to improvement. There may be signs in velocity, type of work, fewer bugs and hotfixes… etc.  Lines of code usually decreases because quality is higher.
As ever, stay agile.

Empowerment Quiz

“Do you feel empowered?”

This is a question a scrum master may look for and even ask directly of an individual or a team.  The emphasis is usually on the teams as a group feeling able to go out and change the world.  There is something very active here.  Solutions don’t always find their way to you as you sit back… you actively have to seek them out and influence their outcome.  There are many types of POWER…  In 1959 an article by French and Raven pointed to types of power between people being based on:

  • Coercion
  • Experience and Expertise
  • Being guarded about Information
  • Legitimate role or position
  • Referent or acceptance seeking
  • The ability to grant Reward

Yet the best way to think of a definition of power is simply the ability to influence.  Can you truly influence a person, solution, process…?  In some areas we have more ability to affect whatever is before us.  In standing back and self-examining at an individual, team, or organizational level, I might ask many questions.  Each of which might be answered yes or no and support or detract from a perceived influence and being truly empowered.  What are some of the questions that resonate with you?

Here are a mix of 50 questions that might come to mind:

  • Can you purchase a tool or software package to try it out?
  • Do you have the ability to purchase a book or have access to e-books with relevant topics.
  • Did you learn something new this past week?
  • Do you feel your opinion is heard?
  • Is your suggestion or question being constantly interrupted before you finish?
  • Can you try a new process?
  • Do you find yourself actually holding back from making comments?
  • Is everyone on the team participating? … Or is it the same one or two people on the team who get heard?
  • Can we move the furniture, put up information radiators on the walls and generally change the physical environment? 
  • Did you feel productive?
  • Was the customer proud of the teams solution?
  • Were you making suggestions that improved how the team worked together or even solved a particular problem?
  • Do you feel that your co-workers are constantly criticizing everything?
  • Did you contribute to something in the agile community outside of the organization or team?
  • Are you able to teach others in the organization?
  • Does management ever attend any of the team stand-ups and is interested in what the team is doing?
  • Does it feel as if you aren’t trusted to do your job?
  • Did you see something that made you think “wow” or “yes!” the past week?
  • Are you proud of your contributions? your team? your organization?
  • I’m worried about what others will think?
  • Are you working on the same thing that you worked on last month? -in the same way?
  • Do you feel the organization recognized you?
  • Was the team rewarded for its accomplishments?
  • Was most of my time was wasted today?
  • Why am I always thinking I am not very good at this?
  • Is it easy to walk over to another part of the organization and enlist their help?
  • Am I isolated?
  • Does the organization continuously seek outside for best practices and know why?
  • Did my team offer to help or include another part of the organization?
  • Is the customer excited about the software and collaborates often?
  • Do I feel burned out and that the pace is unsustainable?
  • Do I think we are working on the wrong things?
  • If you ask for something, how likely are you to actually get it?
  • Do you feel as if you are growing and gaining experience?
  • Did you have the opportunity to be creative or innovative in some way?
  • Does your manager regularly set aside time for you?
  • Are you an active part of the solution?
  • Do you remember the last time you laughed?
  • Does the team interaction seem forced and awkward yet?
  • Do most tasks feel like a check box?
  • Did I thank someone recently for something that really helped me out?
  • Do I feel supported in my role by a couple different people?
  • Can I truly look back over the past few months and see how much more agile and improved we are today?
  • Are we making more work than we are delivering?
  • Am I able to repeat and understand what our current vision is and the goals which align to them?
  • Do I constantly receive or seek feedback from people?
  • Can I walk into a meeting room or office when the door is closed? …And I’m not on the invite list?
  • Can I say that my team ROCKS?
  • Am I focused and really want this to be the best solution for the customer?
  • Is this the best team I have ever worked with?

 … And as with any super hero/heroine – use your powers for good!

0, 1 or Many…

In uncovering better ways to solve problems, we often examine how we think. Sometimes we are even ‘too close to the experiment’  to realize that we might have missed something small or large just outside of the current scope of our attention.  It is part of the implicit trust that we, as part of team, not only seek feedback, we consider it from everywhere in order to get at the best solutions.  In the case where a third party is being talked about in absentia, I usually like to circle back to the person who was not present.

   1) It’s much more fun to involve the person about whom you are speaking. What can I say? It’s the coach in me.
   2) Whether it was good or bad, this is the same reason.  It’s feedback, simple as that.
3) When it’s praise, this is reinforcement and recognition. When critical, then it’s alignment, impact, adjustment.

The critical conversations tend to be learning times for the both of us.  There is also a series of books out there about having these crucial conversations.  It is a chance for me to learn and individual’s thinking, reasoning, motivation, and not only how they communicate but how they interpret as well.  Sharing feedback builds trust, and in larger contexts of the teams or program, brings the perception into reality and better measure the impact. Collaboration, Communication, Convergence – none of this happens without trust.

The best job on the planet is one where we can get paid by contributing both productively and creatively; while learning and growing.  The productive means not only in time, but that the solution is usefulmeaningful.  To be creative means that I can bring something of myself, something reflective, thought provoking, unique.  Any learning augments our contributions.  

Zero, One or Many…

Some one had his code patterns all figured out. Zero, One or Many he would say.  This method will interact with exactly none, one or many objects.  As thought provoking as that is for a moment.  The thinking stopped; and it is only a matter of time before the criticism of the product of that thinking will set in.  How about code quality – what about the undefined or indeterminate?  We should have error handling for bias path escapes.  What about ‘Many’ and the sense of scale?  Typically many would mean everything.  The code would show it’s inflexibility when we needed to SCALE.  Inclusive, exclusive, sets, limits and constraints all prove that there can be priorities when processing everything.  Even security attacks exploited this with Denial of Service distractions to limited resources. The questions became different, could we limit to the first 1,000 in order to save valuable computing resources? How fast can we change to correct or improve our code?…  Conway’s Law postulated that the code reflected the social structure of the organization.  He could see it.  Being a product of our thinking, it will reflect how rigid, or how flexible our minds are.  Communication (thought interface) affects and is affected by our organization every day. How flexible, how agile will we become and how long before that shows up in our solutions?

I heard a coach once tell me of his proudest moment.  His son came home from grade school and started in on his homework.  He said, “You know Dad, everyone at school is always telling me WHAT to think.  You taught me HOW to think”.

The Emphasis on the Impediment

I got into a conversation with a coach once about something which had blocked progress.  We usually call these impediments and the goal is to make them visible, and go after them to remove them from being such a problem.  I wound up considering a few things along the way.  Even though this particular problem was already resolved, the emphasis from the coach still fixated on the problem and the problems it caused.  Though we retain this as experience, it still caused some emotion for this particular person.  I tend to emphasize the solution and action of the solving.  Since time immemorial history favors the conqueror or problem solvers, the tactics used to overcome obstacles.  The obstacles themselves are temporary.   The labors of Hercules, Alexander’s Gordian knot, Alan Turing and the Enigma Machine, Rutan’s White Knight and SpaceShipOne winning the X prize…

Can you go around, over, under it, or iterate through time?

Ender’s Game has a zero gravity room in which there really is no up or down – just an orientation around where the problems are.  Kids are left to explore that context and find different ways of getting around.  Context and situations, call for different strategies and tactics.  Exercises like brain storming, or using the five whys are now often intermixed with daily activities instead of separate and distinct activities with the teams.  We are developing individual and team skill sets as we don’t just ‘go get there‘ but instead ‘grow to get there’.  We can never go fast enough, we are never truly ready, just perhaps we are ‘ready enough’ with the resolve to continuously improve.

Why so much focus on the problem and then simply walk away?

There is a bystander effect which can indicate the cohesiveness of the group.  Many simply find it easier to by remaining a critic.  In the critic’s voice you get to be part of an elite group that establishes a hierarchy over some other group.  Active participation, suggestions and alternate solutions are far more preferable.  The best teachers share. The behavior to get ramped up and even show emotional venting doesn’t strike me as productive and often hurts the situation.  Switching over to better adaptive behaviors to solve problems should be emphasized. Have the calm and experienced understanding to move through it with a state of grace.  Teams should be problem solvers, the best solutions do not come from being defensive, panicked or fearful. They come instead from drive, passion, creativity, inquisitiveness… If you want to continue to foster this in your environment, then some recognition and reward is also important.

Can a person be an impediment?

I have always separated a person from their behavior.  I like people! There are some behaviors I don’t care for. I don’t list a person as an impediment. It’s too easy of a stereotype and doesn’t tend to solve the problems we are having. Selecting a scape goat or  blame and then walking away is not helpful.  Role assignment, support, responsibility,  processes, visibility, convergent expectations, aligned goals all are things that might help.  Things we can TRY, and still continue to move forward.  A person however can solve the problem, a team even more so. Very often techniques like the five whys left us in silence where there was no longer deeper knowledge to draw from.  It is often hard to bring a context you have never experienced as a possible solution.  We speed up this process of extrapolating solutions from experience by communicating ideas in a group and sharing that richer set of contexts for the entire team to draw upon.  We even communicate in abstract development patterns and have some pretty common ones.  Sometimes we bring in architects, subject matter experts or coaches depending upon where the impediment exists.

In the movie Ender’s Game, Ender winds up with someone on the team who steps forward and tells Ender he doesn’t even know why he is there. The two boys don’t even like each other.  Ender’s reply is that he is there to make the team better and responds with his own question – Is he wrong?

The Indirect Goal

I am very grateful to destiny for introducing me to rock climbing.  These indoor climbs are ascents to the top of a building wall which can be 40 feet high.  Routes can also range in difficulty by type of grips and techniques that must be used.  Some climbs leverage ‘naturals’ or the surface instead of being all hand holds.  I have just done this a few times and already I see some great things about being able to take away and bring into the agile context.  We ever talk about scaling mountains of problems in an agile way…

Pair UP

Not all facilities are auto-belay.  The belaying is often done with a partner which can put the brakes on the rope you use to climb.  This also makes for a great trust building exercise.  Trusting not only in someone who literally holds your safety in their hands, but in the equipment that you’ve checked out as well.  Your partner is also someone who can call out advice for holds you do not see, or a technique that does not come to mind.  The same happens when we pair program or pair create tests.  How quickly can we think upon the problem at hand and continue to communicate as we develop the solution.   Climbing is after all a physical problem to solve.  Plenty of other people have been up this same route without fear, or hesitation.  How did they do it, what hold is next?  Programming is thought work, and every so often I may find myself thinking ‘let me go work on this and I’ll get back to you’.  It mostly means I am not being flexible towards teaching, learning or sharing in the solution right now.  We become a better team when there is trust between the climber and the belayer who holds the other end of the rope that will catch you when you fall.  In pair programming we trust in the patience, focus, and desire to solve the problem at hand.  The climb to the top or even just the next handhold.  Sometimes we just need a bit of motivation as physical exhaustion starts in during some of the more difficult climbs.  Even then I am an active participant invested in the success of the reaching a goal.  Even if I am not the climber I am learning technique from occasional climbers which are more skilled, sharing with climbers less skilled or simply challenging one another as equals.  Challenging with the intent to grow ourselves into better climbers, programmers, problem solvers…

Focus Near and Far

It happens occasionally.  I come across an complaint or gripe about the program, or a team, or even an individual.  It takes hold and we focus on the can’t, what we are NOT doing, or the 100 critical questions that halt us in our tracks.  Distractions abound.  Sometimes I have to remind myself of the end goals, sometimes I need to focus on the next hold or step.  Motivators come at different intervals.  That interval often depends upon internal needs and external perceptions.  If my progress is quick my focus is usually far, If I feel stalled out or blocked then it is the single next step I am looking at.   We can all use help now and again with our tempo, and sometimes it comes with experience and consciously striving to improve every single time. Everyone is present to make the team better, adopt the best solution, create the best software they need it to be.  If you stall on a climb on a hand hold, it is a matter of time before strength gives out.  We are repelling back down eventually to go after something easier, or simply recharge.  We are still the better for attempting more and more difficult challenges.  Learning something every time we do.  The practiced ease which turns learning into reflex allows us to learn even more beyond what we were taught.  Alternate between near and far and use each to their advantage.  How far might far be?  We cannot see the sun directly, but by it all things are seen.  How about not the next climb but the next several.

Continuous Improvement

Climbing routes are rated for their difficulty.  They start out around 5.4 and work their way up to 5.8, 5.10, and 5.13… A 5.4 would be easier with larger and numerous holds to grab and step upon.  A 5.9 might require much greater finger strength, some varied techniques, and perhaps simple physical endurance.  Climbers are usually practicing to move up into the more difficult climbs.  Developers and Testers do the same thing as well.  further into the architecture to improve it and make subsequent work far easier and more robust. Further into different areas of testing to qualify and characterize the software at different scales or more quickly than we had the ability to do before.  What techniques have we added to our experience to draw on as we move to the next climb, be it a release or a sprint?  Maybe it wasn’t a skill so much as a process.  If you started with a fear of heights, then isn’t the goal to simply gain enough experience that the fear is crowded out by continuous perception, reasoned evaluation and finally smooth execution?

A Target Indirectly Hit?

I want better teams, better practices.  Does the ability to pair program fall under a near term goal that will improve several things if this is done well?  Several small techniques to practice and on the whole the interaction and the ability to tackle more complex problems becomes apparent.  It is usually why agile stresses breaking down into actionable, move forward steps.  The experience helps us as we continue onward into the more complex. Then the focus at times flips from those who cannot climb fast enough to those who might not have taught others fast enough. A sense of balance, timing and care is ever critical when climbing on small holds up a vertical stretch of wall or mountain.

“Character cannot be developed in ease and quiet. Only through experience of trial and suffering can the soul be strengthened, vision cleared, ambition inspired, and success achieved.”       Helen Keller, who was blind her entire life, knew exactly what a clear vision truly meant.  It enabled her to climb past the obstacles that seemed directly in front of her and not only live, but also influence the direction of so many other lives.

The Gift of Time

TEMPUS FUGIT.   It is a Latin phrase I’ve seen on a headstone in England.  Time Flies, or even flees.  It runs and escapes from us.  Our word ‘fugitive’ is derived from fugit.  In wanting to be the consummate agilist we can often find ourselves flexible enough to ask whether a meeting is worth it or not.  Granted there are certain times when it may not be.  We can cut short the meeting perhaps even cancel the meeting.  In essence, give some time back to whom it would have otherwise tied up. Perhaps we can refocus or re-purpose a meeting since we have some other high priority thing that needs our attention. Let’s do that instead. Maybe this meeting is really overhead and duplicates the purpose of some other meeting… can we simply stop the overlap and reduce these into a single meeting.  How often do we meet? is this daily, weekly, bi-weekly…  For many companies a meeting is 60 minutes.  Some did not consider a 50 minute meeting to provide for group transitions to the room and bio breaks.  What about a 30 minute group meeting?   The daily stand up is only about 15 remember? We did this as a standing meeting so that no one would get too comfortable and sedentary in thought.

Caveat, or in other words, ‘beware’.   Tempest is derived from tempus.  Watch to ensure that short term gains do not accumulate at the cost of longer term objectives.  Though it can be appropriate to cancel a planning meeting are we should be watchful the team is not storming around some not-so-well-formed stories in a future planning session. Will we ever think of doubling down on planning meetings in order to get beyond 1 sprint ahead?  Will we know something of what is coming so that emergent design doesn’t devolve into emergency design.  Another problem may be too many cancellations actually cause nobody to take this meeting seriously and skip attendance when it eventually is held.  Sometimes that repetition is a practiced cadence so that we can spend some box of time to work at a process need.

Other ways to give the gift of time…

Can we improve a process so it is easier, automated, or more robust? Did I leverage what others may have done?

Can we be mindful of our own communication and impact on others? Are we distracting or enabling others from focusing on the right things? Perhaps there was even a lesson learned that I might share to make a task easier for them.

Can I help someone or swarm with others on a task that will get this work to done?

Did I make myself available to someone who needs my help? In the same way, did we make our work visible enough or leave behind just enough artifacts to make this easier for the next team?

Is this a sustainable effort?  Can we maintain our pace with priority commitment through time?

And lastly – Did I give something back to the community?  What contribution, lesson, or insight can I share that might help others?  It could, just maybe, save them some time.

Agile Particle Collider

Take a particle from it’s box. Now take a few more from each of their boxes and collocate then into a single box.  They are at times bound to collide into one another.  The smaller the box, even more-so.  Now take a team of people and put them into a time-box.  To get any where the team needs to move in the same direction, coordinate, and establish some agreed upon destination all while making concerted effort to move. There is bound to be collision, and some will call this conflict.  What if instead it was merely agitation towards alignment – would the terminology make it any less opposing?  What about the state of the particle? Did it trust the particles around it? Did this particular particle not bond or perhaps was in a high energy state that made it very volatile, radioactive and cause some decay…

Assuming even none of these problems, and as part of an agile effort we have a loose collective of particles. I have seen two particles – or people argue and I had to interrupt them both with a laugh…  they were really agreeing with each other (quite vehemently) but neither paused to consider the context from which the point came.  The perspective individually allowed for both of them to be right… How?

Thinking and Communicating Context

Are we at the same perspective or level? – details, tasks, stories, epics, product, portfolio.  Maybe role, team,  program, organization, community.  Possibly impact, resources, scope, priority, knowledge, risk. What about minutes, hours, days, weeks, sprints, months, quarters, years?  The aforementioned argument had two different time contexts in mind.  Both had two quality concerns but one was for today, the other was for for the next several sprints.  It was a false dilemma that both their solutions would be mutually exclusive.  Check out a list of errors in logic sometime.   Poisoning the well, hasty generalization, shotgun argumentation and Nirvana fallacy are common enough.  Both people were absolutely so focused on delivering great software that they overlooked a few things that might have made their collaboration easier.

Needs Drives Behaviors.

I always like people.  There are some behaviors I don’t care for.  Some thinking can be changed… some can’t.  Is it responsive behavior, or deeply ingrained personality, – what level of thinking is it? At times I want to drive back to the motivation, and though I cannot always address it, if I understand what is going on, I am far less fearful and far more effective at suggesting and taking some course of action to make it better. At times this is my imperfect perspective at what is happening and why – but then I tend to over think things at several different angles.  Some movement forward is as important as the right direction. I look to myself to balance things gently, observe if they have gotten better or worse.

And In All This Communication – Did We Forget To LISTEN?

This is the other side of the coin.  There is a GREAT book by Mark Goulston called Just Listen. In it he also describes the various layers to our own mind.  From the reptilian, reflexive, primitive to the higher functioning and cognitive. Some times we are so bent on ourselves and proving a point that we forget the simple courtesy of allowing others to speak to their concerns. We loose the ability to influence others if we were to stop, shutdown, and disengage.  We also forfeit our own opportunity to grow.

When many people get together and have a passion to create the best software possible, they can always have collisions.

Mutual respect for everyone’s craft, expertise, and human being. By ‘being’ I mean our ability to learn and grow.  A human been, as one college professor liked to say, has assumed room temperature.  Allowing someone to grow by necessity includes a certain amount of forgiveness, of forgetting. Things and people moving at the speed of agile – need themselves to be dynamic, and would be unfair to hold them to a static view.  Just like for the organization – it is the rate of change we are measuring.  So in all of this we remember every once in a while to keep our heads up.  Heads down activity all the time does not always allow for continuous improvement or learning.  Taking the time to make the software, the tools, processes, team, or organization better.  There needs to be some balance in all of this.

When these are opportunities we should take hold of them.  Looking ‘oppositionally’ at each other across some problem chasm is never as effective as standing side by side – looking in the same direction and solving it together.  That latter achievement together will build trust, and allow us the chance to collaborate at a dozen different levels.

And at last – if you have to let off some steam – Find creative ways to wash over it.  I have known teams to use Rockem-Sockem robots, Fuzeball, paintball, or a lan party to get past something pent up and laugh.  Any interrupt to our communication is just another impediment to be gotten around and moved past.

Preventing Team Delamination

One of the things I watch out for inside of a Scrum team is delamination.  (Dela wha?)     It is not a Scrum term. – Rather, as I often tell stories by analogy, it is a term I use to describe a behavior.  The term ‘lamination’ comes to us from the Latin language. So it’s been around awhile. It is the method of making a material by using multiple layers, so that the resulting composite has much greater strength and is structurally more stable and sound. By using layering, we get something better.  A laminate also usually bonds together through pressure and heat.  The definition itself sounds like a team with cross-functional roles that is put through some rather challenging work.  Delamination is when all this bonding starts to fall apart and the layers start to separate again and come apart in different directions.  The team in essence diverges.  Typically this is along the thin laminations, (or by analogy) the roles that the teams is comprised of.  Are the developers ahead and working on different stories than the testers?  Is half the team complaining at how slow the other half is? I try to discourage this in teams – as it is together, that we the TEAM will fail or succeed.  What comes to mind is a list of things to look at when we might be facing some delamination.  When we want to keep from pulling too far apart and stay together. Typically it can be the developers that are running a bit ahead, but not always.

Flip how we do the work.

  1. Many developers realize that a good practice is to do the unit tests.  Many also have the tendency to put these last just to complete the ‘coverage’ as a cleanup thing to do.  Do the unit tests first.  Kent Beck had a great book – Test Driven Development: By Example in which he goes through explaining his thought process as he does the unit tests first. He explains the ‘why’. If the unit test is hard to write – he considers that the architecture itself might be too complex and much better off for being simplified so it is easier to test. For testers this often means NOT ever waiting until the development is done – But getting the tests done first and vetting those with the team so that we are all on the same page about what we need to deliver and how it will work.
  2. Some teams will do a whiteboard session in first days of a sprint where the devs and then the testers take turns walking through a deeper analysis of the work, where the risk is, where the verification points are. The roles overlay and vet the algorithms and the edge cases together. Maybe we set some plan for when tasks fit together during the sprint.
  3. Consider everyone on the team a software developer.  We all have our specializations but no one should be left behind.
  4. What can we let go of?  Are we really doing testing that is based on risk and impact? Is the process large, rigid and cumbersome?  What if we are making ‘look and feel’ changes to a user facing document – do we really need to regression test the application that autogenerated it?

Teach me / Teach you

  1. What is covered by those unit tests?   are we overlapping? is some of this testing redundant? or even unnecessary? Are we testing integration points, regression?
  2. Are you using Different Tools, environments? How did you do that?
  3. Increase the Skill sets on the team by teaching something that the team needs – maybe that is SQL or scripting, or whatever.
  4. Take an interest in what the developers/QA are doing.

Enable or help out, this is a team effort

  1. Help develop the functional test automation
  2. Make the daily stand up more of a problem solving plan for the team than an individual status. Focus on the tasks that need to get done and swarm on them. Help out the people that may have difficulty in asking for help, letting go or breaking it down.
  3. Make the application or service more testable.
  4. Look ahead and start grooming some of the stories that will hit the team. This is different than accepting more work – this can be vetting the acceptance criteria, the sequence, or the dependencies for the work so that the team can estimate these more easily.
  5. Bring in more organizational skill sets into the team.  Ideally this work is potentially shippable – and will encompass everything it needs in order to get through the entire organization and into the customer’s hands.  This might include a technical writer, a graphic artist, a system or security specialist.  These roles may also benefit from continuous improvement or help us to integrate what we do to make this the Right software done the right way.
  6. Help another team. Is there someone else that is having a difficult sprint – ask around maybe at the Scrum of Scrums.

Better Quality

  1. Buy down and dig into getting some of your technical debt done. A refactor of some legacy code that is always brittle or tricky to make changes in will make future changes easier and less prone to mistakes.
  2. Address Bugs – typically, most of these are validations that require little time to verify AND make the product better. I shouldn’t need a test case to verify a spelling correction.
  3. Stabilize or improve a process. Perhaps this is something for continuous integration, admin of virtual machines, or the automated smoke test?
  4. Did you perform code reviews, pair program, help review test cases, or develop the artifacts necessary to train and educate others?
  5. Get in there and help test! – learn the tools and processes. Let’s all finish this before we grab another.

Remember, we are trying to become better ourselves at estimating what work the team can deliver and be completed at the end of a sprint.  Also, I will say I have witnessed many GREAT teams pull together where it never felt like delamination was taking place. High performing teams are not just sitting idly around – but neither are they always leaving work half finished at the sprint boundaries. Sometimes is OK, and maybe it is ABSOLUTELY appropriate to get started on that last important piece of the feature or shippable increment.  We just should make certain we can answer if the team is together on this.  They’ll most assuredly be the stronger for it.

The Fierce Urgency Of Now

This title is a quote from MLK.  It reminds me that time can burn and consume like a fire.  With the awareness that something needs to be done, we are challenged with taking action. It is the underlying motivation, logical reasoning, moral compass or character which will sustain that action should it meet opposition, resistance, impediment or chaos.  Anger can be a great short term motivator, but even Lincoln noticed that he destroyed an enemy every time he made them a friend instead.  How does an organization or an environment change?  The answer is usually one person at a time.  Having an optimism to be able to do that is what Powell called a force multiplier.  Going even further, in order to strengthen individuals we form into teams.  Larger or smaller – groups scale, coordinate, communicate, and converge on goals.

How is your organization organizing?

Valerie posted about having the right reasons to adopt scrum.  It makes worlds of difference since everyone’s active participation gets a team to the goal, the winning side of the struggle.

Just like a sustainable pace – Is our Vision sustainable?  This is the end goal, the proverbial chess endgame. What is our progress? Is this realistic? How quickly do we just give up or remain the armchair critic? Did we truly give it everything we had and then some? What did we try?

I once was with a team for a sprint planning session.  The scrum master led them through a visualization exercise for the sprint.  What would have to happen to get the work done.  Bit by bit with a few more questions, all the tasks, the order, the priority, and a plan emerged for the next two weeks.  The team was charged, energized and started the next day with diving right in.  On day two the plan fell apart with a problem the team didn’t expect.   Some people left with a memory that the plan failed.  Instead the plan was a start and the REAL wisdom was in a different spot.  Not the ability to follow a plan, but in the team’s ability to adapt, adjust and overcome.  With experience the team becomes better at critical thinking, and hence makes better plans.  What if this happens at the organizational level with leadership plans?  Does it all just fall apart or do we have a great team with the trusted ability to adjust and adapt?  We are out to improve not only the capacity but the capability of organizations.

How many times will we need to turn inwards and answer ourselves with a clear and immediate response that this effort is indeed worth it? If this is every day then it better be a VERY good answer.  An organizational ‘gut check’ for the proverbial fire that inspires us all to work towards that result.  Improving ourselves, our craft, our community.   A process shapes interaction.  Sometimes we grasp onto and leverage it just like another grip in scaling towards a mountain top.   Especially when we get scared, we can often cling and hold to it.  Moving nowhere until we are left so exhausted that we simply give up.  To change a process takes something else; a continuous desire to move towards something better. To improve upon our position we look for some purchase, or hold that affords us better (ad)vantage.  Teaching someone a best practice isn’t enough.  Without any investment, curiosity, willingness to participate and improve this is a check box action at its best and is still just a facade.  Even the Shu, Ha, Ri maturity model suggests something a bit better.  Emulate, Learn, Teach.

A Scrum is not always a pretty thing.  Prepare for it.

Watch one sometime.  Learn the Rugby analogy we use for software development team.  This is huge effort to move past a mark against an obstacle, a direct resistance.  The effort allows the team to take the ball and run with it. We train for it, participate in them, and improve upon our ability to perform them.  Be prepared to deal with problems and conflict and enable the team and organization to move towards resolution, mitigation, acceptance, or displacing the burden, even taking some iteration at a combination of any of these.  Melville said that if continual success is proof that one may wisely know their powers,–it is only to be added, that, in that case, they know them to be small.  There was never any risk to grow beyond where we were comfortable with control if we didn’t fail somewhere. Minimal frameworks tend towards maximum exposure.   Also, without the right supports things crumble away.  Care and maintenance are aimed at supporting an existing level.   What supports are a team, a program, or the entire organization willing to put in place to make this not only sustainable but incrementally better? Are we out to change the reputation of the company – or perhaps this is simply a side effect.  What can we let go of? Was it control, discomfort, or visibility into our vulnerabilities or insecurities?  Did we just move around the problem spots or did we instead reward and emphasize and grow our strengths?  Did we settle when it became someone else’s problem or did we make it better for everyone?

The wisdom at WHY we do all these things is found in the ability to answer ‘why’.  It is at the very heart of everything that gives us the willingness and drive to get close to the problem, be able to engage and grapple with it.  Where does your answer to ‘why’ lead you to share in a dream?

Team… Engage.

This morning I did something different – I helped out in unpacking and preparing a hot air balloon for flight  (I KNOW!) .  As part of the crew I was prepared to give chase, then retrieve and pack away this lighter than air flight class of transport.  The pilot used air currents to do a giant vertical circle.   I  learned a few terms such as assembling the A-block (part of the harness from the balloon to the heater) and snaking the balloon – which turns out to be some work.  Once the balloon has touched down and has emptied enough to lay horizontal on the ground – there is still a lot of air in there and you put your arms around the throat of the balloon and walk backwards gathering together the fabric and squeezing out the remaining air.  All, in order to pack it away until next flight.  What also was interesting, was the pilot’s intense focus as the balloon landed.  The landing being the most important part!  They may not seem to notice and or reply as they near the ground if a few of the people shout upward and want to chat.  They may be completely focused on making the landing.  A good thing right!

A Team Can Do More

It caused me to wonder about our interactions as teams at different levels – Just like that hot air balloon seeking different altitudes to use the different wind directions at those levels to  it’s advantage.   Is the team’s focus always on just bringing the sprint in for a landing?  Just like at the individual level, a team can often ‘phone it in’ and not always be in the present.  Some teams seem to work well all by themselves.   However, a team can also show leadership, initiative, and continue to stay engaged.

Agile is an Active Thing.

Are we growing, learning, AND reaching out to teach and learn from others? I have had the opportunity to work with some REALLY great teams.  At times I have scrum masters and product owners so focused on their own team’s less-than-ideal behavior that we forget to look around.   Share a story with another team.  For a single sprint we shared a planning, a daily stand-up, a review and a retrospective with one of the better teams on the program.  This ‘pacing’ was a way to learn some good practices, keep communicating across the program, and get familiar with the people on another team.

Leaders Come From Great Teams.

A team – is it actively reaching out not only to take on work, but is the team showing a leadership among all the teams in a program?  A team that is responsible and consistent is usually trusted and reliably so.  Program leaders come from such teams.  They recognize what really works well.  The abilities to be visible, communicate, correct, and all those non-resume’  skills that cause us to consider what is valuable to the organization. These are the teams reaching out to the customers, working with (not against) the business.   Making the right software.  Are the individuals on your team seen as being an active part of the direction of the program?  Is your team learning, growing, and changing the environment around them.  Are we instead, just biding time, sullen and silent.  Maybe bottling up some resentment until so much pressure accumulates and simply bursts through “full of sound and fury”.  It is why we emphasize the actionable to align and transform that energy into something deliverable.

Opposites – Aren’t Always Attractive

It is always the extreme questions which I might flip through now and again in order to place a bit of emphasis on what we should do.  Because behavior is in the extreme, the actionable answer may need to balance out such things as:

  • Is the team creating story half-lives… always splitting off another several stories from an original and working continuously on a single original feature?
  • Is the team always using criticism as a crutch to push back accepting any work at all?
  • Does the team always prefer to be long-winding instead of short, concise and emphasize action and doing?
  • Is the team too quiet, mostly browsing the web all day, or never to be found?
  • Is there always an excuses and they don’t even look each other in the eye every single stand-up?
  • Do other teams hesitate to  dive into the past fixes and work this team has done because they know it will need extra care and effort?

Great Teams Engage!

Any team that engages with the program, engages with other teams, engages with other parts of the organization, adopts new tools to be more efficient, recommends and tries process improvements, helps other teams with architecture, pair programs or code reviews, will prove itself to be influential and valuable.  Speaking of the work – are we only able to do one type of work?   The team that has a variety of skills and wants to learn has many more options when the work in the backlog can be so varied.

Looking up from the work we are doing is a good thing.  Scrum can be a type of disruptive innovation – making us hold something just a bit until it is appropriate, or even time-boxing the investment of our focus on a particular level or piece of work.  Just as we look up now and again to ensure that the work we are doing is done well, we look to see if it makes our sprint goals, contributes and aligns with our release goals.   Look across to see if any other team is floundering a bit, because if they fail, then the release may fail, and it doesn’t do any of us any good as a program.  If one team fails, don’t we all?  How early can we adjust or indicate the risk involved and move to mitigate, accept, or

We value the ability to adapt over following a plan. We are working on making the teams great problems solvers, achievers, and yes, leaders.

Knowing what needs to be done and rolling up your sleeves to become an active part of the solution.  The  ability to navigate at any level. That is the magic of being engaged.