Skip to main content

Be Interruptible

A concept grabbed me today. "Be Interruptible"





Click the link below to read a great article about it:

Be Interruptible


The reason it grabbed me is because like a Product Owner cannot stop stakeholders from coming up with ideas, we can't expect the world to wait, or your family to not need you just because you are deep in thought about a complex problem.


It made me ask the question, how do I slice up the work that I do so that I only need to be in deep thought for shorter bursts of time? Very similar to why we split User Stories to be small so they are independent and easier to complete in a few days.


If the answer is to "be interruptible" what are the ways to work towards this goal? The simplest place to start is to admit that our brain and memory are not built for holding and manipulating large amounts of data for long periods. There is a reason why you see Physicists using massive chalkboards, imagine having to do those calculations in one sitting uninterrupted.


We can copy their approach and try to always use a simple, fast solution to "Save Your Game" such as a whiteboard, sketchpad, sticky notes, storyboard, notepad, story map. Find your favourite tool and use it so that you can "Save Your Game" at any point you get interrupted and resume your game from where you left off with a reduced risk of having to start your train of thought from scratch.

#beinterruptible #agilemindset #continuousimprovement

Labels:

Comments

Post a Comment

Popular posts from this blog

Increasing Analytical Thinking in Agile Teams

Shameless promotion alert! I did a talk this week with the Agile Auckland meetup that was about increasing analytical thinking in Agile Teams. Agile Auckland kindly filmed the virtual session and its uploaded to YouTube here. If you are passionate about analysis and improving the quality of it in your Agile team, please go and check out the video. A link to the Youtube video is below
Post a Comment
Read more

Misusing the word Requirements

The more I think about the word #requirements the more I think it is and has been misused for decades, by myself included. Imagine I have a bunch of nuts, I don’t know what size the nuts are which means I don’t know what size spanner I need. I could write a BABOK format Requirement that explains that “The solution shall have a spanner that loosens a nut easily” but no one can build anything from it because we don’t actually know what size spanner to build. We don’t need a requirement. We need more information. How about a hypothesis instead? I believe that if I test a range of spanners on the nuts I will find the right size, I will know when I am successful as the nut will be turned by the spanner without slipping. Now this tells me what I need to do and how I know I will have found an answer. Let’s imagine the result is that we discover we need a 10mm spanner for our 10mm nut. Now I can write a requirement that says The solution shall provide a 10mm spanner that can turn a 10mm nut co...
Post a Comment
Read more