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.

Advertisements

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.

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?

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.

Preventing Team Delamination

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

Flip how we do the work.

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

Teach me / Teach you

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

Enable or help out, this is a team effort

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

Better Quality

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

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

Team… Engage.

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

A Team Can Do More

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

Agile is an Active Thing.

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

Leaders Come From Great Teams.

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

Opposites – Aren’t Always Attractive

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

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

Great Teams Engage!

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

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

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

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

Where is Scrum Comfortable?

scrummyWorking with a Scrum team can be many things.  Along a spectrum from Comfortable, to Capable, Challenging, and up to Confused,  Calamitous or maybe Chaotic. I ask of myself where I might be.  Where is the team at?  Always I end up where I can’t blame Scrum, instead I point to something within myself. I will often go one step more towards some actionable improvement.  If there is a feeling of comfortable – is this time to strive for greater contribution?  There are moments of calm and quiet that hit just before storms, in the eye of it, and then afterwards.  So many times I pay attention to the storm that I forget to make use of those times of calm.  Change becomes a pain point instead of a welcome opportunity.  It is also why so many people who see the opportunity in a difficult problem have an easier time with agile.   Is the comfort level that I have derived from consistent cohorts, the familiar type of work in the backlog, my skill level, my contribution, etc.  Comfort too often derives from staying the same.  A much better comfort characteristic indicator, however, is being at ease when these things are changing.  Doesn’t continuous improvement always push us ahead, exploring to the edges of our known comfort map?

Critical thinking is a skill

Constantly this demands we be engaged in the moment.  It cannot emphasize confrontation but rather the ability to be candid. Can we recognize, understand, evaluate, communicate, and in the end have some consensus among ourselves?

Coaching

Be ready to receive.  Even those moments of insight can ever be honed for their delivery.  Inflexibility of consideration often caches impediments and contention.  Am I coach-able and correctable?  Kindergarten taught us to get ready and be open to learn from everywhere.  Are we improving and getting better?  Perhaps, we have been content and things seem to slip and decay just a little bit.  The small slips are covert until they accumulate into a moment of catastrophe and cataclysm.

In the Cards

The product owner often represents the team to the organization.  The work that they are doing is valued, valuable, and visible.  The conversations about this work is captured.  The expectation is convergent and aligned. There is definite commitment by the team. There isn’t any magic concealed in the cards – it is instead within our own character. Our capability as an organization, our capacity as teams, and our collaboration as individuals.

Cooperation

Challenges taken as a team or as a program of teams means that we are trusting others to help attain a very important vision.  That vision is comprised of a great many smaller achievements.  This means no hiding, no distracting, and the correct type of enabling.

The feeling of Safe isn’t the same as comfort.  A safety harness or belt allows us to do things with inherent risk.  We still require preparation and still exercise caution. The safe part allows us to achieve, and excel in a different context, while not falling too far.  A psychological safe space conveys innovation, creativity, and condones some risk towards reward.  Without empowerment, safety, and some closure, change often comes at a high revolutionary cost.

A quiet and calm mind during a storm will help.  I remember one of the first public runs I went on. It was part of a team event and I paired up to run with one of the members.  It was a 10k.  My endurance was starting to ebb.  I remember my mind grasping at the thought that if only my teammate would slow down to make it easier on me.  Anger would not have been far behind.  I knew I had to control the unfair contagion of criticism and instead celebrate their ease of achievement.  I stopped mentally accusing and switched context.  I focused on digging within to examine my own form, gait, and breathing.  It was sloppy and it definitely helped to adjust and self-correct.  The effort allowed me to stay in pace, and finish far faster than I could have on my own.  It is a lesson I carry whenever working with others.  Where do I sense comfort coming from?

A Philosophy of Metrics

Long ago, I had the opportunity to work with a team that was really adamant about not using metrics. As I explored their reasons, it became evident that they were uncomfortable with the visibility.  A few more wanted to ‘hold up’ on any metrics as well, but for a different reason.  They didn’t want to standardize on anything that would be ‘gamed’. This prompted quite a few conversations about what we were trying to accomplish.  If I have discovered anything, people can quickly become defensive around a metric.  At this point I start wondering about the environment and the visibility, trust and openness we need for agile teams to thrive.  This is my list to keep mindful, as I use and even explain metrics.

1.     Not the finish-line, but the start.  Any metric is not a goal; it is a side-effect. Treated as a primary goal it can probably be cheated or gamed. As a side-effect it simply is a characteristic of the work done.  Doing something right has its own characteristics.   Reminding the program, pointing the focus of the teams towards something to improve upon is usually the gold coin of the scrum master or coach. If we are not measuring without bias,  it is often difficult to be thought full and ask ourselves a few more questions.  When the results are empirical they may not always be intuitive.  Especially at an organizational level. Before we even begin some may demand a target. Before giving a reasonable target it may be wiser to spend some time characterizing our current ability.

