Take It To The Team

It is inevitable and tempting that many decisions that affect the team are made without ever consulting the ones that are primarily targeted.  Even if  enacted with good intent.  We still see this on a different scale when the software user was never consulted but significant choices were made in their best interests as well.  Certainly there is a balance somewhere in something that might be too small or trivial and as opposed to another extreme where the user is relegated to insignificance.  Taking choices to the teams and discussing solutions which impact them, is every bit as important as involving a software user.

  • Find out what they think and how they think.  This is a chance to connect and understand; an opportunity for innovation and creativity.
  • Get impact that you might not have considered.  Omniscience is not a human ability.
  • Consider some alternatives and adjustments to the plan from the team. Consider even that sometimes you may not be thinking ‘heads-up’ enough for vision and strategy if this is something the team could/should already be capable of deciding.
  • The team may not get the Last word or Decision – but include them in every step of the way.  They are learning about the organization and processes.  What they elect to change might surprise you and start to shift the organization or process in a better direction.

I wrote up a small Empowerment Quiz considering the posture of the teams I encountered.  Were they defensive? Perhaps timid? Spending time having the right conversations, actions and decisions to become better teams is important for me.  Ever made easier because the team is always important to me.  To be able to represent the team as working on the most valuable work to the organization, that the team’s work was high quality, and that we were adjusting to meet the needs of the user is a great job to have.  That a team is also improving the product, as well as it’s own skills, processes, and tools… even more so.

Shared leadership is a chance to grow and learn in an environment conducive to improvement.  We help each other to be accountable.  We are teaching and learning to see from different levels of perspective.  Being an active part of the solution is far more valuable than swept along in the tide.  The answers we search for and find ourselves tend to be more valued than the ones we are readily given. If there is a decision likely to involve them, before one is made, take it to the team.


The Team Physical Task Board

I was once introduced to a new team which was been practicing agile techniques for a while.  As I listened in on their planning, it seemed to blend with other meeting purposes and I came away with an overwhelming sense that everyone was busy.  Especially the louder voices – which would find something for a quieter voice to do here and there.  The team talked about hours.  There were some stories entered into the backlog, and the team talked about a few of them.  Then the team seemed to wind down and proceeded to get back to work.  This is the time for opportunity and to bring a few basics to bear.  To be clear – I get a chance to explain what I see, and what we can improve.

A vision for making a better team.

There is a coach, Bob Galen who talks in terms of pebbles, rocks and boulders…  relative sizing.  pebbles might be equated to tasks – rocks were something bigger such as stories and boulders might be epics.  The proverbial agile mountain would be layered with all three.  The scrum master has to know where their team is on that mountain.  They may even have to act as a Sherpa and lead the team to where they need to be at that moment.  Is this poker planning where we talk about stories, is this the next-sprint planning where we are listing tasks? The scrum master’s gold coin is the focus of the team.  Are we self-examining? resource-balancing? How does this fit into processes? Are we making our commitments?

No room at the inn?

The task board is representative of a teams’ sprint.  There are other information radiators which will scale larger for releases across several sprints – but I’m just focused on the teams’ sprint task board here.   Some teams do not get the opportunity to have a ‘room of their own’s as Virginia Woolf  would advocate.  Instead of complaining and letting it fall into the ether – use this an opportunity to get creative and feel a bit empowered at changing the physical environment.  A team that can walk into a room and move tables without asking permission is far more empowered.  The physical environment acting as a parallel to the thought universe.  There hasn’t been a place yet where we couldn’t make one.  The most creative by far was one that wrapped around two side of a gigantic square column that was ideally situated right in the middle of the team.  They just hadn’t thought of it as usable real estate and took a lemon (sour or negative circumstance) and started making it work for them.  Take painters’ tape and a portion of barren wall.  Use the hallway or corridor – this IS supposed to be about visibility after all.  Try a window, or a rolling board, but try something. Dont get stopped.  Some teams use idea paint, and turn a section of wall into something they can write on with dry erase markers.

3 vertical and one horizontal line.    Stories (Rocks) | To Do (pebbles) | Doing  | Done

