Just one thing …

Curly: Do you know what the secret of life is? [holds up one finger] This.

Mitch: Your finger? Curly: One thing. Just one thing. You stick to that and the rest don’t mean s***.

Mitch: But, what is the “one thing?”

Curly: That’s what you have to find out.

Jack Palance and Billy Crystal  from the movie “City Slickers”

I always found this scene amusing when I was a kid. The old ranch hand trying to teach a city guy the value of focus for clarity. Of course at the time I just thought it was funny. After all these years, I realize that Curly was teaching a true agile value. Focus.

Focus is that thing that often gives us clarity. It gives us the ability to think deep thoughts and really unravel an idea. It allows us to extrapolate from a big thing into discrete pieces upon which we can undertake. It applies to things in life as much as it does in software development. I have started to really appreciate this as I prepare for an upcoming house declutter and move.

Do I allow myself to always embrace this seemingly simple approach. Nope. I, like others, allow myself to get too “focused” (and I use this term loosely here as it really not focused at all) on too many things. Like those performers that are spinning plates on a skinny stick, I find myself focusing on keeping them all spinning sometimes. But, as I am want to do, which often results in a blog post, I find myself stopping, breathing, thinking, assessing and questioning my current chartered course. So here we are.

Focus is a core value in agility as it allows us to actually be more productive by allowing ourselves to work to accomplish “that one thing” as Curly put it.

Under scrum, we demonstrate this through the user story, the task decomposition in terms of work effort. We use focus in terms of daily risk mitigation through a focus meeting called the  stand-up. We focus on the features committed within the review and the team within the retrospective. If you look closely, focus is woven throughout

Kanban has WIP and the innate concept of “pulled work” which itself a way to focus and measures this through the idea of how effective our focus on delivery is through things such as cycle time.

But there is one dimension in which I often see less focus. In the process of delivery. What I mean by this is often I see scrum development teams use a “divide and conquer” approach in which teams members use their specialized skills to scatter and seek to deliver. They are in no way being less agile in this approach but I have always wondered what would happen if they allowed themselves to focus and iterate just like the larger product. There are examples of this. Just take a look at Woody Zuill’s mob programming or pair programming as outlined in Exteme Programming by Kent Beck.

My latest read, “Joy, Inc” talks about the use of pair programming as the standard way of how they hire and how they work. They see it as not only a way to create shared knowledge by this but also to ultimately be more productive.

So, I have posed this question many times to developers and often get the same response “well, development doesn’t quite work that way” to which I often reply “are you willing to try an experiment and either fail or be wrong”? *smiles*

My logic has always been that if a sprint backlog is supposedly composed of a top to bottom prioritized list of the highest business value, wouldn’t we want to work through the items (given we identify any dependencies and work to minimize those with the product owner) and focus to deliver each story in that manner during a sprint? Or even look at the absolute most complex item and focus on completion of that story and then work on the lower hanging less dense fruit?

I see 4 potentially significant benefits that could result from this:

  1. We get items in front of our team members specialized in quality quickly so they can assess features for compliance to acceptance, note any software issues or quality enhancements and they can become productive more quickly. They are reviewing and testing completed features, even if there are mocks behind some dependent needs of other stories. They also are able to learn a portion of the system under construction and build automation against it for regression more quickly if needed.
  2. If we for some unforeseen reason we are impacted to effectively deliver on all stories for our commitment, we can at the first responsible moment, assess remaining team bandwidth, current deliverable dependencies and make decisions so that we can have that conversation immediately with our product owner so we can remain transparent on the impediment and impact but emphasize our focus on the highest priorities or largest complexity first.
  3. We reinforce iterative development at the lowest level of development (by using refactoring and integration as part of the way we work) and can focus on ensuring that we meet our agreed definitions of done at each story level.
  4. We “should” end up with a set of features tested early which should allow us to as a team to swarm baking in quality for our product and preparing for our review at sprint’s end (given we did not over commit …)

So in my view this approach makes sense to me and I have worked on teams that worked this way and we remained productive and felt like we were accomplishing more towards our product goals. We effectively delivered features regularly for review for the stakeholders.

A lot of folks may be reading this and joining the chorus of previous conversations saying “yeah, sounds good but you don’t really understand” …

So I reply to you all … “are you willing to try an experiment and either fail or be wrong”?


Scrum Alliance Webinar

“One of the most sincere forms of respect is listening to what people have to say”

– Bryant McGill

I was very honored to be asked to conduct a webinar for the Scrum Alliance with my colleague and friend, Mr. Joe Kirk, about our agile transformation work with a state transportation department this week.

I really enjoyed discussing our journey and addressing questions for attendees.  The scrum alliance should be posting a follow-up to the talk soon in which we addressed questions for which we did not have time to do so during our talk.

Agile Transformation at Tennessee Department of Transportation


