Running Distributed PIs, ARTs & Teams

Context: I’m writing this blog post during the COVID-19 outbreak. The UK government (along with many governments around the world) have instructed people to work from home where possible. This is unprecedented and has forced many teams to change their way of working over-night.

As I have discussed before, I’m a Certified SAFe Agilst and work with teams and teams of teams to facilitate Scaled Agile delivery. PI Planning is a great way of helping teams to plan and give stakeholders visibility to what the teams have committed to, but what happens when nobody is in the office and everyone is dispersed?

The Podcast

This post was inspired by a really timely podcast. Many of the ideas and insights in this post are inspired by the podcast and the subsequent conversations I’ve had with colleagues and customers about it. I’d recommend giving it a listen if you’re considering running your first dispersed PI events.

DEEP DIVE: Running Remote PIs, ARTs and Teams – SAFe Business Agility Podcast

SAFe Business Agility Podcast

Distributed Vs. Dispersed

Firstly, there is nothing new about doing remote or distributed PI Planning. While SAFe do encourage PI Planning sessions to run with all the participants in the same room, it’s common for teams to be split geographically for a number of reasons and it’s not always possible to bring all the teams together.

In this case a ‘Distributed‘ team usually refers to a group that is split across two locations. This can often be where a company have engineers in Europe or India, for example, and bringing them to the same location can be difficult.

Unlike Distributed teams, ‘Dispersed‘ teams are all in different locations. This is the situation we find ourselves in during the COVID-19 lockdown in the UK.

I’ve tried to compare and contrast some of the differences between Distributed and Dispersed teams and the things that you might need to think about while running a PI event with them.

DistributedDispersed
1. Requires a facilitator in every room1. Requires a facilitator in every comms channel
2. Common for a teams in a different timezone may work late to stay connected
– Consider safe transportation late at night
– Consider food for the team late at night
2. Colleagues in different timezones may work late to stay connected
– Consider other people in their homes
– Consider food times (for families)
3. A technical issues may mean you loose 50% of your team (and you’ll notice)3. A technical issue may mean you loose 1% of your team (and don’t notice)

Up-front Planning

It’s not common in agile teams to advocate from much up-front planning, however, this is going to be the difference between your PI event being good and it being excellent.

As individuals are in different locations, timeszones and potentially in unfamiliar work-patterns, it’s important to try and be flexible around the format of the event and allow people to engage in their own way and at their own time.

These are my thoughts on ways to improve your distributed PI events and help your attendees get the most from (and contribute the most to) the event:

1. Plan your use of technology

Consider carefully your tech stack and what users may need to be able to use it. If everyone is working from home and has a different technology setup, there may be a need to understand what users have at their disposal before you mandate technology that could alienate some of your participants. A helpful list of things to do in advance could be:

  1. Communicate in advance the technology you are going to use
  2. Supply guidance to your teams on how to signup, do you want them to use corporate email addresses to make them easier to identify to administrators? How about using their corporate headshot as their avatar to make them easily recognisable to colleagues?
  3. If participants need to install plugins to make Webex or Zoom work, ensure that they have the time to do so and supply guidance. Some of your colleagues will need a bit of help to do this
  4. Ensure that the you test whatever you pick with a small group, but try to understand if there are any limitations to your chosen platform, if used at scale.

2. Consider adjusting your timings

A PI event has a full agenda that is difficult to fit into two days at the best of times. So think about your timings. If you know that you’ll struggle to retain your participants for a full morning of briefings, consider asking your Product Manager to pre-record their PI vision presentation and get this to your participants to watch in their own time, maybe 48hrs before the event.

Allow a channel for participants to record their questions and use your time together on the first morning to answer those questions, rather than watch the presentation live.

This gap gives the participants the opportunity to ask questions and allows the presenters the opportunity to think through their answers and supply updated material if needed.

Linear schedules may be difficulty for attendees with family and school-age children at home. Try to give suitable breaks and allow people to engage with content in their own time – maybe you’ll choose to leave your retro board live overnight to allow people to come back to it later in the evening after the kids have gone to bed.

3. Create a place to work for every team

Your teams need their own spaces to work, one per-team. They may already have an electronic board, but ensure everyone has access and can see it.

Consider how the teams can chat amongst themselves and how they’ll collaborate in the feature elaboration effort. One thing a team could do is update their leave before the event on a team calendar – helping the Scrum Master to plan for capacity before the event has begun.