The scrum master helps the team spend time together – working and non working. There is much about a board like this that the scrum master takes note of.  Capacity: What is the team’s average velocity at the story-level, and quite possibly how much is being done at one time (task level).  The manner in which it gets done is also telling.  Is the team working highest priority, and swarming as they need to?  Is the team likely to delaminate and each starts their own story?  When did risk surface from the team?  This should be early on and not the day before the end of the sprint. I have my task(s), is it the best thing to be doing right now? Does it contribute to the story?  Does it help the release?  Does someone need help? Large tasks that sit in ‘doing’ all sprint aren’t helpful.  It means we haven’t performed our agile duty and broken it down into something smaller and actionable.  Quick feedback loops.  Are we all on the same page with regards to the end deliverable fairly early into the sprint or are we still thrashing late in the game? Are we improving our interaction? Is the team getting better suggestions from each other and evolving processes and quality of work?

Visibly working and communicating the sprint plan every day in a light touch is important.  Also – Is the plan working? The sprint burn down is a side-effect.  We don’t complete tasks to make the burn down look better – we complete tasks to get the work to done.  The burn down is simply a reminder like a gas gauge – do we seem to have capacity as a team – if not then we need to adjust the plan.  As a scrum master knowing the records for most amount of tasks they’ve ever completed in a day is an achievement worth celebrating.  It gets the team to think as a cohesive group for what they are capable of.  I had an earlier post: Burning Down Not Out

Finding out the the team is experienced and knowledgeable enough to task and tear all the work apart.  Were there any skills or processes or artifacts that would have made the sprint easier?  The scrum master is out to enable the team and remove issues.  This may even take some time to do so.  With enough attention, perseverance and work oysters turn an irritant into a pearl.  The scrum master can even look back on the sprint task board and see how many new tasks were added.   – This is the team learning about what it takes to get everything through the organization and into the customer’s hands.   Always with an emphasis on making the customer delight and re-engage with the experience of how we collaborate and what we deliver.  Some teams may need to call out the preparation for the review as a task for completing a story.  We always want this to be light weight and not overly prepared – more go than show, but some conversation and preparation contribute to a successful review.

We have a plan, and the team has confidence enough that together we can adjust and deliver the work.  What is the team’s confidence in their own plan? Are they engaged and an active part of it or really just waiting around because they know it is doomed to fail.   At the end of the sprint, our plan is pretty much thrown away and the team is left with feedback for how well we problem solved, and worked together to accomplish all of this.  The teams are earning trust by working on high priorities for the business.

Color coding by stickers or by post it’s is often used to convey stage of tasks, if the tasks were added after planning, who might be responsible for a task, or even priorities.  Getting used to Capturing the conversations IN THE MOMENT is an art in and of itself.  It is the lightest weight meeting.  No one leaves with extra cleanup up to do.

Moving a story to Done.

Though tasks are moved by the team – the person doing the work, Teams often like stories moved to done as a ceremony by the product owner.  It conveys they have reviewed and accepted the work.  The product owner should not be surprised by what they see in a review.  The scrum master often acts as a conscious for the team and may probe for definition of done compliance. Especially if this sprint was a new level-up in terms of delivering to the expectations of the organization, role, or the team itself.  “Did we have unit tests completed?”   The team will thoughtfully answer, and we trust them.  Questions should never provoke a team into a defensive posture.  If they do – this is a signal that something else usually requires a bit more investigation and fixing.  Physically touching the work isn’t just an arts an crafts thing – it hits us visually, we feel it, tactile.  This is representing our work that we move with progress from left to right.  It is a visual indicator which radiates information about where the team is at and heading towards.  Within the context of the group – we accept we will make our work visible.  The team talks during the stand-up around the physical board.  Others from outside the team are even invited – but usually don’t speak until after the team is done. You might even judge a successful stand up by the number of break outs that happen AFTERWARDS.   As a team we are also endorsing accountability.  There are some strong proponents for ‘HOLD ACCOUNTABLE’ but I will often say “HELP ACCOUNTABLE”.  Not everyone is good at asking for help, or seeing a possible solution because we are heads down in activity.  Together we rely on each other as a team, and strive to balance in doing the right thing the right way.  No one is perfect every day.  The group together helps, picks up members who might be down, and gets motivated about completing the team goals.  Ever continuously improving to work better and together.

