I like this, and there are some great related resources. “Every buying decision is preceded by an emotion”, I think that is such an important point.
Category: Work
Do user testing… with real people
In around 2005 I was working on a hotel booking engine for a website, it was for my own business at the time. And I had a scary unexpected experience one summer weekend which has affected the way I think about product development till this day.
My mother was visiting, and I asked her to try out the website. Inadvertently, I had arranged my first ever user test.
The website was I thought pretty cool, it had tens of thousands of hotels and even had a proximity search so you could find hotels for example near monuments or parks, and this was before geo enabled MySQL 5. My confidence that she would like it was very high.
The problem although I didn’t realise it was that the site was clearly unusable, it sucked. I watched my mother click on all the wrong things, follow user paths I’d never imagined, it was painful, hard to watch and frankly awful. From that day on I understood the importance of user testing. I promptly ordered Steve Krug’s book ‘Don’t make me think’ and learned about usability and user testing.
In most of the companies I have been in since, little thought was given to user testing and usually only internal testing was done which for me doesn’t count. The tests always came too late anyway, just before launch.
Fortunately this whole testing thing has a new raison d’être now and new guise with the advent of so called ‘lean UX’ which I guess shows somewhere that scrum with the idea of early user feedback has clearly failed. I like Lean UX though and if it helps product managers get a product out earlier to real users, that has to be a good thing. Software development is too expensive both in itself and for the business to waste time pursuing the wrong direction.
I recommend the book ‘Lean UX‘ and also the video workshop. Oh, and for heavens sake, put those detailed designs away, cancel those design meetings, take a break from your analytics and test with real people!
Thoughts on remote working
On a business trip to Germany last year, I had a conversation on remote working with colleagues covering issues like ‘how it works’, pros and cons, difficulties and so on. It set me thinking about the whole thing again. What does make it work? What are the issues? Where does it work?
I have been on all sides of the remote working model for years and currently remote work with colleagues in Germany, UK, Poland and France. In times past, the USA, Romania, Tunisia and Bulgaria and India was in the mix too.
What’s the big deal?
To some degree I find it curious that the whole topic is such a big deal given that a good % of people work for themselves anyway. But the issue here is about remote working within a traditional company framework, where people normally go to a place of work every day.
Why remote work?
Your organisation could be spread across the country or countries already so in a sense you might already remote. Great staff might not be where you are and might not want or be able to move. You can get to a bigger talent pool if you allow remote working and depending on location, staff costs can be reduced.
Also, allowing remote flexibility might allow you to keep staff needing to balance the needs of raising a family or other personal issues with work. It can be very efficient too. Perhaps staff just want a day working at home each week to simply get things done.
When to remote work
Clearly there only so many jobs or industries that can be made to work remotely but desk based positions are probably suited and a lot of companies do that already in that staff might be able to work one or two days a week from home. IT jobs where work is done on remote systems all day anyway seem particularly appropriate.
Home working isn’t a silver bullet for efficiency though, modern internet collaboration tools are helpful but they make it easy to be interrupted, and online meetings are no different to physical meetings, they will still break the day and force context switching.
… the foundation of making remote working ‘work’ is communication and trust… No process or technology will fix a lack of trust or communication.
Selling it to management
This is probably the hardest part and it will be even harder in larger more established companies. I think there is a valid fear that if one person is allowed to remote, then everyone will want to and then what? Can the company handle that? Traditionally, managers like to walk the floors and see their staff at work, or at least think they are seeing their staff at work. If staff work remotely they are probably goofing off, watching TV all day right? How do we know what they are doing? The team will disintegrate and management will lose control right?
With modern computer based jobs, I don’t think that office time is relevant any more as a measure of productivity. Staff can goof off looking at Facebook, Youtube or whatever all day at the office pretty much as easily as at home. With our work stations open to the internet and our permanently connected lifestyles, distractions in our working day are endless either at home or in the office. And do you know what staff are doing already anyway? Sure, they might physically be in the building for nine hours but do you know what they are actually doing?
For me, at the end of the day I think management needs to know:
• is the work getting done?
• how can I see what is getting done?
• is the team working, effective and pulling together?
• am I still in control?
Large open source projects with legions of contributors distributed around the world can organize themselves and get work done, companies can do it too.
How to start
I think firstly, define the scope for the remote working. For which roles in your organisation could it work? Will it be for a day or two a week, or full time? Do you want to pilot it first? Are you prepared to change processes and technology to support it, to introduce a different work culture, to train staff? Will certain things always happen face to face? If you pilot it, what are the criteria to measure success and failure? Are you ready for the question “he’s working from home, can I work from home too?”.
There are probably two broad approaches to allowing remote working, the first is to allow remote working for only some of the week, the other is for full time remote working but with periodic trips to the office or in-person meetings.
Someone working from home a single day a week might find that this is the day when they get all their work done and rave about the benefits, but for a full time remote worker, that might not apply. Full time remote workers can be just as involved in meetings and other work distractions as anyone else.
It will definitely work better with staff who are already good communicators and naturally more transparent and vice versa, allowing your already most distant workers to work from home might not work out.
• Define the boundaries and context, part time, full time, pilot?
• Announce it as a pilot and be careful about how it becomes policy
• Define criteria with which you can measure success and failure
• Allow your best communicating, most focused, trusted and transparent staff to try it first
• Make sure your processes, technology and office based staff are ready/prepared
• Get regular feedback from all those involved. Review, improve, iterate
How do you make it work?
Assuming the basic requirement of a good internet connection is met, I don’t think there is a silver bullet for this. Online collaborative tools, modern practices, internet chat and video and so on all help, but the foundation to making remote working ‘work’ is communication and trust. Colleagues simply must communicate well with each other and they must trust each other. No process or technology will fix a lack of trust or communication.
It helps if colleagues already know each other and have worked together. If not, then get people together from time to time. Get together for the starts of projects or things like milestone meetings, important company meetings, sprint planning and review, new staff joining and the fun stuff like company parties. Or just work together for a few days or a week in the same location. That can be a lot of fun.
Do regular reviews with colleagues to check things are working fine, this isn’t just about the work and communication, but also more mundane issues such as networking and tools working as they should.
A great thing about working from home, you can work pomodoro style with a real timer and not annoy anyone.
Tools
You need tools to facilitate communications and tools to facilitate distributed working. For communications you need some kind of internet chat software, plus the ability to do video conferencing with screen and document sharing. The basic requirements there are good internet speed, webcam, microphone with headphones and software such as skype. Also look at lync, teamviewer, jabber and slack.
Chatrooms are very useful where teams need to collaborate as is the ability to take control of someones’ PC, or someone yours for support purposes. It’s also handy to have software that lets you schedule meetings with an online join link too. Microsoft Outlook does that but for sure there are other solutions.
We also use Atlassian Jira Agile (formerly called Greenhopper) the scrum and kanban tool which is very useful for visualising work and progress. If your team is distributed, a tool like this is essential and check out new kid on the block Trello too. Finally, whilst I haven’t personally used it, Basecamp looks good as a project management tool for distributed teams, they have written some very interesting books too.
And don’t forget your staff will need secure access to intranet tools and files, so likely access through a VPN.
Work environment
You need a dedicated work space and it needs to be quiet, and also somewhere that helps keep you in the work zone. You might find it helps to have some artifacts from the office in your home workspace too.
Organising work
The work tasks must be clear, transparent and with defined timeframes and deliverables. Agile techniques help here and we do a sort of scrumban. Our backlogs and tasks are managed in Jira, Atlassian Jira Agile helps visualise work, we record our velocity and for software tasks also have transparency through use of git and gitlab. We try to minimise discussions through e-mails and rather encourage discussions to take place in gitlab, Jira tickets or in collaborative wiki pages.
All this means that it is easy to see what people are doing at any time, how much they are managing to do within the sprint cycle and view the output. With such practices and transparency, I think it is pretty hard to goof off as a remote worker and it’s certainly not in your interest to do so, the work needs to get done right?
In my experience, contractors are generally better at work time accountability since they are used to filling in time sheets, dealing with work packages and so on. A good scrum process with meaningful and reflective sprint review helps as well.
One other tip: write everything down. At best I prefer to have discussions in tickets (as comments) or collaborative wiki pages, or at least in chat/chatrooms with a recorded history. It becomes a complete pain to trawl through emails after a while, it is even worse when people leave and knowledge becomes locked in dormant mail accounts. Transparency is king.
Meetings
With modern communications software, meetings aren’t a problem. All our scheduled meetings have a link to join online and unless there are network issues, we nearly always have video on. I think seeing your colleagues is important and it helps the team to feel connected.
Office based staff might be sat in a traditional meeting room looking at a big screen and it is important here that screen sharing software works so that remotes can see what is going on.
I don’t personally like video on all the time, simply because I don’t want everyone scrutinising my face when displayed large on a conference screen if I’m feeling unwell that day.
Remote working sounds easy, is it?
Working remotely isn’t necessarily easy, all that time alone might drive some people a little crazy and full time remote working definitely won’t be for everyone. You need to be organised and disciplined both with work and breaks, and the hardest thing I find about remote working is the lack of physical movement. It is all too easy to just sit and work all day and to that end, I try my best to put exercise breaks in the day. Many good ideas come when I’m out walking, and not sat at the computer.
One thing I miss sometimes is a period of disconnect – normally covered by the commute – from work before plunging into the evening family life. On those days where my head feels fried, I just go for a 30 minute walk and that helps.
Working remotely can make it easier to be distracted, in the sense of people talking to you on messenger, and beware feeling the need to be visible online all the time just to show colleagues that you’re there. I tend to get asked a lot of things all day and from time to time go into a do not disturb mode to get things done. It is surprising how not everything turns out to be urgent.
Where it can fail
I think it can go wrong when your remote staff get forgotten and office staff involve them less and less in things. If trust is lacking or communication is poor, things can go wrong and on that point, if the work can’t be seen, that can erode trust. Visual kanban style boards are great here (Jira Agile, Trello). Then there are the basics; is networking reliable? Do staff have the software tools they need? Is communication as good as it can be? If your staff need to go through a VPN, does it work reliably? Does everyone have good headsets and webcams?
And don’t forget to have team meetups from time to time, as with any relationship, once a bond is made, distance isn’t a big deal. I think the biggest point of failure is simply having office based staff who are poor communicators and who don’t care to have remote colleagues. But then, that’s not a remote working problem, that’s just a staff problem.
My experience and final thoughts
I think I can say that I have been on all sides of the remote working model now. On and off, I’ve worked remotely in a different country to my colleagues for around six years, I’ve worked in the ‘office’ managing offshore teams and workers, and also hired and built fully distributed teams both office based and as a remote too. And also hired staff remotely too. It’s all possible.
Certainly some industries are better suited to it than others but most office based jobs could probably support some degree of remote work.Your staff are ultimately your best asset and anything that helps you hire and keep the best people has to be good. The bottom line is that remote working can really work, try it.
Interesting links
http://blog.cloudpeeps.com/top-10-companies-winning-at-remote-work-culture/
https://www.acquia.com/resources/podcasts/acquia-podcast-180-working-rem…
http://37signals.com/remote/
http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work
http://whenihavetime.com/2014/07/08/10-lessons-from-4-years-working-remo…
https://slack.com/ – communications tool, real time chat.
http://asoftmurmur.com/ – great for background sounds.
Edit, 10.09.2015. – now these I like
http://p2theme.com/, and http://ma.tt/2009/05/how-p2-changed-automattic/
http://simplenote.com/
Edit 12.12.2015
http://www.wired.com/2015/12/digital-nomads-telecommuting/
We do scrum-but and it’s fine
It seems that the debates about scrum are always ongoing and it or agile development in general is still a pretty hot topic. There’s even a new job role ‘agile coach’ as more of an industry is built around it. The world is ever more moving online and getting more digital, so it’s a big market.
I think too much is expected of scrum and agile practices and that it is viewed particularly by non-technical people as some kind of development process panacea. It’s also worth remembering that scrum came more from the project management side of things rather than the technical side like extreme programming (XP).
My first scrum project was in 2007 and it was text book stuff. I was in the ‘chosen’ team working on a cool new green field project in a special room and we even did planning poker (for a while). Over the years, in different companies we all did what I now call “scrum-but”. I got this phrase from discussions with people in different organisations asking how they do scrum. It goes like this:
“So you’re doing scrum right? How’s that working for you”
And the answers would invariably be:
“Yes we are doing scrum but we’re not doing this.. “
“Yes we are but we’re doing this…”
“Yes we do scrum but..”
In short “scrum-but”.
The real world is different than what you learn in scrum trainings or read in the books and I’ve seen a lot of this:
- Product owners have a very clear idea of what they want and don’t consult the technical staff until just before the project start. Technical viability and cost is often not explored
- It’s worse if design agencies are involved because then there is no room for feedback, it really is just a case of ‘implement’
- Often, there is little concept of minimum viable product
- Real user feedback isn’t gathered until just before the release or after, there is no feedback and altering of requirements until it’s too late
- Stakeholders and owners often don’t care about the technical details, maintainability and quality and if external code shops are involved, they will probably not be thinking of how the thing will be in five years time
- Scrum is fine for projects but once the project is released, it then goes into maintenance and extend mode. What then?
- Technical teams are often working on multiple areas at once, new work, maintenance and ongoing development work. That doesn’t fit with the idea of nice clean projects and backlogs
- Not nearly enough focus on fundamental technical issues such architecture, quality, testing
- And for agencies, how do they manage billing and cost estimates if the whole thing is done iteratively? This was a big topic for agency managers on a scrum training I went on and the answer was “look, scrum doesn’t solve your business model problems”
- User stories like, ‘As a log file I don’t want to see error message xyz’
After I did a scrum master training in 2012 none of this bothered me any more regards scrum, because I realised that scrum was a square peg in a world was full of round holes. And from then on I decided to just take the good bits from scrum, other lean principles, XP and just make them fit the need and environment, ‘scrum-but’.
I think the trick is knowing where the line is on technical compromise, that’s personally where I don’t budge. Make sure here you have a strong technical lead who gives honest feedback. At the end of the day, corny as it sounds, project success and ongoing success is about people, teams, trust and responding correctly to business needs.
Martin Fowler reposted this post from 2009 last year, and it’s as valid now as then. http://martinfowler.com/bliki/FlaccidScrum.html
An Engineer’s world (sometimes)
This is gold.
Meetings
How to have good meetings:
1. Windows open
2. No phones
3. No chairs
My take on a Consultant’s Tale – from a software development angle
This little story comes from a magazine I saw recently in a waiting room somewhere and it set me thinking:
Every day a small ant arrives at work early and starts to work immediately. She produces a lot of and she was happy.The newly appointed Chief, a Lion was surprised to see that the ant was working without supervision and he thought, if the ant can produce so much without supervision, wouldn’t she be able to produce even more if she had a supervisor. So he recruited a cockroach who had experience as a supervisor and was famous for writing excellent reports.
He needed a Secretary to help him write and type his reports and he recruited a spider who managed the archived and monitored phone calls. He also recruited a fly to manage the IT department.
The ant started to produce less work with the regime of paperwork and meetings which used up so much of her time.
The Lion came to the conclusion that it was high time to nominate a person to be in charge of the department where the ant worked. The new person in charge, the cicada also needed a personal assistant, who he brought in from his previous company to help him to prepare budgets and strategic plans.
Having reviewed the budgets and costs of running the ant’s department, the Lion found out that the production was much less than before so he recruited the Owl, a highly skilled consultant to carry out an audit and to suggest solutions.
The Owl spent three months in the department and came up with a glossy report that concluded “The department is over-staffed“. Guess who the Lion fires first?
The ant of course, because “she showed a lack of motivation and had a negative attitude“.
It’s a story I think some of us can relate to.
For me with coming from software development, such a tale is even more scary because of the potentially enormous sums of money that IT departments can simply swallow and also because IT done wrong can easily sink a company or at least greatly contribute to the sinking of a company. I have seen this first hand with a previous employer.
Regardless of your company’s setup, if your IT staff costs have ballooned or productivity has sunk what can you actually do? Slash R&D in which case you can be overtaken by the competition? Drop quality or reduce maintenance work, which will likely mean being killed by technical debt later and making your product worse, as well as killing developer motivation later as they fight a worsening code base? Or hire new staff to do the work because your existing staff spend all day in meetings, shuffling e-mails, writing reports, justifying budgets or their own jobs? And don’t forget to factor in ramp up time for new people, plus the related drop in productivity from your most experienced people who are tasked to bring the new ones up to speed.
Firing the ant is likely pointless and tricky too. He or she might have a large amount of domain knowledge and your software and systems are probably not that well documented. Also, firing one ant, might trigger the other skilled ants to leave as well.
I personally think that the building of empires needs to be strongly avoided in the first place, and efficiency and leanness need to be kept – difficult in large companies with an established culture I realise. If it is too late and you have large a large staff overhead that doesn’t add value or where staff are just no longer productive, throw away the book, restructure using lean processes, if staff aren’t and can’t add value, move or fire them, recapture a start-up feeling. That doesn’t mean everyone works fifteen hour days and lives off pizza, it means that everyone gets closer to meeting the needs of the customer, feels the urgency of that, does more with less and gets things done.
There is never a silver bullet for anything and everything is always work in progress, but here are are some suggestions around software development I’ve learned from experience:
- Build teams that assume as much responsibility and self-governance as possible themselves and resist losing your top developers turning into project managers. Scrum is great for collective responsibility.
- If you really need a project manager or scrum master, find one and keep your developers coding.
- On the flip side, don’t let your techies become ants performing merely repetitive tasks, they might appear to be happy but inwardly be boiling with frustration and once they have enough time at your firm for their CV will be off to the next company
- Also on the flip side, senior developers are often hungry for an official lead role on their CVs and might leave if that desire is unfulfilled. My suggestion there is nevertheless to try and keep your lead developers focused on technical tasks such as architecture and driving quality, and on guiding the team technically, and being generally hands on. It’s such an expensive waste to lose them in monkey work.
- Seek out the ideas and creativity of your staff, imagine you are a start-up again.
- Don’t shield your staff from the product and the company’s financial figures, or if your company is very large, your department or division’s figures
- If you are the Lion, don’t shut yourself away from your team(s), sit with them regularly, talk to your people and get a feel for things. Don’t let people leaving be the only feedback you receive.
- Cultivate a hands-on attitude, no-one in the technical department should be above getting their hands dirty, and purely administrative IT managers are an expensive luxury.
- Look after your staff
- Tear down communication barriers, don’t just communicate through meetings and tickets, scrum with its cross disciplinary roles e.g. dev, sys, DB, QA is great for communication
Interesting reading
http://www.slideshare.net/AmSam/the-ant-and-the-lion-rethink-about-your-… – a PPT of this story with images
http://en.wikipedia.org/wiki/Lean_software_development
http://www.slideshare.net/jpvajda/lean-software-development-principles
http://radual.com/what-developers-need-from-their-lead/ – Alexandru is a colleague of mine
http://www.dilbert.com/ – we want to avoid this world right?
Klaus Harris 