Weeknotes #32

Little Bets

A few weeks ago, I was chatting to a colleague in our Robotic Process Automation (RPA) team who was telling me about how the team had moved to working in two-week sprints. They mentioned how they were finding it hard to keep momentum and energy up, in particular towards the end of the sprint when it came to getting input to the retro. I asked what day of the week they were starting the sprint to which they replied “Monday”, of course meaning the sprint finished on a Friday. A suggestion I had was actually to move the start of the sprint (keeping the two-week cadence) to be on a Wednesday, as no one really wants to be reviewing or thinking about how to get better (introspection being a notoriously tougher ask anyway) on a Friday. They said they were going to take it away and run it as an experiment and let me know how it went. This week the team had their respective review and retrospective, with the feedback being that the team much preferred this approach, as well as the inputs to the retro being much more meaningful and collaborative.

It reminded me that sometimes as coaches we need to recognise that we can actually achieve big through small, and that a tiny little tweak can actually make the world of difference to a team. For myself I’ve recently found that I’ve been getting very frustrated with bigger changes we want to make, and concepts not landing with people, despite repeated attempts at engagement and involvement. Actually, sometimes it’s better to focus on those tiny tweaks/experiments that can make a big difference.

This concept is explained really well in Peter Sims “Little Bets”, a great book on innovation in organisations through making series of little bets, learning critical information from lots of little failures and from small but significant wins.

Here’s to more little bets with teams, rather than big changes!

Digital Accelerators

This week we also ran the first of two sessions introducing Agile to individuals taking part in our Digital Accelerator programme at PwC. The programme is one of the largest investments by the firm, centered on upskilling our people on all things digital, covering everything from cleansing data and blockchain to 3D Printing and drones.

Our slot was 90 minutes long, where we introduced the manifesto and “Agile Mindset” to individuals, including a couple of exercises such as the Ball Point Game and Bad Breath MVP. With 160 people there we had to run 4 concurrent sessions with 40 people in each, which was the smallest group size we were allowed!

I thoroughly enjoyed my session, as it had been a while since I’d done a short, taster session on Agile — good to brush off the cobwebs! The energy in the room was great, with some maybe getting a little too competitive with plastic balls!

Seems like the rest of our team also enjoyed it, as well as the attendee feedback being very positive. We also had some additional help from colleagues co-facilitating the exercises which I’m very thankful for as it would have been chaotic without their help! Looking forward to hearing how the Digital Accelerators take this back to their day to day, and hopefully generate some future work for us with new teams to work with.

Next week

Next week is another busy one. I’m helping support a proposal around Enterprise Agility for a client, as well as having our first sprint review for our ways of working programme. On top of that we have another Digital Accelerator session to run, so a busy period for our team!

Weeknotes #31

OKRs

We started the week off getting together and formally reviewing our Objectives and Key Results (OKRs) for the last quarter, as well as setting them for this quarter.

Generally, this quarter has gone quite well when you check against our key results, with the only slight blip being around the 1-click deployment and the cycle time at portfolio level. 

A hypothesis I have is due to the misunderstanding around people feeling that they had to hold a retrospective before moving something to “done”, we have inadvertently caused cycle times to elongate. With us correcting this and again re-emphasizing the need to focus on the small batch, the goal for this quarter really will be to focus on getting that as close to our 90-day Service Level Expectation (SLE) at portfolio level. As well as this will be putting some tangible measurements around spinning up new, dedicated product teams and building out our lean offering.

Prioritisation

