Weeknotes #08 - Leading SAFe & Using Twine

Leading SAFe

This week, I spent three days on a Leading SAFe course with a number of PwC colleagues. SAFe is the hot scaling Agile framework in the industry right now, used by 70% of the Fortune 100 and like all good practitioners I think it's important to at least make an informed judgement on something based on trying to learn it from those who do it, as opposed to judging from your Twitter feed alone (where I must admit I see a lot of negativity towards it!).

Thankfully, our training was stretched out over three days, compared to the two day format it is usually delivered in. I’m guessing that a two-day version must be slides only, as that’s the only way I could see it being condensed and still covering everything whilst finishing within the timebox. 

I found it difficult at times to engage in the training, mainly as there were a lot of things over the three days that weren’t that new to myself, in particular things like small batch sizes, limiting WIP at every level, slicing work, WSJF, systems thinking, kanban boards at every level, ruthless prioritization etc. 

However I definitely feel like my understanding around it has improved, albeit I still prefer the Henrik Kniberg image of SAFe in a nutshell:

Over the daunting image that greets most:

Whilst I’m not going to get into the specifics of everything I liked/disliked, I don’t think it’s as big an *evil* thing by some practitioners that it is made out to be. I can see why it appeals to a lot of large organisations, mainly those that have over time become dependent on having component teams, as well as having monolithic architectures, reams of technical debt hiding under the hood and/or still wanting to retain some sense of hierarchy and structure. 

Is it a bad thing these organisations are (finally) being introduced to the great work of Deming, Drucker and Reinertsen as well as important topics such as Lean, Value Streams, Kanban, Scrum and Lean Startup? No. 

Are there elements that I wish they would change as they seem to focus more on the right hand side of the manifesto than the left? Yes. 

Do I like the approach to training and it’s renewal costs? Absolutely not. 

Will I be rushing to use it? No, but that’s mainly as I feel in my current context it would be violating the first rule of scaling (don’t scale). However there are definitely elements of it I will think about and look to tweak/use depending on where appropriate (hypothesis writing of epics/features was one in particular I really liked).

Overall I was glad I took the course, mainly as I now feel much more informed as a practitioner. The instructor Patrick handled my tougher questions really well, and it was a pleasure meeting him as well as chatting to various colleagues who I either met for the first time or knew previously over the three days. We have four subsequent coaching days lined up where I believe we will run a full PI Planning event, which was probably the bit I liked the most! Looking forward to bringing that to reality in the coming weeks.

Making Work Visible

After a heated debate on what is twine vs string, and which is the correct word to use (twine I was told is a northern thing, but search for string on Rymans and the first result is twine so who knows 🙃). We managed to get a portfolio kanban board setup in the office on Thursday.

Thanks to

Sam

for the string/twine suggestion and

Agile Stationary

for the printed backlog!

When making the work visible it’s very clear what the issue is, once again bringing to life a slide I saw Bazil Arden use years ago when he was demonstrating one of the major challenges many organisations are facing:

The hope is that by making the work visible, we can start to have an open conversation about if certain work really is a priority, as well as optimizing the system for flow rather than utilization.

Next week

Next week is obviously a shorter one with the bank holiday on Friday, so I’ll look to put my week notes out a day earlier. 

I’m hoping to take the Leading SAFe exam at some point, as it will be a good way to validate my learning.

Due to commitments outside work I won’t be able to make the first Agile Games Workshop meetup hosted by PwC on Wednesday, feel free to check it out here if you want to know more.

Weeknotes #07 - Port’flow’io, & Escaping The Build Trap

Port’flow’io backlog

Last week I mentioned about how seeing a lack of throughput lead to a rather heated discussion in our weekly portfolio meeting. I was pleased to see this week that our throughput is getting a lot better, with eight more items flowing through to done in the past week. 

A new item of discussion was raised in the weekly meeting around breaking work down. I highlighted that we needed to be careful that we don’t want to fall into the trap of horizontal slicing at portfolio level, where you end up have a card for analysis, a card for build, a card for testing and a card for deployment, mainly as that masks the actual flow of value to users. 

Whilst this isn’t ‘easy’ I do think a lot of it just requires a bit of unlearning around jumping straight to solutions, and again starting with why. 

