When practising Continuous Delivery, it’s important that your application is deployable at all times. This can introduce some challenges, especially when you have features that span multiple builds, or bug fixes that need to get into production quickly.
It can be challenging to get sufficient infrastructure set up to enable you to practice Continuous Delivery, but the biggest challenge may be changing the way you (and your team) think about releasing software.
We’re a company dedicated to producing quality software our clients love, and we’re constantly striving to refine and improve the processes we use to do so. With that in mind, getting things “Done done” is a massive priority for us, and anything that hinders that ability is something we will always work to remove.
One of the riskiest parts of software delivery is the production deployment.
I’ve worked with organisations at various stages of their Agile transition, during which I’ve seen Agile implemented well, but I’ve also seen it done terribly. In a break from my usual tradition of myth-busting, I wanted to share some hard won lessons from my years as a Scrum Master, and give you some tips to help your Agile transformation succeed where many fail.
In my last post I mentioned a common controversy linked with story points. Common wisdom asserts that they shouldn’t be used to represent time, but this is on over-simplification which inhibits good estimation.
A couple of weeks ago we had our first ever Made Hackathon day, where we built a product—based on an existing idea—from scratch, and had it launched by 5pm. It was great fun, and very rewarding for the whole team.
Of all the tools in the Agile developer’s toolbox, the most often misunderstood is the Story Point. Some people will tell you a story point is a measure of time, others will emphatically argue that a Story Point measures complexity, difficulty or effort (anything except time!). I’ll tackle that particular can of worms in a future post, first I want to outline what Story Points are, and why they are useful.
At Made we’re very keen to have our deployments run as safely, quickly and as easily as possible. When you’ve worked on a new feature for a project you want to get it in the hands of the client and end-user at the earliest possibility.
With many of our clients, we see issues of data fragmentation: data that is duplicated in many places, often updated on a casual basis, and with little clarity as to which copy of the data is the most current. This data could be anything from product stock levels, through to customer contact information or retail sales figures.