BDD: Starting With Quality
Quality with a star and stuff
Quality isn’t defined by a lack of defects or bugs. You wouldn’t get a cup of barista coffee and exclaim, “This coffee is quality because it doesn’t have a problem with it.” (No bugs in my coffee). You can get a cup of coffee from a petrol station that doesn’t have any problems with it. It’ll be hot, wet and coffee flavoured – there are no defects with this coffee. So, where does this idea of the “quality” of something come from? It’s a subjective thing. A quality cup of coffee to me may not be the same quality cup of coffee to you. If you favour a black americano, your definition of quality is not going to involve a milky heart drawn into the top of it, which is how I like my coffee.
When we talk about the quality of a feature, the fact that it doesn’t have any defects is an implicit part of that quality, but it’s not where quality starts or stops. What makes the quality of a feature is whether or not it does what it’s supposed to do and whether it provides the amount of value to the user that they expect. Again, this is different depending on your context: what you application does, who it does it for and why.
Quality Assurance (QA) plays a fairly key role in any software development team. I know some schools of thought suggest that there shouldn’t be a QA role, and while this is probably the subject of a separate blog post, I feel that this is wrong. We have a QA in the team, just the same as we have a designer in the team. It’s a specialist role that requires certain skills I don’t expect engineers to necessarily have.
That said, I’ve always been troubled with the way that the QA role is executed in a team. Let’s suppose that we’ve got a scrum team that performs well. They commit to a given number of independent stories, work on them sequentially, so they finish the first story before starting the second and so on. Once the feature has been completed, the work of the QA starts in earnest (until that point, the QA will put together a test execution plan and a strategy for dealing with the tests during the sprint). They will begin exploratory testing and creating or updating automated tests. This is all well and good and will ensure that the feature meets the minimum, implied, level of quality. In most cases, it’s enough that it’s free of defects.
For me, this is where the problem lies. But how do we solve the problem?
We realised that actually, we never really discussed what quality meant to a particular story or sprint. We had made assumptions about the quality based on the content of the story and the acceptance criteria. As long as the story met those acceptance criteria and didn’t have any defects, we assumed we were done. In reality, we weren’t really thinking about what constitutes quality but just what constitutes the feature.
So we decided to start with quality. It made sense to talk about what we thought quality meant to any particular story before we talked about anything else. At the beginning of planning a story in sprint planning, we would spend some time discussing what quality meant to this feature. Using the example of a login screen, the story might be:
- As a user,
- I need to log in to the site,
- to access all the features.
Before we chose to start with quality, we might discuss what the feature looked like, or we may already have a design for it. But then we’d just jump straight into the technical planning: how do we implement it, what code do we need, database schemas – that kind of thing. Instead, now we talk about the feature from a users’ point of view:
- What happens if they get their password wrong?
- How do they reset their password?
- How long should the password be? Should it have characters?
- What happens if a user doesn’t have an account, how should we direct them to sign up?
- What kind of error messages do we want to show?
- Etc.
This opened up a whole new discovery phase. Product Owners cannot think of everything when writing stories and this discovery allowed us to offer our insight into how the feature works, ask questions about how it should work and these are often based on technical knowledge of the platform that the Product Owner may not have. We began by adding these new requirements to the conditions of satisfaction, but they soon become long and arduous to check. So we looked for a better solution than acceptance criteria.
The solution we chose was to use a new tool. BDD (Behaviour Driven Development) is a method of functional testing which allows you to describe the functionality of a feature in a “scenario” file in plain english:
- Given I am on the login page
- When I enter ‘mikepearce’ into the username field
- And I enter ‘butteryballs’ into the password field
- And I click “login”
- Then I should see my dashboard.
We can then use a BDD framework to run these scenarios against our web application. We use Behat as a framework and it works really well (apart from our problem of data fixtures…). It pretends it’s a browser (and, will use Firefox if it needs to work with javascript) and does what your user would do with your system. This allows us to have automated functional testing too. Awesome.
So, when we’re doing this extra discovery step, we record our findings as these step definitions, instead of acceptance criteria:
- Given I am on the login page
- When I enter ‘mikepearce’ into the username field
- And I enter ‘wrongpassword’ into the password field
- Then I should see the message ‘Sorry, your password is wrong’
- And I should see the link ‘Did you forget your password?’
We slowly build up a specification file for this feature, which is mostly centred around the “happy path” and add edge cases or problem scenarios if we think of them. It’s important to note that we don’t expect to think of EVERYTHING in this session as we time box it to ten minutes and expect other features or ideas to emerge during the sprint.
Once we’ve finished, we’ve got a specification file that we can run against the web app with Behat. The first time we run it, it will fail, because the feature isn’t there – but this is good! This is Test Driven Development for the masses! As the team slowly builds the feature and keeps running the Behat tests against it, it will slowly become more and more green. If new things emerge during the sprint, we add extra steps to the scenario file. By the end of the sprint, all Behat tests will be green and we can have confidence that, not only is the feature defect-free, but it also does what the user expects it to and provides them value.
So, now we have a way of assuring that our software has quality. Not only do we have a slick set of automated functional tests, but we’ve also added a low-friction, low effort step of discovery that allows us to really understand AND define what quality means to us in the context of this feature for our product.
I’d encourage you to try this in your teams. Actually having Behat (or any other BDD framework) isn’t really a requirement to get started. You can start by just writing your scenario file as the first step of your team planning a story and storing it somewhere for future reference. The value is in the discussion you have to define the quality. The artefact you create is useful afterwards for checking that you meet those requirements. The added benefit is that it’s written in a language that anyone can read – from your team and product owner, to stakeholders and anyone else in the business who is interested to learn more about your product.
(The benefits of using BDD are outside the scope of this article for more than I’ve described, there are plenty of articles on the web to suit your style, language and infastructure and I would encourage you to learn more about it. Start with this presentation from Gojko Adzic and this from Dan North)
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.
Mad, Glad, Sad retrospectives
I help my first retrospective for a while recently (that’s not to say the team hasn’t been retrospecting, just that others have been doing it in my stead!) and the team wanted to do the Mad, Glad, Sad exercise.
Shockingly, I didn’t know it. Or at least, I didn’t think I did.
The exercise starts with everyone writing on three different coloured posts-its the things that made the mad, glad or sad during the sprint. We then stuck them all up on the whiteboard under an appropriate picture.
We all studied it for a while, but I couldn’t really work out what the difference was between mad and sad. The idea of a retrospective is that you inspect and adapt. Look at what you did, how you did it and change things if they need improving. The idea of mad and sad should be things that, affected us negatively that we want to change in future sprints.
But what is the difference? I asked the team. They didn’t know either.
So, we set about trying to decide what each thing meant. In many retrospectives in the past, we’ve realised that there are things that went wrong, didn’t work or just plain sucked that we could fix and there were things that can be classed as ‘Shit Happens’. Stuff that, while we might expend some effort in fixing them, are unlikely to occur anytime in the near future, so we draw a line under it and move on – there are always more pressing things to deal with.
So, using this idea, we renamed Sad to “Get stuff off my chest” and Mad to “I’m not going to take it ANYMORE”.
This means, we can highlight things that annoyed, frustrated or saddened us, but that, realistically speaking, there isn’t a lot of value in dealing with and then the stuff that REALLY got under our skin and we have to deal with.
Once we’d renamed them, we then re-sorted the post-its we’d stuck under the two columns and found that, things we might have dealt with as a real problem and spent time working on, were no more than just people wanting to have a rant, and real problems might have been overlooked as they hadn’t been applied with enough gravity. Perhaps the team member feels that it’s just something bothering them and doesn’t want to make an issue of it.
We worked through all three columns and, during discussion, decided to move some from Sad to Mad and vice versa as we discussed the pros and cons of each. In the end, we had a good, solid list of things that ‘we’re not going to take ANYMORE’ which turned into a list of definite actions.
So, if you run this exercise with your team, check their and your assumptions about what Glad and Sad mean – you may be met with blank looks – and make sure you all have the same understanding to make a good exercise into a great one.
Have you read the manifesto?
I sometimes wonder whether people have actually even read the Agile manifesto. It is made of four core values and 12 principles, I won’t paste them all here, you can find them at the above link. Maybe the principles are hard to find, but you can read them here.
That’s all there is to it. Agile isn’t a “framework” or a “methodology”, if anything, it’s common sense. Common sense described in four values and 12 principles.
Agile is not a synonym for scrum, or kanban, or anything else. The term “Agile” shouldn’t be used as a description of an all encompassing set of practices that it doesn’t describe. For example, what does “Agile adoption” even mean in this context? Does it mean you’ve finally decided to use common sense? No, it means a company is adopting a framework or methodology that is inspired by the Agile manifestos values and principles, such as Scrum.
Agile is a mindset, a way of being. So please, stop posting things about how “Agile has failed”, or “Agile does damage” unless you actually mean that common sense has failed, or common sense has caused damage. Which is unlikely.
Remember, you don’t DO agile, you ARE agile, it’s a way of being, not something you do.
The one with George Osborne and the right to flexible working
Look! I’ve got nothing up my sleeves!
So, George Osborne today announced that, in exchange for between £2,000 and £50,000 of shares, employees can relinquish some of the rights they have as employees. These rights are; claiming unfair dismissal, redundancy, time-off for training and flexible working. There’s also an extra right to relinquish for women, which is to give 16 weeks, instead of 8, notice when returning from maternity leave.
Essentially, what Mr Osborne is saying is that you can either be a) ejected from the company with no recourse or b) imprisoned at your company with no way out for some figure between £2,000 and £50,000.
I understand that this comes down to a matter of ‘shared-ownership’, meaning that, now you have these shares, it’s up to you to do the very best you can to make the company a success, afterall, if the company is a success, you’ll do well too. I also understand that this is voluntary for existing employees, but could become compulsory for new employees, should an employer choose to do it that way.
What I don’t understand is how on earth he thinks this is a good idea? Claiming unfair dismissal is what protects employees from the pointy-haired bosses who surround them. Redundancy, unless political or strategic, would indicate a company not doing so well (so, who would want shares?). Training is important if you want to retain, improve and increase the value of your staff and flexible working? What on earth does he mean?
For some shares, you get to give up the ability to work from 9 – 5:30, every day in the same office? What a marvellous idea! Let’s ignore the fact that people don’t all march to the same drum – folks aren’t productive when you want them to be, they’re not creative when the clock showing a specific time. Let’s ignore the fact that people have children, families, teeth, health and the multitude of other things that mean working 9 – 5.30 is difficult and a dumb idea. Further, we should force people into thinking that spending time in a particular location, between particular hours is a measure of how well they’re working. Let’s completely ignore the fact that by focussing on WHEN we are, we cannot focus on WHAT we do. Business should focus on results, not hours.
This new proposal from the CHANCELLOR OF THE EXCHEQUER clearly shows that he has almost no idea how business works in the 21st century. Stop trying to apply old fashioned, often Taylorist views, on how you think businesses should be run and be forward-thinking, pragmatic and revolutionary in helping small- and medium-sized businesses achieve greatness.
Who tunes the guitars?
You need men like this, otherwise live music would sound awful.
I read a lot of blog posts, articles, papers and what-not on creating, maintaining and coaching teams. It’s the one thing that, for me, has no set formula. Each team is different, as they’re made from different individuals, each with their own set of morals, ethics and experiences that drive their behaviours. There is no ‘one-size-fits-all’ team guide, unfortunately.
So, what we’re left with is a miasma of different works, all decrying or promoting some way or other of how to form and maintain a team, how to help them become high-performing, how to retrospect, plan, work, play, love, eat, argue and play football together. None of them are right and, equally, none of them are really wrong. But the one thing I see frequently is suggestions, and often demands, that “if they don’t fit, you’re hiring wrong/replace them” and this is alarming.
The common theme I see is that, yes, there IS a formula for creating the winningest team and, if one of the members of the team you’re trying to engineer to stardom doesn’t fit your mould, then he’s out on his ear … hit the road jack, your awesome-coding-but-complete-lack-of-personal-skills ass is outta here!
Not everyone can be a rockstar, you need some roadies too.
Perhaps you know someone, or have someone in your team who doesn’t really have any great ideas, isn’t that keen on researching the latest javascript framework or building some wanky Hipstagram filter in Ruby, but who can build a data abstraction layer, fully unit tested in a day and always reviews your code and finds the one or two things you missed. Where would you be without this guy?
Or maybe there’s the guy who just REALLY enjoys honking about with MySQL queries, doesn’t really give a rats ass about what the business does, but cares deeply about the quality of his code and making his queries elegant and fast.
Some of you may know the guy who get’s a real kick out of cutting HTML all day, taking the photoshop files from your rockstar, sweater-vest wearing, macciato drinking, fixie-bike riding designer and making a cross browser compliant, responsive and even working in IE.
These guys may not be the fastest, or the bloggiest, or the githubbiest, they may not even really get on that well with agile estimation, sprinting or ‘stakeholders’, but they’re rock solid and dependable.
Everyone has a place, even if they’re wearing a christmas sweater in June, they’re part of your team. Find a place for them, or, better yet, let them find their own place and do what they do best, even if it doesn’t align with your idea, or the internets’ idea, of what a perfect team is.
They tune the guitars and your rockstars play ‘em. That’s what a real team is.
Some of us inherit teams. We don’t have the luxury of hand picking the people we want to have. Maybe there just isn’t enough in the budget to fill your team with rockstars. Software gets written outside of Silicon Valley too!
This, for me, is the real notion of building a team. Not chucking money at a bunch of rockstars, but taking what you have, or building on a small budget and creating a live band – you need rockstars AND roadies if you want to wow your audience.
