Agile development has quickly become the favoured method of project development in the workplace. It has replaced the old â€˜waterfallâ€™ or sequential methodologies for developing applications because it offers teams the ability to adapt and respond to unpredictability. This quality has allowed it to now become one of the most effective processes for both application development and cloud migration. However, the elements of Agile need to be fully understood, tested and adapted within your business to achieve the best outcome from the software development process.
The agile process involves developing in incremental, iterative work cadences known as sprints. These work by abbreviating life cycles of application development into smaller cycles and tasks. Each cycle includes own processes of designing, building and testing. At the end of each cycle â€“ which is usually around 2 weeks - the direction and progress of the application is assessed. The assessment should be completed with a high level of stakeholder engagement to gain the most informed feedback which will help achieve the best future iterations and final product.
There is however a major difference between this methodology and the old waterfall process. Waterfall is based on the assumption that you can describe the end product to your team at the start of development and build a complete product from this brief. Agile works on using analysis of feedback to help you adapt to necessary changes and avoid the product becoming irrelevant by the time it is completed. This distinguishing feature is important because initial plans can often become irrelevant due to a high risk of either the architecture or requirements changing before the application has been completed. Both the waterfall and sequential methodologies would not allow you to then make the necessary alterations until the project is completed, wasting valuable time and money. The point of Agile development however, is to make assessments incrementally during development so you can adapt to any of these business changes as you build.
The use of this approach will hopefully result in a reduction to both development costs, and the time spent marketing, which is beneficial both to the software developer and the purchaser. These are reduced by the iterations overlapping the work on developing the software with gathering the requirements; therefore potentially eliminating the concept known as â€˜analysis paralysis.â€™
After working with a form of Agile for over 10 years I've learnt a few lessons regarding its implementation. Primarily I've discovered that while the Agile methodology has become integral to our development process at WorkingMouse, elements of it have to be adapted. Here are 5 little pieces of advice I would offer to anyone using or ready to use this methodology.
No company ever uses pure Agile; instead this is a methodology that should be customised to fit the needs of the business. When you research Agile you're likely to return with a prescribed workflow described in lots of specific detail. However, it would be ridiculous to follow this process exactly. Businesses are unique and will vary in terms of the people, work environment and goals. Therefore it would be unrealistic to expect there to be a generic methodology to fit every business. That's not to say that you should immediately scrap the parts of Agile that you want to avoid, but you should be customising the process based on agile understanding and experimentation.
Though there will be many arguments for either side, I can safely say I prefer to use variable length sprints as opposed to fixed length. This does mean moving away from the most common Agile approach - Scrum - but it also results in a number of advantages. The entire purpose of Agile is to allow for variation and unpredictability. Variable sprint lengths and the Kanban methodology allow you to adjust your goals for any unexpected occurrences. For this reason it may be more appropriate to consider moving away from Scrum.
Generally, Scrum recommends 2 week sprints for the Agile methodology. However, in my experience this is far too short of a time. 2 weeks limits the time available to obtain valuable feedback and utilise it to improve for the next sprint. Furthermore, developers given only 2 weeks to meet a target will often become stressed or at the very least fatigued. This in turn negatively affects the quality of the code they will produce. While it is important to work in sprints, the time period for these should be determined in a discussion with your developers so that it is set at a realistic and achievable goal.
Combining these two methodologies is becoming more common. One company has even suggested that its customers get to market 50% faster and are 25% more productive when they employ a hybrid of Lean and Agile development methods.
Working with Agile I have come to realise it is complimented by implementing lean ideologies. Even though the evaluation process at the end of the sprint is quite different, they still work together in the innovation process. Generally, Agile is at its most effective for small groups of developers, but elements of lean are becoming valuable in adapting it to suit bigger projects. In a lean system the work is broken into a set of value streams where the output of one value stream leads to others. A larger project can therefore apply Agile by creating value streams to organise development teams in sequential and parallel streams of work so that at the end of each iteration, you get a new version of the product.
Now, with the introduction of software bots in the industry we are able to generate on average around 90% of the target code. The last 10% is still handcrafted by a software engineer. The result of this is a significant reduction in time spent on development and testing. This increase in productivity can then shorten the time spent on each iteration and transfer to a real cost saving for businesses.
Agile methodology is constantly being developed through innovation. WorkingMouse has improved its utilisation of Agile through implementing software bots during the development process. In the past, each iteration in the Agile methodology ran cycles of the same processes. These cycles split software engineering into three repeated activities: business analysis, development and testing.
If your business is operating on legacy software, it is likely at some stage you will decide it is time to be moving to the cloud. However, if you donâ€™t break the project down into iterations or sprints, you will be sorely disappointed. Donâ€™t go for an entire system rewrite in one go. More to the point, you wonâ€™t be able to rewrite your system in one go! If you are currently running users on your legacy system then a successful changeover to the cloud will need to be gradual and involve feedback to measure its effectiveness. Doing so will help you avoid numerous challenges associated with the migration process such as the cultural challenge and the technical challenge. To learn more about software migration challenges head here.