Weeknotes #14 - The Rewards of Coaching

The rewards of coaching

Recently I’ve started working with one of our Project Managers who is working towards obtaining her Professional Scrum Master (PSM1) certification. We have a fortnightly catch up (which we had this week) where we run through different aspects of Scrum and how it relates to the reality she is experiencing with the teams she is working with.

What’s been great from my side has been the conversations we’ve been having have not been centered on ‘passing the exam’, they’ve been on checking her understanding of the framework and then how reality differs from that. 

As well as that, it’s really enjoyable to hear her identify where potential improvements/changes could be made to her current context and to ask questions about an idea around an approach, as that shows the learning is landing. It’s these types of discussions where I feel the most satisfaction from a coaching perspective , as you can see how the individual you are working with is understanding and growing their own curiosity, in particular through practical application of the newly acquired knowledge. 

If she’s reading this, a thank you to her for making the past few weeks really enjoyable from a work perspective.

Scrum

This week I talked to a fellow coach for one of our vendors about concerns I had in the way a particular team was practicing Scrum. There were a number of things observable just from a quick browse of the team area/board that stood out to me as being anti-patterns or just bad practices being inflicted on a team new to their Agile journey. It still amazes me over the years how people still persist with techniques that are quite outdated/never actually within the Scrum Guide. Now, I will fully admit that in my own Agile journey I was once the same in that I used to believe commitment to x number of backlog items, story points and velocity were of paramount importance, however after reading/learning more and experimenting, I’ve got my own list on what modern day Scrum looks like. That list includes (assuming you’re nailing your events and sticking to scrum values):

• Tasks are optional

• Anti-pattern — tasks in hours, or for that matter any individual measurement of hours per tasks

• Anti-pattern — Reporting on a per individual basis — names on a dashboard are a no-no

• Kanban boards are a must, and should reflect the end to end flow of value (i.e. they don’t stop at “UAT”, Done = Live)

• WIP limits are a must

• Sprint goals are short and ideally measureable; anti-patterns are long and ambiguous sprint goals

• Story points are optional for the team only, should not be used for any forecasting/predicting (Average velocity must die)

• Prediction on dates/scope should use monte carlo simulation or have an attributed percentage likelihood of outcome (which we know will change)

• Continuous everything — refinement, exploration, compliance, testing, integration & delivery

• Other sensible metrics to use would be:

• - Work item age, cycle/lead time, net flow, throughput, lead time for change, deployment frequency, change failure rate, time to restore service, team health check, no. of experiments

Source: 4 Key Flow Metrics and how to use them in Scrum’s events by Yuval Yeret

Those of you who will have studied and/or taken the Scrum with Kanban course will notice the vast majority of my thoughts are the same as what is echoed in that material. For our teams practicing Scrum, this is what I’d expect them to work towards…ideally without being ‘forced’ through the old training wheels of story points, velocity, hours breakdown etc.

Product Metrics

One thing I’ve always found difficult are product metrics for internal developed products.

Doc Norton has recently updated the final version of his ‘Escape Velocity’ book which I re-read this week. The book has an excellent chapter on what good product/outcome metrics you could potentially use that are much more meaningful than velocity.

Based on what I’ve read, as we transition more teams from project -> product, key metrics for our teams are going to be:

- Feature usage

- Adoption Rate

- Growth rate

- Relative Feature Adoption Rate

- Retention Rate

Next week

Next week we’re running a two-day DevOps People & Process workshop with Microsoft, which should be really interesting. As a team we were a bit taken aback by the overwhelming response for people who wanted to go, so I thought it better to give up my spot on the session for someone else. 

I’m also heading to an event on Thursday which is hosted by IDC and Slack on A Framework for Agile Collaboration — should be some interesting discussion around the organisational culture and change.

Weeknotes #13 - Leading & Lagging Indicators

Leading & Lagging Indicators

The discussion around metrics is a common one when working with teams, and this week was no different. In one sprint review this week, the team running the review presented a scatter plot showing an average cycle time of 10 days for their backlog items.

Now, I have no problems with this as a metric, however used in isolation it can be harmful, mainly as it is a lagging indicator of flow — it’s information that is only available after something has finished. To balance that, you need to use a leading indicator. A powerful metric so few teams use is Work Item Age — which shows the number of elapsed days since a backlog item started and today's date.

Stuck Work Chart — Each bar = a work item and how long it has been in that column

In this scenario now we can clearly see that whilst the average cycle time looks good, the flow of the current WIP is a cause for concern. We now have greater transparency around our flow of value to the customer, and what items we need to focus on/actions we can take to move these items forward.

Typically if this was a common pattern in a team I’d offer to suggest it once a week as an alternative way to run a standup. It shouldn’t be treated as an inquisition (note: hide the names on any dashboards to avoid this trap) but a team discussion on how we can get ‘flowing’ again.

Embedding Agile in the Portfolio

This week we had a quick sense check at the end of our team sprint review around our OKRs for this quarter around embedding Agile in the portfolio.

It’s good to see we’re on track with validating some of our hypothesis around WIP and having empirical evidence to support the changes.

One cause for concern however was looking at one delivery portfolio and the active WIP with the target dates for completion, and forecasting how many items were likely to go over our portfolio 90-day service level expectation (SLE). Taking the WIP age so far and target date minus today's date, it currently looks like 72% of the portfolio is due to go over this 90-day SLE. Obviously this is worrying for us and the Lean PfMO, but it does give us a chance to be proactive and find ways to slice work items down to be smaller. 

A conversation with just one person alone yesterday found that two items could be moved to done as the scope was being treated as every line of business in the company, whereas a slicing exercise was to deliver to respective business lines and learn from the feedback before commencing future work. We’re hopeful that there are more instances of these in order to improve the portfolio flow.

Impediments

Impediments, blockers, issues or whatever your preferred term of choice is are common when trying to adopt new ways of working in an organisation such as ours. One thing that’s really important in modelling the right behaviours is demonstrating Agile leadership in removing these challenges. However, in an IT estate of >600 applications, and trying to spend time determining what’s fit for purpose in shifting from Project to Product, it’s impossible for myself and our team to get involved in removing every single challenge a team faces. 

A discussion this week lead to six or seven issues being reeled off to me one by one, as well as multiple cc’s on emails/chat messages. After probing one or two I found a common theme around the team having not really done anything in terms of trying to tackle the issue and/or understanding the needs of others who may be slowing them down.

Good Scrum Masters / Delivery Managers should help teams to understand that if they find an issue, they have to own the resolution first, and try everything they can to remove it. If they’ve exhausted all options then they need to be able to present what the issue is, the approaches they’ve taken and the impact (ideally quantified) it is having. To engage senior leaders in the role then #DataOrItDidn’tHappen makes the point 10x stronger than anecdotal, one-sided arguments.

RIP Martin Burns

I was sad to read on Monday on my Twitter feed about the passing of Martin Burns. I didn’t know him personally, but always enjoyed the interactions I observed on my Twitter timeline, in particular his staunch, passionate yet well articulated points in defense of SAFe. I had the pleasure of finally hearing him speak in person by attending his talk on 10 Years of Big Room Planning at the Agile Business Conference last year. The number of tributes from the community over social media and at conferences all over the world this week is testimony to the impact he had as a person. There is a GoFundMe open for donations. Thank you Martin for providing inspiration to those who you didn’t even know, you will be sadly missed.

Next Week

Next week I have the quietest week in a while, so lots of free time to work with teams. I’ll be adding to our ways of working (WoW) backlog with some ideas on the next things we want to tackle as well as working on slicing some of that 72% down to hopefully reduce our WIP and cycle time.

Weeknotes #12 - Personal Development & Technical Excellence

Personal Development

Unfortunately I was unable to attend the Pluralsight event I mentioned last week, so I made use of the free slots in the calendar to take a couple other exams/certifications on my list — Scrum.org’s Professional Agile Leadership (PAL) and Professional Scrum Developer (PSD).

The PAL certification in particular was quite interesting. It’s relatively new and according to Scrum.org:

The Professional Agile Leadership (PAL I) assessment is available to anyone who wishes to validate that you are a leader who understands that being Agile adds value to your business, and why leadership understanding, sponsorship, and support of Agile practices are essential to an organization becoming more agile.

