An Agile process evaluation
In the recent past, I have been working as a scrum master for one of the projects. And since there were two folds to this project, a portion being handled onsite as well as a portion being handled offshore, there were initial hiccups that gradually deteriorated away. But here comes the crux of the problem and where an Agile process has to be evaluated.
We had weekly sprints where a subset of tasks were to be completed and we have a daily scrum between the offshore and onsite team. But the onsite team were persistent on a daily mail sent with the changes being addressed. Now the point of the scrum is to take into account who, what and where the changes have to be made based on the product backlog. Now having status mails as part of the Agile process is indeed a flaw in the fundamental flow. After pointing out this fact, I was counter attacked with several points (some of which were valid to have a status update email) and finally left to comply. Now here comes the secondary flaw and something which had a major impact in sprint. The onsite team demanded daily code reviews of the work done offshore. Now this caused a major butterfly effect in the scrum process. First the offshore team needs to comply to the tasks that need to be performed and then perform a code merge of all the developer's changes (again done by one of the team members) which put a lot of stress on the team member doing the merge. I tried to stream line this by asking different members to perform this on a daily basis, but eventually it could not be done in this fashion as well as even suggested a bi-weekly drop which was given a thumbs down. This led to a lot of down time and a morale let down as even I could not prevent this from happening as the scrum master of the team. I could not shield the team from this negative impact. And the other intake I could make was that the code sent for review was not being reviewed on a daily basis (this is the icing on the cake). I on the other hand had to ensure that a few deliverables on my plate did meet the deadline and could not help the offshore team in making changes to the Agile workflow we had in place. Then came the impact of managing the project with TFS (which I definitely had my eyes on) since it became easier to track down the deficits as well as generate charts to figure out where we were heading towards each sprint. But this was turned down by let's say the new product owner who wanted to do this via project plans. With all this and all my say not being looked at, we struggled to get the project to production ready with very minimal glitches.
I think the biggest mistake was my accepting responsibility as the scrum master. The scrum master must be the most strong willed member of the team and should say "NO" when the moment calls for it. But then comes to adapting to the organization's work culture which ultimately led to the undoing of the Agile process. I gave in more to the culture of the organization than the needs of the project which might happen in the future as well. But the next time I will more geared and in case I see the red lights propping up, I am going to step down as the scrum master if I were made one. Also in the case of the pigs and chickens analogy, the chickens had the major say in this case which again is an Agile flaw. But this has left me with quite a few questions unanswered:
- Corporate Culture VS Agile project management. Which needs to be given more priority and Why?
- Do all the team members have equal status in the Agile process or are there scenario's where certain team members should have more pull?
- If point 2 holds, what could be scenarios this could occur?
- Product owner VS Scrum Master in making product design changes based on the sprint timing. Who should have more hold?
Based on my understanding of how Agile works and some of the books I read, I get varying answers to these questions. I think it something that I need to ponder on and figure out an approach myself. Stay tuned to a future article about my insights into such situations….