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?
Over the past few years I’ve become more disappointed with my industry and this has left me tired wondering what I should do.
I’ve seen good experienced people leave the software industry as they’d fallen out of love with it.
Continue reading →
Explaining what you do to none software literal people is the hardest thing to do. Now that’s quite a bold statement as everything can be simplified into some simpler form; we connect this box to this box, we pass this bit of information to that place.
However, it starts to become more complex when the person you’re talking to has a bit more of an understanding of the subject matter. Continue reading →