Scrum and Kanban

We run across informative books that tell us just a bit more.  Henrik Kniberg and his coauthor Mattias Skarin  have just such a publication with Kanban and Scrum – Making the Most of Both.  It is a great reference with many examples.  When I started having individuals and teams and ask for the differences between Scrum and Kanban, I wanted to help them by explaining the impact of choosing either. Once I was sure that a team didn’t just want to adopt kanban in order to hide from a scrum master, we were ready to explore the impact of going with one, the other or a mixture of both (Scrumban).  The 3 columns below were a reminder for making a good comparison.  The choice however also included some consideration for the organization and where we ultimately wanted to grow. Hopefully it serves to help the conversation you may have with that team along their agile journey.

scrumkanban1

scrumkanban2

scrumkanban3

Start with Retrospectives

Never stop experimenting

  • Fear vs. empowered
  • Mistakes vs. failures
  • Continuous Improvement

Feedback +/- Long vs. Short

  • Too Long may make it hard to find a root cause
  • Too Short may cause thrashing with no process stabilization

A Short History of Kanban:

1950’s Edward Deming a quality focused statistical process control person form the US is in Japan doing work for the Government.  Taichi Ohno who creates the Toyota Production System (TPS) is similarly working on Just In Time (JIT) and Lean Manufacturing methods.    Kanban results from this crucible of ideas in time.  Both Edward and Taichi die in the 1990’s when Lean Manufacturing is gaining popularity in the US.  Kanban means ‘signal board’ in Japanese.  It is a tool to help drive out waste.  A pull of inventory and work is preferred over a push.  The signal board helps to communicate work in progress and the state of this work.

Muda    – ‘waste’

7 kinds of waste are identified [They still hold relevance from a manufacturing world to an IT world – Read the book “The Phoenix Project” for more comparisons between the two]

T – Transportation [Today I put this in terms of COMMUNICATION TRANSPORTAION – how many emails, tools notes and days have passed rather than just stopping over or pairing up and getting it straight]
I – Inventory [maybe this is license usage, capacity, ]
M – Motion [meetings that weren’t useful]
W – Waiting [Time, feedback lags, process completion]
O – Over processing [duplication of effort in code, replication in different tools or the organization]
O – Overproduction [producing things the customer didn’t want and didn’t align with expectation]
D – Defects [!!!]

Mura     – ‘unevenness’ – [making the peaks and valleys a bit more level with shared resources or load balancing]
Muri      – ‘overburden’ – [still speaks to sustainable pace today]

A Short History of Scrum:

In 1986 Ikujiro Nonaka and Hirotaka Takeuchi write a reactionary paper called the “New NEW Product Development”.  In it, they note that the team behavior that works best is very scrum-like.  This is in reference to the sport of Rugby.  In the 1990’s in the US, Jeff Sutherland and then Ken Schwaber, start experimenting with software development teams and keep this inspirational terminology.

Advertisements

Red Rover, Red Rover The Waterfall Cross-Over

There are still teams running waterfall.  For certain processes – waterfall may work just fine.  For software development, however, this is becoming a rare sighting.  The paper written by Winston Royce in 1970 described a process for getting software through an organization.  The term ‘waterfall’ itself would be coined 6 years later.  We often joked that a point of no return would come and the software would often be pushed off the ledge and into the customer’s hands.  The customer very often saw it for the first time after several months or more were spent hidden in the depths of the company while it was being created.

“But Agile will make it Worse”

– of course it will silly.

Even Shakespeare said it so long ago.   The fear of the unknown causes us to stick comfortably with what we know. Even to fight to hang on to what is comfortable and familiar.  Change and the unknown “…puzzles the will And makes us rather bear those ills we have Than fly to others that we know not of? Thus conscience does make cowards of us all, And thus the native hue of resolution Is sicklied o’er with the pale cast of thought, And enterprises of great pith and moment With this regard their currents turn awry, And lose the name of action.” – Hamlet

