Definition of Done

Is your “Definition of Done” done?

If yes, when was the last time your team reviewed and updated it?  If it has been awhile, set up a session or tackle in your next retrospective.

The D.O.D is one of the key ways we build quality into our work at all levels.   “It is a comprehensive checklist of necessary, value-added activities that assert the quality of a feature and not the functionality of that feature.”

The functionality of the feature is addressed through acceptance criteria.

As a reminder, your team D.o.D. should be one they are capable to meeting now.  Some teams might propose an “aspirational” Definition of Done – one they cannot meet today, but hope to meet in the future.  This creates significant transparency and expectation issues within and around the team as neither they nor anyone around them would really know what they mean by “Done”.

Keep those aspirational plans around, they make great places to begin discussion on how to improve next.  But, they do not belong in the current Definition of Done.

For more thoughts on the Definition of Done, visit the links below:

https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod)

https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference

https://www.agilealliance.org/glossary/definition-of-done/

https://www.mountaingoatsoftware.com/blog/multiple-levels-of-done

In keeping with my new blogging plan, here is a blog post recently published on ScrumAlliance.org.  The link there is https://www.scrumalliance.org/community/articles/2016/october/best-time-of-the-week-to-start-a-sprint

About once a year the Scrum Team wonders, “When should we sprint?” That is, “What day of the week should we start each sprint?”

There have been blogs on this topic that have concluded Wednesday or Thursday. Many teams sprint successfully from Monday morning. So who is right?

They all are. The Scrum framework does not specify the cycle dates, because that does not matter to the understanding and implementation of the framework. There is no “rule” for start and end days of sprints for Scrum teams.

The base case

For single or small sets of colocated teams and stakeholders, many options are open. For distributed teams, especially those temporally distributed (e.g., Silicon Valley-Chennai, Chicago-Kyiv, New York-Shenzhen), the options quickly become limited, with few really good choices.

The first thought many teams have is a Monday morning start to a Friday afternoon finish. This aligns with the working week in many countries and feels right conceptually, by matching many of their historical work patterns. In practice, it can be more challenging. This model includes a Friday afternoon meeting for the sprint review and retrospective. For organizations that have relaxed Friday policies (a culture of early departure or work from home), Friday afternoon reviews conflict with the organizational culture and norms. Organizations that have retail customer software environments frequently arrive Monday morning to issues from the weekend that demand immediate support attention. This impacts Monday morning availability for sprint planning.

Even when it works perfectly, you have a 2.5-day break between the review/retrospective and the kickoff of the next sprint. This can cost in sprint planning meeting efficiency, as it takes time for the team to review the weekend together and get back into the working mindset. Any urgency around addressing issues from the last sprint may wane after a weekend away.

Many countries and cultures have holidays that are intentionally scheduled at the beginning or end of the work week to allow a natural extension of the weekend time off. In the U.S., Monday and Friday are the days most frequently taken off. These patterns mean that teams sprinting in alignment with the work week more often have their review/retrospective/planning efforts impacted by holidays and vacations. These issues are reduced the further you move from the work week cycle. As a result, Wednesday or Thursday are considered by many to be the optimal start days for a sprint. (You can find advocates and further issues with Monday/Friday at the links above.)

The time-zone trap

Teams that have members in time zones ahead of their reference location wind up expecting participation Friday evening into Saturday morning for demonstrations. Teams with members in time zones behind are asking for arrival really early on Monday mornings. Both patterns can dramatically impact the quality of work/life balance for team members.

Moving to a midweek start pattern does not remove the early-day and late-day issues for distributed teams, but culturally, asking someone to stay late or arrive early is often more tenable in the middle of the work week than compared to the weekend option.

Perfectly in the middle

Distributed teams with large time differences are also left with the question of which is the reference time. The same pattern of issues exists with any choice of time zone. As they progress down this thought path, some decide to focus on their working-hour overlap. They recognize that since the concept of beginning or end of day is a local construct and not an absolute global one (notwithstanding the International Date Line). This frees them to recognize that they can start and end their sprints at any time of day. If the overlap is sufficient, they can handle all three sessions consecutively during one day.

This optimally addresses all of the concerns above, but it adds a new dynamic: The team is in meetings for an extended period of time. This can result in fatigue and loss of focus, especially for teams with engagement issues. Most development teams I have reviewed this model with decide they prefer — it get it over on one day and reduce the interruptions to their work flow.

