At some point in the last few weeks that started to happen to me on my Android (Nexus 10, no less) tablet. Thankfully I managed to solve it.
A quick scan of the BBC help seemed to just direct me to my ISP (they may route you through foreign / non-UK servers - I knew this wouldn't be true as my desktop works OK, and it doesn't sound like BT). A quick mail to them seemed to confirm my fears - no problem there.
A mail to the BBC was never going to be much use. I don't blame them, they have a lot of people to deal with and none of them pay a subscription fee that's optional. It makes no economic sense for them to have a good technical help line.
Any way, after a lot of Google searching for phrases like:
- The BBC thinks I'm not in the UK when I am.
- iPlayer thinks I'm not in the UK.
- iPlayer won't serve me any content.
- BBC has adverts on it.
And many other variations on the theme, I decided to go back to the BBC site and give it one last go.
On one of their help pages I spotted a pretty throwaway comment about web accelerators causing problems sometimes. Knowing that Google's a little too clever for its own good sometimes this seemed like a good avenue to check.
It turns out that this was the problem, and it's really easy to solve.
In Chrome (on Android 4.3 anyway) go to:
- Bandwidth management
- Reduce data usage
- Then in the tip right corner, flick the switch to off.
Basically, if this is switched on then a lot of content isn't served from its source. Rather you get it from Google instead - it gets it from the source, simplifies it, re-compresses it and then sends it to you so that you can get a modest 20% saving on your download sizes.
The result is pretty much as the BBC describes it, your internet content is routed through non-UK servers. It's just that it's not down to your ISP doing, it's Google.
So, hopefully, when you get that dreaded "BBC says I'm not in the UK" feeling, your Google search will bring you here and you'll solve the problem in a fraction the time it took me!
As far as I can see, there is only one reason why a company should ever make redundancies.
Due to some unforseen circumstances the business has become larger than the market conditions can support and it needs to shrink in order to bring it back in line.
Every other reason is simply a minor variation or a consequence of that underlying reason.
Therefore, if the motivation is clear, and the matter dealt with successfully, then once the redundancies are over the business should be "right sized" (we've all heard that term before), and it should be able to carry on operating with the same values, practices and approach that it did prior to the redundancies.
If the business can't, then I would suggest is that it is not the right size for the market conditions and therefore the job isn't complete.
OK, there may be some caveats to that, but to my mind this reasoning is sound.
When you reduce the headcount of the business you look for the essential positions in the company, keep those, and get rid of the rest.
Once the redundancies are finished you should be left with only the positions you need to keep in order to operate successfully.
It's tempting to think that you should have a recruitment freeze and not back-fill positions when people leave, but if someone leaves and you don't need to replace them, then that means you didn't need that position, in which case you should have made it redundant.
Not back-filling positions is effectively the same as allowing your employees to choose who goes based on their personal motives rather than force the business heads to choose based on the business motives. This doesn't make business sense.
So, you need to be decisive and cut as far as you can go without limiting your ability to operate within the current market conditions.
To add to that, recruitment is expensive. If you're in a highly skilled market then you'll likely use an agency. They can easily charge 20% of a salary for a perm head. On top of that you have the cost of bringing someone up to speed, at a time when you're running at the minimum size your market will allow. Plus there's the cost of inefficiency during the onboarding period as well as the increased chance of the remaining overstretched employees leaving as well.
The upshot is that you really can't afford to have people leave, it's so expensive that it jeopardises the extremely hard work you did when you made the redundancies.
There's a theory I often hear that you can't have contractors working when the perm heads are being marched out. That's a perfectly valid argument if the perm head would be of long term value to you and can do the job that the contract head can do. But if you need the contractor to do a job that only lasts another 3 months and that person is by far the best or only person you have for the job, then the argument just doesn't stand up. Get rid of the perm position now and use the contractor, it'll be cheaper and more beneficial to the business in the long run.
OK, that's maybe not the most sentimental of arguments, but why would you worry about hurting the feelings of people who no longer work for you, at the expense of those that still do?
It may even be worse than that - you could be jeopardising the jobs of others that remain by not operating in the most efficient and effective way possible.
Another prime example is maternity cover. If you need the person on maternity to come back to work then you almost certainly need the person covering them. If it's early in the maternity leave then you'll have a long period with limited staff, if it's late in the leave then you only need the temporary cover for a short period more. Either way you're overstretching the perm staff left to cover them and risking having them leave.
Finally, there's the motivation to ensure that the business that remains is running as lean as possible. That costs are as low as they could be. The temptation is to cut the training and entertainments budget to minimum and pull back on the benefits package.
As soon as you do this you fundamentally change the character of the business. If you always prided yourself on being at the forefront of training then you attracted and kept staff who valued that. If you always had an open tab on a Friday night at the local bar, then you attracted people who valued that. Whatever it is that you are cutting back on, you are saying to people who valued it that "we no longer want to be as attractive to you as we once were; we do not value you quite as much as we did". This might not be your intention, but it is the message your staff will hear.
I put it to you that the cheapest way to reduce costs after redundancies is to be completely honest to the staff you keep. Say it was difficult, say that you're running at minimum and that a lot will be expected of whoever's left. But tell them that they're still here because they're the best of the company and they are vital to the company's success. Let them know that the contractors you've kept are there because they're the best people for those positions to ensure that the company succeeds. Tell them that the contractors will be gone the moment they're not generating value or when a perm head would be more appropriate. Make it clear that the company is now at the right size and the last thing you want is for people to leave, because you value them and that if they left it would damage your ability to do business.
Then give them a pay rise and a party to prove it.
Then you get the developers to build it, exactly as you designed it.
Agile development, on the other hand, is a user experience expert's worst nightmare. You want to make a change to a system, so you decide what's the most important bit, and you design and build that - don't worry how it fits into the bigger picture, show it to the users, move on to the next bit, iterate, iterate, iterate, until finally you have a system.
Then you get the user experience expert to fix all the clumsy workflows.
The two approaches are fundamentally opposed.
Well, of course, I'm exaggerating for comic effect, but these impressions are only exaggerations - they're not complete fabrications.
If you look at what's going on, both approaches have the same underlying principle - your users don't know what they want until they see something. Only then do they have something to test their ideas against. Both sides agree, the earlier you get something tangible in front of users and the more appropriate and successful the solution will be.
The only real difference in the two approaches as described is the balance between scope of design and fullness of implementation. On the UX side the favour is for maximum scope of design and minimal implementation; the agile side favours minimal scope of design and maximum implementation.
The trick is to acknowledge this difference and bring them closer together, or mitigate against the risks those differences bring.
Or, the put it another way, the main problem you have with combining these two approaches is the lead up time before development starts.
In the agile world some people would like to think that developing based on a whim is a great way to work, but the reality is different. Every story that is developed will have gone through some phase of analysis even in the lightest of light touch processes. Not least someone has decided that a problem needs fixing. Even in the most agile of teams there needs to be some due diligence and prioritisation.
This happens not just at the small scale, but also when deciding which overarching areas of functionality to change. In some organisations there will be a project (not a dirty word), in some a phase, in others a sprint. Whatever its called it'll be a consistent set of stories that build up to be a fairly large scale change in the system. This will have gone through some kind of appraisal process, and rightly so.
Whilst I don't particularly believe in business cases, I do believe in due diligence.
It is in this phase, the research, appraisal and problem definition stage, that UX research can start without having a significant impact on the start-up time. Statistics can be gathered and evidence amassed to describe the problem that needs to be addressed. This can form a critical part of the argument to start work.
In fact, this research can become part the business-as-usual activities of the team and can be used to discover issues that need to be addressed. This can be as "big process" as you want it to be, just as long as you are willing, and have the resources to pick up the problems that you find, and that you have the agility to react to clear findings as quickly as possible. Basically, you need to avoid being in the situation where you know there's a problem but you can't start to fix it because your process states you need to finish your 2 month research phase.
When you are in this discovery phase there's nothing wrong with starting to feel out some possible solutions. Ideas that can be used to illustrate the problem and the potential benefits of addressing it. Just as long as the techniques you use do not result in high cost and (to reiterate) a lack of ability to react quickly.
Whilst I think its OK to use whatever techniques work for you, for me the key to keeping the reaction time down is to keep it lightweight. That is, make sure you're always doing enough to find out what you need to know, but not so much that it takes you a long time to reach conclusions and start to address them. User surveys, spoken narrative and video recordings, all of which can be done remotely, can be done at any time, and once you're in the routine of doing them they needn't be expensive. Be aware that large sample sets might improve the accuracy of your research, but they also slow you down. Keep the groups small and focused - applicable to the size of team you have to analyse and react to the data. Done right, these groups can be used to continually scrutinise your system and uncover problems.
Once those problems are found, the same evidence can be used to guide potential solutions. Produce some quick lo-fi designs, present them to another (or the same, if you are so inclined) small group and wireframe the best ones to include in your argument to proceed. I honestly believe that once you're in the habit, this whole process can be implemented in two or three weeks.
Having got the go ahead, you have a coherent picture of the problem and a solid starting point for you commence the full blown design work. You can then move into a short, sharp and probably seriously intense design phase.
At all points, the design that you're coming up with is, of course, important. However, it's vital that you don't underestimate the value of the thinking process that goes into the design. Keep earlier iterations of the design, keep notes on why the design changed. This forms a reference document that you can use to remind yourself of the reasoning behind your design. This needn't be a huge formal tome; it could be as simple as comments in your wireframes, but an aide mémoire for the rationale behind where you are today is important.In this short sharp design phase you need to make sure that you get to an initial conclusion quickly and that you bear in mind that this will almost certainly not be the design that you actually end up with. This initial design is primarily used to illustrate the problem and the current thinking on the solution to the developers. It is absolutely not a final reference document.
As soon as you become wedded to a design, you lose the ability to be agile. Almost by definition, an agile project will not deliver exactly the functionality it set out deliver. Recognise this and ensure that you do the level of design appropriate to bring the project to life and no more.
When the development starts, the UX design work doesn't stop. This is where the ultimate design work begins - the point at which the two approaches start to meld.
As the developers start to produce work, the UX expert starts to have the richest material he could have - a real system. It is quite amazing how quickly an agile project can produce a working system that you are able to put in front of users, and there's nothing quite like a real system for investigating system design.
It's not that the wireframes are longer of use. In fact, early on the wireframes remain a vital, and probably only coherent view of the system and these should evolve as the project develops. As elements in the system get built and more rigidly set the wireframes are updated to reflect them. As new problems and opportunities are discovered, the wireframes are used to explore them.
This process moves along in parallel to the BA work that's taking place on the project. As the customer team splits and prioritises the work, the UX expert turns their attention to the detail of their immediate problems, hand in hand with the BAs. The design that's produced is then used to explain the proposed solutions to the development team and act as a useful piece of reference material.
At this point the developers will often have strong opinions on the design of the solution, and these should obviously be heard. The advantage the design team now have is that they have a body of research and previous design directions to draw on, and a coherent complete picture against which these ideas (and often criticisms) can be scrutinised. It's not that the design is complete, or final, it's that a valuable body of work has just been done, which can be drawn upon in order to produce the solution.
As you get towards the end of the project, more and more of the wireframe represents the final product. At this point functionality can be removed from the wireframe in line with what's expected to be built. In fact, this is true all the way through the project, it's just that people become more acutely aware of it towards the end.
This is a useful means of testing the minimum viable product. It allows you to check with the customer team how much can be taken away before you have a system that could not be released: a crucial tool in a truly agile project. If you don't have the wireframes to show people, the description of functionality that's going to be in or out can be open to interpretation - which means it's open to misunderstanding.ConclusionIt takes work to bring a UX expert into an agile project, and it takes awareness and honesty to ensure that you're not introducing a big-up-front design process that reduces your ability to react.
However, by keeping in mind some core principles - that you need to be able to throw and willing to throw work away, you should not become wedded to a design early on, you listen to feedback and react, you keep your level of work and techniques fit for the just-in-time problem that you need to solve right now - you can add four huge advantages to your project.
- A coherent view and design that bind the disparate elements together into a complete system.
- Expert techniques and knowledge that allow you to discover the right problems to fix with greater accuracy.
- Design practices and investigative processes that allow you to test potential solutions earlier in the project (i.e. with less cost) than would otherwise be possible, helping ensure you do the right things at the right time.
- Extremely expressive communication tools that allow you to describe the system you're going to deliver as that understanding changes through the project.
Do it right and you can do all this and still be agile.