Our friends from Ramotion needed a project management methodology in a software package that reduced timeframe & budget overshoots. What they got was amazing. What they got was Agile Scrum. So we asked them to guest post here a mix between an iOS project methodology and agile scrum case study. Enjoy!
A little bit about the team at Ramotion
Ramotion, is an Icon Design and iOS Development Company based in Ukraine that designs and developments mobile applications for our clientele. We have searched far and wide for project management methodologies and software and tools but none had fit our needs for our iOS app project, until we came across Agile project management methodology. We want to share our experience with Agile Scrum and how we used the methodology in our development process of our iOS application Pick’n’Roll. We hope you find this to be a great source of information and allows you to make up your own mind about Agile.
The game plan and play for Pick’N’Roll
Our team at Ramotion developed Pick’n’Roll which is an iPad application that works as a Dribbble viewer. For those of you that don’t know, Dribbble is a Twitter-like platform for designers and creative artists who want to share with other likeminded people designers their latest projects. This works by posting a small screenshot that sums up their latest design, application or project. This was a project that was extremely exciting to work on as we are not just developers, but designers as well!
Before we started development, we had examined the Dribbble API so we could understand the main restrictions and abilities of their API. Before starting the project, we promised ourselves that we would not hard code functionality into the application even if API doesn’t allow us to do something.
Initially we had a broad list of defined functionality requirements and ideas which came up in our In brainstorming sessions. Of course, a few of these ideas while brilliant, were outside the scope of the project so we selectively filtered out the lower-priority ideas and began to take into account all the constraints of the API. After this filtering process, the team at Ramotion made a list of core functions, that were sorted out by priority.
Since we first started, Ramotion have used different project management methodologies which although worked well at the time, probably were lacking some scope and definition right now. We decided it was time to throw out the books from the Jurassic age and try out something new. As an experiment Ramotion developed Pick’n’Roll using Agile Scrum.
How Agile Scrum helped Ramotion perfect Pick’N’Roll
It was during our development process that we decided to use Pick’N’Roll over other project management methodologies. In this industry, our clients have budget constraints and short term timeframes (because they are very eager to show the world their latest releases!) Before using Agile, we were using a development methodology called ‘Waterfall’. The basis of ‘Waterfall’ was that all functions are developed simultaneously according to RS which creation took 10%-20% of project. One of the limitation of ‘Waterfall’ was that testing was possible only when all functions had been finished. This problem was compounded when a client thought about trimming some of the application functionality to rush the launch release. It meant that some of the functions came out unstable and then the everything in the whole project required revision.
From a client perspect, they got an application that worked perfectly, but their initial budget and timeframe were blown over than what was expected in the initial estimate and customer remained dissatisfied (and rightfully so). We wanted to stop problems like this occuring right from the beginning and Agile Scrum looked like it could deliver. What is different about Agile Scrum is that it empowers developers with having the ability to release the project after any milestone or sprint.
The beauty of this methodology is that the client has control over which functions have higher priority and can be grouped into the sprint. This means that within the first sprint, all the core functionality can be implemented and the application can also be launched at the client’s discretion. In summary, Agile Scrum works because at the end of any given sprint, we have a 100% working version of the application that has been tested thoroughly and works correctly which the client can be happy with. If more functionality is neccessary, it is the clients choice to continue the next sprint with more budget & time allocated, whereas before getting a rushed released meant a blowout in timeframe and budget.
A project made in Scrum can be completed any time.
| Waterfall | Scrum |
|
|
Previously before development started, we had to create a lengthy specification document that listed all the requirements, core features with a full multi-page project description that was approved with client. It was impossible to change approved requirements, because ‘Waterfall’ only allowed a fixed pricing and all client side changes required additional costs and more manhours to change documentation. The beauty of using Scrum is that it is free from those rigid requirements. Everything that our team needs is in a fully managed & dynamic list of functions & priorities with a short description of how each function should work. This promotes better understanding across the whole team rather than having to wade through the multi-paged beast known as the Spec Doc.
Also with Scrum, the team could work with a few different tasks simultaneously with the option to swap in team members to different roles within development process (the basketball motif repeats!)
This resulted in
- Significantly increased development speed
- Quality control is distributed accordingly amongst all team members
- Developers don’t get burnt out with the same type of tasks especially if it doesn’t play off their strengths.
The tools that helped Ramotion achieve App Dev Glory!
Although it is quite difficult to start using something new when the entire team has been working a long time with another management methodology, we had little issue with Scrum. This was due to the tools that we used in implementing Scrum in our company.
Jira
We had been looking for a management system to put tasks, assign priority & check compliance. BaseCamp and other project management systems didn’t meet all our requirements so we made our choice in favor of Jira which was used as a Scrum board for easy task tracking.
Trainings and events
To make this happen, we needed to increase the knowledge of project management across the team. To do this we brushed up on reading project management & methodology articles as well as attending events to understand how it operates in a business environment.
We needed to simulate a Scrum project, and to do that was child’s play. We used this an excuse to play with Lego 
Our Lego based trainings served as a Scrum simulation which was the perfect to quickly train our team to work as a whole with this new methodology. Don’t think you are above using Lego, because you aren’t! Using Lego means the uptake of Scrum is a lot smoother since you do not risk losing time & money on mistakes during application development
Evolve with Scrum like we did and take your processes out of the Stone Age
Scrum was not mistakenly called an evolutionary approach. Our case study is proof of this. We just didn’t see evolution from building one simple function that adds to the final complex & functional application, but we also saw evolution in our team as well. Team members are always face with pressures and difficulties in the working process, so we are always looking on how solve problems and share those experiences with the rest of the team.
Scrum fits in well here as everything is swift and easy to navigate. This facilities the all important clear & quick communication skills that drives results before a deadline. We use and thank Scrum everyday for making us look more professional and maintaining client satisfaction which is extremely important as project pressure means a drop in morale & efficiency.
Our Work on Scrum allows the team to be fully concentrated on the task at hand, building the functions that are included in the sprint. There are situations where the bigger picture of development is unclear to the team and it is important not to assume how to develop it. It imposes certain requirements on the flexibility of objects which shows with our libraries and classes that are developed on earlier sprints being so flexible that they can be used in another application without any revisions most of the time.
The future of Scrum and Ramotion
In the near future, we will work towards automate all of our testing which will increase efficiency many times over. Our clients enjoy earlier released products and lower costs which are attractive to new & prospective clients when comparing us with our competitors. We already have some experience in this area as we extensively use unit testing and planning to introduce automated building and functionality testing. On a final note about our project with Pick’n’Roll, we will be continuing development of this app and want to improve UX as well as prepare a visual interface for the iPad 3 retina display. Scrum was definitely worth the experiment and we at Ramotion heartily endorse it for other companies who want to increase productivity with more efficient projects and happier clients.
Have you worked with Scrum before? Don’t think your current methodology is working correctly? Feel free to place your comments below!
