Optimizing AI for immediate response in Smart CCTV
Agile and-startups
1. Startups and Agile
- What can go wrong?
A case study
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
7. 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
8. 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
The Old web team can help
in creating web services/API
9. 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
10. Two teams were created
API Team – the old web team is
now looking after APIs, needed
by the Mobile team
Separate Scrum, Scrum Master,
Sprint meetings, Retrospective
Not in Sync with the Mobile
Scrum
Sit in a different room than
Mobile Team
Mobile Team – “THE team”.
Focus is to get the best from
them as they are developing
“THE PRODUCT”
Separate Scrum, Scrum Master,
Sprint meetings, Retrospective
Not in Sync with the API Scrum
Sit in a different room than API
team
11. 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. 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.
15. 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.
16. 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.
17. 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?
18. 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.
19. 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.
20. 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.
21. We forgot that Agile can
deliver only when we
know
where we’re
going with our product
The Way was lost!
22. Product failed, and its NOT rare
Source: http://innovationcenter.deteconusa.com/article/innovation-execution/
23. 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 it 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.
24. 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.
26. Thank You !
Contact me
Vipin.jain@metacube.com
Linkedin: in.linkedin.com/in/vipinqalead/
Twitter: vipin_QA
Editor's Notes
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.
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.
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.
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.
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.
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.
The Onshore team went through a formal training. However, more developers were added onshore afterwards and they lack true Agile knowledge.
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.
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
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.
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.
Teams started to work as one team, and all inter and intra communication issues were resolved.
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.
The product backlog now seemed irrelevant as investors’ suggestions needed to be incorporated.
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.
Studies show that out of 3000 business ideas, 100 get converted into real projects and only 1 of those succeeds