Prioritisation is something that is essential to success. Whether it be at strategic, portfolio, program or team level, priorities need to be set so that people have a clear sense of purpose, have a goal to work towards, have focus and that ultimately we’re working on the right things. Prioritisation is also a very difficult job, too often we rely on HiPPO (Highest Paid Person's Opinion), First In, First Out (FIFO) or just sheer gut feel. In previous years, I provided teams with this rough, fibonacci-esque approach to formulating a ‘business value’ score, then dividing this by effort to get an ‘ROI’ number:

Business Value Score

10 — Make current users happier

20 — Delight existing users/customers

30 — Upsell opportunity to existing users/customers

50 — Attract new business (users, customers, etc.)

80 — Fulfill a promise to a key user/customer

130 — Aligns with PwC corporate/strategic initiative(s)

210 — Regulatory/Compliance (we will go to jail if we don’t do it)

It’s fairly “meh” I feel, but was a proposed stop gap between getting them doing nothing and something that used numbers. Rather bizarrely, the Delight existing users/customers aspect was then changed by people to be User has agreed deliverable date — which always irked me, mainly as I cannot see how this has anything to do with value. Sure people may have a date in mind, but this to do with urgency, not value. Unfortunately a date-driven (not data-driven) culture is still very prevalent. Just this week for example we had someone explain how an option was ‘high priority’ as it was to going to be delivered in the next three months(!).

Increasingly, I’m finding a simple, lightweight approach to prioritisation I’m gravitating towards, and one that is likely to get easier buy in, is Qualitative Cost of Delay.

Source: Black Swan Farming — Qualitative Cost of Delay

Cost of Delay allows us to combine value AND urgency, which is something we’re all not very good at. Ideally, this would be quantified so we would all be talking a common language (i.e. not some weird dark voodoo such as T-Shirt sizing, story points or fibonacci), however you tend to find people fear numbers. My hope is that this way we can get some of the benefits of cost of delay, whilst planting the seed of gradually moving to more of a quantified approach.

Next Week

Next week is a big week for our team. We’re running the first of two Agile Introduction sessions as part of the firms Digital Accelerator program. With four sessions running in parallel with roughly 40 attendees in each, we’ll be training 160 people in a 90-minute session. Looking forward to it but also nervous!

Weeknotes #30

CI/CD

We started the week with Jon running a demo for the rest of UKIT on CI/CD, with a basic website he built using Azure DevOps for the board, pipeline, code and automated testing. I really enjoyed the way it was pitched, as it went into just enough detail for people who like the technical side, but also was played out in a ‘real’ way of a team pulling an item from the backlog, deploying a fix and being able to quickly validate that the fix worked whilst not compromising on quality and/or security. This was a key item for our backlog this quarter, as it ties in nicely to one of our objectives around embedding Agile delivery in our portfolio, specifically around the technical excellence needed. We’re hoping this should start to spark curiosity and encourage others to start exploring this with their own teams — even if not fully going down the CI/CD route, the pursuit of technical excellence is something all teams should be aspiring to achieve.

Aligned Autonomy

This week we’ve been having multiple discussions around the different initiatives that are going on in our function around new ways of working. Along with moving to an Agile/Product Delivery Model, there are lots of other conversations taking place around things such as changing our funding model, assessing suppliers, future roles, future of operations and the next generation cloud, to name a few. With so many things going on in parallel, it’s little surprise that overlap happens, blockers quickly emerge, and/or a lack of shared understanding ceases to exist. Henrik Kniberg has a great talk where he talks about the importance of aligned autonomy, precisely the thing that we’re missing currently.

Thankfully, those of us involved in these various initiatives have come together to highlight the lack of alignment, with the aim of something a bit more cohesive to manage overlap and dependencies. A one day workshop is planned to build some of this out and agree priorities (note: 15 different ‘priorities’ is not prioritisation!) — which should provide a lot more clarity. 

An important learning though has to be around aligned autonomy, making sure any sort of large ways of working initiative has this.

Next Week

Next week has a break midweek for me, as I have a day off for my birthday 😀 We’ll have a new DevOps Engineer — Dave starting on Monday, looking forward to having him join our organisation and drive some of those changes around the technical aspects. Dan is running a lunch and learn for the team on LeSS, which will be good to hear about his learnings from the course. We’ve also got an OKR review on Monday which will be good to assess how we’ve done against our desired outcomes and what we need to focus on for next quarter.

Weeknotes #29

Back to training

It was back to training this week, as myself and Stefano ran another of our Agile Foundations sessions for people across the firm. It was also Stefano’s first time delivering the course, so a good experience for him. We had an interesting attendee who gave us “a fact for you all, agile is actually a framework” in the introduction which did make me chuckle and also made things a little awkward 10 minutes later for our Agile is a mindset slide:

Source

We also had a number of our new graduates attend, which was good to meet them all and not have to deal with quite so many “but in waterfall” or “how would you do this (insert random project) in an Agile way” type questions. They also got pretty close to building everything in our Lego4Scrum simulation which would have been a first, had it not been for a harsh business stakeholder attending their sprint reviews! There were a couple times they got lost when doing the retro and misunderstanding its purpose, which was hard to not interject and correct it. Feedback was they would have preferred being steered the right way (as we let it play out), so good learning if that happens again.

BXT Jam

On Wednesday night myself and Andy ran a session in the evening as part of a BXT Jam.

BXT (Business, eXperience, Technology) is all about modern ways of working and helping our clients start and sustain on that journey. It has four guiding principles of:

1. Include diverse perspectives

2. Take a human centred approach

3. Work iteratively and collaboratively

4. Be bold

Our session was mainly centered on understanding Agile at its core, really focusing on mindset, values and principles as opposed to any particular practices. We looked at the manifesto, some empirical research supporting Agile (using DORA) and played the Ball Point Game with attendees. We took a little bit of a risk as it was the first time we’d run the game, but given it’s a pretty easy one to facilitate there thankfully weren’t any issues.

Andy handled some particularly interesting questions well (“how are we supposed to collaborate with the customer without signing a contract?”) and I think the attendees left with a better understanding of what Agile at its core is all about. We’ve already been approached to hold a similar session for our Sales and Marketing team in October, so hoping this can lead to lots more opportunities to collaborate with the BXT team and wider firm. Special thank you has to go to Gurdeep Kang for setting up the opportunity and connecting us with the BXT team.

Next Week

Next week I’m heading to Birmingham to run a couple workshops with Senior Managers in our Tax teams, helping them understand Agile and start to apply it to a large, uncertain programme of change they are undertaking. We’ll also be holding a sprint review with one of our vendors centered on new ways of working, looking at how some of our pilot teams are getting on and learning from their feedback.

Weeknotes #28

Incremental Changes

This week I observed a great example of approaching work with an Agile mindset. Within our office we have a number of electronic displays which show desk availability on each floor, as well as room names/locations. John Cowx, one of our Experience Design team, showed to me an incremental change they had made this week, introducing a single touch screen for one display on one floor which would allow staff to interact, type in a room name and then have a route plotted to the room to show them the way. This is a great example of an Agile mindset to work, as rather than roll this out through every single screen across every single office across the country, here we’re piloting it (small batch) and observe the interactions/obtaining feedback, before making changes and/or deciding whether or not to scale it across all locations (inspecting and adapting). It was great to not only see someone so passionate about the product, but to see an example of the Agile mindset being evidenced in the work we do.

Retrospectives

This week we were having a conversation around the Continuous Improvement initiative being run in IT and encouraging people in our ‘Project’ model to conduct retrospectives, regardless of delivery approach (then taking any wider improvements identified in the retrospectives into the initiative to implement). It’s something that has been running for a while with limited success as, generally, the observations are people aren’t conducting Retrospectives or the improvements being implemented are low hanging fruit rather than anything meaningful of impact. The former doesn’t really surprise me, even with using our team to provide lots of guidance, templates and lunch & learns. For me it’s clear that people don’t want to use retros (which is fine), therefore we need to learn from that feedback and change direction, rather than continuing to push the retrospectives agenda, as otherwise we can end up falling into the trap below:

Imposition of Agile

It’s perfectly reasonable to see that people can continuously improve without doing retrospectives but more importantly, it’s to recognise that doing retrospectives != continuously improving. I’ve suggested the group conduct some end user interviews/field research to understand why people are struggling with retros and also around what they see the purpose of the initiative as. Possibly there could be an unearthing from that around what the real improvements are that are needed, rather than relying on the retrospectives as the mechanism to capture them.

TLDR; individuals and interactions over tools and processes

Training

It was back to the training rhythm this week, running a half day session on Wednesday as part of our Hands On With Azure DevOps course. Given it had been so long since running any type of training, I found myself a little bit rusty in parts, but generally thought it went well. Dan from our team was shadowing, so we can reduce the single point dependency in the team of only myself running the session. This was really good from my perspective as there are certain nuances that can be missed, which he was there to either point out to attendees or to ask me about. Having started doing the session months ago it finally feels like now the content flows nicely and that we give a sufficient learning experience without teaching too much unnecessary detail. My favourite point is the challenge on configuring the kanban board, as normally there are a lot of alarmed faces when it’s first presented! However they all end up doing it well and meeting the criteria, which is of course a good indicator that attendees are learning through doing. There is only one slot available across all sessions in the next four months, so please that demand is so high!

Next Week

Next week it’s back to running Agile Foundations courses — with myself and Stefano running a session on Tuesday. I’ll also be working with Andy from our team on presenting at a BXT Jam on Wednesday night, with a 30–45 minute slot introducing people to Agile. A few slides plus the ball point game is our planned approach, hoping it can scale to 40 people!

Weeknotes #27

New Ways of Working

This week we’ve had some really positive discussions around our new delivery model and how we start the transition. We’ve tentatively formulated a ways of working group, bringing expertise across operations, software engineering, programme & portfolio management and Agile — so it should provide a nice blend in managing the change. The more conversations we’re having with people the consistent feedback is that it “makes sense” with no real holes in the way of working, however a recognition that we are some way away in terms of the skills needed with the current workforce. I’m hopeful we’ll be able to spin up our next pilot product teams and service in the next month.

Brand Building

Now that the holiday season is over with, we’re back into full flow on the training front. This week Dan ran another Agile Foundations session on Monday, which was followed up with some fantastic feedback. Speaking to someone who went in a separate conversation on Wednesday she said it was “the best training I have ever attended”, which is a fantastic endorsement to Dan and the material that we have. Currently it’s forecast for us to have delivered 41 training sessions in 2019, which will be a great achievement.

The good thing about these sessions going well is that word of mouth spreads, and this week I was approached about us getting involved in other initiatives across the firm. BXT is one of our Digital Services we offer to clients, and we’ve been requested to present at a BXT Jam later this month for roughly 40–50 people, to help familiarise attendees with what Agile at its core is really about, plus showcasing what we’re doing to grow and embed that thinking in our culture. We’ve also been asked to help run sessions on Agile as part of the firms Digital Accelerator initiative, which is helping over 250 people (open to anyone from Senior Associate to Director, across all LoS and IFS) upskill in all things digital, in order for them to become advocates and help the firms next phase of our transformation, helping us to build our digital future faster. With over 2000 applicants across the UK it’s something recognised by the whole firm and highly visible, so hoping it’s more positive press for the Agile Collaboratory — maybe we can get an exec board member playing with Lego!

Change is hard

This week in general I’ve found things to be really tough from a work perspective. I’m finding it increasingly difficult when involved in calls/meetings to not get frustrated at some of the things that are being discussed. This is mainly due to it being things like bad knowledge, deliberately obstructive behaviour, misinterpretation or statements being made about things people really just don’t know anything about. Despite trying to help guide people you can often be shouted down or simply not consulted in conversations. It must have been noticeable in particular this week as within our own team people asked if my weeknotes were going to be as bad as my mood!

A day in the life…

I think when you’re involved in change like we are, there are going to be setbacks and off days/weeks — you are going to get frustrated. Like all things it’s important to recognise what caused that, and what preventive/proactive measures you’re going to take in order to not feel that way again. For myself, I’m going to temporarily taking myself out of certain meetings, in order to free up time to focus on individual discussions and share/build understanding that way.

Next Week

Next week it’s back to training, with another of our Hands On With Azure DevOps sessions in London. The week concludes with a trip to Manchester to look at identifying our next pilot product teams and areas of focus, a meeting I sense may provide more challenges!

Weeknotes #26

Manchester Travels

This week I spent a couple days on the newly designed fourth floor of our Manchester office. Despite the rain (seemingly every time I go to Manchester) it was great to see a new, modern work environment with lots of space for visualisation and collaboration amongst teams.

Source: PwC_NorthWest Twitter

One of the main reasons for my visit was to present our proposed new ways of working model to get an agreement around this being where we *think* (as it’s emergent) we want to go, as well as formulating a working group and how to approach the change (incremental rather than big bang). It was one of the most positive meetings I’ve been to in recent months, both in the sense of getting feedback/providing clarity to others, and from a personal standpoint being able to passionately showcase the work our team have spent the last few months on.

Another reason for my visit was to meet our new Agile Delivery Manager — Stefano Ciarambino who has moved across from Consulting to do a six month secondment with our team. Me and Stefano have chatted on and off about all things Agile for the past 6/7 months, after he attended one of the Hands On With Azure DevOps course I ran. I was impressed with his experience and understanding as a practitioner, and with us starting to gain momentum with our new ways of working model, we needed a new face in the team to help *do* and help others do. Having learnt through some past mistakes, I’m quite particular now around who we have in our core team and them bringing something unique to the table. I’m hoping it proves to be an enjoyable six months for him and for us, so that we can make his stay a permanent one — welcome aboard Stefano!

Reflection

This week is a bit of one for anniversaries! This post will mark 26 weeks/6 months of writing weeknotes. In reflecting on the writing of them, I’ve found it to be a great vehicle for checking that the work I’m doing actually has purpose. For example if I’m getting to the end of the week and struggling to come up with things to write about, then maybe I’ve not been working on the right things! I hope sharing the things I’m learning through our own internal Agile adoption should help others who are experiencing it in a big organisation, and show to those who I do work with that I’m learning all the time, just as they may be.

This week also marks the four year anniversary since I joined PwC. When I think about that first team I joined to work with, who were split by developer per application, estimating tasks in story points but stories in hours, not delivering anything working at the end of sprints and working without PO’s, it’s fair to say I’ve come a long way since then! There’s been some memorable high points for me, a highlight being over the last twelve months in building a team of people who I look forward to working with every day. Also it contains some low points, for example being maybe too dogmatic at the beginning around Agile or having to walk away from teams as the negative behaviours from a management perspective inflicted on them were not going to change.

Hoping for both to continue for the foreseeable future and to writing the same again in twelve months time!

Next Week

Next week is our sprint review, looking forward to getting feedback on work we’ve done and what we should focus on next. I’ve also got some conversations with people who could help us in our transition towards new ways of working — looking forward to hearing their thoughts and seeing what adjustments we could make.

Weeknotes #25

Team Identity

One of the experiments we’re running is for our newly formed teams to come up with a team name as well as some form of team identity. Typically we’ll suggest teams complete something like a team canvas, coming back to revisit it as the team evolves and matures, to better reflect ways of working.

We’re struggling at the moment around this becoming a ‘thing’ that teams do, and it’s often greeted with derision, a blank stare or a roll of the eyes. As well as that teams aren’t always the most creative with either team names (we’ve suggested a theme of ‘major places — fictional or non-fictional’) or filling out the canvas (i.e. completing them with Agile buzzwords so as to ‘convince’ management). This week in particular I’ve mentioned it a number of times to people, the majority of the time getting one or all of the reactions above. I’m struggling with why this is, in particular when I think about some of the great teams we know of. A great (albeit begrudgingly) example for me is Manchester United. When I think about the Ferguson era, the class of 92 and the values and principles he instilled at that club, everyone there knew what it meant to be ‘Manchester United’ — in terms of what was expected both on the pitch and off it. You hear ex players now talk with great passion about what it means to be at that club, to wear that shirt and how certainly in recent teams they’ve lost their way, with those values seemingly going out the window. When coming up with a team identity, this is what we want teams to strive for. I’m not sure if it’s because work has become so transactional for people they can’t possibly fathom something that isn’t solution focused (i.e. naming yourself after the application you’ve worked on) or that the psychological safety is lacking in the context they are in (i.e. teams don’t feel safe enough that they can be viewed as having fun or show vulnerability). One to watch in the coming months but a topic I’m certainly finding difficult at the moment.

Agile Portfolio Management

This week I’ve also been helping on some client work where we’re looking at helping their PMO transition/adopt Agile ways of working, and what it means for their area. For a lot of organisations this is probably one of the hardest areas to change — with a PMO that is focused on milestones, RAG statuses and being on time and on budget, getting them to shift mindset is one of the biggest challenges. We’ve been trying to do some of this internally, with a real shift towards a focus on flow from a metrics perspective, but also agreeing some principles around what the PMO is there for. Even just adopting the metrics more relevant to Agile teams is not enough, it requires a whole shift in thinking around the PMO being an enabler for business agility. Things like focusing on the small batch, focusing on outcomes, as well as the scaling of team work through to portfolio and strategy at the relevant flight levels is really how a PMO “transforms”.

We’ll be playing back to them some example next week, which should hopefully lead to some good conversations and follow on opportunities for how we can enable their Agile adoption.

Next Week

Next week it’s back to Manchester, as we look to setup a ways of working group to take our adoption to the next level. We’re looking to blend experienced Agilists with PwC’ers, which should give us that balance. As well as that we have our first Agile Delivery Manager starting, looking forward to welcoming Stefano to the team!

Weeknotes #24

Psychological Safety

A trip to Manchester this week involved interviewing for a new Product Manager role, making a point of focusing on questions centered around outcomes people had experienced (both good and bad). I was really impressed in particular during one of the interviews where a candidate mentioned around the importance of psychological safety for the team. This individual even went on to reference Amy Edmondson when I queried further, which was even more impressive! It’s clear now that more and more practitioners are aware of the importance of psychological safety in their environment with it often being the focus of talks at conferences, meetups etc.

For those unfamiliar, psychological safety refers to:

An individual’s perception of the consequences of taking an interpersonal risk or a belief that a team is safe for risk taking in the face of being seen as ignorant, incompetent, negative, or disruptive. In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.

As part of Project Aristotle, Google found it to be the top key dynamic that set successful teams apart from other teams at Google. It also is referenced in this years State of DevOps report as positively impact software delivery performance.

The 2019 Accelerate State of DevOps

In our ways of working (WoW) programme, tracking this will be really important. Measuring it is no doubt hard, however there are some useful articles already that may help us in this aspect of our journey.

Dev+Ops != DevOps

This week we’ve taken a look at some of pilot teams in our WoW programme and planning the next steps in bringing them closer together in the value stream. With a traditional horizontal slicing of roles, we now need to rebuild that relationship between Dev and Ops into the same team, however that means for the time being we’re still going to have a bit of a split, something which we need to address in the coming months. Putting ‘DevOps’ teams together is not as simple as just chucking them together, it’s largely cultural based, with the right tooling to support them to work together.

Looking at where I would rank our organisation using DORA’s quick check, I’d suggest we’re at the following:

Which shows how much work we have to do/some of the challenges we’re facing. On the operational side we’re pretty strong in time to restore service, however we need to do a lot more in building that trust around deployments. The hope in the coming months is to pair up 1 x Dev and 1 x Ops together, in order to grow that capability around DevOps.

Next Week

Next week I’m helping put together some material on Lean-Agile Portfolio management for one of our clients, hoping to weave in some of the metrics we’re using currently, as well as that we’re looking at agreeing our next pilot team(s) and starting them on their Agile journey.

Weeknotes #23

Incremental Approach to Change

This week we’ve been having numerous discussion around roles in our proposed delivery model, with some differing views as to how to approach it. My view, much like how Agile delivery is, would be to incrementally roll-out new ways of working, once confidence builds and constraints are addressed. Taking the expectations/skills we desire in new roles and mapping the current skill set, it’s clear we have a shortfall in what is needed. That’s not to say we don’t have the right people, in particular lots of people can bring contextual knowledge to the table that will help us as change leaders learn. However there should be a recognition that a period of upskilling is needed, one which can only be done through continuous coaching with these individuals, something that you can’t do in one big ‘batch’. Similarly, the technical excellence needed to aid business agility is few and far between currently, which therefore presents a dangerous flirtation of something akin to a TACOS implementation.

[embed]https://twitter.com/tottinge/status/943518694436679681[/embed]

A learning this week therefore has been witnessing first hand the reasons why so many change programmes fail. Taking a SAFe rollout as an example, to suddenly train everyone, then set them up in a release train with a bunch of new roles/titles without any sort of consideration for the individuals impacted is very naive. To expect people to be ‘transformed’ overnight (or over 2/3/4/5 days — depending on your preferred training course) to Agile people in an Agile organisation is simply not how change works. 

Change is hard, change takes time and those involved in change need to be prepared for this. Shortcuts only guarantee one thing, change won’t stick.

Metrics for Business Decisions

I’ve been continuing to read Mattia Battiston and Chris Young’s book — Team Guide To Metrics for Business Decisions. Despite only being 70% complete it’s been a great read so far, and should provide a lot of inspiration for practitioners, both those that are experienced and those that are just starting their Agile journey. A favourite section of mine is the one on forecasting, and the pitfalls of using story points. I conveyed similar thoughts to our internal and client facing teams around why we feel the need to do this with teams, yet it still feels like as an industry we’re finding it hard to let go of some of those things we hold dear. Buy it here.

Ron Jeffries said it best:

[embed]https://twitter.com/ronjeffries/status/943790497981706242?lang=en[/embed]

Team Health Checks

I’ve started introducing the concept of us running Team Health Checks with our Agile teams, to make visible if teams are in an environment they can succeed and if our culture fits their needs. Whilst retrospectives are great, sometimes a high level view of certain areas and identification of trends is needed, particularly if you’re a leader and sometimes need a TL;DR.

This is an example of the outputs from the health check we ran within our own Agile coaching team at the beginning of our retro on Tuesday. We take the mode (most frequent) value in the responses, settling on the lower of the two if there is a tie. I slightly tweaked the well known version famed by Spotify, as not all of our teams are doing software development (however a separate template exists for those that do) as well as adding a question on psychological safety which, given Google’s findings, is one of the most important things to consider. Looking forward to seeing more teams give it a try and spot some underlying trends that may not immediately be apparent.

Next week

Next week involves a trip to Manchester, where we’re interviewing for a new Product Manager and DevOps Engineer. It’s a good indicator around the backing we have in the change that we’re able to make these hires, aligning with roles that are recognised across the industry, rather than creating roles specific to our IT department. Looking forward to meeting some interesting candidates!

Weeknotes #22

Invitation over infliction

This week we’ve been looking at mapping our existing applications into specified products and services, to have an initial idea around where we may want to go next from a product side in incrementally moving to new ways of working. Unfortunately as part of that some had misunderstood, and taken it as a need to also map people into new roles, based on what they do now, without much/any conversation with those impacted individuals. 

After again being inspired by watching Jonathan Smart latest talk on Better Value Sooner Safer Happier, I had to explain around the need to invite rather than inflict change.

RIP Grumpy Cat

Trying to drag and drop humans into new roles just like how we move files on our devices is the classic example of inflicted, capital A/D, capital T, agile/digital transformation. This kind of approach lacks empathy, and is more than likely to result in limited success in adopting new ways of working. Inviting people to the change, be it through asking for their feedback, sowing the seed for maybe where we want to go but showing our own fallibility in admitting of not being sure ourselves is more likely to lead to success in the long run, as people feel a sense of involvement and ownership in the journey. The message seemed to land in the conversations we had, with us agreeing to slow down to focus on the product/service side, and taking a slower, incremental approach on the people side.

Product Management

Increasingly we’re having more and more discussions around Product Management and the importance that role is going to play in achieving positive outcomes for new ways of working. One of the first things that comes up is the difference between a Product Owner and Product Manager. 

As I’ve mentioned before, Melissa Perri’s view of a Product Owner being a role on a Scrum team Vs. a Product Manager being a career is what we’re explaining to people. In addition to that, she gives a great overview here. Scrum has lots of stuff on the process/rules of Scrum and what a PO should do, but leaves a lot of stuff unanswered around knowing if you’re actually building the right thing or not. It’s precisely why we’re focusing on Product Manager as a role, as we want them to be able to prioritise work in particular from an outcome oriented perspective. I recall my days at Royal Mail when I worked with a Product Manager called Anne, who was one the best PM’s I worked with. She showed me what Product Management really was all about, not just prioritising work but also pouring over customer data and obsessing over outcomes rather than individual features. This lead to developing some of the most used products on the platform, as well as creating new revenue streams for the organisation. This mindset is what makes a great Product Manager.

FlowViz

This week I finally managed to get FlowViz into the Azure DevOps Marketplace through a collaboration with Agile Extensions.

Whilst the listing only redirects people to my GitHub page, it’s nice to have something out there and see if it’s going to help people in the teams they work with. I purposely made it free due to me wishing I had something like this early on in my Agile journey-hopefully it will help others avoiding making the same mistakes I made/measure things a bit more useful!

Next Week

Next week we have our team sprint review and retro — a good time for us to reflect on how our adoption of new ways of working are going and a check in on our OKRs to see how we’re performing so far this quarter, changing direction if we need to.

Weeknotes #21

Personal Kanban

I started this week by running a little bit of an experiment, using Kanbanchi as a personal kanban tool for the week. We’re current trialling the product with different teams, mainly as it nicely integrates with G Suite. It’s easy to get started, and once I’d created a board I mapped out my workflow (of course using WIP limits as well) of:

To Do This Week | To Do Today | Doing | Done (Awaiting Feedback) | Done

After that, I set myself a 15 minute daily standup at 7:30 each morning, to review my board and make a plan for the day. Much like when you work with new teams, you don’t quite realise how many things you’re doing (or things that are half done!) till you start to make it visible.

They’ve also recently added some metrics to the product as well which, for those that know me will be aware of, are something I’m very passionate about. Here is a look at my CFD for the week as of this morning:

Overall, I found it pretty useful and something I’ll look to stick with in the future. Nothing like eating your own dog food!

Continuous Everything

This week we ran a workshop to start to define how support would work in our new ‘Product’ world. With the traditional hand-off from Dev to Ops (throwing over the fence?), the conversation was all around how we bring these two groups together, in particular looking at some of our pilot product teams we’re working with at the minute and how we can incrementally introduce that in. It was good to have a number of the roles in teams already prepared to explain to a wider group, as it helped provide context around what outcomes we’re trying to achieve, plus the chance for us to get feedback around if they actually make sense. Whilst there’s no doubting there will be teething problems/learning, the good thing was that everyone came away positive and with a shared understanding on how we want things to work. Simon from the Operations side did a great job in facilitating, in particular by involving not only those of us on the Agile side, but also our supplier (for the pilot team) and procurement in the conversation. With this adoption of new ways of working, it is clear that everything now moves to being continuous. Not just continuous integration and delivery, but also continuous compliance, continuous support and ultimately, continuous transformation. There is no ‘end state’ and teams should now be constantly looking to experiment, learn and evolve their own ways of working.

Agile Outside IT

The Assurance Digital Audit team had a bit of a soft launch this week in their Agile adoption, which I attended along with their core team based in London. The team are taking a pragmatic approach to Agile adoption, using kanban boards at Project > Deliverable > Product Backlog Item (PBI) > Task level depending on your role in the team, combined with daily scrums to start with. What’s been great so far is the recognition that full blown Scrum is probably not right for their context currently, but they have expressed a desire to incrementally get there. The team have taken to it really well so far, with myself just needing to sow the seeds every now and then around what the principles of Agile are, gently steering them if they start to go off track. It will be interesting to see how the next few weeks/month play out, with a plan for a UK wide adoption based on the outcomes of piloting it in London.

Next Week

I’ll be starting next week off with a discussion around Machine Learning in an Agile world, with a team interested in learning more and applying the practices relevant to their context with the work they do in Assurance. We’ve also got a long overdue team night out planned for Wednesday at Swingers Mini Golf — looking forward to a few drinks, great company and hopefully not too many sore heads (and bruised egos after the mini golf?) the next day.

Weeknotes #20

Project to Product

This week we’ve been spending a number of sessions building out what our future IT delivery model looks like, with the focus on shifting from project thinking to aligning products teams around services we offer to the organisation. Building on last weeks notes, the current working definition we’ve gone with on the Product front is the following:

Product — a product is a tangible item that closely meets the demands of a particular market and yields enough value to justify its continued existence. 

It is characterised by its benefits, features, functions and uses that satisfy needs of the consumer.

With this, we feel some taxonomy is also needed around what types of products we offer, with the below being what we currently define as offerings:

Now, we’re still learning through incrementally moving towards the model but kudos must be given to Government Digital Service (GDS) material available online. The role descriptions and skills needed with positions such as a Delivery Manager, Product Manager, Business Analyst and Service Owner are all roles we envisage to feature prominently in our new teams and services, so it’s great to have some material out there to build appropriate roles and (more importantly) career paths for our people. 

The biggest area of challenge I foresee at the moment is around Product Management, with this being a skill that across the whole organisation we’re not great at. A blend of hiring experienced PM’s and upskilling the majority is likely the route we’ll take to address this. Look out for future posts on the rest of the delivery model as we learn and iterate in the coming months/years…

Goal Setting

With it being summer holiday season, it’s the annual “goal setting” period for everyone in the organisation. I’ve found it hard to formulate my goals this year, not so much with what I want our focus to be on as a team, but more the measurement aspect that comes with goals. My goals are currently a blend of launching new ways of working (through product teams), reducing batch size/managing portfolio WIP around ‘old ways of working’ (projects), moving towards certified trainers within our team and finally a personal goal around being a career coach for a couple of our newly promoted managers in IT. 

The notion of setting annual goals is a problematic one I find as a practitioner, drawing parallels with big up front planning akin to a waterfall world. Thankfully I work with a career coach who is pragmatic around my goals and allows me to tweak them where appropriate. 

It was great to see a member of our leadership team share their goals around committing to have N teams (exact number still TBC) having implement continuous delivery within the performance year, especially as that really is the ‘hard stuff’.

Reflection

This week, myself and Andy had a call with a member of our Assurance team who wanted a demonstration around some of the things we had implemented as part of formulating the Lean PfMO within our IT organisation. The call went really well with them being impressed with some of the things we’d done around prioritisation of work using our rough RoI calculator, the visualisation of work using a portfolio kanban board and the empirical nature of monitoring progress using flow metrics. It made me reflect on when myself and Andy first started working together a couple of years ago, and how our own working relationship has developed, as well as the improvement of his own understanding and knowledge around Agile ways of working and portfolio management. With my primary focus being on where I feel we need to be and how far away we are from that, it’s easy to forget just how far we’ve come from where we once were. Some of the things we have implemented so far have gone really well and are a far cry from a large majority of people in our organisation who still rely on techniques such as spreadsheets to manage their work. Much like these posts, reflecting on how far you’ve come can help motivate, in particular during times of frustration.

Next Week

Next week I’m looking forward to meeting one of our new Consulting directors, who is focused in particular on Agile ways of working using SAP and cloud in the FS sector. I’ve already helped him this week get a Kanban board setup for his current team (rare to get someone proactively wanting one!), so hopefully it can be a mutually beneficial chat :) 

With a few gaps in the week I’m hopeful I can finally make a start on our 2-day ICAgile Certified Agile Fundamentals course, which we plan to start offering from October this year.

Weeknotes #19

Agile-impics

This week we ran our second Agile-impics event out of our More London office. Like last time, teams were given a case study which they then had to apply elements of product visioning, story slicing, planning and estimation to before presenting back to myself and others who act as judges (in this case we were board members). This time we had six teams (compared to nine previously) who were battling it out for the coveted PwC Agile Olympics trophy.

Overall, teams did well in understanding the case study and having something engaging to present back to myself and the other two judges. Storytelling is a really important part of what we do, and it’s clear some teams were very strong in that area. Some fell into the trap of throwing too many terms into their presentations. Senior leaders don’t really want to hear about epics / features / fibonacci numbers. Another point was around planning, and in particular planning based on velocity. Now this approach is fine (or maybe try without…CTRL+F the Scrum guide for story points 🙃) however it presents a lot of risk when using ‘average velocity’. Plans based on average fail 50% of the time — should we really be encouraging that as practitioners?

A recommended video would be Dan Vacanti’s talk on forecasting:

[embed]https://www.youtube.com/watch?v=1jI4cvQbWQA[/embed]

Overall though it was a fantastic event. Less teams worked better in terms of the organisation and judging, teams focused on outcomes > outputs and it was great to have partners attend to stress how important Agile is, in particular with our clients. Looking forward to the next event!

The power of the network

This week I’ve been amazed at the power of our network in terms of both creativity and bringing people together. 

On Tuesday we had a visit to our office from Paula who works in our Advisory team in Colombia (Paula was here on holiday — she didn’t fly all that way for just a meeting!). It was great to share ideas and chat to someone else trying to drive change in both our internal ways of working and what we offer our clients. The appetite and enthusiasm we have globally for Agile & DevOps is one that keeps me inspired in my role.

Talking of inspiration, on Wednesday I had the pleasure of recording a short podcast with Mike and Lisa in our IT Employee Engagement team on ‘bringing goals to life’ — and how people can help us achieve our goal this year of taking an Agile by default approach. It was lots of fun and flowed really nicely (one take!), as well as the fact that Mike brought some real concrete examples of where he had applied Agile thinking (small batches FTW) despite being on a traditional waterfall delivery.

Defining a “product”

Now that the main element training is done for close to 90% of our IT staff, the hard work begins on the transition from project to product. A current working definition I quite like around defining what we offer being centered on products is:

A product is a tangible (good) or intangible (service) information offering to meet the needs, wants, and demands of the firm.

As part of the change we need to think about the roles in our IT organisation and how we best align them around products. This presents a good challenge and one where I’m looking forward to a continued learning process, as we incrementally transition.

