Softwire Blog


6 Key Factors for Successful Sprint Planning


24 March 2017, by

elena-prokofyeva-17909 50

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?

 

Plan conservatively

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.

 

Eliminate unknowns

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.

 

And finally

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.

 

By Helen Hosein, Softwire UK

 

 

Building on the global changes of 2016?


9 January 2017, by

2016 is being commonly touted as the “worst year ever“, with people referencing the high number of artist deaths and the close political results of Brexit and the US election between increasingly polarised sides. Not everyone shares this view of course, and it has prompted some retaliatory positive news pieces you can read one here .

Whichever side of the political divide you are on, decisions taken in 2016 look to set us up for big changes in 2017 and beyond.  Sorting out the finer details of Brexit, let alone assessing the impact, will be years in the making.

The pace of change has been accelerating over the recent decades, with new business and technologies coming and going at an incredible pace. Over the last few months alone, Vine is out, Snapspecs are in and Pokemon Go proved to be an instant hit across the globe.

Change means the end of certain things that we love and it means opportunity. Opportunity in your market, opportunity in training and leveraging your employees and opportunity in connecting with your clients. Technology is the foundation of all of this change. In 2016, we helped the BBC to bring coverage of Glastonbury and other events to the public as an interactive experience, we helped David Lloyd Leisure to win an award for their new mobile booking application and we started working with a leading bank to help them transform how they develop technology. You can read about them here.

An increase in change means an increase in the ways that we can help people to innovate and drive their businesses in 2017. And beyond.

Blog Picture

Tips for managing technical people – How to both learn and deliver


25 April 2016, by

Galvanizing the geeksThe following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.

Being able to learn is a key part of being happy. It is also widely cited as a good reason to take a job – books such as the cheesily named The Start-up Of You by LinkedIn founder Reid Hoffman advise you to consider how much you will learn as a key criterion in deciding whether or not to take a job. My favourite maxim (probably because it involves a rhyme, as all good maxims do) is from Never Eat Alone by Keith Ferrazzi: ‘Learn in your twenties, earn in your thirties’.

(more…)

Tips for managing technical people – Embrace Failure


25 April 2016, by

Galvanizing the geeksThe following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.

Whatever we do, whether it’s software development, building cars or policing a city, we are all trying to do it well. We are all trying to succeed. We set our sights on the end point, and aim towards it. We do everything in our power to avoid failure. We carefully manage a list of risks so we can deal with the unexpected and stop it from throwing us off course.

Some organisations go further. You’ll have heard the expression ‘failure is not an option’. This seems like a reasonable way to go about business, surely?

(more…)

Softwire Comedy Night 2016


24 March 2016, by

pieLast week Softwire held another of their amazing charity comedy nights, to raise money for Mind and it was a resounding success. We had five of our own Softwire employees trying their hands at comedy, which saw everyone having a laugh with plenty of terrible in jokes. This was followed by sketches and stand-up from four amazing comedians – Hari Sriskantha, Ian Smith, Amir Khoshsokhan and Nico Yearwood – who put on a hell of a show. Softwire resident comedian Hari Sriskantha also kindly compered the evening.
The rest of the night involved silly balloon popping games and a best joke competition, for which the prize was pieing one of our three beloved morale officers. Although our staff were given the option of two prior morale offices Jamie and Gergana and our current standing officer Laura, there was a surprise nomination and Gareth our old morale officer ended up taking a double pie to the face. All silliness aside we actually managed to raise £1011 for Mind, which was a great effort from everyone involved. You can see how happy Gareth was about being pied and watch all of the pieing action here.

Work Experience at Softwire


23 March 2016, by

Over the last two weeks, we have welcomed work experience student, 15 year-old Ruby Kimber from Stoke Newington School. She spent time with the Sales and Marketing team and the Admin team. Here she writes about her first steps into an office environment. 

During my time at Softwire, I have met many new people, learnt a lot about the company and learnt about what it’s like to work in an office for the first time. Everyone was very nice and friendly when I first came and I became more and more comfortable each day with the people I was working with and the environment. Each day I had something new to do and I always had something to challenge myself with and people surrounding me were always willing to help.

Softwire is a really nice, fun and exciting company where everybody knows each other and gets along well. I got a lot of freedom and everybody wanted what was best for me and helped me to learn new things. Most days I was with the sales and marketing team, doing something at my desk, for example, turning a case study into shorter bullet points to be used in PowerPoint presentations. Both Thursdays I worked with the admin team, answering the phone and creating spreadsheets for new ideas – learning new and different skills.

I always had something interesting to be getting on with and you can always have fun whilst doing so. I had my own desk and laptop where I could get on with my tasks in the relaxed environment and it was easy to settle in with everybody around me being so helpful and friendly. Of course, another great thing about Softwire is all the food and the kitchen staff who make delicious lunches every day.

