When I look into the roads through which the Agile framework has been evolving, it points back to a multiple source of managing software development. Like a project manager on any other mission, the peers in the field of software development also realized the importance of instituting a process. Thus there is Scurm, the process to address the complexity of software development by implementing inspection, adaptation, and visibility requirements in a simple set of rituals. It implements a simple iterative process skeleton which hangs on its own practices. At its core, lies a daily ritual of all-hands meeting to allow everybody to open up their hearts and deep (dark) secrets of their coder life.
Referring back to the classical way of managing projects, and the best practices recommended by the apex PM bodies; such a ritual fits within the project communication management. While the project communication management outlines a comprehensive set of methods and standards to address the communication requirements across the hierarchies, Scrum is largely focused for the people to whom the said project is the primary responsibility.
Being simple in approach, it makes the communication in a peer-to-peer format. Each Scrum starts with a Scrum-master who is tasked to ask 3 questions to everybody:
1. What did you do yesterday?
2. What will you do today?
3. What are the obstacles on your way to completion?
Each member of the project team is to answer these questions, in its most brevity possible, and the Scrum ends there. The collection of the responses form the progress made so far, the anticipated progress to be made in the next one day, the risks/issues in action.
The responses for the third question are particularly very interesting. This is the time the team members (read coders) are asked to open up. More they bring out their problems in hand, more transparent the project becomes. While Scrum does not offer the scope of problem solving right there, it facilitates the agreement of helping each other for problem solving. As example, when a developer is having a particular problem, another developer in the same room may have already overcome with an innovative solution. Scrum facilitates to have an agreement of getting this problem resolved on the same day. Similarly, when two (or more) developers are having the same problem at the same time, Scrum facilitates to have an agreement of joint attempt of resolving the problem instead of trying it from different silos.
The trick here is the culture of opening up. Programmers, by nature, take enormous amount of pride of accomplishing a complex programming problem. When they hit a problem, quite naturally, they try to own that and try to solve that by themselves. Not all programmers are comfortable enough to state a problem with the expectation that somebody will bail them out. Although, the Scrum master is tasked to ask a set of questions, this is the area where he/she needs to overcome the mere role of facilitator, and take a deeper interest in helping to get the problem uncovered. Similarly, there are team members who would describe their problem(s) with such details that it may appear to be very high on severity and complexity. The Scrum master also needs to ensure that such problems are discussed with their due priorities.
While writing this post, I came across two very good documents on Scrum. Both impressed me with their clarity and brevity in describing this practice and it fits well into your busy project life:
- Agile Meetings by Linda Rising (http://members.cox.net/rising1/Articles/STQE.pdf)
- What is Scrum by Ken Schwaber (http://www.scrumalliance.org/system/resource/file/275/whatIsScrum.pdf)
No comments:
Post a Comment