Next week

Next week I’m helping the Digital Audit team build out their Agile ways of working for their Advanced Analytics programme, doing more work on performance goals and spending time putting together what the future operating model looks like from a roles perspective.

Weeknotes #18

Scaling OKRs

After a year of experimenting with OKRs, we’re getting a lot better as a team in setting achievable and ambitious objectives and key results for the quarter. The approach appears to be working, as this week our help was requested by a member of our IT leadership in helping set OKRs for five other teams across our IT department. This presents a new challenge for us, in that we’ll get to learn about scaling OKRs and how we can use them across multiple teams to create departmental (and scaling to organisational) alignment. With the fact that the key results are SMART in their nature, it should also mean personal objective setting is a lot easier for people. I know this is something a number of people (including myself) find difficult, so if we can introduce something that makes this easier then it’s another potential win for our team.

Agile Assurance

I had some good conversations this week with multiple people in our Assurance team who wanted to learn about applying Agile either to their own work internally or developing further offerings to assist clients. 

It makes sense why an offering around an empirical, data-driven approach would appeal to clients, as well as the fact it’s focused on the roots of Agile around empiricism and transparency. An interesting learning for me in our conversations was just around how many misconceptions there are when it comes to metrics/measurements for teams to use. The language used such as ‘Items committed Vs. Items delivered’ or ‘Estimate Accuracy’ are almost all set out with a bias of ‘it must be the teams fault’ — rather than looking at underlying system symptoms, as well as focusing on outcomes. 

