When is it done? An opportunity to help managers manage
Many developers will have heard a manager ask "when is it done?" and have felt a combination of irritation and dread.
Posts by Jasper Bogers
Domain Driven Design - What's in a name? That which we call a rose may not be a rose.
Early on in their career, most software developers develop a muscle memory for writing efficient code and avoiding code duplication. It’s unfortunate that in modular architectures, this practice can seep through into data modelling without context awareness, leading to tight coupling and constraining the software’s ability to be changed.
Handling DynamoDB TTL expiry events with AWS Lambda and DynamoDB Streams
... responding to the uneventful progress of time
There are plenty of ways to build software that responds to changes in data or outside events. It can be less intuitive to come up with a solution that needs to respond to nothing happening.
A day in the life of DevOps
No qualms with CALMS
DevOps is the idea, that the concerns and interests of developers and those of operations are better served when they aren’t addressed in isolation as individual silos, but in unison. As a result, the whole organization that depends on both ends up being more agile and more stable
Insecure by default with OWASP DependencyCheck
... and how to fix that
A tool that helps with scanning for security vulnerabilities in dependencies can be a great addition to a CI/CD stack. Using it poorly can leave you with a false sense of security.
Misconceptions about Scrum by the book
In every organization and in every team, I run into one or two customs that people tell me are part of "Scrum by the book", that aren’t actually in the book.
Problematic archetypes of a tech lead
How do you know when having a tech lead may be taking your organisation in the wrong direction? Let’s take a look at some of the archetypical tech leads, their pitfalls and ways to go about and deal with them.
So many meetings in Scrum!
I’m a developer and I like Scrum. Not every developer does. A complaint I sometimes hear is the following:
We spend so much time in meetings that I don’t get around to writing code!
— A frustrated developer
If you have - or are confronted with - such a complaint, I have some tips for you to take into consideration
Look to learn and don't think in ink
The book The Fifth Discipline by Peter M. Senge landed on my doormat recently. I ordered it after hearing Andrew Harmel-Law of ThoughtWorks mention it at the JFokus 2020 conference (article in Dutch). His takeaway was as follows:
"Placed in the same system, people tend to produce the same results".
Once I received the book however, a line at the top of the cover caught my eye:
"In the long run, the only sustainable source of competitive edge is your organization’s ability to learn faster than its competitors"
This statement rings so many bells I’d like to dwell on just that without even going into the book itself. There are two obvious yet often missed clues here that I’d like to share.
Agile rewrite of an existing system
The times I’ve worked on a project where the scope is "rebuild the existing implementation, but with new tool / techonology X", I’ve encountered various pitfalls that make these projects much harder than they need to be.
Let me offer some tips on how to deal with them.
Cultivating technical innovation in daily operation
Many companies that are undergoing a digital transformation are discovering that it is an endless endeavour. Technological innovation allows a company to become more responsive to change in their business domain, but also makes it subjective to progress in the underlying technical implementation. A lot can be said for the delivery pipeline optimizations that help deliver business value more efficiently, but how does your organisation keep up with technological innovation?
Automation and Measurement as first class citizens in your sprint backlog
When you start work on a product, your velocity may be low and not reflect the investment you need to make to have proper continuous delivery. Here’s an idea to make it visible.
When you build a soda factory, producing your first can of soda effectively costs as much as the entire factory. Of course you plan to produce a whole lot more, and distribute the cost over your planned production.
This is an analogy that’s worth considering when starting on a new product with your Scrum team. During the first few sprints of work on a product, a team is often busy setting up the delivery pipeline, test framework, local development environment, etc. All this work undeniably has value, but usually isn’t expressed as "product features".
For example: You have 20 similar functional user stories that would be an equal effort to implement. The first 2 sprints your functional burndown is low. This is because during sprint planning, whichever user story gets picked up first has the questionable honour of having subtasks such as "Arrange access to Browserstack", "Set up Jenkins", "Set up AWS account", "Set up OpsGenie for alerting" and "Set up Blazemeter for load test", to name a few.
Consider what the Scrum Guide says about a deliverable increment:
Incremental deliveries of "Done" product ensure a potentially useful version of working product is always available.
a "Done", useable, and potentially releasable product Increment is created
The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be "Done," which means it must be in useable condition and meet the Scrum Team’s definition of "Done". An increment is a body of inspectable, done work that supports empiricism at the end of the Sprint. The increment is a step toward a vision or goal. The increment must be in useable condition regardless of whether the Product Owner decides to release it.
Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it.
This is problematic because it means your first few sprints tell you little about your ability to deliver value given the manpower and knowledge at your disposal. Also, it may mean your first few sprints fail to deliver any functional increment that could go live. Because what you’ve decided constitutes value is different than what you’re investing in, it may feel like you’re forced to do necessary work without seeing measurable results. You have little to demo during your sprint reviews. Product owners get nervous the longer this takes. You’re destined to be off to a poor start.
See the following sprint backlog and resulting velocity chart. When you hide all the automation and measurement boilerplate work as subtasks underneath whichever user stories you pick up forst, your burndown charts give the impression you achieved very little.
"Fat" user stories with automation and measurement as boilerplating subtasks hidden behind user story velocity
This doesn’t seem fair.
Some resort to starting out with a "Sprint 0" of undefined length and without a sprint goal, to just get all the ramping up out of the way, as though it’s a necessary evil. Don’t do this. Focus on delivering value from the start.
