Softwire Blog


The power of play at work


1 June 2017, by

HSL_2017_softwireDSC_9797_smallWhat if you worked in a place where you are not only allowed to play, but encouraged. It’s a trend that’s emerging in many organisations, especially amongst technology and start-up businesses. High profile examples include Google, Pixar and IDEO. More importantly, they instil a culture of play – not as a distraction from work, but as a benefit to it. For years the worlds of work and play have been seen as separate and distinct; that play is inferior and takes away from ‘real work.’ In fact, many of us have been taught to think of play in the work place as inappropriate and a waste of time.

What if play at work is really a benefit? Let’s be realistic. People get bored. People get distracted. People get frustrated. It happens! Whether it’s just the monotony of routine tasks that demand our attention, or the root of a thorny problem. What employers want is a more positive, energized problem solving workforce. Employees want to enjoy their work, and have permission to do it. Wouldn’t it be great if all employees were having fun while at work?

Helpguide.org in collaboration with Harvard Health Publications have said, “Success at work doesn’t depend on the amount of time you work; it depends upon the quality of your work. And the quality of your work is highly dependent on your well-being.

“Taking the time to replenish yourself through play is one of the best things you can do for your career. When the project you’re working on hits a serious glitch, take some time out to play and have a few laughs. Taking a pause for play does a lot more than take your mind off the problem. When you play, you engage the creative side of your brain and silence your “inner editor,” that psychological barrier that censors your thoughts and ideas. This can often help you see the problem in a new light and think up fresh, creative solutions.”[i]

Other research indicates that play can decrease stress and absenteeism. As employees make time to play, it lessens work related stress. This leads to less sickness absence. On the other side of the coin, it also leads to a more positive attitude and more energized work environment.

Allowing play in the workplace is good for business and employees. The opportunity to play shows employees they’re valued. Employees are therefore more likely to be engaged, collaborative, creative and focused. All better outcomes for the employer. A natural follow-on is that employees are likely to experience more job satisfaction. As Forbes reported, “Last year revenues increased by an average of 22.2 percent for the 2014 Fortune 100 Best Companies to Work For.”[ii]

Isn’t it about time your staff starting playing?

[i] https://www.helpguide.org/articles/emotional-health/benefits-of-play-for-adults.htm

[ii] https://www.forbes.com/sites/meghanbiro/2014/01/19/happy-employees-hefty-profits/#fa9903b221a8

Alexa is the new command line


19 May 2017, by

Alexa

In the beginning, man created the command line interface, and lo! There were commands that no-one could remember, and syntax designed by Satan himself.

 

User interface experts call this problem discoverability; given that you’re at a particular point in an application, how do you find where you can go next, or what you can do? The early graphical user interfaces beat the more-powerful command line because they allowed users to discover features without needing to remember that a feature was there. This property turns out to be so compelling that command lines were relegated to, well, somewhere that you can discover with a bit of digging.

 

The unchallenged dominance of the graphical user interface is facing a new contender: voice-activated assistants, such as Siri, Alexa, and Google Assistant. These ever-listening devices attack the soft underbelly of the graphical user interface; the (non-alternative) fact that you need a graphical screen to interact with them, and you need to be within touching distance of that screen. With voice-activated assistants, you only need to be in yelling distance (or have your phone nearby).

 

Once you’ve vocally activated your assistant, you need to give it commands. One of the hard problems with this, and with life in general, is that different people ask questions in different ways. Where you’ll say “Alexa, what time is it?”, I’ll proclaim “Alexa, what be the hour?”. Internally, the servers powering Alexa need to figure out that we’re asking the same question, which we call disambiguation. One of the strengths of command and graphical interfaces is that input is unambiguous (yes, you really did click the “delete all my files” button). Unfortunately, disambiguation is a hard problem, even for relatively simple commands. Try adding “fork handles” to your shopping list to discover this for yourself.

 

If we can make the simplifying assumption that we’ve solved the above problem, we’ve just discovered a deeper problem; how do you do discoverability on a voice assistant? “Siri, tell me everything you can do” is likely to flatten your phone battery pretty quickly (which I don’t believe is an intended feature of Siri), nor does it help you decide if Siri can order you a late-night Chimichanga delivery. At the moment, this isn’t really a problem because voice assistants are very limited in what they can achieve. Alexa is about to run face-first into this problem with the addition of Traits. Given two Alexa devices with Traits, there’s no way to tell which Traits are available. Without a good solution to the discoverability problem (wait, you were expecting me to have one?), voice assistants will be limited to simple commands and instructions.

 

An interesting property of command lines that hasn’t featured in voice assistants yet is that of composition (i.e. can I chain the output of multiple commands together?). We even have this concept in the graphical world – the humble copy-paste allows us to move data from one program to another with only a modicum of mouse-pointer shuffling. Telling Siri to “email the news story about the giraffe to my mother” could lead to some unexpected (but possibly hilarious) results. Which is a pity, because composition is incredibly powerful, and we really ought to continue making it available.

 

Is the end nigh for our mellifluous Alexa? It seems unlikely; convenience outweighs theoretical concerns, and there are some genuine good uses as well as novelties and party tricks. Only time will tell. If we can figure out how to ask for it, anyway.

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.

 

 

 

 

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.