Archive for the ‘Methodology’ Category
How to estimate, pitch for and charge for a project in an agency enviroment
When I talk about estimation and planning, people often ask me the above question. The styles of estimating I talk about are more frequently used in a non-agency environment, that is, somewhere maintaining a single, existing product, or creating one, for your own company from scratch instead of the agency method which delivers software per project, per client.
The problem
The problem with this kind of work is that of estimates. Typically, as an agency, you’ll be bidding or pitching to a client to get the work. The client will probably be soliciting bids from multiple agencies, so you need to either stand out from the crowd in some way, or be the cheapest (or, preferably, both).
The client will generally be looking for a fixed price too, this is so they can go back to whoever is commissioning the work and get funding, or raise a PO or whatever.
Sometimes you’ll be given a brief, which you might then turn into a functional and/or technical spec, which then goes to the client along with the quote, then there’s some to-ing and fro-ing, an agreement and then work commences and oh shit, we forgot to add the widget to the spec and oh crap we underestimated the amount of data we’d need to use and have to re-engineer to use mongodb.
So, with this in mind, how do you estimate, quote, pitch or bid when agile methods are so fluid and you have to work to a fixed cost? You know the least about how long a project will take and what is involved right at the beginning. Using the Cone of Uncertainty, you’ll be between 4x and 0.5x inaccurate with your estimate of an end date (eg: at the beginning of a project that you estimate takes a month, it could take between four months and two weeks)?
Some metrics
There’s a few metrics you’ll need in order to derive costs from estimates:
- Day Rate: How much a team costs per day. This is only ever going to be a rule of thumb (as there are holiday, illness, training etc.). But you should make it as accurate as possible. This becomes a key metric in working out costs from estimates. You should make sure that your client understands that for the purposes of estimating and pitching, this is an accurate, but rough figure.
- Best, worst and average velocity: these are important metrics. Your average velocity is simple, add all your sprint velocities together and divide by the number of sprints. You could make this more realistic by using a rolling four sprint velocity, this then takes into account changes in team size, tooling or process. However, for the purposes of estimating the cost of project up front, the average will do.
The best and worst velocities are derived by taking an average of your three most successful sprints and the three least successful sprints. Why you need these will become clear later.
Should you have multiple teams and you’re not sure which team will be working on your project, then take an average across all the teams.
If you don’t have this data, you have two options: guesstimate, or use the cone of uncertainty.
Honesty and transparency
The fundamental tenet in any of these below strategies is complete honesty and transparency with your client. You’ll also need to invest three or four days (maybe less, it will depend on how practiced you are at this process, it will become quicker) in your client, it might sound like a lot and there is a risk there might not be a contract at the end of it, but it is worth it. Once you’ve deeply involved your client in the process from the start, they’ll feel like they’ve already started the project and so it’s easy for them to transition to being a paying customer.
From the outset, you’ll need to explain that you do things a little differently to other agencies. Whatever framework you choose to use (scrum, kanban, etc), spend some time explaining to the client what it is, how it works and why you use it. If you’re a little stuck, here are some ideas
- It gives you a realistic view of the progress and scope of the project.
- It gives you, as the client and stakeholder, complete control over what features make it into the final product and which don’t.
- It allows us to deploy features to live as soon as we’re ready to, meaning you can be getting value from our work and your product, even before we’ve finished it.
- These early and frequent deployments allow you to test your assumptions about your own users and customers and, if necessary, change the features or product without additional cost.
- You will be encouraged to be involved throughout the whole lifecycle of the project and can view each separate feature as soon as it’s finished to help guide and steer the project toward exactly what you want (which might not be what you originally asked for).
The best way to do this is to invite your client in for a half-day, high level training and workshop. Run some exercises to illustrate the key points and answer all their queries – this is a new thing for many companies who aren’t used to this kind of agile environment, so it’s definitely worth introducing your client to it if they haven’t experienced it before.
The next step is to create some artifacts. Once you have a brief in hand and have spent some time with your product team and analysts and have a really good understanding of the brief, the market, the competitors etc, invite the client in again in order to build a product backlog of user stories. Set the scene for them and explain that, unlike other agencies, you won’t write a functional spec, or a technical spec, because they’re a waste of time. What you will do is write user stories, which describe each feature from the users’ point of view and what value each of the stories will bring.
Labour the point too. Ensure your client *really* understands that you won’t be building ANYTHING that you can’t find the value for and WHY you take that stance. If a feature, or some functionality, has no value, then why would you build it?
Work quickly through the brief and your research and build a backlog of epics with your client. Don’t spend longer than an hour or two on this and, if you have somebody, get someone to facilitate the meeting so you don’t get bogged down in ANY technicalities, or discussions that are long or drawn out. Once you’ve got your list of epics, have the client order them – which are the highest priority things? What user/customer value do they want to deliver first? Don’t worry about dependencies right now, this is only rough.
Finally, break the highest priority epic into a few slightly smaller stories. This isn’t strictly necessary, but will help the client understand the process better. Again, this shouldn’t take longer than 30 mins.
The estimate and the pitch.
Now you’ve got your feature list of epics and some smaller stories for the highest priority, get some estimating done. I won’t cover it here, but you can read the article on white elephant estimating, or watch my presentation on agile estimation. Try and use the team that will actually be doing the work. If you haven’t got a team, or not sure which of your teams will be doing it, then pick engineers, designers and QAs from multiple teams – you’re only looking for roughly accurate figures. If it’s proving too difficult because of the epics, then break some into smaller stories – getting epics and stories sized well enough to estimate will become easier with practice.
Finally, you’re in a position to pitch, but how do you do it? It all depends on your clients requirements.
It’s very important that the client understands they have complete control over what goes into their product on a sprint-by-sprint basis. Explain that you expect them to be involved in the decision making about what goes into the product, the priority of the features to be added and the scope. So, once you’ve agreed on one of the below strategies and signed a contract, the success of the project will be partially down to their input.
Fixed deadline
If your client requires the project to be finished by a certain time, you can work towards that. It will be to your advantage to provide two estimates though, allowing the client to choose their own end goal:
All stories by the deadline
Estimate the number of teams or people required to deliver all the story points by teh date, then, based on a day rate, create a figure. Remember, to be accurate (but not specific), you’ll need to provide a range, so, using your best, worst and average velocity you can say to your client, “We ESTIMATE, it will take four months, but it could take up to five and half, but it could take three months, therefore, it will cost between £40,000 and £55,000″.
A valuable, shippable product by the deadline.
Do the same as above, but use a fixed sized team – you won’t be able to fit some stories in, but this is fine. Use the average, best, worst to show the client the stories you will definitely do, you will probably do, you might do and you won’t be able to do. This will reduce the scope of the project, but also the cost. Remind the client that what features make it into the product is based on their input.
Fixed cost
Working towards a fixed cost is quite rare, but does happen and it will likely mean that the client won’t be able to have all the features they’ve asked for. In order to work towards a fixed cost, you need to know it (obviously…). Once your client has offered this, you can use it to work out your strategy. It will be similar to working out a fixed deadline. You know how long you have to deliver the project based on the day rate (fixed cost / day rate = number of days). So, then you have a fixed deadline to work to and can use the average, worst, best strategy again to indicate what you can definitely achieve, what you can probably achieve and what you definitely won’t achieve.
Fixed scope
Finally, there is fixed scope. The client has to have everything they’ve asked for – in practice, during the project, this is rarely true once you start building and the early, regular releases helps steer the project.
Again, using your best, worst and average velocity, you can work out a range of how long it will take and then use your day rate to provide a figure.
Cost per iteration
(I wouldn’t suggest this method unless your client is particularly agreeable to trying new things, but, assuming you did the setup correctly I describe above, then they should be chomping at the bit to try this new, visible, transparent and honest method of commissioning software)
Pitch at a cost per iteration, instead of a day rate. You can give rough estimates on how much it will cost and these will become clearer after each iteration. Pitch for a minimum number of iterations after which your velocity will stabilize and you can be more accurate in the remaining length of the project. This is a fairly ambiguous method of pitching though, you’ll need to draw on the other strategies above to work out what features and functionality can be delivered, but if your client agrees to sign you for a minimum number of iterations, and you deliver what you agreed to, by this time, your estimates should be pretty accurate and your velocity very stable, allowing you to accurately cost any stories you haven’t managed to complete.
Using your average, best and worst velocity to predict a schedule
Honesty and transparency, again.
It’s worth reiterating here that you should be completely honest with your clients as to how complicated and amorphous quoting for a software project is. If you think your client can understand it, then break out the cone of uncertainty to explain that 40 years worth of data prove it to be true.
Explain that, being agile and adopting a framework to allow for short, deliverable cycles allowing for fast-feedback means that your company will very quickly start delivering visible value to them. It will also mean that they can control what that value is on an iteration-by-iteration basis. But, probably the best arrow in your quiver is to explain that, throughout the project, they can see the progress on an almost daily basis and adjust both what you deliver and how much they want to pay you should they need to.
If you deliver some valuable piece of software that causes them to change they way they think about their product, then they could pivot their entire offering and find more funding – and who is already in place to help them achieve that?
Hooray! We won the contract!
Congratulations! Now, don’t sit on your laurels. Remember the commitments you made to your clients during the pitch process and keep them involved through the project. Begin with release planning to decompose the epics into more usable stories and begin to uncover more of the project as you go, with milestones and deadlines if necessary. Keep your client informed, involved and in-the-loop and they’ll be happy when things change (and they will).
Boo, we didn’t win the contract.
Sorry, that sucks – but use it to learn a lesson. Find out why you didn’t win. If it’s just down to cost, then perhaps review your costs, or spend more time breaking down and estimating the stories to provide a more accurate figure next time.
Send out a survey to the client, asking them what they thought of the process and whether there is anything they’d change, or something they didn’t like. Gather as much data as possible, then spend some time retrospecting with your teams about how you can do it better next time.
My client doesn’t want to be that involved or isn’t interested in how we do it.
My advice here would be to not take on the business. If your client isn’t interested in being part of the process of building their product, then you are setting yourself up to fail. You’ll deliver a functional and technical spec detailing exactly what they want, you’ll deliver it and then find out that, while you delivered what they asked for, it isn’t what they wanted.
Finally
The old black box model of estimating and pitching for client work is difficult to manage, hard to sell and will bite you in the ass later down the line if you got it wrong at the start. By getting your client on board and understanding how you do things, and that they can and should be involved from the beginning to the end, you put yourself, your company, your team and, importantly, your client in a position to succeed.
What is best practise?
Practise, just that.
Wikipedia sez:
A best practice is a method or technique that has consistently shown results superior to those achieved with other means, and that is used as a benchmark. In addition, a “best” practice can evolve to become better as improvements are discovered. Best practice is considered by some as a business buzzword, used to describe the process of developing and following a standard way of doing things that multiple organizations can use.
This is my problem with ‘best practise’ – why is it called that? If it’s the ‘best’ way of doing things, why isn’t it just ‘practise’? Why do we have ‘good’ practise and ‘best’ practise? Would you use ‘good’ practise? Probably not, especially if there’s a better way of doing it, which is ‘best’ practise. So, if you’re only ever going to do ‘best’ practise, then it becomes ‘practise’, right? Then, if it’s just ‘practise’ then you wouldn’t refer to it that way, would you?
“How do you do stuff?”
“Oh, you know, with practise.”
I guess you can have ‘bad practise’, but then, that implies the opposite is ‘good practise’, which we just agreed you can’t have, didn’t we? Moreover, ‘developing and following a standard way of doing things that multiple organizations can use’ is silly, why would you do things the way other companies do things? This would just squash any chance of innovation; ‘That’s not best practise! Other companies aren’t doing that!’ dumb, dumb, dumb.
Let’s stop worrying about ‘best practise’ and just get on and make the way we do things better through regular reflection.
Should I start with scrum, or kanban?
or, Should I transition from scrum to kanban?
Adventure lies EVERYWHERE! Image by Daniel Voyager
We’ve been doing scrum at Affiliate Window for a couple of years now. We go through the inspect and adapt cycle regularly and we’ve made few, if any, changes to our process, only our engineering practices. Recently, however, we’ve been working on a couple of projects which have required some groundwork and lots of backend work. This kind of work doesn’t really lend itself to the ideal of having something to show the stakeholders at the end of every iteration. We still have the review, describe what we’ve done and then take a look at the backlog with the stakeholders to decide what the priorities are for the next iteration.
This has raised a question from one of the teams about moving over to kanban and it got me thinking about what organisations can do to start on an agile journey, should they start with scrum, or kanban? What about established teams? Can they transition from scrum to kanban, or vice versa? Why should they? Should they even do it?
Now, there’s no reason why you can’t continue doing scrum (which is what we’ve decided to do), even with backend heavy work. Afterall, it’s simply a framework designed to offer constraints in order to create fast feedback (amongst other benefits), but kanban is attractive in that it allows you to decide when you demo/review and so gives you the benefit of time in order to actually have something tangible to show the stakeholders. Kanban is also attractive for those coming to agile afresh. It allows you to start integrating some agile practices and get a view of your issues (in order to solve them) without changing your heirarchy or existing process.
For Kanban to really work, you need to make sure you’re setting up a pull system that describes your entire process, from inception to delivery – not just a column based todo board (which, unfortunately, you see a lot described as ‘kanban’). To be able to do kanban well and retain the holistic view of your work required by the product team to make educated guesses on delivery and suchlike, the team needs to be mature enough to do kanban well. This means; mapping out the different states in your system, working out WIP limits and, importantly, deriving cycle time (how long it takes an item on the board to get from left to right) in order to estimate delivery/scope/cost etc. Herein lies the rub (I’ve always wanted to put that in a blogpost!).
If you’re not able to use scrum to help you deliver backend-heavy, large work items, then it’s unlikely that kanban can help either. The constraints of scrum help you stay on target and be accountable for what you have or haven’t done and make tweaks and adjustments to perform better in the coming iterations. Once you’ve nailed scrum and you have a product backlog with well defined stories, which are easily estimatable, then you’re ready to mature to a really valuable, efficient and data-driven kanban implementation. Eventually, when you’re able to size your stories all the same, you can do away with estimating as your cycle time will remain constant. Allowing you to set regular reviews and inspect/adapt cycles. You’re one step closer to programmer anarchy!
So, should you start with scrum, or kanban? Kanban allows you to start your agile journey without upsetting the status quo; you don’t change any names, or add/remove roles. You simply illustrate your process on a big visible board and become accountable, as a team and a company for the work you do. You can implement any agile practise you like (standups, backlogs, user stories, etc) and see how they work for you without rocking the boat. Scrum, on the other hand, requires a reboot and an installation of a new process, one with constraints *built in*, but the benefits are numerous and valuable right off the bat.
Should you start with scrum, or kanban? The answer, I think, is ‘it depends’. If your organisation, including those at the top are comfortable with scrapping your current process and starting something new, even with it’s inevitable lead time, then go for it. Use scrum and the constraints will help you become agile. If your organisation is reticent to start, or you have buy-in from teams, but not the business, then start with kanban. It’s lightweight and non-intrusive and will still allow you to raise your impediments and issues (but solving them often requires bold and honest action, beware!).
Should teams transation from scrum to kanban? Probably, but make sure it is for the right reasons and that your team is mature enough to make the most of it, if you’re not sure, then try transitioning via scrum-ban, it’ll help you see the benefits and enable you to get better at the things which make kaban most useful, without changing more than you are comfortable with.
I’d be interested to know how others started their agile journey, or whether many transition from scrum to kanban (or the other way). Drop me a mail, tweet or leave a note in the comments!
Agile core values: Individuals and interactions over processes and tools
Actual is not Normal
The four core value of the agile manifesto are values which I strive to live by, both at home and in my personal life (where it fits, my wife doesn’t care how I write a birthday card, just that I do (although, I suppose that fits too!)). It’s the very core of my job as an agile coach, so I though it was a bit time I wrote a few articles exploring them and what they mean.
I really should have posted this sooner, but, for some reason I haven’t. I think, mostly, because I realised that I needed to get a better understanding of what the values (and principles, but they’ll come later) really mean. While I recognise that being agile is not a destination, but a journey (cheesey, right? But true). I think my understanding of them is now deep enough to write about them, so, without further ado, I present the first in a set of four articles…
Individuals and interactions over processes and tools
I struggle to believe that, in any organisation, there are people that think there is anything that is more valuable than it’s people. If you’re in one of those organisations, then, it’s probably time to look for a new job.
People are the one most important asset in any organisation and the key word here is ‘individuals’, no one wants clones working for them and the more diverse the people you work with are, the more satisfying and fruitful your work life should be. Having an interesting and diverse set of colleagues makes it that much easier to get up and go to work in the morning!
One of the mistakes that I often see made (and, unfortunately, perpetrated by a lot of online and digital scrum tools) is forcing yourself into using a process. It’s interesting to note that the two most popular agile methodologies don’t prescribe any particular process to follow with software development, but people believe that they do. Kanban, for example, is not just a board with a ‘todo’, ‘in progress’ and ‘done’ columns. Each column marks a step in your process. The process you already have. Scrum also doesn’t tell you how to build your sprint backlog, instead, it just says you should have one and is quiet on what you should put on it (with the exception of the sprint burndown, but that isn’t a process, just a tool).
Most companies will already have a process for the way they write software before they begin their journey toward being agile. Sometimes it might be as simple as describe, develop, deploy. Other times it will involve review, QA, regression, analysis etc etc. When you start your agile journey stick with the process you have, don’t make things harder for yourself by changing too much. Introduce the framework of choice and use it to help you see where your problems lie. Then, slowly, organically and by small, incremental changes begin to adapt the process you have into one that allows you to align with the agile principles and create great software (or any other product for that matter).
The point of this is that, really, the process doesn’t matter so much as the people using and creating the process. The tools they use don’t matter as much as the indiviuals working together to create the process and create, or use tools which support their endeavours. Having a process is important, but not as important as the people in your organisation using your process and adapting it to suit their needs in order to attain the principles of being agile. Having tools is important, if they’re the right tools, but not as important as how you use them and what you use them for.
If you’re somebody looking to implement agile in your organisation, or someone trying to make your organisation adhere closer to the agile ideals, then empower your people to improve themselves and their process and then leave them to it.
Hire good people, then get out of their way.
–
So, that’s the first core value. Next time, working software over comprehensive documentation.
10 Reasons why using a whiteboard is better than a digital tool
I’m a big fan of whiteboards. I’ve got a bit of a reputation at work as someone with an unhealthy desire for many whiteboards. As I sit here, I can see seven. There are three more in the office I can’t see and another four waiting delivery.
"Buy whiteboard: done" by Mark.Pilgrim
Ron Jefferies speaks at length about how big visible charts are a “good thing” (he echos Alistair Cockburns sentiments on having Information Radiators) and so, in the name of throw-away blogging, and because I don’t have any link baiting “10 reasons why… ” posts, I thought I’d add one. 
- The elephant in the room.
Whiteboards are there in the room with you. You can’t do anything without having it there, reminding you it’s there and what is on it. With a digital tool, you need to go and find it, on the web, on the intranet, on demand. - The ice breaker.
They start conversations. People will gather around a whiteboard (especially if it is a sprint backlog) and discuss its content. - The flexibility.
Things can be changed, moved around, re-ordered, annotated, etc etc without fuss or hassle. - The process.
The manifesto says “Individuals and interactions over processes and tools”. Use the flexibility of a whiteboard to help hone your process, before committing to a tool which defines a process for you. The structure can be changed REALLY easily. Need a new column? Different chart? Another colour? Silly picture? Stick it up there, instantly with a pen. You’ll probably need to program, request or configure these changes with a digital tool, which takes a LOT longer. - The culture.
They help a team define their culture. Each sprint backlog whiteboard where I work is a little artefact which reflects the culture of the team and it’s members. One is clean accurate and ordered neatly, another is messy and colourful with pictures of Transformers. You can tell a lot about a team from the sprint backlog whiteboard. - The collaboration.
Product owners, stakeholders and interested parties can see what a team are up to and, importantly, collaborate with the team as they’re standing next to them when looking at their board. - The disposable information.
You only need to measure something for as long as it is useful. Need to chart the performance of your tests over a release period? Perhaps you want to chart users of a particular feature temporarily? The whiteboard allows you to track this information, with no overhead and comparatively little investment compared to a digital tool. - The doodle.
If you’re trying to explain something to more than one person, a doodle, or sketch may help (especially in development, when you might be describing a class structure, or some architecture). You’ve already got a whiteboard in your team area for your sprint backlog, use the other side? - The wheels.
I advocate whiteboards on wheels, these can be dragged back and forth between the team area and meeting rooms if needed. You don’t have to worry about logging in to a meeting room PC, getting the digital tool up, logging in to that, then increasing the resolution, or zooming with the browser so everyone can see, then clicking to the right section then … you see what I mean? Take your whiteboard and your pen. - The end.
Often it’s nice, when you reach the end of a release window or the end of your tether, to just wipe the board clean and start again. Get some solvent, give it a good clean, redraw your columns and start from fresh. It’s cathartic and cleansing.
Timeboxes, more than just a buzzword?
Little Baby Timebox! - Image by sⓘndy°
I read in my twitter stream today, this from @lloydwatkin:
lloydwatkin
I really hate bullshit phrases used in tech, my latest word of hate is ‘timebox’
04/05/2011 15:16
and it got me thinking about time boxes. I use the word a lot and use the concept of time boxes in almost everything I do and Lloyds comment made me think “is this just a bullshit idea, or just a bullshit word, or bullshit in general?”
When meetings suck
I don’t know about you, but I’ve sat in my fair share of meetings that totally sucked. No one really had much to say, the conversation goes off on tangents, someone announces that we can’t talk about that now as it’s part of a ‘series of conversations that we need to have’ and everyone inwardly groans. There’s no agenda, no action points … nothing. Usually one person will dominate the room, quacking on as if they love the sound of their own voice, making statements based on little more than opinion, causing everyone in the room to raise an eyebrow and, maybe, an eye from their game of Angry Birds under the table. People pretend to take notes on their pads on their knees, when really they’re drawing larger and larger concentric circles and colouring every other one in while perhaps writing a poem, or ode to boredom*.
These are the meetings that everyone hates, when there are too many people, no agenda and people prone to waffling about shit only 20% of the room understand or care about. How does time boxing help here?
An agenda is a time box. If you’re booking or facilitating the meeting, you’ll find that an agenda and the authority to chair the meeting are all you need to have a successful outcome (assuming you have an idea of what the outcome should be). When you book the meeting, set the agenda in the meeting request:
00 – 10mins – Welcome and introduction
10 – 20mins – Talking about the herping
20 – 30mins – A demonstration of the derpa-machine
30 – 40mins – The future of the thing
40 – 60mins – Q&A, action points and AOB
These are time boxes. Maybe you don’t call them that. Most people call them agenda points and many people will leave off the timings, but by adding the time boxes to it, you’re subconsciously telling the attendees that, unless something extra happens, this is what we’ll discuss and this is how long you can expect it to take. If 50% of your attendees don’t care about the herping and 50% don’t care about the derpa machine, then those people know exactly how long they can draw concentric circles or play angry birds for. Or, they’ll know they only need to give 10mins attention to something they’re uninterested in and that’s better than 60mins attention to find the 10mins you’re interested in. Doing an agenda will also give people time to think about what they should be doing to prepare for any, all or just their part of the meeting. Finally, by setting a perimeter around an acceptable length of discussion time gives you the authority to say: “OK, we’ve run out of time for that agenda point. Batman and Spiderman, if you have more to say on this matter, please book another meeting and invite those people relevant. OK, so onto the next point…”. Trust me, people will be relieved.
So, by simply adding some timings to your agenda (which we can agree are useful) you’ve created time boxes. Things look good for time boxes so far.
What about meetings that can’t have an agenda?
Well, some meetings can’t. In SCRUM there are two that definitely don’t have any kind of official agenda; retrospective and sprint planning. Retrospective is a meeting where the team discusses HOW they did the work in the last sprint and what could be done to make it better. Generally, this involves everyone taking turns to say what they though was good, bad and how they think it might improve. Timeboxing here lends itself well in that, you divide the length of the meeting (in minutes) by the number of people and that’s how long each person get’s to speak for. They’re each time boxed. If there are six people retrospecting for an hour, they get 10 minutes each.
As for sprint planning, you can do the same with each section and then the stories. You’ll have to play with timings, but I suggest:
00 – 10mins – Cocking around that devs do getting coffees etc.
10 – 3omins- Quick groom of the backlog
30 – 60mins – Work out velocity and commit to stories
60 – 240mins – This is where it get’s fuzzy. It all depends on how many stories you’ve committed to. If you’ve committed to, say, three. Then divide the remaining time by three and get on with it. If it’s many stories, then perhaps set aside 45mins for the first story, 30mins for the second and 20 mins for the rest. Remember, you don’t have to do all your planning up front!
So, score two for time boxes. Without time boxes, sprint planning would but much harder and probably longer. Besides, they’re also one of the basic rules of scrum!
But that’s not all…
When scope creeps
![Col. C.B. Winders [i.e., Winder] (LOC)](http://farm3.static.flickr.com/2349/2162738187_ce0b133a3b_m.jpg "Col. C.B. Winders [i.e., Winder] (LOC)")
Mah Scope Don't Creep Suh! - Image by the Library of Congress
If you’ve been in software or web development, you’ll have been a victim of scope creep. You get the list, you work your way through it and, all of a sudden, you’ve run out of time.
“But wait, ” you say, “surely time boxes cause this ‘lack of time’ problem.” Well, yes and no, but they definitely provide you with a reason NOT to do the stuff that has crept out of scope. Scrum is based around the idea of time boxes. Without them there wouldn’t be iterations. An iteration, or a sprint, is a timebox. Sprints don’t get extended, or shortened (although they can be cancelled). At the beginning of a sprint, the team commits to a bunch of stories that the product owner wants done. They work on them and, when nearly finished, will show the product owner or stakeholder who might say “Hey, that’s nice, but can you…” . To which you answer…
“… No, but if you wait unti the end of the sprint and ask me, I’ll do it then.”
Anybody reasonable can see that it’s a good compromise: work has been asked for that is clearly out of scope. The developer doesn’t have time to work on it during this timebox, but the timebox is there, defined and immutable, therefore can be used placeholder for when the work CAN be done (apart from the fact that the extra work needs a user story and estimation and prioritisation etc) and the stakeholder or product owner only has to wait until the end of the sprint (the maximum wait will be two weeks). Usually, by that time, they decide it’s not a relevant change anymore, or it was so insignificant as to be forgotten.
The point is, it’s there to add some boundaries, to protect the developers from scope creep and to protect the stakeholder from adding work that isn’t well thought out or valuable (this is quite a simplistic view, but it proves the point of the value of time boxes. Obviously, lot’s more comes from the scrum framework in order to derive value, but out of the scope (fnarrr!) of this article).
Right, so that’s three for three … next!
When the kitchen is a mess
So, when I said I use time boxes in almost everything I do, I meant it. I mean even my personal life and I suspect you do too (even you @lloydwatkin!). As an example which is fresh in my mind from last night: I was tidying the kitchen and had set myself some time boxes: 10mins to wash up, 5 mins to clear and clean the table, 5 mins to sweep the floor and 10 mins for extra stuff — 30 mins to clean the kitchen.
With these time boxes set for myself, it become a challenge to get this stuff done in those time boxes. And lo and behold, it takes 30 mins to do a chore which might otherwise take me an hour and a half (most of which would be procrastination). It also stops me from doing too-much-work (K.I.S.S!) as I might put something in a cupboard and think “Hmmz, that cupboard is a mess, I’ll just give it a quick tidy.”, et voila, scope creep.
Finally, time boxes aid immensely with parenting. If you’re a parent you’ve probably said (or shouted): “10minutes until bedtime!” and this creates an unwritten expectation (much like the meeting agenda or the sprint length) that, at the end of 10 mins, some action will happen (bedtime). Instead of the ambiguous “Bedtime soon!” which leaves it open ended and easy to abuse.
What to avoid
Boyles law states:
For a fixed amount of an ideal gas kept at a fixed temperature, P [pressure] and V [volume] are inversely proportional (while one doubles, the other halves). – Wikipedia
Which means, gas will expand to fill available volume. This law can also be used to describe development:
For a fixed amount of ideal developers kept saturated in caffeine, velocity and time are inversely proportional.
Which means, work will expand to fill the time allocated to it.
This is not always true, but you should be wary of it. Some teams will feel that, they have two weeks, so they can take it easy if they’ve underestimated a story or two. This is not fine. Velocity should remain constant. If at any point your teams feel they have undercommitted, then commit to more, or do something with value to the team – rebuild a tool, or refactor some code or SOMETHING and perhaps next time, commit to a little bit more and see if you can stretch a bit further. It’s a limbering excercise.
A time box is a limit, not a goal. If you’ve got a 10 minute time box in a meeting, or elsewhere, you don’t have to fill it, you just have to have finished within that time box.
Being agile
Some time ago I held an Agile Dojo at Affiliate Window. It was an entire morning of grass-roots agile training, taking the department back to basics and helping them (and me) understand what ‘Being Agile’ means, there was an accompanying deck of slides, which I’ve redone in full on technicolor and without the need for me presenting them. This was for new starters and those that missed the session or needed a refresher. I thought I would post to slideshare in order to make it easier for people to view it, then I figured I’d post it here too.
Kanban: not what I thought it was…
Production Line Model. Photo by Mr Wabu
So, next in the series of things that are agile, I’ll be looking at Kanban. For the longest time, I had no idea what kanban was and I would bandy the word about like I knew what I was talking about. In my head, it was putting things in a Kanban board and that was it, but it’s way more than that.
It was born in Japan, coming from the Toyota Production System and comes from a desire to minimize waste (see the previous Lean post). Kan means “visual” and Ban means “card”, “board” or “note”.
Imagine, if you will, a car production line. Any car will do, but, as we’re talking about Toyota, let’s talk about an Aygo (I think they’re ugly, but you can park them under the stairs and you don’t pay congestion charge so, whatever). Your job, on the production line, as you’ve yet to be replaced with a Cyberdyne systems robotic arm, is to put the bonnet on these cars. So, a car rolls onto the platform in front of you and you pick up a bonnet from your pile of ten, pick up a screwdriver and fit the bonnet. Well done you.
The next car rolls up and you do the same, then another, and another until you’ve fitted five bonnets. The 6th car rolls onto the line in front of you and you turn to pick up a bonnet and notice a card on the top of the your 6th bonnet. It says “Order 10 more bonnets now.” and a bonnet id number. So, thankful for a break, you pickup your card, go to the guy who makes bits of cars and hand him the card. He’s just got back from delivering windows to someone and he says thanks and begins making bonnets.
The important thing to notice here, is that he hasn’t got any bonnets for you and the last thing he was doing was making and delivering windows for someone else. He isn’t making bonnets yet, because you don’t need them yet. He hasn’t got any “in stock” because you don’t know you need them yet.
Off you toddle, back to your car and carry on fitting the sixth bonnet. The moment you’ve fitted your 10th bonnet, a trolley arrives, pushed by the guy who makes bits of cars and on it is 10 bonnets. While you’re waiting for the next car to roll onto the line in front on you, he stacks the next 10 bonnets where the previous 10 were, slips a new card in between the 5th and 6th bonnets and goes back to his cage to await the card from the next person needing bonnets (or doors, or windows).
In a nutshell, this is Kanban. When you need something, you go to the next step in your process, ask for it and someone gives it to you. You put a “kanban” in their box and they deliver what is required. It’s a pretty simplistic description of it, but that’s what it is. At any one time, there are no more than 15 bonnets in existence. This is the maximum amount of bonnets ever needed at one time and, because there aren’t bonnets hanging around, waste is reduced. What we’re doing here is limiting the amount of work in progress. This is lean; why would we need more than we can actually use?
Kanban board by orcmid
In software development, the Kanban “visual board” is just that, it’s a board you put somewhere with your story cards on it. Because software development doesn’t generally involve bonnets or doors (but it does involve Windows *shudder*), we don’t need to have cards placed between things to be found by our workers. Instead, we put eveything on our board. How your board looks is going to be up to you. Afterall, you’re the owners of your process, right?
When constructing your board, make sure you put a column for each different state, or step that your stories have to go through. Bare in mind that you’ll need a column for the status of the story; from conception through to done. For now, we’ll ignore the idea of ScrumBan, so no tasks, or sprint backlog. I’ll come back to ScrumBan in another post.
So, you’d have a column for your goals. I’d like to coach teams to work to a three month release window. The goals you’ve set for that three month period, should be in the first column. This is for information and just limits “thrash” (as used by Arlo Belshee).
The next column might be a new column. Like our bonnet guy, you might want to limit this to 10. Your mileage may vary though and you’ll want to try out different numbers seeing how you go. From the new column, your story might go into a requirements, or honing phase. You should apply a Work In Progress limit (WIP Limit) here too. To start with, try half the size of your New column WIP, so, in this case, five. This column is where your product owner would clarify what the stories mean and write the acceptance criteria. Perhaps do mockups, or at least write a document describing the interface or requirements.
Next up would be a “Development” column, the WIP here could be three, again it will depend on the size of your team(s). After that, maybe you’ll have a review, test and done columns, each with their own WIPs. The point here is that your board is unique to your process. Kanban isn’t a process, Kanban helps you highlight your process to reduce waste and spot bottlenecks. The great thing is you can introduce Kanban and it doesn’t threaten anyone or anything. You still do the same thing as you were doing before, process wise, it just forces you to have a visual representation of your process, and this is where it helps you cut out the chaff. Run your Kanban board for a while and take note of what happens. Soon your bottlenecks will be totally visible, if you’ve always got three stories in your “Test” column and the developers can’t move onto the next story because they can’t go over the “Test” WIP limit, then you know the bottleneck is with the testing.
If the board looks like it’s running well, but something is still a bit off, then perhaps be a bit more granular with your columns, can you split the “Requirements” into gathering and documenting? Or can you split the “Test” column into “automated” and “regression” columns?
Waste: you don't want it (by cliff1066)
Soon you’ll see where your bottlenecks are and you can fine tune your process to reduce waste. Record your progress now and after you’ve fine-tuned to see whether your changes were successful. Agree with your teams and the powers that be you’re not going to make huge, sweeping changes overnight. Help them understand that, now you can see the process, you can make gradual, incremental, evolutionary changes that means everyone keeps their jobs, but the process get’s better and creates less waste.
According to Wikipedia, this stuff can be broken down into four core components, I agree with the breakdown, but I’ve provided my own examples:
- Visualise the workflow (but it on a board!);- Limit Work In Progress (stop doing so much, only start when you’ve finished and don’t have waste lying around gathering dust);- Mange Flow (Make sure you’re recording your changes and the impact they are making so you can prove whether your changes worked);- Make Process Policies Explicit (Stick to the process on the board. Anything you do that isn’t written done but done “because that’s how you do it” should be written down and shared, some people will go “Oh, THIS is how we do this? Great!”);- Improve Collaboratively (Improve, yes. Do it with your teams, yes. Then read some sciency books about the Theory of Constrant or the Lean Economic Model … or don’t, your process won’t suffer!).
Remember, Kanban isn’t a process and doesn’t use timeboxes, it’s about visualising a process and using that new information to reduce any waste your process has.
Thank you Toyota.
Lean Software Development
Coach by bfishadow
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.
Eliminate Waste
And If I'm Wasting My Time, Then Nothing Could Be Better by Grahambones
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.
Amplify Learning
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
Late Again by Andreas Jalsøe
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
Empowered by Search Engine People Blog
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.
So…
communes, law & common sense by cdrummbks
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.