I’ve touched on certifications before in previous weeknotes, and how for myself I view them as a validation of knowledge as well as a chance to see how the reality we experience relates to the theory one is taught/reads about. 

I was pleased to pass both however I would definitely say the PAL was at the harder end of the scale for exams I’ve taken, mainly as the ‘choose the best answer’ format makes it a bit tougher. There were some really challenging questions which even process of elimination didn’t immediately point to a single answer. For leaders I’d highly encourage this before you consider looking at something like a Leading SAFe certification (if you’re starting to adopt Agile ways of working), as this very much is focused on how you, as a leader, can really add value in an Agile organisation with application to real scenarios you are likely to face.

Agile by default

This week I did a bit of analysis of completed work this year in our IT portfolio and the split between traditional (waterfall) and agile methods:

With only 21% having been delivered using Agile methods it’s clear we have work to do. An experiment we want to try now is to have projects coming through as ‘agile by default’, whereby it should be delivered in an Agile way unless a good case can be made otherwise for it not to be. This could be for example if your requirements are known and will not change, COTS solutions where no changes/customisations are needed, or if there is no desire from the customer to get something of value early.

What defines if something is ‘Agile’? 

For where we are currently (not the end state) we would look for daily standups, retrospectives with continuous improvement items, a backlog, a physical/digital kanban board, a definition of done (DoD) and to be working towards technical excellence (CI/CD, automated testing, etc.). 

Agile ≠ Scrum so we want to be pragmatic with people on the journey, helping them apply as much of the above as they can where relevant.

Hopefully we can start to see those lines get closer together with this experiment…

Technical Excellence

As we know from Accelerate, technical practices directly predict or impact organizational performance and culture. This week Jon gave the rest of the team a demo on his deployment pipeline he’d built in Azure DevOps. There were a few issues he faced which weren’t ideal (all outside his own control), but this is the nature of a big organisation, sometimes changes are made at a group policy level that are going to impact the work we do.

We’re still a low performing organisation particularly for deployment frequency and lead time for change however we are getting there.

A team both Jon and James are working with are now doing daytime production deployments post sprint review, and with us hooking this in to ServiceNow, we’re gradually stripping away the reasons for not being able to be Agile. I am thankful to both of them for reimagining the possible.

As General Stan McChrystal says, take away the excuses:

[embed]https://vimeo.com/203601845[/embed]

Next week

Next week I’m hoping to finalise the first two or three of our core dedicated ‘product’ teams, as we start the shift towards product over project. It will need to be a blend of permanent and supplier individuals, so a good test for how we want our future model to work. I’ll also be starting some one-to-one sessions with someone who is working towards a Scrum Master certification. I haven’t worked with this person much in the past so looking forward to starting that journey, both helping her learn and developing more of my own coaching skills.

Weeknotes #11 - The Power of Questions

The Power of Questions

This week was a shorter week again, back in the office on Wednesday after a long weekend out in Las Vegas. On Wednesday I was introduced to a new member from one of our supplier teams, who is going to help lead on the adoption of Agile ways of working on our account. I really enjoyed our initial discussion, as this particular individual asked a number of open, honest and challenging questions with regards to where we are on our journey, what organisational constraints we faced and how we’d prioritised particular areas so far. It was a great example for me of the impact someone in a coaching or consultancy position can have simply by asking the right questions, as opposed to just blindly accepting what the client asks for. My view on our organisation trying to adopt a framework agnostic way of working where all frameworks have elements that are relevant seemed to resonate well so looking forward to some more fruitful discussion in the coming weeks.

The Coaching Habit

In relation to this, after finishing Escaping The Build Trap I’ve recently picked up a new book called The Coaching Habit.

I made a note of it close to maybe 18 months ago when Don Eitel (I think…sorry if it was someone else!) mentioned it to me in the Modern Agile Slack group. I’m already regretting not starting it sooner, in particular as it’s a book not just relevant to ‘agilists’ but I would say anyone who is in a management role in an organisation.

Training