Our Sprint Cycle

I was asked by a colleague how we have designed our software sprint cycle. As I explained it, I thought that this might be a good topic to just outline as part of this blog. This approach, which could be dubbed “lucky 13”, is the standard of how we conduct product work. Is it perfect, probably not, however, we do see it as an experiment and evaluate its effectiveness over time.

Some precursory notions as to why we built our sprint cycle this way:

  1. We want to be reasonable and responsible in how we build software and give a predictable horizon for commitment delivery to the product owners.
  2. We want to give the proper space for planning, tasking, review and retrospective
  3. Continuous learning is highly important to me and our organization so it was with intention that we built in slack time to allow us to do this.

So how does it work?

Day 1: Planning and Tasking the Work Ahead

This is our planning and tasking day. We split it into portions to allow the conversations to occur so that we can gain understanding and make our commitments as well as use the second half of the day to decompose the work ahead.

Days 2-11: Product Build/Test/Deploy

Composed of 10 working days for building, testing and deploying our code to meet the commitment and prepare to review for the product owner. 15 minute daily standups are held throughout this cycle to synchronize the team work.

Day 12: Review and Retrospective

Typically our product review occurs in the morning allowing us to demonstrate the features for the product owner. We will, on occasion, have a window for sizing any new stories that have emerged into the product backlog. Following lunch (usually as a team) the team meets in the afternoon to conduct their retrospective. While many of our retrospectives focus on improvement in the next cycle, we often times balance this with focus on team unity, team health and technical discussion as needed and to keep the retrospectives fresh and engaging.

Day 13: Lab Day

This is the slack that we build into our schedule for continuous improvement. It’s a very small horizon so deep work is unlikely to occur. Teams spend this time learning new skills through online training, have more “deep dive” technical discussions or discuss refactoring that may be needed as a result of accrued debt within the cycle. This point in the horizon accomplishes two important things. 1) It allows teams a moment to reflect on their skills, their product and seek to learn as a part of the culture. 2) It gives the team a momentary “breath” between sprint cycles. It allows them to level set, focus and be prepared for the next sprint

How we Adjust Capacity

We made a conscious effort to really consider team impacts and after observation we determined that our team impacts to capacity occur in two major forms; team capacity loss and team member capacity loss. We handle each of these differently.

Team Capacity Loss

If the entire team is impacted, by a conference, a holiday or an “act of God” disaster, we consciously adjust our schedule to account for this impact to allow the team to retain a full 10 day build cycle. This does not happen very often but we found that it is best for us as it retains consistency within our development cycle.

Team Member Capacity Loss

This is handled differently based upon the reason behind the impact. If a team member has a planned outage (vacation, doctor’s appointments, etc) then we adjust the capacity for the individual based on the outage and the team adjusts their commitment accordingly to compensate for this team member being out. They communicate about this prior to the next planning meeting so they can make this impact visible to the product owner.

If the team member has an unexpected capacity reduction such as sickness or other life trauma; the team uses the idea of “first responsible moment” to make this impact visible and communicate impact to the commitment to the product owner. It has become generally accepted in our organizational culture that in doing this, they provide insight as soon as they are aware of impact which builds trust and openness between the teams and product owners. It also provides the product owner an opportunity in the face of impact to have a conversation with the team to determine if any value can be salvaged from the commitment impact and provides them insight early to review release plans and manage stakeholders.

Pros and Cons of this Cycle


  • It provides a given horizon for the teams and the product owners.
  • It allows the teams to control and adjust the work based on impact. It reinforces the agile values of self-organization, self-management as well as transparency.
  • It gives team space to ask questions before beginning a sprint cycle in a larger context before commitment to create shared understanding or if necessary split stories, etc.
  • Through building in slack time within the standard sprint cycle, we foster the value of learning and provide the space to do this on a regular basis.It also allows for team building and to “level set” for the next sprint.
  • For our organization, this sprint cycle appears to be a “sweet spot” of predictability and maintaining a small enough horizon to effectively manage risk.


  • Using such a long cycle only allows roughly two sprint cycles per month.
  • The horizon of the “lab day” is very small in scope and therefore no in-depth learning can occur.
  • I have been challenged by purists that this is not a typical scrum sprint cycle as I have purposefully pushed the beginning and ending “rituals” outside of what people think the sprint should be. What we discovered was that the teams sought more time to prepare for the work and therefore made a conscious effort to give them this space. We also felt that the review and retrospective should have its own horizon for effectiveness. I do think we are following the base scrum guidance of a sprint being 1-4 weeks and performing the rituals prescribed. We just feel that they needed more focus outside of delivery to heighten effectiveness.
  • This cycle relies a lot on emergent design from both an architectural and product design sense. Finding ways to place this better into the context of product planning so the team could have wireframes and user experience for guidance (and refine during the sprint) as well as base architectural guidance would be helpful. We are presently evaluating how to best facilitate this.

So, this is how we build products at my company and what has worked for us. This may not be the end result of where we land but we’ve been using this approach effectively over the past 2-3 years. As most everything we do, we see this as an experiment, open for refactoring, destruction or re-envisioning. The process doesn’t make us special, it’s the people and the fact that we know that the process just helps keep us on the rails.


First Responsible Moment

You cannot escape the responsibility of tomorrow by evading it today. – Abraham Lincoln

Responsible is defined as “being the primary cause of something and so able to be blamed or credited for it.” While this sounds very straight-forward, I think sometimes in growing in our agility as a team, a leader or an individual we can forget the power of this word.

Responsibility is a cornerstone to agile thought in my opinion. We strive to teach our teams to be self-managing and instill the idea at the lowest possible level by having them select the work and manage its delivery. As agile leaders, we embrace responsibility coupled with our willingness to experiment, learn and grow and as a basis to keep at bay the fears of failure.

There are three core concepts that I try to instill and reinforce in teams; I ask that they apply a litmus test of reasonableness and responsibility to decisions they make (on an individual, team and organizational scale) and that they respect the power of the “first responsible moment”.

Being Reasonable and Responsible

What does this really mean? It sounds powerful, but also sounds very idealistic. For me, it is very pragmatic. I use these values for myself and my teams as a base “sanity check” for decision making.

Approaching decisions from a position of being reasonable and responsible breaks down this way for me personally allowing me to examine the decision to be made by asking questions:

  • Is what I am proposing an idea or solution that brings value not just to myself but to my team as a whole and the organization?
  • Is this a hotfix solution or does it hold long term value?
  • Am I proposing something from a position of fear or merely pain avoidance?
  • Is what is being considered the right thing for us to be doing?
  • Do I actually believe in this idea in that I could passionately communicate and adapt this position if necessary?

This seems like a lot of “stuff” to go through for a decision but it is really quite simple as when people have a shared understanding of “being reasonable” it really takes little time as muscle memory forms to evaluate quickly (reinforced by a solution oriented outlook).

But here is where the kicker comes in. Evaluation as to the reasonableness is half of the picture for an agile mindset. The final question is the linchpin of this approach.

“Are we willing to be personally and team responsible for the outcome of the decision we are making”?

This takes this application of values to a whole different level. This means should things go sideways, are we willing to accept the consequences of our decision and adapt to self-correct? Are we willing to accept that we failed? Are we willing to re-evaluate our position?

Coupling this with the personal willingness to accept the end result of the action is part of the core definition for this idea.

So why “first responsible moment”?

Again, in my humble opinion, this idea is a cornerstone of agile thinking and doing. It helps support our lack of fear to fail and reinforce our open communication. It empowers us to be transparent and promotes healthy working relationships that reinforce trust among people. It is something that I say often to teams when they encounter a problem.

The “first responsible moment” is how we approach obstacles, problems and impacts. We open the channels of communications to those invested into our work as soon as we see a problem that may impact our commitments.

Often times, there is a lot of fear that surrounds the need to have a conversation that delivery may be less than forecasted. But if we are truly building a healthy agile culture, we use this concept to allow fear to be diminished by encouraging folks to communicate an obstacle or impact as soon as it becomes visible and disruptive.

This does not always necessarily mean the inability to overcome and deliver but what it does do is to set the expectations of everyone involved in a reasonable manner. It always opens a communication for examination to see if there is partial value that may be salvaged and it strengthens the relationships through candid visibility into work. It allows us to take a problem at first encounter and approach it as a discussion for solution.

In an agile (or probably any other) world, no one likes to fail. My teams wring their hands and sometimes beat themselves up too much so I ask them to reflect in retros on “what happened” to create this situation. Sometimes by doing that, we can see patterns of actions that set us up to get there. If we can find these, then we can take actionable steps to reduce the likelihood of failure under those exact sets of conditions. But what is more important (as you noticed I inferred that you cannot just generalize failure to certain things) is that we learn more about ourselves, our team and reinforce our embrace of change. Sometimes things like sickness of a team member can cause items to become in jeopardy.

It can often be random events that create an obstacle. We cannot control the unknown, but we can control our response to it. One of the worst things we can do as a team is to remain silent, kill ourselves to meet commitments for which we know may be unachievable and damage our relationships by waiting until the last moment to make people aware. This stands potential to damage us as team and an organization. We may get the commitment out, but what did we lose as a result? I am not naive to realize that there are times when we are so committed to our work we go “above and beyond” to deliver. But this should be the exception and not the rule. A sustainable pace is always a better approach coupled with the “first responsible moment” when impacts arise.

If you, or your teams, are not presently practicing this concept, give it a try. I think you will be pleasantly surprised at how it can tighten the relationships and reinforce the core values of agility.