I also explored Softwire’s Discourse forum where employees can chat about various issues, some work related, some not so much. I also learnt new skills such as making spreadsheets, creating email layouts and I even tweeted on Softwire’s Twitter page! There are two sides to the company; the one where everybody works really hard and is very focused on their jobs and the other playing table tennis and having fun, and I think the balance is just right. Thanks to everyone here at Softwire for making my experience here such a good one!

Softwire Side Projects: Build Focus


16 March 2016, by

At Softwire we have lots of people with interesting side projects, for all sorts of reasons. Sometimes you want a playground to learn strange and wonderful new things, perhaps you’d like to try out some unusual tech we can’t easily use day to day, and often it just feels good to test yourself with fun new kinds of problems.

In this post, I want to look at a side project I’ve released recently: Build Focus, a productivity tool I’ve built to help you improve your focus and avoid all the distactions and demands for your attention that the internet creates.

The Build Focus website

The Internet is a Distraction

A lot of the internet is actively designed to steal your attention and time. Twitter, Facebook, most news sites, and every app you use are doing all they can to keep you engaged, so you habitually and instinctively spend your time and energy with them, instead of doing whatever you really want to be doing (like getting things done). There’s a whole range of techniques behind this, particularly drawing from the tricks that make slot machines so addictive to help make apps like Farmville as compelling as possible and to lead you towards habitually constantly checking Facebook.

All of this is a bit concerning, and the effects and problems it creates have been debated and discussed all over the place. I’d like to find a solution to this, and I’m particularly interested in whether it’s possible to use the same techniques that these sites use to distract you, but flip them around, to reward you for concentrating rather than getting distracted, and thereby addict you to focusing and getting things done.

Gamification for Good

Enter Build Focus. Build Focus is a city simulator (because building city simulators is fun), wrapped around a pomodoro timer. If you focus for 25 minutes then your city will expand or upgrade, but if you get distracted during that time (by opening Facebook, or any other distracting URL you’ve added) a random building is destroyed. It’s essentially gamified concentration.

It’s also remarkably effective; I’ve been using this myself for months, and found it impressively good at molding my day-to-day habits, and I’ve also got a few hundred early users, of whom 20 or so use Build Focus almost every single day.

This is a free Chrome extension (a strange and wonderful environment I’d never normally work in), it’s written in TypeScript (as a chance to build a whole project with a language a little outside the norm), and opens a huge range of interesting problems I haven’t looked at before: from simulating realistic traffic, to doing my own product marketing. It’s neatly ticking off everything I look for in a side project, and I’d highly recommend finding similar projects and challenges yourself.

For now Build Focus is still in private alpha, so if you want to give it a go you’ll need to sign up for early access at www.buildfocus.io. I’m iterating on user feedback to steadily improve the design though, and I’m aiming to have it publically available to the whole world in the next few months. Watch this space!

Are you interested in playing with different solutions to problems like this too? Do you have your own side projects? Send us yours on Twitter, or leave a comment below.

Tips for managing technical people – There is never a substitute for using your brain.


9 March 2016, by

Galvanizing the geeksThe following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.

In most organisations, when there is a problem with quality or productivity, the answer is to introduce a new process. Too many faults in your widget output? Introduce a quality check or refine the widget-head-putting-on steps. Customers not buying enough? Give your checkout staff an upsell script.

I‘m not saying that there isn’t a place for process in software development. For any mechanical steps, such as those required to make a software release, process – or better still, automation – is essential. But process can’t help with the basic process of software creation.

The reason for this is very simple, and apparent to anyone who has ever done the job (if you’re not technical yourself, your team will find it bizarre that you don’t understand this). For all that we are working with logical, rational, calculating machines, the process of controlling those machines is a creative endeavour. Trying to do it by rote is like trying to paint a picture by rote. You’ll get an outcome, probably much more quickly than you otherwise would, but it quite simply won’t be very good.

The processes that do exist tend to be aimed at keeping arduous administration away from the developers, and allowing them to get ‘into the zone’ – a place where their creativity can be unleashed.

The problems that software developers have to solve are not mundane or routine. There are almost always dozens of different ways of approaching the same problem, and the subtleties of the situation will mean that a solution that may be the correct approach to take in one case could be disastrously wrong in another. So, while you should make sure your developers are aware of best-practice approaches such as dependency injection, you shouldn’t be trying to get them to apply them formulaically.

As a developer, some of the least constructive conversations that I’ve had have been those in which I’ve been trying to discuss what approach to take with someone who’s following a rulebook. One of my colleagues, working on a client site, was terrified of explaining the correct way to do something to the client’s tech lead – open debate wasn’t welcome, and if he didn’t give the answer that fitted with the tech lead’s learned architecture patterns he’d be accused of insubordination. The project that they were working on is now three years behind schedule, and still hasn’t been released.

We’re 14th Best Small Company to work for!


25 February 2016, by

Softwire are pleased to announce that for the 6th year running we’ve placed in the top 25 on the Sunday Times’ Best Small Companies to Work for list. Having surveyed all of our wonderful staff about what it’s like to work at Softwire we came in the 14th this year, placing even higher than last year.

Softwire have always aimed to create a great place to work, this is all part of showing our staff that they are valued and giving them the room to grow and flourish in their careers. We’re very proud of this, so we thought we’d share just some of the reasons why it’s so great working here;

‘I like working at Softwire because of the culture. Being surrounded by motivated people who are keen to write good code, deliver good results, help each other out and have fun doing so makes Softwire a fantastic place to work.’
Rob P – Developer

‘I like the fact that I can count my colleagues as friends, that I’m trusted to do my work without someone peering over my shoulder constantly and that my boss actually cares about my wellbeing.’
Ellie – Office Manager

‘I like being pushed to be the best that I can. There are lots of opportunities to try new and challenging things but with people who will support you if you get out of your depth. I get lots of head-hunters approach me through LinkedIn and they can never seem to understand that I value the company atmosphere more than a 6 figure salary. I really like it here, and I’m paid well, so why would I leave?’ 
Chris A – Developer

‘I love the opportunity to work on interesting, challenging problems that I haven’t already solved many times before. I like working with people who are real experts. I like the trust that lets me accomplish things in a way that works for me, including the lack of clock-watching.’ 
Alex W – Head of Project Delivery

‘I think primarily because my contribution is respected – I’m rewarded for good work and given help to do better when I’m finding things tricky. Managers here both listen and take action to change things when they need changing.’ 
Jenny – Tester

So as you can see there are plenty of reasons why we’ve placed 14th and we’re very chuffed, but that’s not the most important thing here we’re most happy that our staff are happy. The happier they are, the longer we get to keep them and see them flourish!

 

Software Development. Where do you even start?


21 January 2016, by

Kicking off a new project can be challenging. There are lots of options to consider and often many obstacles to overcome. With years of experience delivering successful projects under our belts, we asked our developers what steps they believe people should be taking before they start a project. They had all sorts of ideas to share but the three main points which came up were; think hard about what you want, plan ahead and work with your developers. So what did they mean?

Think hard about what you want!
Getting your requirements together is a hugely important step towards starting a successful project, so it’s important to get this early step right;

  • Try and define requirements primarily in terms of business needs.
    o  The fine details of implementation are best fleshed out later in the process, in collaboration with your designers and developers.
  • Try not to make your requirements list too generic, unless it’s strictly necessary. Often very simple sounding requirements like ‘users can define their own reports’ can be very complex to implement and may not be needed.
  • Don’t be constrained by any existing solution! Now is the time to think differently and perhaps the best solution involves a whole new approach. By focussing primarily on your business goals you give the developers room to translate them into the concrete implementation ideas which will suit you best.
  • Prioritise ruthlessly – for each feature ask “if the whole system was ready to launch tomorrow but this wasn’t there, would I delay launching to add this in?”
  • Make sure you understand what your users really want – particularly if your users are customers outside your organisation.
    o Note that what they actually want might not be the same as what they say they want – if possible get some hard data from tracking usage or watching how they work.
    o And try to avoid “design by committee” – understanding a variety of viewpoints is valuable, but ultimately just one or two people should be responsible for pulling things together in a coherent way.

Plan ahead!
It would be nice to live in a world where all projects could be approached footloose and fancy free, but sometimes it pays to be cautious to give your project the best chance of being a success;

  • Allow some slack in your timelines and budgets. Things often change over the course of the project and giving yourself some extra room for these changes gives your project a greater chance of success.
  • Try and favour incremental approaches wherever you can. Releasing partial solutions early so that users have a chance to test them and give feedback, gives you a chance to creat the best solution possible.
  • If you’re replacing a system it can also be useful to have a period during which the old and the new system are running at the same time. This can help flag up any tiny details you may have missed and it also give people a chance to transition.
  • If you’re doing a big marketing launch, plan to run the system for a short while before making any announcements so that it’s been tested by real users.

Work with your developers.
When it comes down to it, it’s your developers who are going to be responsible for the delivery of a successful project. Involving your developers from the early stages is important;

  • Whether it’s in-house or third party you should consider getting some expert help define your requirements. Your developers will be able to help you identify the things which really matter and eliminate risks early on in the process.
  • Get some help with design and UX and don’t leave it until last. The quality of the visual design and ease of use can have a massive impact on user engagement when you launch. You might want to consider commissioning user workshops with a UX professional to map out the most engaging journey.
  • If you’re inviting proposals you’ll get much more satisfying results if you help the developers to do a good job. Give them as much relevant information to work with as possible and tell then what matters to you most, so that they can focus on it when responding.
  • Stay engaged once your project starts. The best results come from projects where there’s a contant flow of ideas and discussion over the course of the project between developers and customers/product owners.