A good few hours coaching however managed to reset some of these misconceptions, so I’m looking forward to the next steps in us developing something that will ultimately aid organisational agility.

One of the partners in one of our business lines for Assurance seems dedicated to adopting Agile within his team(s), which was great to hear. So often it feels like our role is around convincing people why Agile is the right fit for them, whereas this was very much one centered on the how, rather than the why. We pickup again first thing Monday morning (I love a sense of urgency!) and already I’ve got lots of ideas in how we can help them adopt a pragmatic, flow based way of working based on Agile principles.

The Dip

This week I started reading The Dip, a short book by Seth Godin. The book explains how you might be in a dip, which may get better if you persevere, or that you may get stuck, and it will never get better no matter what you do.

According to the book, Winners quit fast, quit often and quit without guilt — until they commit to beating the right dip for the right reasons. It’s a good short read, and useful for anyone going through wider change programmes, who may need some supporting reading around the dip they may be in.

Next Week

Next week I’ll be recording a podcast with a couple of my colleagues on ‘bringing goals to life’. Given one of our three goals for this performance year is around taking an ‘agile by default’ approach, we want to give people some assistance and (hopefully!) inspiration around what that means and how everyone can help contribute towards us achieving our goals.

Weeknotes #17

We on award tour

As I mentioned before I went away, our team had been shortlisted for the Make a difference award for our IT awards. After an amazing two weeks away it was great to come back refreshed but also to have this:

