Rich Durnall and I presented our experience building apps with REA Group (who run the popular realestate.com.au website). The main focus was on how agile software development fits with mobile, with an emphasis on small, lean teams that iterate and learn quickly.
Building mobile teams and getting a product to market
1. Building a mobile team
and
getting a product to market
Stewart Gleadow Richard Durnall
@stewgleadow @rdurnall
sgleadow@thoughtworks.com richard.durnall@rea-group.com
30. Stewart Gleadow Richard Durnall
stewgleadow.com richarddurnall.com
@stewgleadow @rdurnall
sgleadow@thoughtworks.com richard.durnall@rea-group.com
Hinweis der Redaktion
A bit of the journey that we âve been on building apps for realestate.com.au How we âve built mobile development capability Used an agile development process throughout the journey FInish up with some key learnings This isnât a reflection on how awesome REA and Thoughtworks are at mobile development, or how we got it all right first time Itâs the agile process at work: work in short iterations, test early, fail fast, and adjust Weâre pretty happy with where weâve got to, learnt some painful lessons along the way (thereâs so much more than we could convey in 40 minutes)
Rich/Stew Thoughtworks is a global software development and consulting company (in case you didnât already know!)
Rich
Rich
Rich
Rich
Rich
Rich Agile Continuous Delivery / Automate Everything Continuous Design DevOps Line of Business Teams
Stew Started late due to REA 2.0, needed to play catch up fast. A number of choices when starting out in mobile Which technologies to use (we chose to do native iPhone first) Whether mobile development should be separate from existing software teams (we chose to not align with the line of business teams) Where to get your staff from (there arenât many iOS developers with agile experience) (we chose to build a team with a combination f internal and external staff⊠well, Rich chose, and I was one of those external staff) built around a delivery manager with proven mobile delivery experience (really do need some people who have done it before) Opted to teach talented devs iOS / Android due to limited availability of top skills in the market. Started the project with some standard agile practices (not mobile specific, but even more critical on mobile platform) On a new platform, new technology, new team, new languages: so much unknown, have to work in short sharp iterations
Stew wasnât just because we all have shiny iPhones in our pocket (certainly not the only way you can build apps) If you look at existing usage data, it was the only platform that made sense to target If you canât be the best for one particular platform, how can you do it for all platforms at once? The hurdle to being awesome is lower for native apps than web apps (going native doesnât magically make your app awesome, but thereâs the least barrier) If you go down the web path, you really have to fight to get a good performance and a great user experience Native iPhone does mean Objective C: which I like, but isnât not for everyone
Stew tech lead / DM, designer, product owner and 6 developers (only 1 with Objective C experience, many without much C experience) --> 50% might be a better target team too big, too developer heavy including API development in core delivery team, not separate layer teams makes it very easy to push logic to the server if they are developed in tandem
Stew iOS really started with design agencies, and fly by night coders, perhaps using a marketing budget Weâre getting to the point where a lot of our core business is going to be done on mobile wanted to use practices we knew TDD, BDD, Continuous Integration, Continuous Delivery tried to test drive our code as much as possible (difficult with poor tools and a new framework/language) Strived for behaviour driven style of development, even without automation no culture of automated testing... it âs coming now, but in 2010 was almost non-existant command line integration is an afterthought with Appleâs tools
Stew set up a number of standard agile team practices, call this one out in particular fairly strict: 1 per pair and only 1 spare on top of that (Pez âs talk) logic behind WIP isn ât particular to mobile, but the need for it is accentuated everyone cares about the details of mobile apps: it âs in your hand, in your pocket need to reduce cycle time (if things take too long, priorities change or aren ât respected) avoid death by a thousand cuts hope you also went to Perrynâs talk
Stew started the project with some standard agile processes you can only improve what you measure visibility: burn ups / burn downs , regular retros and showcases get feedback early, adjust how the team works measurement: basic estimation and velocity tracking (nothing over the top) weekly iterations: needs to be shorter for mobile, time scales are different need to learn faster all signs pointed to: missing the deadline by a huge amount, and building a product that the business didn ât quite need some pretty basic out-of-the-box agile gave the business early warning signs... agile didn ât magically bring success but it showed things needed to change drastically early on
Rich - failed first attempt - knew about it early due to standard agile practices being used by the team Failed due toâŠ. Level of business engagement. Organizational mobile knowledge. Maturity of our design thinking. - could: cancel the project, outsource the project, or reset with a different structure and emphasis
Stew re-start project, get everyone on the same page -> started with an inception with all relevant stakeholders the team will make thousands of decisions over the course of the project, give them the context they need to make the right decisions (paraphrasing Jonathan Rasmussen) 1) get a big room 2) draw lots of pictures 3) write lots of stories 4) don ât stop, get building first approach was to build perfection from the start, before it was validated second approach was to start simple, test on real users and iterate content as king vs design as king
Stew Learning new technologies and interaction paradigms is easier in smaller teams: get good people and have less of them (easier said than done, you might have to create them) Footprint of these apps is quite small, so velocity doesnât scale with team size very far (we all know in general it doesnât, but hit the limit sooner) after: added full time UX consultant from Thoughtworks, dropped to 4 developers (skilling up a small team is easier and quicker) design/UX needs to be a bigger part of the team (Apple says to expect 2/3 effort on design ) when you âre playing catch up with the competition in terms of features, quality UX is essential continuous delivery requires continuous design ELT level product owner: no delay in decision making -> empowered team, very few external dependencies UX practice took off within REA and is now a part of most teams and products
Rich Delivering Results Second attempt much more successful Now over one million downloads Engagement events much higher etc.
Rich/Stew Third party, close-shore Thought it would be quick and cheap, a few weeks Don ât just copy the iOS app: itâs not the same Cloning across platforms is not quick of cheap, and probably not what you want to do anyway Good API gives the best saving across your platforms Share high level tests to drive development of other platforms Cost of Android and iPad was not drastically cheaper than the initial iPhone app (reuse didn ât save time or money)
Stew many ways to skin a cat (this is a whole talk in itself, something weâre thinking about a lot at the moment) tradeoff between experience and cost/time REA chose rightly to invest in native iOS at the time, but that doesnât mean there isnât pain associated with that Facebook and LinkedIn both sit somewhere between pure-web and pure-native apps some people donât require a native app at all (if youâre not in the first page or two, used almost daily) be aware of Conwayâs law (the software architecture will come to reflect the organisational structures) eg. Separate iOS, Android and mobile web teams: donât expect much re-use start to build richer APIs, serving not just data but styled-content as well (this is a directly not just for native apps, but for high performance mobile web apps as well, using lots of JS)
Rich - mobile is hard, but it âs here to stay, so we need to get better at it - ROI for mobile is much higher - bring mobile into the core lines of business, no longer technology based teams - allow time for innovation: it âs not just a matter of cloning website features into apps - build mobile specific features that suit the use case of the mobile devices (tablet vs phone) Challenges with native only developmentâŠ. Speed of development Availability of skills Apple store process doesn ât support Lean Start-Up mindset. Little reuse across devices and native/web not line of business oriented: technology based teams might work early on, but long term need to be more product focused
Focus on key learnings from here on. Bringing mobile into the core lines of business (worked as a separate technology team initially, but now time to get more business aligned) Mobile is become a channel of the core business, not a separate venture
Stew small, cross functional and autonomous --> why do we always forget to run projects with teams like this! these apps have a small code footprint, especially early on, more people will not help suspect 3-6 developers is the sweet spot, need a few to keep moving on multiple things ï probably want 50% mobile experience as you scale up every time the team has been struggling, the solution has been to reduce the team size UX and product owner embedded in the team (jason and Daniel sitting with the team) -> touch on that in a minute need the right people: not all developers make great mobile developers for iOS, need engineers technical enough to want to code in C, and high level enough to create a refined user interface and a great experience (eye for detail) need poly skilled people, blurring of roles... UX and Dev are the only two essential roles for small mobile projects in my opinion don ât try and build a LARGE high performing team before you have a SMALL team performing well informal collaboration beats meetings any day, but only works when the team is small enough one of the side effects of a small team, is a very lean process (highlights where our agile process and even our agile dogma starts to get in the way)
Stew recent mobile summit: if weâre going to keep the team small, which roles are essential? expect the balance of design/development to have a more even balance than on typical software need poly skilled people, blurring of roles... UX and Dev are the only two essential roles for small mobile projects in my opinion Mobile UX is an acquired skill: not the same as web or desktop user experience Usually need someone to cut the pixels (someone between UX and Front End Dev)
Stew we âre still working out how people use these devices, donât expect to get it right first time agile provides a way of working that accepts not knowing everything up front, and reacting to feedback many teams treat âagileâ as serialised, incremental delivery --> need to be constantly feeding back in and adjusting what youâre doing fast iteration in Apple âs ecosystem? Enterprise internal releases saw in a recent blog post on how to deliver software effectively: build less, start sooner.
Stew Testing these UI heavy, experiential apps is hard⊠and the tools arenât great Return on investment in testing isnât as short as web development, maybe not worth it straight up, but will be sooner than you think ended up focusing less on automation early on (but test automation is essential for long term agility) manually test only the things that really need a person with an eye for detail (there will still be plenty), don ât waste their time on the mundane stuff good testing will also help get your v1.0 out the door (the payoff from automation is closer than you think, probably weeks, not months) corner cases everywhere --> stuck them up on the wall must test on real devices running over real mobile networks (don ât just use the simulator, or just a wifi network) must have controlled test environments over real network conditions testing tools still have a long way to go (so wrote our own), led to the later development of Zucchini open source framework (screenshot based tool) share high level tests across platforms (iOS, Android - same/similar features, different implementation)
Stew the mobile platforms do dictate the approach to some extent, don ât throw away good engineering practices things like TDD, good Object Oriented design and separation of concerns are all still completely valid building a good mobile app needs to be engineered just as well as a large website, it âs not a toy agile is not just about the process: need proper XP engineering practices to go with it don ât throw the baby out with the bathwater (when all you have is a hammer, everything starts to look like a nail) don ât use web tools just because theyâre the ones you already know
Rich Kent Beck âs updated agile manifesto: validated learning over working software lean startup stuff? mobile is a great opportunity to try out start up culture within a larger organisation keep it simple: most basic thing that can get feedback and inform your next decision agile helped identify things that needed changing, but should have focused more on research, nor development early on continuous delivery helps: TestFlight for beta distribution (or HockeyApp, both good), Enterprise releases within the company (can ât go all the way to app store every green build) get analytics in place figure out what you need to measure: what does success look like? what hypothesis is validated by early releases? can talk about recent inspection planner release, big spikes in traffic on Saturday morning, also leading to high use of Map & Directions, as expected
Rich/Stew not do Capital A, ceremonial Agile, be agile the market moves quickly and pivots often, so should you work in a way that makes this possible every time we think we have it sorted, everything changes again software development is really an exercise in failing, want to do that as quickly and cheaply as possible, learn and fail less the next time