Silver Stripe Software is a startup based in Chennai, India. They specialize in agile project management tools that ease the pain in making software deliveries. They believe that project management is as much about communication and social aspects as it is about numbers and metrics. Hence, their goal is to make software delivery a little less hard with elegant solutions to difficult problems.

I decided to break down the interview questions into a series of posts to make for better reading. Here is the first part.

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.

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.

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.

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.

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.

I’ll be posting the next few questions shortly or you can LISTEN TO THE AUDIO of the full interview right now.

We have a term for this in agile project management. It’s called “Truck Factor.” The name comes from the fact that when knowledge is localised, then any unexpected event–like a person getting hit by a truck–could jeopardise the project.

A Truck Factor of 1 is the worst. It means that there is some part of the system that is understood by only a single person. A Truck Factor of 2 means that at least two people understand every part of the system, and so on.

Here is how to calculate the Truck Factor for your project:

1. Go through each class, file or component
2. Calculate the number of people in the team who understand that part of the system
3. This gives you the Truck Factor for that class or component
4. The smallest of all the component truck factors is the Truck Factor for the project

Hence having a product roadmap even when following an Agile approach is a must. A
product roadmap is a planned approach that helps with strategic project planning and communication of that plan with respect to product releases, functionality listing etc. But it should be formulated by first understanding the target users, the market, and the underlying technologies. Product roadmap forms an integral part of any product strategy and provide the framework for plan changes and the impact they would have on the product. It’s not just about the specific features or functionality of the product, but the long term product vision/goal of how far one would go with it.

The general perception today is that in Agile, unlike the waterfall model, it is difficult to chart out and manage an effective long –term product roadmap. However, Agile reflects the reality better because the planning is done only for the current items and the immediate iterations that may follow. And this necessarily avoids one from making a long-term product goal (say 6-10 months ahead), which may fail because priorities/requirements of the products often change. Moreover, making a long range roadmap has always been a real challenge in general.

In Agile, the roadmap and approximate dates are calculated based on the product backlog and the knowledge of the team velocity. Many a time over-commitment to the customers has been a major issue here. But product managers can certainly employ a centralized system that would ascertain development team velocity, all previously committed requests, and based on that, calculates the next available commit date for a task of importance. This always keeps one in check. A good agile product roadmap should invariably help one deliver the right products with the right features at the right time to the right customers.

Read the entire digest contents

Many in the enterprise software community assume that Agile techniques are targeted only at small, co-located teams of about ten people. This assumption makes sense to a certain extent as time zone differences, language barriers, cultural differences, and lack of synchronization of development processes make implementation of Agile techniques in offshore teams a great challenge. However, these challenges can be overcome by reinforcing the following practices:

Rapid and Frequent Communication : One of the most important principles of Agile is active and regular communication between all teams involved in getting the software to market. So, if there is one or more offshore teams involved, a daily status update informing the other teams of the day’s progress (what they did that day, what they are the planning to do the next day and the problems faced) can be done by making some adjustments for the time zone difference. Instead of the entire team attending the stand-up meetings, every team can have a local stand-up meeting and the team lead alone can convey it to the other team(s). Weekly status meeting with the entire team and face-to-face meetings whenever possible (so you need to budget for that) should also be given priority. All this will ensure that team members are on the same plane and project is progressing as desired. Besides teleconferencing, other collaborative communication methods should also be considered and made use of as appropriate, including video conferencing, wikis, instant messaging, VoIP solutions etc.

Automated Builds and Continuous Integration: The practice of automating builds at regular intervals is advised as several teams develop simultaneously and since the team members are geographically distributed, it becomes a massive task to ensure that each change is integrated into the build. So, if there is continuous integration, any integration issues can be sorted out immediately rather than solving huge issues at the end. An effective integration should include practices like compiling, database integration, unit testing, deployment, functional testing, notifications, and reporting.

Short Iterations: Product requirements keep changing due to a better understanding of what the market really needs. Hence, short iterations that last from one week to four weeks, with working software at the end of each iteration, is advisable. In the case of distributed teams working on different functional areas, having a demo at the end of the iteration will help clarify whether offshore teams have really understood the requirements communicated to them, instead of waiting for months to see the end results.

Efficient Team Organization: Getting the entire team together at the beginning of the project results in everyone getting to interact with the other team members and can result in better camaraderie and collaboration. Project managers should involve distributed team members to discuss release dates, associated costs, and risks involved in the project. Team members at different locations sharing the responsibility of different functional areas (instead of owning different phases of the project) and modules, and collective code ownership can foster a strong sense of pride and ownership among the whole team. Cross functional teams and Scrum masters present at all major team locations also helps to a great extent.

Read the entire digest contents

As Agile teams manage their work differently, they typically need a different set of tools to support their agile approaches. Simple and adhoc tools like index cards and spreadsheets for requirements management and prioritization, wikis for collaborative documentation, commercial or opensource project management and bug tracking tools are usually sufficient for small, co-located teams. However, when teams and projects get larger and Agile methods need to be scaled up, integrated tools become useful.

New agile project and product management tools enable better coordination and collaboration between the various teams involved in the agile process (development, customer support, marketing, management, customers, etc) and also provide better reporting capabilities. Some of these tools even include requirements management, test and defect management and integration with development, test and build environments. They can bring about further improvement and acceleration of existing agile processes.

X-planner, RallyDev, VersionOne, TargetProcess, Yoxel and Mingle are some available Agile project management tools. .NET shops can also consider using MS team SCRUM plug-in for its agile project management functionalities. Some of these tools require you to spend time learning to use it initially while others allow easy integration with existing tools. Finding and using the tools that are well-integrated, facilitate meaningful interaction between your different teams and give more visibility can ultimately help you produce better software faster.

Read the entire digest contents

When Agile first started making an appearance, it was viewed as yet another development fad. But with Agile showing dramatic improvements in delivery time, quality of software and a reduced number of strategic mistakes compared to the waterfall model, it has taken a broader role in software development today. A number of companies practice Agile as a product development methodology from project inception to delivery, support and end-of-life phases.

However, Agile is not about using Scrum, Extreme Programming or RUP. It’s about using the best agile practices to respond to today’s frequently changing business needs. Using the waterfall model, frequent changes to software is difficult – the development cycle is long, systems are over engineered and end up costing a fortune.

Agile as an alternate development methodology evolved from the need for dynamic systems that can rapidly adapt to change. One basic tenet of Agile – simplicity – comes out of this need. Build the simplest possible system that satisfies today’s requirements and when tomorrow comes, be ready to adapt.

Agile is not fool-proof though. It is still evolving and there are some situations where it may not be applicable. The trick is to find out the right mix of techniques from Waterfall, Agile and other development methods that suit your particular product development needs, adapt those techniques and implement them!

Read the entire digest contents