You've probably already heard of Scrum, the popular agile software development framework. While the basics aren't difficult, a lot of people seem to fail implementing it. In this post I'll sum up 10 things you should do if you want your Scrum project to fail miserably.
Some take aways from the 23rd BAEA Café with Chris Potts
Always inspiring, a seminar by Chris Potts. So I was keen on joining this evening’s EA Café about linking enterprise architecture to enterprise investment. If you haven’t read his books or participated in one of his workshops, I strongly encourage you to do so. Here are some things and questions that stuck with me today.
- Do you want to make your projects succesful, or your portfolio? If your portfolio is managed well, it gives you enough probability of success to ensure running a healthy business, yet allows for enough risk to prevent you from standing still.
Business Cases: getting money or creating value?
Business cases are a valuable instrument, but in practice they are not always applied correctly. They are often ‘misused’ in an attempt to get budgets allocated or to win projects. During a most interesting evening with our Business Analysis community, many colleagues presented real-life examples of how business cases are typically used by our customers. It was fascinating to see how the same patterns kept returning again and again.
What’s wrong with business cases?
Someone mentioned that: "You can always calculate your profit with a business case". As a result, business cases become more of a sales instrument for projects instead of a management instrument to evaluate and follow up on investments. And that is a shame, because business cases are extremely useful when applied correctly.
The Road to Continuous Delivery
In this post I will summarize some of the main principles of Jez Humble and David Farley’s great book on Continuous Delivery and share my experiences of applying them on software projects I’ve been involved in. First, I’d like to share a story to give this discussion some context.
Meet Joe
Joe is a software developer. It’s a regular Friday afternoon, 15 PM. Before heading home, Joe has to start this thing called a “weekly build”. Joe makes sure everyone on the team has checked in their changes to the source control system.
Joe starts the fully-automated build at the click of a button. The current build process takes some time, so he grabs a coffee. Five minutes later Joe returns to his computer, only to be shocked by what his monitor is displaying:
build failed.