Fear stalls and halts us.  Often adapting scrum after running waterfall causes initial chaos, and will make it worse -> because problems will be uncovered and exposed.  We then rely on the teams, THE PEOPLE, to solve those problems. It takes a certain thinking to be agile, to work in teams, and to continuously improve.  Fear doesn’t help any bit of it.  To be agile denotes an active participation in moving forward through some obstacle laden terrain.  A waterfall allows us to sit back relax and simply be swept away by a current until it is too late. So, HECK YA! Get excited about seeing those problems.  Unless we get to the truth and start solving them – we won’t be getting any better at this.

There is never a perfect time to adopt a better process, -there is only now.  

Ever in the middle of a release, or just having negotiated the large requirements for the next release – a program may have reluctance to change.  The risk,  may seem too high when all our requirements for the next six months have our customers in lock down and bound.  Running with agile teams has a certain side effect that you cannot discount.  Besides the numerous ways agile actually REDUCES your risk, your organization is now investing in having some great teams.  Over times these teams will change the characteristics of the organization.  In his book Scaling Software Agility, Dean Leffingwell spends his entire second chapter explaining why Waterfall doesn’t work.  Just after that introduction to agile methods.

Knowing how fearless most quality assurance/testers have been on some of my teams I have come to cherish plain words.  The ability to simply tell it like it is.  Just the facts, while NOT stopping here. It is another starting point.  It always helped to dig into the problem and start moving towards a solution together.    The wisdom in the tests wasn’t to say the software was broken and throw it back over the wall.  Instead it was in the collaboration of multiple roles seeing it at the same time, making it a better solution for the customer who needed it.

Once you are tired of falling off the waterfall in an anachronistic organization, paddle on over and take a climb up towards the peak of an agile mountain.  You may need a Sherpa to guide you, but the advantage is absolutely stunning. Build great teams focused on delivering great software and then build an organization that enables that ecosystem to thrive. All the while, connecting with and earning the trust of your customers. What more might there be to say except…

Red Rover Red Rover.

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.

Forming:

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.

Storming:

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?

Norming

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.

Performing

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.

Adjournment

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 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 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.

Respectfully Real

Dilbert Drama Queen

Respect for the Individual is a part of my company’s culture and a huge part of my personal belief structure. When I was a kid and would get in a fight with my siblings my parents usually took the “stop your fighting now; kiss and make up” approach. So, as I grew up and entered High School, University, and the workforce, that was the approach I would most often take; if I saw conflict arise I would encourage the parties involved to stop fighting and “kiss and make up”, as it were. What I’ve come to understand as a Scrum Master and Agile Coach is that conflict is not always a bad thing. In fact, in order for self-organized teams to reach their fullest potential, conflict is necessary.

I was first introduced to this concept by Lyssa Adkins and Michael Spayd at the 2012 Scrum Alliance Global Gathering in Atlanta. They were leading a break-out session entitled “Embracing Conflict: A Systems Intelligence Approach to Conflict Facilitation for Scrum Masters, Coaches & Leaders”. There I learned that there is a difference between Productive Conflict and Unproductive Conflict. In essence, Productive Conflict is issue-driven, where the conflict is centered on a disagreement on how to address a given need, whereas Unproductive Conflict is ego-driven. This was a fascinating concept to me at the time – that there exists a type of conflict that is not only okay but should be encouraged! Despite their masterful instruction, I still struggled with this as I naturally shy away from any form of conflict. I’ve gotten better in the year and a half since I heard this message, and would like to share some advice from what I’ve learned.

Ask Why

I have a son who is almost six. He can drive my wife and I crazy with what she refers to as “Whyarrhea”; he asks “Why?” so often that it’s as if he has no control over it. I fear that my colleagues may feel the same way about me! I always want to understand “Why?”. Why did you choose that tool? Why are you producing that metric? Why are you having this meeting? Why are you working so many hours? You get the idea.

