To Whom It Should Concern

To Whom It Should Concern,

I am writing to you on behalf of a team I have will have the distinct pleasure to work with.  I don’t know when – as I have yet to meet them,  but they are out there.  Some when in time. This team will adopt an entirely new way of working and will change many of the processes around them. They will also change the tools they are used to.   This team is a natural collaborator.  They may not have all the answers, but I will see them get stronger and more  resourceful with every challenge that they come across.   They will develop a calm and deliberate manner with which they approach the work.  They will help the organization to understand the product they inherited and their own capacity for work.  This team will often strive for opportunities to better themselves. They are earnest in delivering a product that is slowly becoming what the user really wants.  It may require a bit if patience as this team matures.  There will be sparks of innovation and creativity that pay small dividends and will continue to accumulate for the benefit and influence with the other teams.  This team will need your support and at times your patience.  They may even struggle at times or misstep as they find answers on their own.  They may even challenge you.  I will tell you, there is greatness in this team. They will grow and tackle some tough problems for the organization.  They will try, learn, teach, and influence others to improve just as they expect it from themselves.  Congratulations on having such a team.  They are the ones doing some heavy lifting.  I hope you trust their professionalism and that they honestly want to create something valuable.    Help them with obstacles and to celebrate the small wins along the way.  Stay engaged.  Your interest and guidance will eventually find that they will be able to run faster than you could imagine.  Congratulations.

Advertisements

Never Going Fast Enough

There is something about organizations today that is prevalent.  The feeling that we just can’t go fast enough.  Many don’t really know the organization’s capability, or aptly characterize what is going on.  To know precisely where and how to improve may be lacking, let alone be aware of the impact of it all.  Teams themselves get impatient and  start to lose some of their calm about the problems that beset and beleaguer them.  So what if we were to make a few basic premises about the organizational landscape.

1) We are all here to do the right thing.

Not everything will help, but wouldn’t it make a difference knowing that we ALL want the software that we deliver to not only rock… but paper and scissors as well. MakerBot’s 3-D printer MakerWare will install and tell you that you are installing a bundle of AWESOME.  I wish we were all as excited about developing and using our software! Trusting that we want to do better lets me have some patience as we try a few things to improve.  Being open and honest also means we are saying directly what concerns us. It also means that if we see a problem then we also know enough to get in there and be a part of the solution. We need EVERYONE’S creativity and innovation. Not locked in up in a solitary head, but communicated and collaborating with the team.  It also means that when teams get moving, they will be fairly quick to act in solving and addressing problems.

2) Organizations are fighting for growth – or sit back, stagnate and eventually become obsolete.

The universe allows very few things to continue without some form of upkeep, maintenance, and eventual improvement.  Mathematical equations might be one exception, but algorithms which are great at data mining are not.  Software is the same way.  Technology improves our platforms of usage with smart phones and tablets.  Education and expectation grow the demand of an increasingly integrated and aware customer base. Innovation changes paradigms and allows some great advancement or advantage.  Moving forward and improving is a continuous adaptation.  The time to react, from perception to deliverable is now the measure for organizations.  How nimble, how agile are we?

3) There are no limits, only plateaus- get beyond them.

Bruce Lee said something to this effect.  We have a tendency to complain about limited memory, limited attention, limited time.  Another way to put it is cognitive load.  The ability to think is relies on internal processes such as motivations, reasoning, planning, learning, and solving.  External processes would include perceptions, stimulus, and actions.  Most of my own limitations start with where I think I can’t.  I have always been most rewarded in pushing beyond what I’ve done before and doing it from the perspective that I CAN… GO.

4) Teams require work

Investing time in the communication, collaboration, and the cultivation of the team is important.  Remember the team is the only thing in the organization that will do the work and get the software to done. Investments in great performing teams will allow the organization to really move.  Just as individuals collaborate, so do teams. It starts to scale. I know some individuals out to change the organization.  How much more influential might teams themselves become?  How about programs of teams?  We might not be able to go fast enough. I will say, however, that if we see the improvement – our rate of change will increase as we push against our own limitations as an organization.

 

 

The Eye of a Transformation Storm

A little known fact about myself.  I used to have a great fear of speaking up in front of a room, in front of others.  No Joke.  It went to such an extreme that I buried myself in books (especially English literature) and memorized vast amounts of quotes from others.  My own words never seemed worthy enough to be expressive and meaningful. So I relied on these quotes and spent a lot of time trying to be prepared when I HAD to speak or give some speech. Then immersion was next.  Speaking again and again and learning something new from every single experience.  A powerful one is when the speaker actually listens to the rest of the room and adjusts to where the group asks to explore. It would be unfair if this circumstance is more like performing a rescue. Getting all gear prepared, getting into the helicopter, starting it up and then just sitting there yelling at a stranded victim to come to you.  We actually need to be at the very perspective they are, help them triage, prioritize and assess, and move.  Ever a balance with leading the group to where it needs to go.

I look back across the years from whence I deliberately wandered and can only smile.  I now find it wonderfully rewarding to speak to rooms of people.  This is where it starts. The spark to transform an organization starts in small teams and grows.  In the beginning of this transformation the inevitable J-Curve panic sets in.  Sometimes the initial chaotic dismay is like listening to a storm. There seem to be SO many problems that I often hear ‘I thought that Agile was supposed to solve all our problems’, and ‘Agile isn’t working’.  The reply is usually – that Agile will not SOLVE your problems, but it will certainly help expose them!  We rely on people to solve problems.  Agile just provides some framework in which we structure the interaction.  We all know that although people are quite comfortable with old processes, that they certainly didn’t work out well either.

Supporting each team in adopting, and watching them grow faster and faster, overcoming the next obstacle, is rewarding.  Watching as they begin to mentor other teams, even more so.  Jot down a few things about what you would like to change.  Then be patient about growing to get there.  As you improve, having a taste of what went well, teams usually move forward from there.  We aren’t only problem solving the right software in the right way, we are building some great teams as well.  The next step is to terra-form the organization to support and allow those teams to thrive.

There will be storms along the way.  I can tell you however that they usually pass.  Come and go.  With every one the landscape changes just a little.  Maybe because Spring is here; but with each deliverable, as we endeavor to make ourselves a little more agile – I see organizations being transformed as well.

The Agile Hard Hat

When a company has made some inroads to being agile it seems as if something is always under construction.  A process, a team, the software… something. On a real construction site, it’s a hard hat that provides some degree of safety. LOOK OUT!  The same might be said for an agile environment.  But within the context of thinking caps, I think of a hard hat as a mode that seems to be stuck, frozen.  There is something to an agile environment that puts us into the edge and makes explorers and problem solvers. There are always a few that seem to hunker down and are really uncomfortable with the participation.  Sometimes it is trust, sometimes it is a slower rate of acceptance… the reasons are legion.  A good way to take some team members and start them down the road to perspective and context switching is Edward de Bono’s 6 Hats Exercise for a retrospective.  Now this isn’t a Scrum thing, but it is a way to get team members to become flexible thinkers.  To describe it quickly – each of the six ‘thinking caps’ represented by a color has it’s own way of thinking.  Take a look.  Black- critical, Yellow – optimistic, White – factual,  Blue – process, Green – creative, and Red – intuitive.   Scrum masters might want to switch up their entrenched black and yellow thinkers in order to move a team forward and get them to be agile thinkers.  Mix it up, rotate or randomize.  

Lincoln once said that if “I were given six hours to chop down a tree, I would spend the first four sharpening the axe.”  In his wisdom Lincoln was differentiating between activity and achievement.  Something John Wooden as a coach would often tell his teams were two very different and distinct things.  Activity. Achievement.  Scrum teams often have to use this disruptive innovation to focus at a level of thinking.  Are we tasking? Or maybe we are using this next (some-time box of) minutes to talk about and clarify our stories, features, epics, releases, product, or portfolio?

