When outsourcing, customers typically take the...
Understanding Agile & Why Every Software Development Team is Agile on Its Own TermsSuppose your company chooses Agile over Waterfall – the traditional project management methodology which requires little involvement on a customer’s part, leaves testing for last and enables customers to plan costs in advance) – what should you expect? If you look “Agile development cycle” up on the Internet, you’ll probably be overwhelmed by the amount of complex articles full of terms like “inception”, “construction” and “product retirement”. You will also discover there are many Agile project management methodologies including Kanban, Scrum and Extreme Programming. Unless you are a developer or Project Manager (PM) yourself or profess a certain Agile project management methodology on a corporate level, the research won’t add anything to your knowledge bank and will probably convince you to choose Waterfall in the end.
In most cases it is impossible to go by the book when outsourcing software development – unless you want to blame your team’s failure on the wrong choice of a project management methodology, of course. Instead, you should attain a firm understanding of an Agile project essential phases and learn what you as a customer should do at those stages.
Breaking down Agile Project Management Life Cycle
Team PresentationFirst, you meet your team – and it’s not just Account and Project Managers and a tech lead who will handle the requirements elicitation process and send you weekly or monthly reports during the development process as it happens with Waterfall projects. You communicate with the key members of your team in person or via a video call and are free to screen developers who will work on your project to make sure they have relevant experience and fully understand your business objectives. The personal approach increases the level of trust between you and your vendor and helps eliminate possible communication issues which account for 57% of all outsourcing project failures.
While a regular Fixed Price software project cannot move forward without a detailed Software Requirements Specification (SRS), Agile is all about seeing the direction for your project and not knowing its actual destination.One of our customers, for example, wanted to develop a web application that would analyze apartment and house plans and draw Smart Home installation schemes taking into account the house’s layout and wiring arrangement. Our client then intended to send users sets of plug-and-play sensors that had to be installed at certain points marked on the scheme. As there were no similar products on the market, our customer wasn’t sure how the system should work in the end and what technology stack it would use, so going Agile was the only option.
A clear understanding of a software system and the business processes it’s going to facilitate which is shared by the customer and his remote development team is the key factor behind an Agile project success.
This understanding is developed during the so-called Discovery Phase which, in its turn, features several stages:
- Business opportunity research. You should conduct a proper analysis to determine how a new software system will improve your company’s position in the market, increase your revenue and affect your employees working across different departments (sales, IT, accounting, etc.) For this purpose, you (among other things!) should prioritize stakeholders’ requirements and reach common ground. If you do not possess the internal resources to complete the task, you may also trust it to an experienced Business Analyst (BA) employed by a custom software development company you’ve addressed.
- Project strategy development. Alongside your vendor, you need to decide whether you’re going to build software from scratch or customize an off-the-shelf solution, determine the appropriate communication channel and project management software, etc.
- Feasibility study. In most cases that do not deal with rocket science, it’ll take a software architect about half an hour to test the feasibility of a software idea. If your software or hardware solution uses new APIs and software libraries, however, the process might take weeks if not months! The R-Style Lab team, for instance, once worked with a US manufacturer of intervertebral prosthetic devices which use unique identifiers. Our customer wanted to create a complex machine vision system that would automatically decode patients’ X-ray images, so we had to code small parts of the system to prove the idea was feasible. The developers tried various technologies and APIs only to find out the system’s accuracy did not exceed 70% (while our customer was aiming for at least 90%). In order to achieve the goal, we needed 4K X-ray images which were not produced by X-ray machines at the time, so the project was cancelled. In other words, the feasibility study stage helps you answer three simple questions – does it work, would I use it, does anyone need it in the first place – to filter out fruitless ideas, choose the right technology stack and reduce software development expenses in the long run.
- Software requirements analysis. The requirements analysis process places high demands on both you and your development team. At our company, for example, skilled BAs and Project Managers elicit software requirements through a series of Skype sessions or personal meetings to determine our client’s business goals and pain points. The information obtained is then forwarded to our architects and senior developers who create a software architecture model, write a preliminary project scope (a project plan listing deliverables and development tasks taken to create them) and split it into sprints – that is, periods of time (usually 2 weeks) during which certain goals like the development of prototypes, a Minimum Viable Product (MVP) or final product are achieved. As we mentioned earlier, you don’t need a detailed SRS to embark on an Agile project; what’s more, you are free to review the work done at the end of each sprint and make changes to the scope!
- Effort estimation. Based on the initial scope, your vendor will provide an approximate estimate of a software solution in question. Agile projects are usually billed according to the Time & Material (T&M) model, so you’ll only pay for the actual development hours spent on your project. If you don’t have enough money to finance the entire project, you can put it on hold after any sprint (although it’s recommended to build at least an MVP, as you need something to show to potential investors).
Unlike Waterfall which leaves customers wondering what the end product will look like and whether it’s going to be exactly what they wanted, Agile is designed to deliver tangible outcomes – be it a fancy contact form or a stripped-down version of the final product – with each sprint.Having said that, the approach works best when developers, Project Managers, Quality Assurance (QA) engineers and other specialists involved in a project are employed full time. It doesn’t mean you’ll have developers idling, though. Frond-end development, for instance, typically accounts for 30% of the entire project timeline. In order to manage resources effectively, your PM will design sprints so that a frond-end developer would only spend two to three sprints on your project, do all the tasks he’s supposed to perform and move on to other projects. Similar logic is applied to other programming and management tasks. Furthermore, you can track developers’ working hours using project management tools like Jira, Zoho Projects and Scoro and schedule a call with your PM, Account Manager or any other member of the remote team at any given moment. Agile teams usually take the Test-Driven (TDD) or Behavior-Driven Development (BDD) approach to software design. With TDD, our QA engineers write tests before programmers actually get down to coding; testing is then conducted at the end of each sprint, and developers don’t have to test the entire system all over again once a new software component is built. The BDD approach provides for a deeper focus on business logic and needs: our customer enlists tasks the end user is supposed to perform with the help of an app (behaviors), and software engineers ask additional questions based on their understanding of the app in question and enhance those behaviors with the behaviors needed from the development perspective (including workload, performance and scalability requirements).
Benefits of Implementing Agile Project Management Methodologies
- Increased velocity. In software development, velocity is the amount of tasks a development team can complete in the course of a sprint. A team of programmers who work together and spend 100% of their time on a project gain a better understanding of the end product and accomplish tasks faster.
- Improved product quality. On the whole, Agile teams tend to make 19% less coding mistakes and are 30% more likely to deliver software on time and within the agreed budget. Combined with continuous QA, this results in improved product quality and shorter time to market.
- Value delivered with each sprint. Every Agile sprint (even the Discovery Phase) is meant to deliver something (a good grasp of the product, prototypes, design requirements, a working MVP or a production-ready application) to the customer. As a result, you can start interacting with the software solution a lot faster and make the necessary changes to its feature set early on to get exactly what you need.
- Reduced software development costs. Once again, you pay for the actual man-hours spent on your project – and there are no stabilization sprints as QA tests are written prior to coding, while each software component is tested straight away. Furthermore, your vendor doesn’t need a buffer against potential risks (these include re-design, bug fixing and requirements analysis expenses which are always included in Waterfall project estimates), which adds up to the same thing.