Archive for the ‘Lean’ Category
I gave a talk at LondonWeb a couple of weeks ago. It was a lot of fun. I tried to broadcast it with Google Hangout on Air, but the hotel wi-fi was rubbish. Luckily, @nathanlon recorded it too, so here it is:
and the slides:
Today, my department begins a trial of a new culture. It’s a new way of thinking about work. Alright, it’s not *new* but it is rare. Especially in the UK. The culture can be summed up with one sentence: ‘Employees are free to do what they want, when they want as long as they get the work done.‘
There will be a whole bunch of blog posts on this subject, so consider this one a bit of a summary of all the main points.
I’m talking about a Results-Only Work Environment, or ROWE for short. It started with Best Buy in the states. Two employees were tasked with making things better and they began with flexible working programs which quickly morphed into a Results-Oriented Work Environment, then settled on a Results-Only. They detail their journey in their book ‘Why work sucks and how to fix it‘. I devoured the book in one sitting and made copious notes and realised that this was what we needed.
The way business works now is outdated; why do we need to work between 9 and 5:30? Why do we need to go to one particular place to do it? It doesn’t matter if you’re a knowledge worker, or in sales, it’s the same thing: the focus should be on results, not when or where you are.
It’s not been easy getting this trial started. There are lots of questions around holiday allocation and remaining on the correct side of UK employment law and legislation. Essentially, we need to still allocate people the appropriate amount of holiday and then ensure that they remember to take it. This mostly covers the company, so if someone leaves on a bad note, they can’t claim to have not taken holiday, because, in ROWE, you take holiday whenever you need it, there’s no allocation really. Because employees get to choose when, where and how they work, the rules governing the Working Time Directive don’t count either. There’s no 48 hour waiver or whatever.
We’re starting with *almost* the exact ROWE for a three month trial, I say almost because we’ve made two concessions, which I detail in the guideposts below. After three months, if it’s still working, we’ll extend the trial. The idea is to see if vanilla ROWE as detailed in the book works in the UK. UK and US cultures are different and employment law and employee rights are also different, so we need to make sure it fits properly for us and our business. I’m 100% confident that this will work.
Freedom and culture
Ultimately, working in a ROWE is purely focussed on the results. But it gives employees absolute freedom to manage their lives they way they need to. We all have to work, there’s no way around that (unless you’re a millionaire playboy or whatever), so we should be free to fit that work into our lives as we see fit. You don’t need to take a half day holiday to visit the doctors, you don’t need to phone in sick unless you’re going to be letting someone down with a meeting or conversation and you don’t need to worry about where anyone is, you and your colleagues are available 24/7 by phone, voicemail, email, SMS, skype, irc, Google Hangout – lot’s of options!
ROWE isn’t an activity or an action, it’s a culture and a new one too. It’s about changing the attitudes people have towards work and challenging the long held beliefs that time plays an important role in measuring someones value (time is still relevant for deadlines and in some lines of work, but not in the web industry).
I’m expecting to see productivity improvements too – I have no idea what they’ll be or in what format, but I’m sure they’ll be there. For one, I find I can get a lot of work done in the wee small hours, because I’m not being distracted and there’s nothing to procrastinate about when the kids and wife are in bed – so I can’t play PS3 or watch a movie, so I work and I can get more done in less time because I’m so focussed on what I’m doing.
Our teams use Scrum to build our software, so we have a built in results measure. We’ll be looking at velocity for each team and the department as a whole, as well as defects, engagement and acceptance rate of stories (the percentage of story points accepted at the end of the sprint). On top of that, all the people in my team have individual goals and objectives; a mix of skills acquisition and platform or performance goals, so I can measure individuals as well as teams.
ROWE is based on a set of principles called ‘Guideposts’ which enable the change of culture to happen with a purpose, the most contentious of which are ‘Unlimited Paid Holidays’ and ‘Every Meeting is Optional’. The holiday one is easy to cover in principle – it’s irrelevant how much holiday you take, or when/where you take it, as long as the work gets done. That said, we still need to make sure that we’re adhering UK legislation and in order to do that, we still need to allocate and record holiday taken. It’s a small price to pay for that much freedom though!
‘Every Meeting is Optional’ is also difficult for people new to the culture to get their heads round, it doesn’t mean ‘flip a coin to decide whether or not to go to a meeting’, it does mean, find out if you can get, or give value to the meeting, find out, or define (if it’s your meeting) the outcomes and then decide whether you need to be there in person, whether you can dial or Skype in, or whether you’re just required to give information which you can email to the organiser. As long as the work get’s done and you’re meeting the goals, objectives and targets set, it’s up to you whether you attend meetings and how you attend them.
The one concession we made to this guidepost was that, ALL meetings are optional, but pay particular attention to external client meetings or group-wide meetings. We’re only one department in one company doing a ROWE trial, we can’t expect others to change they way THEY work … just yet. It’s a small concession and, to be fair, will barely affect our department.
Metrics and the win condition
How do we know the trial is successful? If nothing changes. Like I said, we’re currently tracking:
- Velocity: The average rolling department velocity over the last 4 sprints (and long term velocity, but this is less volatile and less useful)
- Defect rates: how many defects are opened per two-week period and how long those defects stay open (as an aggregate and also by priority)
- Acceptance rate: What percentage of story points is ‘accepted’ by the product owner at the end of the sprint.
- Engagement: we’re using Murmur to track employee engagement with the company on many levels.
We’re also looking to measure the perception of the department from across the business.
The win condition will be if nothing changes. If none of the metrics change over the next three months, then the trial will be considered successful, the net benefits of ROWE will be over and above just the impact on those metrics. So, as long as nothing get’s worse, we’ve proved ROWE as a culture in the organisation.
On top of the team metrics, we’re also setting goals and objectives on an individual level – skills acquisition or just ‘stuff that needs doing’ for the platform, our tools or whatever. So, we can watch everything that’s happening and see if it’s making a difference.
Next I sit back and wait for a sprint or two and see what’s happening, I need to keep my eye on the metrics and the individual objectives, but really, it’s business as usual … or not, depends on how you look at it!
I’ll be blogging more as the trial progresses in the hope that others in the UK who are already in a ROWE, or those thinking about going ROWE can share their progress, problems, failures and successes.
This is the first in a number of posts which will explore a few different software development methodologies. Part of my job as Agile Coach is to know what methodologies there are and how and when they can be applied. We’re agile at Affiliate Window and doing Scrum, which is working well for us, but without knowing what else is out there, we’ll never know if it’s a perfect fit. So, without further ado, I present Lean Software Development!
Lean Software Development is based on seven principles and, in the nature of being Lean, nothing else. These seven guiding tenets were originally written up by Mary and Tom Poppendieck in their award winning book: Implementing Lean Software Development, and I think they’re going to stand the test of time. You could also head to the Wikipedia article, which is what the PoppenDiecks wrote, verbatim. Below is my take on the tenets.
This principle is probably the most well known and the most obvious route to becoming Lean, the hardest part about ‘eliminating waste’ is spotting waste in the first place! It’s often a case of being unable to see the wood for the trees in most teams. But waste comes in many forms. From a developers point of view, waste can be seen as unnecessary code or functionality. So, think about DRY (Don’t Repeat Yourself) and YAGNI (You Ain’t Gonna Need It). Waste can also be seen when developers have to deal with unclear requirements (incomplete requirements are fine though), red tape and bad communication. All of these things, and more, are waste. Think about it this way. If you could get rid of something, or swap something for something more simple and have it not adversely affect your quality or output, then it’s waste.
So, this isn’t listening to a podcast through a Marshall stack, or even making the text bigger in your browser (although, these might help). This is all about making sure that you’re constantly learning and refining your craft as a software engineer. The learning process is sped up by the use of short iteration cycles, meaning you get feedback from the customer and feedback on the process quickly. This ensures you’re constantly learning about your product and the way you build it.
Decide As Late As Possible
This is the part where I tell you about the ‘Last Responsible Moment’. This moment is the very last point in time where you can make a decision. But, it’s not just about putting off a decision until you REALLY have to make one. It’s about putting off a decision until you have as much information as you’re going to get before you have to make a decision. You need to weigh up all the potential options that a decision throws at you, decide what the deadlines are on each of those options, then you’ll know when you need to make your decision by. This is to stop you from making generalised decisions, or writing generalised class structures – stuff you might end up throwing away. Waiting until the very last moment to make a decision might seem reckless, but weigh that with making decisions too early and having to throw work away and you’ll start to see the benefit. If you’re struggling to work out when the last responsible moment is, there’s a great comic strip on the Agile Journal that might help you out.
Deliver As Fast As Possible
This is just common sense in an agile world. Any of the agile-y methodologies suggests that you do this – it increases visibility on how your product is doing through the medium of early feedback. Your customers or users can see what you’re doing in short bursts and feedback to the team. On top of this, it allows the teams to step amplify their learning process with constant, quick feedback. You’ll also be delivering things the customer wants today and not what they asked for three weeks ago. This also draws from Toyota’s way of doing things Just-In-Time. Where you deliver things just in time for the next part of the process, eliminating waste by having nothing hanging around waiting for the next step or phase. In development terms, this means finishing a task and handing it off for testing just as the tester finishes testing the previous task. Not that that’s going to be easy, but no one said it would be!
Empower The Team
Find good people and let them do their job. Don’t hire good developers, testers and the like, then tell them how to deliver the software. The people who know the most about how to deliver your product for you, are the guys in the trenches, the girls on the factory floor, not the managers in their glass boxes. Teach your management layer how to listen to your developers. If you can’t do that, then make sure there’s a conduit for information to flow both ways. If management starts telling developers how to build software, you might as well not bother…
Hire good people, show them what you want and how you think you’d like to get there, then get out of their way.
Empower the team to make decisions on the direction of the product – from their point of view – this is important. Developers aren’t going to know the overarching roadmap and vision of the product unless you tell them, they’ll then be able to start making design decisions based on that knowledge, so hide nothing from them. Hire good people, show them what you want and how you think you’d like to get there, then get out of their way.
Build Integrity In
Software quality is paramount. Developers are no longer satisfied with being such, they’re now engineers, artists and craftsman. To be a good software engineer, you need to be both artist and craftsman. Both of these professions strive for quality and perfection. Your teams should be doing this too. Your software should ship with no defects and to ensure this happens, you need to make sure your teams are baking tests into their product. Automated tests are part of the product, if they’re not useful, they’re wasted and should be stripped. They’re also not the goal, they’re the means to achieve to the goal (a quality product, free from defects).
Building integrity into the code is one thing, you also need to build integrity into the entire system itself. Everyone from the customer to the team members should be refactoring, de-coupling and generally making sure the whole system is rock solid and trustworthy. If your customer has a good feeling about the entire product, then you will too!
See The Whole
Software nowadays is no longer the sum of it’s parts. Now software is modularised, or farmed off into services, it’s the interactions which count – the layers between the layers. Be mindful of the way things interact with one another and you’ll avoid common defects and be able to deliver a better product. Seeing the whole also refers to the relationships between all relevant parties of you project or product. If you’re making software with teams that span the globe, make sure you’re keeping the interactions between your teams and even your 3rd party vendors in your sights. That way, you’re much less likely to miss the problems of integration when they occur.
Implementing these seven parts of Lean Software Development into your Software Delivery Lifecycle, along with a good dash of common sense and some good people on your team should be all you need to create a great software product. Is Lean the answer? I don’t know. It’s one methodology that might suit your team, your industry or your product. But maybe it won’t. From the outside, it seems fairly sensible that, reducing waste is a great idea, but – what is waste really? I don’t think that anyone nowadays will be of the mindset that ‘this is what we do because it’s the way it’s always been done’ are they? So, how do you identify waste when your software development and delivery practices all have a purpose? Do you try and assign a value to the purpose and ditch those practices which fall below a certain value threshold? Maybe. But, until I’ve had a chance to experiment with Lean Software Development, I’ll never be sure.
I’m beginning to think that each methodology has it’s good ideas and common sense ideas – it’s up to you and your team to pick the best ones that work for you, I think that, regardless of your methodology, ‘reducing waste’ is a good guideline to subscribe to and if you take anything away from this, then that’s definitely something to adhere to.
I recently started a conversation on the agile development group over at Yahoo Groups. My initial question was, should I ditch the product backlog? We tend to do a lot of just-in-time development, the requirements come in, sometimes mere hours before our sprint planning and as such, these stories are only on the product backlog for a very short period of time, if at all. Often they’ll just come in via email from the Technical Director and they get added to the sprint. The backlog, then, becomes ever growing and it seems that some of the stories on there will never be looked at again, let alone completed. It’s the fable of the ever-growing backlog.
So, do we even need it? Jack Milunksy of Agile Buddy fame said, if you’re not using it, then in pure lean fashion, ditch it and stick with the just in time. Others have said, if you’re not using a product backlog, how will you define a release strategy or be able to roadmap the product? Which is a good point. The answer then is that it depends. Why is this always the answer with anything scrum?
If you’re using the product backlog as a place to store and prioritise stories, use as a release manager or roadmapper, then you should keep at it. If you’re using the product backlog as somewhere to store half-formed ideas of possible features of additions to your product, then maybe you should use a backlog. If you get your priorities minutes before the sprint starts, hastily written on the back of a beer mat, then maybe not. Or, maybe just use it to store high priority stories that are definitely going to be worked on but not yet.Above and beyond all this though, is grooming. If you don’t groom your product backlog, then you’re in a whole world of pain. Epics, which are at the bottom will suddenly become top priority and, without grooming, will still be Epics. Your team may even throw things at you, I wouldn’t be surprised. So groom the backlog regularly, get the team involved and make sure you’re breaking stuff down!
Update: Jack Milunksy over at the Agile Buddy blog even blogged about this: http://blog.agilebuddy.com/2009/11/do-you-even-need-a-product-backlog.html