Agile Coaching - 2/5 - Agile Doctor

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.

14 September, 2015

One Effective Interview Question for a Scrum Master or Agile Coach

I have had the good fortune to be involved with Agile software development for close to a decade now. During that time I went from a somewhat skeptical Director of Software Development to someone who now makes his living helping others create great software by applying the Agile philosophy as an Agile Practice Director. One of the things I have noticed during this time is, as Agile (and especially Scrum) have become more mainstream, the quality of individuals calling themselves scrum masters and agile coaches has become more variable.

The problem is certainly not new or particular to Agile Scrum Masters and Coaches, However, I feel that that, given their centrality to software development teams, the fact that Agile is new to many organizations and in many cases these individuals are expected to aid in transformation, having an ineffective Scrum Master or Coach can lead to disproportionally negative effects. For example, a single inadequate developer can be a real drag to a team, an ineffective Scrum Master can be detrimental to multiple individuals and multiple teams and the same inadequacy at the Coach level can lead to wholesale bedlam for large parts (if not the entire) organization.

The problem is further exacerbated by, as I (and others) have pointed out in the past, by a weak and inadequate system of certification. It is good business to mint as many scrum masters as possible from a two-day training, but it does the outside world no service. This begs the question – in a world where every former project manager with a CSM calls themselves a scrum master and every scrum master with a few teams under their belt calls themselves a coach, how can I really assess those who have talent from those who do not?

Of course, one could use someone’s resume to assess the breadth of work. How many different teams has one worked with? How many years has one been involved with scrum? How many different organizations has one coached at? Unfortunately, individuals looking for work have a tendency to prevaricate at times so how is one to know if that time was really spent doing Agile or did I conveniently reclassify this work because it was not “entirely waterfall”?

A good deal of my current work is trying to make these kinds of judgments. If you too need to assess the ability of a scrum master or coach, let me share the question that I have found to be most effective:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

If you are merely a paper candidate who has relied on the minimum set of qualifications (ie you have a good number of certifications) then this question is very difficult to answer. Being a scrum master or coach requires a level of passion that transcends merely implementing a small set of learned behaviors. It requires an active mind that is constantly seeking new ways of thinking,, new experiments to try, new behaviors to model – any and everything that one can do to truly be a servant leader. Passionate people always want to improve. There is no better indication than reading as a means of improving one’s ability.

The question not only shows ones ability to think critically, but it also indicates a higher level of maturity. To read something that changes ones view requires the ability to realize ones knowledge is never perfect or complete. I have to acknowledge that something I hold to be true today may not be true or that I have a true ignorance of certain things.

Agile and scrum are about continuous improvement. We should not expect our scrum masters and coaches to have all the answers any more than we can expect our teams to function perfectly. There is always room for improvement and it is the good scrum master and coach who is not only able to admit this, but also has taken the steps necessary to improve. One of the most accessible ways for this improvement is to read books and to apply this knowledge. So the next time you are asking yourself “Is this scrum master or coach any good?” perhaps you might want to ask them this simple question:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

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.

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.

20 May, 201516 September, 2015

No More Agile Checklists – Can We Concentrate on Outcomes?

As an agile coach and change agent I am always asked how maturity can be measured at the team and organizational level. What I have found over the years is that there is no lack of different checklists that can be used to give us these “metrics”. In fact, a recent Google search gave me a page that contains links to literally 41 checklists. In addition to these I have personally worked on many different custom checklists myself as if the 41 currently available do not adequately address the needs of teams transitioning to agile! Why is it that these already existing measures are not enough?

Here’s my theory. Most agile transformations are accomplished by outside consultants (like myself) and these outside consultants know that beginners are looking for checklists. A great way to make money and to fulfill the client’s desire is to create a custom checklist or impress the client with a proprietary checklist – one assured to work where none of the hundreds of others can’t.

There is a problem with this checklist approach – it doesn’t really work all that well. The problem is that checklists tend to measure input and are very reminiscent of the failed waterfall view software development. It is, in effect, a CYA type of activity. In other words, you cannot blame project failure on me because I checked all the checkboxes. If checklist software development worked then waterfall would have a respectable success rate and folks wouldn’t be flocking to agile alternatives. No sense trying to fix the problem with the failed approaches of the past.
Another problem is that Agile works because of self-organization of teams and checklist tend to be very prescriptive and top down. A great number of these checklists have so many very specific factors that are measured that they provide little room for experimentation for the team to discover the best way for them. A checklist assumes that they way measured is THE way. If this is truly the case then what about the manifesto which States that we are “uncovering new ways ” not that we have found a way and we have a checklist to show you the way.

