Once there was a project given to us for maintenance. Our customer said that it has been built with knowledge and what we got was good. We believed in that. A story about wrong assumptions and change for good.
We normally use Behaviour-Driven Development (BDD) in our projects in order to minimize misunderstandings between developers and our customers which can help reduce overhead and technical debt. This blog post describes our experiences with the tool Fitnesse and suggests Cucumber as an alternative to improve communication and efficiency.
In the basic retrospective formats like "What went well? What didn't?", everyone has the option to state things about the last sprint. Things that worked out well - the plus side - just as things that didn't work well - the negative side. Now there's usually only a single rule for almost any retrospective format: Public blame is not allowed.
This blame-free environment is also the crux: How would you be able to deliver a negative message without the option of blaming? Read on to get some tips of better message transportation in order to gain more.
Small User Stories are an important part of incremental and iterative software development. It's not always easy to split large Stories into smaller ones. Therefore, I would like to introduce 5 simple techniques for Story splitting.
It's important to split big chunks of work into smaller ones to handle risk and uncertainty. What should be done if a User Story can't be split, though?
We make estimates for the work planned. The team gets the estimates by playing planning poker. Our estimate drivers are complexity and uncertainty. So far, so normal. But what is this "uncertainty" and how does detail fit into the picture?
Creating an AWS EC2 instance is really easy. Just follow these steps and pay attention to the most common pitfalls and you're good to go.
If you connect your laptop with a dock and several storage disks, a global keyboard shortcut or - easier to remember - a touch bar button is awesome. Read on to learn how it works ...
Having an agile mindset is part of the eMundo spirit. We have lots of agile projects, so basically everyone must know about this. Yet, sometimes, doing agile software development is harder than expected.
To get around this, we developed a game - "The Temple of Grog" - that tries to teach the contents of the agile manifesto without actually doing software development. This makes it much easier because of the domain being completely inconvenient to any single workshop participant.
On a regular basis, you may want to tag the master branch with a (beta) version that is deployed to a customer's staging system.
People not engaged in development themselves (e.g. product owners) usually have a hard time following the changes that are made available with each new version. So the easiest way to help them is to create a readable changelog from the git log.