In our context I feel that we could/should be utilising more of a design sprint concept from Mark and his innovation team to aid the flow upstream and/or reducing batch sizes of work flowing through our portfolio. 

Our portfolio kanban board has a flow of:

Ideas | Refinement | Ready | In Progress | Validate | Done

I provided some guidance as to questions to ask upstream:

Interested to know if you think anything else is worth adding.

OK, OK, OKRs

This week we got together as a team to review our OKRs, grading ourselves against how we had performed. We’ve been using OKRs for the past 9 months, and finally it feels like we’re getting the hang of them. 

The first ones we put together didn’t come close to the target 0.6–0.7 grade range, which alluded to them being too ambitious. The second ones we put together ended up being too “easy”, as four out of the five achieved a score of 1.0 — so looks like we set the bar too low!

Finally, with our latest grading, it looks like we’ve achieved the right amount of balance of ambition/reality in our objectives:

As a team, we’re going to carry on using them as we think they are really useful as an alignment tool. We’ve agreed to regularly check them at the end of each 4-week sprint just to make sure we aren’t losing site of things. Our leadership team have expressed an interest in applying the same concepts which could hopefully bring some portfolio and team alignment to the work it is we are undertaking. A side project may be some AzDO (yes I am going with that abbreviation) customisation to trace PBIs -> OKRs — similar to what Microsoft talk about here.

Escaping The Build Trap

At the beginning of the week our TV at home was broken, which gave me a much needed push to pick up a new book to read. 

I’ve started reading Escaping the Build Trap by Melissa Perri, which is already edging into the ‘must reads for practitioners’ category of my Agile library. 

Such is the quality of the content/learning that I’ve found myself taking screenshots (reading on iPad, ebooks FTW) of most pages, as highlighting a whole section seems to defeat the purpose of what highlighting is for! Hopefully I’ll finish it over the next week and can give it a full review, in particular if it’s pushed its way into my all time favourites.

Next week

Next week I’ll be taking the Scaled Agile Framework – Leading SAFe course with a number of other PwC colleagues. I’m looking forward to the learning outcomes, in particular being able to make a more balanced assessment of SAFe. 

I hear both good and bad (more the latter) things about it, so it should be interesting. I view all methods/frameworks as tools in the toolbox, which should be used when relevant to context, so will be good to add this to the list and I’m sure it will be a fun few days of learning. 

A number of our leadership team/senior managers will also be attending a G2G3 DevOps simulation. I hear nothing but great things so hopefully it sparks a lot of discussion and challenge!

Weeknotes #06 - Measure What Matters

Measure what matters

This week I’ve had a number of coaching conversations around metrics and measurement. On Tuesday we had our weekly portfolio review meeting which always proves to be one I find challenging. With an inordinate amount of WIP in our IT portfolio it’s proving very difficult to help people ‘get it’ and focus on finishing over starting, as well as slicing demand down to small batch sizes of work, regardless of methodology used. This boiled over as I found myself disagreeing/arguing with an attendee of the meeting who viewed slicing work down as admin, that customers have no problems with our delivery and that the data was “wrong”.

I wasn’t particularly proud of the fact I’d resorted to calling someone out publicly, but it did make me question what matters to people measurement wise, and challenge my own thinking. As you can probably tell I’m obsessed with small batch sizes of work and swarming on aged WIP, using empiricism to support the actions you take, mainly because for me you are viewing this with a customer lens. However it’s clear based on what happened this week that these metrics aren’t quite what matter to others. A positive was the conversation I had the following day which centered on setting limits within the overall WIP (say for a particular type of work), which showed that some were embracing the idea. 

Checking today I can see that Throughput for this week has gotten to the joint highest it has been in the past six months, so looks like the message on Tuesday did land.

Slowly, slowly catchy monkey

Shameless plug

This week, the video of myself and my role within PwC was published to our careers website. Whilst I always find being filmed a bit awkward I did enjoy having the opportunity to share my experience, in particular as I feel people can have a certain view on the ‘big four’ life. It’s definitely not what I had imagined it would be like and I can safely say the last year (I’ve been here three and a half years) has been the most enjoyable I’ve had in any organisation so far. Watch the video below if you want to see someone over emphasise hand movements!

[embed]https://www.youtube.com/watch?v=5-wg9CyLZr8[/embed]

Sprint Reviews

This week I attended a couple of sprint reviews, both of which were not particularly great to actually dial into. One was flat with little/nothing demonstrated (showing your Azure DevOps kanban board does not count), and no energy in the room. The other had an enthusiastic group ready to have good discussion but a main stakeholder who accepted didn’t turn up, which lead to the team just moving on to the retrospective.

Once you start taking Agile outside of software then the sprint reviews are hard, but not impossible. I’ve found that to make them engaging you should have meaningful discussion points and/or at least something to show. 

If you are falling into the trap I mentioned at the beginning, be sure to take a read of Your Sprint Reviews suck, and that’s why!

Next week

Next week is a quieter week, with no training planned. We’re getting an increasing amount of project teams who, whilst not delivering in an Agile manner are at least wanting to adopt a kanban board for visualization/management of work. This for me is a good start for people on their Agile journey, and I’ve got 4/5 teams lined up next week to speak to and get them started on that journey…

Weeknotes #05 - What did one brick say to the other? Never Lego...

DXB

This week I’ve been out in Dubai in the PwC Middle East office, running three 1-day Agile Foundations sessions for people in IT, Digital and Finance. 

For these sessions I made some tweaks to the usual format our team uses, mainly in replacing Featureban with our version of Lego4Scrum. Reason being that I wanted to have an environment where attendees of the training get the chance to bring all their learnings (agile principles, scrum roles, kanban, MVP) together. Plus I find the lego exercise in a lot easier to facilitate than Featureban, as there is more freedom for creativity, whereas with Featureban some teams do need a lot more help in order for the exercise to be effective.

“what did one brick say to the other? Never Lego”

The training was requested by members of a new leadership team being formed out in Dubai, who have decided to really focus on their own people as a starting point, with Agile one of the first things to introduce to the group. I really appreciated that a number of the leadership team made the effort to attend, as quite often leaders want to “go agile” but then won’t attend sessions like this, immediately leading to attendees questioning the validity/seriousness of the message. 

Thankfully this didn’t happen here, which made the training had even more impact, I’m very thankful to Sophie Thomas and the rest of the team for “being the change they want to see” and inviting me out there this week.

Feedback over the 3 sessions was extremely positive, which is always nice. 

My favourite being this:

😊 😊 😊

After the second day I was getting quite tired, but reading this at the end of the day definitely did spur me on to make the third session just as enjoyable and energetic. It reminded me of when I was out in Brazil before Christmas and ran seven ½ day sessions over five days, in particular how I really struggled motivation wise both towards the final sessions and in subsequent weeks when back in the UK. 

Recently I’ve reflected on the fact that when you’re running training, remember that people are giving up their time to listen and learn from you. So, whilst it may feel onerous, repetitive, and potentially boring, remember that by attending people are saying they believe in you and what you’re saying, as well as showing a big appreciation for what it is you do. 

As a trainer you shouldn’t view that as a chore but a privilege that many people don’t have, so make sure that is reflected in your delivery and mindset.

We’ve already been talking about adoption and next steps for the Middle East, with the potential for another set of sessions in the coming months. 

One of the attendees in particular seemed really impressed with the concepts/demos I showcased around portfolio kanban, which I feel would be a good first step for the team out there, especially as thief too much WIP and thief conflicting priorities seem to be prevalent in discussion during the training.

If you know you know…but if you don’t then read

Making Work Visible

LLKD19

Unfortunately being out in Dubai meant missing out on my favourite conferences — London Lean Kanban Days. Despite not being able to attend I was following the hashtag on Twitter through breaks in the training with a bit of FOMO. Sessions that caught my attention included:

Pawel Brodzinski — Power as privilege

Mainly due to his LLKD17 session on Emotional Safety, which I found to be so honest and genuine, I always find Pawels talks engaging, emotive and a must see.

Olga Heismann — Forecasting in complex systems

I actually had the pleasure of seeing this at LKCE18, with Olga’s talk in the same room before my own session. I was blown away by the incredible detail and knowledge within the talk, looking forward to watching again.

