James Shore is a very busy man. Currently writing the second edition of his book in the open, we were lucky to nab 30 minutes of his time to discuss all things delivery. Here the award-winning Agile expert, author and teacher talks through mistakes during estimation and planning and radical approaches to scaling.
Hi James! Thanks for meeting with me today. Tell me, what’s keeping you busy right now?
I am working on the second edition of my book The Art of Agile Development. It is taking up all my time so that’s my main focus. I have some consulting work that I’m doing, but mostly I’m focused on the book and getting it out. I’m actually having an open review, so when I finish chapters, I put them up online for people to read and respond to. I’ve been getting amazing feedback from a great panel of reviewers.
Sounds great! What are some of the biggest mistakes that you’ve seen in your experience, that engineering teams can make when estimating and roadmapping.
Oh, this is a whole can of worms! I would say that the mistake actually doesn’t come from engineering teams; it comes from managers who are asking for estimates because they’re using project-based budgeting. And that is a fairly deep mistake because it puts everybody in the vein of focusing on ‘What are we going to do?’ and ‘When it is going to be done?’
But that is assuming you can finish something exactly as requested and exactly on time and not have it be an absolute business failure. So the correct focus is product-based management where you’re saying: This is the money we’re spending every month, and this is the value we expect to receive every month. Where you’re comparing the two in that environment, you’re not estimating when something’s going to be done, you’re estimating what it’s going to do for you. And that is a very different type of conversation and it leads to much better results.
Good to know. So before starting a project what are your secrets for effective planning?
Well I’m an agile guy, so I’m very interested in a product-based approach, where we’re focusing on what value we are delivering over time.
So, the very first thing that any organisation needs to do when they form a team – or even before they form a team – is to have a fairly in-depth conversation with stakeholders about what value they are creating and why. The ‘why’ is it important? Only then do you have that conversation with your team and say: ‘Okay, this is the value we want to create what we want to achieve and in order for this to be worth the money we’re spending, this is what we need to achieve.’… ‘What input do you have for us about how to make this successful?’
Involve the team early on, because they are the people who will be doing the work and have the most information about how said work should be done. Just look for lots and lots of feedback, and don’t stop.
So, do you think that getting engineers connected to the ‘why’ of something is also beneficial for getting them invested in it?
You can’t commit anybody to anything, you can only force people to pretend to commit. People can only commit themselves so you have to create a compelling reason for them to do so.
Also in this day and age where engineers move around so freely and so easily because they’re in such high demand, it is more about inspiring and leading than committing people to something.
So if you want to get the engineering team on board with a goal, the way you do that is by genuinely connecting that goal to the things they care about. And that’s going to be different for every person. For some people it’s going to be: ‘I want to make something insanely great’ for others, it’s going to be: ‘I am really excited about working with this technology’. You need to be aware of those things as a manager, (less so as a CTO because that’s more what managers are doing with their teams). But as a CTO, what you need is you need to make sure that your team of managers is skilled in doing that, and also to make sure that your team of managers is really clear on the goals and the benefits that your company is getting and why that’s important.
Obviously, with everything going on globally at the moment, most teams are co-located or distributed in ways that they never were before. While you have been writing the book, have you heard about or can you envisage any problems with delivery as a result of that, or a change in peoples’ motivation, perhaps?
Well, the remote environment is obviously a big change for companies that weren’t previously focused on remote working.
I have been focusing primarily on the book so I haven’t been working with a lot of teams lately, so I can’t say how that’s changed. But when I talk to people I know in software development and the impact of the pandemic, we’re really fortunate that it’s a job that doesn’t have to be done in person.
So, while I don’t think it’s caused major problems, I do think that some organisations are handling it better than others. If you’re an environment where you’re command and control focused – where you have to know what everybody’s doing all the time – you’re going to really struggle in a remote environment. If, however, you’re in an environment that is more delegatory and really focused on creating a situation where people can succeed, then you’ll have more success.
That said, I do see organisations failing to take advantage; they are not realising that the environment is different and so the tooling needs to be different. So tools like Miro or Mural are really important, but I still see people trying to do everything through JIRA. Whiteboarding tools are really important for engineers. So, if you haven’t gotten everybody a tablet so they can log into your virtual whiteboard and sketch and have that always available, why not? It’s $200 to do it.
How do you scale delivery and planning as a team grows?
Oh, that is a huge question! There are three basic approaches that I see out there in the world.
First, there is the horizontal scaling approach where teams are limited to about five-to-eight people per team. Then, as you grow beyond that, what you need to do is add more teams. There’s an excellent book called Team Topologies that talks about how to do that well.
The second approach is the cross team ownership one, which is exemplified by the Large-Scale Scrum (LeSS) agile scaling framework where teams choose for themselves which pieces of the plan to focus on, rather than having very tightly defined specialties.
And thirdly there’s a radical, vertical approach called Fluid Scaling Technology for Agile (FAST), which I have not yet had the opportunity to use, but it’s about allowing a team to grow past that five-to-10 people. The person who invented it, Ron Quartel, got it up to 65 people on a single virtual team, and it’s a very innovative approach that involves lots of autonomy on the part of the engineers to work as a group, and also choose work to sort of peel off and working on using mob-programming.
So if I was working with an innovative company today that wanted to be on the bleeding edge, I would try FAST with them. If not, I would probably use the team topologist approach.
Great! And finally, what books would you recommend to delivery managers?
There’s definitely some books on my reading shelf that I’d recommend. One is called Agile Conversations by Douglas squirrel and Jeffrey Frederick; it’s a really good book and also appropriate for people in a management role.
The other book that I think is really interesting and valuable if you wanted to use a horizontal scaling technique would be the Team Topologies book I mentioned earlier by Matthew Skelton and Manuel Pais. I haven’t read it through, yet, but the parts of it that I have read, I thought were perfect.
Thank you, James!
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us here and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more.