Clock Time, Event Time, and Bullet Time

When becoming agile, there are many ways that we start to look inward in order to change how flexible we can be.  We start to think about work differently.  We think about how we collaborate together.  We think about task, story and epic level things.  We also ponder time itself.    Is there a placeholder event for that?  Is this the appropriate time? Is the time-box up? I remember the high school teacher’s frustration at having students look eagerly at the clock – anticipating the moment when the bell would sound the end of class. Ultimately later in the year, the note underneath, which was posted and read “Time will pass.  Will you?”

 Clock Time

There are things that are run by clock time.  In the agile world we set limits on meetings and sprints Many organizations still account for hours. Things that are run by the clock.  It lends a sense of urgency and there is a certain puzzling in order to fit activities and interactions to fit appropriately.  Time does not stop. It marches.  What does change though – is our perception of time.  Some moments whiz by or instead as Shakespeare said slowly drags on and “Creeps in this petty pace from day to day, To the last syllable of recorded time”.  When our days are managed by the clock, I often wonder if this alien and measured arbiter of fate sometimes robs us of an empowered position.  Some teams often measure a sprint burn down with hours remaining (Which I’ve previously talked about here) .

Event Time

When timelines are populated by events they often give us a sense of achievement and better context than Chronos‘ stamp of numbers.  I am looking for a task to complete rather than time to run out.  Choosing achievement over activity and hallmarking instead by the memorable actions which have culminated in a sense of completion.  Sometimes ending a day in a ‘good spot’.  Event time seems to allow for creativity and innovation that spark and motivate just a little more.  Doing something Better than before, not just the same way over and over.  Is event time always better? probably not as with all things there is a balance.  It will Clock time that helps us determine if something ‘unsustainable’. But, again, only because we haven’t achieved the desired events. A Team might measure tasks, not as hours remaining, but rather as events – only wanting to know if they are in progress or done. A retrospective timeline will often be measured in 3 ways – the chronological timeline (1) earmarked with events (2) and our reactions (3).

Bullet Time

The matrix first coined the term, being fluid and moving faster than we thought possible.  Unfortunately it always seems to be during crisis moments.  Whether on a six story drop on an amusement park ride or in front of a release review.  Our brain registers everything and goes into a hyper protective mode.  It’s sometimes hard to remain calm and in a problem solving in a panic driven environment.  At times the uber-urgency brings out some of the best in our teams in an almost Apollo 13 type of way.  There are no lives on the line, but the sense of responsibility doesn’t seem any lessened.  It usually takes longer term investments in teams of people to make critical and good decisions.  To support those teams we invest in infrastructure and technologies.  We let them adopt lightweight processes which enable them to move quickly.  Bullet time is not a sustainable thing. But some of the best days are briefly ventured here, when the team pulls together and works itself out of a crisis.  Even better when the team plans to avoid the same thing from ever happening again and moves back into Clock or Event time.

Take It To The Team

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

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

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

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

 

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.

Xtreme Feedback

I once posted that in an agile sense it seems like We Can Never Go Fast Enough.  Going fast means we need to have quick reflexes; the ability to adjust. This in turn relies upon feedback.  Some information that quickly lets us know how we are doing and allows us to steer back on course. If someone is YELLING, then it’s our ears. Very often, however, it is our eyes that tell us.  It is why we lean so heavily on information radiators and large visual displays.
There has been a growing trend for a while now in pursuing ever faster feedback mechanisms; often named Extreme Feedback.   

The Extreme isn’t so  bad. Not as in some reality show which uses shock collars when something gets broken, but rather in the ability to very quickly ascertain information.

1) Where the code is
2) What State the code is in
3) If Something undesired actually happens – Signal for help!  600px-Nabaztag-IMG_1666

Whether it’s a bunny from Nabaztag or an Arduino (Uno or Mega) with some LED’s like this starter kit – these indicators can be tied into a build process and let the entire team know what is happening.  Collocated or distributed, these devices are fun ways to immediately inform the team about what is going on.

A Team Foundation Server Build Bunny

http://stackoverflow.com/questions/303614/whats-your-favorite-extreme-feedback-device
https://blog.codecentric.de/en/2013/07/using-a-raspberry-pi-to-control-an-extreme-feedback-devices/
https://jenkins-ci.org/content/extreme-feedback-lamp-switch-gear-style
https://wiki.jenkins-ci.org/display/JENKINS/eXtreme+Feedback+Panel+Plugin

