Wednesday, November 05, 2008

Agile Success Story: interview on how Agile movement helps company to grow and succeed

Picture courtesy of M. Keefe@flickr
Last week I had a great fun and honour to interview Janusz Gorycki who is a partner and a team manager in an Agile Software Development company - Spartez. Janusz is also the author of the open-source screen capture and painting utility for Windows named Mazio.

In this interview I'm asking Janusz about how they founded their company and how agile movement helped them achieve success. I'm also asking how they see their agility, what problems they have and how they deal with them. Janusz also answers why you can be CMMI-compliant using agile methodologies and recommends steps by which you can start applying Agile practices in your company.

Is this interview about yet another agile company? Not really - Spartez is an extraordinary company composed of ordinary engineers who were not afraid of making their dreams come true. Their determination, team work, a bit of luck and an extreme agile spirit helped them be and work together and become successful. This is a real-life example how cross-functional team, where each member is an expert in some areas, is able to deliver any software to any customer. And how do I know this? I used to be a part of this team at Intel and know this team as well as each member pretty well, however I'm not affiliated with them anymore in any way.

If you are interested in getting to know how they started, what and how they do now, this article is for you. Maybe you will follow their dreams and ideas - I think it's worth.

List of questions:


  1. As far as I know you worked together as a team at Intel which is huge corporation. I also know that you were not using Agile from the beginning. So, how did this all start?

  2. What are you working on now and how Agile methodology helps you?

  3. What Agile techniques you use (Scrum, XP, etc.)? What principles and activities you utilize and which one you abandon? Why? Don't they work for you or you consider them obsolete/unnecessary/unimportant?

  4. What tools do you use? Can you be Agile without them? What do you gain/lose using tools?

  5. Do you want to tell our readers something more about your development process? What makes you successful, what would you like to recommend trying?

  6. What are, in your opinion, three most important things that make Agile methodologies successful?

  7. What are three most important problems you encounter with Agile techniques? I won't believe it's always cool and problemless. How do you cope with them?

  8. You are familiar with CMMI as well and worked in huge corporations. Can you accommodate CMMI and Agile?

  9. Was it good decision to start thinking Agile? What did you gain as people, engineers and team?

  10. How would you encourage other companies and teams to start investing their time in Agile methodologies?

Przemysław Bielicki: As far as I know you worked together as a team at Intel which is huge corporation. I also know that you were not using Agile from the beginning. So, how did this all start?


Janusz Gorycki (Spartez): Yes, we have started our work together as a team at Intel's IT. The team consisted mostly of Intel newcomers and I was a long-time Intel employee (more than 10 years in one company, but in a different division), so I got appointed as their manager. Very soon after the team was formed, it became apparent that traditional software development methods, which I was used to while working at my former team, and which more-less worked acceptably well there, were hopelessly inefficient, unpredictable and very costly when applied to the internal IT environment. It was not uncommon for a software project at that organization to be more than a year late, and during that time deliver hardly any business value at all.

So we have started, at first in the "stealth mode" (without telling any higher-ups), to look for more efficient alternatives. Agile methods were, at least partially, known to some members of the team, so we decided to try them out. The productivity boost just from time-boxing our development and defining exactly what we will work on during each iteration was immediate and obvious. And as far as I remember, we have initially decided on a three-month iteration cycle - unbelievably long by normal agile standards. Encouraged by this success, we tried more and more practices.

But the real, no holds barred, use of agile methods, started after we all left Intel and created our own company - Spartez. We basically established the company as a place with agile spirit from the very beginning.

Back to list of questions

PB: What are you working on now and how Agile methodology helps you?


JG: We were able to launch Spartez, because we have managed to find a strategic partner - a company from Sydney, called Atlassian - the makers of excellent software such as JIRA and Confluence. Most of the software we develop is written for them and we are also resellers of their products. The main software product we are working on, and actually 100% own its development, is an open-source IDE Connector, integrating Atlassian web-based software into IDEs such as IntelliJ IDEA and Eclipse.

The development of this tool is done as a series of 2-week-long Scrum sprints, with almost each sprint's results actually released publicly, with downloadable and installable binaries. Each sprint delivers an increment of value to users of the Connector. I don't think we would be able to successfully launch Spartez and remain in operation for a year, without any initial funding whatsoever, were it not for agile methods - Atlassian folks were astonished that we were actually able to release a usable piece of software after just two weeks of work. Obviously, compared to where we are now, the functionality of the release was extremely limited and primitive, but the point was - we were able to prove to our customers from the very beginning that their investment was justified, because we are able to deliver on our promises.

Back to list of questions

PB: What Agile techniques you use (Scrum, XP, etc.)? What principles and activities you utilize and which one you abandon? Why? Don't they work for you or you consider them obsolete/unnecessary/unimportant?


JG: Sometimes we do get tired of this or that practice, becuase the downside of these practices is that they require quite a lot of discipline. The funny thing is, we get in trouble each and every time we abandon or do too little of some practice.

An example: we have agreed to release (internally) the new version of the software every second Thursday, dogfood it for a bit and launch a public version the next Monday morning. It so happened a couple of times, that we told ourselves "let's not release on Thursday because we need to finish this or that story". That proved to be a mistake every time we did this. By breaking the release cycle, we were forced to shorten a subsequent iteration and not only we delivered less functionality the next time around, but we broke our velocity measurement and lost control over one of the most vital metrics we had at our disposal.


Another example - unfortunately we don't unit test enough. Sometimes unit testing some functionality is prohibitively difficult when you write a plugin for some other software (like IDE), because there is no way to properly mock or stub some piece of code that you depend on. Well, we could probably try to mock them, but we decided that we would not, as we would have to rewrite half of the IDE. This has immediate negative consequence on the quality of the code. There is no doubt that the pieces of code that are unit tested (because they are not tied to the IDE), are of much better quality and easier to extend and maintain, than the pieces of code that are not unit tested. We are aware of this problem and we are long overdue addressing it adequately.

I can honestly say that all of the agile practices are important and they represent a coherent system. Abandoning some XP or Scrum practice may sometimes be necessary due to unforeseen circumstances, but I would recommend sticking to them as much as possible. Therefore I will not try to list the ones that are of more or less use.

Back to list of questions

PB: What tools do you use? Can you be Agile without them? What do you gain/lose using tools?


JG: This is the beauty of it - you don't really need sophisticated tools to successfully do agile development. At Intel, we have started with a cork board, sticky notes, scissors and pencil. And it turns out, these remain to be our most important tools to this day. This, a version control system (I would recommend SVN in most cases), a bug tracker and a continuous integration server are the only crucial tools you will need.

You should use other software tools only after you know which aspect of the agile software development you want to optimize in your particular situation. We are in a very lucky situation, where Atlassian has supplied us with an excellent software tools that nicely compliment each other. We use JIRA bug tracker for planning, tracking and bug reporting, Bamboo build server for continuous integration, Confluence Wiki for knowledge sharing, and Crucible for source code reviews.

Other tools? I would recommend getting the largest LCD screen you can buy (and they are dirt-cheap these days), computer with enough juice in its CPU to not frustrate you, plenty of RAM and a comfortable chair.

Some folks also like IDEs - like the IntelliJ IDEA that we happen to use. And I would agree that they do help, but I am tempted to also say that they sometimes help you too much - and instead of spending your time thinking about your design - you Control-space through your code, often times making it overly bloated and unnecessarily spaghetti-like. I sort of long for the days when you were limited to just bash and emacs (vi users - I am sorry, your way is wrong, but you will see the light some day). Not because I am a ludditte, but because in the absence of the powerful IDE, you have to stretch your mind more to make the code simple, elegant and concise.

Back to list of questions

PB: Do you want to tell our readers something more about your development process? What makes you successful, what would you like to recommend trying?


JG: Before I try to describe what we do, it is important to understand that these days, the eight of us work on at least four different projects. This means that some teams are actually one-person teams. And such small teams actually do not need any formal process - after all, the only reason for the existence of a process is communication - and if you are alone in what you do, you don't need much communicating. Except of course with your customers.

For the bigger projects, we start with a release planning session, during which we size all user stories that we have been able to gather from the customer. The stories are already prioritized by the product owner in some way - unfortunately sometimes only roughly. We play planning poker for each story and after the session we enter the results into JIRA.

After that, every two weeks (on Monday) comes an iteration planning session. During this session we commit to a subset of stories, trying to pick the ones from the top of the backlog, but sometimes for architectural or other reasons we also pick stories form the middle. Obviously, we also have bugs - and they tend to be quite hard to properly size, so in their case there is a lot of guessing involved sometimes. So what we do is try to have at least a 50-50 distribution of bugs and user stories for every iteration.

Then, every day we do daily stand-up - 10am sharp. We try hard to make it no longer than 15 minutes, but sometimes we fail (and this is all my fault as I lead these meetings).

Sprint demos are quite problematic in our case - our customer is in Australia and it is not realistic to actually do live presentation. What happens instead is we try to educate our product owner (who is in Sydney) what we delivered - he just looks into JIRA and he can monitor what's going on. He would then do demos for the end users (who are at this moment mostly developers in the Sydney office).

How we do actual development? That sort of depends on the task at hand. Sometimes we pair-program. Actually we should do much more of it than we do now, but this is a pretty intensive activity and therefore not everybody naturally chooses it. We have a Bamboo continuous integration server checking our code, so all of our commits get sanity checks, the code is always compilable and unit tested. For the more problematic, tricky and complicated code we do code reviews - using the Crucible tool. We do try to "dogfood" our own product as much as possible - if the required functionality is available (even if it has bugs), we try to do as much interactions with the tools using the IDE Connector that we are developing. That way, we know if we like the UI that we have just created and we are able to detect bugs before they hit the customer.

Would I recommend our ways to everybody? The elements of it - yes, all of them. The whole process? Not necessarily. In reality, you should use a process and methods that suits your team. Ours attempts to be optimal for us. It will probably not be optimal for you.

Back to list of questions

PB: What are, in your opinion, three most important things that make Agile methodologies successful?


JG: Let's tweak this question and answer this one: "Why are agile methods better than non-agile ones?" Let's try to answer that question. I would begin by this observation: software development is a chaotic process. By "chaotic" I mean "the one where slight modification of input parameters causes huge changes to the results" (I guess I could give a lot of examples here, but I don't want to make this interview even longer than it is now). The only way to control a chaotic process that we know of is by using empirical methods. Agile development give you means for empirical process control. You get your process checkpoints every day, every two weeks, every release. You can actually measure (as opposed to just guessing) how effective you are and what your real (as opposed to perceived) pace is. There is no "perpetual 80% done" syndrome in agile development. You can actually tell how much you have done so far and be certain that you are "done" working on something.

Second, agile software development give your customers better control over how they spend their money. They get results fast, they can check at any moment the health of the project they invested in, and they can stop the project at any moment when they determine that the investment does no longer brings expected results. Usually, 20% of the features give your customer 80% of satisfaction. With agile methods, you can deliver these 20% in 20% time, instead of being 2 years too late.

Third, agile methods give your team frequent and regular small successes - you release your software every second week or so, somebody is using it, giving you feedback, and the feedback is very likely to be positive, as you are building the software to exact specs of the ones you are working for. This builds confidence, enthusiasm and sense of working on something useful.

Back to list of questions

PB: What are three most important problems you encounter with Agile techniques? I won't believe it's always cool and problemless. How do you cope with them?



JG: The problem with agile methods is that they require much more discipline than "traditional" ones. The simplicity of the process definitions and "obviousness" of the practices is very deceptive. Agile methods require you to keep your pace day in and day out. There is no "quiet period" after a "death march". At first that may be problematic to some people. You will have to be effective as a developer, and your effectiveness is easily verifiable, every day of the year. The good news is that once you get accustomed to the routine, it becomes natural. Moreover, once you prove to yourself that you are able to deliver at an acceptable pace, your confidence improves. The question is - what if you _are not_ able to deliver at an acceptable pace? Well - XP has built-in mechanism for improving skills of team members, the best of which is without a doubt pair programming. But you have to be aware of the skills of everybody and react to people's deficiencies as you discover them. This is not always a pleasant exercise.

More dangerous than the first threat is lack of feedback from your users. This will surely cause you to get derailed, as user feedback is of paramount importance. Agile team has to do everything that is in their powers to get feedback. This is not only the responsibility of the ScrumMaster and the product owner - everybody on the team has to be aware that the feedback loop has to be maintained and supported by all means possible.

Third threat is lack of flexibility. Agile processes are meant to be improved. You are supposed to tweak, modify and fix them to your liking and to the precise needs of your team and its customers. There are sets of "best known methods" in Scrum or XP, but they are just that - "best known methods" and not a bible. It is important to understand that there are no "sacred cows". The process itself must not become a holy grail - it is just a means to achieve a goal and nothing more than that. If it makes sense to break the rules that you learned at your ScrumMaster training, go ahead and break them. Just be aware that you are breaking them and that you are doing it for a reason.

Back to list of questions

PB: You are familiar with CMMI as well and worked in huge corporations. Can you accommodate CMMI and Agile?



JG: I have somewhat mixed opinion about CMMI. On the one hand, the principles of CMMI are actually great - the central goal of striving for ordered, dynamic process, that has built-in mechanisms for self-improvement is something that I like, and which is also exactly what the agile methods are all about. On the the other hand, I am yet to see an implementation of CMMI that is not hopelessly heavyweight, overly complicated and and that is not making your life as developer miserable.

I suppose the reason for this is two-fold:

First, the only successful processes are ones that are built bottom-up, as a response of actual, painful needs development teams, designed and tailored by the teams themselves and modifiable by the actual users, without having to go through the huge bureaucratic hassles. CMMI however, is unfortunately usually introduced from top down, at the request of the higher management - more often than not quite isolated from, and unaware of, the gory details of day to day development work.

Second, the successful process has to be simple, intuitive and so natural that you would naturally resort to it when working under stress. Unfortunately, all CMMI implementations I have seen so far are heavy, complicated and impossible to fit in the head of a mere human. So what people tend to do is work around the complicated process in many cases, giving the false impression that they follow it, while in reality their real process is quite different from the "CMMI-defined" one. I have seen this evolution from "let's follow our CMMI process to the letter" to "let's pretend to follow it and get stuff done somehow, because our defined process does not actually work" happen a lot.

Having said that - I think agile methods can be basis of a complete CMMI implementation (up to level 5, no less). Just notice that some of the core agile principles are precise, empirical measurements (story size estimations, velocity), formal contracts between stakeholders (prioritized backlog) as well as built-in self-healing and self-improvement of the process (Scrum demos, retrospectives, daily stand-ups, pair programming).

Back to list of questions

PB: Was it good decision to start thinking Agile? What did you gain as people, engineers and team?


JG: I think it was the best decision that we as a team have ever made. The decision actually started us as an independent, and so far quite successful company - something that many of us dreamed of but before we met, had no guts to actually decide to do. Agile methods gave us discipline, they allowed us to easily share knowledge, improve ourselves, understand what we are capable of and what are our realistic and objectively measurable abilities. This is not to say that we are perfect - far from it, the team seems to be in a constant state of internal turmoil - and I think this is a good thing. But we seem to be, as a team and as a company, in control of our lives and we are able to "make our own luck" in stead of totally depending on the decision of others.

Back to list of questions

PB: How would you encourage other companies and teams to start investing their time in Agile methodologies?


JG: I would advise to start small. Don't make a "big bang jump" to an all-agile software shop. For example, it took us about three years of incremental improvements to get to where we are now, and we are still very far from perfect. Stay cool, stay calm, have guts and courage to try new things, pick and choose whatever seems to make natural sense.

Also - do not try to spend most of your money on fancy tools. Like I said - at first, paper, pencil and cork board will be all you need. After you understand what it is that you need, you will know what fancy tools to buy. And I hope you will turn to us to sell them to you, because we sell good stuff.

Back to list of questions

PB: Thank you very much for your time


Few facts about Spartez


Website: spartez.com
Location: Gdańsk, Poland
Operational range: global (currently working with customers in Australia, USA and Europe)
Areas of development: IT systems integration (B2B, SOA, middleware), aeronautics and GIS, telecommunication, low-level and embedded systems in the following technologies Java, C# (.NET), C++, C, assembler

Originally published on AgileSoftwareDevelopment.com

No comments: