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.
Delivery
Building a Product in a Day
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.
Continuous Delivery with Jenkins
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.
Busting Agile Myths: Story Points and Time
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.
Busting Agile Myths: Story Points
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.
Why a Single Source of Truth Matters
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.
