Agile Complexification Inverter

Sarah asked the team during Stand-up if she could pull in the other slice of the sorting widget she had been working upon. The team looked at their board - everyone agreed they would have all the stories done by the end of the sprint and no one needed Sarah's help so that would be a good plan of action. Working toward TINY is the key to increasing Velocity How do you increase your Velocity?  It's not by planning to do more work!  It is by finishing more work - FIRST! I delight in a team that proves their capability before they plan upon that capability. Let the action preceded the planning, such that we are planning upon a strong knowledge of success. When beginning teams wish to become high performing many mistakenly feel that getting work started earlier is the secret - it is actually the opposite of starting more work.  There is a lot of learning involved in finishing work.  This is where the high-performing team differentiates itself from other teams....

After several sprints of FAILURE, the team decides to cut in half the stories it takes into the sprint. I have worked with enough teams that are beginning with Scrum to estimate their beginning velocity fairly accurately.  Most believe I am full of IT when I suggest this.  So instead of taking my advice, they plan to fail. Start with Velocity/2 RECURSIVELY How would you define success and failure at the sprint level for a brand new (to Scrum) team/group.  I try to make it very simple - we are successful if we achieve the sprint goal.  Typically with new teams, the only goal is to accomplish the stories we've put into the sprint.  So it's easy to define success - 6 stories put into the sprint, 6 stories done at the end of the sprint, and we have a success! Invariably the team does NOT finish all 6 stories and so the result is NOT success or failure.  That's so simple.  Now if we keep track of this for a few sprints, and the product owner starts...

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. Velocity—the rate of change in the position of an object; a vector quantity, with both magnitude and direction. “C alculus is the mathematical study of change.”  — Donald Latorre  This pamphlet describes the method I use to teach beginning teams this one very important Scrum concept via  a photo journal simulation. Some of the basic reasons many teams are "doing it wrong"... (from my comment on Doc Norton's FB question:  Hey social media friends, I am curious to hear about dysfunctions on agile teams related to use of velocity. What have you seen? mgmt not understanding purpose of Velocity empirical measure; teams using some bogus statistical manipulation called an average ...

Is your "Agile Project Manager" driving the team to increase their velocity?  Has the Agile Death March begun? Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month . One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates.  So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers.  A classic game (Innovation Game) to expose these impediments is Speed Boa t. I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game .  See the article by Alan Dayley  Velocity is Like a Helium Balloon  ...

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 te...

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.

What metrics do you collect to  analyze  your scrum team? It's the Trends of Metrics that matter. We live in a world of data and information.  Some people have a mindset that numbers will diagnose all problems – “just show me the data.”  Therefore many directors and senior managers wish to see some list of metrics that should indicate the productivity and efficiency of the Scrum team.  I personally believe this is something that can be felt, that human intuition is much better in this decision realm than the data that can be collected.  However, one would have to actually spend time and carefully observe the team in action to get this powerful connection to the energy in a high-performing team space.  Few leaders are willing to take this time, they delegate this information synthesis task to managers via the typical report/dashboard request.  Therefore we are asked to collect data, to condense this data into information, all while ignorin...