Interview with Siddharth Govindaraj on Agile development tools, myths and best practices
Welcome to the Producteering Forum’s Podcast series. I’m Selina D’Souza, your host for today’s interview session. We have with us today Siddharta Govindaraj, founder of Silver Stripe Software, a start-up based in Chennai, India. Silver Stripe Software is the creator of Silver Catalyst, an agile project management tool for lean and nimble teams. Welcome Siddharth and how are you doing today?
Siddharta: Thank you. Good to be here.
Selina: Alright great, so let’s get started. There is a tendency among some of the folks who practice agile to interpret the “Individuals and Interactions over processes and tools” in the Agile Manifesto to mean that Agile software development does not require any defined set of processes. So what is your take on that?
Siddharta: This is a good question, because the Agile Manifesto actually says individuals over processes – so why are we all talking about agile processes? There are two parts to this question – one is about processes and another is about defined processes. Now, what agile says is when you have different projects running, they all run in different conditions.
You might have one project which is composed of a lot of senior people, you might have another project with a lot of junior people and a couple of senior people. Now what we say is that we can’t have the same process for both the teams because the team structure is different, so some practices that work for the senior teams will not work for the mixed team and so on and so forth. So while they will follow some practices, they might follow different set of practices. Now that’s a process, but then it’s not a centralized defined process done by someone sitting in an ivory tower who then enforces it among all the projects in the company…that’s something which people are genuinely against.
Now, what we say is have a process – but have a process which is suitable for your condition. And that’s where agile comes into the picture because there are numbers of practices within agile. If you look at Scrum, there is a retrospective which encourages teams to take their own process decisions to introspect about what they feel and decide if they want to things differently. And that’s all under the idea of evolving the process to suit your own conditions.
Selina: Right. So you have to see and adapt accordingly.
Siddharta: Inspect and adapt – that’s the core word here. So while you may follow a process – it’s not a centrally defined, enforced process among all the projects – that’s bad.
Selina: Let’s move on to how the tool market is doing. The agile tool market has well-known (enterprise market) players like Rally, VersionOne, TargetProcess and a host of other lean agile tools – so where does Silver Catalyst fit in, how does it compare and how do you hope to make an impact?
Siddharta: The strategy followed by Rally, VersionOne is slightly different from what we are doing. Rally and Version One are really targeting big enterprises who are transitioning to agile, so apart from the tool they provide a whole lot of other services, for example coaching, certification, training. So you can take a tool or company which is not agile and move them to agile, and the tool is just one component of it. So they are looking at companies that are transitioning to agile.
What we follow is targeting teams who are already following agile and the difference is – if you search the internet about what people think about these tools, you’ll find Rally, Version One etc are targeted a lot towards management because they are the guys who are pushing the adoption and change, so there is a need of reports. But the people that are actually using the tool are developers and testers. And a lot of them find it too complicated and too cumbersome to use. It’s not really suited from their line of thinking – what they need to do on a day to day basis.
So Silver Catalyst, because we are targeting teams who are already agile, we are really focusing on how we can make a tool that’s easier to use and better for the developer. We want to make a tool such that you can get your job done in 2-3 min and get on with your work. We don’t want you to spend half a day or one day just figuring out the tool and grappling with it. That’s just a waste of your time because you could be doing a lot of productive work on your project in that time. So that’s kind of different markets which we are targeting and different mindset with which we started when we developed Silver Catalyst.
Selina: That’s a very interesting take. But like I said there’s a lot of lean tools in the market, is there any key difference that Silver Catalyst brings to the table?
Siddharta: When it comes to lean tools, I disagree that Silver Catalyst is only a lean tool because it’s got lot of integrations with 3rd party software which many lean tools don’t have. And we have hosted as well as onsite versions. Again, many of the smaller, lean agile tools tend to be hosted only.
There is a difference when you talk about enterprises. One of the key factors which they look at is security of their data – they don’t want their data stored on a 3rd party server and so lot of these companies actually want onsite server versions which they can install and use. Enterprises also want integration with all their other tools, where as smaller companies may be ok – it can be pure project management. But an enterprise or the bigger company will want integration between the parties and between the tools that they use to provide an integrated workflow.
Selina: So that’s your key strength.
Siddharta: Yes, we have a server version as well as integration with third party tools that many of the smaller tools don’t have.
Selina: Great. Let’s move on. So agile has its own advantages and people who vouch for it. So does a completely different way of doing things – the CMM (Capability Maturity Model). What are the compelling reasons for a person who is practicing CMM processes to move to agile?
Siddharta: I’d say there’s only one compelling reason – and that is, if what you are doing currently is not working for you. If you’re following CMMI and it is working for you, that’s great, then there is really no need to change. You don’t have to change because it’s the in-thing. That’s something which I’m quite against.
But a lot of people do have problems when it comes to CMMI when requirements are unstable, because the way it is structured of having say, testing and user acceptance right at the end, which creates a lot of issues with respect to changing requirements or cases where you’ve not got the requirements exactly or there’s also the case where the customer sees a product and then gets lots of ideas on how it can be done.
So when you have a market like this, then you find that CMMI tends to cause issues because you get bugs right in the end, you get change requests right in the end. It can be difficult to cope with it. Whereas agile is perfectly suited for those kinds of project. You make frequent releases, there is a lot of feedback is involved, there is a lot of collaboration involved. So in these cases, agile is well suited for these kinds of projects. If you’re doing what you’re doing, and its working then fine, I’d say continue with it. But if it’s not working, then agile could be an alternative.
Selina: Right, but is it true that agile is more applicable for consumer kind of applications and products compared to enterprise-class systems?
Siddharta: No, I wouldn’t say it’s true. In fact it’s kind of interesting because where agile originated from – if you look at it – a lot of it is from enterprise applications. If you look at extreme programming, it developed out of a project at Chrysler. If you look at feature-driven development, it came out of a project in Singapore and so all these projects are enterprise projects. The history of agile is actually quite the opposite – it’s come out of an enterprise background, where if you look at it, in an enterprise setting – requirements can change often and things like that.
Now of course, if you really think about agile, it started a lot before Web 2.0 came into the scene. So that’s the background from which it has come and it just so happens, now that we talk about web 2.0, it turns out that agile its perfect for those kind of applications as well because you have releases going out very quickly. But I wouldn’t say that that’s the only type of project that it is suitable for because the history of agile is really coming out from the enterprise group. Even today if you look at it, most agile projects are Java oriented enterprise projects.
Selina: That’s a very interesting take. Can you outline some of the biggest challenges you see when people try to make the transition to Agile?
Siddharta: Yeah, there are so many. The number one is getting into a mindset and cultural change. You know, agile is not really about processes if you think about it. What agile promotes is a set of values and process is something which just comes out of a value and that’s why we have so many different processes that can all call themselves agile.
The values we are talking about is like, for example, collaboration between customer and developers and management and testers and so on, we are talking about self-management, about being adaptable. These kinds of values are quite the opposite of what traditional project managers have been used to. They are used to plan-driven projects, they are used to command & control hierarchies, they are used to contract negotiations with the customer. So coming out of this mindset and coming into the culture of agile – that’s the biggest stumbling block.
We see a lot of people who try to adopt agile without changing the values and it runs into some dysfunction or the other. For example, instead of having a self-organizing team, they do iterations but the manager tells everybody what to do. So they think they are doing agile but actually speaking I wouldn’t really call it agile. So you come across these kind of dysfunctions because the cultures as a mind-set change has not been done and that’s really the number one issue. Once you do the mind-set change then you can pick on any number of practices to do what ever you need to do but if you do practices without doing the mind-set change, you could be in some trouble.
Selina: Right, I totally agree. Initially, agile techniques were targeted only at small, co-located teams usually, but now larger teams that are geographically distributed have adopted agile. How has that change come about and does distributed agile really work?
Siddharta: Right, so agile always talks about co-located teams and even now most people agree that co-located teams are always going to be more productive than distributed teams. But there are a whole lot of other things which can decide to make you go in for a distributed team – for example availability of skill sets or strategic decisions by the company. There are many things which tell you, you need to go in for a distributed agile project. We’ve seen over time, distributed agile has been becoming bigger and bigger. In fact, there are a lot of things being distributed.
Jeff Sutherland, one of the scrum founders talked about teams in the US and Russia doing distributed agile and how productive they are. So there are a lot of people who are really succeeding in doing distributing agile. But the thing is to succeed in distributed agile – you need to make a few changes. Obviously, communication is not going to be as good as if everyone is co-located; similar bunch of practices which ensures that you try to maximize the amount of communication available, it might be a shorter iteration so that you can get further feedback.
You try to split groups not amongst teams – so you don’t want to have developers in one location and testers in another. But along functions or bits of functionality. So you might have developers and testers working on one part of the system in one location, and developers and testers working on another part of the system in another location. And you want to maximize the amount of communication bandwidth that you’re going to build through chat, voice messaging or through cameras and things like that. If you make these kinds of changes you can succeed. I know a number of companies, not just out of India, who are doing distributed agile and are successful.
Selina: Ok. So if you look at it, the nay-sayers of agile say that agile practices don’t give too much important to design, or the design aspects. But design is vital to a product’s long-term success. What do you have to say on this?
Siddharta: This is something that you hear very often – that agile teams don’t do design, there’s a similar thing that agile teams don’t do documentation. But these are kind of misconceptions. A lot of people understand agile to be coding without design, without documentation and equate it to adhoc development. And nothing could be further from the truth.
We need to make a slight distinction between not doing design and not doing Upfront design. So the term used in agile circles is Big Up-Front Design (BUFD). What agile does not do is to get all the details upfront and do a BUFD. So we don’t have a design phase like your typical but agile teams do do design.
As and when they keep incrementing features they revisit the design. And design is something that you look at throughout the project, it’s not technically something at the beginning alone. At the end of every iteration, it is re-evaluated; re-factoring is done constantly to improve the design. This is something which happens continuously. So agile does continuous design and evolving design, but they don’t do BUFD.
So it’s not to say that agile doesn’t do design, in fact it does it right through out the project development. Constant evaluation and redesign.
Selina: So how is design planned? In every sprint or whenever it’s required, you take a look at it?
Siddharta: Whenever someone is recommending a feature, they think about whether it fits in the existing design or not. If it doesn’t fit in, then assuming you are all co-located, you can take a few people and decide these are the kind of changes you need to make and then go ahead and implement them. So it happens on a day-to-day basis, week-to-week, sprint-to-sprint basis.
Selina: That’s interesting. You have over 6 years of experience working with agile practices, what are some of things that successful agile practitioners do in your opinion? Can you outline some best practices for us?
Siddharta: There’s a thing about best practices, like I said earlier about defined processes, I wouldn’t say that there are a series of best practices that everyone has to follow, but there are number of good practices which could be helpful for many teams.
If you look at it, obviously one of the most important ones is frequent releases and a lot of people think that the point of frequent releases is to get your product out into the market as soon as possible. While that could be one reason, the real reason for frequent releases is to get feedback from end-users – that may be the customer or the actual user or whoever it is.
So teams that keep releasing but don’t take any feedback – they are falling into one of the pitfalls of agile. So you have lot of teams doing iterations – they make something but they never release it. In the sense, they don’t show it to somebody who can give them feedback. So frequent releases is very important.
The second thing is communication. Agile depends a lot on communication. That could be communication between the customer and the team, communication within members of the team, it could be communication between managers and the team. All throughout, you have to have high band width for communication.
And along with communication, you need to have trust. Agile lies on the basis of trust, which is one of the values that I talked about. Trust is a very important value. So from a high level, I think communication, the ability to look back at what you are doing and adapt a process, and frequent releases are probably the three most important things that any team wants to do.
Infact, Alistair Cockburn, well-known Agile guru has got a list of seven properties and these 3 are the top three that any team really needs to do. And then he’s got a whole lot of other stuff like using good technical practices like unit testing, continuous integration and so on. You’ve got stuff like having customers or end-users look at the product frequently and things like that. But the top three has got to be communication, frequent releases and adapting the process – to retrospect and things like that.
Selina: To get back to your tool, Silver Catalyst – it is developed using the Python language. Why is that so? Any particular reason – are you an open-source advocate?
Siddharta: The reason for using Python is very simple. It’s a niche, it’s fun to code in and we been using Python for a long time. I’ve been using Python for projects since 2001. So there’s lots of familiarity with the language, and Python has got a great community. It’s got a fantastic set of my tools to do a whole lot of things. It’s well supported. I think it’s the best language I know of at the moment. I know a lot of people are talking about Ruby and Rails and other stuff, but in my opinion Python’s got to be the best.
Selina: Ok, so one last question before we wind up: is agile over-hyped?
Siddharta: Well, whenever something gets big, it tends to gets over hyped. So agile is following the same cycle. In the beginning, not many people knew about it, the only people who were doing agile were like die-hard agile enthusiasts. Then it starts to get mainstream. I think in the US and Europe it’s gone mainstream – its gone mainstream for a year/year and a half now. And when it goes mainstream, a lot of people jump on the bandwagon and lot of people want to do agile, thinking it’s like a miracle cure. If I do agile, all my problems will go away.
Selina: Right, without understanding whether it’s applicable or not to them.
Siddharta: Exactly. So lot of people go ahead, do agile. But then they do this half agile – or implement it without this cultural and mindset change. But they make half changes.
Really don’t do agile in the true sense of the word. I know a lot of people who claim they do agile, when I actually ask them what they are doing, I find out they are not doing agile at all. But it has become a kind of buzzword, lots of people are happy to say that they are doing agile.
But at the same time, this is just a phase, and after this phase people are going to stop talking about agile but there will be a lot of practices that agile has been advocating for. If you look at object oriented technologies, throughout the early 90s, lot of people said it’s the big solution to all our problems etc. It went through a hype cycle and today no one really talks about object oriented design and development a lot but everybody is doing it without talking about it. So, eventually agile is going to go down that path, where people are going to do unit testing, they are going to do continuous integration simply because they are good practices. In fact agile itself is constantly evolving. Even today there have been lots of evolutions of agile, versions of agile like Kanban which is coming into prominence, Lean has become important. So these kinds of evolutions will keep going on.
Selina: Ok so there’s lot of room for growth and sophistication as well.
Siddharta: Right absolutely.
Selina: Well, that’s a very, very interesting talk with you Siddharth and very insightful. So thanks for joining us today, and to everyone listening in, thanks for joining.
For more on software development best practices, issues and trends, please visit our Producteering forum http://producteering.org. Once again, thank you all.