Skip to main content

Posts

Showing posts with the label Scrum

The shape of Classic Sprint Burndown Charts

 Many new leaders of scrum teams want to know what the burndown chart "should" look like.  Some even start running statistical calculations on the data (I once worked with a 'coach' that had a spreadsheet custom designed to extract just such anomalies).  The best answer I've given is a session on the whiteboard to explain: how the data is obtained how accurate & precise the data is - just good enough & not any better interruptions that MAY be made ... but only by the TEAM  So here is that whiteboard session - on index cards... Let's go one at a time. They are learning to make their work visible... praise this effort - it can be quite scary to show your work. Do not use tools that show this mathematically perfect line from start to finish.  Only robots are capable of such precession, and only with the perfect PLAN. If you see something like this in the first 3 or 4 sprints... it is a good sign.  Now reduce the scope of work by at least HALF. This is ...

#4 of 100 Agile Transition Guide Delights

A manager responsible for the delivery of Project X asks the team that will do the work to estimate a first release date.  That is defined as the next sprint goal.  The team plans to meet in the large conference room to estimate the backlog and create the first iteration of a release plan. Within the first interaction with a client, the manager tells me she would be happy if we could just get the team to deliver upon the milestones and release dates.  After inquiring as to who sets those milestones she stated that some times the company imposed dates, but that usually the team was asked to estimate when the project would be complete.  That it was only after missing several deadlines that the company executives would start imposing drop-dead dates.  This sounds like a client I can delight. 1st Objective: Predictable Team After training and workshops to teach a team many managers have goals or key performance metrics they wish to achieve.  I rather don'...

#3 of 100 Agile Transition Guide Delights

A new team member drew an "ideal" straight line from the top left of the burndown chart to the end of the sprint on the bottom-right origin-line.  Another team member asked why that straight line was IDEAL? What's the "Ideal" burndown? Just because some "agile" tool they have used in the past drew that "ideal" line, they thought that it helped the team to know if they were performing on target for the sprint.  I was delighted that Julien questioned the meaning of the "ideal" line.  I've never drawn such a lie upon my hand-drawn burndown charts and may have mentioned this anomaly (or ranted about its absurdity in a training workshop). Julien explained that our team was willing to take work into the sprint that was some-what undefined, that we were accustomed to learning about the solution as we discovered the problem.  And hence we often saw the task burndown rise before it curved down and we completed sprints.  Julien thou...

A Game of Experience - Scrum

Presented in OpenSpace at Agile Games 2018 for FUN and Feedback. This game design is not focused where you might assume - at training people how to "do" Scrum.  The inventors of the game, Tim Snyder and Derek Lane, are focused upon the experience of Scrumming, the group dynamics of being a scrum team.  The game has been designed, and is being refined with the objective of allowing groups of people that know how to do Scrum, to experience some of the Ah-HA moments that mature Scrum team learn after many, laborious retrospectives.  By compressing the group dynamic into a game with the glorious "happen-chance" cards causing random, yet all too common software development events, playing this game for a few hours can give you the deep insights that may only be achieved after months or years of real-life time developing products.  Learning doesn't require time... * Al Shalloway. One of the core questions Tim & Derek have been pondering:  How does one gai...

UnBoxing: Open Space Agility workshop

I'm taking Mezick's introduction course to OpenSpace Agility - thought I'd write a bit about what I'm learning. Unboxing the workshop - Your move Schrodinger. Day One: Beginning concepts - leaders have a duty to set direction and name constraints; yet stay away from telling how to achieve the goals.  Executives commits to holding first OpenSpace and Acting upon the proceedings.  And holding a second OpenSpace after a time box (100 days). A constraining forces in OSA will be the Agile Manifesto, actions and experiments should be judged by this definition and if seen to support it, be considered good. Another foundational concept of OSA - Self Management - defined as the behavior of a group to know and practice their decision making process (whatever that may be).  A good test is to ask 5 people how their group makes decisions - then count the number of answers - one general description of their decision making apparatus points strongly toward a self-managin...

Applying Little's fLaw to Software Development

Concept of Product Development Flow "I believe that the dominant paradigm for managing product development is fundamentally wrong.  Not just a little wrong, but wrong to its very core.  It is as wrong as we were in manufacturing, before the Japanese unlocked the secret of lean manufacturing.  I believe that a  new paradigm is emerging, one that challenges the current orthodoxy of product development."  -- Donald Reinertsen Reinertsen goes beyond the advance ideas of lean manufacturing, what he calls Flow-Based Product Development. Scrum was sparked by a paper called The New New Product Development Game by  Hirotaka Takeuchi and Ikujiro Nonaka (1986).  Are you seeing a synergy of ideas? Lean principle of Flow In the manufacturing world Toyota exemplifies the achievements one may obtain in 50 years of practicing a new mindset of principles.  Manufacturing deals with repetitive tasks predictable processes to produce component parts, hom...

Mandatory Stand-up meetings; in Indication of What?

What might it mean when the terms used in your Agile transition start to be applied to almost any fleetingly similar activity?  For example, the manager starts "inviting" the group to mandatory stand-up meetings, scheduled ad-hoc for the same day, with no agenda; at this "gathering" there will be a particular dynamic of communication, wonder what that style can best be described as...  Will it be anything like you wish at a team morning stand-up in the Scrum process that introduced the term? Is this a positive or negative indication of the perfusion of terminology? What is the positive aspect of people adopting the new terminology of an introduced framework? What is the negative aspect of this terminology being used to describe old and new behaviors as if they are similar. How should one address this with there supervisor? A conundrum I find myself wrestling with lately.  Do you have advice for me? A command performance for the Queen See Also: ...

Waggle Dance -or- Standup Meeting

Bees do a dance that bee keeper refer to as the Waggle dance... It is with great pleasure that you can watch and using the power of science have this dance translated into English. Bee Dance (Waggle Dance) by  Bienentanz GmbH What does this have to do with Scrum?  The power of a metaphor was well known to the creators of Extreme Programming (XP) - so much so, that it is one of only 12 "rules" that those really smart people decided to enshrine into their process.  It is also the most likely rule to not be mentioned in any survey of software development practices.  Unless you happen to be chatting with Eric Evens, and he may agree that he's captured the underlying principle in Domain-Driven Design, the Ubiquitous Language pattern . Have you ever observed a great scrum team using a classic tool of many innovative company environments - the physical visual management board (Scrum Task Board). The generic behavior for a small group of people (say around 7 p...

Velocity Calculus - The mathematical study of the changing software development effort by a team

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