The

case of Agile project: processes and benefits

This article is intended for managers of products and technologies. It describes the elaboration
of Agile on the example of using flexible methodology. Using this process we managed to
produce a high quality product in a short time. At the same time nobody was hurt or
overworked. If only a little and with pleasure.

About us
We are a small elaboration company; we lead 4-6 projects monthly. Our specialization is mobile
applications, but we also develop backends and interfaces for the loyal clients. Wed been
working for a long time on the Russian market; this project is one of several Western cases.

About the project

Daily Present is Austrian Startup in the field of content marketing. They propose to
accommodate the story in iOS application and website to the brands, and provide game service
and awards for training and sharing content to users. Our challenge was to elaborate Android
application with the same functions and integrate it with the existing service.

Challenges of the project:

hard deadline release 9 weeks from the date of commencement of works

we dont have much information, but what we have is in German
we could speak with the team before starting but theyve moved into another project
and didnt support existing solution.

Methodology
Fortunately we had an expertise in gamification and we had some idea about operating
principles of such application. But we still had to study the situation; we saw all technical
details, which could be opened up in the process of elaboration. Maybe it was the main reason
why we began to frame the application for Agile.
It would allow us to save our face in the date of release. For 9 week releases, even if we hadnt
realized all functions, wed see the weakest points from the very beginning but not in a week
before release.

Assessment and project plan

So, the client asked us to give the assessment of application (at least approximately). There
were no technical assignments except for existing application iOS. Then we wrote the functions
of application, in terms understandable for users, in our terminology user story. The formula is
simple: as (type of use) I want (function description) to (description benefit).

Thereafter we thought from the viewpoint of development and management of application and
finished writing more stories in Backlog. Such method of describing problems isnt correct
enough. But, what is important, that could be understandable, prioritize and have a freedom in
choice the variant in selecting embodiment (from hours to weeks). We appreciated and pitched
it in stages. We saw that 1 creator isnt enough, and we added another one to the team. The
last 2 weeks we left on polish animation interface, debugging the errors, and preparation for
publication.

Team and Tools

Totally 6 persons participated in the project I, as a Product Manager, 2 Android developer, QA
(tester), the designer has adapted graphics, service station helped to integrate the server and
analyzed the old code on iOS. For the project management we used Jira, test cases worked in a
text editor. We have adopted OC Android, for the test we had devices: lg nexus, Samsung
galaxy s3 and s4, and also noname the Chinese device. We chose a week as a period of the
sprint for this project.

Backlog refinement meeting

Before starting the operation the team had a very superficial understanding of the nature and
objectives of the project. In order to understand the details of the problems we organized
Sprint Refinement Meeting (1hour) before starting the work and every month before new
version. The goal of the meeting was to check with the product manager and be more exact in
questions about user story. The result of this meeting is goals clear to everybody, override in
the ticket tracker on priorities and taking into account the issues raised.

Sprint planning meeting

Directly on the day of the sprint we organize Sprint Planning Meeting (1 hour) - there the team
views the labor costs for feature and determines the content of the sprint. For the assessment
we use Story Points the abstract units (1, 3, 7) which allow to estimate the complexity of the
goal. For more pleasure of the process we bought special cards with these values, for all the
participants to be able to show their assumptions simultaneously.


Initially, imagine that 1 point = 1 hour, but the result of the work of our team in this case was
on the level 35 48 points for 2 programmers. The point is in combining the results, debugging
errors, additional data collection. With this approach we focus not on the working hours but on
the contribution to the value of the application. It also displays the progress on our list of
stories more realistic:

The content of the sprint and daily scrum

When a set of the stories was selected and the team (which is important) vouched them to do
during the sprint, everybody starts the work. The Jire story includes such stages: new, in
working, test and ready-made. The stories which are in the status of test can already be
tested and returned for revision, if the problem is found.

Our service station controls minimizing developers multitasking in one time for 1 developer
should be 1 task in 1 ideally. Otherwise, when there are many tasks in the work it is
impossible to test them or to understand the progress.
To analyze the progress and difficulties every day our team meet for 5 minutes and share about
what has been done, what Im working on now and if there are any problems.
Using this approach, the team is always informed and assembled as a team in rugby.

Sprint Retrospective + Reports

When the week passes away the team collects the version and reports about the made
function. Our client in this project is CEO and he is very busy. In order to help him to control I
just recorded the video review of the new version and showed on the device what we have
added in this version and told what we plan to do next.
From time to time we succeeded to do a little more or less than had been planned.
At the same time we have never had finished functional in version. Just what is useful works
fully and can be checked. For example, the developers often set the goal develop the
architecture the manager cant check it. When you need to invite your friends and you can see
the least of your friends it is visually and precisely.

Documentation
According to the plans we have one-year support and development of application. But we
werent idle and had made the documentation in English. There is a good rule for programmers
when making a decision. If this project is for someone to promote tomorrow what hell think
about the previous developer. If we have the words of gratitude the decision is right.

Conclusion 1. It Works and is Released in Time

First of all, as a product manager, I really appreciated working soft from the first week of
operation. Even when it is 1-2 final screen, it is better than a large volume but in the process.
If we suddenly saw that we didnt have time or we had the resource dropped out (people get
sick, computers break down, etc.) we would pass a good application in time. We could get less
money for the less volume of work and functions. But it is incomparable with fever and Epic Fail
in the night before the deadline.

Conclusion 2. Transparency of progress

We are fortunate to have professionals who love their work. And our expectations were often
exceeded. At the same time it is very easy to see the contribution to the project of each
member of the team, for example in closed point story.

Conclusion 3. Harmony in the team by the end of the project

One of the principles of Agile is self-organizing of the team. In complex project directory
management isnt the best solution. The participants shared their knowledge, supported each
other and found common approaches in solving problems.

If your team is involved in the project give them an opportunity to react and youll see the
motivation to do the best work.

Improvement of existing functions

A very common mistake in the construction of the product is overloaded with functions. The
result is ugly and not usable monsters.

Intermediate versions allow to see the imperfections of the current system and put their
improvement into a process. Google says that they spend 80% on the improvement of current
functional and only 20% on the addition of a new. On the market the solution with 5-6 ideal
functions bypass other with 100 but raw and undesirable ones.

Client Quote
______________________________