The More Mature Teams

I am looking for everyone in the team to participate.  Problem solving what is needed to get the work done.  This critical thinking is an opportunity to teach and visibly vet what is needed.  It also ends up being a plan for the team.  The team will adjust the plan as it needs to.  This is about driving out risk and unknown.  Teaching the team to be better and better with reliably representing their capability to the organization. Making commitments to the business and customers.    Load balancing the team resources, thinking ahead and envisioning the end game at a couple different levels.  Does this align with our goals for the sprint?> How about our larger goals for the release?  Are there any dependencies we need to address early? Is everyone stepping forward appropriately? Is there some swarming behavior?  Are we focused on the tasks that get the stories to done or are we instead focused on hours which really obscure whether something is simply done.  If you have all that and are a great team, and want to move to electronic forms of tasking, then do so with blessing.  Go faster, improve processes.  Just bring with you the practiced behaviors that you developed together as a team.  Distributed teams rely heavily on this to keep connected. I look for a team to pop – their communication includes each other, their plans for the day are intertwined.  There is a great side effect of having teams like this in every organization.  It is force enough to move mountains.

Scrum Master Series: Team Maturity

There is no doubt that a scrum master’s role is seen as a leader.  A leader should also be prepared to adjust their leadership style to provide what the group may be missing.  This would compliment the team.  Other times the team might be best served by capitalizing on their strengths and instead augment them.  Yes, there may also be times when the team is so empowered that for a short while they may be almost invisible; sharing the leadership with others. A scrum master might consider being lenient with some processes in the cases where the team is showing respect for the agile principals.

A Scrum master will grow a team.  Keep the team and the organization continuously improving.  The ability to identify where a team is in its maturity will help.  To be clear, a team’s maturity has little to do with the time spent together and is more about the characteristics of the team.  How do they interact?  How well do they tackle some fairly thought-intensive work?

Bruce Tuckman described 5 phases to team formation.  All these phases required common tasks or goals for the team to align with. While the product owner’s abilities lay in the analysis of unfolding information; the scrum master’s job is to facilitate the team’s transition through towards becoming more mature, shaping the interaction.


Here the scrum master is a trainer.  This group of individuals may be seeking acceptance and may feel relatively uninformed.  Being more directive while members of the team seek acceptance and start orienting themselves.


Still as a trainer, the team may be expressing some dissatisfaction as they test limits and boundaries.  Many different ideas are competing as they form acceptable leadership behaviors.  How the team deals with conflict will stop them or help them move onward.  Does the team focus on minutia or avoid real issues?  How is time spent?


Now as a coach, the scrum master is helping the team integrate with one another. The team has a goal and a mutually derived plan.  Some of the team members may have to acknowledge and help champion an idea that was someone else’s or perhaps even contrary to their own. All done towards achieving the group goal.


Now as a Mentor, the scrum master is seeing the team produce.  The team has a rhythm and perhaps even a swagger as they operate smoothly and are able to problem solve effectively without much conflict.  There is a high trust among the team members.


Things with beginnings also have an end.  Having closure, ending, celebration, recognition and reflection are all part of this cycle.  If the team delivered, celebrate and recognize the team for the win!  Not every ending is ideal however.  Say that a team has worked 6 months to deliver a product, has a sustainable pace AND met their deadline but the product is never put to market by the company.  There is no closure to the goals that have been the vision of the team for so long.  Motivation will certainly be affected.  It might take a while to get going again.  So too the loss of a team member… even one lost to promotion.  Keep visibility and an openness as teams deliver or maybe even wind down projects, deprecate portfolios, and assign applications to obsolescence.

Being an eternal peacemaker within the team might even inhibit a team advancing from norming to performing.  The largest caveat here is that the journey is not always a linear one.  The team can revert or be thrown into ANY of the stages for a time.  Maybe a new member has been added, or a particular stressor has the team acting differently.

Another way to look at a team’s maturity is to gauge the capability and characteristics.  Every team has it’s own unique identity, and watching an agile team work is  organizational behavior.

12 Criteria for measuring the maturity of a team

  • Feedback Mechanisms (poor -> excellent)  Does the team adapt? How long does it take to adjust?  Does it revert to a defensive posture when questioned or is it more reflective and thoughtfull? Does the team possess and agile mindset where they exhibit iterative, time-boxed and incremental improvement?
  • Decision Making Methods (dysfunctional -> functional)  This is bad when a head is locked up in a little view or single perspective.
  • Group Loyalty / Cohesion (low -> high)
  • Processes and Tools (inflexible ->very flexible)
  • Use of Member resources (poor -> excellent) Does the team exhibit swarming behavior? Is everyone efficient and effective?  Are we challenged and utilized?
  • Communications (unclear -> clear)  Does the team talk? Can I hear them? Does the team participate and help inform the organization? Are they visible with information radiators that are up to date and aligned?
  • Goals (unclear -> clear) The Product Owner will answer what is next, while the team will be able to explain their vision, how we will get there, and how we will know if we are there yet.
  • Problem-Solving Ability (simple -> complex)  Does the team stall out when presented with a challenge or do they forge ahead?  Are the solutions brittle or robust?
  • Participation in Leadership (low -> high) Is the team engaging, challenging and growing the organization around them.  Great teams have and influence others and benefit those around them.  What about outside the organization and in the community?
  • Acceptance of minority views (low -> high) are the quiet ones considered or even invited to speak?  Is is just one person’s opinion again and again? What about all the different perspectives that might use or even abuse this product?
  • Standards (low -> high) Is the quality of work high?  Are there defects or rework that make others avoid this team?  Is this team’s work readily accepted and meet a definition of done that sets a new level of expectation.

Just remember that where your team(s) might be,– is just the start of where they might go.

Scrum Master Series: The Team

Definitions and Back to Basics

Once in awhile I get to look back over some of the notes I put together on topics.    I think about organizations, teams and roles that we have.  Once in a while I have to lay the justification to an organization for one of the roles.  A scrum master included.  For a few people in the organization, as I take them through their valley of disbelief, I like to start very simply, and sometime include some history lessons along the way.  Dr. Winston Rice, the father of waterfall wasn’t all bad, but over time we learned to organize ourselves in even better ways.  New ideas in an organization that is pretty big and set in its ways is never easy, but I love watching the transformation.  I have the patience to see the changes and continue to grow and support the people who are experiencing it as well.

I had a developer say to me that they hated agile.  A very clear and aggressive message with an emotional anchor.  All pre-formed before I even got to know this individual or what his prior experiences were.  I love what I do, and it shows.

It’s not about you.

Organizations are dedicated to using teams.  This means what?   A team is a group of people… pretty basic.  But wait, there is more!

  • Holding themselves collectively accountable
  • For using complimentary skills
  • To achieve a common purpose

Scrum does not assume a minimal skill set.  There is also an assumption that the work is complex enough to warrant a team. Ralph Douglas Stacey who spent a career analyzing organizational relationships had a Matrix which might be adapted to agile as follows…Stacey Matrix

Scrum tends to play really well in breaking things up from chaos and pulling them down into the complex realm, and again pulling complex solutions down into the complicated.  Scrum for it’s simplicity cuts through the noise.  Kanban tends to work really well with simple or repetitive solutions we find ourselves performing again and again.solutions down into the complicated.

Why a team?

Well, it has the tendency to be good for people.

  • Improves our creativity
  • Can make better decisions
  • Can increase commitments to action
  • Help control their members
  • Helps offset large organization sizes
  • Types
    • Formal vs Informal
    • Temporary vs Long Term

In groups of a certain size we no longer feel lost amidst a very large organization.  Daniel Goleman who wrote Social Intelligence was curious about the maximum number of people to exhibit innovation in groups.  What he saw was natural pairing in groups of 2 then 4 and somewhere greater than 8 the groups tended to fracture and not be as cohesive.  Greater than 8 we don’t collaborate as well.  Seems right in line with what individual scrum teams are used to.

What can Teams Do?

It does seems obvious that we use them to develop software.  Our teams place an emphasis on making or doing things.  Team might also exist to recommend or just run things as well.   I get into teams more and more in the coming weeks as this is really where the scrum master matters most.  The team might be considered the scrum master’s product.