This week we ran a training session for a group of people within our Assurance Transformation team. It was the first session I myself had run after a six-week period of no training, which is the longest gap I’ve had in the last six months. Along with the time off, I definitely noticed an impact to my delivery, as I didn’t quite feel like I got into the ‘flow’ of how things usually go. Nevertheless the feedback was positive however there is an important learning for myself around keeping fresh and maybe not having quite as long a gap between training sessions next time.

And the anti-pattern award goes to…

In the training, one of the attendees explained around how he and his team(s) use hardening sprints within their delivery. For those of you that aren’t aware, a hardening sprint is essentially a sprint where a team will focus on bug fixing, technical debt, integration testing, performance testing, security testing, etc. —in most cases it being everything that needs to be done before software can actually be released. I was first introduced to it once I joined PwC when someone was explaining how previous successful(!) Agile projects had been run. For me it is my favourite anti-pattern in the sense of it being a clear indication of not remaining true to the principles set out in the manifesto (sustainable pace anyone?).

If you are using hardening sprints, then it’s clear that your definition of done is most likely not very robust, that the work you are completing is not potentially shippable and unfortunately that you have compromised on quality. The irony in articles titled ‘Optimize Your Hardening Sprint for a Quality Advantage’is one that does make me chuckle.

Next Week

Next week I start the week working with a team looking at that million-pound question — “None of our stuff is moving on the board, can you help us fix it?”. I’m hoping to get to the second day of the Pluralsight:Live event on Tuesday in particular with a session on DevSecOps. Then the rest of the week will be focused on some one-to-one coaching conversations.

Weeknotes #10 - Back To It

Back to it

After a fun week away looking for wedding venues, it was back to the office this week. Thankfully I’d resisted the temptation to take my personal iPad away with me which I use as part of our BYOD scheme, so I was greeted with all 120 emails to read once I got back. With only seven actually needing my response I think I need to work on my filters! Interestingly whilst away I had received emails from colleagues in the US, Brazil and Malaysia, it’s great that we’re finally bringing together the agile islands (to coin the phrase fromJonathan Smart) to all work towards better business outcomes, both internally and with our clients.

The good and bad of tooling

On Monday I was up in our Manchester office running another Hands on with Azure DevOps training session. After having to postpone/re-arrange four times due to other conflicts, it was good to give people the same opportunity that those in London had. The continued postponement obviously had an impact on attendee numbers, with only five out of the original ten who signed up being able to attend on the day. Monday’s session was a good one for me from a learning standpoint, as now I’ve learnt that smaller numbers work better for me with this type of training, as we were able to finish ahead of time (planned for four hours, finished just after three hours). I think this is because it allows me to have one-on-one time with everyone in the group, as well as having the group small enough to ensure that no one is left behind or that we aren’t flying too far ahead. I also think I’ve now got a better handle on my delivery pace, as in the first few sessions it was fed back that I was moving a little too quickly for people. All attendees did ask to keep the printed workbooks I brought with me and for their ‘dummy’ projects to be kept open for a few weeks to play around with, which I take as the session going well!

I’m not always keen on training session dedicated to tools, mainly as I feel most of what we do is mindset based, but also I hate to feel like we’re prescribing a way to use a tool to people. Thankfully no one has fed that back but I do hope people leave with an appreciation they can tailor their usage of something dependent on their context, rather than following “the book”. 

I’ve struggled with motivation for these in the past as well, mainly due to the time dedication needed however I did really enjoy the one this week, so hoping to hold a couple more of these if there is enough interest.

One potential negative impact of running sessions like these is that once people become exposed to a tool and see others using it, they fall into the trap of using the tool for everything, and almost as a replacement for actual interaction with people. This was highlighted to me in particular this week with one of our teams who had raised four new impediments within Azure DevOps. As part of our new ways of working we’re obviously going to uncover challenges/constraints we face in our organisation and I have no problem with raising impediments in a tool, however I also think as practitioners we should be consistent in our exploratory nature towards problem solving, much like we are with new feature requests. In this instance, simply creating an impediment titled “Security delays” with no elaboration or conversation as a group is not particularly helpful. It has the ‘smell’ of “let’s raise everything in the tool so we can say it’s been raised” rather than proactively working together to find a way forward. Let’s try to apply the same principle of the 3 C’s in order to break down what the issue is, rather than relying on the tool to drive our interactions.

Trending in the right direction

