I have attended the Adobe KickStart Innovation Workshop, which is the latest Adobe attempt to increase innovation in the corporation. You see, having a pyramidal structure where the top instructs the bottom, stifles initiative and sucks the life out of people was not working for them anymore. In all likelihood the move was sparked by Adobe not being in the list of top 100 most innovative companies and they took that to heart.

That being said (in a mean spirited, ranty and spiteful way, of course) I really liked Mark Randall, the guy that introduced the concept. You see, he is a rather brilliant entrepreneur, almost hugely successful several times and certainly above most business people I know of, who uses the ideas of Lean startups to create companies that "change the world". He is also kind of funny, in that personally distant way that Americans often display, but still funny and smart. He is as far away from the classical corporate vision as he could be, as he advocated structures that self organize under the scrutiny, but lack of involvement of the management. In a sort of "If you build it, he will come" sort of way, he thinks that if you create a system that allows for everybody to win, then people will automatically use it, improve on it and make it work, without the need for suffocating oversight. And that is what the KickStart project entails.

There is a lot to say about this, including my ongoing efforts in it (the two day presentation was just the preparation for the actual work, which I must do for myself), but I will keep this to a minimum. It could be enough to say that I really liked the idea, even if I completely disliked the presentation video, with all the diversely ethnic people excited about the opportunity to rise from the dirt by the all enabling Adobe. In truth, I opened my big mouth again asked Mark why the video sucked so much and he said that it was made in a day with only the people that could come on short notice. So I guess the excited people were actually the excited ones.

Anyway, let me summarize the concept of KickStart. You go to this two day preparatory presentation with Mark Randal where he gives everybody a red box containing the blueprint for a business. He lists the six steps that one must take in order to get the blue box, which I guess is the symbol of success. One of the most important ideas that can be taken from this process is that you do not need to do any actual development of the idea in order to validate its success. You get the idea, you share it with people, ask for feedback of the people that would use and/or buy your product, improve the idea, prototype something fast, without anything in the background, and iterate through this until you have some sort of metric of success: is your idea good? Would people use it? Would they pay for it? After you have changed the idea to conform to the realities of business and the clients needs and after you have gained support behind the idea, only then you get to make the actual development. In other words: gather data as fast as you can on the interest people have in your idea before you actually get to work. It's based on science: gather data, make a hypothesis, test the hypothesis, iterate.

Now, what does KickStart mean in the context of the corporation? It means they give you 1000$ (on a card that is valid only for the duration of the workshop - one and a half months) that you can use to further your business (like buying a domain and hosting, advertising, research, etc) and they want you to do the work that validates the idea. The sixth step is convincing the Adobe executives that your idea is good and not only that, but in sync with Adobe's strategy and values. What strategy and values, you ask? I could not answer that, neither could Mark Randall. The example business plan that won the blue box in another workshop was some kind of online challenge based on photos that where connected by their GPS location. And even if this really aligns with the Photoshop+mobile+creativity Adobe thematic, he still got to change the idea until it became something more marketable. You also have to fight out of the blue concepts like "Adobe doesn't do hardware" or "Adobe doesn't do games". Who comes up with these? Executives. They don't have an anti-porn charter, but they assume it's common sense not to pitch your newest Creative Sexuality idea.

And here is the kicker (pun intended): if your idea does not pass, you have gained invaluable knowledge as an innovator and a possible entrepreneur. If your idea does pass, you gain more support to expand on it, under the corporation protective umbrella (insert Resident Evil jibe here). In fact, if you are hugely successful, the business belongs to Adobe, not to you. It only makes sense, since they supported you from the beginning. And if it works, who else to run it and earn the big bucks but you? so I don't see it as a big problem, but you have to be aware of it.

Last but not least is the question: Who the hell is Mark Randall? He is the guy that in the 90's could have revolutionized the video and photo industries with little gadgets that they did with heart and a lot of work. He and his best friend Paul worked their ass off for five years (and here I mean off! They lived in their offices, even if they had rented apartments to live in) until they reached from a garage shop the size of a company that was going to go public for 650 million $. I won't spoil the story that Mark himself tells during the initial presentation, but enough to say that the feeling and vibe of those days he is trying to kindle into others, to make them live the same wonder - if they chose to.

If I would have written an article two years ago (wait a minute, I did!) it would have been a cold enumeration of rules and my outsider opinion about it.

If I would have written an article about Scrum two months ago, it would have probably been an insider rant, explaining how just following the rules of Scrum leads to blind bureaucracy and to a lot of waste of time.

Well, now I am writing about Scrum as I understood it from a personal viewpoint, because I've had this epiphany: Scrum (or any other development process) is a personal process first and foremost. To use a metaphor, so that I can move it out of the way and talk shop, it is like driving a car on a straight road. You are the engine (strong and reliable, hopefully), the road is the development process and your speed is your development speed. It is so easy to do everything fast and furious, it's a straight road after all, but what if there is a fog? Then you would have to slow down, for danger that you wouldn't see a sudden obstacle.

To get real now, the fog is the lack of foreknowledge about what you are going to do. And I don't mean project vision, or strategic planning, I am talking about your personal schedule, of how well you know what you are going to do. Scrum is trying to achieve this by enforcing a time table (the sprints) and a schedule (the sprint planning) and a recurrent update mechanism (the daily meetings), but it is only the beginning. If you plan your sprint superficially, it is like adding fog to the road in front of you. If you (and I mean YOU!) do not update your schedule as you go, including documentation, estimated time, time spent and all useful metrics, you add fog to the road behind you. If you are surrounded by uncertainty, you cannot plan anything. You don't know where you are, where you are going and how fast you are going to get there.

After 6 months of badly implemented Scrum, I've experimented with using a simple text file to mark when I start a job and when I finish it and any breaks in between, updating the actual work time and estimated time in the Scrum tool. We are using a clearly defined specification document for each feature, including requirements, acceptance tests, implementation details, code reviews, definition of done, test plan, updated as we go. I've discovered that all this huge amount of information, instead of slowing me down, lifts the fog and allows me to push the pedal to the metal and go as fast as I can. I know when I am doing something, why, and who is doing everything else and why. At the end of the day I don't have to rack my brains to remember what I did, I just cut and paste the task names and times from my text file to an email and the Scrum master just goes over the list and we are free to talk about what really mattered in those tasks: new issues, dependencies, implementation details. The result is visibility of what we are doing and not less important, I get to go home early.

Of course, I am writing this enthusiastic post after a single day of well done and 6 months of poorly done, but I have a great feeling about this, something akin to fog being lifted from my eyes.

First of all, I seem to be the proverbial man who can't do it so he teaches it. I've not worked in a Scrum or XP environment, but I did read a few books about them and this is what I gathered. I beg of you to point out any mistruth or inconsistency. You might want to take a look at this previous post, more general post, on the matter of agile development.

Some key elements of all agile methods I've read about are:

• the code does not belong to any programmer, in other words anyone can change any piece of code in order to solve an issue
• the members of the team are interchangeable, so not a bunch of experts in different fields, but people that can do all things (and be easily replaced by people just as agile as them :) )
• the members of the team must have similar competencies, one cannot do pair programming between a rookie and a senior, for example. That is called teaching :)
• the client is supposed to change their mind often and unpredictably, one plans for the unplannable
• the client must be represented in the agile team, so as to not have delays or misunderstandings in requirements

Scrum

The Scrum system does seem to be more of a disciplined way of developing than a method in itself. There are Scrum principles that must be upholded, but if you ignore them, the whole system looks like this:

• All development is done in fixed time increments called Sprints. Scrum specifies 15 or 30 days, although I bet most dev companies actually plan this on a calendaristic month.
• At the start of each Sprint a meeting of 8 hours takes place (so the first day) in which half of it is to present the requests by the Product Owner (in our case that would be either the client or the person that did the analysis) and the other half to plan which of the tasks in the Project BackLog (requirements list) can be done in the current Sprint. This last part if the responsability of the Team (that would be the developers and their team leaders and managers).
• In the last day of the Sprint two meetings will be held: a 4 hour meeting that will allow the Team to present what was done in the current Sprint to the Product Owner (this would be an informal meeting that "is intended to bring people together and help them collaboratively determined what the Team should do next") and a 3 hour meeting in which the ScrumMaster (the person in charge with the implementation of Scrum in the project) "encourages the Team to revise, within the Scrum process framework and practices, its development process to make it more effective and enjoyable for the next Sprint"
• The development is one in the rest of 28 days
• Each day there is a 15 minute Scrum Meeting held within the Team in which "each Team member answers three questions: What have you done on this project since the last Daily Scrum meeting? What do you plan on doing on this project between now and the next Daily Scrum meeting? What impediments stand in the way of you meeting your commitments to this Sprint and this project? The purpose of the meeting is to synchronize the work of all Team members daily and to schedule any meetings that the Team needs to forward its progress".

What is important about these Sprints is that at the end of each sprint the product should be fully implemented, tested and ready for production. At each increment the client could just take the product and leave. Any changes to the specifications must be included in the backlog and prioritised so that the developers apply them in the next Sprints. Once a Sprint is planned, there are no changes to it.

So, as far as I understand, this is a method of making rigid planning for very small periods of time, then executing it, effectively reducing each project to a bunch of smaller ones. Instead of "Make me a business management application" there will be projects like "Make me a member management interface", then "Add activities management" and so on. It reminds me of the time when I wanted to learn in college and I would divide the number of pages I had to understand and memorize to the number of days remaining till the exam.

I don't consider Scrum a very innovative way of development, although back in 1986 it probably was, but that's also good. One can easily adapt some of these ideas to their own system of development. By allowing the developer to build a finite number of things in a predetermined time, they can select a time to test the application in which they are certain no more requests will delay that process. Of course, I don't know what happends if the client changes their mind about a thing that is supposed to be done in a Sprint. Do we abandon the task in the current Sprint and plan it modified in the next? Do we build it as if nothing happened, then start making the changes or, worse, remove it?

XP (Extreme Programming)

The Extreme Programming development method seems to have the same roots as Scrum does. The idea is to develop in successive iterations that encapsulate planning, testing, development and refactoring. The "12 principles" of XP are again and again mentioned in the book, but I think that's crap. The most important ideas in XP, to me at least, seem to be :

• User stories as requirements gathering; Most important! a detailed story of what the user will do and why, like a narrative, the Word version of an UML flow diagram, which is the responsability of the client! The actual developing is the implementation in code of those stories
• iterations, which in the case of XP don't have a specific time length, each one is planned depending on what there is to do and what can be done
• the separation of user and client, the user is the one that actually uses the program, while the client... well, you know
• user-on-site, you can always ask the user what they think and receive quick feedback
• Test driven development, which, together with pair programming, seem the only actual extreme parts of XP, where they insist on tests first, programming later.
• Spikes: small bursts of programming for no other reason than to research an idea. Developers don't have to be rigurous in spike programming, since they only do the bit of code, test its functionality, then throw it away, the idea being that they learn how to do the actual code they wanted to do and what problems they might be facing. In this particular case, the spike is part of the planning or designing of a piece of code.

I will mention here Pair Programming as well, although I clearly don't see it happening. The idea is that two programmers sit on the same machine, one programs, while the other does just-in-time code review and thinks of the large implications of the code. While the concept is sound and I seldom find myself wanting to be able to code and also think in a larger context, I don't see how this can be done anymore than a master painter could get help from a second one that watches from afar and keeps nagging him on how to do things. Besides, sitting near a code that is being written sounds both boring and terribly frustrating.

But then again, I always like talking to other programmers that are as passionate as I am, so maybe a hands-on discussion, even an argument, might provide the drive to good code. Besides, it is harder to waste time on news sites and online games when you have some guy next to you :)

Conclusion

My conclusion is that agile is a solution to the problems that arose during the Waterfall days. It is not a solution to all problems and it certainly presents some level of difficulty in implementation.

I believe it would be hard to do in a small team with high turnover. One needs a stable team that works well together and has a decent management to implement agile development. But I do see it as a positive thing, as it puts the needs of the customer first and, no matter how good a coder you are, your primary goal is to satisfy the client.

• I have started with a book recommended by many sites about software architecture and design as a must read: Smalltalk Best Practice Patterns by Kent Beck. It is well written and I can see why it attracted a lot of people, even if there aren't so many Smalltalk programmers out there: it is written for use! That means that the book has less than 200 pages, but each of the specific patterns there are laden with references to others in the book, some even in the next chapters. That's because the book itself is structured to be kept nearby and consulted whenever a new project is started or in progress, not something that you read and forget in a bookshelf, gathering dust.
  
  However, the patterns presented are sometimes useless for a C# programmer, some being already integrated in language and some being not applicable. The fact that Smalltalk works with Messages further complicates things. I did eventually open a link to #-Smalltalk, but who will ever have time for it?
  
  I have decided that rather than reading this book and forgetting or not getting many of the things inside, it would be more efficient searching for a similar book that is more C# oriented.
  
  So, bottom line: great approach, both literary and technical, but a little hard to use for one such as me. Anyone know of a C# Best Practice Patterns book?
• My next attempt was in the wonderful world of management! Yes, I was approached by their people, apparently they want me to join them and rule the galaxy. Maybe if they wrote more concise books!!
  
  
  The Knowledge Management Toolkit: Practical Techniques for Building a Knowledge Management System starts interestingly enough, describing the need of every company to build a way to retain knowledge against employee turnover or plain forgetfulness. Basically what I am doing with this blog. But it goes further than that, quantifying the return on investment for such a KM system, describing ways of rewarding people and encouraging them to use it (it is not something done automatically).
  
  All great, but then it kept going on telling me how the book is going to change my world, rock my boat, help me in my business... after reading the preface, the introduction, the "how it's structured", the marketing bullshit, the first chapter (full of promises about the next chapters) I was completely bored! If there is any technical description of what to do, when to do it, how to do it, why , etc, I didn't find a trace of it in the first chapter. Reading on my PDA from a badly scanned txt file didn't help either.
  
  Besides, I got more and more frustrated. I barely have the time to scratch all I planned on doing in this holiday (while getting nagged on by the wife, the cat and whatever friends I got left) and improving the company workings is not my responsibility. I am the god damn coder! I write code! I have a management system all of my own and I get my ROI by googling a frustrating bug and discovering I solved it a month ago myself and wrote about it here.
  
  So there! If you have a business it is good to have a repository of actual knowledge (a.k.a. processed information) and encourage people to use it so that they don't take all their experience with them when they leave your sorry cheap ass company! I've summarised the entire book for you! I am not reading it anymore. It hurts my sensitive techie soul!