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.