The weekly portfolio review meeting brought about a nice surprise this week. Throughput was trending up (delivering more), average cycle time was trending down (delivering sooner) and net flow was trending up (finishing existing work before starting new work). It’s good to see that we are staying true to the WIP limits we have set, however with a queue forming at the front we face a big test ahead in coming weeks.

Slowly flowing

The easiest thing to do of course will be to start something new, due to external pressures or a need to please, however if we are serious about new ways of working then it will be an important part in putting into practice the mindset we want to have. We also had a couple reported instances of work being ‘pushed’ by senio people this week, and/or side conversations to get people to start new projects. Whilst frustrating these are all learnings and examples to feed into future discussions at leadership level to ensure we aren’t reverting back to old behaviours.

Next week

I’m out on annual leave again from Thursday this week (do I even do any work?) so will be back in the office on Wednesday. We’ve got a session for one of our teams in Assurance on Thursday around Agile Foundations, which will be fun and start to bring that ‘single team’ mindset together. I’m also starting to do some one-on-one coaching with a couple people around taking them to the next level as Scrum Masters and/or working towards their PSM1 certification.

Weeknotes #09 - Portfolio WIP Crack

Portfolio WIP Crack

This week we introduced WIP limits to all our different portfolio columns, as well as reducing our in progress column by five (down to 45 from 50!):

The board is looking better, with three items moving to done this week — anything with a black line has moved forward as well…so getting there.

Whilst I recognise the WIP is still incredibly high, it’s progress in taking those first steps to optimising WIP for portfolio flow. We’ve set OKRs this quarter around reducing WIP and cycle time across all delivery channels by 10%, so this will help us on that incremental change path.

Budgeting Constraints

This week highlighted one of our biggest organisational constraints around budgeting, with it currently being driven via individual business lines. 

A challenge we’re therefore facing is how to charge for work if you group teams around delivering a particular service (say Compliance) that covers multiple areas of the business (Tax, Advisory, etc.). In particular with our current context where IT has yet to prove a solid delivery capability it’s very hard to tackle that constraint head on (i.e. change the funding model) without the evidence as to why we should change, so this looks like being some cultural debt we will have to take on and potentially address longer term. It could be that we can group our services sensibly so that it doesn’t become an issue, but it certainly has me worried around scalability potential.

Certifications

This week I passed my Leading SAFe exam after getting my login details at the beginning of the week. You get unlimited attempts at a practice exam (same questions each time but shuffled order) before you proceed into the real exam, which is 45 questions over 90 minutes. I must admit, I found the exam pretty easy when compared to others I have taken (PSM, PSK and PSPO), which in turn will make me treat it with a pinch of salt when I see it on any future CV’s! I didn’t like the fact that even on the practice exam you didn’t get told which questions you answered incorrectly (just the topic area), as well as the fact that the PDF slides from the training are actually page scans rather than text, therefore you can’t CTRL+F a particular section if you’re stuck.

The best kind of certification 🤣

Certifications in general are obviously a touchy topic in the Agile world, with most practitioners recognising that in a market so saturated they aren’t really that valuable when assessing potential candidates.

For me I use them purely as a validation of my own knowledge and as a potential “in” for those who may doubt your credentials (rather than experience!) and look for badges as proof. 

Obviously this isn’t ideal but like everything related to Agile, you have to meet people where they are and for some, that’s how they validate credibility.

One aspect I find interesting about certifications is when people include them on CVs, yet when you try cross-reference it with the certification body the same individual cannot be found. Now, most likely they’ve let it expire either knowingly or unknowingly but what if they’ve just made it up? There is no real way to validate it. I had this exact scenario with a candidate this week who had obtained their CSPO in 2011, but when I searched in the Scrum Alliance database they couldn’t be found.

Should this be something brought up in the interview? I’ve seen it a few times now with candidates we’ve had but never been quite sure as to how to bring it up in conversation. I think the next time I come across this scenario it I’ll give it a go to see how it lands with the candidate.

Next Week

I’ll be away from the office from this Friday all the way to the next, so likely to take a week out of writing these. Looking forward to a bank holiday weekend with lots of fun planned, before heading up to Scotland during the week to look at wedding locations and see family.