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 separate their teams along

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 very good - it is almost like English i

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 you see this