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.

Weeknotes #12

Personal Development

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

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

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

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

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

Agile by default

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

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

What defines if something is ‘Agile’? 

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

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

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

Technical Excellence

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

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

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

As General Stan McChrystal says, take away the excuses:

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

Next week

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

Weeknotes #11

The Power of Questions

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

The Coaching Habit

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

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

Training

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

And the anti-pattern award goes to…

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

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

Next Week

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

Weeknotes #08

Leading SAFe

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

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

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

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

Over the daunting image that greets most:

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

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

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

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

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

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

Making Work Visible

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

Thanks to

Sam

for the string/twine suggestion and

Agile Stationary

for the printed backlog!

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

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

Next week

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

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

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

Weeknotes #07

Port’flow’io backlog

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

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

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

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

Our portfolio kanban board has a flow of:

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

I provided some guidance as to questions to ask upstream:

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

OK, OK, OKRs

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

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

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

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

Escaping The Build Trap

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

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

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

Next week

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

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

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

Weeknotes #06

Measure what matters

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

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

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

Slowly, slowly catchy monkey

Shameless plug

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

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

Sprint Reviews

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

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

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

Next week

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

Weeknotes #05

DXB

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

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

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

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

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

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

My favourite being this:

😊 😊 😊

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

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

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

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

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

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

Making Work Visible

LLKD19

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

Pawel Brodzinski — Power as privilege

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

Olga Heismann — Forecasting in complex systems

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

Dan Vacanti — Don’t be a ditka

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

Source — 

Twitter

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

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

Next week

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

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