I spent the early days of this week on a Scrum course that was presented by Ken Schwaber that a considerable amount of my colleagues at Conchango have attended. I must admit that I have been slightly sceptical about the viability of Scrum, mainly because I was trying to understand how to apply the practices to my current project within a large retail company in the UK. The project itself is not necessarily large, but it can touch upon the majority of the internal IT services offered within the company due to its nature - we are providing an Integration Services platform. Therefore there are can be a significant number of dependencies that would make such a switch challenging, without then being concerned about attempting to influence the methodologies practiced by those individual services whose resources you will be tapping into.
I left the course not only a (slightly pretentiously named in my opinion) ScrumMaster, but with enough knowledge and questions in my head to challenge the more traditional Waterfall framework in which I work. The benefits for using Scrum in various scenarios not only made sense, but there were also tangible results that had been gathered. It is not a new concept and has been in practice for numerous years in various sized projects.
The number of projects that I have been involved in as either a tech lead or a team member in the past whereby you have had to adapt your solution to changing requirements are numerous. I had noticed the difficulty for the team as a whole to adjust when adhering to a more rigid Waterfall approach. Not only that, I saw that this sometimes incurred monetary implications, especially if the changes were raised towards the latter end of a project.
Obviously changes should be managed with the various processes available and you could argue that some of these should be highlighted by a good requirements gathering exercise. But the reality is that requirements are not always known and often new ideas are grown through the visibility of a certain piece of functionality that has been created. Projects that I had been involved in had avoided some of these issues by implementing an incremental phased approach to releasing the solution. We also tended to provide as many prototypes as possible at the early stages of a project so that the customer could have a high degree of visibility and therefore raise concerns at an early stage of the system lifecycle.
So when I started hearing about Scrum I thought that some of these principles had already been adopted in a less formalised manner within the context of the Waterfall approach. It was comforting to know that not only had people taken these concepts and formalised them within a difference methodology, not only that, they had taken a closer look at other aspects and taken the whole agile approach to another level.
From what I learnt from the course, I believe one of the main parts of Scrum and probably the most difficult for some companies to buy into is the approach of empowering team members. One of the first exercises in the course was useful in visualising the theory behind this concept. Take a set boundary on the floor of a room and then fill this partially with a number of people. If you then pair up these people and ask one to direct the others movements with a set of simple commands such as left, right, forward etc and then asked them to see how many paces they could achieve within a set time period you would note that this is substantially less that if you just asked the same person to walk within the confines of the box on their own accord.
This is quite a simplistic view of the benefits of empowering people to determine their own fulfilment. However, if you complete the exercise rather than try and visualise through words alone it does hit home quite well. As said, this is a simplistic view and obviously giving your team members a free reign is not such an easy task, but that is where the role of the ScrumMaster comes into play. An analogy would be like a sheepdog (the ScrumMaster) guiding his flock of sheep. Scrum is a simple concept, but can be difficult to implement.
Going back to my original thoughts on how Scrum would fit in with the company I am currently contracted out to, I am not entirely sure it has its place quite yet. The challenges of educating such a vast, loosely coupled team of IT experts in addition to the complexities of their outsourcing programme, I believe would make this move too much of a hindrance with any project that spans a number of different sections of its IT infrastructure. However, any self contained applications that may need to be developed I believe could benefit from at least investigating the concepts of Scrum in more detail. Perhaps by slowly implementing Scum with each new autonomous project that comes along, the move towards using Scrum for the entire company could be achievable.
At present this is purely conceptual, so being part of a number of Scrum projects will pose new questions and improve my understanding of tackling some of my current ones. However, I do know that Conchango have implemented some projects using Scrum and they have been very successful. I think the challenge is determining which of those projects that arise are appropriate and those that are not.