People who feel compelled to do things without understanding why they are doing them scare me. So, when I see conflict arise in my team, I start asking “Why?”. I want to get to the root of what they’re arguing about, and I don’t stop asking “Why?” until I get all parties to the same root problem. Once I understand what they’re really arguing about, I get them to explain their contradictory solutions so that we can all weigh the pros and cons of each. Once each solution is explained, I ask what it will take for us to get to a consensus, be it a proof of concept, cost/savings analysis, weighted requirements matrix, etc. I remind them that the solution doesn’t have to be perfect, just good enough.

This approach doesn’t work if the conflict is ego-driven, and this root cause analysis, logical solutions approach will reveal Unproductive Conflict fairly quickly.

Ask the Stupid Questions

I come from a background of software development, but I like to act like I don’t sometimes. If the team seems to be chugging along without any kind of disagreement I may throw a wrench in the system by asking something they might consider being a stupid question. “How are you going to test that?” “Why don’t you do it this way?” “I heard about this Open Source library we could use, why don’t we try that?” These questions are good at introducing Productive Conflict in one of two ways. First, I might strike a chord that resonates with one of the team members who didn’t want to speak up at first, thus bringing out a beneficial conversation that might not have otherwise taken place.

Second, the team members may find that they agree on a decision but not for the same reasons; by trying to answer me, they may find that there is an underlying factor that they disagree on which may impact implementation details or future decisions. Without the “stupid question”, this realization may have occurred much later down the line, if at all. Some may think that not ever revealing a disagreement is a good thing; what they do not realize is that the conversations that those disagreements create and the consensus that results makes the team much better than they would otherwise be. The sooner we can make that happen, the better.

Solicit Ideas prior to Conversation

What is the point of Planning Poker? Most people will tell you that it’s to prevent influencers from running the show when the team is estimating the work, which is definitely one of its major benefits. Without something like Planning Poker, the timid on the team would be left to accept the estimates of the bold, resulting in a lack of ownership and some rather passive-aggressive Retros when commitments are not met.

This concept can and should be extended to other realms as well. Use this when picking a tech stack. Discuss the need first; make sure that everyone understands what the purpose will be behind whatever language, library, or tool they will be picking. Then let everyone bring their solution proposals to the table, with everyone revealing their recommendations at the same time. This gives everyone a voice and produces conversation that might otherwise not have happened.

Separate Ideas from People

Great, high-performing teams embrace Productive Conflict because they don’t associate people with their ideas. All ideas belong to the team, and no person is belittled because their idea was not chosen by the team. This is difficult for many people; it is hard to have your idea rejected without feeling rejected as a person. You can help by referring to ideas by a name or title appropriate for the idea, such as “Spring” or “EJB3”, and not “Bob’s idea” or “Susie’s suggestion”.

You can also reinforce the team’s ownership of ideas by congratulating the entire team for a job well done when ideas are successfully implemented. We succeed or fail as a team, not individuals. If an idea isn’t working out then let’s fail fast and do something different; it does nobody any good to dwell on the fact that the idea was so-and-so’s to begin with. The conversation that led to the decision to implement the idea should have involved everyone and ended with team consensus. That means that, by the end, it was the team’s idea, not one person’s.

Respectfully Real

My CIO, Karenann Terrell, uses the phrase “Respectfully Real” when she wants to discuss something we could be doing better at as a division. She encourages others to voice concerns and even dissent, so long as it’s done respectfully. She understands the power of embracing Productive Conflict. She sees what Lyssa and Michael see – that teams have their own attitudes and behaviors, and that Productive Conflict is an essential tool at improving the team as an entity beyond any of its individual members. Not all conflict is productive and respect for the individual is paramount; however, trying to squash all conflict with a “kiss and make up” approach instead of leveraging it as a tool for growth shows a lack of respect for the team and does them a disservice.

What are your thoughts on conflict? What methods do you use to identify what particular type of conflict is arising? How do you foster an environment that promotes and encourages Productive Conflict? I’d love to get your thoughts. I also hope that I did justice to Lyssa and Michael; if you would like to learn more about taking a Systems approach to Agile Coaching, I suggest you look them up and learn more directly from the source.