It’s a testimony to the people in our team that we’ve been recognised with an award, and I’m incredibly thankful to all of them for a great year, hoping for a repeat in the next performance year.

Complex = Waterfall (🙄)

Another discussion this week has been around when to use Waterfall vs when to use Agile. Now this is a common discussion point for us at the moment, in particular with the current approach we are experimenting with being ‘agile by default’ with people needing to prove why Waterfall is a better fit for delivery. Our approach has been on a case-by-case basis, preferring conversation with individuals over a computer generated answer.

A document was passed our way as to some guidelines for when to use Waterfall or when to use Agile:

The major problem I have with things like this, is that they are similar to maturity models in their ‘one size fits all’ approach, and heavily favoured as revenue generators for consultants. They look to get away from conversation by getting a system generated answer, with little appreciation of context. 

The most baffling aspect on this particular one is alluding to that if it’s a complex product, where users are unknown, then waterfall is the best fit.

Perhaps it’s best for the creators to take a look at page 3 of the Scrum Guide:

Purpose of the Scrum Guide

Scrum is a framework for developing, delivering, and sustaining complex products.

This is where another useful tool in the practitioner toolkit is having familiarity with Cynefin.

Cynefin offers five decision-making contexts or “domains” — obvious (known until 2014 as simple), complicated, complex, chaotic, and disorder — that help managers to identify how they perceive situations and make sense of their own and other people’s behaviour.

Complex in particular is a domain that represents the “unknown unknowns”. Cause and effect can only be deduced in retrospect, and there are no right answers.

The notion of being in a complex domain and therefore waterfall being the only sensible approach is clearly flawed. Similarly the idea around ‘best practices’ for Agile also being an oxymoron.

Ultimately, regardless of approach to delivery, we should all try to remember this from Jeff Gothelf:

Every project does not have to be Agile. However, each project you work on should encourage and support agility.

Reviewing OKRs

With us coming to the end of the first quarter in our performance year, today we had a review of our OKRs as a team.

Overall, I think we were all quite pleased with the outcomes. In particular the 32% reduction in cycle time at portfolio level shows the impact introducing (and sticking to) WIP limits has had. Unfortunately it looks like a few things we’ve neglected or we were maybe too ambitious in setting as key results we looked to achieve. All useful in informing the direction we need to go for the next quarter.

Next week

Next week I’ve got a few discussions planned with other coaches in the different business lines we have, so looking forward to hearing what’s going on in their areas. I also have a workshop myself and others in our team have been invited to which is tentatively titled as “Agile session for digital audit” — currently I’ve not had any briefing so prepared for an interesting session!

Weeknotes #16

Reward and recognition

This week, I was really pleased to see that our team have been shortlisted for the Make a difference award for our IT awards on 17th June:

Reward and recognition are tough subjects when playing the role of coaches and/or change agents. We all want to be rewarded/recognised for driving a wider change but we can often end up failing to get recognised with the ‘old’ behaviours still rewarded, this then tests your own ability to continue driving the wider change, as well as not be perceived as bias by those rewarding the wrong behaviours. Individual reward conversations are happening in the next few weeks so it will be interesting to see what has been recognised as leading by example, in particular with our strategic shift at the end of November to move towards more Agile ways of working. Hopefully the right behaviours have been recognised, otherwise my fear is that the sense of urgency will not be created if we still reward business-as-usual, big batch projects, year-long delivery cycles.

Training Day

