The S Curve

Atlassian Chats It Up

Kudos to Atlassian for expanding the collaborative and social aspects of the Atlassian suite even further with HipChat. And congrats to the HipChat team for joining Atlassian! Chat is of course a critical aspect to collaboration along with wikis, activity streams, etc. zAgile recognized this as such a few years ago when we integrated the Jabber-based Openfire server into the zAgile Wikidsmart platform.

As always, you can count on zAgile as the Atlassian software vendor partner to contextually integrate Atlassian products. zAgile's Wikidsmart open source platform and applications deliver tight interoperability, traceability, and federated search of content (Requirements, Issues/Tasks, Tests, etc.) across the Atlassian environment, as well as with other tools (Jenkins, Selenium, etc.) and applications (Salesforce.com, etc.). 

And now HipChat's chat history content will be counted among those of course. In this way, HipChat conversations may be automatically tied (via key word/topic association) to issues in JIRA, requirements in Confluence, projects in JIRA, customers in Salesforce.com, etc. No longer will chats remain isolated but can be shared (to the extent desired) and associated with all aspects of the project. 

This means historical chats may be part of the contextual content served to users whenever they are doing something (like creating an issue in JIRA) or performing a search for something. For example, if they are performing a search for a specific Requirement, now they can also see the associated historical conversations along with the associated Tasks/Issues, associated Customers, etc.

The Wikidsmart platform is about teams gaining efficiency and managers gaining insight into the software engineering activities by contextually integrating content and information. Now Atlassian's HipChat's chat history will be amongst that important content to drive collaboration in an ever more contextual way.

@AndrewLampitt
zAgile

At the SAP Cloud Community Inside Track Event on Feb 16 in Palo Alto

I am excited to be speaking at this event on Feb 16.  Its an opportunity to share and explore what cloud technologies provide in support of running and management of large-scale, globally distributed software projects. 

Here is the abstract of my talk:

Cloud-based technologies can address a number of challenges involved in running and managing large-scale software projects using globally distributed teams.  They can facilitate consistency of tools used by distributed teams throughout the software development lifecycle, from product definition to delivery.  They can enable integration of heterogeneous tools, processes, participants and stakeholders across lifecycle phases, including customers and support.   They can provide full transparency of all activities.  And finally, they can leverage the elasticity of the cloud to support activity-bursts, such as those used with test automation and continuous build cycles.  This session focuses on zAgile's cloud-based collaboration platform for software devleopment, that brings distributed teams together, providing a cohesive and unified environment with full visibility and traceability to facilitate rapid application development cycles.

In software outsourcing -- time zones matter

Companies engaging in software outsourcing/offshoring, or that have distributed software engineering teams, tackle a variety of challenges related to the distributed aspects of their operation.  Through some combination of collaboration tools, technologies, processes, T&E $s, lots of late night conference calls, etc., they work towards managing through these challenges and experience varying degrees of success with their projects.  And they do that while striving to reduce overall engineering costs (the key objective for most of them). 

 

Of the challenges they face in coordinating software engineering projects across distributed environments (and there are many), I believe that time zone difference is the most significant. You can save money, find great talent and implement the most effective platform and process for collaboration and software development -- but not being able to reach people when you need to still makes a difference in the 'velocity' and effectiveness of your development/delivery lifecycle.

 

While this was not the key factor influencing our decision to establish teams in South America, we certainly have benefited tremendously from it.  With teams in Chile, Peru and Brazil, our teams (or individuals) have never been more than six time zones away.  This means that throughout the year, there is always a core window available for us to collaborate.  Of course, this does not mean that we are in constant hourly contact.  In fact, I spend an average of an hour a day on such communication.  It simply means that people are more accessible and therefore there are more opportunities for direct (or synchronous) communication, brainstorming, etc.

 

While most people address this issue through a lot of after hour calls as well as relying on local management teams, we have had to do neither.  Having to hire offshore management team to look over local operations obviously adds to the overall costs.  We have hired and managed individuals directly, maintained a flat team structure, regular work hours, and implemented a number of different agile techniques towards the development of our platform and solutions.  Given that we are implementing leading-edge technologies, the model has worked very effectively for us -- both in the development of our products but also during deployment with our first customer.

 

All this without compromising on the cost benefit or talent.  In our case, we have a significant edge on both fronts. 

 

So time zones matter.

 

-Sanjiva, Oct 2008

Success with Offshore Software Initiatives - Establishing Key Objectives (Part 2)

PRELUDE: This is one of a number of briefs that focuses on my perspectives on offshore software initiatives and specifically the keys towards achieving success with them. 

