Pragmatic Agile Weblog

Agile software development in real life

Why SCRUM?

I guess this is the mother of all questions… And I actually thought there was no need anymore to answer this question in the team. I instead realized at the latest release retrospection meeting that some people in the team could not answer theirself this question… It was a very good feedback that told me I did not communicate it properly and/or I did not make sure everybody understood what we were doing and why. This post is a first attempt to explain the fundamental reasons why we adopted SCRUM (but I’ll make sure to have other in-person occasions).

First of all I must say adopting SCRUM was not something that the developers (in a broad sense, I include anyone contributing to the development of the product) asked to do. One day I woke up and decided we need such a change. I take all the responsibility, good and bad of this decision.

Here is what I think about software development. The development of a software is made of separate and discrete units (the developers) each working on a piece of the product or project and therefore in some way interacting each other. Potentially each unit may be driven by different forces, be influenced by many internal or external factors, tend to move quickly towards a goal or be static, vibrate consuming a lot of energy and going no where or try to figure out how to maximize the result with the minimum effort. Potentially (still) software development is an anarchic process, or, if you want, an art (this is the way usually people like to represent software development in order not to have any constraint and restriction 🙂 ).

I think of the software development process as the way to organize and discipline the interactions between developers in order to achieve a common goal.

If you lack a process, you risk that each developer goes on his/her own, developing what s/he thinks is what the goal is in a disorganized way. If developers were molecules, you could see this absence of a process like a gas (as a state of the material). In an environment ruled with very weak rules, people may work even very hard but due to the lack of directions, in a inconsistent way, resulting for sure in not hitting any remarkable goal.

At a complete opposite side, a team of developers can be very well structured and organized. You divide the team in functional teams, define tech leads, managers, junior and senior developers and then define rules: a process to define the requirements, a process to estimate them, a process to define a plan, a process to manage the plan, a process to manage changes to the plan. With a strongly structured team the tendency is that all those processes depend on some key responsibility, person, role. The analyst must define all requirements, the architect must validate any small change, the tech lead must estimate and decide the tasks to do, the project manager must check where each single resource spends his/her time and fine-grain follow the whole process. Due to the many centers of responsibilities those processes tend to become very formal and rigid. The main advantage of this approach is that it really keeps the established order and in a way it makes very simple to determine who is in charge of what. On the disadvantages side, it is pretty clear that such organization is very difficult to scale because it requires to scale the whole organization, increasing the number of middle layers. Again, if engineers were molecules, you can see this rigid ruled model of interactions like the team was a solid (as opposed to be a gas). It has its own shape and volume that you can see easily, but what happens if something changes or has to change? It is more likely that the solid breaks than changes its shape. Another disadvantage I noticed in a “solid” organization is that people in the team can take two main approaches with regards to their lead or manager: try to take their place or let them lead completely. Both attitudes are very bad; the former because generates a lot of frictions and makes people not work together, the latter because makes the environment even more rigid since people tend to wait that somebody tells them what to do next (see JTMWTD).

What does all the above has to do with Funambol? Well, I introduced the team here. Let’s introduce the product now:

  • Funambol is a product company
    • i.e. No consulting
  • Push email product
    • Blackberry open source
  • Client and server components
  • Carrier grade server
  • Many components
    • Synchronization service
    • Push service
    • Inbox listener service
    • PIM listener service
    • a portal
  • Multi platform clients
    • WM (smartphone & pocket PC)
    • Win32/fat clients
    • Symbian
    • J2ME
    • BlackBerry
    • iPhone
    • Android
    • Mobile linux
  • An online portal (my.funambol.com)

as you can see a quite complex product with many components. The most obvious approach in terms of team organization was by functions with leaders that concentrate the responsibilities of the development and the deliveries. I must say it was working pretty well. I had three or four specific persons to who I could go to ask for feasibility, efforts, deadlines and so on.

However, the product was still expanding and being everybody very busy, I started to notice something concerning. Fundamentally, the leads had to work more, trying to balance their role of being the leaders of the teams, but also the experts of the components they were in charge of. I started to notice that things were not moving forward alone, and many times the intervention of the lead was necessary to have a good delivery. I think the leads have been doing a terrific job and they were able in many occasions to resolve very critical situations. But then I started to ask myself if this model would have scaled with the increasing number of components. I was also concerned because I was noticing that people in the teams were not growing at the speed I wanted. I started to ask myself “why am I hiring senior people if I don’t let them fly?”. I started to get too concerned that people would have turned into YTMWTD people… I instead want that engineers are free to run on their legs, and fly, limited only by their creativity (and my business constraints 🙂 ). The “solid” model does not scale, does not free people creativity, does not let people become real owners of the product they are contributing to. We needed to change!

I haven’t been ever attracted by XP and I maybe I’ll never buy it (but never say “never” 🙂 ). What instead I believe is the real fundamental switch that will help us in changing the situation above is SCRUM. SCRUM sells itself very well, because it has something to give to managers. The iterative approach and the possibility to change priorities between iterations is a succulent sweet for product managers and the top management. However, I do not think it is the key. You can have an iterative process with a mini waterfall cycle, and believe me, it would work very well.

The key of SCRUM is that it forces people to take care of things, to feel the ownership of user stories and tasks, to be proactive and creative about what they are developing. In some way, it breaks the intrinsic hierarchical relationship inside the teams and allows the good developers to emerge. This is exaclty what I wanted and needed. SCRUM frameworks engineers work into a firm, but adaptable set of rules that turns software development into a “fluid”. A liquids has its own volume, but it takes the shape you want it to take. Therefore you can shape your software iteration after iteration, but people contrubute to the final result at their maximum. Each member of the team is invested of the responsibility to estimate stories, commit them, develop and test the software s/he developed. All this requires that each person feels a sense of ownership in all they do that the “solid” approach makes much more difficult. This is why I like SCRUM, this is why I wanted to introduce it into my team.

Advertisements

September 28, 2008 - Posted by | Funambol, SCRUM, Software engineering

2 Comments »

  1. […] Pragmatic Agile Weblog placed an interesting blog post on Why SCRUM?Here’s a brief overviewI guess this is the mother of all questions… And I actually thought there was no need anymore […]

    Pingback by Why SCRUM? » iPhone Tricks | September 28, 2008 | Reply

  2. […] engineering team uses the SCRUM methodology to develop software. It’s a very interesting method that seems highly compatible with free/libre open source software development habits. It mandates […]

    Pingback by SCRUM and volunteer developers | ][ stefano maffulli | March 20, 2009 | Reply


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: