Being an aspiring software craftsman goes way beyond than just saying it. I’ll quote my own definition of software craftsmanship from my previous post. Software craftsmanship is a long journey to mastery. It’s a lifestyle where developers choose to be…
Posts Categorized: Agile
Is software engineering the best approach for developing software? Does it apply for the majority of the software projects or just a very few of them?Software Engineering was an answer for the perceived “software crisis”, back in 1968, in the First NAT…
Our team is currently working with a client on a medium sized, medium complexity Java application which has quite low test coverage. We are introducing characterisation tests to snapshot functionality. These will give us the confidence to refactor away technical debt and extend the application without regression. One of the problems we are experiencing is… Read more »
Quality has always been a “hot” subject in software engineering, and several good development practices used in Agile development, unit testing for example, have been created to improve the quality of the softwares developed. Programme Managers, Project Managers and Assurance Quality Managers haven’t just been looking for techniques to improve quality, they’ve also been looking… Read more »
In my previous post on High Level Project Estimates, I talked about 3 points estimates to help provide an up-front estime of effort for a project. Aside from the effort estimate you also need to consider other aspects that the team will spend time on. The following are some aspects I consider with the kind [...]
What is the best way to review a backlog? How do you ensure that it is “complete”? How do you ensure that the prioritisation reflects the business vision and goals? When first faced with a backlog, you are often overwhelmed by the long list of userstories. The most important step is to set a context [...]
Thanks to Rachel Davies for sharing her approach to constructing a diagram of effects.
Rachel proposes that the diagram of effects can trigger a team to discuss how a variety of issues relate and goes on to highlight advice from Bas Vodde and Craig Larman in their first book “Scaling Lean and Agile Development”, the First [...]
I walked past two teams doing their daily SCRUM standup today. Both teams claim to be agile. I didn’t join in (even as a chicken) but just observed for a minute or so.
The first team was sitting down in a breakout area. Their body language spoke volumes. There was not one single participant maintaining eye contact with anybody else. Two people were playing on their phones. One developer had his head in his hands. Most had bored expressions. The team leader who is also the SCRUM master was the only person who spoke for the entire time I watched.
The second team was stood in a space near their desks. They were gathered round a task board which appeared to be up to date and the focus of several of the individual’s updates. One person spoke at a time. Almost everybody appeared to be paying attention to whomever was speaking. Most updates were short and concise. A couple rambled on.
Other than both teams calling their meeting a SCRUM I could see no similarities.
As our agile adoption has spread beyond the original teams I suppose it is inevitable that as the experience gets spread a little thinner that people will simply label their existing activities with agile sounding names. Often we have no clear remit in those teams to supply a mentor and to try offer advice would result in rebuttal as team leaders guard their territory. Does this matter? Is there a risk that these teams who are not practicing agile correctly will diminish and discredit agile in the eyes of our programme managers? This is sounding a bit like an excuse for an Agile Inquisition going round checking that no team is using Agile’s name in vain. This cannot be a good thing either.
I was recently asked to help a client kick-off development of a new product. This was to be their first “agile” project so the kick-off had to set the scene for the collaborative development approach that was to follow.
I used a variety of tools and techniques to bring the project to life. As is usually [...]
Take-away #3 from David Anderson’s Kanban Coaching workshop.
A discussion of Kanban can only go on for so long before the subject of the Theory of Constraints comes up. In this post I’ll try to explain just enough to show this connection.