Tweet A few months ago an article was published in Computer Weekly where corporate IT Lawyer Alistair Maughan, argues the case that Agile will not work in Government projects.  I didn’t see this article when it was first published, but it was brought to my attention when a colleague noticed that one of the comments [...]

Tweet I feel enthused to blog about my current project, which is the first project I’ve ran where we have a dedicated UX expert on the team. For those of you who are not aware of the term UX, it stands for User eXperience. The UX expert will work closely with the customer and business [...]

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…

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…

Tweet 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 [...]

Tweet 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 [...]

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.