Standing Meetings: Estimating, Pre-Planning, Pre-Pointing

It's helpful to have standing meetings. Although they are indeed standing in the photo, in this case I'm not referring to the absence of chairs. I'm referring to regular and reoccurring.

I've found it useful to have regularly scheduled estimating meetings. For two-week sprints I hold estimating in the middle of the sprint in the same time-slot as planning. If planning is every other Monday at 10, estimating is the other every other Monday at 10. (Planning is usually longer, though. Planning usually takes one to four hours, depending on the local situation at my client. Estimating usually takes less than one to two hours, depending on how many stories we feel the need to estimate.) Being careful to not let this become waste, we don't estimate more than necessary just because we have a regular meeting.

But why the standing meeting? Why not just estimate whenever needed? The scheduled meeting disrupts the team less than an impromptu meeting. This is because the team knows it's coming and they plan their day around it. This also affords a bit of discipline that even mature teams can benefit from. It forces the product owner to always be ready to estimate and to always have something ready for planning.

This brings me to pre-planning and pre-pointing meetings. I schedule a standing meeting to occur a couple days before each planning day and each estimating day. For newer Product Owners, this is time for the Product Owner to work with the Scrum Master or Agile Coach (me) to be sure the PO is ready. We don't want to come unprepared and waste everyone's time. Many Product Owners continue to use this time in this way even after our engagement is over. When useful, we pull other team members into our prep to help define acceptance criteria or to split stories.

Regular or Impromptu? What do you do?

Approaches to Retrospectives

I had the distinct pleasure of working briefly with Tim Wingfield a few months ago. Bright guy. We were talking recently about different retrospective approaches. One of his teams was in a rut with how their retrospectives were going. They tend to only be the griping and airing of grievances style and they weren't getting actionable items. Everyone was caught up in the complaints.

The great thing about agile is that you can be agile in order keep from getting into a rut. Each new client has a different situation which gives me opportunity to focus on a one aspect of agile more heavily than at another client. I get to try different nuances each time.

The neat thing about retrospectives is how applicable they are and how easy they are to apply outside of IT. Today I was sharing some of my approaches with a cycling friend whose realty group, Dillard & Company, uses a genuine team approach. I say genuine because they are a team in the real sense of the word. They aren't just a group or loose federation that incorrectly calls themselves a team.

Anyway, I had these approaches in my head and Tim had commented that my retrospective artifact was a little different than what he had seen described in writing so I thought I'd put them down in a blog post.

I tend to use a flip chart for the retrospective when I have a dedicated space in which I can leave a big visible chart. Unfortunately, my clients often lack sufficient space. So I find that I most often end up using a white board and then transcribing the retrospective notes into some tool like VersionOne or into a wiki. I like using the whiteboard during the retrospective, but I don't like hiding the results online.

When I use a flip chart, I find it convenient to draw quadrants. When I use a whiteboard, I just do columns.

Either way, in these quadrants or columns I often write:

• what went well
• what did not go well
• do more of
• do less of

Sometimes I use:

• good
• bad
• do differently

Less often I use SaMoLo:

• Same As
• More Of
• Less Of

I may use "opportunities" instead of "bad" or "did not go well". It depends on the tone of or presence of animosity in the team and whether certain terms are emotionally charged.

There are times when I really want to dig into things and fully understand what's going on. I facilitate the whole discussion. I often start out with "so, what happened this iteration?" Or, "what went well?" Or, "how did it go?" I try to record the essence of what people say. Be a good facilitator. Elicit input from the quiet ones. Try to cover each of the areas at least a little. I may dot-vote for the one or two issues to attack in the next iteration, if consensus isn’t obvious. This approach can take a while. I use this approach the first few times with a client or when we have largish iterations. If people get impatient, I don't use this approach.

Once I'm through that stage I like to switch to this other approach. I have everyone come up to the whiteboard all at once and write whatever they want in any of the columns. I request that they briefly tell someone in the room about what they just wrote. I listen in for themes or things I want to dig into during the discussion that I have once everyone is done writing. I often don't write anything of my own, but I may if I see something important missing. This gets us through the kudos and complaints more quickly so that I can get on to the "do differently" items and find some specific action item to take away. I have gotten a lot of positive feedback on this approach. Everyone feels more engaged. It gets them out of their chairs and their blood pumping.

Another approach is to ask people to write their thoughts on sticky notes. You can then read them or have them read them. You can have the team do an affinity grouping of them. I'm not sure how to keep that approach from dragging on too long, but I can see how it can help elicit input from the quiet ones.

One other thing I like to do before I run a retrospective is skim over what we recorded in prior retros. If I find an issue that was brought up over and over but that never made it into an action item, I’ll just start the retrospective with that and figure out how to solve it.

Other than in that instance, I never exclude the opportunity for people to complain about something. It's important to have a release valve, an opportunity to blow off some steam. But we don't have to dwell on it. Some things you are just not going to solve and other times just mentioning an issue can solve it.

I mix it up because it's important to do retrospectives in different ways. Regardless of how I run it, I always look for one specific, measurable, achievable, actionable action item as an outcome of the process and I make sure it has an owner.

Of course, Esther Derby's Agile Retrospectives book is a great resource for more ideas.

Sticking With It

In the prior century I made several failed attempts to read the whole Bible. I usually quit because I found the language tedious to read and hard to understand. (That, and a lack of spiritual maturity.) I had tried the King James and the New International versions. I finally bought a study Bible, one of those with lots of footnotes, in a modern translation. Since I was having so much trouble with the wording and reading, I picked a translation that was easy to read, a dynamic equivalence translation -- NLT. It took three years to make it all the way through, but it was very rewarding.

