Agile is all fun and games once you’re up and running, but how does one start developing a software product in an agile way? There is a lot of information out there about how to run an agile team - Be it with scrum, kanban, or any other flavor of a variety of agile processes. But when it comes to how to get started, most advice is “just get going”. So how does this “just get going” look like?
Project based “Design first and build it once” approaches are a waste when creating software. Software engineering benefits hugely from an agile approach to product development - not just because software lets us tackle more complex problems, but also because of the different constraints that software development faces compared to other engineering disciplines. Software is wonderfully volatile and easy to change compared to other engineering disciplines, so a different way of building products is necessary.
“The software is almost done, we just need to integrate it on the device.” Is one of the biggest self-deceptions in embedded software development. What often follows are failed deadlines and weeks or months of everybody taking shortcuts and hacks to finally ship that device. And often enough, what could have been an awesome product severely lacks quality in the end. Early and frequent vertical integration is THE way out of this deadlock and often a huge game-changer towards better products and agility.
Having a high-quality backlog is a cornerstone of lean-agile development. The backlog is a central part of agile software development. Whether you’re doing Scrum, Kanban, or any of the scaled agile approaches, virtually all methodologies have a backlog as the central artifact of storing upcoming and current work. Because of its central role, handling the backlog well and keeping it lean is a necessity to unlock the possibilities of agile development.
I would like to do agile software development for my medical devices, but the #$%! regulations make it impossible! This response is common when asking people from med-tech or similarly regulated industries about agile software development. Contrary to this popular belief, developing regulated software in an agile way is not as hard as one might think. Yes, going agile will not lessen the additional overhead required to pass a regulatory audit. But by focusing on creating artifacts and features which bring value to the products first, the result will be better products.
CMake is awesome, but it can be hard to figure out. Over the last few years, CMake has become one of the most popular ways to build C++ applications and libraries. Unfortunately, you might be stuck with an existing piece of software that is built entirely differently - be it makefiles, gradle, Qmake or even a completely custom-built way to compile software - you name it. So what if you want to move your codebase to CMake without rewriting the way all these old dependencies are built?
“NoEstimates cannot work because people want to plan ahead.” Sounds familiar? Actually NoEstimates means does not mean the absence of any forecasting and planning ahead. Quite the contrary. By tracking the throughput of a team and having a lean development process planning can actually become more reliable, despite not estimating a single story.
99.9% of software bugs are caused by programmer mistakes. Testing and code reviews help, but are not enough. If bad code could be caught even earlier, that would be so much nicer. With Design by contract we software engineers get a tool that does exactly that. Design by Contract not just makes code more correct, it also makes it more readable and much more robust against regression bugs.
Breaking down stories in small, manageable chunks is an essential skill when maintaining a good backlog. Sounds good, but how does one actually do the slicing? Splitting backlog items is not magic, but a skill that can be learned. All it needs is a bit of thinking and a few techniques to get going.
How does remote teamwork actually work? Working together remotely has its challenges, but they are not as big as one might think from the cozy office of a co-located team. While the communication bandwidth of physical face-to-face communication still beats everything else, but modern technology and a few rules for online behavior can make up for a lot.