Posts Categorized: Agile

Testing and concurrency

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 »

Unit tests, code coverage and the hidden trap…

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 »

Project Estimates

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

Agile retrospectives – Cause and effect

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

Tale of two SCRUM stand ups

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.

Reviewing a project initiation

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