Agile Complexification Inverter

I live in Texas, it comes with a unique flavor of people - my neighbors.  I was walking Malibu (my golden retriever) and stopped to chat with a neighbor mowing his yard.  I asked about his mower - an 80volt Kobalt electric push mower .  He liked it a lot, was glad he didn't have to store dangerous liquids in his home (gas & oil) and enjoyed the exercise.  I commented that the pollution from small engines was a significant source and that the internal combustion engine used in these tools was still based upon 19th Century technology.  I knew that he was a tech guy with a very large database company.  I was proud of his choice.  Like a true Texican, he remarked that was not his concern - that moving to electric was just moving the source of pollution from one place to another (his lawn to the power plant).  I suggested that that was true AND that the power plant was designed to deal with the pollution.  He ignored that info, I assume he was...

I've seen way too many teams working with just a big list of stories (they call it a backlog - but it's not).  Many of these organizations can find someone to play the role of the (proxy) Product Owner, and that unlucky bloke will do the best they can at prioritizing the list... but it's still not a Product Backlog. What is really amazing is when you hand that unlucky PO a list of SIZED stories and they can see the cost of those wee little things that seemed like a big deal because we've all been living with that crap since forever.  But now with the addition of a story size, those little nuisances become a top priority.  The team's value goes up in the eyes of the stakeholders and users because the apps are visibly being improved. "But sizing all those stories will take forever and a day." That is what my product owner said a few years ago at a client known for its storage products.  And being great organizers of storage, they put those skills to t...

The product owner calls everyone together and explains the "crazy" direction we are headed and why. Team morale does an immediate 180-degree turnaround and sky-rockets. Product Owner has a Sprint Goal This little tidbit of Sprint Planning often goes unnoticed, is frequently forgotten or never mentioned. But when you see the difference it makes for a bunch of devs that thought we were building the wrong thing and then realize how crafty your product owner is... well you will not forget to insist on the reasons - the goal of sprints you and the team are running. Years ago, in a rainy distant land far from sunny Texas, I worked for a SpeakEasy. The company was a hot-shot in ISD land (Internet Service Delivery in the days of modems). They had this crazy idea to build a Voice-Over-IP telephone product and hired out the tree-hugging hippies from a little consultancy company across the lake. These hippies said they had a new collaborative way to build products that work...

A package just arrived, express mail from a toy store.  I tear it open and inside are 40 PEZ dispensers and candy.  They are gifts for the teams.  Tomorrow will be a delightful day. PEZ in place of Task Hours When the team acknowledged that the task estimates would never accumulate to the number of work hours in the week - we had a great discussion.  The team of 5 people worked the typical 40 to 45 hour workweek.  Yes, we had lots of overhead chores that took us away from actual productive work on story tasks each week.  As well as those pesky Scrum meetings like planning, review & retrospective.  Heck - just doing the company's time accounting BS each week took an hour.  Yet, it wasn't like we only worked 3 to 5 hours per day.  Maybe we would be much more effective if we worked half days. Is it our inability to estimate accurately? Our over-optimistic nature? The fact that many of our tools required too much time to navigate and we...

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