Dan Vacanti — Don’t be a ditka

This session has caused a bit of stir over the Agile twitter-sphere, mainly due to this slide:

Source — 

Twitter

As someone who takes a lot of inspiration from Dan, I always find his books and talks interesting, engaging and full of learning. So looking forward to when this one is available. I also need to have an in depth read of his supporting piece here (one for the flight back).

Looking forward to those as my “top 3” when available, and congratulations to Jose Casal and the rest of the BCS team for what looks like another successful conference.

Next week

Next week I’m back in the UK (as this goes out I will hopefully be in the air on the way back to London) and looking forward to a number of coaching conversations. For our team next week is a big one, as James takes the lead on running a kaizen event for our cloud provisioning process.

With our UK CIO Stuart Fulton attending it’s again a strong statement to the rest of the organisation around how serious we are about enabling business agility. Looking forward to the outcomes of what should be another good week for learning in our Agile journey.

Weeknotes #04 - Pull-based Coaching & Baby Steps

Pull-based coaching

As mentioned in previous weeks, our approach to Agile adoption has been very much centred on a pull based approach. Whilst we do what we can in marketing and training, we aren’t going to “force” people to go Agile, nor are we of the mindset you have to ‘agile everything’.

The other day I had an interesting observation whilst in my social time. Normally I play badminton a couple days a week with local meetup groups and, after one particular game, I noticed something that for me is a great analogy for Agile coaching. The doubles pair we just played against clearly had one stronger player of the pair. Once the game was over and hands were shaken, the stronger player of the pair prompted to coach/tell their partner what they should do to improve. What was interesting for me was that the person receiving the feedback had not requested the coaching/advice, nor did they appear to really want the help. For me this was a great reflection on the reality of an Agile coach working with teams and/or individuals. 

If you are acting as a Coach but simply imposing Agile onto people without being asked, this is the exact effect you are likely to have on someone. 

They may not desire or require your assistance, and subsequently it makes for an even more uncomfortable situation by them then feeling like they have to listen to you. Hence, try your very best to adopt pull-based coaching.

Portfolio Baby Steps

Our main focus in adopting Agile ways of working has been concentrating our efforts at portfolio, rather than team level. The main inspiration from this of course being the flight level captain himself Klaus Leopold. Using Klaus’ flight level model you could argue we’re focusing somewhere between flight level two or three (IT Portfolio level), but the main point is that we’re focusing on tackling Agile principles at a higher level first, in conjunction with a few (but not all) teams.

One thing we’ve done as part of this is map our portfolio of work on a kanban board, with all the steps a piece of work goes through, as well as some rough, ROI score (fibonacci-esque business value ÷ effort) for prioritisation and what methodology is being used to deliver the piece of work. 

Since introducing WIP limits, we’ve managed to reduce portfolio WIP by 28% in the last 6 months, however we’re still struggling on refinement and slicing work down to smaller batch sizes. In particular average portfolio cycle time still remains very high due to older items only just moving to done, but at least it’s trending in the right direction.

This obviously makes something like WIP limits a hard sell to those sceptical as the time to deliver isn’t noticeably reducing as much as we’d like, so something to monitor in the coming weeks and learn from.

A positive for me this week though has been seeing the portfolio team apply their learning from Featureban in our Agile training when it comes to pipeline replenishment. Prioritising only a few items for what work comes next, and staying strict to the WIP limits. Hearing “we only have room for 2 so what’s the highest value” on a call was something we haven’t heard before, so that’s a positive. Slowly getting there with baby steps…

Manny on the Map

Yesterday myself and Marie ran another of our Agile Foundations sessions, this time in our Manchester office. Despite the session being centred on IT we did have some participants from our client teams as well, which I take as a positive to the positive feedback the course has received.

One common point of discussion is around budgeting in an Agile context and, whilst we discuss how generally the concept of annual budgeting needs to change, we include an example of how to set a price for Agile projects. 

I also have an internal article about using Troy Magennis’ free tools and in particular the throughput forecaster. Whilst this is outside the scope of a #weeknotes, let me know if you’d like to see in a separate post this as a worked example.

Overall it was another really fun session, with some great characters in the room, in particular showcased via the the feedback we received.