The challenges inherent in software development, which have led to continuously evolving processes, methodologies and tools become multi-dimensional and more complex when the project is outsourced to a partner or a team in a different geography (see my earlier entry titled "Outsourcing The S-Curve", http://sanjiva.typepad.com/thescurve/2005/10/outsourcing_the.html).  In the offshore context, you face a number of other factors, such as culture, language and time zone difference, that heavily increase the complexity of the undertaking and influence the mechanics of execution of these projects. 

Why do so many offshore projects 'fail'?  Why do people sometimes refer to offshore as "the valley of despair"?  Why do we keep trying?  In this series, I provide some of the answers to these questions indirectly by addressing the keys that are critical to succeeding with these initiatives.

Setting A Common Objective (contd.)

Why is it so important to set an objective for your offshore initiative (or at least set some objectives and their relative priorities)?

As I indicated in an earlier Blog entry, the strategy for outsourcing or "off-shoring" and the execution mechanics are heavily influenced by the specific objectives that are set and the results that are desired by the organization.

Here are some of the areas where the objectives influence the strategy you develop and the ways in which you execute the relationship and the offshore engagement (some are more obvious than others):

Geography --Where do you go to look for a partner?   If it is Toronto, Canada then you are not likely to "Follow-the-Sun" (at least not for more than a couple of hours) if your local team is in California. Geography also influences costs.  Beijing may be cheaper than Bangalore which may be cheaper than Toronto, etc. (although the rates alone do not ensure cost savings).

Partner--The type of partner you choose is influenced by the type of expertise you want to  leverage (language translations, performance or platform QA, integrations with tier-1 ERP solutions, etc.) and/or to build, i.e. build a team that needs to become proficient with your application, domain and customers.  Similarly, if you desire to scale the team quickly then 'offshore' does not need to be a parameter in the equation.  If that is the objective then nothing specifically relevant is gained by separating the team by 12 time zones unless there is a significant advantage in recruiting desired talent in a particular geography.

Parnership model--Is it a one-time project or a task-level engagement (i.e. you develop the software and the partner performs the translation or QA or platform testing or …), or is it a team that you build that will be responsible for end-to-end product development that will dictate the type of partner that you will select for this venture.  Moreover, it will also dictate the engagement model, since a number of more established offshore service providers support a number of different engagement models depending upon your specific objectives.

Strategic Engagement--Is the assignment project-based or a desire to build a team that will be an integral part of the organization.  Will the team eventually become part of the organization?  Will it use its own tools and processes to delivery the results or integrate and incorporate yours (referred to as Build-Operate-Transfer model)?   Will you eventually acquire the team?

Cost Saving--Cost saving can likely happen in two scenarios -- 1) when you are leveraging expertise, technology, process or tools that exist; 2) when you make long-term investment and measure it in the long-term.  It doesn't happen if you spend 3x the time training a new team to deliver something that is likely to be a one-time deliverable.

Team Culture and makeover--Is the team only going to take over maintenance or engage in new product development or engage in R&D activities?  This influences the type of investment needed into the partner, the team, its engagement with the local team, its makeover (innovation versus delivery focus), processes and skill sets.

There is a lot more to this but at least this list helps one appreciate the need for a common set of 'objective(s)' for the offshore initiatives.

Sanjiva, Orinda, CA,  Nov 5, 2005

Success with Offshore Initiatives--Establishing Key Objective(s) (Part 1)

PRELUDE: This is one of a number of briefs that focuses on my perspectives on offshore software initiatives and specifically the keys towards achieving success with them. 

The challenges inherent in software development, which have led to continuously evolving processes, methodologies and tools become multi-dimensional and more complex when the project is outsourced to a partner or a team in a different geography (see my earlier entry titled "Outsourcing The S-Curve", http://sanjiva.typepad.com/thescurve/2005/10/outsourcing_the.html).  In the offshore context, you face a number of other factors, such as culture, language and time zone difference, that heavily increase the complexity of the undertaking and influence the mechanics of execution of these projects. 

Why do so many offshore projects 'fail'?  Why do people sometimes refer to offshore as "the valley of despair"?  Why do we keep trying?  In this series, I provide some of the answers to these questions indirectly by addressing the keys that are critical to succeeding with these initiatives.

Setting A Common Objective

Success with your offshore initiatives will begin with an agreed-upon set of objectives and priorities of these objectives by key stakeholders in the organizations. 

I am a strong believer that any initiative must begin with a single primary objective.   The primary objective that you set for your offshore initiatives has a significant influence on the strategy and mechanics of execution throughout the life of the initiative (I will elaborate in a future entry).  The emphasis here is on a 'single' (or primary) objective because I have often found that multiple objectives (or agendas) exist within an organization for 'offshore-ing' software development and more often these tend to have competing (if not conflicting) priorities, disrupting influences on strategy and execution and vastly differing expectations of results.  Of course, as stated earlier, multiple objectives can be managed through priority setting but there should still be a single goal for why this needs to be undertaken.

So, why do you want to develop software across geographies, time zones and cultures?   

I can think of several reasons (not in any relevant order) along with the common rationale, wisdom or belief associated with each:

• Cost savings (most intuitive) 

Development costs are considerably less overseas

• Scaling of the engineering team 

You can hire faster, build and expand teams more rapidly

• Rapid product delivery

To deliver more product and features in the same amount of time

• Outsourcing mundane or tedious projects

The need for the 'home team' to focus on 'cool' stuff

• Exploiting time zones ('follow-the-sun')

Developers/testers working in multiple timezones on the same projects will give us an extended cycle in a single 24-hr period

• Separating development paradigms

R&D in one zone, product development in another, different teams, different processes for each

• Leveraging specific expertise of a partner or vendor

• Outsourcing product maintenance

The grunt work can be handed off to someone else while the organization focuses on product development

• Improving product quality

Increasing QA cycles or bandwidth through specialized offshore teams

• Impressing the board members and investors

Well!!  They believe in it so why not, even though we may not be clear about what we want to accomplish

• Adding perceived value to the organization

They are not our salaried employees but they can be part of the overall headcount if one is to measure our assets

Not all of these are necessarily in the same class of objectives that people often set for this initiative but the key here is that stakeholders within an organization will have different expectations depending upon their perspective of the reason for the initiative.  It is most critical to align everyone to the same understanding of the goal(s) that need to be achieved through this venture.  They need to understand it, agree to it and support it.  This applies to the Exec team, the product development team, the sales team and everyone else.

In the next blog entry on this topic, I will focus on ways in which these objectives can alter your strategy and execution mechanics.

-Sanjiva, San Francisco, November 5, 2005