I think; as an agile development methodology this is well understood by now, or at least people have their own versions of it and by now comfortable with the overall benefits of it.. and perhaps the patrons have reached a level of maturity where they can teach someone on how tos or give an orientation of where it will be ... in the short note below I will summarise my experience and how much we have benefited from and its applicability to multitude of situations.
To be honest; its one of the most simple set of concepts to learn; still then the implementations becomes one of the most difficult aspects of the journey. We went through such a story way back in 2008 when as a project ours were going through a very difficult phase. Our service had no direct link with product development (at least in an operational sense), ours were no where a product company, but a hard core services / consulting company. Our success depended on what efficiencies we bring in day to day basis to the operation and less on type of innovations which SCRUM envisages or at least gives a perception about (dynamic products - googles and face books?). Our success came from how fast we can scale our teams and skill the team to run the operations.. still the talk about Agile SCRUM as a methodolgy of great efficiency led us to explore this methodology.
How did we start with it
So we started with doing some preparatory readings of the SCRUM methodology. People read the circulated material and came back to the meetings to share their ideas. And soon we understood that everyone had different ideas about how this should be done and whether its relevant for us... even worse it was one point in time thought to be an anti-authoritarian process which made people insecure..
We for our satisfaction got to some level of form to do this. Everyone agreed that getting started is more important than debating endlessly. Our senior executive was quoted to say that we were trying to understand that secret sauce to win.. once understood it will need much less thought but just practice.. how true that was in hindsight. I probably will take that advice for any new initiative which is prescriptive; we need to invent our secret sauce before we can say we understand that..
Implementation Approach
We started with daily SCRUM meetings. After going through the experience, I think the practice of SCRUM meetings brought a rigour in the team, a much more cohesive organisation, better reporting of the situation etc. probably it meant a day to day improvement in people's ability to perform. When you have a very dynamic set of requirements and the prioritisation is changing on daily basis i think the scrum meetings becomes very beneficial for you. It is perceived to be less heirarchical and less directed. But in our experience this was still to be lot 'managed' and lot 'told to be done' etc. But never the less the mechanism of reporting what happened yesterday and what is planned today was exciting to start with. Lot of people started thinking about how differently the same thing can be stated day on day (smile)..
The learning for us is that this is implemented at various parts of the organisation differently. Some cases 15 minute daily meeting ran for hours, but we did have success with some of the scrum of scrum meetings where we did that with 30 min window.. the audience was much more mature, the authority of the scrum master was tremendous..
Where we were dealing with direct customer groups and where we did have evolving requirements backlog formed a very useful tool for ongoing prioritisation and people's common agreement of sprint scope. Having been through that process and seeing the complex world of software product requirements I cant think of any other way of operating to improve upon organisations product and services description. It also brought variety of groups into the same platform - development / test teams with definite amount of capacity to offer into sprint, design members who can change the architecture or tweak the requirements in discussion with the product owners (in case there are too many competing requirements) , the product owners who can change the business case by going back to the sponsors (or budget proved insufficent) and finally people who will see things gets done end to end.
So in summary I would say, SCRUM is an excellent mechanism for fast paced organisations. Organisations need to learn to manage the demands put on the time to market scenarios and cross functional nature of teams - there are some very simple concepts involved to run teams and organisations in the methodology (to the extent that you wonder if they were new at all). The newness of SCRUM comes from sprint planning and backlog concepts of the process, which I think is must haves in the current multi stakeholder / evolving markets.
more information can be found in the wiki link below: http://en.wikipedia.org/wiki/Scrum_(development)
No comments:
Post a Comment