Agile Complexification Inverter

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

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

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

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

I delight in the realization a new team member has when task estimates do not equate to actual clock hours. Task Estimates != Sprint Time Task Hours vs Day of Sprint - Burndown Chart In the activity of updating the sprint burndown chart, a team-mate notes that the sprint contains 3 to 5 times the amount of work hours as our accumulated task estimates. Wonder where all that extra time is spent?  This epiphany occurs because I require the team to calculate and hand draw the team's sprint burndown chart. Immediately after stand-up someone (an unassigned, expectation upon the team) does the task of updating the chart.  They calculate the task effort remaining for all unfinished stories and update the burndown chart.  I am delighted when she notes that the sprint has 2 weeks for 5 people, meaning 2 X 40 hours X 5 people = 400 effort hours per sprint.  Yet we are only estimating and accomplishing something like 130 - 200 effort hours over the last several success...

I received this letter from  Jurgen Appelo and thought it might be worth posting here as an example of good criticism and taking action, rather than just complaining.  Yes, there is a  call-to-action   down near the bottom. Dear David, In the Lean-Agile community,  there is a ton of criticism on the topic of certification . Most certificates have little meaning, prove nothing, empty your wallet, and are little more than nasty money-making schemes of savvy certification bodies. At least, that is the sentiment that I usually hear when I bring up the topic. I believe it’s worth trying to do better. 1. Accomplishments One reason for improving upon the idea of certification is that many people find the motivational aspect of certificates to be a positive thing. Human beings crave recognition.  We all want to feel appreciated for the work we do and the successes we have achieved . Badges, awards, trophies, and certificates are standard techniques for signa...

I've been around agilist and SW devs that are using the term MVP quite a lot these days.  And when we get deeper into the conversation I learn that the thing there are referring to is not at all an MVP . It's not the box - it is the Star! Perhaps we need a better term.  Perhaps we should define the terms we are using.  Perhaps we should just use the tools we have to find the better term.   Or I could just tell you - the better term is MBI - Minimum Business Increment . Why does MVP not suffice?  Because to have a product one needs a customer that has paid for said product.  And the purpose of the MVP was to learn for actual customers about how they liked our product and if we should change it in any way.  It was also a test of our current business model, and an opportunity to learn about our business model (was it efficient, could we optimize it in some way, etc.). Most MVPs I've discussed with people have no customers - there is no exchange ...

I've been attracted to people that are self-aware of their own cognitive bias.  And I will have to admit that I'm not as self-aware.  Yet, I now have a wonderful mental model of human cognitive bias.  A tool to understand and categorize the many, many biases and the questions to inquire into my own preferences and biases. The article on Medium by author Buster Benson tells the story of his research and learning and the collaboration with graphic artist John Manoogian III - I suggest you read it. References:    Cognitive bias cheat sheet - Better Humans Wikipedia's list of Cognitive Biases Buy the Cognitive Bias Codex poster

Door Security Protocol: Find the next number in the sequence 313, 331, 367, ...? This is a test... How long will it take you to work this out... Quite a while is my guess.  And only a few will actually try to figure it out.  Most will give up, a few will search online, and a few will have already seen the sequence recognize it and either remember the answer (the next number in the sequence) or derive it with the sparse knowledge they remember about the sequence. Spoiler Alert!  Let me give you the background knowledge. You know what a Prime Number is - do you recognize that all the numbers in the list are prime? Do you know what a Happy Number is?  Or it's inverse an Unhappy Number?  Well, this is a bit more obscure in the general knowledge.  So here is a spoiler...  all those numbers are happy!  They are Happy Primes! A number is happy when the repeated practice of replacing the number by the sum of the squares...

Recess Kit I've found yet another tool for improving teams.  This is a subscription service that monthly sends you and your team a fun and engaging way to reflect upon your work and discover areas to improve.  Take a look at their site and offering and give it a try like I did. I will update this post as I get to experience Recess Kit and their monthly box of yummy with my team. See Also: Retromat - A well planned Retro Retrospectives trump Planning Collaboration Tools List

Pondering... why are gender "neutral" words such as craftsman are not as gender neutral as we men seem to think they are? I've been personally trying to break myself from a bad habit... one that I've thought was not such a big  deal...  I use the term "guys" in mixed company to describe a group of people ... not yet a team.  In mentoring groups toward becoming a team, I reserve that term for groups that truly behave like a real team.  I was giving a presentation at a local special interest group and afterwards a person gave me some useful feedback... my usage of the term "guys" was distracting and verging on "off-putting" in the room of mostly females.  I needed to read the audience and the room - and choosing the proper term would help them to engage... what I truly desired. I remember in the 1970s (yes this should date me) teachers in school told us that some words were considered gender neutral - I believe that "guys" w...

At what age should we be inspecting all this code full of colons?  Sometime in 1970's the software world had a lot of colons evolving - 1973 for the popular C Language and its family... That tells us that in 2023 at age 50 the C Language should begin Colonoscopy procedures, yearly.  It's not a pleasant thought but it is the recommendation. Now some of the more modern (non-legacy) code may not need this extreme level of screening... but how would one know - unless one probes around in all those semicolons. Now, many Proctologist have worked to make this procedure less stressful, what have we done in the software community to improve patient outcomes, and satisfaction with our inspection and visualizations? Jokes from the Hole (A Proctologist's Perspective) Shall we work on that?