Agile Complexification Inverter

 They tell me I'm not a Rocket Engineer -  and it's true.  To think like a rocket engineer is to think very differently.  So who is  a  rocket engineer - I bet you came  up with the name Elon. Here is Elon's  thought process for building  rockets. Make the  requirements less dumb.    Question the   requirements - the constraints  are wrong.   Especially  if the requirements are given by an  expert.   Also all requirement need to be traceable to a  person - not  a department. Delete the  part or the  process  - it's redundant or not at all needed.   Remember the  human  bias is to add.  The rocket engineer should be adding back only after first deleting and proving it  must be added back (an  acceptable rate of  re-addition  is 10%). Simplify or  optimize  only after steps 1 &  2.   Never optimize early.   Do  NOT optimize the thing that shouldn't  exist.  Example SpaceX grid fin folding parts - they just are not needed. Excelerate cycle time.   But only after 1,

Unlimited Agility Hello! I'd like to invite you to our community, Unlimited Agility. It takes less than a minute to join and together we're sharing our stories, experiences, and ideas. I know you'll love it. See you here! David Koontz David Koontz Join Me Unlimited Agility   Discovering unlimited agility through servant leadership. Are you looking for a safe place where you can grow as a servant leader? The UnlimitedAgility community focuses on growing servant leaders through... Join Us Now You've been invited to join Unlimited Agility | Unsubscribe   Unlimited Agility is powered by Mighty Networks 127 Lytton Ave, Palo Alto, CA 94301 |

 Where do you stand on the imposition of a process upon the workers doing the work? Is this Imposition OK in the Agile community?  Well, yes if one observers the work in enough work places it becomes quite obvious that this is common practice, and done by the most Agile of the change initiatives. But have YOU stopped to question this practice of imposition? Martin Fowler - Where we (the agile community) are in 2018 - 3 main topics (AIC Imposing Process, Technical Excellence, Organize around Products) at Agile Ausis (2018).  "It sounds like success."  "Individuals and Interactions over Process and Tools" - "The team chooses its own path."  "And it goes further than that..."  "the team should not just choose the process, but they should be actively encouraged to continue to evolve it and change it as they go..." (7 minutes into talk).

 Hey Manager,   I'm going to work from home this week, you can IM me if you need anything.  I will be at the beach with my family.  No, I'm not talking vacation - why would I... I'll be working. How will you respond? Returning to work is going to raise some command and control issues.  Are you buying the works time and presence and efforts for an 8 hour day - or has that changed?  We have experienced a different way.  Can we discuss what this means upon the return to work?

 Many new leaders of scrum teams want to know what the burndown chart "should" look like.  Some even start running statistical calculations on the data (I once worked with a 'coach' that had a spreadsheet custom designed to extract just such anomalies).  The best answer I've given is a session on the whiteboard to explain: how the data is obtained how accurate & precise the data is - just good enough & not any better interruptions that MAY be made ... but only by the TEAM  So here is that whiteboard session - on index cards... Let's go one at a time. They are learning to make their work visible... praise this effort - it can be quite scary to show your work. Do not use tools that show this mathematically perfect line from start to finish.  Only robots are capable of such precession, and only with the perfect PLAN. If you see something like this in the first 3 or 4 sprints... it is a good sign.  Now reduce the scope of work by at least HALF. This is wha

 Years ago there was a pattern in the Scrum community - loosely call "Kidnapp the ScrumMaster" - I googled and didn't easily find it - so here the reason this is a good practice . In general I am not talking about kidnap and ransom... I'm talking about agreeing with the ScrumMaster before the daily Scrum that they have an important personal errand and they just disappear for 30 minutes, with no warning, no preparedness, nothing - just gone! Then observing the team, from a distance - do not take over any of the duties of "DRIVING THE MEETING" (yuck) do not step in and facilitate.  The objective is to see the team, wait a few minutes and then start their daily Scrum meeting without missing a beat. If this can happen for the SM it could happen to any Team Member.  Feel empowered to kidnap other Team's players from time to time to test the resiliency of the teams.   I suggest once a month all the SM meet at the local coffee bar to have a group kidnapping.

 Here is the set up of the classic joke: A human brain, a dolphin brain, a octopus brain, and an  ant brain walk in to a bar.... Well that will not happen... but 4 diverse experts studying those creatures brains did walk into an interview and this is what came out of it. "Redefine 'Man',  redefine 'Tool', or accept chimpanzees as human." -    Louis Leakey PARTICIPANTS: Simon Garnier, Suzana Herculano-Houzel, Frank Grasso, Denise Herzing MODERATOR: Faith Salie