Emerging workplace etiquette and maintaining a safe working environment…
People adopt different tactics to deal with emotional interactions and responding to emails emotionally can have long lasting effect on working relationships.
Favouring Individuals and Interactions over Processes and Tools.
Receiving an email with emotionally charged language or aggravated tone can really impact your day and can have flow on impacts to others around you. Not forgetting the direct relationship impact between the sender and receiver.
It pays to give some thought to the intent for passing on these feelings electronically and causing a chain reaction or domino effect.
The development of a safe working environment starts with building trust and the best way to build trust is transparency through telling the truth. Safe workplaces are foundational to building high performance.
Are you typing an emotive email because you have been the recipient of poorly delivered feedback yourself?
Are about to continue the same reactive or emotional way because of how it made you feel?
If someone has suffered a slip-up, don’t stress, use this approach to respond!
STOP! You have yourself an opportunity to change the future! Why pass the vibe on to the next person or retaliate by responding. Give some time for reflection. Take a few deep breaths and regroup.
LINK! Try to uncover the motivation or the connection between the sender and the emotional content. Read between the lines, let your existing relationship with them and your knowledge of them help to discover the issue or the why?! Think of the person not of the problem.
INTENTION! Assume positive intent, reflect on positive interactions you have had with the person and allow yourself to rise above this unusual event with grace. Consider your next steps carefully. Will you be part of the domino effect? Or will you have the courage to be different?
PERSPECTIVE! Keep it short, leave titles at the door, focus on well-being. Take some time to respond and select just one item to keep the interaction simple. Type your response but don’t send it. Get yourself a glass of water and come back, review it again before sending. This breather might provide just enough time for a fresh perspective.
Be the change you want to see!
You don’t even need a poor interaction or conflict to start making a difference to others around you. Start today, think about the value you can provide by improving your interactions and deepening relationships through being hyper-considerate.
Pick up that task that doesn’t belong to you
State you have capacity to help during stand-up
Pair work with someone you have not paired with before
Ask a teammate if they are ok if the look a bit off
Choose a retrospective action and take the lead
Contribute to someone else’s development where you can
Donate your time to a benefit others
Use appropriate salutations in electronic communication
Be pleasant and buck ugly trends
Start with something small, start with something easy, start with just 1 thing, but whatever you choose…just get started!
ScrumCraft announced today that it has joined the Scaled Agile Partner Network as a Bronze Partner. This worldwide network includes transformation and platform providers who help enterprises facilitate and accelerate business results through adoption of the Scaled Agile Framework ® (SAFe ® ).
As one of the world’s leading framework for enterprise agility, SAFe helps businesses address the significant challenges of developing and delivering high-quality software and systems in the shortest sustainable lead time.
Where Individuals & Interactions really do come before Processes & Tools!
“Working with best-in-class partners like ScrumCraft represents our commitment to helping software and systems-dependent enterprises improve time-to-market, quality, and employee engagement,” said Dean Leffingwell, creator of SAFe and cofounder of Scaled Agile, Inc. “By incorporating SAFe into their solution offering, ScrumCraft is enabling the world’s largest organizations to become more Agile in the marketplace and more competitive in their industry.”
About ScrumCraft
We love agile, I mean we really love agile! It has provided us so many fantastic opportunities and experiences that we cannot help but want to share its awesomeness with others and provide them an avenue to grow as well. That is why, at ScrumCraft, #welovewhatwedo! We are on a mission to demystify agile at scale and help organisations and individuals connect with their inner awesome to meet complex challenges head on.
About Scaled Agile, Inc.
Scaled Agile, Inc., is the provider of SAFe®, the world’s leading framework for enterprise agility. Through learning and certification, a global partner network, and a growing community of over 450,000 trained professionals, Scaled Agile helps enterprises build better systems, increase employee engagement, and improve business outcomes. Scaled Agile is a contributing member of the Pledge 1% corporate philanthropy and community service movement. For more information on Scaled Agile and SAFe, visit scaledagile.com.
I have been watching the news of late and thinking about the potential of Lean and Agile learnings that may exist in societies response to world events…to be honest I do this all the time, news, movies, TV series, books, songs, you name it, I am always seeing examples or hearing quotes and feel inspired.
Here in Australia we have been watching the news about the production of the COVID vaccine which is said to be as close as Feb21 with around 4 million doses. There are 2 thoughts here:
1. Testing & Production
I would love to lift the lid and look under the bonnet of the process for testing and production. I feel like there has been a big focus on speed to market, where else could we possibly need greater speed to market than here, right?! But it would be great to hear about what challenges and how improvements were put in place to minimise bureaucracy and eliminate delay in process. Imagine what could be achieved if we applied the same or similar approaches when an outcome was not as life threatening.
There are approx. 25.5 million people in Australia. It is said the first COVID vaccine batch of 4 million will be ready in Feb21. This will likely, and should, be prioritised to those in the highest and medium risk categories first such as those that are over 70, recently had organ transplants or have a disease that puts them at risk if they were to contract the virus. Is 4 million the right batch size? It seems small enough, but what if the first million was to be distributed as production continued, could this help prevent the spread faster? What is the optimum batch size when the cost of delay is so high?
Figures from the ABS show in 2019 that 16% of the Australian population were 65 and older so maybe 4 million is based on catering for the over 70’s first.
It is possible with the new strain in the UK starting to be identified in other countries, and the potential that the virus could evolve or mutate again, we could be looking at a cycle of jabs like to flu shot to keep up. The ability to be adaptive, flow focussed and increase the speed of distribution are all important.
This is a serious topic and, like many, my friends and family have been impacted by change due to COVID. I mean no offence in offering these thoughts. Situations like this get me thinking about improvement and I do believe it is an opportunity to learn about what has worked well in this case study so we can inspect and adapt.
Over time there have been many different ways I have seen agile projects or scrum teams measure value. The most important criterion is that it needs to be fit for purpose and usable, easily repeatable throughout the project life-cycle and teams cadences as well as relevant to the project resources, business stakeholders and end customer/user alike.
Challenges often present early in establishing value scales as team members challenge what is important to measure and how to measure different value criteria. The best approach, as is the case in almost all agile team formations, is to get the team agreement early to “just get started“. Start simple and then refine as you go. Create an initial prototype even if you cannot agree on the value ratings and learn what needs improvement by using the prototype, reviewing feedback and improve the process or model as you go. If you are starting to look at business value once a project has kicked off a good way to test out your prototype is to use historical data such as delivered user stories, put them through your prototype and then compare the results with the stories that may have been deprioritised during backlog refinement.
The benefits of starting with the simple model, even if it is as simple as suggesting a single numerical scale of 1 to 10 (or use Fibonacci as you would for story points 1,2,3,5,8,13,20), is that everyone can easily follow how to use it as it is familiar. The downside of this is that the team will often debate heavily around what the difference is between one persons 7 compared to another persons 7 etc. This is common, and an opportunity to have that exact conversation in the context of the item being discussed (lets say it is a story being rated for business value). This will give a real life example of how the prototype is being used and will generate insights on how the process might be incrementally improved. At the very least it starts to establish team thoughts on what a “7” actually is and relative value estimation starts to evolve.
So what do you do when peeps cant agree in a relative estimation model?
The answer in my experience is you need to move to a less subjective model. My advice is always to introduce change in consumable bite size pieces, iteratively. Don’t jump straight to a model that locks people down to a value scale that is dictated by directly quantifiable data values unless this was easily achieved at conception of the prototype. This can lead to teams feeling like they need to conduct high levels of detailed analysis up front around justifying business benefit at a story level and is not repeatable or sustainable.
One of my favorite models to use as a starting point in a baseline measuring system is the WSJF model as outlined in the Scaled Agile Framework (SAFe). WSJF is a mouthful of an acronym but stands for Weighted Shortest Job First, essentially this model compares the value (SAFe term being Cost of Delay) with the effort to complete the delivery of this value. The goal is to select the highest value reward with the lowest effort to complete. Another way of looking at this is lowest effort vs. highest return, therefore these product backlog increments (PBI’s) should go first.
Lets look at this concept firstly at it’s most basic, single backlog, single value stream level. In a fit for purpose approach the criteria can change to what ever the customer wants to measure as being valuable. In the original SAFe framework the criteria are User-Business Value, Time Criticality and Risk Reduction and/or Opportunity Enablement. The sum of these criteria then get divided by the effort or story points to come up with a figure that can be used at a glance to compare items across the backlog. For example:
In commercial business environments it is easy enough to put quantifiable value set behind the scale and therefore introduce less subjectivity. Opportunity Enablement in a Fibonacci scale of 1 to 20 for example can be linked to a dollar value (e.g. 1= <$50k and 20= >$5m).
In this example the user value was of medium benefit, it had low time criticality but high in opportunity generation.
What happens if your project is less attached to quantifiable measures and outputs?
You may find yourself working on more qualitative driven projects which are harder for the stakeholders to quantify benefit, however you still need to have conversations around business or customer value. You can still use a multi criteria approach based on the value drivers for that project but you may need to start with a less descriptive scale increments and adopt more of a low, medium, high value rating system.
The intent behind the criteria should be reflected in the scale language.
In a recent project the product owners short listed a bunch of value measures and then prioritised these down to a set of 4 criteria being Customer Experience (CX), User Experience (UX), Time Criticality (TC) and Risk Reduction (RR). To set the scale for each they used terms that meant something to them or their customers but still keeping the scale simple so that it was easy to use…whilst maintaining relevancy.
The team then simply used the scale of 1 being lowest and 20 being highest for each criteria.
So what happens next?
Backlog prioritisation sees the Product Ownership team, guided by the Product Owner & Business SME, evaluate each PBI (in this case User Story) relative to each other across each value category. This requires a starting point for relativity. SAFe suggests the team should identify the lowest value rated PBI in each category and give it a 1, thereafter every rating has a comparison point. Just as good is getting the team to elect the PBI they feel they know the most about and rate all categories for that Story. Then the story and all of the rated categories becomes the reference point for business value rating.
The figure above assumes that the team has also been involved in story point estimation. The business value is then created as a sum of the 4 categories. In this example the logical sequence of priority would be Story C, Story A and then Story B. Story C has the highest business value and lowest story points and therefore meets the highest reward vs lowest effort criteria. As we have strayed from true WSJF its interesting to note the WSJF on Story C would be 12 (36/3=12). Stories A & B have the same business value but Story A is only 5 story points so takes pole position. To reinforce this selection Story A = a WSJF of 6.4 and B = 2.5.
A good friend of mine and I were solving a particular problem for a customer and we were looking at ways to improve their business value rating system. For the purpose of this tale I am going to call him Andy, as that is his name. We were reviewing the value ratings of epics across the portfolio and observed that each product owner had very strong views that their epics scheduled next on the roadmap were all of high business vale. That could be because they were higher on each individual product owners backlog and as such of highest importance to that product owner, and fair enough right? But this introduced priority conflicts that were hard to defend with a single business value figure as they were only reviewing the business value sum for each others epics not the category breakdown. If the maximum business value number was 100%, everyone’s epics were 80% or higher.
Now for some fun… Its time to call the doctor!
To combat this we needed to come up with something that would expose value over effort, avoid concealing the rating of each category from only reviewing the sum and use something that would generate enthusiasm in its use. And the business value Blood Pressure chart was born.
By keeping each value category rating visible, the priority conversation can be had at a more granular level.
Based on the concept of blood pressure measurements being articulated as 120 over 80, if you’re lucky ;), we wanted to carry this concept through to plotting your results on a hospital chart. In this example the reading was 36 over 3.
With the Value & Effort exposed they can easily be plotted on the blood pressure chart. The blood pressure chart is based on a version of a prioritisation matrix.
Blood Pressure Chart
This type of chart or approach is not new but giving it a theme adds to engagement and collaboration. The line dividing the quadrant will need to move based on your scale and rating averages.
Its always good to review the process, the measures and outcomes in retrospectives to ensure they are as accurate as the initial vision and re-calibrate.
It is good for transparency to have the chart made visible in the team area and not hidden away in a digital location where its not accessible to the team and wider stakeholders.
Example chart using Stories A,B & C.
This method has been very successful when managing multiple value streams under a program or portfolio or a single project, and it’s fully scaleable when required. Finding ways to gain consensus across multiple Product Owners and project objectives can be tricky to say the least. Whether you have an org structure that has a Group Product Ownership structure or separate product owners needing to collaborate on priority, a common business value system is hugely beneficial in generating the right conversations and transparency in an effort to remove information masking by more subjective methods.
What do you use to measure business value?
What has worked well or not so well?
Please share or provide thoughts on this article in the comments.
Sketchnotes are an easy way to capture those “Ah-ha!” moments at conferences, seminars, meetups or even every day meetings at work. I find them so much more motivating and interesting to refer back to in the future and much more effective at sparking the memory of the event be it days, weeks or months later… whats more is they’re fun!
Granted you have to be able to recognise the sketches later on (I’m still working on this bit…) but the beauty of being your own author is that the images you create will mean something to you and the combination of sketches and notes will give it relevance and context for you.
This image is from the the first Be 1st Conference that was held in Adelaide in 2018 and these notes were taken from one of the key note speakers Nigel Dalton.
There are a number of elements that I tend to reflect back on the most regardless of having the notes open. One being the image of the tree and the words I want to quote from Nigel “Plant the tree our grandchildren will sit under” which speaks volumes to me and was definitely in the top of the list of impacting statements from the event.
Another Ah-ha! moment or memory from his key note speech was the image of interaction or conflict points based on team size. It was the first time I had seen this thinking articulated in pictures and I immediately related this image to the scrum guides development team size guideline of of 5-9 people. I have used this many times since. The thinking behind the image is that teams of 3 people will have 3 interaction, hand-off or potential conflict points, where as a team of 4 people will manage 6 etc. A great image to use when you are asked why limit the team size!
Regardless of whether or not you can draw give sketchnotes a go, it is a fun way to recall important moments and great practice for appealing to visual learners.
For my other sketchnotes from the 2018 Be 1st Conference please refer to the Photo Gallery page.
