Gunther Verheyen says that Scrum starts with Done and a recent incident in a Scrum Team I’m working with helped me remember the power of the Definition of Done.
I’m following the process of becoming a licensed Trainer for Scrum Masters as outlined by Scrum.org. (https://www.scrum.org/become-professional-scrum-trainer/psm). The process is a mixture of exams and reviews in which you have to pass each stage in order to progress onto the next:
(taken from http://www.thescrummaster.co.uk/
Many years ago when I first attended a Scrum course, it was suggested that the burndown chart was similar to a boat moving from point a to point b and the burndown records its progress – sometimes it is on course, sometimes it is off and adjustments need to be made in order to correct the course.
After being a Developer and having worked with some great Developers, I thought it would be worth highlighting some of the characteristics a Developer should have when working in an Agile team.
In everything we do there should be some value – some importance in what we do.
If not then why do it?
Without any worth, the thing that you’re doing becomes a chore or you can easily drift on to something else. So we need to see the value in what we’re doing.
However, as a team we don’t always see the value at the same time; depending on your point of view you will see the value at different stages. Continue reading →
“If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck.“
implies that a person can identify an unknown subject by observing that subject’s habitual characteristics. It is sometimes used to counter abstruse, or even valid, arguments that something is not what it appears to be. – Wikipedia – https://en.wikipedia.org/wiki/Duck_test
How about this..?
One of the complaints I’ve heard is that Developers cannot present; which for some people is true. Providing a structure to the showcase / review should help present the work in a way that all attendees can follow. Continue reading →
Agile allows us to commit at the last responsible moment, delivering value early and have self-organised teams.
So why have a role in a team which forces you to do upfront design on a system, when we don’t know all the requirements yet, let alone how we’re going to meet the requirements?
NO we shouldn’t
Ok – but why not?
Our role is to give options – Always give options. As a Team we should be able to say if things are not possible but then immediately follow that statement up with what we can do to help.
I first heard the phrase “Don’t devalue the learning process” on a podcast of either Hanselminutes, This Developer’s Life or .Net Rocks. The talk revolved around the way, in this industry, when we struggle to resolve issues, we battle through, attempt new things and then when we find the solution go “Oh, it was that. Of course. Right what’s next?” The two feelings don’t balance out each other; the effort we put in to resolving the issue isn’t matched with the equivalent feeling when we find the solution.