Building Agile teams to mitigate risk for organisations looking to launch new products, migrate to the cloud or build new data services.
Businesses want to leverage Agile approaches within the software development teams to be responsive, flexible and quick. However, there is an internal mismatch within the organisations in the way that budgets are set and allocated. There are many occasions where people fail to acknowledge this simple reality. As a result “muddling through” gets very painful and on occasion expensive. At Emeis we recognise the importance of the commercial alignment and embed this in our project planning. One technique that we have employed to good effect in fixed budget situations is change for free. Change for Free is based on the idea that the customer can make any change, provided that the total volume of work is not changed. This allows new features to be added provided that lower priority items are removed from the project.
Building a Minimum Viable Product (MVP) is a pragmatic step in building a new software product. Not least that it intuitively sounds like common sense. The challenge is that building an MVP fits into the category of things that anyone can do but not many people can do well. An MVP is not the output of a Hackathon, it’s a valid product with a minimal set of features required to get engagement. At Emeis we set out to build an MVP within 6 iterations, that is 6 sprint cycles. We believe that 95% of products can be built within this time box
Many corporates wish to draw on a startup mentality particularly within their software development teams. On the face of it there are many aspects of a startup culture that are beneficial such as dynamism, flexibility, autonomy. However, it’s really important to acknowledge that there are areas where business are not startups . Businesses typically have some form of reputational risk, therefore the build and throw away approach is a challenge. Business culture is not well aligned to failure – failure is rarely a badge of honour and is often career limiting. At Emeis, we support the dynamism of the start up but understand that constraint that business face.
The problem with a big bang approach to migrating applications whether it is driven by old technology, new features, or consolidation as a result of acquisitions is that its high risk. This is exacerbated by the fact that lift and shift is a misnomer and most organisations which to take the opportunity to make things better or at least they should. At Emeis we have leveraged a Microservices wrapper around legacy applications to effectively eat away at the old legacy app replacing it with a newly structured app built on a microservices architecture.
What distinguishes web facing applications from the old world that they are under continuous development. There is no notion of developing a product and transferring into business as usual (BAU). Web facing applications are either alive and in a state of constant flux or dying/dead. Applications are under continuous development or from a deployment perspective continuous integration. Additionally web facing application API and micro-services architectures are more loosely coupled, which increases the emphasis on integration testing. Given this new reality manual testing is neither practical or cost effective. The only option is test automation.
Procurement groups often exercise themselves on the relative benefits of Commercial off the shelf software packages vs Bespoke software. While the focus on build costs and the cost of ownership are valid, the choice is not. Focusing on operational software as opposed type desktop applications eg ms office, the COTS package rarely comes as an install and go option, more often requiring some form of professional services. Professional services may require “Configuration” and consultancy. Equally there is very little software that is built to day that is bespoke, the availability of extensive libraries, and package managers to manage dependencies is ubiquitous.
Building products in the face of increasing competition requires product developers to engage on the important stuff, differentiators, maintainability, scalability and security. Conversely, there is a lot of commonality around authentication and entitlement, administration interfaces and data migration. At Emeis, we leverage API’s to quickly build the “scaffolding” so that we can we move the conversation on to focus on the important stuff – the areas of real value add.
Perimeter based security and the battle to maintain it is a battle that I long fought and lost. The new model of security works at multiple levels throughout applications and platforms. As well as guarding against cross site scripting, or injection we employ techniques such as the principle of least privilege, to build a multi layered approach to security. At Emeis, everyone is empowered to raise a concern around security and take an effective part in the design. We also understand the importance of hygiene factors when it comes to security, small breaches lead to bad habits. We will never share a password over unencrypted email.