While it’s perfectly normal for people to have side-chats at these events, try and think of ways to keep people together where possible and workout how you’ll present your commitments back to the wider group.

Interactions and follow-ups

It’s understandable that many teams aren’t familiar in working this way. The situation could be stressful and all of the participants are likely to have distractions and worries, outside of the event.

It’s important to be mindful of the situation that we find ourselves in and take care no to unintentionally upset or offend people. Written text can often be interpreted differently to how it was first intended and so offer to follow-up with a colleague verbally if you think they have missunderstood.

If you’re struggling to contact a participant, be aware that they may have stepped away to get a coffee, take a call or look after a family member. Don’t bombard them with multiple messages, instead – ask them to contact you on their return. And if you as a participant want to step away, consider adjusting your status to allow others to know you’re not there and when they can expect you back.

Imagine the sorts of status you might see:

  • “Feeding the kids, be back at 1pm”
  • “Just nipped downstairs for a coffee, back in 5”
  • “On a call with a customer, trying to get some clarity”
  • “Taking the dog for a walk, be back soon!”

Delivery starts… soon!

Playback at a PI planning is very visual – it may take some time to produce the sorts of artefacts needed to get teams started and you might need to give a couple of days to people to get copies of all the agreed commitments.

Think about what might aid you in pulling this together. Should the Scrum Masters be sharing time-stamped screenshots of their Scrum boards at each scrum-of-scrums? Would this help give someone a head-start at putting a quick powerpoint together to aid playback? Knowing that this would be needed, could a deck be created before the event, with gaps for each teams boards and objectives to slot in?

Whatever you do, its important to not rush the start of the delivery cadence, until you’re confident that all participants have a clear set of objectives and know what they are doing.

Be agile and keep learning

Getting through your first dispersed PI event will be an incredible learning curve. Accept that not everything is going to be perfect and find ways to capture feedback and look for creative ways to achieve the outcomes you need, even if you have to do them very differently.

We might be working like this for some time to come, so you’ll have plenty of opportunity to practice and improve your skills at delivering PI events in this way!

Joining BAE Applied Intelligence

I’m really proud today to announce that I’ve joined BAE’s Applied Intelligence business as a Technical Consultant.

I’ve had some fantastic opportunities over the past couple of years working with Rayethon, from their Cyber Centre in Manchester – but the time has come to try something new and return to the sort of consultancy that I love.

I’m looking forward to getting started and meeting the team.

Becoming a SAFe Agilist

I had a great opportunity recently to attend the Leading SAFe course, led by Dan and Phil at Add Agility.

Here are some of my thoughts about the two-day course, where attendees gain the knowledge necessary to lead a Lean-Agile enterprise by leveraging the Scaled Agile Framework® (SAFe®) and its underlying principles derived from Lean, systems thinking, Agile development, product development flow, and DevOps.

I have been working in and leading agile teams for a number of years, but in more recent months I’ve worked with customers that have decided to adopt SAFe as their framework of choice for conducting multi-team planning.

The course outline states:

Participants in the class gain insights into mastering Business Agility in order to thrive in the competitive market. They discuss how to establish team and technical agility and organise and re-organize around the flow of value. They also learn and practice the skills for supporting and executing PI Planning events and coordinating multiple Agile Release Trains (ARTs). Participants in the class explore the importance of adopting a customer-centric mindset and design thinking approach to agile product delivery. Learners also develop an understanding for implementing a Lean Portfolio Management function in their enterprise.

ScaledAgile.com

Things I found:

  • The course is full on. There is a lot of material to cover (over 400 slides in 2 days) and so make sure you have coffee on tap!
  • A lot of the course content and principals come from other methodologies. If you have a good grounding in Scrum, XP, Lean etc you’ll do well.
  • The course seems to be traditionally based around synchronising releases. I think of this like how it must have been to release software versions onto CD-ROMs. If you ‘missed the train’ your feature wasn’t going to customers until they bough the next CD. SAFe have clearly tried to leverage DevOps and push towards more regular releases
  • Attending the course prepares individuals to take the exam and become a certified SAFe® Agilist (SA) – but not all the content is covered in the course. You should prepare to do some home study in order to complete the exam successfully.

Would I recommend it? Yes. If you’re interested in adding some governance around how you do agile at scale, this course could be really beneficial to you.

Modeling options: Getting the best return on investment

