Every development project has a business guy attached, who holds the project money and makes the decisions what the team should implement. That guy can be your customer, sales manager, product manager, the product owner in a scrum project or simply your boss. In this article we will conveniently call him "manager". Constant small refactoring, test coverage and other technical things that you do while developing features don't really concern him. But from time to time you have a big, technical issue, that does not have apparent business value and does not add any features. You see it as absolutely necessary but you need the time and approval from your manager to do it. Watch this conversation between a developer and the well known "pointy haired boss", that I stole from a stackexchange.com post and that seems awkwardly familiar to every developer:
Tag Archives: Processes
Following our principle of Continuous Skill Enhancement here at Synyx I recently read the book Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble (from ThoughtWorks) and David Farley (from LMAX).
The book consists of three distinct parts.
Part one provides a high-level overview about the basics of software delivery. The authors are touching topics such as configuration management, continuous integration and software testing, describing what they are good for and what the challenges are when implementing them. While the chapters help to understand the terminology used throughout the book they don't (and cannot) describe each of the topics in great detail - there are other books for that. But of course you're already familiar with these topics so it's just a little refresher.
Gespannt habe ich auf das neue Buch der Kollegen Baron und Hüttermann über die Zerbrechlichkeit der Agilität gewartet. Zu oft habe ich selbst Erfahrung damit gemacht, wie missverständlich Agilität aufgenommen und interpretiert werden kann. Zu oft habe ich selbst gesehen, wie man Agilität missbrauchen kann, sei es als Schutzschild für eigene Versäumnisse, sei es um ein Buzzword mehr in seinem Lebenslauf zu haben.
"In der freien Wirtschaft ist nur selten Platz für rein technische Spielereien. Gut, bei Google oder Microsoft vielleicht, deswegen zieht es da ja auch so viele Geeks hin, als wäre ihr Logo mit Honig beschmiert"
For quite some years Scrum has been THE agile development process. Scrum got mainstream. But let's have a look what got mainstream here. Scrum, Agility, Buzzwords, Scrum Master got mainstream as words, in business talk, in dev talk, in trainings.
But what did it really achive for better communication, better relations and collaboration between developers, managers, customers etc. Has Scrum fundamentally improved the way software is delivered in our industry?
I probably couldn't find many people who'd respond with an unconditional "YES!" to this question.
But why? Why is Scrum getting an anti-word for many?