An Exercise in Estimation:  How many times can you fold a piece of paper in half & half again... I do this exercise when beginning scrum teams start story estimation or task estimation.  While this exercise has a unique twist that is very different than task estimation or story estimation - very few people foresee this aspect of the exercise, so it adds to the ah-ha moment. Start by giving everyone a sheet of typical paper (8.5 x 11 in the USA - although the size just doesn't matter).  Then tell them the exercise but ask that no one do any thing yet.  First we will estimate.  The task is to estimate how many times you could fold the paper in half and then again in half and repeat... without doing it what's your estimate of the number of folds? Ask people to call out their estimate, write then on a board in no particular order or fashion. Typical groups come up with estimate in the range of 5 - 20 folds. If you want to do math... calcula...

When asked, many people wish to get better at estimation by tracking actuals and then assuming that some form of reflection upon those actuals will lead to better estimation.  I've long held a belief that it doesn't happen quite so simply in reality.  There are many assumptions in that proposal that are just glossed over.   Let's list a few (just for fun):  Actuals are accurate and precise representations, time will be allotted to reflections and learning,  people (teams of people) will all arrive at similar conclusions and learn from the reflection of estimate not equal to actual, future behavior will change significantly and quickly, among other assumptions. Well finally science has something to say about this.  A study: " How unrealistic optimism is maintained in the face of reality " by  Tali Sharot , Christoph W Korn & Raymond J Dolan  published in Nature Neuroscience (2011) has some fMRI proof that these behaviors are hard to...

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 Don't mistake preception of temperature and the measurement of temperature.... see Derek's Veritasum experiment: Misconception About Temperature . Now... relate the misconception about temperature back to the topic of relative points...

How precise are your estimates?  Are we inferring false precision with those 5 significant digits? I saw an hours estimate for a medium size project at our company just the other day.  I don't remember the actual digits, but that's not the point it was a number like: 4145.8 hours Let's just assume that a team of 7 people will do this project.  How many weeks is this?  I'd guess 4145.8 hr divided by (7 * 40) equals 14.806 weeks.  Or, as a human would say it 15 weeks, give or take. Are those digits really necessary?  No.  Are they even real?  No.  They are just artifacts of inappropriate rounding or truncation.   There is very little doubt that someone could estimate a 4000 hour project down to the quarter of an hour (the implied accuracy of the 0.8 hour).  And if you think they are so good at estimating that they can distinguish between 45 hours and 50 hours for a portion of this project - well, then keep on trucking to the mi...

What will increase your web-blog traffic the most - getting aggregated into a well known site like All About Agile   or pictures of dogs? Well it may be too early to tell for sure.  But here are some early stats. Daily stats for the week that my site was added to All About Agile some time Saturday.  I see traffic up about 100+ page loads.  That's great - wonderful. However that's just one data point, and one aspect of the study.  What drives traffic to a blog? I have another data point.  In late November I added about 12 dog photos on a post about story estimation.  How has that effected traffic? Here we see monthly (not daily) page load counts.  That spike in December, 90% is the dog story from Nov 28th.  Below are individual pages, my site sees a few hits a day per story - until aggregated with All About Agile, then it bounces into the 20 - 35 range.  But nothing compares to pictures of puppy dogs! So go ahead... I know you...

Do you know what your team's sustainable pace is?  Do you believe it is equal to their Velocity? Let's try to answer that question. Scrum tells us that we should be Sprinting toward the goal of delivering working software.  But then it tells us that we should work at a pace that is sustainable over the long haul.  Is that an oxymoron?  Or is that Zen? Velocity is the rate at which the team is delivering valuable-working-tested software to the customer.  If that velocity is at a steady state then it is the sustainable pace for that team - right?  I'll agree to that - if that velocity is relatively steady state over 2 years of time.  Then there is a high likely hood that the velocity accounts for vacation, holiday, sickness, team member changes, and growth of the scope of the definition of done for a sprint. So how do you get a team working on a project to a steady state for two years?  In this industry - you don't!  But that doesn't ...

Columbus Coat of Arms Christopher Columbus' purpose was to find a faster, safer route to the silk , spices , and opiates of Asia (a total system rewrite for the failing legacy system - Silk Road). "Columbus map", drawn ca. 1490 in the Lisbon workshop of Bartolomeo and Christopher Columbus [1] Was his problem that he didn't know his location and the location of his destination?  No.  Those were knowns to him.  He had maps of these locations. Was his problem that he didn't know how to navigate?  No.  He was an accomplished ship's captain and in those days you had to navigate via dead reconing and he was adopting the new technology of celestial navigation .  I'm practicing a bit of historical speculation but in his day, figuring out Latitude was hard but a known problem with lots of calculations requiring a computer (person good with figures & lookup tables).  Guessing at Longitude was an unknown problem. It would be centuries before t...

First let's talk about Numbers , then something else, and then Story Points. Number, integers and real numbers provide the scientist with a very valuable tool, a continuum of regular spaced labels for comparison purposes.  These integers are sequential with no gaps or voids.  This is quite special in nature, for there are very few things in the natural world that are so regular and consistent over an infinite range. Let's look at the number 10.  It's a nice round number (divisible by two) and it has a roundness to it's drawing.  It is a commonly used end point in quizzes and surveys.  Is there something special about it - why not use 12?  Chicken farmers do, bakers do, why don't we in the Agile software world?  No - we use unlucky 13. Something else - Font Sizes What's your favorite font size?  I'm betting 12 point.  Because it is the default on most software programs - I'll wait take a look.  While you're up there at the font ...