Agile Coaching - 3/6 - Agile Doctor

26 October, 2015

You Can Be Right or You Can Be Successful

I recently had lunch with one of my friends and we spoke about some issues that one of his teams was having. As a new team, they were still in the storming and norming stages and they were having some fairly heated discussions around some philosophical issues of software development. For those not familiar with software development you might think there is not really anything to get all worked up about, in which case you would be surprised at the level of intensity some folks have. The discussions the team was having bordered on “a holy war” and there appeared to be little hope for compromise.

I asked my friend a simple question, “would you rather be right or be successful?” This question is one I like to use and is a variation of the quote “you can be right or you can be happy” which I have, until I did the research for this blog, incorrectly attributed to Dr. Phil McGraw (for those who care, the quote is from Gerald Jampolsky). Basically, there are times when we can be right and we can be happy but often we have to make a choice. The same applies to success at work. There are times when we can have it all, but sometimes we need to choose whether we wish to be right or effective.

Recently there has been an outbreak of measles in the United States due to the fact that some parents have not been vaccinating their children. The reason these parents were not vaccinating was due to false science that has since been refuted. In other words, the truth is unequivocal; vaccines do not cause the reactions that anti-vaccination parents fear. These parents are 100% wrong.

Since these parents are 100% wrong and not vaccinating children can lead to adverse health issues in the community, it makes sense that public health officials would try to change the minds of the “anti-vaxxer” parents. They did try. Their first approach was to try and convince the parents by presenting the scientific facts. They theorized that by knowing the true facts, people would make the correct decisions. That effort failed. It seems that merely presenting facts did not change peoples’ minds.