Class comedian — we know who you are :)

It brings us to the 80% mark of people we’ve trained, with two sessions left for IT. After that is when the hard work really starts but, I must say, it is the bit I’m most looking forward to.

Next week

Next week I’m heading out to our Middle East office, running a series of Agile Foundations courses out there and returning back to the UK on Friday. 

I’ll be missing out on my favourite conference — London Lean Kanban Days but I am intrigued to see how the training lands with folks out there, in particularly given some of the concepts on celebrating failure, psychological safety and embracing uncertainty…a great chance to develop my coaching experience!

Weeknotes #03 - Learning, Feedback & Flow

Partner Up

Last week I talked about a new initiative we’re trialling called Partner Up. Partner Up is opportunity for PwC staff below Manager grade to showcase technologies and interact with Senior Staff. Held in one to one (or one to many) sessions, volunteers are encouraged to discuss modern technologies with those who have the ability to create future opportunities for PwC.

For my Partner Up session, I had the pleasure of pairing up with Diana, who works in our IT Consultancy team. Diana had decided to showcase the capabilities of Google Sites, in particular things that could be done using Google Apps Script. 

After 45 minutes of learning a hell of a lot, including calendar integration with forms, qualtrics surveys and data visualization embedding within sites, Diana was closing the session in showing me the capability of integrating other tools we use. The highlight being the capability to embed a kanban board within a Google Site, which to me was fantastic!

Agile nerd alert 😍 😍 😍

I started to imagine a world of submitting a request via a Google Form, which then copies into a live Kanban board, where you can see the lead time for your request, where it sits in the queue etc etc…evoking memories of the Phoenix Project and visualising lead times for replacement laptops…always a dream of mine to implement something similar!

Special thank you to Diana, she really went above and beyond what I expected and it was great to have an hour dedicated to someone helping me learn.

Feedback, feedback and feedback

With our performance year coming to an end this month, the inevitable overflow of feedback requests have been hitting my inbox this week. 

One of my struggles with this time of year is determining what warrants feedback and potentially turning down requests where not appropriate. 

As a firm we have our professional framework which, whilst important, feels unfair/unfit for purpose when, for example being asked to score someone against “global acumen” if the work they did was help me out on something small locally. Similarly, I often find people request feedback as a means to showcase they’ve completed work, rather than using it for a constructive conversation centred on development. If that’s the reason for a feedback request then surely we’ve lost the spirit of it?

So yes, I really struggle with this time of year, also as I find it increasingly challenging with what we do to quantify the impact myself and our team is having on the organisation. 

How do you quantify internal coaching impact? Number of people trained? Training NPS? Number of Agile projects vs. Waterfall? Number of teams coached? New products launched using Agile principles? Portfolio WIP trend? Portfolio/team cycle time? Individual feedback?

I’m still learning about what we can look at empirically in supporting what we do, but for now have settled on a blend of all the above in terms of my own performance appraisal. 

Before you ask, yes, we are still doing annual performance reviews. 

Mid-year reviews take place as a checkpoint and more of an informal discussion, but end of year is when you get your performance rating which may/may not be attributed to a pay increase and/or bonus. 

The majority of people I talk to express surprise/dismay we still do it this way.

I’ll put that down as one for the cultural debt backlog to be addressed long term…

Training

Today I’ve been running another Hands On With Azure DevOps session, this time for folk in our Consulting team. The session has gone well, with pretty much all attendees feeding back that they had learnt a thing or two, which is the main thing for me. One particular feedback was that it was “the best training someone has been to in the past year” — I didn’t stop to ask if this was the only training they had been on ;)

The course is structured like so:

I learnt that I didn’t have the right setup for enterprise licenses today, which meant a number of people couldn’t move work items on the board — not ideal! However I found a workaround through pairing and learnt about what I need to fix for next time…so a good day for me on the learning front as well.

For those of you who are users, I’d love to hear if you have any feedback on the above and if you think there are significant gaps for first time users.

Next week

Next week I’ll be finishing my performance appraisal, putting my Google Sites learning into practice, and heading up t’north to our Manchester office for an Agile Foundations session. Looking forward to a week of reflection, learning and starting others on their Agile journey.