2.     Are You A Pirate? Are we fearful, do we know the person monitoring compliance. So much concern for metrics revolves around how it can be used against me. No one should be looking to play hangman based on other’s fear of accusation. Nor should this be received as anything but information. I ever prefer the teams to be in a problem solving position rather than in a defensive posture. So how do you know if you’ve really improved if you don’t bring in some standards or a backstop to help prevent your teams from sliding? Metrics can be useful to identify, explain, question and problem solve. These metrics REALLY are for all of us.  You are the person, as part of a team, program and product that is trying to continuously improve AND using the metrics. As much information as we have at the time to make the right decisions. Don’t just give yourself a pass, or even beat yourself up, just do something small to improve it.

3.     Fast and Light Sailing. Is this an automated data collection? I get leery about anything manual unless it is very light weight! This is intended to be a side effect, unnoticed as we go. Large manual data collection is a pause and requires effort from someone every time.  Tools often have features to integrate and import/export data in many formats.  John Wooden tried never to mistake activity for achievement, and he certainly knew that if you didn’t have time to do it right, you should ask yourself when you will have time to do it over.

4.     No Metric Is An Island.  A metric hardly stands alone. It may be part of a larger picture that can indirectly be addressed. What questions might this metric answer? Why is it important? Details like this on the report itself often helps teach others.   Is the information actionable? What is acceptable?  Do I have enough information to improve it? Were there exceptions?  Can the metric be corroborated, or correlated?  Does it prove out what initial assumptions may have been? How does the behavior it should promote, affect other metrics?  e.g. What about the average number of days to address bugs by severity; which seems much more useful in assessing our capabilities than a current bug count. Could we ever measure that in hours?  Lastly, how do we balance the impact and prioritize these initiatives?

5.     Buried Is Not Treasured.  Make this visible to everyone in the company in 1 or 2 clicks.  Find a place for it.  Scrum is all about being visible to encourage feedback for improvement and a convergence that draws alignment.  Being visible also includes being in a format that is intuitive. Many times, even in some task boards, information is so disorganized as to be buried.  If I look for 5 seconds and then close my eyes, do I know and understand what was trying to be conveyed to me. Although the measurement may be empirical, the results should be fairly forward to understand.  The teams should also be used to these metrics, know they are supported, and fearless about having everyone’s help.

6.     Level Up. Take the time periodically to review and update the metrics based on the behaviors, and improvements you want in your organization.  What level is it appropriate for… the team, the program, or the organization? How mature are we? Once a quarter we should ask of ourselves if this metric has been useful. Perhaps other metrics might actually promote better program behaviors. Iterate and update to a different set of metrics if you have to. Scrum is a  continuous inspect and adapt. Are we improving? Which way is the needle trending?

Scaling By Analogy: Using Story Points

As the story goes… A city once kept a knotted piece of rope so intricately entangled that it was impossible to untie.  For all who tried.  Alexander the Great walks into town, and when he tries, he can’t even find the ends of the rope…so he uses his sword to cut the knot in half.  A solution from the battlefield brought into rope work.  The Gordian knot is now a problem that has been solved, although in a very nontraditional, unexpected manner. We used to get hung up on hours- how long something took to complete.  We were usually wrong.  The human species needed clocks because temporal management may not be entirely instinctive to us.  We changed the focus to get up out of hours and instead focus on task completion.  Doing the right thing and in alignment with the business.  Having an urgency for a time box that is the same cadence, always helps with our urgency, commitment and focus.

Analogy.  It is a way of thinking which transfers meaning or insight from one topic into a different realm, subject or topic.  From analogy we problem-solve, make decisions, explain, communicate, compare, create similes and say this thing is like some other thing.  It is often very useful when the work we do constantly changes – and yet we still need to compare when this work is BIGGER or smaller than some other type of work we did.   Humans long ago knew to size up danger from a big bear immediately and differently than from seeing a little rabbit.  Same with problem solving.  Stay with me… this all ties together eventually.

Scrum uses story points to estimate work.  That’s right.  Something that sounds made up and imaginary to be told to young children at bedtime.  This method also works really well for estimating work. Also, just like anything else – at times can be misused and misunderstood. Teams may have a series of cards, or use cell phones to display a number that is somewhere close to the Fibonacci series.  0,1,2,3,5,8,13,21,34,55 or maybe 0,1,3,5,8,13,20,40,100.  We talk about the work or ‘story’ that needs to be completed, and then we vote a sizing.  If we disagree then we talk about why we voted as we did, what we may have missed.  We typically capture this conversation for future reference.  It is one level at which we will assess the work before we actually commit to doing it, as a team, later.

I wanted to point out some common bumps in the road that teams can have.  Irregardless if they are just starting along their agile journey, or if they have been estimating stories for years.

Troubles with Story Points – what to avoid:

Anchoring. Don’t  let one person consistently shout out their determination before we all vote at the same time. – This typically anchors the rest of the group, absolves them from any critical thinking or questions and does not help teach what may be involved to others… Don’t anchor the estimate – just speak to what is involved, and effort.

