Agile Complexification Inverter

"That went very well."  Said in reference to today's sprint planning session, and an inferred commentary upon the previous planning session which was a tornado disaster zone of a trailer park. Few people like to attend a disaster waiting to happen.  But I've found that there are times when it's the best thing that can happen for a team.  And while I don't cheer for the tornado, I don't mind its visit to the sprint planning meeting once in a while. I'm typically heard explaining why the tornado hit our little trailer park... it's because we didn't do any (or enough) backlog refinement .  And then people want to know what backlog refinement is - what should happen in these "meetings"? If you search the old books and articles on Scrum you might not find this meeting mentioned.  But that's just because refining the backlog was something that most teams understood needed to happen and did what needed to be done.  Somewhere alon...

There are many ways to decompose a large task into smaller portions.  When agilist start doing this there are a few general ways to do such a thing.  Let's start by distinguishing between a story split and a story slice. Splitting != Slicing If you've spent some time with an ax and a pile of wood then you understand that many logs have a naturally easier way to split along with the grain direction.  It requires much less energy to split a log than it does to slice the log. If you've spent some time baking cakes you know that people like to slice cake.  You never hear of a person wanting a split of the cake.  Many cakes have multiple layers, sometimes with different flavors in each layer. What does this have to do with software development stories?  Well many software systems have layers, and it turns out that it is easy to split the layers apart.  For example: the UI layer is easy to separate from the Persistence layer.  Many organizations...

I am working with a team that is in transition.  They have been told that they will practice Scrum.  I don't bother to question this directive from above.  I figure that the people above the team don't know why either...  oh, yes they were at the company all-hands meeting where IT was handed down, there were the typical platitude reasons for the change, faster time to market, being able to respond to new influences in the greater marketplace (e.g. AI, Serverless Environments, etc.) all sounded great at the town hall.  But when asked why this particular team that will never see those technologies in their arena would need to practice Scrum - the best reason is - because we said so.  So that is the CHANGE - it has been forced upon these 7 people.  I am acting upon the transition they are going through.  The current transition is in writing stories.  All have said they are use to working with stories, so we dive right in... but they are not ver...

Have you had that conversation with the struggling team that wants to switch to Kanban?  They don't really know why - but they've heard that Kanban will be easier.  So why don't they switch processes? We are failing at Scrum, so let's switch to Kanban! Does that sentence make sense in your world?  I hear it quite a lot.  Well not stated that emphatically.  In fact, most teams don't know that they are failing at Scrum - but they are... it is such an easy process to follow - how could you fail? More Prescriptive -to- More Adaptive Cutting to the gist of the problem - a team that cannot complete stories in a sprint.... well they are failing.  You could ask why they cannot complete stories in the sprint.  There may be several legitimate reasons, typically it is an impediment beyond their control.  Something like getting "sign-off" from some stakeholders that the feature desired works as expected and doesn't break anything else.  When yo...

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