I'm now attempting a read-the-Bible-in-a-year program in a different translation. This time I picked a balanced translation, Holman, backed up by a number of formal equivalence translations, chiefly NKJV and NASB.

There are many different approaches to reading plans. I picked a chronological plan, which I thought would be neat. And it is at least a little neat. I'm hoping that reading the whole thing in a more compressed time frame and chronologically will give me another perspective on the whole thing. Less time will have elapsed from one book to another.

This time around, though, I find the reading much less enjoyable than the 3 year deep study approach. It's a lot more reading and a lot less studying. I would recommend the reading through in a year approach to someone only after they have done it the other way.

Question

What has helped you stick with it and read the whole thing?

My Approach to Estimating

I did some research on using function point counting on an XP project many years ago. A few people remember that paper and occasionally I'll be asked what approach I recommend these days for estimating. There is a lot to like about function point counting and it can be useful on an agile project for estimating a whole project (but not an iteration for reasons explained in the paper).

Story Points and Planning Poker

The best approach for estimating user stories on an agile project is planning poker cards, small stories, estimating regularly, and keeping a small set of good (well estimated) stories visible. What I mean by keeping some standard stories visible is having a BVC (or just story cards left up on the wall somewhere) for those stories that went well, that everyone agrees it was a good 1 pointer or 3 pointer. "How does this story compare to that one?" is a common refrain.

Estimating regularly (weekly or at least every other week) keeps the approach and the "standards" fresh on everyone's mind. Have a regularly scheduled (standing) meeting on the calendar.

I don't get any more complicated than that. That's good enough. It's quick and requires little special skill. Well, estimating with points and planning poker is a skill that does need to be learned, but it doesn't necessitate a class, a thick set of rules, or a software estimating tool of any kind. Sure, a class or some reading can help, but it's not necessary.

Bootstrapping

For bootstrapping an estimating process for a new team or a new project, I like Steve Bockman’s Team Estimation Game or the less formal approach I used on a project in the early 2000's which amounts to little more than collaborative sorting of story cards into simlarly sized piles. James Grenning describes another version of a similar activity.

Question

On a related topic, tell me, do you have only the developers participate in estimating or does QA participate too?

If It's Painful, Do It More Often

I've worked with a number of teams who couldn't deliver. They could write code all day long for months on end, and they'd do just that. But then they'd spend a month or three shaking bugs out and still not be able to get the product into production. In many of these cases, the programmers just want to program. They don't want to or know how to do the messy task of deployment. Install and upgrade is not their core competency.

It's instinctive to cram more features into the release when it is just so hard to deliver. If you get few chances to deliver improvement, you want to cram as much in the release as possible. But that just makes it harder. More beautiful garbage to push over the goal line. This raises the inventory of unfinished work, the amount of work in process, which further delays deployment and hides the real problem.

I'm reminded of the Israelites when Moses instructed them to not save the manna that God provided from one day to the next. Do not keep an inventory of the stuff. But some of them didn’t listen and kept some of it until morning. But by then it was full of maggots and had a terrible smell. Software development with too much WIP is exactly like that.

Anyway, Lean software development reduces work in process in order to surface problems and reduce costs.

I like this illustration from page 7 in Mary Poppendieck's book, Implementing Lean Software Development. When you first look at it, your reaction might be "No! RAISE the water because there are rocks!" But the rocks are still there. Some day you are going to hit those rocks. Better to hit the rocks and deal with it in a dingy than in a yacht. Better to deal with the inability to deploy using a small release than a big one. It's better to lower the inventory, surface the issues and work to resolve them. Don't leave them there, lingering.

In eXtreme Programming we say that if is something is painful, do it more often. What we mean is that we should not avoiding dealing with problems. Solve them right away.

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.

You break your stories down /when/ ?

http://www.flickr.com/photos/pointshoot/ / CC BY 2.0

I've had a revelation. The other day I was talking to Mike Cottmeyer about Scrum and how I don't like the idea of tasking out and estimating all stories at the start of the sprint and then signing up for tasks, all before committing to the Sprint backlog.

When I first started doing XP in early 2000 we tried that and it was painful. Painfully long. Painfully tedious. And it felt painfully like Big Design Up Front even though it was for one or two weeks worth of work.

One team I was with for a handful of years broke our stories down into small 1 to 6 hour sized tasks and we pair programmed (up to 10 of us) on a limited number of stories (preferably 2, normally 3-4, but it could get up to 6-8 near the end of the iteration if something got blocked and if we had lots of abnormally small stories in the iteration). One person with an optional pair would design a story just in time and then walk the team through the details and proposed tasks and get their input. All the tasks were written on the whiteboard and this drove all development. Tasks were small and explicit:

• extract foo.class from fred.class
• extract bar#makeGenerous from #makeMagnanimous
•  introduce strategy pattern to someOther.class
• create someNew.class
• domain/persistance/patch for someNew.class
• write the acceptance test
• etc.

That design work could take up to a day or two to do for some of our stories. There is no way it would make sense to design all of our stories at the start of each iteration before committing to the iteration. That's how we did it using XP.

Tasks in Scrum, however, seem to be around 8 to 16 hours long, according to what I'm reading. And that was the new insight I gained. Some teams do things differently. (I'm slow sometimes, but I usually catch on.) With tasks that size, you could easily identify the tasks and estimate them before committing to the sprint. Further, teams that don't pair-program or that have too much specialization or too much code ownership need to break their tasks down by specialty and assign each task to the person that can implement it. Such teams would need to do this step before committing to the sprint.

I was blinded by my experiences being so similar to one another for such a long period of time. Help me see. How big are your story's tasks and how and when do you estimate them?