I might choose the bunny because Easter is almost here! I might choose an Arduino because I am tired of Hidden Easter Eggs!
From the Quality side of things, I always disliked very long processes that went on and didn’t have any verification until a dozen or more changes were involved. Let alone another dozen processes had already been gone through.  It was even worse, if like in waterfall, the next stage was the verification of several months of work.  Extreme feedback pushes into the small changes that the build is compiling and does a great job of simply making everyone aware. Quality in the moment. Devices like this can be tied into deployments, and even into Test results. What about some aggregated sprint or release results? Granted the feedback on a release is going in the BIGGER direction – but the automated indicator of a 😦  *sad* bunny is impetus enough to rouse ourselves to action and address the problem.  In a fun way of course.  

If the team has a budget (and I often think it should), this might be a great, fun, and motivating project to help the team to get ‘to good’ as soon as something goes wrong.  In TDD (Test Driven Development) terms “getting back into the green”.  A passing state, and out from the red, broken state, as soon as possible.  The term leverages from the eXtreme Programming or XP Practices that Kent Beck championed.

Have fun if your team decides to use one.  Let us know how creative you were.

Without A Net

As a traveler I know there is always something new just lurking around the corner.  Whether it is taking a metro train and navigating a city, navigating a building, or even meeting people for the very first time.  Sometimes even when I am doing something practiced, a new situation has the tendency to spill itself all over the comfortable events I had planned on neatly unfolding.

There was a book written a while ago Working Without a Net.  I liked the premise that – eventually we should get used to doing some great things without worrying if we had a safety net below us.  Now I do NOT condone physically working without safety equipment.  Yet the mental equivalent of something comfortable which might hold us back from trying something amazing now and again, resonates with me.   The chapter about channeling one’s anger, seemed outdated, since it suffices only as a very short term motivator. – But, back to my story…

I have had a slide deck around for a little while.  I spent an hour updating it.  Improving it a little each time I bring it out.  It might be getting a little long with all the cumulative material through the ages.  Yet it allows me to cover the breadth and depth of the material.  I am comfortable with the content.

I had arrived early to the room.  I usually like to get a feel for the space which I am going to be throwing ideas around in.  Often I will change the contents around in some formation that benefits the audience as they participate.  Sometimes just to introduce a a change that keeps a creative ember burning somewhere that spacial permanence has seemed to desensitize the returning audience.  Tables and chairs arranged. CHECK.

Then the projector, screen, computer, slide deck, and any typical markers or post-its that a ‘meeting-in-a-bag’ might offer.  CHECK.

I know my voice can dial up to carry across the room – no mic. needed.  Wireless presenter to allow for some mobility.  CHECK.

Audience is starting to trickle in now. CHECK.

and with a quorum – off we go.  First Slide… Starting into the topic… and the projector goes out.   *sigh*

Is there a quick 10 second fix… nope.. and then the priorities start to become clear.

Why are we here -FOR THE AUDIENCE.  These people are important to me and I absolutely do not want to wast their time.  They have asked me to explain and explore a topic they have all previously expressed an interest in learning more about….  Alright – I made the slides – and those were from my experiences and insights… I’m still functioning….   What do I have around me… I have just switched from assessing situation, and a quick personal (psychological) inventory to looking at my surroundings.  What in the environment can I use to aid my survival.  🙂

Abandoning the projector and screen

I see a whiteboard… I’ve got a marker or two… and the slides now become the old ‘Chalk Talk’ using some dry erase markers.

What were the really REALLY important things I want them to come away with… my mind starts leaping forward and re-arranging the material instantly.  Let’s draw it out.

Along the way I reach out and offer some choices as an audience… there might be two different exercises we can do to practice this… ‘which one would you like?’  The decision from the crowd takes a few seconds… It is one way to characterize the group – how long do they take to make a decision and how many were vocal.

The time and breadth of topic passes quickly as we get questions along the way which perfectly explore some common areas that can be misunderstood.  GREAT Questions that actually lead me to cover areas I might have missed AND take the audience along the route they wish to explore.  I feel more like a guide than a presenter.  Our safari into the topic still leaves me with how fun it can be though I’ve been here many times before- just not in the same vehicle driving through it.

