This blog is intended to be a disorganised outpouring of opinions, observations and general ranting. The content will be loosely related to Agile and Scrum. A mix of coaching, retrospective summaries, challenges and even the occasional solution to a problem I have faced.
About me:
I am an Agile Coach, currently working for Asynchrony Labs which is a division of WWT World Wide Technology Inc. assisting with their development teams and organisation, improving the way they and their clients deliver software.
I have twenty-something years software development experience, working in the UK and the USA. I have been a software developer, I have managed software departments and more recently I have been an Agile Coach and Scrum Master. I have been involved in creating software for telecoms, air traffic control, law enforcement, industrial automation, the patent office and the Admiralty. Each was a different challenge.
I have a wonderful wife and four fantastic children. I have learnt that in life and in my work there is always more to learn and there are always opportunities to do better, although at times I feel like I am herding cats, or wading through treacle.
As an Agile Coach I am the happiest I have been in my career, I have found a niche where my skills and personality complement the job at hand. My goal is to improve the teams I work with and there is a huge amount of job satisfaction seeing them grow.
John Yorke 
John – hi! You may have noticed from linkedin that I’m now a fully fledged Scrum Master (albeit learnin’ every day!). Hope all is well with you.
I had a question that I thought I’d run past you regarding ‘doing just what the story asks’. Obviously stories should be independent and not sequenced but of course they often tend to be. If you are working on story 1 of a given feature and you know what the rest of the feature will look like from your refining sessions do you really just code for what story 1 says even though you know that you will have to majorly refactor or do you at least acknowledge what is coming, potentially even within the same sprint?
LikeLike
Congrats on becoming a Scrum Master, with your experience as a PO you will be amazing. First I don’t mind stories being sequenced if they truly are. Ideally better to avoid it but it is not really an issue, if there is a genuine dependency or sequence. The bigger concern is stories that must be done together, that is a big No No, you need to look at it again.
For the second part of your question. Yes absolutely you code for the story ONLY! If there are two ways of doing something that are similar in effort then code in the way that makes it easier to change later, but frankly that is not a concern. you are better delivering some value inefficiently than delivering ZERO value efficiently. Or delivering value late, because of a belief that you will need something later.
I cannot count the number of projects I have seen cancelled because they deferred delivering some value early in favour of efficiently working on something they were certain would be needed later.
“I know we will need this later” is in my opinion the most un-agile phrase you can use. Deliver some value – get feedback and then decide whether you need it.
Hope that was not too preachy 🙂 would love to catch-up with you at some point.
LikeLike
Ha ha. Not preachy at all. Completely get where you are coming from. I think the subtlety I am curious about is where the stories are all in the same release, or potentially even in the same sprint. I absolutely agree that anything beyond that may never happen and therefore should not be considered but to refactor within that timeframe seemed inefficient because at that point you haven’t actually delivered any value. One for Philosophy Corner perhaps ;O)
Yes, catch up would be great.
LikeLike
So… a lot of this comes down to judgement, these are guidelines not rules and we want the team to make decisions but to understand why and be aware of the potential consequences. Having said that I very recently worked with a team that wanted to bring extra columns in a table and make a separate table because they were certain they would need it later. I advised strongly against and gave them a pretty rough ride over it, they somewhat reluctantly went with my advice and it turned out they found a better way of doing it. (That won’t always be the case). But after that I could hear them pushing back on suggestions to “do things now because we know we’ll need it later” we don’t yet know what we’ll know later so defer decisions until you are in best place to make them. But again this is a suggestion not a rule, deferring decisions keeps options open. Options have value but options also expire. There is no answer but I prefer to not work/commit to a path ahead of time wherever possible
LikeLike
Also refactoring is a crucial skill in development, ideally the team will write code in a manner that is easy to maintain, they will write lots of tests that will make refactoring with confidence a breeze. If a team is worried about refactoring effort I would suggest that might be a smell that their code base has issues OR their priority maybe their own time rather than customer value, and we want a team asking how they deliver the most value not how they maximise their efficiency.
LikeLike
Fair point. The specific example was where there were changes to a database schema. Story 1 in the sprint very simply required an additional column added to a table whereas story 2 clearly demanded a separate table with a composite key. The team were questioning the value of doing story 1 as is when we knew story 2 was next and would effectively negate the work on 1
LikeLike
On an unrelated point, we’re full of world cup fever over here and Gareth Southgate the England Manager (who I happened to go to school with, by chance) has been demonstrating some excellent Agile values around transparency, servant leadership and self organising teams and lo and behold, we’re in a semi-final tonight!
LikeLike
Hi Bruce, I wrote a new blog that I posted yesterday that tried to address your questions from before about doing things now because it is more efficient. It was great to see England do so well and I was so glad it wasn’t a team of big egos like it used to be. The team philosophy Southgate showed was a good example for us, not to mention his fashion sense
LikeLike
Like the blog. Thanks for that. And like your latest comment. As I say the subtlety for me is whether the you TRULY just look at the story in front of your with no consideration of the Sprint or the release but, as you say, it could get pulled at any time so there is never a guarantee that the other work will be done. Much to ponder!
LikeLike