“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.
Change is everywhere in modern organizations. Those organizations that find it easy to change succeed, the others suffer. Life in modern companies is signified by fast and frequent changes. Be it agile transformations, digitalization, new tools, new technology, new methods, new processes (and much more) - there are are many powerful drivers for change in a modern VUCA-World The stories of painful and failed change are abundant, yet there are organizations that successfully change frequently without all the pain. What makes their changes much more likely to succeed? And how make they change appear easy? Together with colleagues at bbv Software Services we dove into the topic and we came up with seven major factors that contribute to successful and lightweight change.
A good part of leadership is to bring inspiration and purpose to people in order to motivate them do get things done. In modern companies job no longer falls to a single boss-leader, but situational, decentralized leadership is the way to go. In essence “whoever knows best” leads the way. In the book Start with Why and a TED talk, the author Simon Sinek describes what he calls the “golden circle” as a model to create purpose and inspiration. In the tiniest nutshell the method consists of three concentric rings, “Why” (innermost), “How” and “What” (outermost) and these questions get answered inside out.
“We only learn through failure. This quote attributed to the legendary alpinist Reinhold Messner holds a lot of truth in it. Modern organizations like to talk about good failure culture, but is failure in every circumstance a good thing? Probably not. As a software engineer and climber I saw a few fails with sometimes quite drastic consequences. Failure is never the goal but sometimes unavoidable, so how can we as individuals, teams and companies benefit from it?
What is your organizations currency of getting things done? When trying to getting things outside daily business done, every organization reacts to different kind of arguments and incentives. “Paying” in the right kind of arguments is often the key to get ones concerns put into action.
Cmake can be hard to figure out. I love cmake, but unfortunately its documentation is more focused on completeness than on providing hands-on-examples. Since I found it hard to find a comprehensive example of how a header only library can be set up, I decided to provide an example of a CMakeLists.txt file for such a library here and analyze it line by line. The example is taken from SI, a header only library that provides strongly typed physical units. In order to keep the cmake file as small as possible, few possible optimizations are omitted. Notably I stripped any information relating to testing out of the project.
Are modern organizations ready to pay the price for increased demand in their leaders? Countless companies and organizations are currently changing how they work internally. Some experience a growth spurt in the wake of digitalisation, others want to be more flexible in reacting to change. And a lot of these organizations struggle with these transformations. They got the agile framework of their choosing in place, they got the teams set up and maybe they even streamlined their portfolio and technological infrastructure. At first everything looks good, but after a while all the shiny new things start to lose their gleam and things become tedious again. Decisions take ages to be put into action and once a course is set, people find it hard to deviate from it. All the fluffy stuff like empowerment of the teams and people, that somehow does not seem to happen. These symptoms might hint that an organization is suffering from “leadership debt”.
Scrum is hard and tedious! It’s like groundhog day for software projects! Ever noticed that scrum does the same thing over and over again? Plannings, retrospectives, dailies, backlog refinements… Each sprint we do the same thing! Especially for long running projects this becomes boring. Programmers follow the Don’t repeat yourself paradigm, so why we do differently in processes? There has to be room to optimize, right? There is a solution to it: Scaled Single Sprint Scrum - It’s like scrum but totally different!
SAFe is the worst implementation of “corporate agile” that is out there! Over the last few months I heard this sentence or a variety of it a few times. There is some truth to it, but it is not the whole truth. The SAFe-framework is far away from what I imagine when thinking “agile”, but there are some aspects which are pretty neat. Despite all the critics it is a very popular framework that is implemented in a lot of bigger companies. So there has to be something good in it, doesn’t it? Let’s have a more differentiated look at it!
A good product vision is the cornerstone for being successful at delivering software products1. Having a product vision that is tangible and accepted by your developers is one of the most important things to have, if teams are supposed to work in an empowered and self-organized way. A vision is not just a good advertising tool, but it is the foundation to creating a purpose for everyone’s alignment towards what the product shall be. It is a common pattern, that companies that struggle with creating good product or company visions, find it very hard to create alignment and motivation in those employees who are building and delivering their products.
Actually this is true for any product in development, not just software. ↩
Most hobby projects die at the idea stage - Mine do not. A while ago I decided to revive an old idea of mine to implement the International System of Units as a strongly typed C++ library. In order to try to bring this project forward I tried an experiment: I would make at least one commit each workday for a month. A month later I am somewhat proud to say, that I kept this promise to myself with only one “comittless” day. But how does my pet project look now?
How good are your decisions? - Every day we decide a lot of things small and big. At work or any professional setting we often have clear deciders. This can be a senior subject matter expert, the traditional “boss” or some collaborative process in an empowered team - it does not really matter. Contrary to our private live, in business we often have to make decisions more explicit and documented, for instance in the form of meeting minutes. Some people are good at deciding, others find it very hard.
The core capital of modern companies are their employees. This fundamental truth is even more important for companies operating in areas that require highly trained and motivated people with a high degree of initiative. It is not just software companies that fit perfectly into that scheme, but almost any engineering-driven company and many, many companies outside classical STEM fields. After all as Humphrey Watts said: “Every business is a software business”. In the article “The James Bond Package” I wrote how having someone with the skills and mentality of James Bond in your company helps a lot when solving complex problems is daily business. However getting James Bond to work for you and then be able to unlock his full potential needs a company culture that fits the modus operandi of a secret agent.
Due to his combination of skills, motivation and initiative James Bond is the perfect agile problem solver. Agile working requires empowerment of teams and individuals, self-organizing and a different mentality than classical command-and-control structures. This is not just the case for the leaders but also for the people actually solving the problems and delivering the products. To perform in such an environment it helps if each and everyone of us shares a bit of what I like to call the “James Bond Package”.
“It is really demotivating, nothing gets done here.” A complaint I heard a few times in various settings. Sometimes just as a exclamation to vent steam, sometimes with a sigh and an edge of desperation to it. Surprisingly most of the time I hear this, it is from people that I esteem as far from lazy and quite capable of actually doing and completing things. But lack of motivation can strike the best of us.
Iterate fast and often to make better products. This rings true not just when creating software but also when developing it close to or together with hardware. IoT and fully automated Industry 4.0 are currently big topics in the industry, which promotes integrated development between hardware and software even more. Unfortunately, the reality is often that software- and hardware-engineers fail to work effectively together and because of this struggle with creating awesome products.
Unpacking a fixed size container in C++ can be tedious, and require you to fiddle around with std::get or std::tie. But not anymore, thanks to the new structured bindings introduced in C++17. Unpacking anything with a fixed size into named variables never has been easier.
Agile is successful and we know it. For years we scrum masters, agile coaches and change champions advertised and trained developers in the agile principles and the many frameworks and ideas out there. We have seen teams and individuals grow and become self-organized and empowered. It was fun but tough work. We grass-rooted ideas with the developers and helped people changing their minds about “how we work”. And it was frustrating when we hit the hard wall of culture-shifting whole organizations instead of just teams. Our teams worked well but somehow the movers and shakers of the companies needed a lot more and a different kind of attention to bring them along. Suddenly the ideas and principles we instilled so successfully into cross-functional teams of developers, testers and engineers were under harsh critique. Somehow there always seemed a someone up a higher level that did not agree with what we tried to achieve. Countless stories of trying to put scrum into action on a contract that is essentially waterfall are a strong indicator to that.
Planning poker, magic estimation, T-shirt-size estimation and even the famed #NoEstiamtes are too inaccurate - But there is a way to estimate to up to 50% more accurately by using a simple formula based on empirical measures and applied linguistics. Notice how developers use the same qualifiers for estimating workload over and over again? “It is just a minor bugfix”, “This is a huge, complex task”, “There is absolutely no way I can put an estimate on this one”. Heard this sentences or variations of it in the past? Your best estimations are lying in front of you in plain sight.
We need to be innovative! - I heard this statement or a variation of it a few times over my past in working as a software engineer. We engineers love this, as we get more time to tinker with anything we find interesting - Which is a lot. The result are often better tools or tool-chains to make our life as developers easier, but very rarely the output of such initiatives improves something tangible for the users of the product we are working on. Why? Because on these innovation days we are usually stuck together with other engineers which means that we mainly discuss engineering problems.
Good code is self-documenting - We coders love this sentence and with the standard attributes available since C++11 we are one step closer to this utopia.
C++ is hard! Luckily the new standards brought some features and tools to make writing C++ easier. Selection statements with initializers are one of these small-but-nice features that make our coding-life easier.
We should stop calling it agile and start calling it modern company culture. In the past fifteen years the word ‘agile’ has become widely popular in software development and other technology affine areas of business, but still people find it hard to find a consensus on what ‘agile’ means for them or their company. There seems to be an agreement that agile development contains such processes as scrum, kanban, xp or on a bigger scale SAFe, Less or any of the other frameworks out there. But an often heard complaint by people involved in software development is, that they are never “100% agile”. Or that they do scrum but find it hard to get that elusive culture shift happening in their companies.
C++17 - is officially out! So what can we as coders expect from it? With C++17 the standard-comitee brought further modernisation into the language. C++17 brings a set of new features which enhances convenience for the coder and makes writing portable code easier.
Agile is shortsighted! In scrum you are only interested in what’s going on in the next sprint! Kanban focusses only on what’s next! Long term planning is not agile! Sounds familiar? The gap between short term (sprint-)planning and long term roadmaps is an often discussed focus point in the world of agile and an often cited reason why “our company cannot do agile”. And it is true. A lot of litarature advertises mainly the fast reaction time and short iteration cycles that agile methods give us, especially if applied to software development. But it is also true, that a lot of businesses are operating on longer cycles than single sprints. Yearly budget allocations, fixed cost projects and hard deadlines are real and existing challenges in the industry. Leaving aside if this is how it should be or not, those practices are still alive and kicking in a lot of industrial sectors such as the medical or machine industry.
Meetings are boring, overcrowded, take up much of your valuable time and don’t produce the desired results. Or they can be interactive, efficient, goal-driven, interesting and sometimes even fun. So how to go about planning and running successful meetings? Five and a half Steps to successful meetings
Over the course of the last few years I read a lot of books about agile principles and teamwork and there are some that stood out to me as particularly worth to read. Most of the books are rather about agile teamwork in general than any particular methodology such as scrum or kanban. These books are also starting point on the way to knowing and doing agile, so the list is obviously by no means complete.
Everybody is a great coder! It’s now over fifteen years since I first got money for a program that I wrote, and since over ten years I consider myself a professional software engineer. When I started out programming I was convinced that raw coding ability and deep, innate technical knowledge of a few programming languages would be all it would take to make it in the industry. But over the years I learned that there is more to being a professional programmer than hacking together complex code. Having worked both in academics and industry, this often became most apparent to me when working with newbies fresh out of college. Often they are great programmers, but lack some of the surrounding skills to make them look professional to me. So what distinguishes the common coder and/or hobbyist from the pros? Before I forget: This article is written on a purely subjective basis of my personal experiences, feel free to tell me that I’m wrong