Tag: Agile

Posted on

Retrospectives in Battle

I have been lax in continuing my blog in retirement – sorry! We’ll see if I do better in the future. It is retirement, after all.

The following excerpt (italics) is from Air Combat at 20 Feet … Selected missions from a strafer pilot’s diary … by Garrett Middlebrook (“Middie”). This amazing book, borrowed from my friend Mark Dickerson, details missions from Middie’s diary of air and ground combat during World War II. He was the pilot and commander of a North American B-25 Mitchell. Shortly after arriving in the South Pacific his medium bomber aircraft was modified by adding strafing gun packs. This excerpt is near the beginning of the book. So often we learn too little from these gentlemen of our greatest generation, simply because it is too difficult for them to speak much about their experiences. No one blames them for this, but this man, Garrett Middlebrook, was up to the task of transcribing portions of his missions diary into an excellent book, and for that we should all be grateful.

That afternoon I met in private with my crew. From the very first mission we did something the other crews, except for Bill Gay, thought unnecessary. We critiqued each mission with a clear understanding that each crew member had the right to make any suggestion or criticism he desired. If I found that some suggestion was not practical, I never ignored the crewman. Instead, I explained to him detail why his idea was not practical or effective. 

On that particular day, however, I accepted all the blame and responsibility for having centered my attention on Parker’s plane [after the airplane was hit by the enemy and was going down], and for having allowed myself to become emotionally distraught with sympathy. Three other crew members confessed to sympathetic indulgence also.

I promised I would never again lose my trend of concentration [on the mission] by being sympathetic to a doomed crew, no matter who they were. I then advised my fellow crewmen that I expected them to refrain from sympathy and to maintain vigilance at all times. I suggested that we would have plenty of time for sympathy and sadness once we were back at base.

I kept my promise. I saw several planes go down after that date. When a plane fell from the formation, I always pressed the intercom button and reminded the crew to look up and not down. I asked them to fight for themselves and for each other so that the Japs would not bring us down. I received magnificent response on each occasion. They did not need morale lectures thereafter because we shared a common transition that day. We all became veterans. Although we endured and suffered through many [Japanese] Zero attacks thereafter, none ever surprised us.

I have two quick remarks on this sobering text. First, retrospectives are useful even in, perhaps especially in, the most dire of circumstances. Second, to accomplish the mission, sometimes one’s sole focus must remain on that mission. These lessons were learned the hard way, in battle. May those who fell rest in peace. 

Posted on

Remote Story Point Sizing

All you need is a chat window. No really, it’s true. (Though sadly, the reason I’m posting this is because too many companies, even large ones, are astoundingly reluctant to invest in the successful collaboration of their teams.)

Here is a script for sizing a small number of items one at a time using a voice conference call and a chat window; this seems like a small enough technology requirement to assure that almost everyone doing a remote team exercise will have the necessary technology. I’ve been honing the wording on this, as the slightest mistake in wording can lead to someone prematurely showing their size to others, which results in bias.

  • Your facilitator says, “Is anyone NOT clear on the item we are about to size?“
  • If everyone is clear, then the facilitator says, “Ok, without typing the enter key yet, please type your size estimate into the chat window, sending to all; again, do NOT yet type the Enter key.”
  • The facilitator can type into the chat window, “Looking at item <number or description>” – this is an informative interstitial that separates this sizing evolution from a previous one.
  • The facilitator says, “Does anyone have yet to decide on a size?“
  • If not, the facilitator says, “Three two one Vote“, and at that point everyone types their Enter key at the same time, on the spoken word “Vote”.
  • Of course, if everyone is agreed, then your item is sized.
  • Otherwise, one more round of voting can occur as above, after allowing for discussion, remember to get the high size vote and the low size vote in on the discussion to clarify their reasoning to your team. I recommend no more than two voting rounds total to save time.

One can do a Fist of 5 (Fist to 5) in this way also.

  • Facilitator: “I’d like to get a Fist of 5 to ascertain our confidence in meeting the sprint goal and sprint content to which we are about to commit.“
  • Facilitator: “Without typing your Enter key yet, please type your number of fingers into the chat; again, do NOT yet type the Enter key.” Here also, you can describe what each number 0 (or 1) through 5 means as you are accustomed to using this consensus method.
  • Facilitator: “Does anyone have yet to type in a number of fingers?“
  • Facilitator: “Three two one Vote” – as above.

I hope that helps! There are many other ways, but as most readers will already be aware, obtaining an unbiased response from each participant is important.

Theory. If you want to read more, try …

Posted on

Working Agreements

I was about to write a post on working agreements with an emphasis on their use in Agile Teams. There was no need – the wheel has already been invented! and is right there on the amazing internet. I encourage you to read these two internet posts in order; they’re both short. The second one has a video with dogs in it – that can’t be bad.

Posted on

to Kanban from Scrum

