Building accountability in Agile teams - Someone needs to ask the tough questions

Agile teams often find themselves in a difficult position when it comes to accountability of the work done. Agile rightly promotes collective owenership, in the codebase, build environment, and even the story wall.While it is extremely useful to have polyskilled people in the team, it should not hamper the need for accountablity on the delivery of a Story, A Feature and A Release.

One way to build this accountability is to ask the critical questions when there are issues in delivery, and tie it with feedback so that the issue doesnt manifest itself again. This can also be coupled with a bit of coaching.

Examples

Scenario 1 : Customer's testing team finds a bug on a story which was delivered to them.

Question (to team QA) : Is this bug breaking the acceptance criteria of the story ?
QA : Yes

Question (to team QA) : Why was this bug not caught when we tested this story ?
QA : Well, this was working fine on the build I used. It broke in the build given to the customer for testing

Question (to team QA) : Why did we not catch this when we ran our automation/regression suite ?
QA : That is because we have some QA backlog on the automation front. This test isnt yet been added to the automation suite

Feedback (to team QA) : Well, that means we need to catchup on our automation first, before developing anymore stories. Now you understand how bad it looks when a basic bug is found during customer testing. Please take this as a challenge that from now on, any stories you test and give to customer, the customer should not be able to find any bugs in them. We should do all that is required so that a story does not fail at any point again.


Scenario 2 : QAs find some basic bugs during testing of a story. A bug which breaks a happy path scenario

Question (to team Dev pair) : Why was such a basic bug not caught during development ?
Dev : Thats because we had to refactoring as a part of another story which ended up breaking this piece of code.

Question (to team Dev pair) : Why were there no unit tests around this piece of code then ?
Dev : Well.. The unit tests were missing because I was finding it difficult to write tests for this piece

Feedback (to team Dev pair) : We now know that having unit tests around this would have ensured that this code would not have broken during a refactoring session. Simply put, if we had test driven the whole piece, we would not have ended up in this situation. I think we need to practice TDD more religiously. in the team. Let us have ahuddle to see how we can improve this. (Maybe look at some coaching on TDD)

It is the Iteration Manager's role to actually ask these questions and make the team retrospect their delivery, time and again, and learn from mistakes.This will allow the team to build more accountability on the work that is delivered.

How do we do both SOA and Agile in a big enterprise ?

The project I am working on currently is a big enterprise application, mostly structured around the SOA model. Since we evolved a legacy code base, the service boundaries have just started to become crisp and clear. We are slowly starting to think of certain teams in the project owning a set of services, and also deciding on service contracts as a norm.

I am now starting to wonder how this model is going to work with Agile teams.

* Will this force us to do Big Design Upfront ? (BDUF)
* Will this force us to have service level teams ?
* How can we write good user stories (which are testable and showcaseable) for service level teams ?
* How can we structure the teams when we have multiple consumers (teams?) for one service ?
* Will this force developers to communicate using service contracts and documents more than unit tests?
* If we try to encourage cross functional teams, will it put a lot of stress on resourcing, with the need of shuffling people around a lot ?

I do not have answers to any of these yet, and a quick look at the Agile community , also does not give me any concrete answers.

Using FreeMind in Retrospectives

So in the last few weeks I attended a couple of retrospectives for my team, and towards the end I facilitated one for another team.

To facilitate I used FreeMind to jot down points which came up during the retro mapping them using the Mind Map. As people were discussing "What could the team do better ?" , I ended up collating them on the map which was projected on a whiteboard. When it came to voting the top 3 points to discuss, we just asked people to put their votes (read color dots) on the whiteboard against the projected map.

Worked nicely. No use of markers, no dirty handwriting, and the team has their mental map right in front of them. The best part is, to send across Retrospective notes as a soft copy, all you need is to export this map as HTML/Word Doc with one click. You can even click print and give each person a copy of it before they leave the meeting room.




Worth a try guys !