I will end with some immediate Dangers to a team.  Again this is always tricky with people who can have selective hearing. As a basis for evaluation in order to really make decisions with steps towards getting better, there are several terms which apply to groups becoming dysfunctional.

Dangers to a Team:

  • Social Loafing – complacency.  It is GREAT to have fun (There is an awful lots of stress and hard work)  but this points more to appropriateness within the context of accomplishment
  • Group think – the team actually loses its ability to think critically and is making decision from a defensive posture within the organizational hierarchy.
  • Social Facilitation – behaviors that start to become acceptable in front of others.  Teasing and hazing are such examples.
  • Personality Conflicts
    • Antagonizing relationships
    • jeopardize team accomplishments
  • Disruptive Behavior
    • Interrupts the group’s processes
    • Limits the teams effectiveness
    • Impacts the team’s cohesiveness

I have never called out an individual as being an impediment, as I tend to distinguish and separate behavior from a person.  There are certainly some behaviors I don’t care for and wont be helpful to a team.  One of the ways to focus on the good part of being within a team is to call out your working agreements.  Together as a team establish some guiding principles of your own.  There are quite a few examples and it has the tendency to put everyone on the same foot forward as they will come together against some tough thought problems.

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!

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.

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.

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.

Happy Birthday Team

Birthday cakeWelcome to your team. A new one is forming, storming, norming, performing, and yes, adjourning or re-forming as we speak… somewhere.  Bruce Tuckman wrote about the stages that teams go through.  In the agile world of software we do the work a little differently than we used to.  We also grow and enable teams – after all, these are the groups of professionals that do the work!  Ideally they will encompass and deliver everything it takes to get through the organization and into the customers hands.   More today than ever before, companies interview not only for a candidate’s technical ability, but their grace in problem solving AND their fit for working in teams.  Emphasis is placed on the constant ‘connectedness’ and the clarity of communication.  The team you are going to be a part of is typically included as part of the interview process.  There are lots of reasons why we form into teams.  To prevent ourselves from being lost amidst a very large organization, to have a common sense of purpose, make better decisions… and so on.  At it’s core: A team is a group of people holding themselves collectively accountable for using complimentary skills to achieve a common purpose.  I wanted to leave myself a few notes as I again become part of a new team.  Especially concerning one that may be new to agile or scrum software development.

I think it was the movie Princess Bride where the giant had trouble in fighting the man in black only because the moves used in singular, one on one interactions are much different than those needed when you are facing many.  A gang, a pack, a team, somehow we have a small group of people that for many reasons, are together in this.  

Seek the Wisdom.   Be straightforward, but the wisdom in doing something often is not.   Sometimes not everyone is ready to receive so realizations can come at different times. We typically want to do the right thing.  Even the right way, if we know how.  When presented with an idea, listen, consider, and explore the possibility of what people are trying to understand.  It shows respect, and many times we learn from the encounter.  It helps us practice being flexible in our thinking.  This will be the greatest resource you bring to the team.

Mind the Balance. Asses for impact. Is the effort of  simply trying something a little time to learn something.   Typically the all or nothing is a false dilemma. Sometimes we build vertical slices up through layers of architecture… sometimes we build a little architectural runway.  Be comfortable in seeking the Mark that is Twain (between the two).

Be a time traveler.   Often I find myself in the midst of a conversation between two people that strongly disagree.  Then the perspective and context comes in, they are both really talking about the same thing, only from different points in time.  The ability to alter your perspectives, build from one to the next, and right size the work so that it can be done in deliverable increments is learned.  Practice makes it a skill.

Go forth into the Org.  This speaks to being empowered.  Very few teams are islands.  The ability of a team to exist in some environment, requires being able to forage, communicate and align.

Be a Constant Gardener.  Have patience for growth. There is also implied weeding (maybe refactoring),  feeding (celebrate small wins and improvements),  reflection (retrospective moments), and even cross pollination (shared experience and lessons).