I recently transitioned a team from Scrum to Kanban. Here are some of the things I learned. Those of you experienced in Kanban – I’m really not – will probably find this boring. Many of these items are bread-and-butter for Kanban.

  • Kanban has less formality but requires the same degree of rigor as Scrum or even more. This implies a greater requirement in Kanban for discipline, enough so that teams can do it, but are unlikely to do it well, without focused help from a good coach, unless the Kanban Master is quite well-trained. That is, Kanban Master(s) needs to be higher quality with respect to Agile and Kanban techniques than are most Scrum Masters with Scrum techniques, for the team to be successful.
  • Kanban is Lean. Start with what you have, keep learning, and feel very free to change and expand your board. More columns, maybe more rows, and make it truly live and visually representative of your current work, state and needs. Be incremental. Experiment, try stuff, continuously improve. Focus on pull in lieu of push. (A good and easy example of pull is inserting a new column in a Kanban board between In Progress and Testing called Ready to Test.) Oh, and read Kanban by David J. Anderson. Don’t argue, just go read it. I found it a challenge to find the board online that I wanted to cite as a good example. Here’s one that is not bad, take awhile to just study it and think about what they must be doing and how it visualizes things for the team.
  • Policies. Each column-to-column move made by a work item is a state transition; endow each state transition with a policy. In Scrum, from In Progress or Doing or Testing or whatever to the Donecolumn (state) has a policy associated with it called Definition of Done. Optionally, from Backlog to In Progress has a policy associated with it called Definition of Ready. Each policy specifies the conditions that must be true to allow the state transition, as well as the actions to be taken when the transition is performed. In Kanban, all possible state transitions should be endowed with such a policy. They don’t need to be lengthy, but they definitely should be visible and easily found so that they are quickly referred to during work and updated during retrospectives with new knowledge gained.
  • WIP. Going from Scrum to Kanban made the transition from (work in progress naturally limited by 2 week sprints) to (WIP limited poorly and without a strategy) painfully easy to see. Shoring up the WIP limits to enable good flow and predictability became priority almost immediately. Fortunately it’s not difficult as long as the principles are understood. The rule of half got us in the ballpark: Team: “is this about right?” Coach: “try half that”.
  • Reviews. In Scrum there is a sprint review every two weeks. Everything forecasted for a sprint is reviewed or thrown back into the backlog if not done. In Kanban there is no such formalism, but every work item should still result in a product improvement that is executable, demonstrable, and demonstrated to a product owner or stakeholder(s) and approved. Visibility is key, so put the appropriate state transition into your Kanban so that you can know that all your work items pass this “it’s done, and it’s approved” policy test. In addition, don’t underestimate the value of cadence; maybe you should keep reviews of your working stuff on a regular cadence. Kanban doesn’t care; if it adds value, do it. Does that make it Scrumban instead of Kanban? Not sure, and not sure it matters, but rhythm is often useful to a team.
  • Retros. In Scrum there is a retrospective every two weeks. One must account for this functionally. In Kanban, once again, the retro does not have to occur on cadence, but experience shows it has to occur with similar frequency in order for your team to qualify as a team seriously engaged in continuous improvement. My suggestion: stick with what you did in Scrum, if you can. Set up a convenient time, and do your retrospective every two weeks on cadence. If this is the only thing you do on cadence, I believe it’s the best thing to do on cadence. Retros are the most important event, right? Rhythm is useful to many teams (see previous bullet), and it is a reason Scrum is so easy to like.
  • Kanban doesn’t have a Product Owner. I recommend a Product Owner anyway. Bring someone in from the Business who will do the things a Product Owner does. Make that person a full-time member of your team.
  • Kanban doesn’t have a Scrum Master. I don’t recommend one, but I almost do. You need a level of effort of approximately a one full-time person to engage the team in continuous process improvement, remove impediments, and facilitate ceremonies/events of importance. In fact, maybe the LOE is higher, because Scrum’s processes are straightforward whereas Kanban is nominally very flexible and dynamic. My suggestion then (falling just short of a recommendation), is to avoid underestimating the value of a single, dedicated person who acts for your Kanban process as your Scrum Master would if you were using Scrum. Call him/her your Kanban Master perhaps, if you as a team decide to leverage this idea. Be sure that person reads Kanban.
  • Story pointing or story sizing. Predictability is a major element of growing maturity as a team. In Scrum, we often perform Story Pointing as a part of backlog refinement, to understand the relative size of each work item (many of which are user stories, hence the name). However, in Kanban, one doesn’t measure velocity because there are no sprints. Instead one measures lead time and cycle time. For this to work well, each work item needs to be “about the same size” as its brethren. Story sizing keeps this from being a need, but story sizing only works if you’re on a static cadence like two weeks. If you have some 1s, 2s and 3s floating around, you’ll probably be ok with the assumption that all stories are close enough to the same size to ignore their differences. If you have some 2s, some 3s, but a 13 or three as well, then the assumptions of similar size required by the lead time and cycle time measurements don’t work as well, and those measures won’t help you nearly as much to understand your predictability. Therefore, a significant element of improving maturity with Kanban is to solve this problem by splitting those 13 point user story into stories that are 1, 2 or 3 or so in size, that is, all of similar size. And we don’t do this by explicitly sizing the stories, we just split them until the collection of stories all are “about the right size”.
  • Story Understanding. On the other hand, part of backlog refinement is ensuring that the whole team understands the needs represented in the backlog. My experience is that this happens very naturally when stories are routinely sized. If the team stops sizing stories, they often forego exactly what it takes for them to have an adequate understanding of the stories. Quality suffers. Thus, even if the team is not sizing stories any longer, they still need to understand them as well as when the stories were being sized. The team must figure out how to maintain that sufficient level of understanding of the backlog.

Hope that helps! Keep learning and improving.