Agile Roles and Responsibilities - My Key Note from AGILE NYC Conf held on 11/17

I attended the NYC Agile Conf yesterday where Dan Mezick was talking about BART (Boundary, Authority, Role, Task)


This Topic in iteslf is very obvious given the fact that every book on agile (or any process) would say that you need to follow all rules to the T to make it work.
And of course, why not, the great minds behind the Agile Manifesto must have put loads of thought to write these responsibilites for different roles in an Agile world.

So now coming to the big question "what were the key take aways if the topic of disucssion was known".
I would say the the one thing I would like to write about after this session is to take a pause and "RETROSPECT".Let me explain.
When we kick off a project in SCRUM and put a team in place, we jot down a certain set of rules for the team to follow. The team then agrees to follow many of these rules and

takes up the responsibilities at will. They also start adhering to it religiously in the beginning. All good so far.

However down the line, there will be several instances when somebody in the team would drop the ball in doing what it takes for the team, given the responsibility he / she has.

And given our human nature there is this somebody who will back fill for this person and take up those responsibilities.
To give you an example there was this team where a senior team member, who was the tech Lead had taken up the task of facilitating all team meetings as the SCRUM Master (being

from the senior leadership) was not able to do that due to lack of bandwidth. Now such kind of instances are very common with every team, as we evolve and adapt to situations

and that is what we call team rythm in scrum.

So is such a kind of Rythm good or bad. Ofcourse like I earlier said, to make a process work, you need to follow every rule to the T.
The Verdict - We need need to avoid this as much as possible and if it is already happening to a great extent then we must plan to take corrective actions. But many a times we

just let it go because the team is delivering expected results and we are hesitant to make any changes fearing that it will reduce velocity. But if we just give this phenomenon

a deeper thought then it would make sense to put things in place even at the cost of a reduced velocity for a few sprints as it is bound to give better results later.

Well apart from this there was in teresting quote that came up during discussion in this Session.
" SCRUM Master is the Team's Mother". This topic in itself is so interesting and vast that I will be writing a separate BLOG to express my thoughts.
Till then Adios

- Nikhil