Now, as a manager or a project manager, I occasionally hear something that goes to the effect. ‘Why are my developers in a meeting?  They should be coding 100% of the time”  I try not to sigh noticeably.  This, is after all, where the some of the organizational terra-forming begins.  It can be  a mistake made by some traditional practices.  It is more surprising to continue to uncover this years into an agile adoption.  But make no mistake, I am always glad to bump into it.  We can’t get to the correction which makes it right until we are speaking openly and truthfully.  There is an echelon of QA and test professionals that echo this mantra.  However, I’m not usually the first to bump into the mentality – which means it is rather a rigidness of thought that has a tendency to persist until it meets with its paradigm shift.  Some one buried in activity has little time to change how they work, let alon how they think.  We advocate and support it should be expected instead some time is spent to focus on improving how we work.  Kaizan.

Agile does more than just re-arrange the way we do our work.  It changes how we think.  Software is problem solving and some pretty hard thought work.  If there is a difference between achievement and activity – the axe that we should spend some time sharpening – it is our own minds. Other tools and processes certainly fly into the mix, but the interaction still leverages our ‘thinker’.

A rigidness of thought.  The thinker might have stalled out.  Ever meet that contrarian person?  Just so negative all the time?  To go the opposite extreme and be perennially optimistic can sometimes lead to solutions which might not be robust.  We need everyone to be agile thinkers to get this software to done.  I think I can… I know I can set aside my hard hat as we improve the software, ourselves, our team, and the organization.

The Sprint That Blew Up

Is it appropriate to blow up a sprint?

The Setting
We were several sprints in with a new team and suddenly the team was faced something new.  Something out of their control caused havoc with the priorities in the Backlog. The work that the Scrum team had committed to for the sprint was no longer needed.  In the Sprint Review the scrum teams voiced that we did not meet our original goals.   The teams and the product owners were hard-voiced about having to “blow up the sprint” and having to “re-plan and re-baseline”.  There was a discomfort level and some confusion within the team as to whether we might have done the right thing. The strongest statement was, “The institution of scrum was disrespected.”

The Cliff Notes Answer
Leadership, stakeholders, coaches, and scrum authors say we all made the right decision and behaved correctly. Changing our sprint backlog in the middle of the sprint made sense because it honored new business objects and the desires of our Product Owners. The scrum play book says it is perfectly fine for teams to break the sprint this way as long as this is the rare exception rather than the norm.
  
The Detailed Answer
As I am talking with the team I will start this out with saying “GOOD JOB”
and end my conversation in the same way. I start asking QUESTIONS.  
 
When is it appropriate to Blow up a sprint and re-plan/recommit? 
Are we allowed to do it? Sure.
Always I want to ask questions. The first one is obviously Why? 
Is this a BIG Deal? I think it is.  Firsts often are. 
Were our assumptions on the sprint goals wrong?
What risk did we not think about critically?
What wasn’t communicated?
Does this still make sense?
Were the release themes not vetted from above and below? 
Was everyone on the same page for acceptance criteria for the stories?
What changed our assumptions?
How can we prevent this from happening again?
The Team did A LOT of work! 
We adjusted to the highest priority!  
 
Will the business expect this as common practice?
How disruptive was this? 
What was the impact? Did we lose 3 days of our sprint?
What did we learn? 
How do we improve?
 
I write this after the fact because we are empowered to make these decisions.
Don’t regret the decision – learn and adapt.  You have also worked through a fairly large and complicated problem.
You have changed, and will continue to change some of the assumptions we have together, as an organization.
Good Job!
 
————–Here are some external references from the proverbial Agile Library: 
Succeeding with Agile (Mike Cohn) pg 282 “I usually advise Scrum teams to start taking a firm stance against mid sprint changes. This is not because I am Opposed to redirecting a team or because I want to slavishly obey a Scrum Rule. It is because I want to help those outside the team learn that there is a cost to redirecting the team.  Of course, sometimes redirecting a team mid-sprint is necessary. But, all too often teams are redirected because it’s easy to do and because someone didn’t think ahead. I relax this hard-line stance against change after I see the organization no longer thinks of every new request as an emergency worthy of a mid-sprint change.   Being responsive is what has made us successful, and users expect that of us.
 
