Saturday, November 23, 2013

13+2 Sprint Cadence

Sprint length - a fun debate. What is the best practice - a funny question. There is no best practice for sprint length.  But what factors should go into the decision?


  • The team's ability to become predictable within the sprint duration.
  • The Product Owner's ability to plan and to commit to the unknown of not changing the plan for the sprint's duration.
  • The frequency of needed feedback on the direction the team is making toward the release goal.
  • The ability of the team to create their sustainable pace.


Many team's I've worked with have trouble defining their sustainable pace.  I've argued that this pace that allows the team to deliver both working software that is potentially shippable each sprint and to have high quality deliverables along with team learning is quite a bit below the teams typical sprint velocity.

When teams are under extreme pressure to deliver they typically forget one of the 7 habits of effective people - to sharpen the saw.  So why not build this habit into the structure of your team's cadence?  Instead of a two week sprint (10 work days) try the 13+2 model.  Thirteen work days followed by 2 days of slack (read the book: Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency).

This slack will give the team time to reflect upon the many things they wish they had time to do, but didn't; and now perhaps they will do them.  Silly little task like cleaning up the automated build scripts, pruning out the dead wood out of the smoke tests, refactoring the last story to a design pattern that now appear obvious after the fact.

This three week sprint length will add in 13% slack to your sprint in a tempo that is easily predictable for the team members.  You might find that the team members start using this 2 day slack time for things like doctor visits and Fed-Ex days.

See Also:
Slack and the Manager's Role in Scrum by Andrew Fuqua
21 Tips on Choosing a Sprint Length by Mishkin Berteig

Hat tip to my friend Caleb Jenkins for the idea - I told him he better patent the idea, or I would steal it.


The Holiday Stratagem

What do the Thanksgiving and Christmas holidays do to your teams tempo and cadence?

For most US teams this holiday period from mid November to after the first of January is hectic and disruptive in various ways.  This calls for a Holiday Stratagem.  A trick to allow the team to have some semblance of continuity and flow during these times.
The Sontaran Stratagem - Doctor Who

To discuss this stratagem let's first define some terms:

Tempo - the rate of workdays to calendar days
Cadence - the beat of the sprint events to fall upon the same calendar day of the week
Sprint duration -  in work days (in this example I'll use 10 work days)
Sprint length - the length of calendar days between two sprints (14 days for the example 2 week sprint)

What do you value more?  The ability to deliver more work in the short term -or- the ability to predict long term the capability of the team to deliver that work?  Or perhaps something else, like teaching a new team the trade-offs in making decisions and helping them to learn from reflecting upon these decisions.

This is one area that I find lots of variability in agile coaches answers when the team just wants an answer to the question - what do we do?  I love this variability.  I enjoy the ensuing debate over the better answer and delving into the reasons why for a specific case.  And this is definitely one domain that is not simple - nor is there a best practice.  So reader beware - there will be no one best practice, no correct way - here is the land of trade-offs.  And it is an interesting land well balanced between the trade-offs such that the replications of the decision are virtually uninteresting.  I think that makes a great play space for the team to practice decision making.

Let's use an example and then discuss the options.  Team Alpha-Dog is on a 2 week sprint schedule with the beginning on Monday (Sprint Planning) and the end of sprint activities (Demo & Retro) on the Friday of the following week.  Along comes the 2013 holiday season with the company's holiday plan for Thanksgiving days off on Nov. 28th & 29th.  In the sprint planning on Monday, Nov 25th the team has a decision.  Do they keep the sprint duration constant (at 10 working days) and there by break cadence - or - do they break tempo and keep the sprint length consistent at 14 days?


Option A - Illustrated
Option A:  Sprint duration constant at 10 working days.  Sprint begins Nov 25th and runs to Demo on Tuesday, Dec 10th.  The cadence of the team and stakeholders will change.

Option B:  Sprint cadence constant at 14 calendar days.  Sprint begins Nov 25th and runs to Demo on Friday, Dec 6th.  The duration changes to 8 working days - impacting planning and subsequent velocity calculations.

Option C: Sprint duration and cadence are broken.  Sprint begins Nov 25th and runs to Demo on Friday, Dec 13th.  A sprint duration of 13 work days to try to reestablish the Monday/Friday cadence - just on an alternate rhythm.

I'm sure someone will offer another option, I'm just going to stop with these three and quickly rule out option C as the worst of all.  It's always nice to have an option everyone can agree upon - even if it is the worst - at least we all agree.

One may want to do a bit of mid-term planning before making the decision.  What will happen with the Christmas and New Year's holiday if we continue with the decision principles we use now; does this leave us in a cadence we wish for the coming year?



If the team desires to switch it's cadence or duration - there is no better time than now.  Have you met the 13+2 Sprint Cadence?



If the team chooses option A then planning is easy, the average velocity calculation is consistent (no need for an asterisks in the log book); however the team ends up changing the sprint cadence and this may wreck havoc on stakeholder's schedules.  The impact to this decision typically ripples outside the team more than inside the team.  It's a good test of the servant leadership paradigm at your company.  Do the leaders server the team or does the team serve the leaders?

If the team chooses option B then planning is a touch harder involving fractional math (I've found this surprisingly difficult for some,  capacity this unique sprint is 8/10 times the typical sprints velocity).  This sprint's velocity may be thrown out of the set for future statistical calculations.  Stakeholder's may be happy because they don't have to rearrange their busy calendars.  But the externality impact to the team may be hidden, it is the compression of the sprint that will throw them off, they will be off tempo.

Projecting these decision into the mid-range future and through to the middle of January may help you make a decision on principles.  But don't expect these principles to hold true when it comes to the following year's calendars.  These are not true principles but just situational guide lines.  It is a good time to practice team consensus making tools like the fist of five.

Have a happy holiday!




Friday, November 22, 2013

Starting a Tech Lending Library

Just bought the Craig Larman agile library collection on Amazon for our lending library at work.


I first feel in love with Agile by reading Larman's Agile & Iterative Development: A Manager's Guide.  The organizational context that sets the stage for comparing and contrasting various agile (and non-agile) methods of software development is a powerful framework.  I find few managers choosing a method understand these concepts enough to make an informed choice.  Only a few hours with this book would raise their awareness to a much improved state.

Here how I started a mini-movement... one email...

I find an empty book shelf to be an aberration.  So I’m filling it up with techie books and some not so techie books.  Feel free to BORROW a book for a few weeks then bring it back for someone else to borrow.  Bring in those dusty books you found interesting and join me in creating a Tech Dev Lending Library.   Connector Breakout Lounge 5001.
There is no check out system, no late fees, no sexy librarian to scold you for not returning a book, just your guilty conscience.
So have a coffee, pick up a book, learn something new, share your knowledge with your colleagues.
David


The beginning of a Techie Lending Library
[ see also:  http://littlefreelibrary.org ]


Little Free Library Story from Beargrass Media on Vimeo.

Tuesday, November 19, 2013

Elements of an Effective Scrum Task Board

Leadership desires - Info Radiators 
What are the individual elements that make a Scrum task board effective for the team and the leadership of the team?  There are a few basic elements that are quite obvious when you have seen a few good Scrum boards... but there are some other elements that appear to elude even the most servant of leaders of Scrum teams.

Team desires - Info Radiators








In general I'm referring to a physical Scrum board.  Although software applications will replicated may of the elements of a good Scrum board there will be affordances that are not easily replicated.  And software applications offer features not easily implemented in the physical domain also.





Scrum Info Radiator Checklist (PDF)

Basic Elements


Board Framework - columns and rows laid out in bold colors (blue tape works well)
    Attributes:  space for the total number of stickies that will need to belong in each cell of the matrix;  lines that are not easy eroded, but are also easy to replace;  see Orientation.

Columns (or Rows) - labeled
    Stories
    To Do
    Work In Process - (many teams limit WIP - label this or make the column very small)
    Done

Rows (or Columns)
    a column title label row (at the top)
    one row for each story in the sprint backlog
    one row for each unique action item from the retrospective
    (optional) rows for company initiatives that team members will be working upon

Stories - the classic user story is typically written on an index card or large sticky note.
     Attributes:  title, description, acceptance criteria, effort size, delivery order (backlog priority), business value, dependencies, negotiated in/out of scope agreements, etc.  See Also:  One sentence does not make a User Story.

Tasks - a sticky note or index card for each task the team identifies or discovers in the sprint.
     Attributes:  each task should be specific (not something like "test it"), each task should be less that a day's worth of effort (when this is not true - the first action of the task should be to break the task up into a plan of action); each task should be estimated in relative units (different & more fine grained than story points) - for example "aspirin"- this is proportional to the amount of wall clock time between it's current state and done (not equal, but proportional to real time).  See Also: What belongs on the TASK board?

Sprint Burndown Chart - task units remaining plotted per day; with sketches of the trend lines; annotated with events that impacted the sprint (ex: reduced scope on day 4;  pulled in small story on day 8; holiday on Monday, flu hit the team, etc.).  See Also: A burndown chart that radiates information.

Impediments List - the one guarantee that Scrum will deliver - and if you are not capturing these on a daily biases and the triaging these, recording the resolutions, reflecting periodically on the classification of root causes -- well then you are not doing Scrum.  See Also: 7 aspects of a great Impediment Sticky.

Advanced Elements


Trend of Sprint success - Predictability graph - graph each sprints planned story points and the accepted (by PO) story points;  the simplest form of this is a binary trend of success (sprint delivered on time, in budget, with planned scope) or not.  See Also:  Metrics for a Scrum Team.

Working Agreements - team working agreements are always a great way to quickly negotiate the forming, storming, norming phases of team development;  these are living documents and should be posted in the team room, so that they can be mutated as understanding grows.

Definition of Ready & Done - a team with a shared understanding of their meaning of done will be much more likely to deliver potentially shippable working and tested software each sprint; a understanding of stories ready for sprint planning will lead to a robust definition of done; one is a precursor catalyst agent for the other.  See Also:  Exercise: Definition of Done.

Calendar - a very old planning tool; heck even the Maya used one.  A great place to note holidays, and events that will impact the team (like the beginning of the next sprint, the time of the next demo, the projected release ship date, etc.)

Backlog - a wish list becomes a Scrum backlog when it attains three things:  effort size estimates by the team that will do the work, a stack ranked deliver order made by the PO, visibility to the whole team (and by visibility I mean via an information radiator - not a spreadsheet on someones hard drive information cooler).

Trophy Model
Navteq data processing visualized
 components added to the model each sprint.
Release Plan - a backlog become a release plan when the team projects which stories will be slotted into which forecasted sprints within the release.  Think of this as a tool - not a report.  You will know it is a tool if it is updated frequently and if planning happens using this visualization - if not, sadly you have a report (reports are notorious for having stale information).

Day of Sprint - count down clock, I prefer to focus on the done so I like the days to count down to D-day (Demo).

Project Goals / Objectives / Elevator pitch - this is typically the release level objectives or release acceptance criteria - how will we judge each story as moving us closer or further from these objectives for this release - how do we know when the release has accumulated enough value to ship it?  See Product Positioning Statement in Beyond Software Architecture by L Hohmann.

Trophy Wall - big game hunters like trophies.  They can take many forms, like the data flow model done at Navteq.  It does wonders for the team moral.

Annotations


Avatars - photos of each team member (including the PO & SM); these should be small but instantly recognized as that person - even by an outsider or stakeholder (don't use Bill-the-Cat)

Impeded - bright colorful attention getting contrasting sticky - noting the reason the story/task is impeded. See '7 Aspects of a GREAT Impediment Sticky'.

Theme Dots - colored sticky dots to indicate themes (well know to the team - with a reference key and labels)

Dependency - sticky annotation to label the item as dependent upon another task/story.


Orientation - Horizontal or Vertical 


I find that everyone starts a task board with a horizontal flow, task moving from left to right.  This is easiest to conceptualize when beginning to adopt the practice.  However it will soon create an impediment.  I've found it amazing that few teams are capable of realizing this impediment and solving it.  The problem with the horizontal board flow is that the available space for stories is then limited by the human hight ergonomics.  We don't like to stand on step stools or bend over - therefore we have about 50 inches of useful space located about 2 feet above the floor.  This impediment will lead many teams to start creating smaller row heights for each story.
A Scrum task board in need of 90 deg. rotation.
Step back and visualize the problem.  We humans have a small range of vertical space that is within our ergonomic comfort zone - yet a large range in the horizontal direction (use your feet).  The answer is to rotate the task board by 90 degrees.  Make the flow of tasks from top to bottom; stories in columns.

Physical vs Software Application


Let's discuss the pros & cons of this aspect of the tools.  Ah... don't get me started.  There is no comparison, physical, tactical, haptic boards have far superior affordances than the expensive software doppelgänger.  When I'm teaching a team new to Scrum there is no replacement for a physical board.  The information that flows when one knows how to watch and read the negative space of interaction during the stand-up meeting is phenomenal compared to the stand-up using a projector and application.  And this level of observation is what the beginning scrum master needs to learn to pick up upon, it is orders of magnitude harder for me to teach using a virtual Scrum board.

However for a team that has mastered the basics of the process, and understands the reasons for most all of the behaviors they are practicing, moving to a virtual Scrum board will add a few affordances that are not available in the physical realm.  These affordances are portability, time dislocation, multi-site collaboration, etc.  All very advanced stages of team dynamics - WARNING - do not start with these attributes at the top of your team dynamics desires.

Google Ventures' Jake Knapp wrote about their war room - here are just a few of his reasons that resonate with this post:
Spatial Memory > Short-term Memory 
To solve a complex design problem, you need to track lots of moving parts. As humans, our short-term memory is not all that good--but our spatial memory is awesome. Plaster a room with notes and you take advantage of that spatial memory. You begin to know where information is, which extends your ability to remember things.
Physical Ideas are Easier to Manipulate 
We all know it’s better to re-order a prioritized list of sticky notes or re-draw a diagram than to make the same decisions verbally. That’s why there are whiteboards in meeting rooms and why people love agile trackers with sticky notes. War rooms take those tools to the next level.
See a video tour of Google Ventures' War Room:  Your Design Team Needs A War Room. Here's How To Set One UP  Want to foster creativity? Skip the foosball table and opt for a war room instead.

References:
Missing Affordances by David Koontz
Master's thesis paper: "Analysis of a paper- and software-based Scrum task board" by Jan Segers
Agile For All blog - Building a Useful Task Board by Richard Lawerence
Visual Management Blog by Xavier Quesada Allue Elements of Taskboard Design
Task Boards: Telling a Compelling Agile Story by Tom Perry



Saturday, November 16, 2013

Velocity Calculus

Velocity Calculus  -- by David A. Koontz
In the practice of Scrum many people appear to have their favorite method of calculating the team's velocity.  For many this exercise appears very academic.  Yet when you get three people and ask them you will invariability get more answers than you have belly-buttons.  That in its self is an interesting phenomenon, worthy of a blog post.  But this is not it.

Calculus is the mathematical study of change.



This video is a photo journal simulation describing how to calculate a Scrum sprint velocity.  It explains the calculus for one of the most difficult decision a team faces.  What to do with that first unfinished story.


Relative Points explained

Are your teams having difficulty understanding the relative nature of story points?  Try an analogy ... maybe one that is already well know... yet so often used that they have forgotten just how easy it is to use relative measures.  I'll bet they use it every day, multiple times per day.  That kind of practice makes usage very easy.  That is how easy story points will become for a team that practices.

Here's your analogy - in less than 10 seconds.  But you might need to repeat it about 14 times...



YouTube channel:  Minute Physics


Monday, November 4, 2013

Yahoo sees the ROI from canceling the work from home policy.  Who said: "collaboration tames giants in the land of Lilliput" - oh that was me.

"There is definitely merit to the idea, however, that bringing its agile programming teams together in the same place at the same time can have a small but crucial impact on performance. In his book People Analytics, MIT visiting scientist Ben Waber discusses the role of dependencies for programmers, that teams must coordinate closely to ensure their code meshes well. Citing others’ research as well as his own, Waber argues remote programmers are 8% less likely than co-located groups to communicate about dependencies, which translates to 32% longer code completion times--or death when you’re already as lumbering as Yahoo."

Read the article: Yahoo Says That Killing Working From Home is Turning Out Perfectly
by Greg Lindsay  Oct. 30, 2013.

http://www.fastcoexist.com/3020930/yahoo-says-that-killing-working-from-home-is-turning-out-perfectly

Friday, November 1, 2013

What is the impact of coaching?

Guest post by: Tracy Gibson  (tracy@gibson.name)

"If we don't change, we don't grow. If we don't grow, we aren't really living." ~ Gail Shelly


Long-term results are the impact of coaching. We all want to improve our life in an area of career and work, money and wealth, people and relationships, health and wellbeing, and/or learning and growing. Yet how often have we vowed to change and sooner or later, the resolve that we have to start has waned or the methods chosen seem too hard. That wavering moment is where coaching steps in and strengthens our resolve.

A good coach is someone who is an expert at helping others create positive change in their lives. For some clients, the positive change they most want may be focused on personal goals such as relationships, time management, work-life balance, stress reduction, simplification, health, etc., but other clients may be more interested in professional or business goals such as leadership, getting a promotion, starting a business, etc. An effective coach works with the client to help them live a better, richer life - regardless of their type of goals.

As it turns out, working with a professional coach is probably one of the smartest decisions you can make. According to a Visually infographic created for the International Coach Federation (ICF), 99% of people are satisfied with the overall coaching experience – and 96% would do it again.

Why Coaching Works
by swrightcreative.
Explore more infographics like this one on the web's largest information design community - Visually.

That’s because the coaching process helps people: unlock their potential; increase productivity and effectiveness; increase creativity; improve problem-solving skills; increase resiliency; gain self-confidence and trust in oneself.

While some of those benefits sound vague, many of them can be measured. Of those surveyed by the ICF, 80% said they became more confident, 70% said their work performance improved, 72% said their communication skills improved, and 61% said business management improved.

Many company leaders benefit from coaching as they seek to improve business outcomes. Employees are also vital to company success, and coaching can help maximize their talents. In fact, 86% of companies who hired a coach for employees reported that they made back at least their investment (IFC).

Done right, professional coaching can drive sales, employee engagement, creativity, workplace satisfaction, and bottom line results. The Chicago Tribune reports wellness programs have been shown to provide approximately a 300% return on investment (ROI). In other words, companies who spend $1 in a wellness program (e.g., exercise clubs, personal trainers, smoking cessation workshops) earn $3 as a result of decreased turnover, fewer sick days, reduced health insurance costs, etc. It is a no wonder wellness programs have experienced such tremendous growth; it makes financial sense.

“The ROI from professional coaching is even more astonishing. According to a Manchester Consulting Group study of Fortune 100 executives, the Economic Times reports "coaching resulted in a ROI of almost six times the program cost as well as a 77% improvement in relationships, 67% improvement in teamwork, 61% improvement in job satisfaction and 48% improvement in quality." (http://economictimes.indiatimes.com/)

 -- Article by Tracy Gibson

See Also:
35 Reasons you should Work with a Coach
The New Yorker - Annals of Medicine,  PERSONAL BEST Top athletes and singers have coaches. Should you?  by Atul Gawande
Performance Appraisals what have we learned in 50 years?  Where GE in the 1960's studied management's coaching effort to increase employee performance.
What is the ROI of Agile Coaching - by Payton Consulting