Context is King: Why I stopped blogging

A lot of the articles I read about agile don't describe the context in which their advice applies. The authors don't take the time. Many authors aren't even aware of their context. They haven't seen enough different kinds of agile implementations to understand that their advice doesn't apply outside of their context.

Writing was easy for me when I worked for Leading Agile because we had a well documented and limited context. Grossly oversimplified, companies who wanted predictability in their software development efforts were attracted to our offering. We had one message, one services offering, and one target market.

Everything on our blog and everything on our website and every talk given at a conference adhered to this single context. That context was explained so much that it didn't have to be explained every time. Yet every blog post pointed back to that context in some way. It all dovetailed together.

Every aspect of agile, of teams, of org structure, of metrics, of forecasting, of planning, of funding, of portfolio management, of roadmapping, of prioritization, and on and on needed to be explained in terms of that context, so there was lots of fodder.

I stopped blogging when I left Leading Agile because of this need for the applicable context to be explained. When I left the firm I left the context. I've seen agile done many different (valid and effective) ways before my time at the firm and in many ways after. For which context should I write? How should I explain the applicability of my opinions? 

I don't run my agile programs now the way we did at Leading Agile. It's not because I didn't believe in that approach, didn't find value in it, or can't do it. In fact, I like that approach a great deal. But it doesn't apply to my context now. Predictability isn't my driver. 

This isn't anything new. People have been arguing over agile since the 90s, with much disagreement stemming from the unique and unstated context in the mind of each author and consultant.

What triggered me to write this was some things John Cutler wrote. "…the key to putting bets in motion is to tailor your working approach to the bet." How you develop the idea of the bet and how you implement the bet should vary based on the nature of the bet, the uncertainty of the opportunity, the uncertainty of the solution, urgency, size, allowance for failure, level of collaboration needed, and etc. There's no single agile prescription that's best for every kind of bet. John explains the anti-pattern of when companies "lack any sense that the things they are doing have different characteristics. They try to use a mono-process for everything." "Impact: picking less-than-optimal ways of working." And "Mono-process kills companies." 

Don't bother trying to do agile "right" and don't fret over other people's advice when it doesn't match your context.

Constellations and Deep Democracy

Constellations can be used as effectively with just one or two statements as well as with dozen, making it an effective tool for Deep Democracy.

One of the tools I picked up from Lyssa Adkins' book, Coaching Agile Teams, is called Constellation. (It really should be plural, Lyssa.) Briefly, the purpose of Constellations is to gain a better understanding of your team and their individual preferences, values, interests, or opinions.

Mechanically Constellations works like this: Put something in the middle of a big open room. Have everyone stand in a big circle around this object. Explain that you are going to read some statements. (Such as: "I like Scrum." "I get value out of our retros." "We should TDD more." "I think Agile will work for us." Etc.) Instruct the team to orient themselves closer or further away from this object after each statement is read to represent the extent to which they agree with that statement. If they agree, move in. If not, move out. Tell them to not over think it. Tell them to stand where their heart and head tells them to stand, not where they think they should stand. Then have the team observe the Constellation of people and discuss what it means. There are some considerations for how that discussion is facilitated, but that's a topic for another post.

The way it's described in the book is that the facilitator might want to read numerous statements. This is a great way for a team to get to know each other. I've done this exercise with about a dozen different teams. Now, I'm no longer surprised by what I find. A common surprise to the team is when they discover that their Product Owner doesn't like to run the demo but that someone else one the team has been dying to do it. Another: There's often an ah-ha moment when the team begins to understand that the quiet person just needs time to think before he speaks.

Anyway, I've done this lots and lots and have used 20 to 40 statements each time. Some of the resulting Constellations aren't interesting. I move on quickly and don't have discussion for those. Some are very revealing. I have a short discussion on the spot for those. Even the teams that are well established have interesting revelations using this technique. The number of questions and amount of discussion is bounded only by the team's willingness to continue standing.

Building on Michael Spayd's talk on Deep Democracy at Agile 2009, during the Atlanta Scrum Gathering in 2012, Lyssa Adkins and Michael Spayd led a Constellations exercise and only asked 2 questions.

They used the technique for Deep Democracy (Arnold Mindell). They were working with a large random group of people from the conference; I usually work with a team that has at least a little work history, and often a long history with each other. They facilitated the discussion carefully, more carefully than I would with a known group. Lyssa started with the inner ring and encouraged all voices to be heard, one ring at a time, an important aspect of Deep Democracy. Lyssa was careful to give voice to each ring in the Constellation and to set the ground rules: don't state that someone else's opinion is wrong or challenge someone else, use "I think" or "I feel" or "my opinion is", all opinions are valid, I will step in if you violate these rules, etc.

What I learned directly from Lyssa that I didn't get out of the book is that the Constellations technique can be useful with just one or two questions. In particular, it's useful when you have a specific narrow topic, even a controversial one -- when Deep Democracy is needed. This can provide a safe environment in which to speak and allows the facilitator to manage diverse opinions in a logical progression. It's also useful to reduce the number of questions as the size of the team grows (since it takes more time to allow more people to voice their opinion).

I would love to hear about your experiences with Constellations and Deep Democracy, together or separately. Are there other variations on this theme? Other ways to use this technique?

For the Sake of a Productive Retrospective

Even good, competent, and valued people sometimes have an off day, make an ill-advised or selfish choice, or are just plain mindless.¹

