Scrum vs Kanban

While having a twitter "discussion" on some of the differences between Scrum and Kanban with Alan Shalloway, he prompted me to an article he wrote about the subject. It's a very interesting post and I would encourage you to go read it now.

I like how he attributes a team's learning ability as a result of retrospective done throughout different projects. On a scrum project, this would happen once at the end of every iteration. Kanban, by Alan's thinking, do mini-retrospection every day while reviewing the Kanban board. Would many mini-retrospection be equivalent or better to a "prescribed" end-of-iteration retrospection? I don't know, but the thought is interesting. Obviously the team also gets key learning outside of retrospective but this is true regardless of process.

In the same section he describes scrum as a black box, with well-defined inputs and well-defines outputs (product backlog -> software built). Although he mentions that these words are not his but Ken Schwaber's, I don't agree with them. I hate the thought of any process to be described as a black box. It almost implies that the results are guaranteed when given a set of similar inputs. We all know that this isn't true in software development. In fact, that's why we look at empirical process in the first place instead of traditional prescribed methodologies. The input might be well defined as a product backlog, but the product backlog itself is not important, what's interesting is the stories it contains and the complexity behind them. Given a similar project with a different team, the product backlog might look completely different. Scrum is a black-box as much as any other process is a black-box, requirements-in -> resulting assets out. This usage of black-box in that context is not very interesting and obviously can't be used to differentiate methodologies.

In both Scrum and Kanban, they have a solution for one of the most frustrating aspect of our work: interruptions. There's ton of different types of interruptions (meeting, phone calls, company outings)but one that really is costly is switching tasks because of priorities. I don't know of a worst thing for a developer to put his solution on hold while he's switch to another "more important" task.

Scrum's approach is to lock an iteration down (normally 30 days) where you cannot changed anything that you planned to worked on (sprint backlog). If you do change something because of grave priority, then the scrum master may cancel the sprint entirely if the sprint goal is invalidated. This is normally an exception and not the rule.

Kanban's approach is more flexible, you cannot change the task that you are currently working on unless you haven't attained your limit, but you can certainly changed what's the priority for the tasks in your to do list. Iteration isn't a prescribed practice in Kanban.

In my mind one of the most important factor between Kanban and Scrum: Inclusion of Management. I actually agree that Kanban is better on the relationship between management and their team. Although I don't agree that Scrum stops management from providing "proper interference"(maybe an oxymoron?). Interference might not be allowed at the daily Scrum meetings, why waste everyone's time if only a few are concerned. There's no reason why a guiding discussion can't happen with the Scrum master on information that could help the team. Having said that, scrum does create a barrier between management and the members of the team that many managers would find uncomfortable (more on this later).

I disagree on the visibility being the main factor (it could certainly be a factor). One of the factors I attribute to Kanban being easier to accept by management would be "Controlled Change Management", which Alan says is the biggest difference between Scrum and Kanban. I think that this factor alone make it so much easier to get backing from middle management and above. I believe having buy-in from management is one of the most important aspects of adopting a process (agile or not) for a company.

If you do Scrum by the book, using the Chicken and Pig analogy, how many business do you think would be ready to accept it top-down? It takes so much control and power away from the management (even if it might be for the better good) and they are the ones that should make the decision to use Scrum. Or at least endorse it because the different teams believe it will help. Most of the time, Scrum is instead implemented bottom-up (it's easier to ask for forgiveness instead of permission), and then it's up to the Scrum master to act as a proxy between middle/high management and the team. Gantt charts over Product backlog, Scrum meetings where he urges some "chickens" to remain silent etc. Maybe eventually, the results will speak for itself and will break down the barrier for an adoption of Scrum throughout the organization, but that takes time. Managers that employs a "servant-leader" approach already know instinctively why a methodology like Scrum would work, but not everyone is so open-minded.

I've been with a company where one of a project really hit an impasse with one of our customer. We were in trouble, everyone was desperate. We called in some expert to put a process in place that would help us out with our problems. I wonder how many companies are in that state of mind when they accept Scrum? It's unfortunate, but I can see more companies accepting it because of desperation rather than wanting to change for the better. I think this is fast changing though.

So the ability to slowly adopt Kanban in your organization will certainly be easier to sell than the Scrum "in your face manager" attitude. Especially with managers reading books like "The inmates are running the asylum" :)

IPhone Programming, where to start---REBOOT

I've previously posted a where to start before. This is when I had just started doing IPhone programming and I think the list of books would still stand today as being great books to learn from to start programming on the IDevices. Beginning iPhone 3 Development: Exploring the iPhone SDK, Programming in Objective-C 2.0 (2nd Edition), Cocoa(R) Programming for Mac(R) OS X (3rd Edition) are all great starting points to get to programming quickly on the IPhone SDK.

Since then, I've added many other books to my repertoire. Some that I didn't even have time to read yet :) I've always been a fan of the gems type books. They list concrete and sometimes more difficult examples than the normal "learning" type books. To this list I added iPhone Games Projects, iPhone Cool Projects, iPhone Advanced Projects. They are all great books, some of them helped me to work better in cocos2D and others gave me some good optimizing tips.

I'm afraid though, that the most important book that most of us indie type programmer can buy isn't a programming book at all. Let's face it, programming is rather easy for most of us. I've been programming in games for years, and sure there's new things to learn when switching to a new platform and language. But it's most likely not unlike anything you did in the past. So what is this important void of knowledge we need to fill? If you are on the Appstore trying to get noticed, you probably already know : Marketing. I've never really given marketing too much thoughts before going on the Appstore. Even while developing for our Zombie Planet game, marketing is something I was going to do at the end, once it's in the Appstore. Wrong! We were happy enough at first, but our numbers dropped quickly enough. Since we got good reviews from the users who did try it, I think our marketing effort (or lack of) is at fault.

So to refresh my list, here's the most important book you can buy BEFORE starting to program your application: The Business of iPhone App Development: Making and Marketing Apps that Succeed. There's simply no better book out there right now on this subject. Although the book makes it very clear that marketing should start before your game, it promises to also help the poor souls who are already released in the Appstore. I haven't yet tried to apply any of these tips to our game yet. I've been busy with our new bundle of joy the past few months (a baby, not a toy or a game). I hope to do all of this soon though, as I'm working on releasing our first update to our game (way overdue now).

I absolutely enjoyed this book. Because I lack any formal training in this domain, I've learned so much from it, which is absolutely thrilling. Imagine my surprised when I actually saw code in there to help you along for things like in-app purchase and in-app email. I've always wondered how some games are able to give mojo or credits of some sort (We rule, imob) by downloading other applications. This book covers how to do this too; mystery solved. It also gives good tips on the benefit of free, when to use in-app advertising and how to properly use in-app purchase.

If there is one part I didn't like about this book, it's chapter 3: Protecting your intellectual property. If you find yourself in the same boat, just skip it. The main point you should take from this chapter is to do your research to make sure you don't use any existing trademarks. As indie developers, the rest probably won't apply to you unless you are very successful. If you are aren't indie, chances are you have your own marketing and legal department. In any case, this chapter didn't speak to me but maybe there is someone out there that will like it. The question is: if Mobigame had read this chapter, would they have changed anything about how they went forward with their great game Edge? Probably not.

Beside that chapter, the rest is pure gold. It answers a ton of questions and what it can't answer due to space limitation it provides in links to online resources. From affiliate programs to how to setup an ad-hoc distribution to social media integration, this book is full of useful tips!