7 ways we tweaked the development process to deliver a high-quality product fast
This was originally posted at https://www.fairskill.com/blog/2017/02/22/7-ways-we-tweaked-our-process.html
It is supposed to be the impossible task; delivering a complete and high quality product fast and cheap. You all remember the project management triangle often used to describe this. Never the less Fair Skill was recently hired to deliver a front-end lead/team leader for the Soldr/Aracua project at MittMedia, Sweden’s market leader in local news. The project went public today, and so I want to share with you a couple of methods we either invented or used to deliver what we think is an exceptionally high quality product, with high quality code, in the desired time and without busting the budget or making huge trade-offs. While keeping everybody happy, and many times truly blissful even.
Mission, goals and empathy
First off. Having been a developer, interaction designer and scrum master for a couple of years now gives me an incredible set of tools as a team leader, but no team or process works if you’re not working with your users in mind, with measurable goals and towards a higher cause or mission, is my experience, and this is crucial to ever getting our process to work no matter what it is.
In Aracua we collaboratively put these pieces together early. This is how we did it:
- First of all, we were fortunate to have at our disposal an excellent set of user interviews and usability tests done in the past by the UX team at MittMedia. These would help us put together a couple of behavioral archetypes and we were able to extract user goals and challenges. If you do not have any data from your users, I’d strongly recommend you to make that effort early. They will likely assist you in the kind of activities we did next, as they did us.
- We interviewed all stakeholders in the project. People working in the editorial environment, with data and various business aspects. The interviews were semi-structured and were focused on what kind of impact they’d need to see within a couple of years’ timeframe.
- This, together with any descriptions of why the project started or how the initial vision was formed –including the actual vision set before the project — served as our data for putting our measurable goals together. The stakeholders, each and every one of them, were then asked to verify it’s what they want to achieve.
- What came out was a couple of documented, well defined goals and a consistent mission. They were indeed specific, time-bound, measurable and realistic. As long as we deliver on them, the playing field is open. This gives us as a team the trust, initiative and mandate we crave to do our best work.
I hold business impact mapping, as defined by inUse Experience, close to my heart and I’d recommend you to read more about it (in Swedish).
The 7 strategies
My passion for development processes was the main reason for starting Fair Skill at all. Going into Aracua I knew, given the challenge we faced, I had the perfect opportunity to put some of my own “manifesto” into practice. The next segment will not contain any links to external resources or research. These are my views which I implemented in the process we use in Aracua, and with a lot of success.
I believe in being agile as much as the next guy or gal. In Aracua we do our version of Scrum. We have our daily stand ups, we estimate in points and we have two week sprints that begins with a sprint planning. We have a definition of ready and a definition of done. We write user stories. All of that is pretty straight forward. There’s a few things that we seem to not have in common with other teams, that makes our version of agile development interesting.
1. We plan for months ahead — but not years.
Not agile? We believe that the world, the company and our users do not change a whole lot in the span of a couple of months. In this project, we have planned from the vision and whatever seems to give us the most outcome considering our business goals and our users’ goals. The result is a list of epics. We usually set dates for the expected UX delivery, which helps us paint the greater picture of what to expect when, which is a very helpful tool for our product owner. So far, he has been able to tell what is getting done when, weeks in advance, and so far, it’s been spot on and a big help. We assume that we’ll achieve, on average, one large feature theme (one epic) each week. I believe this helps our focus a lot, and I know it helps us prioritize.
But all it really is, is a list of themes and a few target dates. Powerful in its simplicity.
2. The design team is a part of our team, but they work independently.
They are not a part of our Scrum process, is what I meant to say. They do design sprints, one week long with a Kanban board in Trello. Once a week they host a UX demo, and everyone takes part. The back-end team, the front-end team and many times our tester and product owner. The design team shows their current work as Balsamiq mock-ups. The reason for this early collaborative meeting is to make sure they don’t move towards solutions that might be really, really bad from a developers’ perspective.
This has proven to be a great concept for finding problems early (read: cheaply) and letting developers in as early as possible in forming the solution. The main reason for splitting up our processes is the simple fact that optimizing each team and letting them do their best work is crucial to our success, and for our success to be blazingly fast. The design team functions best with design sprints, and the development team works better in Scrum. So, let them.
3. Our designers do system design.
The system design is also a collaborative thing across all teams and roles, including our tester and visual designer. Here, too, can we find problems early and fix them before we write any code at all. We also, mainly, want to make sure the developers have the perspective of the designer, and vice versa of course. It gives us comfort and builds trust going forward.
All in all, we are basically all included in each step of our process, from vision and goals to deployment. It doesn’t take too much time and everyone is part of it. This has really improved ownership of the entire product, and we catch a lot of problems before they surprise us.
4. We do not complete our sprint during the sprint.
In short, we don’t include our In-Testing column and Done column in the current sprint. Two reasons. Review and testing takes place when our designer and tester finds the time, they are shared resources and cannot always follow the pace of the developers. Over time, our velocity will still be useful indicators since we have a steady process all-in-all. The second reason is the fact that a sprint begins by writing code, and then the tester goes to work when the code has been written. So, if the developer delivers code late in the sprint, the window for testing gets smaller by the minute until the sprint is closed. Our burndown charts are totally bogus as a result, though.
This has really saved us from a lot of discussions about how to handle the development and testing pace in regard to sprint start/stop — and everyone will get the time they need. Like I said, shared resources, so this helps people prioritize their own work between teams and products.
5. A feature always takes a minimum of 6–8 weeks to come to market.
I don’t know about you, but most of the time when I kind of promise a feature can get done in two weeks I end up realizing I didn’t quite take into consideration the design process and test phase, not to mention that meeting we need to have to hammer out how it fits with our users goals and needs etcetera. I’ve come to the conclusion that a feature never takes a sprint to go from vision and goals to design to being shipped, and placing all teams and types of work into the same process (Scrum) doesn’t quite show the complexity or optimize each step.
So, this is also one of the reasons for having independent processes. A feature comes from either working with the users, or as an idea sprung from the vision and our goals. What follows is planning, interaction design, validating the design, graphic design, system design, the plan to implement and the implementation itself — then comes the test phase and deployment phase. To be very fair to our product owner and to keep ourselves sane — or simply by looking at our processes and realizing — we agreed that our time to market is 6–8 weeks. This is not the same as saying we work on a feature for 6–8 weeks, we have a much larger capacity. But for any individual feature to reach the users, yes, it would take that long.
Be honest, what’s your time to market, really, and do you even know? I can tell you that we have not once had that “is it done yet?”-discussion.
6. We made time for refactoring focus.
It is very common to make trade-offs when you’re aiming for the MVP, and it’s very common not to really find the time to go back and fix it due to the forward motion of the project. This came as a surprise to a couple of my colleagues, but we took the time right after the first product demo, and we were clear about it towards our stakeholders. We said at the beginning we were doing a very important product at a world class standard. So, obviously, we took the time to refactor code, validate our architecture, implement security features and write all those tests we didn’t at first. This should never come as a surprise and taking care of our technical debt should absolutely halt the forward motion. Ours is quite a bit smaller and we benefit from it in more than only practical ways. As an example, it had a tremendous impact on how we feel about the project and product. It feels great to deliver something we know we took the time to perfect. We have the same principle not only for the code quality, but for the users experience as well.
You might think that this slowed us down considerably. It didn’t. First of all, our process allows for great UX work to be done during that period, and we’ll have an awesome backlog to work with when we’re ready. Second, we learn a lot about our code and it helps us write the right code from the start.
7. We do ad-hoc sprints to improve what we already built.
Every now and then we do what we call ad-hoc sprints. It basically means we do what we (or our users) want for two weeks. The simple rule is that we cannot implement new features, only improve the stuff we already have. So, the users will love the product. Because that is really important if you tell everyone we’re aiming for it. World class user experience comes from caring and taking the time to actually make it world class. :)
Wrapping it up…
If you came this far you might be ready to call it out as a waterfall process. You wouldn’t be entirely wrong. Our waterfall consists of a number of iterative activities and a couple of detached agile processes, and the waterfall itself aren’t that high before we iterate on the big picture. So, the waterfall is quite controlled, and we know we face the risk of blasting the barriers all the time (as with any process, really) and it all requires a big portion of professionalism, communication and openness to process tweaking. This may not be the most suitable approach for all agile projects, obviously, but it works out wonderfully for us. We are happy, and we are building what we believe to be a great product, with great quality and at a pretty fast pace.
It wasn’t obvious at the start. Nothing was, really. We put the team together before we knew anything about the challenge. The project had frequently been compared to the several years long project of building and optimizing MittMedias entire digital platform. Our process was born out of trying to find the best way to get this off the ground fast and cheap and with the assumption to launch this big and complex thing, this every day and all day tool, for a lot of people and use cases, within less than a year. These strategies served us very well, so I hope you can find some inspiration for your own work.
Credit must go out to all my team members at MittMedia, and my excellent front-end colleagues Igor and Dzmitry from Altoros in Belarus, who all delivered beyond expectations. Obviously hard work goes into this more than anything else.
Thank you for reading, and I look forward to answering any questions, to hear your thoughts on it and read about your development process tweaks. :)
I’m at fredrik@fairskill.com if you need direct contact!
