Category: Agile
Specialisation and agile
This article was originally published here on LinkedIn
The Scrum guide states that it “recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person”. I have read a number of posts and articles recently that seem to have taken a very narrow reading of this statement and imply (or even claim quite strongly) that specialisation within an agile team is a bad thing. Interestingly, it is often certain specific specialisations that these people seem to dismiss. These include business analysis (or service design), UX design, and sometimes technical architect. It’s notable that I’ve never seen anyone describe software development as being a valueless specialisation. Some of these articles I seem to imply that a goal of the agile coach should be to ensure that every member of the agile team acquires all of the necessary skills to deliver the product. In this agile nirvana they would have not just technical skills but also the soft ones such as eliciting requirements and understanding underlying business drivers.
Do we need a daily scrum
I came across this question on Quora and, while it’s very much Scrum 101, I thought I’d show off my Professional Scrum Master knowledge by answering it in full:
How do you start when faced with a big project
I found an interesting question today about where to start when embarking on a big project. The questioner asked whether they should start with the small or the big modules. My answer was rather different:
Best book for agile businesses
A question appeared on Quora asking for the must read book on agile for businesses. Here’s my answer:
External Deadlines in Scrum
Someone asked how to handle external deadlines in scrum. Here’s my answer (spoiler alert – the answer is use Scrum)!
When to document during a project
I came across this fascinating question today about how to determine what documentation is needed for a project. Here’s my answer:
Back to the source
I was listening to Vasco Duarte’s interview with Nirmaljeet Malhotra yesterday and he mentioned a thing that I often do: When people ask about this or that aspect of Scrum, I refer them back to the Scrum Guide. It’s a very short read, but it contains everything you need to know about the practice of Scrum.
It reminds me of when I practiced Aikido back in the 80’s. The head of the school that I practiced with, Saito Sensei used to say, “I teach basic, because there is only basic”.
Who can undermine the agile development process
A question was asked on Quora about whether Business Analysts can undermine Agile development methodologies. While the easy answer is ‘yes’ (as can anyone else) the more complex answer is that agile has the checks and balances built in:
Do Business Analysts tend to undermine Agile software development methodologies?
on Quora
Helping the team to ensure they capture all the tasks when they estimate
In my experience, the problem with estimates is not that the estimates are inaccurate, it’s more that people forget to estimate some of the tasks when they are estimating.
In this question from Quora, the questioner has observed that the length of time required to complete code reviews is throwing their schedules out. I suggest using their definition of done to help them to make sure that all tasks are estimated: