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.

Weeknotes #04

Pull-based coaching

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

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

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

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

Portfolio Baby Steps

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

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

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

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

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

Manny on the Map

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

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

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

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

Class comedian — we know who you are :)

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

Next week

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

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

Weeknotes #03

Partner Up

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

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

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

Agile nerd alert 😍 😍 😍

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

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

Feedback, feedback and feedback

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

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

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

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

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

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

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

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

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

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

Training

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

The course is structured like so:

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

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

Next week

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

Weeknotes #02

Wroclaw (Vrohts-wahf)

As I mentioned in closing last week, I headed out to Wroclaw (pronounced Vrohts-wahf) to visit one of our suppliers this week.

Accompanied by Jon, Andy and Stuart we had 3 days of good discussion on Agile, DevOps, Product Management, UX, Data Science, Security and, what is fast becoming my favourite topic, anti-patterns. 

Whilst there was some really impressive stuff that we saw, mainly from a technical practices perspective, there were a number of anti-patterns identified in our *current* Agile ways of working, largely being imposed from within our own organisation. Sprint zero, gantt charts, change advisory boards (CABs) approving all deployments (even to low level environments), RAG status, the iron triangle as the measure of project success, changes in scope needing a change request to be raised — all got a mention. 

It’s clear that we still have a large amount of cultural debt to overcome. 

For anyone new to the concept of cultural debt, Chris Matts describes it well in that it commonly comes in two forms:

• Imposing Agile rather than allowing people to opt-in

• Focusing on Practices and Tools exclusively and ignoring the Principles and Values

As a team we are very strict in our interactions with individuals that training and/or coaching must be via pull rather than push (i.e. opt-in). 

However the second point is, I feel, much tougher. Plenty of teams are wanting to plough on ahead and get a kanban board setup, do daily stand-ups and retrospectives, etc. and, whilst this enthusiasm is great, the mindset and reason why we’re choosing to work in this way is often lost.

An outcome of our discussion was creating a supplier working group to work with our team, so we can share some of the approaches we’re taking to encouraging Agile ways of working, and how we can collaborate and support, sharing data/examples to drive continuous improvement rather than taking on the organisational challenges individually.

Less is more?

We also had the last couple days of our Sprint this week as a team. 

We like to work in 4-week sprints, as we find this is the right balance in cadence and as a feedback loop with stakeholders. From the end of Jan we went down to one less team member, so with five in our team I was interested see how our throughput was compared to previous sprints.

Our team throughput per sprint over the last 6 sprints

As you can see, this sprint we managed to complete more work items than in any sprint prior.

Upon review as a team, the general consensus was that we put this down to having run more training in this sprint compared to previous sprints (a training session is 1 PBI on our backlog) and that as we trained more people it spawned off more opportunities from a coaching standpoint. We’re going to stick with current team size going forward, mainly due to a good dynamic as a team and having a good variety of skillset.

Done column = 😍😍😍 (shoutout

Agile Stationary

for the stickies)

One thing we did try this sprint as an ‘experiment’ over this sprint was working with both physical and digital boards. It’s rare for us as a team to have a day where everyone is in the same office, so primary for us is a digital board. However we wanted people to also have the view of a physical board in our London office, mainly so they could see what we were working on and how a kanban board works in practice. Whilst we’ve not had loads of questions, general feedback seems to be positive and people like seeing it in action — we’re hoping it encourages others to experiment with physical and/or digital versions of their workflow.

TIL Python

One learning I have made this week is I’ve picked up a little bit of Python knowledge. One of my biggest frustrations with FlowViz has been how the Scatter Chart within Power BI cannot handle date values and can only use whole numbers in the X-axis, therefore needing a date string (i.e. 20190301) which of course, is then treated as a number rather than a date (so 20,190,301) leading to a rather bizarre looking scatter plot.

And the award for most useless Scatter Chart goes to…

However this week Microsoft announced that python visuals are now available in the web service and hence, I could ‘code’ my own python chart to display the scatter chart how I really wanted it to be.

After some browsing of the web (read: Stack Overflow) I managed to get a scatter chart working with my dataset. However I needed the brilliance of Tim in our Data Science team to help get the dates working how they should be (checkout his Tableau public profile btw), as well as clean up the axis and add my percentile line. It’s not *done done* yet as it needs a label for the percentile line but I’m pretty pleased with how it is now looking.

Much better (thanks Tim!)

Next Week

Next week I’m running what I hope will be the polished version of our Hands on with Azure DevOps course for a group of 20 in Consulting. 

I’ll also be learning about Google Analytics, as we launch our Partner Up initiative where senior staff pair up with someone junior who then demos and coaches the more senior person about a new tool/technology, all in the spirit of creating a learning organisation — looking forward to sharing my own learnings with you all next week.