Agile, cool and hobos !
September 24th, 2017 | Heri
I'm Heri, Scrum Master and Lead software engineer of the team and today I'd like to tell you a little bit more about the development team organization. Since we started developping this application we decided to go for an agile approach instead of a classic V-cycle model. Why is that, what are the results ? Let's check it out!
For many traditional project managers (PM) agile is scary, it includes too many changes and is usually too unpredictable to be reliable. It also rethinks the traditional organisation of a team as well as the relationship with the client. To trully understand what is it, I will quote here the Manifesto for Agile :
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
If there is any PM reading this post I can easily imagine them cringing while reading these four sentences. You can read more about the principles of agile by visiting this short page. Many traditional PM argues that this method can't be used on big projects or that the "lack of organization" makes it messy. The idea of agile is to adapt to changing requirements of the client to meet client satisfation. One of the biggest industry being the video game : if you look for an industry brassing lot of money using agile, this it THE one. Game companies have the constraint of regularly showing demos, having open/closed betas and other events to attract people into their game and build up the hype around it. Gamasutra covers it in a great article about Scrum and game development. So let's see why we decided to use agile compared to a waterfall model.
Let's face it, VR is an emerging field and technologies are revealed every day. One day you have SDK charging you hundred of dollars for SLAM technology, the day after Apple makes ARKit available to everybody for free. We need to find a way to integrate or at least try these new tech without impacting the product development. If an SDK is interesting for us, we can then create a new feature with it and plan the integration in our sprints. When Apple announced the ARkit, we used one sprint to develop a small demo and learn how it works.
Our ARkit Shopping demo bringing you to a wine cellar
Even if we have great ideas, they still need to be confronted to real users feedbacks. We are exploring and experimenting in terms of UX and this article covers the many (not all) challenges of UX on VR. We have to find new way to interact with a virtual world using devices like Leap motion. We think about interfaces with no buttons but interactions instead and we analyze the reactions to these changes. With this strategy we are confident to have a product that will be convenient to use, plus it gives people something fun to do when they visit our booth during exhibitions ! People who visit us regularly can also see continuous improvements of our product.
The Coolhobo VR wine space experience doesn't include any button. It makes the user manipulate bottles by grabbing them.
The obvious good thing about Agile is that people can see the progresses of the software over time (while in a traditional V-cycle you would only see the result during the testing phase). At the end of each sprint we end up with a working product that meet out code quality standards. The interesting thing is that as mentioned in this article, we notice that the final design of the application becomes emergent. Instead of being planned the design naturally evolves to meet the user need ! As the article says :
"Scrum teams acknowledge that as nice as it might be to make all design decisions up front, doing so is impossible. This means that on a Scrum project, design is both intentional and emergent. The design emerges because there is no up-front design phase (even though there are design activities during all sprints). Design is intentional because product backlog items are deliberately chosen with an eye toward pushing the design in different directions at different times."
Evolution of the Coolhobo AR app over the time (2 months separate the first and the last picture)
Another indirect effect of Scrum over the codebase is that it forces you to have a very flexible architecture. In some V-cycle projects I did in the past, many finished project had problems during the maintenance because the client wanted something that was not planned in the initial scope (and the PM always said yes to everything but... that's another issue :D). In Scrum, we embrace these changes ! We write code that can easily be upgraded and moreover we make sure that all the components are independant so we can replace them easily. The biggest example is the AR engine that we currently use ! We started with Vuforia, then tried EasyAR to finally settle on Kudan ! The impact on the codebase was minimal thanks to a flexible architecture and if we decide to change again we know that it won't be a big deal.
Many people will tell you Scrum is great for client satisfaction, good software and excellent technical architecture... I agree with these points BUT one thing that is not emphasized enough is that Scrum can create great teams ! It's not only about delivering a software, it's also about people working towards the same objective and the same goal. It also push team members (whatever their role is) to exchange with each other :
as a lead developer I can teach other developers software practices so they can improve
the developers teach designers how to use GIT in order to share the 3D models and assets
the designers teach basic 3D modelling and graphic creation to developers for quick prototyping
Even if we all have a field of speciality, all the members grow skills over time and learn from each other increasing the capacity of the overall team. In addition everybody can write stories/feature and contribute to the final product. This will give all team members a feeling of ownership on the final application. Of course the Product owner (PO) will have the final word on developped products but he may get interesting input from the team (for example when we want to try to use ARKit and ARCore to check their capabilities). Last but not least... There's no Project Manager (PM) in Scrum, only a Scrum master to make sure we apply the method correctly and a PO (who is from the business side) which means that everybody has to take decisions and give input to the final software.
Every day starts on the Scrum board
This article was a sum up of all the majors reasons why we use agile methodologies, of course this methodology is not fit for everybody. Some PM will not feel comfortable about self-managing teams, some developers wil not be able fit into an agile team, some PO will be too busy to be available for the team... Many obstacles can rise from implementing Scrum especially in China where you have traditionals vertical hierarchies. It's not only a methodology, it's also a mindset. The next challenge will be to find other people with the same mindset to join us !