Pocket Coach

I am guessing we all work in some kind of hybrid environment these days, with VC, headsets and Miro Whiteboards. When thinking about setting up a new or existing Scrum team how do you choose where they will work? Should everyone try and be together physically on "High Value Co Location Days" for things like Sprint Review?  If your VC is really good and everyone has their cameras on maybe you and your team are 100% remote? Maybe your company has mandated which days you should be in the office? I am interested to hear from you how you and the teams you coach with have set up your hybrid Scrum environment for success.  In the image is an example of one teams set up for where they work in their hybrid Scrum team environment. #hybridworking #scrum #agilecoaching

Have you every wondered what it takes to create a Coaching Practice in your organisation? What will it do, how is it structured, how will people know what services are on offer.  An internal Coaching Practise is like a little business. You have to start with why and understand what your customers needs then create a practice that can provide products and services that helps meet those needs. Where I work my Coaching Practice started with a Service Catalogue, this is our list of all the services our team offers to our customers in the areas of coaching, facilitating, mentoring, teaching as well as technical, transformation or business mastery. Need to rent a Scrum Master for a few days? We got you! Need help to facilitate a user story mapping workshop? We got you! A comprehensive service catalogue is a great way to share with your customers what your coaching team can offer. #servicedesign #coaching #agilecoaching #agility

Teaching teams to change their mindset, to develop iteratively instead of incrementally is hard. I always find examples help. Yes there is the classic Skateboard to Car picture but why not think up some real world examples to share with your teams, something simple that provides the same outcome as a more engineered product. One of them will resonate.  For me it was the Guitar one below. I watched Jack White make a one string electric guitar out of a plank of wood and he played a song with it! Would I need to develop more? Well, that's up to your customers. #agilemindset #productdevelopment #coaching

For years I have collected books, URLs, Blog Posts, YouTube videos, pretty much anything I can to keep learning. 20 years ago I had a very well organized set of Browser Bookmarks that moved to GetPocket & Feedly. I didn’t realize it but for the last 20 years I have been building my “Second Brain”. A collection of my Goals, Projects, Tasks, Resources and Knowledge collected across a set of curated tools. Recently I discovered that Notion.so (one of the tools I have used for the last 5 years) has a template for a Second Brain so I can pull everything together in one place through the power of relational databases.  The image below shows work in progress the consolidation of my second brain, based around the P.A.R.A. Method by Tiago Forte and some lessons from the book Make Time by Jake Knapp. Each Brain Area has a definition and purpose, projects, tasks, resources and a knowledge base, each of which is just a view of the related databases that are filtered for each Brain Area. I ...

Flow Efficiency! Although my Coaching team have used it for a while to gain insights, this year we are working with teams to formally measure it. The goal is to focus our teams on identification of waste in our end to end system, understand team processes better, use Flow Scores as a way to gauge if improvement experiments have moved the needle and contribute to our continuous improvement mindset. #flow #productivity #lean #agilecoaching #mindset

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

I was looking over old slides today and found this one I made from 2015. I have always liked it as it shows the collaborative nature of Agile & Lean practitioners and where the practices, that many of us perform daily, originally came from before the Agile Manifesto even existed. I think I need to update it to include practices from Design Thinking, Lean UX and DevOps. #agile #devops #lean #designthinking

Carrying on our Flow Efficiency focus, if your organisation uses Azure DevOps make sure you install the Marketplace Extension called 'Work Item Flow Efficiency' by Jeff Przylucki. It allows you to capture flow metrics for each team and provides a historic graph of running efficiency over a 12 month period. My team uses this tool to help our product teams try to identify where the waiting and waste is in their end to end flow, encouraging them to experiment and re-score to see the outcome of their experiments. #agile #flow #experimentation #leanthinking

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

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

With my current focus on #flowefficiency where I work, I thought it was a good time to share how we are ensuring we focus on leading indicators instead of lagging ones. Having collecting 2.5 years of metrics during our Agile journey so far, its sometimes tricky to measure the right thing. What you measure tends to drive unwanted behaviour. I think of a lagging indicator as something that has already happened. For example how many stories did a team complete, how many teams completed all committed stories, what is a teams current Flow Efficiency score? These metrics are useful, but don't necessarily lead me to my desired outcome. They just tell me what the current state is.  A leading indicator leads me towards the outcome we want to achieve. I think of it as the impact or behaviour change we need to see to achieve the outcome. When you think of it in these terms you need to think about how to measure the changed behaviour. For example, to improve the flow efficiency score I need te...

Have you every worked out what your team cost per story point is? I have and it has some pros and cons but largely I found it valuable. Here is why. Let's imagine your team has got to the point of consistent, predictable delivery and the number of story points completed is pretty accurate each sprint. Let's also imagine you have created a pretty good User Story Map that  shows which stories are required to deliver a Feature. At this point I can total up the number of story points for a Feature to understand how much it is going to cost to deliver.  In one teams case this was $2,370 for a Story Point and a Feature cost on ave. was approx $15,000. What this did was help not only the Product Owner but also the Business Stakeholders decide if they really wanted to "Buy" that feature. Would the value be worth the cost. If you have never played the "Buy A Feature" game I highly recommend it - https://lnkd.in/gyhkbShF There are some Cons to this approach, you must ...

Asynchronous Daily Scrums, hot new thing or a great way to avoid face to face contact? If you are still doing Scrum the same way you were last year, maybe you haven't identified continuous improvement opportunities at your Retrospectives? I always keep this in mind when new trends pop up. Asynchronous Daily Scrums might be something you haven't heard of yet, click the link below if you are unsure. My Coaching team have used them, we didn't start with them, we experimented and found they worked for our team. But everything has pros and cons. For example how do you get clarification quickly on something if you are just leaving a message for stand up, what if the work someone says they are doing today has nothing to contribute towards the Sprint Goal? What are your thoughts and experiences on asynchronous daily scrums. https://geekbot.com/blog/asynchronous-scrum/

There are quite a few Law's that underpin Agile, lets start with Gall’s Law — “A complex system that works is invariably found to have evolved from a simple system that worked.”  Almost every product you use these days have some level of 'Feature Rot' caused by adding more and more features to try and attract new customers or keep existing ones. A great, and funny, video on this is from Des Traynor, link below. https://youtu.be/9AM6QQlgLSQ

More Laws of Agile, today is everyone's favourite, Conway's Law. “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” I have certainly experienced and witnessed this one but why is this a problem?  A study by MacCormack, Carliss, and Rusnak at Harvard verified that a loosely coupled organization produced a software design whose components were less tightly coupled than designs produced by a more traditional tightly structured organization. Tightly coupled components are typically single purpose, highly dependent and not easily reusable. This means harder to diversify, pivot, enhancements and maintenance are more costly. To start to understand how to overcome Conway's Law this article on The Inverse Conway Maneuver is a good place to start. Conway's Law