My inclination is to reduce our focus on the inputs of Agile and spend more time focusing on outputs. Instead of measuring whether a stand up lasts 15 minutes or less, I think it best to focus on what value did the team deliver during the previous iteration. In fact, I have only two primary measures for when it is time for me to stop coaching – does the team exhibit predictability by completing 90% or more of the work planned each sprint and is the Product Owner happy with the amount of work taken and quality of work delivered. Give me these two things and I don’t give a damn how you did it! However, if you are not giving me these things then you have opened the door to coaching on the inputs. Interestingly enough in order to achieve these pared down metrics most teams figure out what the proper inputs are without a top down mandate.

You can spend a great deal of time, money and effort checking endless inputs or just measure a few highly critical outputs. The choice to me is clear. Stop concentrating on inputs as primary measure and concentrate on the few critical outputs.

23 April, 20154 May, 2015

Individuals, Teams, Systems – The Evolution of Agile at Scale

If you have any interest at all in agile, if you read agile blogs, if you follow agile trends, you most certainly have been (over) exposed to one phrase “scaled agile.” I, myself, recently received a certification for one of the new scaled agile programs. While I enjoyed the training I find myself not 100% convinced of its effectiveness.

Perhaps it is because of its very novelty that I remain skeptical. Perhaps it is because I know front line people in companies referenced as successfully adopting who do not agree to the efficacy. Perhaps it is because “scaling ” has simply become the latest excuse from management why agile cannot be adopted at their company (as in why should we bother when agile has not been Provence to scale). In the end though I think the reason that I am lukewarm on the idea is because companies have been latching on to scaling before doing the initial groundwork. in other words, scaling has become a red herring that induces companies to put the cart before the horse or the system before the team.

Once upon a time I coached one of the most amazing agile scrum teams. They were able to deliver things that their management found quite unbelievable so much so that they conveyed a meeting to find answers to why this particular group of people were able to so greatly outperform others in the organization. As an aside I was not originally invited to the meeting but the team lobbies for me to be there as they considered me one of the team and, as a team member, partially responsible for their success.

I remember very well one manager in particular gushing about the team performance and wondering aloud how such a miraculous feat could be “scaled.” “It is very much like the legends of people working together out of their garages,” the manager said, “but how can such a thing” he paused briefly to allow the group to understand what came next would be important, “be scaled?”

Before I realized that the question was merely a rhetorical one to introduce us to the new management buzzword “scaling”, I opened my mouth to answer. “Why we just create more garages,” I said. The answer, which I still stand by to this day, was roundly ignored by aforementioned manager and his manager reports and was about as welcome as a tart in a crowded elevator. What I realized too late was that “scaling” was management’s way of avoiding any action, especially action that might involve hard work and opposition.

So, you might say, scaled agile to the rescue. Not so fast my friend. My amusing anecdote above was all about creating good teams (and creating more good teams). Agile at scale is about creating a good overall system. There is no need to scale agile until you have enough teams doing agile.

Here is the way I like to explain the evolution to scaled agile. Waterfall is inefficient because it tries to optimize individuals at the expense of teams. Good teams have a higher productivity, shorter time to market, higher quality, etc than individuals. Enter Scrum. Scrum, when done correctly, optimizes teams. This is a huge advance and if your agile evolution ended here, you would have come a very long way. Nevertheless it frequently happens that we cam optimize teams at the expense of the system. Once we reach this point it is appropriate to look at ” scaling” and how we can optimize the entire system.

To recap – waterfall optimizes individuals at the expense of teams. Scrum optimizes teams at the expense of the system. Scaling is the attempt to optimize the system. My experience (and it may be biased because like Freud I work mainly with the “sick”) is that companies abuse scaling because they either use it as a means to avoid agile or they rush to scaling without first making the tremendously difficult transition to creating effective scrum teams. My advice remains “build more garages.”