If presenting facts does not work, public health officials concluded the reason for the resistance was emotional and that emotional arguments would be more effective in convincing parents to vaccinate their children. That effort failed as well. (For a more details analysis see http://web.missouri.edu/~segerti/3830/Pediatrics-2014-Nyhan-e835-42.pdf).

This was surprising. Furthermore, not only are people not convinced by facts or emotion, but that when presented with factual or emotional arguments, the anti-vaxxer parents in the study were LESS likely to vaccinate their children. Evidence suggests that once someone has a strong belief in something, anything (or anyone) contradictory to that belief is seen as a threat. People who are threatened will cease to listen, much like a child will put a finger in their ears. People will erect walls to keep you out.

Knowing this, should we just give in to despair? Of course not. We need to stop trying to be right, whether presenting factual or emotional arguments, and concentrate more on being successful. The question is – what works in convincing people with strong beliefs to change their position? There is something that has been shown to work, something that lowers peoples’ walls and defenses and that thing is listening.

Instead of telling or implying people are wrong, we need to take the time to ask them about their position. We need to stop threatening them. Given the space to explain their position, people will not only feel less threatened, but also they will have to defend their own position and when tasked with defending their own position, people will slowly be able to see that they might not be the experts they think they are. This is where the walls and defenses are lowered so that other arguments might be entertained and listened too. Furthermore, showing respect to individuals and spending time with them will also make it more difficult to not listen. We listen to our friends not our antagonists.

A study of midwives in India found that arguments did not work with them either. What did work was “the rule of seven touches” which marketers know well. You must have meaningful contact and get to know someone (seven touches) before they are willing to trust and listen to you.

This applies to my work of transforming companies from waterfall to agile approach. While I may be 100% correct and it may make me feel good to be right, by presenting my viewpoint as THE way, I will not meet my objective. If I choose to be successful then I must take a different approach. I need to get to know the people involved, understand their concerns, not threaten their ideas, but allow their defenses to be lowered by listening to their ideas and then, and only then, if my ideas are truly right will I have the chance to convince them of or, better yet, guide them to the truth.

In the end you can be right or you can be successful. You can’t always be both.

19 October, 2015

Stop the Sprint Slop and Shot Your Zombie Stories in the Head

One of my loyal supporters last week requested I write an article about “sprint slop” and I am very happy to accommodate any requests. Before I could begin it was important that to understand the request because this particular term is not ubiquitous. A Google search for “sprint slop” returned few links and those returned were associated with skiing and not Agile or Scrum. Nevertheless, I had a good idea of what was meant by the term “sprint slop” and was able to isolate the meaning to refer to those stories that move from sprint to sprint and are not completed. I have also referred to such stories in my agile coaching practice as “zombie stories” since the never seem to “die”.

“Zombie stories” are a great indicator of team maturity, the origin of which is mostly related to either stories that are too large, poorly written and poorly refined or teams that are pressured to plan more in a sprint than is possible or are victims of “false” dependencies. In most cases, the root cause of the above is related to poor understanding of Agile Scrum from the business, particularly in relation to expectations of the product owner and the amount of time that is necessary to devote to the processes associated with the scrum framework.

The scrum framework consists of ceremonies for each sprint – daily standup, planning, review, retrospective and refinement (new term – originally referred to as grooming), which can be broken into backlog refinement and story refinement. If we were to look at the time that is necessary for all of the these ceremonies for a two week sprint (which seems to be the most popular timeframe), we would have something similar to the table below, with the total time between 9.5 and roughly 12 hours:

Ceremony	Time (in Minutes)
Daily Standup	150
Planning	60
Review	60
Retrospective	60
Refinement	240 – 400
TOTAL	570 – 730

Refinement of the backlog (and stories) for future iterations is estimated to be between 5 and 10 percent of the current sprint. It is during this time that we gain a greater understanding of the work that we are going to do in the future. In my agile coaching I break the refinement into backlog refinement and story refinement. Backlog refinement consists primarily in story identification, effort and value estimation, and sequencing of the stories – basically understanding the work that will be done in the next iteration. This happens as the beginning of the sprint in anticipation of the future sprint. The story refinement happens after the sequence of the stories is understood and consists of a deeper dive into the stories, one at a time in backlog order, generating a good story description (As a..Iwant..So that), generally understood acceptance criteria (my teams use BDD) and preliminary implementation tasks and estimates that are used for Sprint Planning ceremony.

When I have witnessed “zombie stories” and “sprint slop” it has been generally the teams inability to take the proper amount of time to refine the stories for future work and by not using tasks and hours to better understand the implementation of the stories. I know my particular way may be somewhat controversial since the trend these days is to not do estimates, either for tasks or stories, but in my experience the ability for teams to become predictive (ie complete 90% or greater of planned work) is something for mature teams and tasks and hours are a necessary step to help the team truly understand what they are capable of accomplishing. The detail work forces the team to consider how they will implement and will give the team more information on the true size of stories and places they might be able to break the story into smaller pieces.

In some cases, where the detailed work is done and the team still is unable to complete high percentages of the work, then the problem can be related to pressure from the business. Sprint Planning should be based in reality, but when timeline expectations are placed on a team, their natural inclination is no longer to make estimates and predictions based on their best understanding of the work, but based on the expectations of how much work “needs” to be completed.

The last reason I see for work moving from sprint to sprint is dependencies. Again, this is more an indicator of maturity level and an inability to write proper stories, than actual “hard-stop” dependencies. A “hard-stop” dependency is one where no work can be accomplished unless some other work is completed first. In software development I usually find that these are the more hardware-dependent stories. It is really difficult to deliver working software if I do not have the servers with which to deliver the software to.

However, my experience has taught me that most of the stories teams think are dependencies are, in many cases, not. These I call false dependencies and proper utilization of an INVEST acronym in writing stories will go a along way to breaking these “false” dependencies. For example, if there are two different team working on the same feature, one that is doing the backend services and one that is doing the front end UI work, then there appears to be a dependency of one team waiting for output from another team. This is a “false” dependency. There are two ways to address this issue. First, I can change the teams so that they follow the guidance that all members necessary for software functionality are on one team. Second, I can create three different stories that would allow the teams to operate somewhat independently – one for the service mocking the front end, one for the front end mocking the service and one for integrating the two stories. While not ideal, it allows for much quicker feedback on the work and allows the teams to schedule a chunk of work that they can accomplish in a single sprint. This can even work sometimes with hardware dependencies. I currently have a team that did their integration locally to a laptop while they waited for the real hardware to be delivered. Again, no optimal, but it did represent a way for the team to deliver into an environment that allowed for faster feedback and it is particularly this feedback that is missing from “sprint slop” and “zombie stories.”

One word of caution about team commitment and expectations. When I received my CSM training all those many years ago, I was taught that every story (100% of the work) should be completed by the end of each sprint. I remember the instructor saying something about developers “chopping off their arms” and “banging them on the keyboard” if it was necessary to get the work done. I did then, and still do not, believe that this is what is meant by commitment and have railed against the 100% expectation ever since. As with all things in life there is the ideal and the acceptable. My three boys are all still in various years in school, but my expectation from all is that they try their best to get 100% on every test, but I find that 90% or greater (an “A” these days) is acceptable. I preach the same with my scrum teams. Of course, we plan each sprint so that we can complete 100% of our work, but I find that 90% or greater on a consistent basis is acceptable because it shows maturity in planning and predictability in implementation so that longer term planning is possible.

The thing to always keep in mind is that Scrum is a framework that will shine a light on those things in your current environment and system that are not optimal. Scrum also gives you the framework to continually improve and solve underlying issues. “Sprint slop” and “zombie stories” are merely another example of the systemic symptoms Scrum will shine a light on. If you follow the framework properly it will also give you the ability to fix the underlying system so that you can be “sprint slop” and “zombie” free.

22 September, 2015

Real World Agile Q&A

One of the joys of being an Agile Coach is that it is a passion and a calling that doesn’t end at 5pm. Frequently I have the pleasure of staying in contact with individuals who I have worked with via phone and email. With the permission of a good friend, and changing a few details to render our exchange more generic, I present our latest exchange in hopes that people will find it helpful or at least interesting.

Larry,

I keep reading your articles and really enjoy the insight you continue to bring to the Agile world. I’m particularly stuck with a situation here at my current employer.

We’ve organized a scrum team that has done a fantastic job pushing out working, quality software since we started 10 weeks ago. However, this team primarily has worked on our website, but as I see it, we are bringing all of our development work to the team. Consequently, we are about to kick off work for redesigning our Intranet. This too falls into the team’s backlog, but now my business contact is pushing back, saying her backlog for Internet is separate and she doesn’t want to have to prioritize her work including the Intranet. I don’t have the luxury of just adding more developers to an additional team.

What tactics would you use to approach solving this? It’s a fragile situation. Your thoughts?

My response:

Thanks for the kind words. My first thought is a question – how many people are on the team? If you have enough, I would float the idea of splitting the team. The rule of thumb is one or more teams per backlog. What your proxy PO is doing is to (perhaps arbitrarily) split one backlog into two. One team cannot really service multiple POs or multiple backlogs. This way you can give the PO a choice – work with me to understand resources are limited, work with me to value all of the work for the team (not just your work) and then sequence the work so that the entire company is getting the benefit of a stable, focused agile scrum team.

That said, the real root of your problem might be that you really don’t have a product owner in the classic sense. Perhaps you would be well served to find someone who could represent a full backlog, especially if your team is too small to split as outlined above. I would suggest that all stories on your backlog should have both effort (in points) and value. Perhaps the best way to achieve your story value is to have your people compute the cost of delay (COD) for each item. You can then show all the work of the team with respect to value/effort to get an idea of which items to sequence first. If you find stories too granular to perform COD, group them (call them Epics, Themes, etc). Though I don’t recommend wholesale use of SAFe in your case, I would recommend that you have your folks look into concepts like COD and WSJF (Weighted Shortest Job First) that SAFe describes fairly well. Donald G. Reinertsen further elucidates these ideas in the book The Principles of Product Development Flow.

If you cannot get a different PO who can oversee more than just their parochial concerns and you cannot split the team in a way to service the two different products you are working on then your options become even more limited. My next question would be to ask who is in charge of your Agile effort? One of the reasons I have proposed the concept of CAO (Chief Agile Officer) is for situations such as these where someone at the top level of the organization can arbitrate using the entire organizational as a lens to determine best courses of action. It sounds like you are both on the same organizational level so it would help to appeal to a higher management level in instances where two of the same level cannot come to a satisfactory conclusion. Obviously this is a last resort in that people involved tend to react negatively to people “going over their heads.”

I wish you all the best, hope that you are able to resolve this situation and that my advice will prove valuable, and if not so, will at least not result in a negative outcome.

In the end, my friend decided to split the team into two smaller teams. Maybe in a later blog I can follow up to see how well this tactic worked.

9 September, 20159 September, 2015

Type Three and Four Errors – Solving the Wrong Problems Flawlessly

For some reason, I find myself attracted to statistics and probability. This is one of the reasons I love the books of Nassim Taleb, anything that Stephen J. Dubner and Steven D. Levitt of Freakonomics fame write, the social economics work of Dan Ariely, etc. Most recently I was doing some research and ran into the work of Ian I. Mitroff and Abraham Silvers and “The Error of the Third Kind (E3)”.

Because I had read so many books that have statistics and probability as themes, I was familiar with Type One and Type Two errors. Type One errors can be defined as incorrectly detecting an effect that is not present. Type Two errors, on the other hand, occur when one fails to detect an effect that was present. However, Type Three and Type Four errors were new to me.

An Error of the Third Kind (E3), as presented by Mitroff (and others), are those where the wrong problem has been not only proposed, but it is solved flawlessly so that it has the perception of being correct. Mitroff states:

The vast majority of books on management contribute to E3 because they imply that managers already know what their important problems are, for example: how to downsize in the most efficient way, how to improve chances for success in the global economy, how to install the correct Total Quality Management program, how to design the right reward system and so on. In each case, the unstated assumptions are that the essential problem the organization is facing is downsizing, global competitiveness or whatever it may be. While the assumptions may be correct, they are so crucial to formulating a problem correctly that they deserve to be challenged in the strongest possible way by asking tough questions.

This type of error reminds me of the argument I often hear from clients that “we have always delivered” or “waterfall has worked for us for years.” The real question that needs to be answered is not if one has “always delivered” it is “what has one always delivered?” If, in software development, the code is difficult to maintain, if it has a great deal of technical debt (for example, only concentrating on on-time delivery), can it really be said that one has delivered successfully?

When someone mentions “waterfall has always worked for us”, I believe this is an example of Type Three error. The real question – has waterfall been optimal? The example I always give is that the covered wagon was successful for transportation, but when I look out the window of a plane, I don’t see any crossing the prairie. In the case of those applying the values and principles of agile properly there is little doubt as to which is the airplane and which is the covered wagon.

Type Four errors may be even more insidious. These are sometimes better known as HiPPO errors (Highest Paid Person’s Opinion). These are seen in companies where top down hierarchical control is the norm. In their book, Dirty Rotten Strategies: How We Trick Ourselves and Others Into Solving the Wrong Problems Precisely, Mitroff and Silvers state:

The Type Three Error is the unintentional error of solving the wrong problem precisely. In sharp contrast, the Type Four Error is the intentional error of solving the wrong problems…

The Type Three Error is primarily the result of ignorance, a narrow and faulty education, and unreflective practice. In contrast, the Type Four is the result of deliberate malice, narrow ideology, overzealousness, a sense of self-righteousness, and wrongdoing.

By allowing others to improperly frame the question, a troublesome groupthink is created that allows many people to solve the wrong problems precisely.

As companies go down the road to Agile transformation, it is helpful to understand the Type Three and Four errors so that we don’t fall into the trap of solving the wrong problems flawlessly.

31 August, 2015

Patterns, Anti-Patterns and Pilots – Guidance versus Governance

In the past, I have proposed that an agile transformation should follow “three pillars of success – Structure, Practices and Governance.” This was a concept I decided to borrow from something I read in the past. It made sense at the time that to successfully transform we need to change structure (build good teams, etc.) and adopt new practices both at the framework/process level (ie Scrum) and for software development (ie TDD, Continuous Integration). It was the concept of governance that, while it seemed to make sense, gave me some pause.

It didn’t take me long before I began to understand why I was uncomfortable with “governance” – primarily because governance seemed too top-down and heavy-handed. It seemed a holdover from the very school of thinking our transformation was trying to change. Perhaps it bothered more so because governance was something easier to implement via the PMO (and something that people were too comfortable with).

It wasn’t that governance isn’t needed – even the games we play need rules. It would be chaos indeed if the length of a football field, number of downs or number of players changed from game to game. However, elevating governance seemed to embolden attempts by people in the organization to dictate even the smallest minutia. It was as if governance gave implicit authority to make every team run a west coast offense instead of concentrating on eleven players on each side.

Once governance lost its cache, the question remained as what to replace it with. It made sense to pick a word with a more appropriate servant-leader feel. “Guidance” became a much more palatable alternative. This was better, but it didn’t provide everything needed because there were some rules that would need to be followed. After a brief flirtation with the concept “Governance and Guidance”, in the end, we settled on “Guidance and Tools” as a replacement to the original concept of “Government.” The reason for this was that most of the “rules” revolved around reporting and the tools support necessary to some basic reporting.

Once we settled on the concept of guidance, a definition of guidance was needed. Over time, a working definition emerged that was referred to as:

Patterns, Anti-Patterns and Pilots

Not only does this option have alliterative qualities, but it also allows for a much greater environment for teams to self-organize and experiment. The process is simple. There are certain things that we know to generally work well for teams. One example is Behavior Driven Development (BDD). This would be considered a pattern. It would be a practice that is not only highly recommended, but would be fully supported by the organization from a training perspective for teams that wanted to try it. The key is that this practice would not be mandated. Each team has the option to choose and would be supported in their decision, but not every team would choose to (or have the maturity to successfully) implement. I often tell my teams, while I think driving is great there is a reason I don’t hand my car keys to my nine year old.

The second category would be anti-patterns, which are defined as those things that teams have tried but there is consensus that these have not worked. In other words, something becomes an anti-pattern when multiple teams have tried something unsuccessfully. In addition, there are things our experience as agile coaches and scrum masters have shown to not be effective which are added to the list. One example would be splitting stories between offshore and onshore for the same team. In practice, the anti-patterns begin to look a lot like a “scrum but” list.

The final category, pilots, is where the power resides. This category that allows teams to freely experiment with different ways of doing business without a great deal of pressure. The approach is empirical like the Agile Manifesto. Try something and see what works. There is no failure – only data.

The team identifies these experiments during retrospectives and is free to experiment on anything that is neither a pattern nor anti-pattern. These experiments follow the scientific method in that they have an identifiable hypothesis. The outcome from this experiment (usually lasting a single iteration) is either that the experiment has proven successful in which case it can be elevated to a pattern, the pilot did not achieve the desired outcome or the experiment needs to gather more data.

In the end, after changing from “Governance” to “Guidance and Tools” and outlining an approach to using Patterns, Anti-Patterns and Pilots, I found myself much more comfortable with the underlying “three pillars” approach of our agile transformation. I believe the new approach was better aligned to the underlying Values and Principles outlined in the Agile Manifesto. And, more importantly, I noticed that organization itself seemed more comfortable with the agile transformation and the teams were much more empowered to self-organize.

21 August, 201528 August, 2015

A New Chapter Begins

I recently accepted the position of Agile Practice Director for 10XP Solutions, Inc. (an affiliate of Systems Integration Solutions (SIS), Inc.) – a new and very exciting chapter in my life.

As always, the beginning of a new chapter is bittersweet. I really enjoyed working with the people at Apple and wish all of them continued personal and professional success. Fortunately I was able to handpick my replacement so I know they are in good hands and that they will continue on their Agile journey.

I am very excited about my new position because I will have the opportunity to create a brand new practice whose primary focus is creating great agile teams. While it is widely known that good agile teams are small, co-located, dedicated, stable and cross functional, there are very few folks in software development that actually get to work in such an environment. The possibility of actually creating such an environment is an honor and a dream come true. Additionally, we have the chance to operate like a startup but still have the backing of a strong, staffing company with over 25 years experience. The fact that I get to work with some really incredible people at SIS is amazing. I really appreciate their warm welcome.

The world is always changing. The world of staffing needs to change as well. As more and more organizations try to become Agile, they are finding it difficult to create optimal agile teams. We can provide intact agile teams to these and also to startups who need to ramp up quickly but may find it difficult to ramp up quality teams quickly.

We call our new effort 10XP Solutions. “10X” comes from the well known adage that the best programmers are ten times more productive than the least. The “XP” alludes to Extreme Programming whose emphasis has always been on high quality code, something that is central to the value that we bring to our clients.

I have always been fortunate and I am grateful to Peter Ling (CEO of SIS) for giving me this opportunity, the people at SIS for their support as we move into new territory and, most of all, to my wife and son for allowing me to pursue my dream.