A few weeks ago I shared something with my friends and family on Facebook that got quite a reaction. It was an article entitled McDouble is ‘cheapest and most nutritious food in human history’ [1].

The originator of the claim, Stephen Dubner, who co-authored the best-selling book Freakonomics went on to say:

The double cheeseburger provides 390 calories, 23 grams of protein – half a daily serving – seven per cent of daily fibre, 19 grams of fat and 20 per cent of daily calcium, all for between $1 and $2, or 65p and £1.30.

Kyle Smith, a New York Post columnist, agreed:

“For the average poor person, it isn’t a great option to take a trip to the farmers market to puzzle over esoteric lefty-foodie codes”, Mr Smith wrote.

“Facts are facts – where else but McDonald’s can poor people obtain so many calories per dollar?”

It was a ridiculous claim, a controversial one at best and yet one that the data showed to be true. It got me thinking about what Return on Investment (ROI) and how we model it to help better decision making.

ROI measures the amount of return on an investment relative to the investment’s cost.

[2]

In the example above the McDouble returns the highest number of calories per dollar. To phrase it in a way that the ‘business’ might describe a potential solution, it “delivers the biggest bang for the buck”. http://idioms.thefreedictionary.com/bang+for+the+buck

As a Business Analyst I strongly believe that it’s my job to table options to my stakeholders and to back up the options with data, modelled in a way that helps them make informed decisions. I know many will find that difficult, stating that it’s not the role of the BA to provide solutions, but I’m not actually suggesting that here (although for the record I disagree – that’s a different blog post). What I’m suggesting here is that however ridiculous or unpalatable the solutions suggested are, it’s the role of the BA to model benefits and potential outputs to aid stakeholders in making a decision.

Lean tells us we should validate a hypothesis with the minimum amount of effort, this sounds like the “maximum amount of calories for the dollar to me”.

In Agile delivery we would say that an MVP can be defined as the least amount of work we can do to in/validate the hypothesis.

Modeling options is the the best way to ensure that you’re helping stakeholders make informed decisions (and gives them the ability to defend themselves when they get caught eating a burger!)

[1] Daniel Johnson. Jul 30, 2013. “McDouble is ‘cheapest and most nutritious food in human history'” [online]. The Telegraph
[2] 2014. “Return On Investment – ROI” [online]. investopedia.com

The Laterooms BA: A day in the life

Last week I was invited to chat to Vicki, one of the Laterooms Talent Managers, to talk about the role of the BA at Laterooms.com and what we get up to on a day-to-day basis.

It was a great opportunity to explain to her what it is we look for in great BAs at Laterooms to help her support some of the hiring we’re doing at the moment to grow our capability internally.

If you’re interested in finding out more about being a BA at Laterooms checkout my “Day in the life” post or have a look at our careers site for more info.


careers We’re hiring! at Laterooms.com
Click the link below to find out more information about who we are and how you can join the team.
LateRooms.com Jobs

IIBA UK Tour

One of the great things I get to do as the Principal Business Analyst at Laterooms.com is attend events and engaging with the BA community, promoting the great work that we do here and identifying quality people who share a passion for analysis and want to join our growing BA Practice.

I’m doing a bit of a tour of the country to attend some of the IIBA branch events and meet more of the community, learn some new skills and get inspired by some of the amazingly talented Business Analysts up and down the country.

If you’re about for any of the following events, come and find me and have a chat:


careers We’re hiring! at Laterooms.com
Click the link below to find out more information about who we are and how you can join the team.
LateRooms.com Jobs

BA Conference Europe: Going beyond what success looks like

Later on this month I’ll be attending Business Analyst Europe 2015 to present “Going Beyond ‘What Success Looks Like’ – Using Data to Achieve Successful Projects” with my colleague Joanne Latham.

We’re really excited for the opportunity to present and to represent Laterooms.com at such a great event. Previous years conferences have been critical in my development as a BA and I’m thrilled to be speaking there for the first time this year.

If you’re going to be attending, give me a shout!

Synopsis

Delivering value is at the heart of the Business Analyst role, but how easy is it to identify tangible value and prove the success of a project or program?

In agile projects we’ll often define a “definition of done” or ask the question “what does success look like”. At LateRooms.com, we’ve developed a toolkit for our Business Analysts to support the business in using data to define what success looks like, and track it throughout the project lifecycle.

This presentation will look at the ways LateRooms.com collects, analyses and uses data to better define the problem space, setup up KPI driven Critical Success Factors and present Benefits Realisation.

The session will cover:

  • Leveraging the most out of the data you already have
  • Setting up baselines and real-time KPI dashboards
  • Making better decisions from your data
  • Presenting Benefits Realisation in a way the business will understand

Presentation

[slideshare id=54838749&doc=iiba-presentation-linkedin-151106215935-lva1-app6891]

Going beyond ‘what success looks like’

#BASummit14: I was lucky enough to be asked to take part in this years BA Summit by Penny Pullan of Making Projects Work Ltd.

To hear my talk on this topic you check out my SoundCloud.

Over the past couple of years I have seen a growing trend in BAs and product teams striving to define what ‘success looks like’. It’s comes from a desire within the business to understand how we’ll know when we’ve achieved what we set out to do and what the world will look like at the finish line.

I think it’s worth recognising that there are probably a collection of terms out there that describe similar things here. You may call the, Critical Success Factors in your organisation and have associated KPIs.

If you’re working in a Scrum team you may refer to theses as the Definition of Done, a series of criteria or success factors that must be met in order for something to be considered as completed, as done.

The closest I could find in the BABOK about measuring success was in chapter 6.3 Specify and Model Requirements [1]:

The activity of analysing expressed stakeholder desires and/or the current state of the organization using a combination of textual statements, matrices, diagrams and formal models

I’m a real advocate of this approach and have found it resonates well with the product team I sit in, as together we defining a testable state in which to measure if we have achieved our intended goal. This is similar to the team’s approach in writing software, where they will write tests that fail, prior to writing a line of code. They then write software that passes the tests that were defined. Once all the tests pass the project is finished.

However, too often I think BA’s try and define success far too late in a projects life cycle and as a result, miss out on being able to show real business value early in the process.

Lean Statup

Many of you may have heard of Eric Ries and Lean Startup. You may have discredited it as applying to your organisation, as you’re not a startup, but I believe that everyone can use Lean Startup principles in their work, especially business analysts.

Eric discusses in his book, The Lean Startup, a new approach to testing hypothesis to help innovation. I believe we can use this same approach when identifying the impact of problems we uncover in our projects, whether it is a bug, an inefficient process or a missed deadline. And using the same principles we can continual measure for the improvements made as we get to work on tackling those issues.

Measuring failure, the “as is” state

So before we can measure what success looks like I encourage people to re-frame the problem. I ask them what failure looks like, often to their surprise. What I mean is, if we did nothing to resolve this issue what would the cost or impact top the business be. This may cause them to go and collect some information in order to answer this, but chances are they have a good idea and can articulate it.

This is a great place to start and will have many other benefits that can feed your product vision, and even help with ROI calculations further down the line.

Once you understand the problem or opportunity, you can start to consider solutions for achieving your goals, but how will we know that we’ve actually been successful?
If you work for a company that sells products online it may be easy for you to measure success. If you sell more items or increase your profit on what you sell, you’ve clearly been successful and perhaps these are some of the most obvious ways of measuring success and may not require models or equations to prove it.

However, if your project doesn’t have an obvious revenue stream to measure, you may need to be a little more creative with what you measure – and this I think, is where Business Analyst can really take a lead.

Have you ever considered the impact your project may have on customer satisfaction? Do you know what your current customer satisfaction score is and would you know how to measure it? Do you know where you rank amongst competitors, especially the ones that you are chasing for market share? I’m willing to bet someone in your organisation already knows the answer to all of those questions!

Do you know how long a manual process takes to run in your organisation? If you could identify improvements then you could calculate an efficiency saving to the business in terms of employee cost or an increase in productivity per employee.

Now measurement isn’t just something that we do at the end of projects. I often hear of the Definition of Done or the definition of what success looks like as being the finish line of a race that once crossed, means the project is closed. While this is true, I sort of dislike the analogy as it suggests it’s the last thing that happens in a project. I believe measuring success is a continuous process. if the definition of what success looks like is our finish line we measure at every step along the race course asking the question, have we crossed the line? Have we improved revenue, have we improved customer satisfaction? For teams that work on incremental delivery strategies, this data is crucial in checking that the team are going in the right direction and if they’re not this data will help support the need for changing direction or pivoting. This in itself is ensuring project success by getting early visibility of failure and risks.

Change, measure, change, measure…

So I’ve explained how I think measuring should take place at every step of the journey and how “what success looks like” is the finish line, the goal we’re aiming for. But in reality the improvements and gains that we see from the success of our projects don’t end once we cross that finish line. If you’ve managed to see an increase of 2% in sales as a result of your project, that’s for life. The business will continue to see that additional value month on month and as a BA I think it’s important that we shout about success and recognise the value that we as BA’s and the teams we support add to the organisation we live in. Everyone likes to have evidence they can show their boss that the project they’ve delivered was successful… And if it over achieved, how pleased will you be that you were tracking the data from day 1!

Conclusion

So to conclude I want to just recap on what I’ve said and recommend some further reading:

  1. Measuring success is linked right back to your initial requirements and stakeholder desires. You’re helping your team prove that they’ve been met with real data
  2. Measuring success is a continuous process, measuring it at the end is too late… you could be miles off and have not known
  3. Measuring success continuously reduces risk and allows for innovation and agility
  4. Evidence of success is the best reward of all, and will really help you as a BA
How to Measure Anything: Finding the Value of Intangibles in Business by Douglas Hubbard

For more on creative measuring check out Douglas Hubbard’s book.

[1] 2009. “IIBA BABOK V2.” [online]. iiba.org/babok

Senior Business Analyst: Laterooms.com

So I’ve not had chance to update my blog recently. A lot has changed in the months that I’ve been away…

laterooms_logoEarlier in October I took up a new and exciting role at Laterooms.com, the UK’s leading hotel booking company. It’s an exciting role for a number of reasons:

  • I’ll be joining a team of 10 other great BAs, so expect more posts and maybe even some collaborations
  • It allows be to focus on a single product, or at least a single organisation for a while
  • It’s based right here in Manchester, so I can balance work and home life a little better

The job move coincides with a house move too. Then family and I have moved to a larger house with plenty of room for the kids to grow up in. We’re still surrounded by boxes but as soon as we’re settled I’ll be blogging again.

Some blog posts coming up include:

  • Paper prototyping with the UX stencil
  • Writing effective User Stories for backend systems and APIs
  • Defining success and measuring business benefits
  • Decoupling UX from Development in Scrum

If anyone has any blog requests please let me know.

Thanks,
Jamie

Agile Estimating: What’s the point(s)?

Recently I gave a presentation on Agile Estimation, as based on some of the material cover in the course I attended. While I can not take credit for the materials, or the activities, I was keen to write about them as I believe my own perspective could be of benefit to others who find themselves in a similar situation.

Estimation is something that every team does, but approaches vary wildly. Commonly developers will estimate in hours based on their feel for how long a task or activity will take. While this is not terrible the individual doing the estimating makes a number of assumptions about their approach, their experiences of similar tasks, their confidence in finding a solution, the risk involved, etc. However, what if the person that has done the estimate isn’t the person who will complete the task? What if they aren’t aware of the assumptions made and are not able to understand how the estimate was so low or high?

In the session I asked the teams to estimate the distance from our office to Paris. Instantly they started working on understanding the distance, what roads they would need to take, a ferry or a train and if they would need to sleep on the way. Within a very small variance the teams were pretty consistent in the distance it was from our office to Paris. However, when they started to estimate the time required, based on their distance estimate, the hours varied based on speed assumptions, accounting for traffic and other variables.

What I was trying to show the team is that most of us are good at judging the complexity of a task. They were all good at determining the distance, the route and even the car they’d take and those that had driven the route before knew more confidently what the number of miles required to drive.

When teams decouple complexity estimates from duration estimates they are usually more accurate. Even for the guys that had driven to Paris before, the number of miles required to drive was not smaller in any way, the size or complexity of the task didn’t change for them.

Mike Cohn teaches that we should

Estimate size and derive duration

Mike Cohn

You see duration or velocity is something that a team understands best through practice. Once teams get into a rhythm or cadence they naturally start working more effectively. This will improve the speed that they are working at and the number of tasks that they can complete.

By estimating as a team (or at least in pairs) developers will at least get some peer input into if their estimates to help them check they are in the right sort of range. And through conversation and repeated estimates the teams should see an improved confidence in their estimate ranges.

Agile Estimating and Planning by Mike Cohn

For more on Agile Estimating & Planning check out Mike Cohn’s book. A must read for anyone who is moving into planning and managing agile projects for the first time. Mike packs the book full of helpful lessons learnt from over 20 years in the field.