Weeknotes #20 - Project to Product & Goal Setting

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 & The Power of the Network

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 - Agile Assurance & The Dip

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

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 & Recognition

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, Estimation & Organisational Agility

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.