Exploring Scrum: The Fundamentals (Doug Shimp and Dan Rawsthorne) 1rst ed. pg 268 “Cancelling a Sprint. The product owner may cancel a Sprint at any time, usually because the Sprint Goal isn’t going to be met or because the Sprint Goal is no longer what is needed. In either case, the Sprint’s work is evaluated to see what can be kept, and whether or not a replanning is called for.  This is not considered abnormal, but it is simply an agile reaction to something that has happened. It should not be considered a ‘bad thing’ – it is merely a ‘thing’.”
 
Scrum Product Ownership (Bob Galen) pg 110 “Adjusting the Sprint. … In fact the leader here should be the Scrum Master. He or she is your partner and should guide you in making any necessary adjustments, etc.  However you do play a significant part in the Sprint recovery process, too!
 CONTENT DISCONNECT. The team is struggling to deliver the Sprint contents. Within a few days of the Sprint, you and the Scrum Master realize that an adjustment is necessary. I’ve seen several approaches to this. Classically, Scrum allows for cancelling and re-planning your Sprint.  That works well if you’re a stand-alone team. However, if your team is synchronized with others, then this approach can be awkward in that you’ll need to plan a reduced length Sprint in order to maintain your Synchronization. …  I’ve seen teams significantly recover their progress and often meet the original Sprint Goal. …
 PRIORITY DISCONNECT. … In these cases he (product owner) was more likely to cancel the sprint and then re-plan a new one based on a major shift on the backlog.  However when re-planning we tried to stay open minded about integrating the new work and maintaining some of the original Sprint focus.  Another aspect of this is insufficient look-ahead. I was never convinced that we couldn’t anticipate these changes in some way. Remember, we were on a 2 week sprint model which is fairly nimble.”
 ————————————————————————————
Changing direction doesn’t come for free. We are trying to be agile and make adapting lightweight – but a team’s capacity to do so is not infinite.  The time and impact required to pack up what we were focused on, and then re-plan should not be ignored. When we commit to a backlog at the beginning of a sprint, the team is serious about delivering the work and trusts that they have everyone’s support and are allowed to maintain this focus in order to deliver.  Unanticipated work in the middle of a sprint distracts. If a team starts to believe their commitments will be ignored, the erosion of urgency, commitment and trust start to occur. Loss of trust erodes team morale and we’ll eventually find ourselves back to where we started. In quiet silos with being defensive about collaborating.  Our ability to fail early is not a joke.  It is instead a measurement for how quickly can we get to right.   
 
A message like this should be visible enough to encourage the team we did the right thing.  Some VPs, a few Directors, coaches and half a dozen managers as well as the teams themselves needed to know and think in a manner where there was no ‘us’ vs ‘them’.  There is only “WE”, together.  As in WE will make this better and work together so that it shouldn’t happen again.  As well as, we will be thought-full about the “But if it does…”.   This is what transforms the organization, delivers great software, and as a side-effect, makes some high performing teams.
If you’ve made it this far, thank you for reading through the details.

Team Behaviors

good_teamsI found myself looking over the shoulder of a 10 year old who was watching YouTube videos.  Teams challenging each other in competitively created Minecraft worlds.  I get curious about what other people see.  Maybe an even better word is ‘perceive’. By being so, I also get to learn.  As this particular video series unfolds, the same competition is recorded by each of the two teams involved.  A perspective from each side.  After the winning team series was viewed, he continued to watch the same contest from the losing team’s perspective.  ‘Why’ resounded in my mind.  “What did you learn? What did the team, that won, – do better?” This elicited such a thoughtful look that I then asked if he could write down just exactly what made the winning team a good team.  I share this list with you, not only because I believe that it was good, but it is also how we spend a majority of our lives.  From kindergarten and even after retirement – we interact in groups.  Teams if you will.  Esther Derby noted the good characteristics of a thriving team.  As well as struggling teams exhibiting something different. What do you and your teams strive for?  I am going to go over this young professor’s list.