So my general recommendation to teams is to start your sprint “in the middle of the day and the middle of the week,” based on the team’s shared work week. This model can work with collocated or distributed teams.

No overlap

Teams that cannot find enough overlap are pushed back to making more compromises. Some cannot accommodate the late or early options are forced to split the events up to fit into overlap. This results in nearly a full working-day gap somewhere in the middle of the three meetings for one or more team members. The question then becomes, what to do with this time? If the split is the development team is separated from their product owner (a great model is to place the gap with the product owner), this gives them a day to adjust the backlog based on the prior sprint review. If the gap must be placed with the development team, a common practice is to split the planning meeting in half. The product owner reviews the “what” with the team on same day the prior sprint ends. The team has about one day to plan their “how” they will implement. Then the two reconvene to confirm and make the sprint agreement. This has the effect of making sprint planning a full day but should result in a better-prepared sprint.

If the gap is within the development team, the gap can be used for spike work. The portion of the team that is working uses this time for exploratory work to better understand upcoming stories. Some teams have chosen to use this time for “cleanup” work from the just-ended sprint. Be careful with this approach, as it breaks the integrity of the sprint idea of completing work during the sprint and creates uncertainty around what work is “done” during reviews.

Big challenges

Teams that are part of larger groups of teams (scaling) have additional considerations. Does the scaling model force alignment of sprint boundaries? SAFe and LeSS both include shared planning meetings that push teams toward having closely aligned sprint boundaries. The Nexus team work also pushes to aligned sprint schedules within the Nexus group. The need for coordination between teams (Scrum-of-Scrums) may also impact the choices of the teams.

Sets of teams with shared stakeholders may be pushed in the opposite direction. If all the sprint reviews are occurring concurrently, the stakeholder must choose which to attend. This can lead teams to choose varying schedules to allow shared stakeholder participation.

If you decide to change

Changing the calendar for a team already sprinting does have a cost. First, never change the calendar mid-sprint. The team made their sprint goal agreement based on an understood calendar, and changing mid-sprint clearly violates the integrity of the sprint.

When you do decide to change, how to handle the “remainder” in the equation? You can choose during sprint planning to have a single shorter or longer changeover sprint to align with the new calendar. Remember, this will result in a sprint with a different velocity, so be aware of this when planning and looking at trends. This should revert immediately back in the next sprint. (Remember, we are only talking about shifting the alignment with the weekly calendar. Scrum teams should have a consistent cadence.)

Alternately, you could insert a non-sprinting period. There are no gaps between sprints in the Scrum model. If the gap is several days to a week long, you can insert a one-time gap for an innovation period, lab week, hacking event, etc. If the gap is a day or two, consider an outside team-building event. Teams are often reluctant to schedule full-day team-building events due to their impact on a sprint, so take advantage of the opportunity.

And, as always: Retrospect – Adapt – Repeat. – See more at: https://www.scrumalliance.org/community/articles/2016/october/best-time-of-the-week-to-start-a-sprint#sthash.nMLpiWyY.dpuf

They so often say “you cannot teach an old dog new tricks”.

While this may be true, I truly believe that all of us, young or old can learn as many new tricks as we are wish providing we are willing to put in the time.

I was watching the child in the park the other day perform a new “trick” for his mother.  Watch me, he cried out to her.  She obliged and he attempted to jump up to grab the rings on the playground.  He got one and almost the other, but just not quite and fell to the ground.   He jumped up, ready to try again.

As he prepared again, I mentioned to her that he was really, quite close.  She laughed and said, he had been quite close for 3 weeks now and worried about what was next once he succeeded.

As I pondered this, I thought perhaps it is not that we become to old to learn new tricks, but merely that we become too impatient.  We know oh so many tricks already, it is really worth this time and effort for a new one.  Would it not merely be simpler to continue to perform the tricks we already know so, so well.

Ask any of who have done or any who have tried and they will agree to a person – Agile is hard.

Like everything else, learning new tricks requires effort, patience, and the perseverance to keep picking ourselves up off the ground and jumping for those rings one more time.

In honor of my birthday, for my new trick, I plan to start blogging.  Been saying it for a long time – so here we go.