If you’ve not heard of it, there is a race called the Sawtooth Relay.  Take a team of 6 and some volunteers and divide a 62 mile course through the mountains into 12 legs.  I was part of a new team that took on the challenge.  I wasn’t even part of the original team.  I took someone’s conflict and stepped in to fill the gap.   To this point I have never run more than 6 miles in my life.  With the relay, I would run two 6 mile segments in the same day.  I took someone’s difficulty as my own challenge and opportunity.  It even meant a 1400 ft elevation change along one of the segments.  This team had never run together, no one had been in the race before, and none of us had run this distance.  We started at 3:30 am and everyone simply amazed me as we each ran our leg and contributed.  After all was said and done, I ended up with and additional 3rd leg of the race.  One runner on our team had to pull up with a painful injury.  We were all concerned and thankful that a week later there were no lasting effects.  I got to both start and to finish the run – which I think to be a great honor.  Our team came in under the 10 hour mark – which to a person, we thought was very successful for what we collectively hoped to accomplish.  I myself, appreciated several things about this new team!

We had individuals from different teams across a software program come together as a team for this event.  This was a great chance to continue growing our cross-team communications.

We shared the truth – we were honest about what hurt, and shared every thing we could to help.

We did it by the rules – we took to heart the honesty and integrity that everyone even the 304 other relay teams and the 5 individual Ultra runners (who ran the whole 62 miles) were striving for.

We savored EVERYONE’S encouragement and help.  Especially if they weren’t on our team.  (Running at night, my headlamp started going out, and another team loaned me one of theirs…  My appreciation for help in a time of need goes way beyond words.  We in turn encouraged others. We went out of our way to  keep each other motivated, and share the experience.

We celebrated the achievement and this meant special appreciation for the volunteers without whose participation we would not be allowed to run.

We adapted our processes and adjusted how the team operated.  Sure we made a few mistakes, but none of us felt halted by them.  There wasn’t enough time to dwell on it and angst or anger wouldn’t have been useful anyway.

I look forward to doing better!

This will be a reminder to myself as I again become part of a new Agile team.

  1. This is about doing our work differently
  2. Cherish people  but don’t just associate, achieve together.  My day is ever better when I have learned something new AND I have been productive.
  3. You are part of a team for a reason, and just as you are unique, the team will have it’s own personality.  Like any seed needs sunlight, water and soil,  teams need space, support, and empowerment.

Can you hide in a team… sure… Leave your grumpiness, your bullying, and your defensive insecurities elsewhere… we have work to do.

The Worst Teams

  1. Always find an excuse, never fault ourselves. Can’t be corrected.
  2. Miss the opportunity. Don’t use the chance to improve… may be heads down in activity – something always breaks, but never look up, learn, level up.
  3. Never venture beyond and out from their comfort zone, like program contributions, or even cross roles.  We isolate ourselves.
  4. Have fun only by criticizing others. Stereotype and make blanket statements, leaving criticism without specific recommendations and even better.. a willingness to help.
  5. Have no urgency.
  6. Leave mayhem behind that other teams don’t want to clean up.  Management may have  to smooth interactions over.  Never becoming truly become aware of  our impact.

The Best Teams

  1. Don’t stress, aren’t defensive – they are forward looking.
  2. Have some fun and celebrate the achievement.
  3. Help each other grow.
  4. Give honest feedback.  We are also honest with ourselves.
  5. Learn something new.  More importantly they teach others.
  6. Exhibit a fearlessness in exploring. They TRY IT.
  7. Have a tempo which allows urgency and thought-full-ness.  It IS possible to show urgency for some things and patience for others.
  8. Adapt – Accepting the situation and weigh the impact to implement recommendations.
  9. Think at different levels, context switch, or time travel.
  10. Make whatever we touch better – improve.  Innovate, create, surprise…
  11. Are calm problem solvers.
  12. DELIVER.  Higher quality.  Higher standards.  There is no hesitation for representing what anything is really like.


The last two miles of the Sawtooth Relay I will always remember…  The penultimate mile was painful, and the more I concentrated on the pain, the slower I got and the pain only increased…  That Last mile I focused instead on going faster… pushing myself.  My pace increased, my running was lighter and smoothing out, the pain went away… I finished knowing I poured myself into the moment and gave more.  The accomplishment pushed past the limits I knew for myself,  it made me proud to be part of the team. More so, as I knew others had done the same.