Context is king

I know the common phrase is “content is king”, but as far as Agile is concerned it’s context that is key.

When a team starts a new initiative, it’s important that they understand who it is for, why it is important, what value is it expected to provide, what problem(s) will it solve, etc. Without this context, the team can’t be expected to know if they are building the right thing – all they can do is follow the Product Owner’s direction.

As much as we look to the PO to represent the stakeholders’ needs, the development team need to understand the bigger picture: how does this feature fit into the product? With a wider context, the team can think about a general technical direction, bearing in mind things will change and the project might end before finishing the whole thing (hopefully because the customers are happy rather than running out of time/money).

The team can also identify risks, dependencies and unknowns – not all of them, of course, because there will always be discoveries as they dig deeper. They can create spikes, run experiments, build a proof of concept, and/or change the prioritisation of the backlog in order to reduce those concerns. This is a big difference from my experience of waterfall projects where the project manager would fill in the risk assessment sheet and file it away.

Tackling the high-risk issues early can improve the confidence in the rest of the backlog, or (in at least one project I can recall) result in the project being canned because it would be too expensive to resolve a showstopper… and this is a good thing! It’s far better than we identified the risk and investigated our options, so that the PO could make an informed decision whether to proceed. The alternative is to plough time and effort into the project and only think about the problem when we couldn’t ignore it any longer – that would have been a huge waste.

So how do we help the teams gain the context they need? I find Jeff Patton’s Story Mapping incredibly useful – the template I use is slightly different to Jeff’s because I really want the initial conversation to focus on the who and why pieces. The “Frame the problem” section is important in Jeff’s approach too, but I find the addition of specific sections in the template reminds the team (and the facilitator!) that we need to spend time really discussing and understanding this context.

I find teams often want to jump to the details, the minutiae, the weeds – junior developers tend to be detail-oriented, so it’s important to repeatedly bring them back to the bigger picture. An experienced software engineer knows that the technical details are important but so are other things: are we building the right thing (e.g. does it address the problem? does it provide value?) as well as are we building it right (e.g. is our testing strategy solid? is our architecture evolving?).

Context is important throughout: in Refinement and Planning, we should set goals that move us towards the initiative’s objective; during the sprint, keeping the context in mind helps ensure we build what’s needed, not necessarily something because that’s what’s written in a user story; and then the Sprint Review should use the initiative’s context as the frame for understanding progress and any impact on the product backlog. Refer to it early & often. If we were in a team room, big posters of business and technical context FTW! (Jim Benson did a great presentation on this in the Agile Virtual Summit recently, but I’ll come back to this in another post.)

Scaling Up

If some is good, then surely more is better? Companies want to expand, and frequently the assumption is that just adding more people will result in successfully growing the organisation. Then, when they realise that’s not working, they decide that what’s needed is more process.

Fortunately, there are frameworks which you can install to fix all your problems; just invest in SAFe training and consultants, then follow their prescriptive framework, and magically you’ll be back to a command and control organisation in no time. Whoops!

It’s quite telling that the “Agile Teams” image is tucked away down in the bottom left corner; the majority of the people in the company are reduced to that little graphic. Meanwhile at the top of that hierarchy are Epic Owners and Enterprise Architect; I wonder at what stage of designing the framework they remembered to remove the picture of a waterfall. You also have to look pretty closely to find a mention of the customer.

I’m not saying there is nothing of value in SAFe – in fact it covers so much that there’s bound to be something useful for everyone! But most of the valuable pieces can be found outside SAFe, e.g. Scrum, Kanban, continuous delivery, DevOps – the key thing is to be selective.

Rather than painting SAFe across the organisation, recognise that each org is different and therefore has different challenges, but also that within an organisation there are departments, groups, and teams with their own circumstances. They should all be working towards the same goals, and following the same principles, but the implementation details within each unit are going to differ… and they will change over time.

And therein lies the challenge: if each team is different, then they need to find their own path… but that is time-consuming and expensive. The temptation is to enforce standardisation, which simplifies the thinking (not necessarily the problem!) and assumes that the same solution can be applied across multiple teams. This should make you shout “slippery slope” because it’s the path back to factory-thinking and turning everyone into widget makers.

The teams are building different things because they are solving different business problems, and with different people in the teams they will have different approaches to creating those solutions. If those differences don’t exist (a) you should probably look at your hiring practices, and (b) your staff might be about to be replaced by robots (or a very small shell script).

So does that mean there’s no easy way to scale up? I don’t think there’s an easy way, but there are things that can help… and it’s similar to how we help teams tackle feature delivery. It starts by understanding the problems you’re trying to address, then breaking them down into manageable chunks, minimising dependencies and risks, and using frequent feedback loops to check you’re heading in the right direction.

You probably don’t need to scale up equally across the organisation – some parts warrant adding more people, e.g. if there’s a promising new business sector. But reducing the impediments that a group faces could also help their growth, and dependencies between teams is one of the biggest obstacles they face. In the same way that developers try to have clean interfaces between services, teams should be clear on their responsibilities and their backlog should reflect that.

Work with the team to identify the challenges; an exercise like Circles and Soup can help identify where the team cannot address the issues on their own – these are slowing progress, so focus on reducing or removing them and that will help your team grow.

If you add people to a team that’s not addressing its impediments, then you just end up with more people struggling with those impediments. Make the teams independent and autonomous; focus on continuous improvement; address the issues which impede the system, and you may not need to scale up!

When I say resources, I mean resources

It shouldn’t need to be said, but unfortunately there are still people who refer to others (usually subordinate staff) as resources. As we become more aware of potentially offensive or harmful language and make efforts to change the words we use, I hope resources will appear on the list of inappropriate terms.

I still wear my #PeopleWorkHere T-shirt from This Agile Life as a visual reminder.

I think the second image comes from Mike Cohn (Mountain Goat Software) but I can’t find it.

But on to the real topic: where to find reliable agile-related information? The benefit of the internet is having access to so many resources, but the downside is that anyone can post their (mis)understanding – it’s important to check that the author has relevant, practical experience.

Personally, I find podcasts a great way to learn about new techniques etc. I tend to play them at 1.25x (or sometimes 1.5x) speed because I follow a lot of podcasts (across many topics) and at that speed I can just about keep up with the influx of new episodes 🙂

Unfortunately some of my favourites haven’t released anything in a year or more, so my currently-active favs are:

Similarly, I have a backlog of webinars and books. I don’t follow any agile-related YouTube channels; I tend to come across videos via email (mailing lists), websites, slack, and the infamous YouTube rabbit hole, and then I add them to my bookmarks to watch later. If there are some good channels that you would recommend, please leave a comment.

Update: I checked and actually I do subscribe to a few YT feeds:

OK, that’s a longer list than I expected!

Ultimately, I think it’s about finding a format (or formats) that works for you and then identify some reliable authors. But it’s not just about absorbing information – it’s useful to discuss concepts and challenges, and (as the saying goes) the best way to understand a topic is to explain it to someone else. Meetup groups (albeit online at the moment) and twitter (I have an agile list of people I follow) are good, but the one I find most useful is my team’s coaching circle: a weekly opportunity for us to discuss our challenges, discoveries, experiments, and questions. Rather than squeeze this in at the end of a long post, I’ll write a separate entry about how this format works and the type of things we discuss.

Developer or Engineer

When I graduated (many years ago!) my first job was as a Developer. I was one of about 90 developers on a multi-year project (I think it was in its third year when I joined) and my role required me to churn out code according to the detailed design specification. Follow the design, turn it into C code, make sure it compiled and passed some basic tests then throw it over the wall to the QA team. You won’t be surprised to hear that the project was not a success. In fact, when the company was sold about four years later the new owners discovered two other very similar projects had been underway for about the same time, and none were close to done.

Rather than point out how things could have been far better if they had used an Agile approach, I want to explore how the role of the Developer has changed. Even though we may still use the term these days, the expectations of a Developer have grown significantly. Writing code is just part of the job; as a Software Engineer, the expectation is no longer that of an individual following a design doc and converting it into code then handing it off to the next group in the chain. I’ve seen many argue (and I would agree) that coding is the least challenging part because it’s often what comes naturally as well as being the focus of most training.

Coding is still important, of course, but it’s not where most Engineers need help. Engineers are expected to participate right across the software development lifecycle. They need to be able to talk to their customer and understand the business needs; this used to be the Business Analysts’ role, who would spend a long time learning the domain’s terminology and nuances. They need to take that understanding and merge it with their knowledge of the system; this may require thinking like an Architect, to see not only how to get from where we are to what’s needed to address this particular problem but also to consider how that could impact aspects of the wider system, and even whether that direction is in line with the organisation’s overall technical strategy.

Now they need to implement that design, ideally writing tests first but if not then at least developing tests whilst creating the code. Producing small, testable, incremental steps towards solving the problem; don’t forget to check in with your customer to demonstrate the work in progress and get feedback as often as possible. With the move to DevOps, it’s now also the Engineer’s responsibility to push that code into Production and monitor it so that any adverse events are handled as quickly as possible so as to minimise business impact.

There are probably a lot of things I’ve not included (I know I didn’t mention documentation, UI/UX design, or the many flavours of testing) but my point is that a Developer used to be able to focus on a small step in that process and become an expert in particular languages or techniques; now we expect Software Engineers to be highly competent across a diverse range of skills.

One of the benefits of working in teams is that an individual doesn’t have to be an expert in all those skills – the cross-functional team should contain Engineers with a variety of backgrounds so that the sum of their knowledge covers all the needed areas; diversity of experience, knowledge and interests. We don’t want a team made up of a Business Analyst, an Architect, some Developers, and a QA tester or two – that would just be a mini-waterfall team and would lead to the same flawed processes that I encountered way back when I was starting out.

What we want is a team with at least someone with strong BA skills, someone with design/architecture experiences, and most if not all the team to have an appreciation for testing. And then we want the team to share that knowledge; it’s unlikely all the team members will become experts in all the areas, but they should have enough knowledge so that they can continue to function if a particular domain expert is away for a couple of weeks. We want the team to learn from each other, but that takes time and practice so we should be building that into the expectations of the team, and that means including it when the team is asked to estimate work.

If we expect a team to strive for continuous improvement (in their knowledge, practices, and all aspects of their work) then we need to ensure there’s support to do that. If we constantly focus on delivery or tell a team that they have to hit a deadline, then learning & growth are among the first things that are sacrificed. If leadership doesn’t lead by example and show that they value kaizen and education, then don’t be surprised when the team stops making time to grow.

The role of a software engineer is broad and complex; we need to ensure that we nurture that growth or we’ll revert to having silos of specialists who don’t collaborate, and we’ll wonder why we’re producing poor quality solutions.