To stay relevant in a digitizing world, organizations must master continuous improvement. Because many – if not all – of the necessary changes for this kind of optimization are driven by software, businesses face a never-ending challenge of improving their software platforms faster and making them more flexible each day. Evidently, though, evolving from semi-annual or monthly releases to virtually continuous roll-out is no easy feat. Using DevOps as a lever for release management is a clever and increasingly common strategy to make organizations more agile. Unfortunately, a prescriptive set of steps to implement DevOps principles and practices for this purpose does not exist. But don’t fret just yet! AE has got you covered with a structured, scientific framework from the DORA* research program.
In our ever faster digital world, time to market is an increasingly important factor in any IT project. A shorter time to market is crucial to stay ahead of the competition. However, this is not possible without an agile and qualitative IT environment. This is where Quality Assurance comes into play.
Recently, I participated in an agile business requirements training given by my colleague Thomas De Vries and Patrick Steyaert. One very interesting technique that they highlighted is story mapping. In this post, I will explain how to apply this technique and highlight the advantages compared to traditional techniques for eliciting requirements.
Business and IT speak a different language. This is a challenge for many organizations as it hinders communication about requirements in IT projects. An often suggested way to deal with this problem is to use the simple and fixed format of user stories to express requirements (as a..., I can... so that ...) and I fully agree on this. However, as a business analyst, I notice a lot of confusion among business people when it comes to the definition of a user story. I often hear that user stories are too technical for them. In this blog post I provide 4 tips to write user stories that express business requirements making sense from a business point of view.
One thing we've learned from the first phase of the iHRM program is that a complete waterfall approach with one delivery moment, followed by an extended user acceptance period is not the silver bullet. For the second phase of the program, the scope is wider and the number of project teams is higher. In this blog post, I'll share some insights on how to effectively manage scope while going for an iterative and incremental development plan.