Splitting Resources

Effectiveness in being visible with what resources we have.  Many of the reality survival shows take a group that will depend upon the openness to share what they have.  Tools, knowledge, food, sources of inspiration.  Everything is fair game.  What if we consider the members of the group itself to be a resource.  We are sharing of ourselves… Pair programming for example. Teaching or helping to perform a task.  Load balancing the team itself and how it works with what it has. Even creating things that the team will need and help it to thrive.

Plan

There it is.  We need to plan… we start out with one.  Agile also tells us that this is the starting place, and we cherish our ability to adapt and alter that plan as the struggle ensues.  Some of the goals remain unchanged, but the little adjustments along the way point to our ability to absorb changes as reality proves itself to be divergent from our imagination and preconceptions. The plan helps our expectations converge.  It is something that we leverage to rally the team. Typically we even have multiple levels of planning. Our coordination begins somewhere.

Help Each Other

This is one of the main reasons we are in a team.  It is also why we emphasize self-organization.  What can we do to be a part of the solution and move the team towards success. Helping drives the interaction of the team.  Trust is integral.  I sometimes have to remind members to assume good intent and focus on the goals.  No matter how hectic and chaotic the circumstances are, watching a team calmly work through the tough situations with a focus and clarity allows them to analyze and critically process.  Better decisions and great solutions will result from a team like this.  The opposite end of the spectrum is a team in a defensive or reactive mode as a loose grouping of individuals that simply do what was heard to be the loudest.  It may get you through some short term fires, but there is usually a cost to the team and organization in the longer term. Team building is the best by-product I have ever witnessed as a result of any agile program.

Tell each other what they’re doing – so people can help and support them.  

This sounds exactly like a stand-up.  Even in a larger sense how the entire team is being visible and open with the work we are doing. Especially the problems or opportunities along the way. This is how our coordination continues.  We work on our communication daily.  Being face to face is still the widest broadband form of communication around… but it may not always be feasible.  An active team usually has a buzz or chatter as tasks are worked. There is little trepidation at relaying the information of what is happening and our progress towards our goals.  Everyone here is trying to get the team ahead, through the thought-work, through the software, hardware, processes,tools…  Many people are connected by a headset as part of a team and rely on this coordination to achieve work for the team.  For teams this is another line of sight – making our work visible.  Great teams make decisions based on information passed along quickly.  It is part of their reaction time.  Going off into a mine and being isolated for a very long time may not always be in the interest of the quick pace at which a team needs to be informed, move and react. Speak up, we need ideas from everyone.

Defend each other

Now hopefully, no one on the team is being attacked physically and directly to where we need to shield our mate from the slings and arrows of outrageous fortune.  Yet there are other things to defend against. From the perspective of the author of this original list – this would include bullying.  Software is hard problem-solving. Usually instead, we are probing for work being done on the wrong thing that might not be highest priority. Providing a solution might prove too fragile, or hold us for far too long.  Defending takes the support for someone just a bit further.  Defending is the type of behavior that promotes swarming. Not everyone may start out knowing when to ask for help.   Swarming on tasks the team knows to be critical should come naturally.  What about sustainable pace?  Defending each other against burnout, or helping to ensure the quality of the code is high. Perhaps even ensuring that the acceptance criteria is well understood or that a definition of done is met. What about improving or automating some repetitive task so that another team member can contribute more?

Thinks Creatively

Great teams have a gift for this.  Innovation by it’s nature takes some risk taking, vision, drive and creative tenacity.  Seeing what could be is far more powerful than why it can’t. I often think that this is the singular most powerful characteristic someone can possess as jobs change.  The speed or the rate of technological and scientific discovery will continue to quicken and broaden.  Without creativity, the possibilities, unorthodox connections and navigation of shifting paradigms should otherwise ever prove to be a challenge. Adventure time.

My profound thank you to a growing ‘coach’ that is understanding and looking at teams in a way, that I didn’t start exploring, until I was far older.
What would make your team’s list?

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.

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

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.