Joking, laughter, and even a few AHA moments.

And before we go, a few minutes for being retrospective and feedback about the time we spent together… Some pretty high marks…no mention of the projector.  The ability to switch manner of delivery and increase participation is perhaps left unstated; simply appreciated. No thing is perfect but our ability to make adjustments along the way is perhaps one of the basic tenants for agile – have a plan but get used to adapting.

A few linger afterward and want to explore other areas of knowledge.  I wonder if the teachers choose the students as often as students prefer to choose their teachers?

The NET that I was careful to prepare, the slide deck… seemed as if it held me back from really connecting and getting the best curiosity and participation from those who attended.  What else is there that might be so comfortable, it may actually hold back and keep from moving into some spectacular things?

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

How Close Was The Customer Collaboration?

So I was near a conversation that kind of went like this;

A developer was asking the actual user of his team’s software for some feedback about the product.
I was heartened to see the invitation and he had a lean in to listen better.  He was taking mental notes (I could see the gears moving) on how to make this better. The developer also explained how rare an actual customer interaction had been over the past several years. The user didn’t have much in the way positive to say about the software and was matter-of-fact in conveying that it really wasn’t all that usable and we needed some extra fields and the training needed to be a lot better – to reflect how they were using it. I watched his wonderful continued calm as the developer wasn’t at all defensive, continuing to listen. Then a third person, who thought they knew the next step, interrupted to say that the customer needed to get project funding.

This is where my head leaps in and explores.

The customer really doesn’t care about someone else’s internal processes for funding.  And at time this is going to be some organizational telekinesis that is way too big for them to tackle. The customer may feel alone – like they were left to swim in the middle of the ocean. No Hope.

There are at least three things that need to be said here ….

1)      Good job for the developer – not just to invite, ask and listen. I have the distinct impression that this will continue.  I heavily encourage it.

2)      The ‘Future funding’ is simply a stall tactic to put off our being responsible today.   There is a current project that didn’t even include the customer. Why not open that up and start inviting them to the reviews, as a first step.  Get their feedback. Developing a trust and a responsiveness with the end-user will help in all sorts of ways.  Elicit their help in building and testing it.  Now I am not saying that funding isn’t needed.  Typically however funding never really gets at all the hidden costs within an organization to get the software out the door and into the customers hands. The definition of being done means that it is fit for use.  The requirements aren’t sitting down at some desk using the software to get a job done – a person is.  We should ever cherish and understand that.  Maybe over time – the software, the job, both change. Who knows.

3)      Why would anyone want to continue funding a ‘redo’ when it wasn’t done right the first time.

Now pullback a year or more, and there is a conversation that I had with a director about his organization.  We talked about involving the customer and he wanted to hold-off on doing exactly that.  The argument went something like… my customer is internal since we develop our own software.  My customers are not going to innovate, adopt change, and discover ways to do things better.  Just put it out in the field and they will use it as we leverage external sources for creativity and innovation.

My counter was that we required a balance.  No matter how creative we are, if software isn’t usable – then we have a great big point of failure once we’ve deployed.  The mix of this balance might be slim in the beginning as we learn to work together.  20/80 or even say 10/90 but if we just absolutely brick a Berlin wall and shut out or silo the left hand from the right – we are going to miss the inevitable handshake that is coming.  Over the course of the next year, took a while to grow that relationship.  As the new teams learned from the experienced field about the app, they also grew to trust the deliverable more.  Slowly the field also started not only accepting changes but also leveraged opportunities with more suggestions.  The field started getting used to the idea of being innovative just as they were able to share their experience.

Both sides were far richer for the interaction.  Expectant convergence about the end-results were also happening more often.

What also started to happen was that the teams were increasingly aware of Everything it took to move software through the organization and into the customers hands.  Processes started improving. Requests for infrastructure were aligned to support business objectives.

It is my experience it takes a while to move some big things like an entire organization.  You do it by being part of the culture and then changing it.  A little at a time.  Some things catch on and sometimes you even have a motivational brush fire within an organization that started from a just a few sparks.  The fire within us, helps us along whatever journey we have.

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.