Agile incentives 1 – the CEO

This is the first in a series on agile incentives. In it I will take a number of key roles within an organisation, outline the high-level incentives that person has, and then discuss how the adoption of agile aligns with those incentives.
Today I’m going to start right at the ‘top’ of the organisation: the Chief Executive Officer (CEO).

Continue reading Agile incentives 1 – the CEO

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.

Continue reading Specialisation and agile

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”.

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:

Read Stephen Green's answer to How is code quality ensured when code reviews are taking too long? on Quora