Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (12)
Semelhante a Building mobile teams and getting a product to market
Semelhante a Building mobile teams and getting a product to market (20)
Mais de sgleadow
Mais de sgleadow (14)
Último
Último (20)
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
- 2. A bit about us
- 3. Ground Zero 3
- 4. 4
- 5. Delivering Results New data centres within 6 months 5
- 6. Delivering Results realestate.com.au rebuilt and launched in 10 months
- 7. Learning Agile 7
- 8. How We Work 8
- 10. Why iPhone First? It’s not just because we like shiny toys
- 12. Engineering & Testing 12
- 13. Limited Work in Progress
- 15. The Pivot
- 16. Common Vision
- 17. Smaller Team Structure Experience design part of the core delivery team
- 18. Delivering Results 18
- 19. Multiple Platforms NEEDS UP TO DATE SCREENSHOT
- 20. Hybrid Mobile Apps 20
- 21. Into the Future
- 23. Keep the Team Small
- 24. Design and UX are essential 24
- 26. Get your testing sorted
- 27. Use what you already know Good engineering is platform agnostic
- 29. Be agile
- 30. Stewart Gleadow Richard Durnall stewgleadow.com richarddurnall.com @stewgleadow @rdurnall sgleadow@thoughtworks.com richard.durnall@rea-group.com
Notas do Editor
- 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