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.
Continue reading Specialisation and agile
An interesting question came up on Quora the other day. Here’s my answer:
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:
I saw this question on Quora that piqued my interest. In answering the question (Spoiler alert: the answer is Yes) I describe my approach to managing change on software projects.
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:
A question appeared on Quora asking for the must read book on agile for businesses. Here’s my answer:
Someone asked how they could become valued on without being a genius programmer. I blame “The Social Network”. Here’s my answer:
Someone asked how to handle external deadlines in scrum. Here’s my answer (spoiler alert – the answer is use Scrum)!
As an enfp I am very conscious of praise. External validation is really important to me so I am always looking for signs that my work is being appreciated.
However, there are kinds of praise that work for me and others that I mistrust.
A previous client would frequently tell me how happy they were that I was on board. This is the kind of praise I mistrust. It’s generic rather than specific. It’s like being praised for being beautiful. It makes me feel uncomfortable and anxious. I feel that it sets up an expectation that I cannot live up to.
Being praised for a specific thing I have done however, is a different matter. This acknowledges a past action without setting up expectations for the future. This is the kind of praise I like. This is the kind of praise I try to give as a manager.
There is some scientific basis to all of this. In his fascinating book “Bounce” (a must read for anyone who cares about managing well) Matthew Syed recounts the difference in performance that is seen when people are praised for their hard work rather than their talent.
A question was asked about this on quota. Here’s my answer: