Agile Complexification Inverter

Have you heard about the PO's new assistant?   It is quite the item of gossip - isn't it? Could you imagine if we were to outsource our development jobs to someone?  Someone in another country, a foreigner,  or an artificial life-form, an AI - oh the shame of it all! What would it require to craft an AI with the ability to write a Product Backlog?  Would we require special software, expensive specialist knowledge, and millions of dollars? Would we be able to trust that the user stories the AI wrote and placed in our backlog were the correct requirements for our unique product? It is the 21st Century - we have to be ready! That is a quote from Captian Jack Harkness , and he is in a Time to know. Let's run a test.  Let's try the AI out and see if it could write the basic product backlog for a travel app.  Phone apps have been around now for 15 years or more.  The best ones are targeted at just such a task.   We could then see if the AI generated us...

It ain't nothing - until I call it. - The Umpire  My brother was an intramural league referee at App State (that's Appalachian State in NC); that's the most important lesson they taught beginners. So if you were going to start to program a baseball game - where would you start?  At some point, you are going to come to the conclusion that on any given play... anything could happen... that is until the Ump calls the play.  So is this key person part of the object model? In November Lance Kind & I are going to start on a venture to program a baseball game - in Swift on the iOS Apple platform.  We are going to start with Test Driven Development - Red, Green, Refactor.  The end goal - to have an App to launch in the Apple Store. I'm not real sure what that App might do... but I trust it will emerge and we will learn quite a lot about the app as we build it.  We have set some other objectives:  to practice TDD, to learn Swift 5+, to use SwiftUI (a de...

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

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

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

You have not empowered a person by telling them "you are empowered."  This is a classic mistake in communication.  When one does this, they misinterpret their message, "I'm empowering you..." with the action that a verb such as empowerment requires to happen.  This person is taking a short cut, by giving the platitude of empowerment in place of any action that would be view by the other as empowering. "When told that they are empowered to do something; this message is actually interrupted to dis-empower the persons agency." How does this misinterpretation occur?  Why do we humans mess up this simple act of communication? Let's look at an example: For a few months I had been working with a new team of software developers at a large organization.  Like many organizations they had already done the agile/scrum thing and it didn't work for them.  Recently the leadership had built a satellite office and started from a very small pool of tenur...

Countless times I've heard people say they hate the Scrum joke about the pig and chicken .  Some people just can't tell a joke. Jeff Sutherland points the fickle finger of fate at Ken Schwaber for starting this fable : I've hated having to tell teams this joke... the lore of the Scrum pig and chicken is so pervasive that before long someone is going to call someone else a chicken (or a pig)... and then you have to tell the joke to help that person retain face... it can be quite uncomfortable for me. I think my disdain for this joke has to do with two of American's least favorite farm animals being featured.  We call people chickens to say they have little courage.  We call people a pig to insult their appearance (clothing choices, weight, manners).  Had the joke featured a cat and dog... it would be so different - wouldn't it? Now Jake it appears has taken this joke metaphor to a new level...  good job Jake! See Also: It is 2018 and this j...

Here's a overview of a Scrum Immersion workshop done at GameStop this month. A case study example. Normally these workshops start with the leadership (the stakeholders or shareholders) which have a vision for a product (or project). This time we skipped this activity. The purpose of the Workshop is to ensure alignment between the leadership team and the Agile Coaches with regards to the upcoming scrum workshop for the team(s). Set expectations for a transition from current (ad-hoc) practices to Scrum. Explain and educate on the role of the Product Owner. Expected Outcomes: Create a transition plan/schedule Set realistic expectations for transition and next release Overview of Scrum & leadership in an Agile environment Identify a Scrum Product Owner – review role expectations Alignment on Project/Program purpose or vision Release goal (within context of Project/Program & Scrum transition) Once we have alignment on the Product Owner role and the Project V...