Consensus.  Do we all need to agree and stay till the wee hours of the night or is a simple majority OK? Does our majority make someone consistently irrelevant? Does this team member still not seem to get it? I want to emphasize the team working together quickly and well.  Moving forward.  If you want to see and compare some other teams that either charge in and problem solve or seem to stop and thrash when presented with a problem or challenge – I usually like showing teams these videos.  These are teams going through an LRC – Leadership Reaction Course.  I often stop along the way to ask what they see is happening. LRC1 (How do the 3 teams compare?, Is one team placing emphasis on blame or where they succeeded?) and LRC2 (Did they change their process along the way? What did the team forget?)

Bidding.. This is not lowest bidder. – If Madam X does it then it’s a 21, if Mr. Z does it, then it’s a 55. Discontinue the delamination of your team. Discourage the work of the roles ever separating, not mixing, learning, improving until we are no longer a team.  A team leverage resources, trusts and exhibits a swarming behavior that everyone will pitch in to help get the work done.

Re-estimate the past.  Don’t.  Just keep moving forward.  Emphasize to the team that I want you better on the estimates were are making from this point forward.  There are also exceptions to almost every rule.  The only re-estimation I might do, is if this is a special reference story that your team can use to compare the size of OTHER work that it will estimate in the future. Perhaps this work is significant and sticks out in tribal memory of the team.   This story was really a 20 – and since it is sooo vivid in the team’s consciousness, it is now a standard for the next quarter to compare the SIZE and effort of different types of work to this particularly memorable one.

 – Making in-between values to be more precise… Don’t.  Once we start using 3.5 and 26, then we are right back to arguing hours.  The results are just as successful.  Be comforted in the thought that statistical distribution of all a team’s size ‘8’ stories – some were bigger, some were smaller but most will be pretty close.  In fact i might have had an 8 that turned out to overlap a  smaller 13. – Again don’t re-estimate.  Just become better and keep moving forward.  Trust that there is a variability to these mutable, intangible, team specific story points.

Other Factors

 –The team is constantly changing.  A team that is allowed to stabilize, go through storming, norming and performing, will have an easier time and more consistent estimates.

The team is judged by velocity only.  Don’t.  Take a look at the work they are doing even without the estimates.  Is it challenging, is the team growing to take on different types of work? How predictable are they for their commitments.  How robust and reliable is the solution they create?

The team just has 1 big story.  Really? all the time? This might point to a team’s lack of ability to critically break work down, narrow scope, or improve processes.  1,2,3,5, are fairly close, as they should be.  At a smaller scale we should be more accurate.   The Scrum master acts as a historian for the team and should be able to answer – What was the most amount of stories we estimated in an hour? What was the biggest story we ever completed? What was the most (number irregardless of size) stories we ever completed?  What is our average number of story points?  These aren’t to prevent a team so much as to ask the question, and have the team ponder, think differently for a moment and either confirm or change their answer on whether they feel this work can be completed.

Recycling.  Normally a good thing right?  This has to do more with the story that with the sizing.  We do iterate to improve things. Except when it is the SAME old story again  and again. Even kids pick up on this one. – I have known some teams to hide in a particular story and do the SAME work over and over and over.  They never finished a good deliverable.  Not a good way to represent value.

No Guess. No Conversation. Sometimes this is a matter that the stories are a bit too fuzzy.  Perhaps some time has to be set aside to make these a bit more ‘mature’, better vetted, or formed if this is not happening naturally in the moment.  Don’t allow team members to consistently abstain either.  There is nothing to be wrong about – this is a lean in moment to help problem solve and see from everyone what might be involved in doing this work.

Cards – Have some made for your team!  There are websites to do this or just get to a printer that has a good card stock.  I would put things on the back of the cards that meant something to the teams.  This could be personas – typical of those different people that use the software.  It could also be reference stories of typical work the team has estimated and done before for that number size.  These tended to be more useful and easier to guide the tempo of the voting than everyone using cell phones.

Flexibility is far more valued than rigidity.

For the project managers: Money burn down – yep we can still do it, even with story points.  This is done indirectly by empirical analysis once the system (team, time box)  has a chance to stabilize.  A project manager might take an average salary and at a sustainable pace (40 hrs a week), this means that our average velocity actually has a $ amount.  Though I don’t like doing this – it can bring in a sense of perspective for cost and priority. Is the team’s attention on this for a week worth the cost?   There are a LOT of intangibles though – like better quality and trust of the end-user. Sometimes there is an acceptable higher cost – because a team with the talent to do this more quickly is busy working on something with a higher priority and we are balancing the capacity of the program to complete the must haves in a release.

ANALOGY AND COMPARISON – This is helping us at one-level, think critically about what can be completed in a sprint… and the team teaches ourselves to become better problem solvers and know our capacity.

What we are learning how to be honest with ourselves, to tighten up sprint boundaries for what we can accomplish and show to the business as being complete and done.  We are earning some trust when done successfully.

It is the delivery of working software that truly matters.   The story point estimation is simply one level of thinking in order to view and assess the risk and size of the team’s commitment or forecast for several chunks of work.

 At first my concern for a new team is the commitment for this sprint.. but over time… we emphasize and cherish even more, the ability of the team to problem solve and right fit the stories into the sprint.  Then we get bigger about the work that fits into a release, and across a couple teams.

As ever, here’s to everyone being able to cut through a Gordian knot of their own.