On Wednesday I ran a one-day Foundations session for fellow IT staff in our Manchester office. This was the first one we’d run for IT people in the UK where we have switched up the format, replacing Featureban with lego4Scrum to get more of a feel for simulated delivery in an Agile world.

Feedback was positive across the board, which is good to know given the changes made. I’m a big fan of lego4Scrum, mainly due to its potential variability in outcomes (plus the fact it’s lego!). I’d like to give Featureban 3.0 a go, but

FlowViz

With some time to myself after flaky wifi (Virgin Trains 👀) on the train to/from Manchester and then up to Newcastle on Thursday, I set about refactoring FlowViz, given the API is now up to v3.0 (I built it using v1.0). 

It’s good to see the Azure DevOps team making more data such as builds, pipelines and test items available…although when looking through the data I was struggling to see what additions I could make with the new information. Ideally I’d like to bring in the 4 Software Delivery Performance metrics from DORA, alas this currently looks to be unavailable.

In any case, I made a number of tweaks, updating the endpoint to use both the new URL format (dev.azure.com) and the v3.0-preview of the API, as well as creating a few new charts for teams to use. With Power BI * still * (to my disbelief and frustration) unable to handle date on the x-axis without aggregating I’ve moved to using average cycle time per week with a trend line to see if we’re on the right path.

Wrong direction team!

I actually did this for existing teams a couple of months ago, so was quite pleased to see Troy’s new team dashboard having the same chart added a few weeks ago. Made me smile that my own thinking was in-line with someone far more experienced than myself.

Other charts added/updates include:

- Layout changes/new modern visual header

- In-Progress Item Age (Calendar Days)

- Stale Work (Days since item updated)

- Cumulative Flow by Day

I also made an attempt at the Tasktop flow metrics that get a frequent mention in Project to Product:

Nowhere near as good however feedback from others has been that they really like the ‘clean’ design — hopefully it’s a simpler way to present information that teams can start to leverage.

Check the link here for the free download.

Next week (or next few weeks)

Next week I’ll only be in the office on Monday morning, then taking an extended break till 3rd July. On Monday night myself and my fiancée will be flying out to Bali (not Hotel K — but thanks Jon for the book suggestion) for two weeks of relaxing and travelling. Of course, this means I’ll be taking a hiatus from Weeknotes till I’m back, so look out for Weeknotes #17 on 5th July.

Weeknotes #15

Metrics and Curiosity

This week I spent a few days (along with some big help from my colleague Tim) reworking one of troy.magennis amazing team dashboards from Excel into Google Sheets.

I view Troy’s work as really important to what we do in our industry, and the fact he gives it all away for free in a format that is easily consumable with clear instructions is even better. He has been one of my biggest inspirations in the last few years, always available to chat, give feedback and share ideas with. If you are going to Agile 2019 this year, be sure to check out the Data & Metrics track he has put together (I’m biased as I helped review the submissions!).

On the topic of metrics, it’s great how beneficial they are in unearthing information that isn’t immediately visible to a Coach/Scrum Master/Delivery Manager. A great example of that was this week with someone I’m coaching, where we looked at a scatter plot for her team:

Now, whilst this is great in showing you how long things in general take (85th percentile — 16 days — not bad as this team are doing two week sprints), it should, if it’s an effective chart, spark curiosity and questions. 

Good coaches then find a way to safely introduce this information to the team (See: Goodhart’s Law) and leverage it to have better conversations as a team.

If we go back to the original visual, these are the sort of things I would be considering:

That way we’re asking open questions centered on improvement, rather than making the team feel they are being critiqued for performance using data.

Estimation

Estimation is always an interesting topic in the Agile world, from story points, t-shirt sizes, fibonacci or fibonacci-esque, cost of delay or even #noestimates there is always passionate discussion in this area. This week task estimation came up, specifically the topic of needing to estimate in hours for tasks, with some of our coaches working with teams saying that they ‘needed’ the team to estimate tasks in hours to understand capacity. Now I’ll admit this was a practice I once encouraged at the beginning of my career, however having learned and experimented with other techniques I can see it’s not effective, and something I wouldn’t get teams to start with now. The days of telling (or as I witness from some other Scrum Masters — yelling 😐) a team member to change their hours remaining in the digital tool from 3 to 2 are ones I look back on and cringe at. I was trying to explain to the coaches that it’s a bad practice, hourly estimation is nigh on impossible and that we should focus on flow, small stories and limiting WIP. 

Don’t believe me? Sutherland himself says:

We want to abandon hours as a reporting tool for Scrum teams as data on over 60,000 teams in a Rally survey shows that the slowest teams use hours. 

The fastest teams use small stories, no tasking, and no hourly estimation.

So as practitioners who are all about empiricism, why push old/bad practices on teams and ignore the empiricism that shows they don’t work?

Focus on flow, manage WIP, and slicing work into small vertical slices will tackle your capacity issue in a much more effective manner than updating your hours in any respective digital tool will.

A framework for Agile collaboration

On Thursday night I went along to an executive dinner at the Connaught Hotel hosted by IDC & Slack.

It was a really interesting evening, with approx 30–40 people from different organisations big and small sharing about their own Agile journey, challenges they were facing and success stories. Common themes over the dinner around approaches that help to success were, leadership buy in is a must for success, trust, measure outcomes over outputs and the shift from project -> product. The two challenges I heard most frequently used were culture and the funding model, which I would agree with.

A member of a large bank on our table in particular stressed the importance of having HR as part of the change which, given what I mentioned earlier, helped me validate we were making the right steps forward. 

Some surprising points for me were around technical practices, in particular on our table where some people didn’t think they were key (albeit important) to organisational agility. When you consider the work from DORA and Accelerate, which both talk about how technical practices directly influence organisational performance, I found that odd. Another interesting observation was around the love digital tools (Jira, Azure DevOps, Trello etc) were getting from everyone.

One table in particular began their answer to the main topic discussion point with “tools and process”. This was confusing to me given the values in the manifesto. In summary, I don’t think there was anything massively * new * I learnt over the evening, other than big organisations have similar issues to ours. It confirmed to me certainly that our current approach is sound and, whilst it may take years to get there we are getting there incrementally.

Next Week

Next week I’ve got some conversations around release management, which should be interesting given the inroads Jon made this week in automating ticket creation/closing for deployments with SNow and Azure DevOps. 

I’ll also be heading up to our Manchester office, running another 1-day Agile Foundations session for a number of new joiners in our IT organisation.

Weeknotes #14

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

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.