Like many others, I'm not quite satisfied with the Retrospective Prime Directive as it's written. I understand and appreciate Dinwiddie's explanation of it, but as a useful tool, the directive doesn't strike any chords for me. What I think the directive is trying to say is:

Retrospectives are not about blame. They are about moving forward.

So why not just say that? I'm fond of Tobias' take on it (with another phrase² inserted):

We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so.
     Bearing in mind that there are many factors of which I am unaware.²
Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?

Whenever I'm working with a team that is still struggling to create a safe environment, I also suggest "quietly considering" this:

I will ensure that we have a safe environment
in which we can each own up to our own mistakes own our own
and endeavor to not be defensive if someone else points out my mistakes.
If someone gets defensive, we'll assume that the environment is not safe
rather than assume a personality flaw.

1. Stone, Patton, Heen, Fisher, Difficult Conversations: How to Discuss What Matters Most, Penguin, 2010, page 287.

2. Wallace C. Ellerbroek, MD, “Language, Thought, & Disease”, The CoEvolution Quarterly, No. 17, Spring 1978, page 33.

How to Engage an Agile Coach

I'm often asked by companies how they can engage me as an Agile Coach. What would you do? For how long would you be there? How long would it take? My response is always tailored given their specific context. Each situation is different. However, here's an attempt to give a very general response to that question.

In short, you can pretty much design your own ideal engagement with an Agile Coach. I'm sure there is a coach out there that will be willing work with you toward your goals or activities, whatever they are. Although some coaches only do deals of a certain size or of a certain type of work, there is generally lots of flexibility to be found.

For example, depending on what you are after and on your budget, the number of days and the frequency of involvement can vary.

• Very limited: A day or a small number of days
• Regular or periodic: A day or three each iteration
• Full time but temporary: like 1 to 6 months
• Full time permanent: unbounded

A single small team that just wants some outside eyes once, or once in a while, can get help with a small budget. Involving the coach with more teams and more people typically means more days are needed to accomplish your improvement or transformation goals. An organization looking for coaching for many large non-collocated teams is a much larger deal.

The engagement can be just as simple as "hey, I think we're doing pretty good, but we'd like to have a fresh set of eyes to point out what we're overlooking." That could lead to any number of recommendations that the team is free to tackle on their own. Or that could lead to an additional engagement designed to address some specific issues. Or an engagement can be as broad as be here every day and work with us for three months.

As for the type of work that a coach may do for you, the work of the coach may be in the form of training and workshops, mentoring, coaching, consulting/advising, or getting his hands dirty.

Here are some examples of what you might engage a coach to help you with. This is not an exhaustive list.

• Limiting WIP and setting limits
• Using Kanban and Lean metrics
• Eliminating delay, prioritizing work via cost of delay, and improving flow
• A3 problem solving
• Demonstrate many retrospective techniques, lead retrospectives, mentor others as they use these techniques
• Spotting and removing impediments and managing risks
• Creating and sizing / estimating the release backlog, using velocity
• Identifying the MMF set
• Story mapping
• Project chartering, vision casting
• Planning and preplanning
• Communicating
• Using BVCs and information radiators, addressing why they are stale and not being used
• Space and facilities
• Pair programming, SOLID design, emergent architecture, TDD, CI, continuous deployment, etc.
• Defining Done
• Coding katas
• Design patterns, refactoring, etc., for example through lunch-n-learns
• Designing and tasking-out of stories; design review; shared task list and working as a team on each story
• A myriad of dysfunctions
• Issues with interpersonal relationships, working agreements, appreciation, active listening and working as a genuine team instead of as a simple working group, team accountability
• Team goals, rewards, recognition, MBOs and other HR/management policies
• The management role, including management influence and interference, people management
• Scrum of scrums, multi-layer scrum and kanban
• Working effectively with remote workers
• Project portfolio management
• Documentation
• Q&A - Address the team's concerns and questions such as:
  
  • "How should we handle defects and minor changes in our specific context? Plan them and estimate them? Treat them as high priority and don't plan/estimate?"
  • "What should we do if we don't finish a story in the iteration?"
  • "On what day of the week should we have planning?"
  • "We're considering changing the way we do xxxxxx, what do you think?"
  • "We have work left over at the end of each iteration. What do we do?"
    

This list could go on and on and on. Each coach has their specialties and strengths and would come up with a somewhat different list.

Give me a call and we'll set up a time to craft an engagement of your own, suitable for your needs and your context.

What is an Agile Coach?

This is an unusual post for me in that it's just a quote from someone else. I wanted a pointer to it from my blog, so here it comes. Brian Bozzuto over at BigVisible describes an Agile Coach thusly:

An Agile Coach is a professional, working internally as a full time employee or externally as a hired consultant, who is working to help realize a profound organizational change to better embrace the values and principles espoused in the Agile Manifesto. Specifically, this is a person who is doing a blend of a number of activities based on the situation to help that organization overcome barriers to change – be they technical, organizational, or skills based. One of the key values of such a person is their ability to play different roles based on the context, and a high level of awareness of these different potential roles can be a critical factor in their effectiveness.

You should go read the rest of Brian's article.

Off the Road Again

I'm back! I'm definitely back in Atlanta and hopefully back into my blog as well. As of this month I'm once again focused on the Southeast, but now as an independent lean and agile coach.

Working with Pillar Technology was fun. They are a great bunch of people and have some amazing programmer talent. I'm glad I followed Mike Cottmeyer to Pillar and really enjoyed working with him. I can't thank him enough for the help he gave me early on. I'm appreciative of the slack and the support Matt VanVleet gave me. Working with Pillar also gave me lots of opportunity to work with and be challenged by Matt Barcomb. Always a plus. But going independent gives Pillar and I some relief from the costs and pressures of my travel to the Northeast.

I am engaged with a great client here in Sandy Springs but my calendar through the end of the year isn't full. Help me fill it! I’d enjoy talking through your projects and the challenges they bring and how we can work together. Let's meet up. Give me a call or drop me an email.

These last couple of years I've re-learned how passionate I am about coaching and training. I've never had more joy from work than when I help a team improve their environment and see their appreciation. I've been blessed to be able to do that as part of my job from '99 through '09. And I have been even more blessed to make it my sole focus since then.

Each context is different, a unique challenge requiring a unique prescription. I'm looking forward to bringing this passion and experience to new challenges, in your context, to your environment.

Bias

The other night I found a credit card receipt from The Pampered Chef. This is one of those Tupperware party kind of things that women go to and overpay for stuff because they feel guilty for insulting the party giver if they don't buy something. I told Laura before she went to that party to not buy anything. I had just started my own business and had made it clear in a Family Meeting that we're going to restrict our spending until I see what kind of cash flow we're going to have. We were to buy nothing unless we could eat it.

So, as Laura was heading off to this Pampered Chef party the other day and I told her not to buy anything, she told me she was getting a free meal out of it so I should relax. I can't remember if she explicitly agreed to not buy anything but I know she heard and understood my request to not-buy-anything.

What was she thinking? I stewed over this all night. Laura was already asleep when I found the receipt. I didn't think I should wake her up to discuss this. I knew that wouldn't go over well. So I stayed up thinking about how I'd approach this in the morning.

I avoided my wife for a while the next morning. When I could avoid her no longer I told her I thought we agreed that she wasn't going to buy anything at that party. Laura calmly told me she bought me a birthday present. A $22.26 birthday present. She bought something inexpensive which is exactly what I would have wanted her to do. And I bet it's an incredibly thoughtful gift.

Man did I feel like a heel.

I've been reading lately about biases. In The Principles of Product Development Flow, Donald G. Reinertsen says that psychologists know that "…[humans] have a general bias to interpret the behavior of other people negatively."

There is a nice list of cognitive biases on wikipedia. Some that are particularly relevant to this topic are:

• Actor–observer bias – the tendency for explanations of other individuals' behaviors to overemphasize the influence of their personality and underemphasize the influence of their situation (see also Fundamental attribution error), and for explanations of one's own behaviors to do the opposite (that is, to overemphasize the influence of our situation and underemphasize the influence of our own personality).
• Fundamental attribution error – the tendency for people to over-emphasize personality-based explanations for behaviors observed in others while under-emphasizing the role and power of situational influences on the same behavior (see also actor-observer bias, group attribution error, positivity effect, and negativity effect).

These are amplified by an additional set of biases:

• Bias blind spot – the tendency to see oneself as less biased than other people.
• Negativity bias – the tendency to pay more attention and give more weight to negative than positive experiences or other kinds of information.
• Availability cascade – a self-reinforcing process in which a collective belief gains more and more plausibility through its increasing repetition in public discourse (or "repeat something long enough and it will become true").
• Halo effect – the tendency for a person's positive or negative traits to "spill over" from one area of their personality to another in others' perceptions of them (see also physical attractiveness stereotype).
• Illusion of asymmetric insight – people perceive their knowledge of their peers to surpass their peers' knowledge of them.
• Illusion of transparency – people overestimate others' ability to know them, and they also overestimate their ability to know others.
• Illusory superiority – overestimating one's desirable qualities, and underestimating undesirable qualities, relative to other people. (Also known as "Lake Wobegon effect," "better-than-average effect," or "superiority bias").
• Ingroup bias – the tendency for people to give preferential treatment to others they perceive to be members of their own groups.
• Projection bias – the tendency to unconsciously assume that others (or one's future selves) share one's current emotional states, thoughts and values.

But why would I assume the worst of my spouse? That's ridiculous. Of all the people in the world, I should not have these biases towards her. If this can happen within my family, how much more so can it happen in the workplace?

What I learned from this experience is how real these biases are and how on-guard we as humans need to be. Poor communication skills (or just a simple mismatch in communication styles), fear of reprisal and fear of confrontation can make matters worse. The problem with poor communication is we always assume it's the other person who can't communicate.

Kerth's Retrospective Prime Directive hints at a solution:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

How do you encourage that other than posting it and reviewing it before retrospectives?

And in Coaching Agile Teams, Lyssa Adkins says to "...create a positive regard for them. Do this by changing your view of them. Regard the person as a human being with hopes, dreams and desires (like your own) so that you can approach them with love and compassion..."

How do you foster this in an organization?

Reinersten offers this advice:

This tendency [toward bias] is reduced when we get to know others as complex hum beings, much like ourselves. Task related (job related) communications by itself is not enough to create an appreciation of this complexity. Non-task-related interpersonal communication that comes from colocation is key to developing cohesive teams.

Chats around the water cooler, going out to lunch together, after-work drinks, post iteration and post release celebrations and kick offs beforehand are good things to try. Fantasy football and office baby birth date/weight pools and the like can help. Team working agreements (norms) posted on a big visible chart can help. Praying daily for your co-workers by name helps remarkably well. Other ideas?

We can bring up the elephant in the room in our retrospectives, but other than just hashing it out, what techniques or exercises have you found useful?

Most of us don't enjoy a tense and confrontational workplace. Likewise, most of us don't recognize how much we ourselves contribute to that situation.

What additional advice do you have to combat bias, increase non-task-related interpersonal communication and improve interpersonal relationships?

Sizing with Incomplete Information

Some teams that I work with that are new to agile struggle to size their first big agile release. The team is often still trying to gel, assimilate new members, and increase their velocity while spending lots of time creating, understanding and refining the product backlog. One of the challenges they face is learning to estimate with imperfect and incomplete information. How quickly they adapt seems to depend on what they are presented with during their 1st agile/relative estimating session.

Some teams new to agile start with a new project and need to estimate the whole thing with little info, perhaps during a "sprint 0". Those teams are forced to deal with ambiguity right from the start. From then on they accept that they'll have to estimate fuzzy stories. This helps them accept that stories will change, both the details of individual stories as well as what stories make up the backlog. Sometimes revealed detail changes an estimate (up or down). Sometimes it doesn't. But that's life and we can deal with that quite well on an agile project. More on that in a moment.

Other teams I work with already have a project well underway. They have a product in maintenance when they go agile. They've got lots of small and well understood stories. Or if they aren't well understood, they can get that way quickly. The 1st stories they estimate are detailed and certain. But a day will come when the team is forced to estimate some new release or some new product with less than full information. That can be frightening. As these estimates are recorded, we can note that the estimates were made with less info and certainty, but that seldom provides much comfort to this type of team.

However, what you'll find (on a healthy team) is that:

• Large estimates on the larger stories tend to drive the Product Owner to decompose those behemoths and then ask for new estimates.
• The team is allowed and even encouraged to revise the estimates (up or down) as more information is revealed.
• Many of the estimates will not need to be revised. Any additional detail or certainty often doesn't affect the estimate after all.
• Consistency is good, but accuracy and precision are not necessary. Wrong estimates have an offsetting impact on velocity. That's the beauty of using relative estimates and the empirically measured velocity to compute a release end-date -- an incorrect increase in one gives an offsetting decrease in the other.
• There will be details that are overlooked. Developers tend to be optimistic with estimates. But that too will soon be taken into account in the velocity (unless you implement all the well understood stories 1st and always save the others for later). (Do note, however, that the shorter your release is the shorter your iterations need to be in order for a change in velocity to be noticed in time.)
• And management will heed the warning signs when presented with the estimates and velocity and not pressure the team into short-cutting craftsmanship, quality or sustainable pace. (Remember that I said /healthy/ team.)

Seeing is believing

On the second type of team this learning happens slowly. You can have a conversation around these things to try to speed up the learning or to provide some comfort. It's certainly worth trying. But don't be surprised if your convincing arguments are met with disbelief.

Scrum Master? Or coach?

I've seen many more open positions for Scrum Masters than I have agile coaches. I've been asked to be a Scrum Master more than I've been asked to be a coach. Is it just marketing? Scrum has market share; it's widely known and understood. Does the market distinguish between a Scrum Master and a coach?

I often find that companies looking for a Scrum Master want someone to run their standups, planning and retrospectives. They want an agile project manager to manage the projects, to report status, to track budget.

They seem to not want the change agent and process improvement aspects of the Scrum Master role. Or, they want a little change agent and process improvement to happen as long as it's directed towards the team and not management. And anything directed toward the team mustn't involve facilities or pair programming. Or HR. Or empowerment.

But isn't that what a Scrum Master is supposed to be, a coach?

I dislike this dichotomy.

There was a recent discussion on the Agile Alliance discussion group on LinkedIn about the career growth path of a Scrum Master. The question was, is there a growth path? I liked Irene Michlin's response:

Have they all brought their teams to "performing" stage? Process is perfect, as in "nothing left to improve" a constant motive in retrospectives?

They are either all very brilliant and need to go and become trainers and coaches, or they don't get what it means to be a Scrum Master.

If there is something left to improve, then your job as a Scrum Master is not done -- you haven't mastered Scrum Mastering. Or, at least you aren't done coaching. But there is that distinction again.

I dislike this distinction between Scrum Master and coach. Unfortunately, I find it useful. It's a tell, as in poker. It helps evaluate an opportunity. It's how the conversation goes. "No, I won't be your Scrum Master, but I'll gladly train your team to handle this role. I'll be your coach. Are you ready for a change agent?" Sigh. I find it useful, therefore I tend to perpetuate the distinction.

What should we do? Not use the term coach and elevate the term Scrum Master? Should we live with it because it is what it is? Once the dichotomy is there it's not possible to kill it. Is there a useful distinction between the two?

CAN: Shifting the Voice of the Business to the Team

I've been thinking about Mike Cottmeyer's "12 Keys to Success with Agile", specifically his bullet #3, single voice of the business, where he says "This cannot be shifted to the team..."

It can.

Earlier this week Scott Chacon of GitHub presented his approach to projects, called Developer Driven Development, in a keynote address at CodeMash 2011. I won't try to explain DDD here, since the details aren't germane to this post.

However, key to DDD is that you must have careful hiring practices, careful to the point that you only hire people that already demonstrate a commitment to the project and possess great knowledge of the domain. (My words, not his, but I think he'd agree.) Hire those that are already involved in the project or in related ones. Clearly, to be already involved in the project before you are hired likely implies you are either involved in an open source project or are an actively involved customer or user of the product, be it open source or commercial.

Can that be applied to Corporate America? Not completely sure, but we can certainly apply some lessons. If your team hasn't already caught the vision, you need to help them catch the vision. This is important on any project, agile or not. But its importance is indirectly proportional to the extent to which you have an effective voice for the business involved with the team. That is, the less that the team understands the business need already, the more that vision casting is needed. The more that the team knows the business need own their own, the less involvement the team needs from "the business".

I've been on at least one team of note in Corporate America that the single voice of the business was successfully shifted to the team. In this case the team sold the business on a need. The team was given the leeway to run with the idea. Each person brought to the project what they thought the project needed. Each person on the team had a voice in prioritization. Anything that was to get done had to have the support of the team. (So, this wasn't a free-for-all to the extent that an open source project would be. Everyone did not go off and build whichever feature they wanted. The team agreed to the iteration's backlog.)

This worked because the team wanted it to. We wanted to keep doing what we were doing. We liked the product, the project, the team. To keep it going we had to demonstrate value to the organization that was paying the bills. So, we listened to those using the product and took their needs and suggestions into consideration.

It worked much like the open source model: I build what I want, what is interesting to me. But motivation is multifaceted. I'd like help from others, so I have to consider their interests. I'd like my product to be useful, to be used. I'd enjoy a little fame or appreciation from others. I'd like enough money out of the project to take money off the table. So if I'm relying on the product to pay the bills or support my multifaceted motivation, then I'm going to listen to my users and supporters.

It's going too far to say that you cannot shift "single voice of the business" to the team. A trusting cross functional team with empowered team members sharing accountability who have the vision can BE the single voice of the business.

Wearing the Right Hat

A Scrum Product Owner at a client of mine once told me he didn't trust development to build what he wanted built. Sadly, I find this quite common with the more technical POs. The lack of trust was largely due to his negative experience with some other dev team at a different company. His concern was that future value would be blocked by using a simplistic approach now. This PO therefore stepped way over the PO/DEV responsibility line into specifying some of the "how" for a set of stories.

Lack of trust is a significant issue. I could have told the PO that he needs to be able to trust the team. I could have suggested he create opportunity to build that trust, or change the team. Either way, that would take some time and we can work on that. But that's not the focus of this post.

And I could have explained emergent design and the danger of over-architecting things now. I could have told him YAGNI, but have also said that it is okay to share the big-picture vision with the dev team. That it's okay for the dev team to think about where they are headed long term as long as they "pay as you go" and not design and build too much up front. But that's not the focus of this post either.

The focus of this post is that I told him it was okay for him to not trust the developers for now and that it was okay for him to step over the line.

Now, before you take away my Agile Badge, let me explain myself.

Product Owner	Architect

I told the PO that if he is technically capable and can pull it off, then he can AT THE APPROPRIATE TIME review development's planned approach and make suggestions. I told him he can have a PO hat and an architect hat, but that he can only wear one at a time and he needs to wear the correct one at the correct time. He must wear the PO-only hat and only the PO hat during the planning game. Once the business requirement is sized, split, resized, scheduled, and planned, he can visibly remove his PO hat and put on his architect hat during the design and tasking part of the sprint.

In this case, I told him that I believe he is wrong and most likely doesn't need what he was requesting and that what he was requesting will greatly complicate the design and require much much more code than necessary. There was a better approach. Nevertheless, I didn't tell him not to put forth his ideas. For me, it's just a matter of timing.

What would you have done?

My Road to Agile

For those of you without the patience to read yesterday's long post, here is the abridged version. My route to agile wasn't overnight.

Fist exposure to an automated regression test suite in '89 (with the IBM 3174 Communications Controller).
Many years of coding and laboriously testing stuff by hand.
Wanted to try my hand at management in '96.
Project managed wrongly what could have been a nice agile project.
Felt ignorant.
Started studying.
Went back to programming.
Fell into an XP project in '99.
Fell in love with XP.
Studied it.
Tried to spread it.
Practiced it on a number of projects.
Wrote about it.
Spoke about it.
Disappointed people didn't flock to it.
Wanted to try my hand at managing in an agile fashion in '05.
Did much better.
Wanted to practice it on more projects, so became a coach for hire.

The moral of the story:
Consider all that led up to you buying in. Then guide and encourage those you work with, but give people space to find their own road to agile. Have patience with those you coach.

photo credit: Tomasz Wiech

How I Got Into Agile

This is long, but there is a moral to the story.

I had been programming for several years when I became tired of supporting the PPP and Frame Relay code in IBM's first router. No, that's not it. What really drove me away was the threat of having to pick up support for LU6.2. Maybe it wasn't LU6.2. Maybe it was something else, but it was definitely SNA. That's not the direction I wanted to go in. I wanted to work on IP. Any part of IP. I'd have been happy supporting basic IP, UDP, TCP. Developing any of the routing protocols would have been great. That's where the future was going to be. SNA? Yuck.

Prognostication in the early '90s -- score one for me.

I pleaded with the manager of the IP group to take me on. He had no openings. Or he no likey me. Or I had no IP knowledge. Whatever.

My manager at the time was Tom, a great manager and a real character. Tom was often railing about how many worthless meetings we had and how many people we had in them. Tom wrote a program in those days to compute the cost of meetings. All you had to know was the salary bands for the various levels and what level each of the attendees were -- stuff most people knew. Today you can get a program that does this for your iPhone. I digress. Tom was disappointed by my desire to leave his group, but was supportive in helping me find a place where I could grow and be happy. We'll come back to Tom in a bit.

A good friend, Sam, was working in the same division on some Smalltalk apps. Cool stuff, I thought, but I didn't realize how cool. Smalltalk will never make it, I thought. "What you are doing is kind of hard to buy into", I thought. C++ is where you want to be. I later said the same thing about Java.

Prognostication in the mid '90s -- Although Smalltalk didn't make it in the market, it would have been the thing to learn. Score one for me against Smalltalk's market-share; But -1 for being against Smalltalk as an important language; -1 against Java.

Sam's manager, Joe, offered me a position and made hints toward his retiring soon. I was thinking that if I couldn't work on IP I just might as well go into management. So I joined up. Sure enough, Joe very soon retired and handed the reigns over to me.

Now back to Tom. Not one month into my new role as manager, something was found to be lacking in our software. I don't recall whether it was a bug or an enhancement request. Whatever it was, Tom needed it for his product. My former manager, Tom, was now my customer. So, wanting to be a strong manager with a backbone, one who could make the tough decisions and stand by them, protect his team and his schedule, I said no. I either said simply 'no', or I gave him a delivery date way out in the future, which might as well have been 'no'. Although Tom was the man who helped me get this job, had given me a promotion along the way, and was now my customer, and although his request was quite small, I said no. When I became a manager I threw out the window all I knew about being collaborative. I stopped practicing what I believed in as a developer. I did what I thought managers were supposed to do. Tom wasn't my only customer. I had bigger customers with big projects and big demands. Tom was furious.

What I didn't know then was that this team of Smalltalkers was quite agile. Of course, we didn't have that term back then. Gosh. This was in the midst of the ISO 9000 certification heyday. I had to document our process. I never new managers had to do that kind of stuff! "What have I gotten myself into?" I thought. I really didn't know how to describe our process. I kind of knew what we did, but document it? I knew I'd need help and thought the team would be as annoyed as I with this task. I dreaded asking the question and I didn't fully understand the answer: "Iterative and Incremental" with a few other words wrapped around it. So, I wrote down Iterative and Incremental on the process document, wrapped a few other miscellaneous made up words around it, then whipped out MS Project and got my project plan in shape. And it was a doozey! Spread out, the project plan covered a very large conference room table. I was so proud. (But it was really quite disgusting.) I could demonstrate when we'd be done (well after everyone wanted it), how I carefully put the plan together (with painstaking detail), and how many more expensive Smalltalk contractors we'd need (don't ask). I knew nothing of negotiating scope. I project managed wrongly what could have been a nice agile project.

I knew I was missing something. I felt ignorant so I started studying. I went back to programming while trying to figure out what I was missing. Steve McConnell's Rapid Development and Steve Maguire's Debugging the Development Process and Fred Brook's The Mythical Man-Month stand out as books that began to point me in the right direction.

Then in '99 I discovered jUnit and very soon after got invited onto an XP team, thanks to Greg Houston. Greg would say I resisted XP. Perhaps I did. But I soon fell in love with it after I got used to pair-programming. That took some number of months. Then I began studying XP, writing about it and tried to spread it. I was there at the start of XP Atlanta, which was led at the time by Obie Fernandez and which we later renamed Agile Atlanta. I attended XP Universe in 2001. I practiced XP on a number of projects then started speaking about it within the company, at a local user group and at a nearby college. I also submitted an experience report and a research paper to XP 2003 in Genova. I knew I'd be using agile for a very long time.

I thought I could convert people, that people would readily see the light and that in just a few short years everyone would be doing XP. They would be won over by my passion if nothing else. People would flock to our XP user group. jUnit would lead people to XP and the XP books would convert everybody. And I knew this would happen throughout the industry.

Prognostication in the early '00s -- score one for industry wide fear, uncertainty and doubt with a big helping of resistance to change.

My Prognostication Score: 2 out of 5.

After some years of being an agile developer and advocate in an organization lukewarm to the concept, I decided that I wanted to get onto a team where everyone really wanted to do XP and management supported it. And I wanted to try my hand at managing again, this time in an agile fashion. I found such a team to manage and I did much better this time (though considering how bad the first time was, this might not be saying much). This project eventually brought me to my desire to practice lean/agile on more projects, so I became a coach for hire.

So that's how I came to agile and here's the moral of the story: I think it's important to remember the route you took and how long it took. For most of you I suspect it wasn't really overnight. It might seem that way on the surface. "I got the book, read it, tried it, loved it, all overnight." Not likely. There was a road that got you prepared for the switch. Those we work with, those we try to coach, are on their own road. Have patience with them.

photo credit: Tomasz Wiech

Getting Your Team to Take Short-Cuts

I was once in a software product company teetering on the edge of financial problems. And who in this business hasn't been? We had only one customer of consequence and they were unhappy with the cost of what was essentially custom development. This turned into pressure to deliver more features per dollar of cost. I.E., to develop the features faster. Right away. Pronto. How do you make a team of programmers immediately faster?

I had already looked at our process and had evaluated our use of best practices and our quality. We were following XP well, so if you subscribe to XP being a good set of best practices, we had that covered. Our development speed was average for enterprise software vendors using Java/Swing. But our quality was best in class. I am basing my evaluation mainly on the work of Capers Jones' recent books and metrics gathered from the team's history. That's about as objective as I could get. I also considered what I know of the industry and other groups, a more subjective measure. From what I've seen since, that team's velocity was actually quite good. To get the performance boost, there was only one thing left to do.

You may be able to get a short boost of speed at the expense of incurring technical debt, or, more technical debt than normal as your case may be. But to do that, to get a short boost in the rate of delivered features, you’ve got to paint a good picture of the situation to development. Why? Because you’ve got to get them to understand the seriousness of the situation and give them a vision of how long or how much or how many of what is needed so that they can buy-in to changing their habits and their preferred, ingrained and natural method of working. Saying "preferred way of working" makes this sound like a choice. A team's preferred way of working is indeed a preference, but it isn't much of a choice. It's a compulsion. You must realize when you demand speed, when you ask the team to take short-cuts, you are asking them to work-differently. You are asking them to work in an unnatural manner.

To illustrate: You are most likely right handed. Pick up your pen with your left hand and write a long letter to your spouse or your mom. Get the picture? The unnatural is difficult to achieve.

In Complete Control and Not Controlling

My regular followers know I post on lean/agile IT topics as well as bicycling and faith-based views. You agile IT guys – hang with me and I’ll tie a little agile into this before the end.

One of my favorite bloggers is Joe Gibson, co-author of the Ant Developer’s handbook. I like his opinionated writing on topics of interest to me: Java, Scala, Groovy, Ruby, Lisp, Koine Greek and religion. His own translation of old Greek manuscripts and commentary on other translations are quite interesting.

Joey posted a few days ago on how those who use the Bible too often "selectively edit scripture to fit a particular message, or to fit nicely with a pithy saying." This is essentially eisegesis (to draw in) rather than proper exegesis (to draw out). That is, reading stuff into the text rather than more appropriately getting out of it what the author intended. I was passionately into his post, in complete agreement.

Now Joey and I don’t see eye to eye on a number of matters of faith. Yet even when we strongly disagree there is usually some point in his writing that I strongly support. So I was with him right up until he said this:

...the minister was going on about how we need to "stop worrying" and just know that "God is in complete control" and blah blah blah… I’ve always hated that way of thinking. I despise the Sandy Patty song, "God Is In Control," because I do not believe that is true. (Bold emphasis added.)

So I crafted a nice and timely, intelligent, thorough and sound response. Joey’s blog seems to have a multi-step click-post, preview, click-post-again are-you-sure, captcha phrase kind of process that I obviously flubbed because my response never made it to the blog. Time has passed and now I’m here rambling on, many times over what I so eloquently put in my initial response.

So back to Joey. Joey’s next statement shows a misunderstanding of "complete control" and he has made quite a leap.

...if you believe that he is in "complete control" then you have to take that to its logical conclusion. If you believe that every good thing that happens to you is because God wanted it to be that way, then you must also accept that every bad thing that happens to you is because God wanted it that way.

The error here is the assumption that to believe that God is in complete control is to believe that everything that happens to you is because God wanted it to be that way. Let me explain. My kids run wild at times. This is not what I want. "Hey kids! Run around the house, fight some, and drive your mother and I crazy." It’s not what I want, but that’s what happens. I give them some room to exercise their free will. Notice I said some room. I have boundaries and my kids test them. I’m not controlling my kids, at least not most of the time. At least I try to not be controlling. Anyway, I assure you I’m in complete control of the situation at home and am quick hand out corporal punishment when boundaries are reached. In control, but not controlling.

A good agile manager or agile architect does likewise. They aren’t controlling. Rather, they set some boundaries, and otherwise let the team self-organize. They give the team much latitude to decide how to get the work done within some boundaries. Rather than hand out tasks, they encourage the team to select their own work tasks. Yet they remain in complete control.

[Sorry – I have no analogy for you bicyclists. I control my bicycle, but am never fully in control, much to the disappointment of my Dunwoody Cycling buddies.]

Notice that God told Adam that he is free. Free to eat of any tree in the garden but one. God gave man free will. But God also set some boundaries. So Adam was hanging out in this cool garden in complete fellowship with God Himself. But Adam poked God’s boundary so Adam and all of us now suffer the consequences. God’s will is for man to love God and obey his boundaries. God sends no one to hell. God’s will is that no one perishes, but that everyone accepts his free gift of salvation by faith in Jesus Christ alone. But for love and obedience to be real, there has to be a choice. A choice to disobey. Therefore, God is not controlling our every action and decision. And we will all suffer the consequences of my sin and your sin and Adam’s sin and the sin of others. God does not wish this on any of us.

Witness Job. God allowed Satan to bring disaster on Job and his family. But God set boundaries for Satan. "Go this far and no further" in effect. So God certainly allows bad things to happen, within boundaries. I wouldn’t wish Job’s trials on anyone, but I’m sure glad it happened. There are a lot of lessons for us to learn at Job’s expense, in particular, that God is in control.

Boundaries – God is not going to allow us to interfere with his plans. We can’t blow up the earth, for example, and kill everyone. We can’t wreck the environment such that we all die. Unless, of course, that is God’s plan for how the "first earth" will pass away (Revelation 21). But in that case, there is nothing we can do to stop it from happening either. But in any case, we’ve got boundaries and God is in control. We can certainly kill many and do big-time damage. But we can’t mess up his plans. God will intervene.

God does directly intervene at times. See 1 Kings 22:23 -- "You see, the LORD has put a lying spirit into the mouth of all these prophets of yours, and the LORD has pronounced disaster against you." The Bible says that what Joseph’s brothers meant for harm, God used for good. And there are the New Testament miracles.

This is getting long and a bit rambling, and my argument is beginning (or perhaps continuing) to trail off, so rather than wrap it up and put a nice bow on it like Joey does, I’m just going to quit here.

It’s The Values That Matter. Or Maybe It’s The Culture.

Mechanical Agile^[1] is when one tries to follow the process with no understanding of the theory behind the practices, with no understanding of why it is designed as it is. Daryl Kulak wrote the most excellent post "Five Symptoms of Mechanical Agile". Any team exhibiting the conditions represented there, certainly need help. But truly, any team having those problems is pretty far along. They are trying to be agile but are misfiring on some point. Many teams don’t get that far because they just don’t get it.

As with XP, Scrum can be followed mechanically, without any understanding of why. Have some iterations, estimate in points, make a pretty burn down chart, do a demo, and maybe a retrospective every other sprint “because we just don’t see the value of doing it every sprint”.

And they totally miss the point of agile.

Ken Schwaber said that teams implementing Scrum need to "...recognize the even higher degree of control, risk management, and transparency required to use Scrum successfully. I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it." (Emphasis in original.)

I agree with Ken. More is needed than is evident to most teams. In the context of the quote, Ken is pointing out what is needed to supplement Scrum in lieu of "controls and safeguards of waterfall and predictive processes." And there is more needed beyond just that.

Same thing with Kanban: model the process, put some swim lanes on the wall, and maybe put some WIP limits in. Visualize the workflow and break a log-jam from time to time.

And totally miss the point of continuous improvement and the metrics that enable such.

In his article, Daryl wrote that if you fall into mechanical agile, "[only] addressing the attitude of thinking of people as machines will help you." Daryl touches briefly on the topic of culture in his article, suggesting that cultural issues can be a problem and the need to change the culture as a solution.

Jeff Patton says that "Agile development is more culture than process". That is, if you ain’t got the culture, your Scrum/Kanban team may not be agile. Pay close attention to agile values and mismatches between those and the organization’s values.

That’s the key ingredient: the agile values. Or maybe it’s the agile culture. Not sure if values drive the culture or whether it’s the culture that influences the values. Either way, they go together.

When I teach XP in a time-limited situation I’m always torn between focusing on the four core values versus the practices. The practices are easier for people to understand. They add some value by themselves. They are concrete and give the audience something they can grab on to. But picking up the practices don’t make one agile. It’s the XP or Scrum or agile values that give you a fighting chance of understanding what you are doing the practices for. But starting with the values leaves most people scratching their heads. They don’t resonate with the average software practitioner.

The best chance you have of changing a culture, then, is with successful agile projects, mechanical or otherwise, punctuated with judicious and timely explanations of the values.

1. Dr. Hong Li coined the term Mechanical Agile which was first used publically by his co-author in an upcoming book, Daryl Kulak.

Pair Programming, the Breaststroke

I’ve been working on my swimming for a few years. When I first started attempting the butterfly stroke, I found it very difficult. It required a lot of strength and technique that I did not have. I was lucky to make half a lap. Test Driven Design is like that. If you haven’t been shown some techniques and aren’t real strong with refactoring, with useful design patterns and with SOLID design principles, TDD is difficult to pick up.

In each case, you need a good coach. While struggling with my butterfly, I watched a few videos and read up on it in an attempt to improve my technique. But it’s just not ‘there’. And it never will be. My TDD skill is the same way. Underdeveloped. No amount of reading will get me where I would need to be with either topic if I depended on programming or swimming for a living. Hence the need for a coach. A coach will examine what you are doing and supply what you are missing or overlooking. A coach will help you build technique and strength.


Other strokes are easily done. Take the breaststroke for example. Anyone can do it. It’s not that strenuous. For years, I did the breaststroke only for fun or to cool-down or to swim to the bottom of the pool. It wasn’t for “serious exercise.” I never saw any benefit as a fitness routine. But then a swimming coach happened to stop by my house and commented on my stroke. I was doing it wrong. My strokes were too long and slow. Wow, what a difference a little technique makes. I couldn’t see my mistakes without a coach. Now, with a more effective pull, I’m quickly winded and building strength.

Pair Programming is like that. There are so many little things in this technique that can render it ineffective. What do most people do with an ineffective development practice? Typically, they drop it. At worst they keep doing it the same useless way, or they quit and then disparage it publicly. But at best, they get someone to improve their technique. Hence the need for a coach. I can watch a pair for a few minutes and usually give them half a dozen improvements right off. Chairs, posture, distance, and desk. Surface, keyboards, monitors and mice. Smells, habits, distractions and dirt. Communication, collaboration, cordiality, and care. Promiscuous, driving, navigating and alignment. A coach will examine what you are doing and supply what you are missing or overlooking. A coach will help you build technique and strength.