I recently got this wonderful opportunity to present a case study "Agile and Startups - What can go wrong" at ExpoQA, Madrid. The talk is about how startups think, build on the idea and try to sell it, until it is influenced by external factors like market and competitors. A lack of strong product owner didnt help as well. Agile, is a technology and is prone to failure as well, until it is practiced right.

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