No one wants to be the next Novopay! How do you ensure good value for money in web application development? It’s a question we are often asked and doesn’t have a straightforward answer. In this post we will look at some of the techniques we use to deliver better value for money on our projects.
Customer and team collaborate at every stage
To ensure that the vision held by the customer is shared, the customer and team must collaborate effectively and efficiently. Using good facilitation tools and techniques, and agile ways of working, the customer’s vision is clearly shared by the team and enables them to make sound decisions at every stop of the way.
Get fast feedback from the market
Key to getting good value for money is getting feedback from your market early and often. Working to get the application to market as early as possible reduces risk by ensuring the feedback loop from clients is as short as possible and by reducing investment before feedback. Integrating customer feedback into your development process will ensure that the features being developed are of value to your customers.
Following technical best practices such as BDD & TDD is an excellent way to ensure quality is at the forefront in development. Technical best practices reduce the number and severity of defects in the work which frees valuable resource for creating features. The cost of finding and correcting defects grows quickly, so early discovery and re-mediation is key.
It is absolutely essential to continually and rigorously inspect both the software being created and the way the team is working to create the software. We use agile processes to ensure that the team and client work together to improve on a continuous basis. The result is a high-performing team that is continuously improving, adapting to change and providing more and more value.
All of these ideas are supported by Agile and Lean and we are in a great position today where we are able to stand on the shoulders of giants who’ve discovered pragmatic solutions to the problems of software development.
We would love to hear your your point of view, what has worked for you in the past?
We are still working behind the scenes on the Boost website and another sprint has come to an end, bringing with it a few more changes.
This week we’ve made one change to the Boost site, some changes to the site that houses our event’s bookings, and furthered our concept for the Boost design portfolio.
View the Board’s latest episode
In our last post we talked about the Boost TV channel on livestream. We air a live show called The Board, where we talk about all things agile, every second Thursday.
Two shows have already been aired, so we thought it was time we made them easily accessible from the Boost website. You can now click through to the latest episode directly from the sidebar on the homepage, and if you are viewing it on a smartphone you’ll find it under our events information.
Eventbrite
We are going to allow event attendees to book directly though our website in the near future, but until then Eventbrite handles it. Whilst they do a great job, we felt the jump from the Boost website to their page was a bit jarring due to the differences in colours used and the placeholder images that are displayed alongside each event.
We have replaced these images with Boost branded ones, and used similar fonts and colours to our own website, which in turn makes the transition feel a bit more seamless.
Portfolio concept
We had a story in the last sprint to come up with a concept for displaying Boost’s design work in an interesting way. There was no implementation necessary, so we showed a hand drawn concept at our sprint review. We can’t say too much about it now, as it’s still a work in progress, but our next step is to create a working prototype which we can show to the team here at Boost.
If they like what they see, we will design and build the portfolio, so expect an update on that soon.
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
The project kick-off
We kicked off our two days of development with a full team meeting starting at 9am sharp – all under the keen gaze of our documentary team.
Vision
Nathan outlined his vision to build a tool that would support Scrum teams, both co-located and distributed. By the end of the two days, Nathan told us, he wanted to have something ready to take out and show to people as the next step in validating this potential product.
Nathan then introduced the product backlog and read out the first three user stories and their acceptance criteria.
Team charter
Next, Paul, our Scrum Master for the project, lead us to create a team charter – an agreement on how we wanted to work together as a team for the two days.
Team charter for the development of Scrummaker
Format:
Half-day sprints
Retro at lunch time
Retro at end of day
Teams:
Three teams (there’s 17 of us)
Communication:
If you have a problem – put your hand up
Be respectful of each other
Everything done face to face
Pro-active communication between teams.
Definition of done
For the purposes of the two days, ‘done’ meant:
Cross-browser tested (IE8 and above)
Technical debt reduced
Merged to master
Passing tests (full coverage)
Internationalised
Deployed
Metrics in place
Split into teams
We shuffled ourselves into three teams, dividing up devs, designers and UX/content people. Nathan then handed out a story to each team, and we reshuffled a little to suit them, allocating more devs to the first (and largest) story. Once we had our teams we moved into three different parts of the office, tasked up our stories and started our story boards. At about 10am, we all kicked off our first sprints.
The next two posts will cover what we learned from our two-day experiment, and Nathan’s over all thoughts.
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
Scrummaker: The technical discussion
At the end of the day on Wednesday, the team met (for strict 30 minute timebox) to thrash out technical decisions we felt we needed to make in order to get off to a clean start on Thursday morning.
We grabbed post-its and had two minutes to scribble down the things we wanted to discuss. These went up on a sheet of paper, were quickly grouped, then we dot-voted to pick what we wanted to discuss the most. We agreed to spend 8 minutes discussing the highest priority item, and 4 minutes on each of the other issues, until we ran out of time.
Post-it notes with topics for our technical discussion, grouped in priority order
The highest priority post-it was How do we avoid design blocking work. Balancing the needs of Scrum and design is something we’ve worked hard on for several years now, so it’s not surprising that with a two-day development period this came to the fore.
After discussing the issue, we came up with a series of actions:
Collaborative wireframing to kick each story off (then being able to start work on dev and design concurrently)
Next we quickly covered off Testing, agreeing to stick to our usual practice of Behaviour Driven Development, and to use RSpec and Cucumber
The Hosting post-it got the one-word answer Heroku.
JavaScript was up next. We knew that Scrummaker was going to be heavily interactive, and that JavaScript would be very important. We agreed on Unobtrusive JavaScript and that we’d discuss this in further detail on the day as it came up.
Finally, we agreed on a zero critical bugs policy – new development would always come second to fixing critical bugs in existing features.
At the end of half an hour, we felt prepared for the project kick off at 9am the next morning.
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool to support teams to run Agile retrospectives, which we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
The experience-mapping workshop
Since we started using story mapping last year, we’ve made experience mapping a regular part of all new project kick-offs. It’s the best way we’ve found to quickly generate and prioritise a product backlog.
For Scrummaker, our experience mapping workshop was made up of three of Boost’s Scrum Masters plus two other prominent Wellington Scrum practitioners. Nathan facilitated the session, in which the group
Brainstormed all the steps in running a retrospective, from starting thinking about planning a new retro through to checking back on progress on actions from a retro held several weeks ago
Wrote each step on a post-it note, then put these in a long single line along a wall, from start to finish
Grouped the post-its into the major steps for planning, running and reviewing a retro, and identified pain points in the process, which included:
planning effective retros
running good retros with distributed teams
collecting information from a retro and sharing it with the team
Reviewed these pain points to identify where a product might lie.
The group then did some rapid persona development: a quick exercise to identify different users, the context each is operating in, and what they value. (This kind of persona development is described by Jeff Patton in this 2009 talk on pragmatic personas.) These personas were then prioritised, with Daphne the Distributed Scrum Master coming out on top.
Daphne, our key user persona for Scrummaker
Daphne’s context
Daphne will use Scrummaker to run online retros
About Daphne
She is an experienced Scrum Master with a distributed team (a team split over several locations that finds it hard or impossible to physically meet)
She has had trouble getting value from the retros she runs with these distributed teams
She feels out of sync with her team
She finds it hard to follow up on retro actions
Daphne values
Being able to see her team during the retro
Easy coordination of meetings across time zones
Good team communications
Tools that are easy to set up for the team
Good visibility of actions
Integration with other tools e.g. Pivotal tracker, Basecamp, Jira.
(Our other two personas were Rob the Rookie, an inexperienced Scrum Master who has just passed the CSM and is working on his first project, and Carl the Corporate Scrum Master, who is a more experienced Scrum Master with particular concerns around traceability and accountability for retro actions and outcomes, and data security.)
Taking the retro steps they had identified, the group then wrote features for the tool based on these personas. Finally, using Daphne as their priority customer, the group arranged these features into three releases: the minimal viable product (MVP) and two further releases that would add more and more value.
And that was the end of the experience mapping workshop. Between the time that we ran the workshop (Tuesday) and the morning we met to start work on the new product (Thursday) Nathan worked with Federico, one of our Rails devs, to turn the features on the post-it notes into fully developed user stories with complete acceptance criteria, so a product backlog was available for the team on Day One.
There was one more step between the experience mapping workshop and project kick-off. The team decided to hold a technical Q&A session, to thrash out some details so we could hit the ground running on Thursday. The next post in this series covers this technical discussion.
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
Customer validation: the research process behind Scrummaker
Customer validation has been at the heart of this project. It’s actually seen us take a completely different direction to the one that, three short weeks ago, we thought we were moving in.
Originally, we’d considered building a tool to solve one of our own pain points: turning stories in Pivotal Tracker into physical objects for sprint planning and visible workspaces. At the moment, our Scrum Master or our Office Manager spend a not-insignificant amount of time each week pulling stories out of Pivotal Tracker as CSVs, dropping them into project templates in Pages, tidying them up, then printing and trimming. We’d identified this as a pain point and poor use of our time, and considered building a tool that would integrate with Pivotal Tracker and automate this as much as possible.
We used two frameworks to conduct and capture our customer research. One was Lean Launch Lab, a product that helps you store and visualise your customer research. The other was the Validation Canvas from Lean Startup Machine, a simple one-page format for displaying assumptions, hypotheses, and pivot points.
Validation canvas for Scrummaker (from Lean Startup Machine)
We conducted research in a number of different ways. The most complex was using unbounce to set up a landing page for our theoretical new product. We used LinkedIn advertising to promote the page, and tracked conversions from people visiting the page to following a call to action to sign up or find out more. We ran a poll through the LinkedIn Scrum Practitioners group, and we also conducted a series of email and face to face interviews with Scrum practitioners in Wellington and around the world.
What our customer research rapidly showed was that our ‘printing out stories is a pain in the ass’ sentiment wasn’t widely shared. (Perhaps, being a design-led company, we worry a tad too much about everything looking good as well as working well.) Instead, what emerged was a cluster of concerns around retrospectives:
they aren’t always valued by teams and/or organisations
they are hard to run with distributed teams
it can be hard to generate actionable improvements
it can be even harder to track whether these actions are taken and what the outcomes are.
Some market research showed us that few tools already exist to tackle these problems. At this point, we felt confident that we had a good problem to solve. What could we build that would help Scrum teams run efficient and valuable retrospectives?
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool for teams running Agile retrospectives that we’ve named Scrummaker.
The purpose of the workshop was three-fold. We wanted to build a new product. We wanted to build a new product as a team. And we wanted to build a new product as a team using the Agile practices we’ve been working with now for about six years.
We’re now publishing a series of blog posts to record the two days of product development: what we made, and how we did in. The blog posts are only the beginning; we also had a crew of student filmmakers along for the two days, recording all the goings-on for a short documentary.
The first posts will cover the project lead-in: customer validation of our product ideas, the experience mapping workshop we ran to generate the user stories for the product backlog, the time-boxed technical discussion the team held to ensure we’d hit Thursday morning ready to work. There’s a post on the project kick-off, and then the meat of the series: what we learned from two days of compressed Scrum, and the product we came out of the end of the process with.
So grab a cup of whatever makes you happy and settle in for the read ….
We’ve just completed Sprint 4 of our boost.co.nz Scrum and our site has evolved in some obvious and not so obvious ways.
Testimonial
We’ve added a client testimonial feature to the sidebar:
Our alliances
The sidebar now displays our ties with organisations such as WorldBlu (Democratic workplaces), Agile Alliance, Drupal Alliance and the Scrum Alliance:
Blog design
Our blog, built in WordPress, has had a tweak to bring it in line with the current website design. Although a future story will deal with a blog redesign along with the full website design, we’ve changed the header now in order to provide more consistency between the website and the blog:
Deployments and code merging
Behind the scenes we’ve made changes to make deployments and code merging easier and faster. The goal is to be able to potentially release software including all but the last few hours work, at any time. Deployment is now handled by Webistrano and we’ve also set up a GIT repository for code management.
Check back here for updates as we continue to release features as they are completed.
Test Driven Development (TDD) approaches the production of code in a different way, it enables the developer to consider the writing of code from a user perspective. At Boost we find TDD incredibly useful for emphasising the focus on user centered design of code. The test takes into account what the function should achieve rather than testing that a piece of code works.
By beginning with writing code to satisfy a function, the developer is approaching the function as a whole and will often make assumptions on how it should behave, this can lead to extraneous code as well as the omission of code. Although a test written after code may succeed, the resulting functionality may not satisfy the user requirement. Writing tests prior to the writing of code encourages the developer to focus on what the functionality specifically needs to achieve. The test informs the writing of code rather than the code dictating the writing of the test. TDD is not just testing that code works, it’s also testing that a user requirement is met.
Writing tests first can also help reduce the psychological impact of writing and amending code in that if the developer is confident they understand the requirement, they can then write a very specific test and be more confident the code they write will succeed. Writing code against specific criteria is a far more structured and therefore less risky way to produce code.
What is Test Driven Development in practice?
Test Driven Development (TDD) is a way of writing code that starts with writing a test as opposed to writing code. It’s often referred to as an outside in approach because a test is written and run prior to the writing of production code. The initial test should fail, if the test does not fail it should be rewritten until it does fail. Once the test has failed production code should be written and the test re run. If the test fails the developer goes back to the code then reruns the test in a cycle until the test succeeds. Once the test has passed the code is cleaned up and the process is restarted for the next unit of code. As development progresses all previous tests as well as the latest test are run each time new code is tested to ensure the code is integrated without breaking anything.
A simple way of remembering the process is to remember Red, Green, Refactor. In other words, the test must first fail (red), code is written, the test passes (green) and then the code is refactored. The TDD process is illustrated below:
What effect has TDD had on the production of code at Boost?
Using TDD to produce code means that developers begin by setting out exactly what the code should do rather than beginning with how the code should satisfy the requirement. The advantage of this is that the developer is focussed on what the code needs to achieve from the outset rather than writing code in a more generalised way. At Boost we’ve found that continuous testing quite naturally results in fewer defects and TTD results in a greater understanding of what the code should achieve as well as cleaner code.
How does it work alongside Behaviour Driven Development (BDD)?
BDD is used to test an entire feature whereas TDD test actions or units within a feature, they work together in the following way: If all unit tests pass but the feature test fails, a new unit test should be written and the cycle of writing code and running unit tests should be run until the unit test passes. The feature test should then be re run, if it still fails, the developer goes back to the TDD process and so on until both the unit tests and the feature test pass. This is shown in the diagram below:
How does TDD fit in with Agile processes?
One of the principles of Agile is to inspect and adapt, TDD fits in with this principle as the process is a continuous cycle of inspection through testing and adapting of code to achieve successful tests. TDD can also help to reduce the likelihood of technical debt as the process includes a refactoring step in each cycle.
At Boost we find that TDD not only reduces the chance of code defects, it also fits in well with our Agile practices and in conjunction with BDD, gives us confidence in the resulting code and functionality.
Behavior Driven Development has become a key tool in our toolkit as developers strive to become leaner and more agile. Here at Boost we have been using Cucumber with Ruby on Rails to integrate Behavior Driven Development into our everyday software engineering practices.
At Boost we’ve been using Test Driven Development (TDD) for some time now. Test driven development is a process whereby the developer writes an automated test prior to the beginning of coding of a new function or improvement to an existing function – the test fails at the outset as no code has been written. The developer then develops the code to pass the test, as well as refactoring the code to an accepted standard.
We’re also using Behavior Driven Development (often referred to as BDD). Behavior Driven Development extends Test driven development by writing text cases in a way anyone can understand. Behavior Driven Development fits in well with Scrum in that the Behavior Driven Development tests can be written by the product owner. A product owner writes acceptance criteria for a user story within a sprint, but by asking the product owner to contribute to Behavior Driven Development testing by writing feature descriptions we are fostering collaboration rather than merely co-operation. The product owner is able to take fuller responsibility for a successful outcome.
Over the last year we’ve been using a tool that combines both Test Driven Development and Behavior Driven Development. Cucumber is a tool that enables the product owner and developer to work together to produce features. Here’s how it works:
1. The product owner writes a plain text description of a task and how it should work using a particular syntax (Gherkin) and providing scenario examples. Here’s an example of a feature description written for our Intuition HQ site:
Feature: Sign up to a plan
Sign up should be quick and friendly.
Scenario: Successful sign up
Users should see a confirmation when their payment details have been accepted.
Given I have chosen to sign up
When I sign up with valid details
Then I should receive a confirmation page
Scenario: Invalid card number entered
Where an incorrect card number is entered
Given I have chosen to sign up
But I enter an invalid payment card number
Then I should be told that the card number is invalid
And the form should be redisplayed offering me the opportunity to re enter my card number
2. The developer writes corresponding step definitions. The step definitions should include the phrases used within the feature description. The step definitions are tests written in code that Cucumber then runs against the site. The first time the tests are run they will fail as no code has been written.
3. The developer writes code for the new functionality described in the feature description and re runs the tests. Cucumber highlights success within the feature description in green, pending in yellow and failure in red as shown in the image below:
5. The developer amends the code and reruns the tests and so on until Cucumber shows the entire feature in green indicating that the tests have been successful.
The advantage of working with Cucumber is that both Behavior Driven Development, (in the form of the feature descriptions and scenarios) and test-driven development, (in the form of step definitions), are used to verify the success of development.
I spoke to one of our developers about his experience of using Behavior Driven Development and his response was that one of the most important advantages of using Behavior Driven Development is that it allows the product owner to write acceptance criteria in the form of features. The developer can then work towards developing step definitions to test the features the product owner has defined. The step definitions correlate with the acceptance criteria/features with the intention of leaving no discrepancies between what the product owner wants from their product and what the programmer develops.
Behavior Driven Development is proving to be a valuable tool in helping us to eliminate the gap between developer and client understanding of requirements therefore producing successful and useful features.
