The Codist

The mobile group at work is likely to be forced to follow the exact same Scrum process as the rest of the company in the near future. Currently we operate a Lean/Kanban approach, which works well given the many products we support with a relatively small team. How Scrum is supposed to work with so many overlapping projects is really confusing.

We have 5 different but related projects, all using a common webservice layer of ours which acts as a front end to the back end services. There is a mobile website, two iPhone and one iPad apps and a variety of HTML5 Android apps that are all minor variations of each other. In the past year we had 80 releases including a pair of new iOS apps and many versions of everything. The rest of the company primarily supports a single large website and a lot of different backend systems which also call out to a lot of third party systems.

Our group is known for being extremely fast to market, a must since the mobile world is highly competitive, where the rest of the company never expects to do anything fast. Given the large number of releases of everything and a team with only a dozen or so people, being agile is a real requirement. We work closely with a product team that tracks stories using a Kanban style board. It isn't unusual for me to work on three different apps in a single week, and being flexible is definitely a plus to work here.

Now the pressure is going to force us to hire a scrum master and switch to standard iterations, and I don't see how that could possibly do anything but slow us down. Some updates only take a couple of days, some take weeks and some months. Not everyone works on everything however; although there is some common experience no one is an expert on everything. Scrum is usually good for single team single project environments with fairly long project times. Our issue is that our team has multiple projects with overlapping market requirements but a wide range of development times. This doesn't seem to make any sense in Scrum.

My own experience leading development teams started in the mid 80's with desktop apps, namely Trapeze, Persuasion and Deltagraph, which covers about 8 years and around a dozen major releases. In those days of course we shipped on floppy disks with printed manuals in a box. This of course predated much of the modern concepts of software methodology. What I would up doing would probably be called today Lean. It's funny to me that people often think that the only process predating today was waterfall, which we didn't do. Our releases were generally 6-8 months long since you couldn't afford to send out all those boxes much more often. For Deltagraph a major release to 100,000+ customers could cost the publisher a million dollars and they had to get the customers to contribute to the cost.

In this environment a release plan generally consisted of a simple list of new features and ideas. Over the follow months we would work with the product manager (for Trapeze that was all of us, for Persuasion it was the primary author and Deltagraph had a real one) to refine features as we went along. There was no formal structure at all, we paralleled work on features and added/dropped things as necessary. Testing was continuous. There were no formal documents or hard rules about anything. We didn't even have email until Deltagraph started in 1988/89, which was handy as the publisher was in California and my development team was in Texas. It all worked well.

Now Scrum could have worked in that environment I guess; although the original thoughts about it date back to the same timeframe it didn't really become known until at least a decade later. I think we would have rejected it as being far too rigid to get anything done. My preference for a Lean type of process certainly dates back to those days.

I've always thought of Scrum as being a line of mini-waterfalls which never really made much sense to me. Sometimes Scrum is seen as too static and robotic but if you have a lot of people and a long project having the comfort of predictability can help. Scrum does tend to keep the forces of change at bay but at the same time you lose the ability to be -- agile if necessary. That I think is the crux of our lack of enthusiasm about being forced to change. It feels like going backwards to a less agile process, and I think our product managers will be even more startled by a rigid process than the developers and testers.

We built a new iPhone app mid last year based on a demand by a board member who wanted us to compete with a new (but profitless) small competitor, starting the project the next day. Initially the app was supposed to be in the App Store in 3 weeks, clearly a laughable timeline. We started at great speed but it become obvious that features and design were not even barely known so everything was changed on a daily basis for weeks until a general design started to take hold. Many features went through 10's of iterations. In one case our designer was checking in one while listening to a group of folks deciding to change it completely. All of this iteration was necessary as there was no time given up front for consideration of what the app should do, other than the original vague request. We also had many user lab tests which sometimes required changes before the next tester showed up!

The app was in the store in 9 weeks and got great reviews for its design, although predictably it's not a big income producer as the market segment isn't really that great to be in. Now imagine doing this with a 2 week sprint schedule in Scrum. We'd still be working on it today! If you know exactly what something is supposed to be and look like and function at the start of a sprint, then you can simply work on it. If you need to first try and prototype quickly several times a day until it you know that it's correct then the Scrum process doesn't work, other than glacially as you complete features that are useless.

Given that most of what we do is as dynamic (though not as crazy as that project was) I think that this switch is going to trash our reputation as being able to deliver quickly. Given all my "Lean" type experience I am not enthused at all about slowing down progress for the sake of conformity. Unless we find the most flexible scrum master of all time, this isn't going to be any fun at all.

I just love the original Agile Manifesto, as the ideal makes so much sense to me from my experience.

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

I will probably get an earful from folks but I don't think Scrum is a particularly agile process outside of the large team -- single project -- long schedule world. I know people who agree perfectly with me and those who think I am perfectly stupid. The joys of developing software: everyone has an opinion!