Weeknotes #39

Agile not WAgile

This week we’ve been reviewing a number of our projects that are tagged as being delivered using Agile ways of working within our main delivery portfolio. Whilst we ultimately do want to shift from project to product, we recognise that right now we’re still doing a lot of ‘project-y’ style of delivery, and that this will never completely go away. So we’re trying to in parallel at least get people familiar with what Agile delivery is all about, even if delivering from a project perspective.

The catalyst really for this was one of our charts where we look at the work being started and the split between which of that is Agile (blue line) Vs. Waterfall (orange line).

The aspiration being of course that with a strategic goal to be ‘agile by default’ the chart should indeed look something like it does here, with the orange line only slightly creeping up when needed but generally people looking to adopt Agile as much as they can.

When I saw the chart looking like the above last week I must admit, I got suspicious! I felt that we definitely were not noticing the changes in behaviours, mindset and outcomes that the chart would suggest, which prompted a more thorough review.

The review was not intended to act as the Agile police(!), as we very much want to help people in moving to new ways of working, but to really make sure people had understood correctly around what Agile at its core really is about, and if they are indeed doing that as part of their projects.

The review is still ongoing, but currently it looks like so (changing the waterfall/agile field retrospectively updates the chart):

The main problems observed being things such as lack of frequent delivery, with project teams still doing one big deployment to production at the end before going ‘live’ (but lots of deployments to test environments). Projects are maybe using tools such as Azure DevOps and some form of Agile events (maybe daily scrums), but work is still being delivered in phases (Dev / Test / UAT / Live). As well as this, a common theme was not getting early feedback and changing direction/priorities based on that (hardly a surprise if you are infrequently getting stuff into production!).

Inspired by the Agile BS detector from the US Department of Defense, I prepared a one-pager to help people quickly understand if their application of Agile to their projects is right, or if they need to rethink their approach:

Here’s hoping the blue line goes up, but against some of that criteria above, or at least we get more people approaching us for help in how to get there.

Team Health Check

This week we had our sprint review for the project our grads are working on, helping develop a team health check web app for teams to conduct monthly self assessments as to different areas of team needs and ways of working.

Again, I was blown away by what the team had managed to achieve this sprint. Not only had they managed to go from a very basic, black and white version of the app to a fully PwC branded version.

They’ve also successfully worked with Dave (aka DevOps Dave) to configure a full CI/CD pipeline for any future changes made. As the PO for the project I’ll now be in control of any future releases via the release gate in Azure DevOps, very impressive stuff! Hopefully now we can share more widely and get teams using it.

Next Week

Next week will be the last weeknotes for a few weeks, whilst we all recharge and eat lots over Christmas. Looking at finalising training for the new year and getting a run through from Rachel in our team of our new Product Management course!

Weeknotes 36

Refreshing Mindsets

This week was the second week of our first sprint working with our graduate intake on our team health check web app. It was great to see in the past week or so that the team, despite not having much of a technical background, had gone away and been able to create a very small app created using a mix of Python and an Azure SQL database for the responses. It just goes to show how taking the work to a team and allowing them to work in an environment where they can be creative (rather than prescribing the ‘how’) can lead to a great outcome. Whilst the app is still not quite yet in a ‘releasable’ state, in just a short time it really isn’t too far away from something a larger group of Agile Delivery Managers and Coaches can use. It’s refreshing to not have to take on the battle of convincing hearts and minds, working with a group of people who recognise this is the right way to work and are just happy to get on and deliver. Thanks to all of them for their efforts so far!

Cargo Culting

“Cargo Culting” is a term used when people believe they can achieve benefits by adopting/copying certain behaviours, actions or techniques. They don’t consider why the benefits and/or causes occur, instead just blindly copy the behaviours to try get similar results.

In the agile world, this is becoming increasingly commonplace, with the Spotify model being the latest fad for cargo culting in organisations. Organisations are hearing about how Spotify or companies like ING are scaling Agile ways of working which, in practice, sounds great, but it is incredibly hard and nowhere near as simple as just redesigning organisations into squads, tribes, chapters and guilds.

In a training session with some of our client facing teams this week, I used the above as an example of what cargo culting is like. Experienced practitioners need to be aware that the Spotify model is one tool in the toolbox, with there being lots of possible paths to organisational agility. Spotify themselves never referred to it as a model, nor use it themselves anymore, as well as ING moving towards experimenting with using LeSS in addition to the Spotify model. Dogma is one of the worst traps you can fall into when it comes to moving to new ways of working, particularly when you don’t stop and reassess whether this actually is the right way for this context. Alignment on language is important, but should not be at the compromise of finding first of all what works in the environment.

Next Week

Next week I’ll be running an Agile Foundations training session, and we (finally!) have Rachel joining our team as a Product Manager. I’m super excited to have her as part of the team, whilst hopeful we can control the flow of requests her way so she does not feel swamped, looking forward to having her join PwC!

Weeknotes #33

Right to Left

This week I finished reading Mike Burrows’ latest book Right to Left. 

Yet again Mike manages to expertly tie together numerous aspects of Agile, Lean and everything else, in a manner that’s easy to digest and understandable from a reader/practitioner perspective. One of my favourite sections of the book is the concept of the ‘Outside-In’ Service Delivery Review. As you can imagine from the title of the book, it’s taking the perspective of the right (needs, outcomes, etc.) as an input, over the left (roles, events, etc.) and then applying this thinking across the board, say for example in the Service Delivery Review meeting. This is really handy for where we are on our own journey, as we emphasise the need to focus on outcomes in grouping and moving to product teams that provide a service to the organisation. One area of this being around how you construct the agenda of a service review. 

I’ve slightly tweaked Mikes take on matters, but most of the format/wording is still the same:

With a Service Review coming soon, the hope is that we can start adopting this format as a loose agenda going forward, in particular due to it’s right to left perspective.

Formulating the above has also helped with clarity around the different events and cadences we want teams to be thinking about in choosing their own ways of working. I’ve always been a fan of the kanban cadences and their inputs/outputs into each other:

However I wanted to tweak this again to be a bit simpler, to be relevant to more teams and to align with some of what teams are already doing currently. Sonya Siderova has a nice addition to the above with some overarching themes for each meeting, which again I’ve tailored based on our context:

These will obviously vary depending on what level (team/service) we’re focusing on, but my hope is something like the image above will give teams a bit clearer steer as to things they should be thinking about and the intended purpose of them.

Digital Accelerators

We had another session for our Digital Accelerators this week, which seemed to be very well received by our attendees. We did make a couple changes for this one based on the feedback from last week, removing 2–3 slides and changing the Bad Breath MVP exercise from 2 groups to 4 groups. 

It’s amazing how much a little tweak can make, as it did feel like it flowed a lot easier this time, with plenty opportunity for people to ask questions. 

Last weeks session was apparently one of the highest scoring ones across the whole week (and apparently received the biggest cheer when the recap video showed photos of people playing the ball point game!), with a feedback score of 4.38/5 — hopefully these small changes lead to an even higher score once we get the feedback!

Next Week

Next week is a quieter one, with a trip to Manchester on Tuesday to meet Dave, our new DevOps Engineer, as well as help coach one of our teams around ‘Product’ thinking with one of our larger IT projects at the minute. Looking forward to some different types of challenges there, and how we can start growing that product management capability.

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