Everybody in our branch knows the Manifesto for Agile Software Development and nobody will be tired of emphasizing those values:
„Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan“
Yes, this sounds fancy and cool for sure! And why shouldn’t we tell people that we are working agile as it eases our daily business so much.
But isn’t it a lame excuse for being inconsistent of developing processes and using tools? Aren’t we just too lazy to write documentations? Nobody likes documentations. Really. Contracts? Sounds exhausting and no fun at all. Maybe we are also incapable of good planning due to an enormous amount of variables to deal with. You could say it is easy to hide behind the Agile Manifesto and name it as reason for not having defined processes.
Anyway we at the M-Way Solutions Professional Services Team are developing our applications agile. And – as our unique department name says – we claim to be professional as well! So how do we do it? And what does professional mean to us?
If a team is growing as well as the project portfolio there is one point where described processes are a must have. Otherwise chaos is exceeding agile efficiency and nobody will be happy. First of all we developed a process cycle which describes several processes from first customer contact to Maintenance. Anyway we try to keep it simple and we are also improving and updating this process descriptions from time to time if new requirements occur.
In this article I want to give you a short introduction in those processes we perform continuously:
1. Customer Communication
We love to talk to our customers! A open and clear communication with a minimum of information loss between sender and recipient is the key for successful projects to us.
Phone (or Skype) is better than Mail. Written words always cause a loss of information and misunderstanding. We always try to directly dial the customers number and find solutions on the phone instead of writing huge amounts of emails and wasting hours to find the best formulation between clear statements and sounding too harsh.
Note: Professional customer communications also means to document important decisions after calls for the future argumentation or organizational /HR changes.
2. Requirements Analysis
This is basis of developing good apps! Without a clear understanding of the customers needs it is almost impossible to create an application which fulfills the client’s wishes. You might have heard about the principle-agent theory which enlightens the asymmetry of information between sender and recipient. This asymmetry of information is crucial for immaterial information goods to which applications belong. Our solution for this is called workshop! Workshops are widely spread and this name can be (ab)used for almost every kind of meeting. In our workshops we try to interact as much as possible with our customers. A workshop shouldn’t be like a presentation. The client represents the typical app user and specifies the use cases which should be displayed in the application. Basically we draw a lot of crazy pictures on whiteboards and get a common idea of the application.
Conception at Professional Services is split into functional conception, User Experience Design and technical conception. The output of the requirements analysis defines the functionality and the IT architecture as well as the UX. Therefore Designer, architects and concept dudes put their heads together and create something beautiful. Basically there is one big question “What does the app do?”
In the Conception phase, especially in UX we follow a strongly visual approach. The goal of this process is to enable a very fast hands on experience to the client. As user experience is the totality of the end users´ perception of interaction with the app it is important to give the user (client) a good feeling of the app via in best case click dummies and wireframes supported by pixel perfect mockups.
Technical conception will clarify the app architecture with API´s, data aggregation and usage of several technologies. Also the decision between native or hybrid application will be finalized here.
Well, this can probably considered as the main part of an app emergence. Our software engineers will read the concept papers, examine the click dummies, take the graphical resources provided by the Design team and do some magic to create clever applications to ease the end user’s´ life. And hey – we are agile!
This means lots of prototyping via Continuous Integration. Source Code will be committed versionized to a git repository. Changes will be automatized compiled by a Jenkins CI Server and new builds will be deployed via Relution EAS our own gorgeous App Store with a multi status model. From Relution the project management hands over the versions to the Quality Assurance and afterwards to the client. Customers feedback will be gathered by the project management, evaluated and incorporated in a new version. That is one agile loop.
If you are now confused how to use git in efficient way Markus will clear up your mind in: http://blog.mwaysolutions.com/2015/07/16/a-short-introduction-to-git/
5. Quality Assurance
Our QA Managers inspect the application from end user’s point of view regarding usability and performance. There are predefined quality criteria which contain correct rendering, technical functionality as well as functional requirements. All in all the QA Team will try to crash the app, and find as much bugs as they can. They will report errors to the project manager who will prioritize them and create bug fixing tasks for the developer who screwed this up.
If you´re now curious how the Quality Assurance Team works in a more detailed way read also: http://blog.mwaysolutions.com/2015/07/02/how-to-test-mobile-apps/
To do documentation can be boring but becomes more and more important as the branch of enterprise mobility is emerging and becoming more professional. This means clients expect a valid and clear technical system documentation especially for bigger projects. Also requirements and change requests need to be documented. On the long term knowledge management is a huge thing.
I often hear things like: “Do you remember this great thing which was implemented by this dude we had three years ago in our team working on that project?” – Lucky you if you can find the project’s´ wiki site which also contains the necessary information.
Weather this article stops here the lifecycle of an application surely does not just stop with documentation. There will be an roll-out, mostly internal as we do enterprise applications. This roll-out can be accompanied by training. We also do hosting and for sure there is maintenance to deal e.g. with OS updates.
Now as you’re introduced to our approach of trying to be agile and professional at once, get yourself moving out of your comfort zone and define (at least on a low level) your processes. This will not only help your team to be more efficient but is also a nice thing to show your clients how you work.