10 May 2017, by Helen Hosein
The technology industry is notoriously bad at embracing diversity. Almost everyone acknowledges the problem, but a lot of folks don’t know where to start. As a non-binary person of colour who’s worked in technology for their entire career, I’ve seen and experienced a lot of things that I think could be better. Here at Softwire, my colleagues often ask me what they can do to help. This is where allyship becomes important – to amplify our voices and help make the technology industry (and the world!) a more equal place.
Who can be an ally?
Anyone can be an ally! It doesn’t matter what your own background is, or how you identify. Even if you’re going through your own struggle, you can still be an ally to someone whose struggle may be slightly different than yours. If you don’t think that applies to you, that’s ok too – there’s no need to feel guilty about privilege. What we call privilege may just mean that there are more ways that you can help out.
A good ally isn’t a perfect human being either – we’re all flawed, and we all carry our own biases. Part of allyship is educating yourself and working to overcome yours.
What do I have to do?
I can’t speak for all marginalised folks (nor would I want to!) but here are three steps that I’d suggest to get you started.
Step 1: Talk to us
Ask your friends and colleagues what it’s like for them (understand, though, that sometimes talking about it is hard, so be patient). You may already have done some reading up, which is awesome, but don’t assume that you already know what your friend’s or colleague’s experience is like. Everyone’s experience is different. Your friend may have a very different experience from someone you’ve read about, or someone you’ve talked to in the past. The more you talk to us, and listen with humility and an open mind, the more you learn about us as individuals and as a group.
Step 2: Believe us
When you talk to us, some of what you hear may surprise you! It’s easy to imagine that our negative experiences are rare, not only because you may not experience them yourself, but also because you may not hear about them. For a person who feels marginalised, it can be embarrassing, or worse, frightening, to face the prospect of coming forward. In some cases, they may feel personally threatened.
Those who do speak out usually feel more comfortable doing so among other members of their group – they know these are people who will understand. If you’re not a member of that particular group, you may never get to hear those stories. That makes it all the more important, when someone does make the leap of faith to confide in you, that you believe everything they say. By believing them, you demonstrate that it’s safe to come talk to you about their experiences.
Step 3: Support us
Get involved! There are loads of ways to help support marginalised and underrepresented folks in the technology industry. You can lend your skills at events like codebar, support inclusive events like AlterConf or Diversity in Tech, sign the Minimum Viable Diversity Pledge, or do lots more stuff like those.
Don’t neglect the people you already know, as well. If you’re managing someone who may be from a marginalised group, check in on them. If there’s something they’ve asked for in your 1:1s, make sure you follow through.
Most of all, make sure you give us space to be heard, and back us up when we need it.
Remember that “ally” is not just a noun, it’s also a verb, so make sure you do the work to help out. This article is just a starting point; there are a lot more useful resources out there when you’re ready to take your journey as an ally further. The job is never done – there’s always more to learn, and more to do, so keep working at it!
24 March 2017, by Helen Hosein
Picture this: You’re leading a talented, cohesive, high-performing team of software engineers. They work as consistently and predictably as a beating heart. Every sprint planning, you pick the next eight stories off the top of your perfectly groomed, prioritised backlog, knowing that in two weeks’ time, those eight stories will be delivered in production, and your team will be ready for eight more. Sound familiar? No?
If you’ve yet to achieve ‘scrumvana’, then your team probably has a variable throughput. This is particularly likely if you’ve got a new team, or are setting up a new project. Until you’ve had time to settle into a cadence of delivery, it can be difficult to predict how much work your team can get through in a two-week sprint. So how do you plan? How many stories do you assign to a sprint if you don’t know whether you’ll get through two or ten?
Start by identifying a minimal nugget of work that your team can reasonably get through, based on your team’s capacity. Even your most pessimistic team members should agree, “If we can’t get through this by the end of the sprint, something is horribly wrong.” That will give you the best chance of delivering your plan, keeping your stakeholders happy, and leaving your team with a sense of accomplishment. It also gives you an early warning system: if you can’t deliver that minimum amount by the end of the sprint, something is horribly wrong. You’ve made some bad assumptions about the project, which you need to investigate and fix.
Far more likely, you’ll get through at least that minimal amount. So what do you do with the slack?
Set some stretch goals
When you identify your minimal nugget of work, you should also identify a few stretch goals for the team that will keep them busy if (or more likely, when) they’re done with their main goals for the sprint. Make sure it’s clear which stories (or other tasks) are stretch goals and which are the main goals – your overall project plan shouldn’t depend on getting your stretch goals done this sprint, and your stakeholders shouldn’t be counting on them. There should be absolutely no shame in carrying them over to the next sprint if they’re not done yet. Your team should also be aware that they’re lower priority than the main goals. Stretch goals are like dessert. You’re not allowed to touch them until you’ve finished your mains.
A lot of the variation in throughput at the start of a project is because there’s so much unknown. There are problems you don’t know how to solve yet – you may not even know whether or not they’ll be problems yet. Planning in spikes in your early sprints can shed light on those unknowns to make things more predictable. Use your early spikes to test your riskiest assumptions, and also to identify and solve the problems that could slow down your first few stories. With those answers in hand, you can increase your confidence that the next sprint’s worth of work will be appropriately sized and free of blockers.
Later in the project, there will naturally be fewer unknowns, so you won’t need to do as many spikes, but you should still plan them in where appropriate throughout your project to make sure the next batch of work is sufficiently well understood. Always plan a spike with a clear set of objectives – it should be answering a specific question that will then help to refine and break down an upcoming story. Remember to factor in the time your team will spend on spikes when you’re working out your capacity for story work.
Keep measuring and improving
At any phase of your project, you should always be on the lookout for ways to improve. It helps to focus on whatever is the biggest challenge the team is facing at that point in time. At the beginning, variable throughput may well be a big issue. To help you improve, you may want to use a Kanban board to visualise the flow of work so you can easily see where the bottlenecks are. Keeping an eye on cycle times and then investigating what’s slowing you down (or speeding you up!) can also lead to improvement. Use data to find the root causes of variation, and work with your team to address them. Make continuous improvement a habit, so when your throughput settles down, you can tackle the next challenge.
What about bugs?
If your throughput is not yet stable, your flow of bugs is unlikely to be stable either. That can make it hard to predict how much capacity you should allocate for bug fixing each sprint. Again, start by planning conservatively – assume the worst and make sure you have enough capacity to fix loads of bugs if needed. You can always fill the slack with stretch goals if there aren’t as many bugs to fix.
In the meantime, work towards building quality into your stories. Shorten your feedback loops by doing things like running an automated regression suite on each commit. Avoid writing bugs in the first place by conducting good code reviews, or using pair programming. Any bugs associated with a story should be fixed or avoided as part of the process of getting that story to done. Then, bug fixing won’t be a separate process you need to plan for – planning a story will inherently include bug fixing around it.
What about tech debt?
Just as you may need to devote some capacity within a sprint to spikes, you may also want to devote some to resolving tech debt. Remember to time-box any investigatory work, and adjust the output you expect from your team to account for the time they’ll spend on it. Tech debt tasks should be well-defined and broken down, just as you would stories, to help you maintain your cadence. Then you can schedule those tasks into your sprint the same way you would do with stories.
Capacity-based sprint planning can be a useful fallback to get things going when throughput is variable. Eventually your team will settle into a more predictable cadence, making it easy to plan based on throughput alone. Make sure you keep measuring and improving so that sources of variability don’t creep back in. That way, you can keep that rhythm of delivery beating for the life of the project.
17 August 2016, by Helen Hosein
One of the most important aspects of Project Management is being able to answer the question, “How is the project going?” Is it on schedule? Is it on budget? A very popular tool for keeping track is a Burnup Chart.
Every burnup chart has the same basic anatomy:
- The x-axis denotes time. Usually it’s measured in sprints, but it can be weeks or even days depending on how much granularity you need for reporting (and how frequently you can measure your progress).
- The y-axis is a metric of progress. In this example, the metric is story points completed which is a common choice but can be somewhat subjective. Other possibilities include number of stories completed, or amount of budget used. You can choose any metric you like as long as it’s a good representation of progress.
- The scope line (shown in black, and labelled “Scope (points)” in this example). This represents everything that needs to get done. In this case, it’s the total story point estimate for the whole project. If you’re measuring story count, it’s the total number of stories. If you’re measuring budget, it’s the maximum budget for the project. In this example the scope line is nice and flat, but in some cases, scope can change over the course of a project, so the scope line will change accordingly. This is one reason why burnup charts might be preferable to burndown charts – it’s easier to represent changes in scope.
- The burn line (shown in blue, and labelled “Story points” in this example). This is a cumulative plot of work done, according to our chosen metric. In a project that’s running to schedule, we expect the burn line to meet the scope line around (or ideally just before) the end of the project. The gradient of the burn line indicates velocity, or how fast we’re burning through work. Velocity can help project a rough end date for your project and is another useful indicator of how things are going. If your velocity is much lower than expected, there’s a good chance your project will be late. Also, if your velocity changes unexpectedly, it may indicate that something has happened that is worth investigating. Your burn line should be relatively smooth if things are going well.
Here are two projects with similar scopes and schedules but different velocities. Adding a trendline to the burn line makes it clear which is likely to be delivered early, and which is in danger of being late.
Another way to visualise this is with a target line. Here’s a project that ran pretty much exactly on schedule.
It’s normal for the burn line to wobble above and below target (staying perfectly on target would be a bit spooky – and may be a sign that your team is gaming the system), so a small wobble usually isn’t cause for concern.
One way to be sure is to add multiple target lines – one for the worst case (shown in dashed red, labelled “Pessimistic”), one for the best case (shown in dashed green, labelled “Optimistic”) and one for the average case (shown in dashed grey, just labelled “Target”).
Now we can see that once the project gained momentum, it stayed within our expectations, so we know that the wobbles in progress were definitely ok.
This other project, however, has been below the red line for all 8 sprints so far. Work is being completed, but the burnup shows that it’s not happening at the rate we would expect in order for the project to be delivered on time.
It looks like things might be improving: the trendline shows that at our current velocity, we should just about finish before the worst case end date, but it’s a pretty narrow margin and it assumes nothing else will go wrong.
Because we can visualise the project’s progress so clearly, we have the opportunity to take action before it’s too late. This project’s PM was able to intervene and turn things around. In the end, it finished ahead of schedule!
It’s easy to see the point at which effective changes were made to the project because the gradient of the burn line (the velocity) changed sharply. Burnup charts are also a great way to check whether the changes you make as a PM are having the effect you want.
Another handy use for burnup charts is keeping track of Work in Progress (WiP). If you’re familiar with Lean or Kanban, you’ll know that too much Work in Progress slows your project down, so it’s useful to be able to visualise how much WiP you have. The way to do this on a burnup chart is to plot a second burn line for work that’s in development. Just as the usual burn line shows cumulative work completed (using your metric of choice), the “In dev” line shows cumulative work in development or further, using the same metric. The distance between the two lines is your Work in Progress at that moment in time.
In this example, we can see that we had a lot of WiP in Sprint 6 (20 points!) which might have been slowing us down a bit. In Sprint 7, we picked up fewer stories and pushed more of the in-progress stories through the pipeline, which helped get velocity back on track. Here’s that project’s burnup again with target lines added.
One final tale of caution – Burnup charts are an excellent tool for visualising progress, but they’re only as good as the metrics you choose and your interpretation of them. Here are two burnup charts of the same project, one plotting story count and one plotting story points.
What’s going on here? Is the project running early or running late? Should you be worried?
What these charts are telling us is that, in Sprints 6 and 7 in particular, we got through a lot of stories but not a lot of story points. A look at the backlog shows that we completed a lot of smaller stories then, which gave us some quick wins. Does that mean we’re now ahead of schedule? Or are the remaining, larger stories going to bite us in the end, meaning we’re actually behind schedule?
Looking at the work remaining after Sprint 8, there are 3 small stories, 7 medium stories and 9 large ones. Large stories carry a lot of risk, so the project is starting to look precarious. At this point, it’s critical to remove any blockers and progress those large stories. In this case, the story points chart is probably a truer picture of what’s going on because it captures the risk associated with the size of the stories, and that’s where the trouble with this particular project lies. If you report the story count chart to your stakeholders, they may get their hopes up that the project will be early, and will actually be disappointed if it’s late. They also may not understand the urgency of unblocking the large stories if it looks like everything’s fine.
How did it end? The large stories were unblocked after Sprint 8, and things got better. Here are what those charts looked like at the end of the project.
The story points chart shows an increase in velocity when the large stories were unblocked. Things stayed pretty much on target after that.
The story count chart shows how the team got as much done as they could while they were blocked, but then ate through that buffer as they finished off the large stories. It shows that the rate of story completion was not sustainable, because of all the large stories still to be done.
Make sure that you choose the right metrics for your project so that the shape of your burnup chart is a true representation of its status. Then, use your burnup chart as a tool to help you identify when investigation and action are needed. Finally, use your burnup chart to verify the results.