Agile and Startups - What can go wrong - a Case study (Presented at ExpoQA 2015, Madrid)
Download as PPT, PDF1 like743 views
The document presents a case study of a startup that initially used the waterfall model before transitioning to agile methodology, highlighting the challenges encountered during this shift. As the project evolved, a lack of synchronization among teams and insufficient agile training led to chaos, resulting in delays, investor pressure, and ultimately a failed product. Key lessons learned emphasize the importance of comprehensive agile training for all team members, executive support for agile adoption, and the necessity of a strong product owner throughout the process.
Agile and Startups - What can go wrong - a Case study (Presented at ExpoQA 2015, Madrid)
- 1. Startups and Agile - What can go wrong? A case study Presenter - Vipin Jain QA Manager Metacube Software, India
- 2. Agenda Case study of a startup, that opted for Waterfall model and then midway moved to Agile. How Agile was setup and how the project was affected by Internal/external events. What went wrong. Lessons Learned.
- 3. Brief History Base idea behind this product was to make people connect via a web application and browse for people with special skills in neighborhood. Similar to Facebook / Linkedin but on a much lesser level. Base idea is to CONNECT and CHAT. Someone suggested to have a MOBILE APPLICATION as well for increased reach and faster access. Another suggestion came up to OUTSOURCE this project to an offshore company to incur less cost.
- 4. How clear are the project’s objectives and requirements? – We know what we want. How clear and well-defined is the solution? – We are an experienced team and know how to get the solution. How dispersed is the project team? - We will outsource, so we would be geographically far located. What is the team’s and stakeholder’s experience with these methodologies? – We are quite familiar with Waterfall model. Agile, well, we need to learn. Do you want the product be delivered at once – Yes. Make it and ship it all in one go. Waterfall emerged as the winner
- 5. Teams’ Structure Onshore Offshore-Web Team Owners Product Manager Tech. Architect Tech. Architect Project Manager Developers Single Tester Offshore-Mobile Team Tech. Architect Developers
- 6. The Testers began as well.. Common Tester for both Mobile as well as Web team. Initially only one tester, with a plan for another hiring later. He began his tasks of creating detailed test cases for each design and functional elements. Processes were setup for bug management, and testing tools identified. Plan for automation put in place.
- 7. The News Broke $19 Billion
- 8. The Focus changed Onshore Offshore-Web Team Owners Product Manager Tech. Architect Tech. Architect Project Manager Developers Testers Offshore-Mobile Team Tech. Architect Developers Testers
- 9. Great ! We have Mobile team in place. What’s the Plan? Encash the whatsapp fever - We need Quick deliveries to make quick $$. Let’s Bring in AGILE What about the Web Team? Well, they can help in creating web services/API to be used in Mobile App
- 10. What did this mean for testers? Whole approach to testing changed as team switched to Agile. The Test plans and test cases created were of no use as the Web app got scrapped off. The Automation plan went awry as well. More time would be required now to identify tools for mobile app automation. The whole testing plan was shelved and precious time and efforts got waste.
- 11. We need Agile Training ! 1 WEEK Classroom training arranged for Onshore team And Offshore team? The PPTs of training emailed for self training, to be done in 1 DAY
- 12. Two teams were created API Team – the old web team started looking after APIs, needed by the Mobile team Separate Scrum, Scrum Master, Sprint meetings, Retrospectives Not in Sync with the Mobile Scrum Satin a different room than Mobile Team Mobile Team–“THE team”. Focus was to get the best from them as they are developing “THE PRODUCT” Separate Scrum, Scrum Master, Sprint meetings, Retrospectives Not in Sync with the API Scrum Sit in a different room than API team
- 13. We need a third team ! A new feature, Search, was identified and should be implemented before first rollout of app. It’s a Database feature, and hence could not be part of the existing teams Solution? • Form a new team. It should be following AGILE as well, so lets combine it with the API team, but should follow its OWN SCRUM.
- 14. 3 Agile teams for 1 Application Team 3
- 15. Work Began.. No SYNC between teams, leading to total chaos
- 16. What did this mean for testers? With three parallel sprints, the tester soon found himself just switching between them. Every two weeks, there are three sprints planning sessions, three releases, three retrospectives, numerous status calls internally and with clients, and loads of stories and bugs. The poor guy was overloaded with tasks and lost his way.
- 17. No, this is not working! Two sprints finished and still there is no stable release. Issues kept surfacing as teams were doing their meetings, story planning, stand-ups and retrospectives separately. The teams have their own product backlogs, resulting in picking un-related tasks. E.g. Mobile team picked Search feature but the API team picked Connect feature.
- 18. So what should we do? The Agile methodology says “Have a single Scrum master who can help syncing the three teams.” Great !! Let’s do it.
- 19. Let’s start afresh Old work was scrapped off as new scrum master, who was earlier API team’s scrum master, wanted to start afresh instead of correcting existing processes. This created more confusion amongst teams as to which direction the project was moving.
- 20. All began AGAIN!! Finally, after three months, whole team started again. Whole team sat together in same room Common sprint planning session took place. Common status meetings happened. Different teams got to know what others teams are up to. Things started to look better FINALLY, everyone started to hope for a stable release !!! But, is this the end of all chaos?
- 21. New issues came up! Teams seemed uninterested when other teams’ members discuss issues or update their status. e.g. API people not listening when mobile people spoke. Teams took a while to understand the Whole project, delaying the project further.
- 22. Investors getting impatient! All these restructuring resulted in further delays. Growing pressure from impatient investors forced everyone to work in a hurry. Ad hoc queries started flowing in and they needed to be acted upon immediately. These factors disrupted the Agile process further.
- 23. Time Constraints: Lack of Automated Testing Frustration creeps up that began to affect the productivity. Lack of Automated Tests didn’t help either. Since the product took many different forms and was continually adding features and patching bugs, there's not much dev time to add in Automated Tests. For the product, which had a backend, front end web, and iOS and Android components, only 20% of the system was automated. No time and resources were left to commit for front end and mobile to move to TDD.
- 24. Budget constraints – No Additional QA resource iOS Testing Android Testing Documentation Bug Life Cycle
- 25. Product demos added more to the Agile disruption To pacify the investors and stake holders, product demos were arranged for their viewing. This opened the gates for various suggestions and changes that needed even redesigning some parts of the application. The Sprint got a complete halt. It was declared Zero sprint. More weeks added to provide more time to developers to work on investors’ change requests. No Visibility in sprint now.
- 26. We forgot that Agile can deliver only when we know where we’re going with our product The Way was lost!
- 27. Product failed, and its NOT rare Source: http://innovationcenter.deteconusa.com/article/innovation-execution/
- 28. Lessons Learned Agile is a technology and is as failure prone as any other technology. Everyone in the team needs Agile Training. Though Agile makes big promises, it also presents significant challenges to fulfill those. Agile is Quick in terms of development in small stages over small periods. However, this depends on following: The software is built in a way that makes it easy to change. Projects can fail faster, providing opportunities to apply fixes along the way. Product we end up delivering may not be the one that was envisioned. But it should be one that delivers value for business.
- 29. Lessons Learned …contd. Drive for Agile should come from Top of the organization. Its not a development team’s task to drive it. Substantial commitment from whole organization is required. A strong product owner is required throughout the process. His absence can derail a smooth going Agile process. Businesses may find it tempting to see Agile as a way to use few expensive personnel. An Effective Agile team needs lot more than a product owner, Scrum master and a couple of developers.
- 30. Any questions?
- 31. About Anubha and Vipin • I believe that Quality is not an Act, it’s a habit. Assurance of client is not an achievement, it’s the Attitude. The Habit of having this Attitude is QA. • A tester by choice, traveler by nature, incognito photographer. Love to meet people! • I believe the teaching profession contributes more to the future of our society. • She is working as Associate Professor & Head, IT department, The IIS University, Jaipur, India. An academician for last 14 years, she is currently pursuing her PhD, in the field of Information Retrieval. • Anubha is the author of 9 books and a regular contributor in various forums.
- 32. Thank You ! Vipin.jain@metacube.com Linkedin: in.linkedin.com/in/vipinqalead/ Twitter: vipin_QA Anubha.jain@iisuniv.ac.in Linkedin: in.linkedin.com/pub/anubha-jain/17/541/140/en
Editor's Notes
- #3: I will explain how Agile, when not implemented correctly and when too much affected by external events, can fail a project. I will also explain the lessons learned from this case study.
- #4: In the beginning, the application was supposed to have a web interface where an individual can login, and make friends online. He can then share his updates with them. When needed, he can search for people with specialties, like a plumber or an electrician around his neighborhood and connect with him. A small mobile app was also planned so that people can always stay connected.
- #5: Waterfall methodology was decided as the team were well aware with it. The classical model was agreed upon and conveyed to the off shore team who are also well versed with the methodology.
- #6: Three teams got created: Onshore team, with owners, prod manager and tech architect Offshore team, managing the Web interface of the application The Offshore mobile team whose sole task was to develop a scaled down mobile version of the application.
- #8: Whatsapp – Facebook deal happened and this just changed all dynamics of the product company. They began to think how to make use of this situation.
- #10: To capture mobile market, they planned to have Agile, and scrapped the Waterfall model. With this, the web work done was scrapped and focus shifted to the mobile application with lots of enhanced features.
- #11: The approach to the documentation changed. For test plan, long term plan that gets rare review during testing made way for small sprint based plans which gets reviewed often. Test cases for all functionalities are replaced by test cases for developed functionalities for current sprint/release only. Acceptance testing that was done by customer after the release in waterfall model is now being done by test team for each iteration. Test team does it before delivery and customer takes over after delivery. Team gets more involved with developers and that increased interaction time, as against in waterfall model where Dev and Test teams are two different teams.
- #12: To play football in High School, you had to be a pretty athletic teen. You had to be fast, have stamina, and change speed and direction in a heartbeat when you needed to. In fact you had to be quite Agile, didn’t you? Fast-forward 15 years. How would you fair if you were called up to fill a spot on the roster of a World Cup team – or your high school alma mater for that matter? If the first thing that comes to mind is sore knees and burning lungs, then you get the point. Use it or lose it: Training is vital before you take action, and even more important to keep taking action. Back in High School you didn’t just step on the field and start playing like an all-star. You trained, first to learn how to play, then to sharpen your skills, and finally, to stay in shape. In the world of Agile project management, the same principle applies. There’s no way an Agile transformation will succeed without at least some level of introductory knowledge. But trouble comes when an organization stops at that point and allows all levels of responsibility to continue on a as-needed basis methodology. The very basis of an Agile workplace requires being open to – and adaptable to – constant change. The Onshore team went through a formal training. For offshore teams, PowerPoint presentations were deemed good. Right from the commencement, there is a huge difference of Agile understanding between onshore and offshore teams. However, more developers were added onshore afterwards and they lack true Agile knowledge.
- #16: Teams have different start and end days for their sprints There are three scrum masters but there is no chief Scrum master or chief Product owner There are three product backlogs, one each for each team. There is absolutely no syncing. Agile is applied well to one team, but never considered multi-team scenario
- #19: API team scrum master was made Chief scrum master. Other two scrum masters were not involved further in the process. Now common sprint planning, common retrospective, common backlog were achieved. However, old work was scrapped off as new scrum master, who was earlier API team’s scrum master, wanted to start afresh instead of correcting processes.
- #20: One of the Scrum master was made the common scrum master of all teams, merged into one. He was well aware of how his team was performing, but had no visibility in other team’ status. Now since all three teams got merged into one big team, issues arose.
- #21: Teams started to work as one team, and all inter and intra communication issues were resolved.
- #22: Despite of working as 1 team, the different functionalities they were working on, kept the project divided in three teams. API team, Mobile team and Search team are still functioning internally as three teams.
- #23: The product backlog now seemed irrelevant as investors’ suggestions needed to be incorporated.
- #24: Teams started to work as one team, and all inter and intra communication issues were resolved.
- #25: Having only one QA resource compounded problems further. While it took 2 hours each for iOS and Android application testing on various devices, the API testing took about 3-4 hrs. Add in the time spent documenting and changing tests for new and changing features and UI, QA was overloaded. His request for additional QA resource was not approved due to budget issues.
- #26: Just to show the progress, various demos were delivered. This gave a lot of food for thought to the investors. They started to have a bigger say in the development process and put more weight on the processes. This caused Agile to take a back seat.
- #28: Lack of a good coach didn’t do any goods to the sinking ship. These guys were typical Agile coaches, just got trained few months ago and still working on “Scrum Rules”. A real coach with vast experience driving such Agile ships would have supported the teams how to get the best product in the shortest time, or how to kill the project as quickly as possible if they found out that we would be in the 3000 ideas space, but not in the success space. A good coach would have spotted the non-interoperationality of the whole within the first sprint.