10 Tips for starting with Specification by Example
Here are my 10 tips for starting with Specification by Example. These tips comes from my personal experience. They’re by no means rules or whatsoever.
Posted on March 14th, 2015
Team culture - knowNow
I just finished the mini-book "An Agile Adoption and Transformation Survival Guide". As a result, I wanted to model the team culture of knowNow.
There are a lots of quotes and statements flying through the air during development. They define our culture for a big part. I added the shared values we agreed on and now we have a model of how we roll.
We will hang the model on the wall, so we can add and strip so the model will reflect reality. I think it's also a wonderful starting point to introduce the team culture to new team members.
Posted on February 13th, 2015
Answers on Ron Jeffries' Thoughts on estimation
Ron Jeffries wrote a great article sharing his thoughts on estimation. I agree on his thoughts and shared some of my experience with him. Our team got rid of most estimations for over a year now. And we'll never go back.
Ron asks in his article to answer some questions about estimation and I replied with the following answers.
Where have small-scale estimates actually been useful to your team?
I'm the product owner of knowNow, a social knowledge management platform. We only use small-scale estimate for high risk proof-of-concepts. Maybe this sounds as a contradiction, to estimate for an uncertain period. We rank other features by customer value. Just like you wrote in your article. For me as a Product owner it's easy to determine the priority and to track value. But for technical opportunities, new tools and high risk features, it's harder to rely on just common sense. In such cases we try to breakdown the proof-of-concept in the smallest parts possible. Each part should give a result which we can validate on value, risk and better understanding of the amount of work still needed. The first part get a small-scaled estimate. This stimulates design thinking and extremely scoping the proof-of-concept. Based on this estimate, I can decide if we're going to do the experiment and if so when.
We did a limited number of these estimates last year and about 3 out of 8 gave me a reason to skip or delay the experiment. When we start the experiment it will be like a regular task and starts with a budget. Based on the progress and the results we can decide to continue or stop the experiment.
What have you done to get rid of estimates if you found them troublesome?
After repeatedly failed to meet sprint estimates, we just skipped them. Sprint reviews left the team disappointed most of the times, because estimates were not met. I, as the product owner, was quite happy most of the time. We did not meet estimates, but delivered enough customer value. Sprint plans got disrupted all the time due to bug fixes, weird problems or other unforeseen activities. With every sprint we spend a lot of effort in improving estimates, without significant results. Even worse, the team focused merely on meeting estimates than on creating customer value. Instead of getting more control we lost sight of the most important part: creating customer value.
The moment I realized this problem, we skipped the estimates for good. The sprint is like a budget, the priority of backlog items is clear and the team is highly motivated. For me it's a myth that better estimates makes people more productive. Everyone is giving their best and knows which features to develop.
Instead of estimates we put our effort in breaking down features in very, very small deliverable features. These features are straightforward, easy to understand and relatively simple. We do not need estimates for these features. The time we are saving with not estimating the sprint is spend on measuring customer value. By releasing small (sub)features, we stop developing on the feature as soon as it stops adding customer value.
At first we were afraid to lose discussion over the features if we didn't estimate them. And what if we run into trouble during development? What if it takes too long? What is too long? The answer is simple: communicate. We agreed that the team contacts me as soon as something disturbs developement. When a feature stops being straightforward, easy to understand or stops being simple. But what are the boundaries of easy, simple, too long, etc? Just by starting this communication it's calibrated soon.
We're skipping estimates for more than a year. And I can say we increased productivity, team motivation, quality and customer value.
Posted on February 4th, 2015
Gratis boek "Verleiden op het internet"
Via de site http://www.aartjanvanerkel.nl kun je gratis zijn boek Verleiden op het internet download. Zodra je je inschrijft voor zijn nieuwsbrief, dan kun je het boek in PDF formaat downloaden. Daarnaast vraagt de schrijver of je zijn boek wil beoordelen op bol.com.
Posted on September 28th, 2013
Syncing problems Evernote on iPad or iPhone
Hope this will help if you get the some problem like me. Evernote is syncing forever and then pops up with a message like it cannot sync with the Evernote server, please try again.
Somehow there were a couple of large notes with PDF files in my recycle bin. These notes stopped Evernote from syncing. Just by emptying the bin and restarting Evernote, the syncing problem was fixed.
Posted on May 19th, 2013
Scrum is a mirror
Last week I heard a great metaphor about Scrum: "Scrum is like a mirror it shows where you're fat and ugly. It doesn't tell you how to solve this."
I think it's a clear statement that SCRUM is a framework and not a process.
Posted on May 18th, 2013