Archive for the ‘Tasktop Sync’ Category

Connecting ServiceNow to Microsoft’s Team Foundation Server (TFS)

Wednesday, July 16th, 2014

One of the neat things about being so focused on SLI and DevOps integration in its various incarnations for the past decade stemming back to Mik’s PhD thesis is that we’ve seen more than nearly any other company in what it takes to be successful in making DevOps in the enterprise a reality. Note that when we talk about DevOps, we aren’t just talking about Continuous Delivery popularized by Jez Humble but actually the complete holistic view of DevOps which includes all activities in the software lifecycle from planning to development to testing to production. This holistic view has allowed us to create a set of common DevOps integration patterns. In this blog and accompanying video(s), I’ll focus on one integration pattern, the Help Desk Incident Escalation pattern.

Envision an organization who has an Operations team who uses ServiceNow for their help desk / ITSM solution to track and resolve customer support tickets. This may be internal or external customer support tickets. The same organization’s Development team uses Microsoft Team Foundation Server (TFS) to schedule and track its work.

As we show in this video (see below) recorded a few weeks ago during one of our weekly demo sessions, Tasktop Sync will create a bi-directional synchronization between the Operations team that uses ServiceNow and the Development team that uses TFS. Many of the incidents and problems that come into ServiceNow have nothing to do with software applications built in-house but rather things like “my laptop has a virus” or “my screen is cracked” or other IT related tickets. However, if in the course of triaging customer tickets, the Ops teams uncovers a defect that requires the development team to spring into action (e.g., related to a internally developed piece of software), Sync will synchronize the ticket in ServiceNow as a defect in TFS so that the developers can work to remedy that defect. The status of the defect in TFS can by synced back to a custom field on the ticket in ServiceNow so that the Ops team knows what is going on at all times and can keep the customer apprised on any progress of the ticket. Alternatively, the status field in each repository can map directly to each other.

We didn’t show this in this specific demo video but many of our customers also have HP Quality Center (QC) for their testing infrastructure. If the Dev systems and QA systems are also connected via Tasktop Sync, Ops can also see if that defect fix has been successfully verified and tested by QA.

The really cool thing is that some of our biggest customers follow the ITIL cookbook in their Operations department (and even more fun are the ones who “sort of” follow the ITIL cookbook). Regardless, the neat thing is that Sync, in these cases, allows our friends in Operations to follow their ITIL processes (following the ITIL transitions from incident to problem or change request) while not forcing the ITIL processes visibly onto their colleagues in Development, who may react poorly to such “heavy weight process” imposed on them.

Recording of Shawn’s recent ServiceNow / TFS Video:

Connecting BlueMix to the world

Friday, June 27th, 2014

Over the last 6 months IBM has been heavily promoting BlueMix, the IBM cloud delivery platform based on IBM’s open cloud architecture and Cloud Foundry. The platform is heavily aimed at developers, promoting the ability to rapidly deliver applications to the IBM cloud by leveraging auto provisioning,  development frameworks and a very cool web IDE. But what makes BlueMix special is the idea that customers can start developing in a very modern flexible “cloud” environment whilst managing the risk of change and do this all with staying with IBM. The same IBM that supports many other aspects of the customer’s IT infrastructure. As cloud development crosses the chasm, hybrid or combination development, will be the reality for many large organizations that will have to connect these “new” cloud developments with their more traditional development projects. IBM is well-placed with their knowledge of both worlds – and their integration partner Tasktop. As many of you know, Tasktop partners with IBM to provide software lifecycle integration by OEMing the “IBM Rational Lifecycle Integration Adaptors – Tasktop Edition,” from us.  Tasktop provides the integrations that enable IBM customers to connect their different tools, creating an integrated lifecycle supported by heterogenous tools. This integration technology already supports connecting on-premise tools like Rational Team Concert to cloud tools, such as Rally, but I would like to announce a technical preview for BlueMix.

Technical Preview for BlueMix

In this attached preview, you will see a typical scenario of an application being developed in BlueMix with testing being performed in HP QC, in a Testing Center of Excellence. This Testing Center of excellence uses an on-premise version of HP QC which integrates with Tasktop in real time to the BlueMix version of JazzHub. This supports the natural flow of work being done in BlueMix: tests undertaken in HP QC and the defects running back to the developers in BlueMix. This replaces the need for BlueMix developers to leave BlueMix and allows testers to work in their tool of choice. And this is just a preview of one scenario – but because BlueMix is just another connector to the Tasktop integration bus, it opens up BlueMix to all the other lifecycle tools supported by Tasktop. For example, maybe requirements are being developed in IBM RRC, or the PMO wants to continue to report on project progress in Clarity… or your organization is using ServiceNow and wants problems to automatically be pushed to developers in BlueMix. All of this is possible by connecting BlueMix to the software lifecycle with Tasktop.

If you are using BlueMix today and are interested in trying this technical preview please let me, or your Tasktop contact, know. We are excited to connect the worlds of cloud development and of traditional software delivery lifecycles together.

Right Action, Right Time: Tasktop Raises Financing

Tuesday, June 24th, 2014

After 7 years and growing to 70 people as a bootstrapped company, at the end of 2013, Tasktop made a decision to raise external financing.  We’re very proud of what we’ve achieved as a bootstrapped entity and the innovations we’ve created including Mylyn, the task-focused interface, co-authoring the Change Management portion of the OSLC specification, the DevOps integration bus Tasktop Sync, and Software Lifecycle Integration.  I am very proud of the organization that I’ve helped build, and the cool thing was that we could have kept growing without raising money.  We made a choice because we felt that the opportunity to change how software was built was so big and the foundation we had put in place was so solid, that it was time to add a catalyst to our business.  Also, our customers and partners wanted more from us than we could give to them organically so to grow commercially at the pace that the market was demanding, we felt the funding was needed.

Now as you know, wanting funding and actually getting funding are two different things.  We were quite gratified as we went through the process that there was significant interest in the team we had built and what we had accomplished to date.

Today, I’m very pleased to announce that we’ve raised $11M.  The primary focus of this investment is to expand the commercial part of our business.  Over the past 7.5 years, we’ve created technology that drives tremendous value to our customers.  When companies purchase Tasktop Sync or Tasktop Dev, they get software that pays for itself in the quarter it was purchased in (contact us to walk you through how Tasktop can drive significant returns for your organization).  We need to get these innovations into the hands of even more organizations so that more of our colleagues who build software for banks, insurance, healthcare, manufacturing, government, retail, and the like can do it at the increasingly rapid pace demanded by today’s marketplace.  We are proud that our customers get increased visibility into their software manufacturing processes, see improved collaboration between the various stakeholders involved in delivering software and get home to their families in time for dinner because they’ve been so productive during the day.  So we will grow geographically, adding more local presences around the globe (in many cases with our growing partner ecosystem).

We will also grow the breadth of our integrations portfolio so that we will provide coverage for the top 80% of the market leading tools in every category we support (project/portfolio management, requirements management, Agile planning, change management, test / quality assurance, and help desk / ITSM).  Finally, we will evaluate adding integrations into adjacent markets based on customer demand.  In essence, we have raised funding to do a lot more of what we’ve been doing.  That also means we will maintain the discipline that allowed us to bootstrap the business through the ups and downs of the past 7.5 years.

John Thornton

The round was led by Austin Ventures, the VC in my home state of Texas.  With over $3.9B raised over the course of 10 funds, Austin Ventures has been the most active investor in Texas.   We’re excited to be adding John Thornton to our board of directors.  John has been a VC for Austin Ventures for the past 25 years, even leading the firm for a number of years as the managing director.  John’s ability to reach into his decades of experience in enterprise software stemming all the way back to his Tivoli and BuildForge investments to some of his other investments like SolarWinds, Datical and ITInvolve will help us navigate the growth we will be going through over the next few years.

Mike Satterfield

We also syndicated the round with Yaletown Ventures, the most active VC in Canada.  Mike Satterfield will be representing Yaletown on the Tasktop board after spending about a year as a board observer.  We’re thrilled to be continuing to get Mike’s experience working with enterprise software companies.  He has already been critical to helping us in recruiting in Vancouver as well as helping us navigate some of the challenges we’ve faced as a Canadian company working on a global stage.

I’m also excited that my friends at the Capital Factory also chose to participate in this round.  Both John and I are mentors at the Capital Factory, so this investment comes full circle for both of us.

I want to also say that I am proud that we’ve done it as a Canadian company.  Mik Kersten, Gail Murphy and Rob Elves started this company 7.5 years ago out of the University of British Columbia.  UBC has been a huge part of what we are, what we’ve been and what we will be.  I’m proud of the partnership we have with UBC and am proud of our organization who takes time to give back to its roots.  There are so many other people who have made a difference en route to this milestone for the company e.g., Rizwan Kheraj and all of the folks at the NRC, Bill Tam and the folks at BCTIA, and Mike Milinkovich and the Eclipse Foundation.

We also want to thank our customers, our partners, and our friends in the media and at analyst firms for their support over the past 7.5 years in allowing us to enter this new chapter of our company’s growth.

First look: Tasktop Sync Integrates Visual Studio Online with popular DevOps Tools

Tuesday, May 13th, 2014

I’m excited about returning to TechEd for the first time in 3 years.  In 2011, I attended my first TechEd in Atlanta.  It was an exciting time for Tasktop; we had just announced Visual Studio support for Tasktop Dev and were a couple months away from announcing Tasktop Sync, our flagship integration hub for the DevOps stack.

Maude Hejna, Program Manager for Visual Studio Partner Program (VSIP) at Microsoft, and Neelan Choksi, President of Tasktop

TechEd is particularly interesting this year because Microsoft is embracing interoperability between Microsoft and other technologies under Microsoft’s new CEO Satya Nadella, the same Nadella who offered Linux on Azure and, in his first activity as CEO of Microsoft, rolled out Office for Apple’s iPad.  I am personally rooting for success for Nadella, who, like me, is a graduate of the University of Chicago Graduate School of Business (now the Booth School of Business).

At Tasktop, we are especially pleased to see the trend towards interoperability. To that end, we are excited to show a Technology Preview of Tasktop Sync’s support of Visual Studio Online (VSO) at TechEd today. This Technology Preview highlights Tasktop’s strong and long-standing relationship with Microsoft:

Tasktop Dev integration with Visual Studio and Team Foundation Server (TFS)
Tasktop Sync integration with Microsoft TFS (including sim-shipping with TFS 2012 and TFS 2013 when they were released)

The demo video above highlights integration between Visual Studio Online and Atlassian JIRA.  This extension is currently a Technology Preview (closed Beta) with the GA of this functionality coming this summer.

In this video, we demonstrate a Visual Studio Online-to-JIRA integration. You’ll see a defect created in JIRA sync to Visual Studio Online. Tasktop Sync will create the corresponding defect work item in Visual Studio Online and set up ongoing bi-directional synchronizations. During the demo, the work item in Visual Studio Online is updated and the defect in JIRA is updated in real-time.  The video also shows the opposite workflow– a bug created in Visual Studio Online is automatically created in JIRA.

This is just one example use case.   The great news is that the entire ecosystem of Tasktop integrations now works for VS online.

As we head towards GA this summer, we expect to be solving additional business challenges based on our upcoming release with support for VSO. For example:

Connecting VSO to Microsoft TFS on-premise and other on-premise tools.   As organizations determine what they will move to the cloud and what will remain on-premise, this integration will provide important functionality.
Connecting cloud-based development tools like VSO to other cloud-based DevOps technologies currently supported by Tasktop Sync e.g., ServiceNow, Zendesk, Rally, VersionOne, and others.
Connecting cloud-based development tools like VSO to other on-premise DevOps tools currently supported by Tasktop Sync e.g., HP Quality Center, IBM Rational, ThoughtWorks Mingle, CA Clarity.

To see the full list of DevOps tools currently supported by Tasktop Sync, please check out the list at

If you are in Houston this week at TechEd, do not hesitate to contact us about meeting up.

Living the Experiences of Our Customers

Monday, April 28th, 2014

Joining Tasktop as a business analyst in September 2013, I was tasked to learn about the intricacies of the software delivery process while doing my part to help the company work toward its goal of improving that very process. While at first this seemed like an overwhelming undertaking, it turns out that Tasktop has been a great place to do so.
Our Vice President of Product Management, Nicole Bryan, often states that building software takes a village. As a business analyst, I regularly interact with the many members of this village and have seen how the contributions of each combine to create our own software solutions. This interaction has revealed not only the importance of each unit, but has also underscored the principal reasons for Tasktop’s existence.

When I first pursued a career opportunity at Tasktop and learned about its technology, I thought to myself “If the disconnect between teams using different tools is so pronounced, why wouldn’t someone focus on building a single piece of software that could be used by everyone involved in software development and delivery?” If such a tool existed, the need for integration would cease. (And the company that built it would make a lot of money.) Tasktop seemed to be doing well, though, and the position seemed interesting, so I happily joined when I was extended an offer, eager to learn about the world of software development.

And oh, how much I have learned. I now realize how naïve a notion that the development and large-scale adoption of this theoretical all-inclusive tool was. While I knew there was a disconnect between teams, I didn’t realize just how many teams were involved in software development and delivery, the high volume of which would make developing an comprehensive tool extremely difficult. I now see that software development and delivery involves more than Engineering and QA. Product, Business Development, IT, Management, Sales, Solutions, and Marketing, among others, are also at its core.

While developing any all-encompassing tool would be difficult, developing a high quality one that satisfied every team seems like it would be next to impossible. Before starting at Tasktop, I not only underestimated the number of teams involved in software delivery, but also did not fully grasp the fact that different types of teams (Product, QA, Engineering, etc.) have not only drastically different needs, but also different desires in terms of the functionality and mental model of a product. As I’ve seen at Tasktop, people with different inclinations and talents tend to have distinct preferences and to work in particular ways—and this is at a company that is small in size compared to many of its customers. Satisfying all of these predilections in a single tool would be quite the feat to accomplish.

Finally, I failed to discern just how engrained people could become in using a certain tool. The tools we use to do our job define our basic workflows and fundamentally affect our day-to-day activities. And if a given tool is serving your team well, why would you move to something else? Working is the software industry is demanding enough without having to learn a new tool simply to do your job. The bottom line is that change is hard. This is true not only at the team level, but also at the organizational level. Migrating any team to a new tool would be an expensive and exhausting effort and would significantly disrupt work; migrating all teams to this tool I originally envisioned would be all the more difficult.

As it turns out, developing such an all-encompassing tool would not only be a challenging endeavor, but would also be less than ideal. The need for integration will always exist. But this is not a bad thing. With solutions like Tasktop Sync, our partners can build tools that focus on solving problems for a particular set of individuals, rather than tools that fruitlessly try and help everybody. Though varied, the resulting tool landscape offers a strong set of options for practitioners involved in all parts of the process.

The beauty of Tasktop Sync is that it allows each team the freedom to use the tool they choose from this landscape, a valuable affordance that I only now understand, having lived the experiences of our customers first hand. The insight I’ve gained while working at Tasktop has given me an appreciation for the fundamental need for a software lifecycle integration strategy that defines processes and connects disparate tools and teams. It has also led me to empathize with the multitude of other knowledge workers involved in software delivery across the globe, an empathy that drives the work of myself of my colleagues everyday.

So, go ahead and keep working in your preferred tool–We’ll worry about the cross-team integration, and you won’t even know we’re doing it.

Tasktop Sync 3.5 released: VersionOne, Zendesk, links get sync

Tuesday, April 1st, 2014

We’re at the ALM Forum this week, where the hot topic is how to scale Agile and DevOps deployments.  What Scott Ambler made clear in his opening keynote is that there isn’t a single Agile best practice that spans the various sizes, domains, business processes that we find across organizations. While the practices and vendor tools implementing them vary greatly, the principles are consistent.  Short iterations, automation, real-time collaboration and end-to-end traceability are critical to an effective software lifecycle.  These principles are relatively easy for individual teams and startups to adopt.  The massive challenge that mid-size and large organizations are faced with is how to reap the benefits of Agile at scale.

While December’s Tasktop Sync 3.0 release extended our support to DevOps, the 3.5 release is all about supporting Agile at scale. Sync is now the lifecycle integration infrastructure for 5 of the top 25 world banks and powers many of the world’s largest Agile deployments.  The larger the scale of the deployment, the more problematic the disconnects between tools and processes become.  With Sync 3.5, we are introducing a new capability to our software lifecycle bus called Artifact Relationship Management.  This provides the last mile of integration needed for large scale Agile.  In addition to synchronizing the artifacts that make up your lifecycle, we now synchronize the relationships between those artifacts.  The result is end-to-end traceability and for best-of-breed and heterogeneous Agile deployments.  Which is pretty much every sizeable Agile deployment.

The internal workings of Artifact Relationship Management are complex due to the different kinds of relationships that make up your software lifecycle architecture.  For example, a requirement can be in a hierarchy, a folder, depend on an internal item or an external item, as well as being connected to tests, builds or source changes in other tools.  While it took 3 PhDs to untangle the various scenarios that enable Sync to federate relationships across tools, as with the rest of Sync, all of this functionality is now easy to configure for your administrators and completely transparent to your end users.  Whether you’re working with traditional requirements managements and Water-Scrum-Fall, or deploying new methodologies for large-sale Agile such as the Scaled Agile Framework (SAFe) or Disciplined Agile Delivery (DAD), you will now have end-to-end visibility, traceability, and collaboration across your best-of-breed tool stack.


We are also very pleased to announce Sync support for our partners VersionOne and Zendesk.  This means that we now have support for all of the market-leading Agile tools, and we have also made significant improvements to our support for Atlassian JIRA Agile, Bugzilla, CA Clarity Agile, IBM Rational Team Concert (RTC), Rally, Microsoft Team Foundation Server (TFS) and ThoughtWorks Mingle.  Adding to our other integrations, our Integration Factory is now continually testing 220 different versions of the Agile, ALM and DevOps tools that we support.


Finally, Sync now has a new desktop and mobile device friendly Web UI. While Sync Studio provides the rich Eclipse-based configuration environment that allows Agile ALM tool administrators to easily deploy Sync purely through configuration, the Web UI provides you with a metrics of what Sync is doing, such as the number of synchronizations and artifact creations that are spanning systems.  Now that Sync has become a core part of the organizations’ Agile and DevOps infrastructure, these metrics provide a quick way to manage your Software Lifecycle Integration infrastructure as it evolves.

For more on the release, see New & Noteworthy

Business DevOps is really what we want…

Wednesday, January 8th, 2014

I remember the famous blog by Mike Gualtieri, an analyst at Forrester stating, “I don’t want DevOps, I want NoOps,” creating a passionate debate in the DevOps community about the importance and value of operations. After reading all the comments, it seemed that the solution was a sensible one: Organizations need balance – releasing software requires the skills of both operations and development. For some organizations, this means developers taking on more of the deployment burdens. For others, it’s operations creating automation that is used by developers. And in some companies, it’s Agile teams including operations specialists that focus on both deployment and operations. The bottom line is that DevOps calls for a balanced, thought-through discussion about the role of operations and development. It also calls for collaboration between these two groups.

But hang on a minute – aren’t we missing someone from this discussion? DevOps has focused on connecting development and operations – but mostly in terms of the technical, discipline-oriented work – such as defining techniques that allow builds, deployments, installs and configurations to work seamlessly. DevOps has even promoted the idea that the developer’s work management tools and the organization’s service desks should be integrated. But what DevOPs often misses is that it takes a village (or small city) to deliver software, and a key set of people called “managers” need to also be involved. We need to connect portfolio management to the practice of DevOps – we need to make DevOps, BusDevOps (Business-Dev-Ops).

OK – I can hear the skeptic saying “why do management need to be involved?” Well, “management,” specifically portfolio management and the PMO, are responsible for making strategic investment decisions. They are also, in many organizations, responsible for the financial management of projects/ programs and portfolios. Thus, the process and work done by DevOps need to be managed, and more importantly, reported on by the PMO. This management might be as granular as deciding which trouble tickets to work on, or as macro as seeing the aggregated ticket cost grow and shrink over time and allocating resources accordingly. Depending on your organization, the governance and oversight provided by the PMO needs to be integrated into the process of DevOps allowing improved reporting and decision-making.

We’re bringing Business DevOps together

As part of the Sync 3.0 release we added ServiceNow and JIRA ServiceDesk connectors. These connectors allow tickets to be integrated into both ALM and PMO processes. For example, a service ticket in ServiceNow can generate work items in Clarity, which then are planned in Rally, allocated in TFS to be worked on, and tested in HP QC – all the time being the same “single source of the truth” even if living in many systems. Thus, consistent reporting, collaboration and workflow can be executed against this artifact in real time. With Tasktop Sync 3.0 we allow comments to stream seamlessly from different systems allowing developers, operations, project managers and testers to freely collaborate without leaving the comfort of their own tool. In addition to collaboration by integrating the data across discipline and application boundary, software delivery professionals can generate reports in the system that makes sense to them and of course, get cross discipline and artifact traceability. Integration between operations, development and portfolio management gives organizations the information infrastructure to be more efficient, collaborative and replace the need for manual processes and email and spreadsheets. In fact, one of our missions at Tasktop is to replace the need for email and spreadsheets on software delivery projects and this is just another example of how we can replace those tools.

The creation of the ServiceNow connector was driven by customer demand. When looking at these customers there were two things that unified them:

  1. Increase the lifecycle feedback – Agility highlights the importance and value of feedback. For projects, getting feedback early allows problems to be uncovered earlier and corrective decisions to be made earlier. Though the adoption of Agile methods is widespread, most organizations still suffer from a disconnect between operations, development and the project office.
  2. The need for delivery speed – For many organizations software is crucial for their survival and success. Getting new features and products to market earlier has real impact on the bottom line. But as delivery cadence increased, many of the manual processes that glue together the different disciplines start to break. And while data exchange needs to happen in real time, spreadsheets and email actually start to fracture communication, rather than enable it.

Many organizations talk about Agility, but without automated feedback, Agility really only resides within the boundary of the development team. By connecting development, operations and project managers, organizations have the chance to effectively break down the barriers between those groups, moving to one integrated agile process without assuming that having one process means needing only one tool (which for many organizations is just impossible).

A call to action for Business DevOps

The idea that the way to increase Agility is to reduce the number of disciplines and replace everything with a super developer who can manage the team, work with the business, write great code, test it and then manage its deployment and support, is a pipe dream. Even the most capable developers cannot do everything and specialist practitioners, using the tools that make sense to them, will always be the reality. But that does not mean you have to give up on the dream, organizations can better integrate these groups and disciplines. By focusing on information federation rather than control all groups involved in development can get a better view of what is happening.

Here is a three step program for business DevOps:

  1. Understand the information flow of the primary artifacts – for example, how does a ticket flow through the process from operations to the project office and then into development and test.
  2. Understand the transitions between the artifacts – for example when does a ticket become a new user story or defect and what information would make sense to share across those artifact boundaries.
  3. Replace spreadsheets and manual processes that connect the disciplines today.  Connect up the end tools or adopt a software lifecycle integration business such as Tasktop Sync to make the transition smooth and happen in real time.

Tasktop Sync 3.0 released, service desks get support

Tuesday, December 10th, 2013

Open source projects have it good. Their issue tracker serves as the single system of record for all development, support, quality management and planning activity. The result is a theoretical ideal in terms of a connected software lifecycle. For example, every vote that a user makes for a particular bug is immediately visible to developers. As soon as a new feature is added, users watching the corresponding task are automatically prompted to try the latest build and report back. This kind of real-time connectivity between users, developers and project leaders makes for an incredibly efficient build-measure-learn loop, which explains why so many open source project are able to deliver so much value so quickly. Having lived it day-to-day, it continues to inspire me in wanting to bring these benefits to software delivery in the large, where these benefits can make a tremendous difference.

Tasktop Sync 3.0: Defect Unification

The problem is that this open source project management approach doesn’t scale to the enterprise. It’s fine when you’ve got one stakeholder playing multiple roles. For example, on Mylyn I played the role of developer, product manager, tester, and support desk. I spent so much of my time triaging and commenting on bug reports that, in order to help me get through the tickets fast enough to have enough time for coding, I ended up adding features to Mylyn to make it work as a developer’s inbox for triaging tickets. The experience of other open source projects leads that I know is very similar, in that a tremendous portion of their time is spent triaging and responding to users. This direct touch with end users enables open source developers leverage the collective wisdom of their community so quickly.

However, the developer’s issue tracker does not scale to meet the demands of commercial software support, such the need for SLAs and ITIL processes. So a separate help desk tool is required, once that separation is made, real-time collaboration between the developer and support team stops, and reverts to inefficient channels such as email and meetings. The result is a chasm between the people who are user facing and those who are developing the application. The knowledge of the customer’s experience gets siloed into the help desk and voice of the customer gets diffused by the time that the next sprint planning session comes around. Given the increasingly primary role that the service desk plays in the software lifecycle, as evidenced by the amazing growth of ServiceNow, we need to fix this.

Tasktop Sync 3.0: ITSM

Our goal with Software Lifecycle Integration is to unify the ALM stack while allowing software stakeholders to use the systems that make them most productive. With today’s Tasktop Sync 3.0 announcement, we are very happy to reveal that the Sync bus now supports ITSM artifacts such as tickets and problems, and can connect service desk tools to the large and growing number of Agile and ALM tools that we support. Tasktop Sync makes it possible to extend the popular Defect Unification SLI pattern to the service desk, meaning that tickets matching specific criteria, such as those marked as problems, are automatically created as issues in the issue tracker or defects in the quality management system, and synchronized bidirectionally from that point on. For example, if the defect is Synced to IBM’s RTC, developers can schedule them onto a sprint, and the support team will instantly know that it has been assigned. And as soon as it’s completed, the workflow transition will happen on the service desk indicating that the fix is ready to review or deploy to the customer. Comments and activity streams are federated in real-time. And then it’s smiles all around.

We are launching two service desk integrations with Sync 3.0. Our integration for ServiceNow integration is fully certified by ServiceNow, and will support the many uses of the ServiceNow platform ranging across its ITSM and lifecycle capabilities. We are also launching support for Atlassian’s recently announced JIRA Service Desk, which builds on our comprehensive support of JIRA versions including the latest JIRA 6.1. And as usual, there will be more to come so please let us know what other support desks you would like to see integrated.

ServiceNow Visualizer

Connecting the help desk and bridging the task management gap between Dev and Ops is the most exciting Sync 3.0 news in terms of our mission to scale the efficiency of open source development to the enterprise software lifecycle. In other news, we’re releasing new template support for inheriting and extending mappings, making it dramatically easier to manage large numbers of of projects with different schemas. For those customers using Rally and Serena Business Manager, we’re very happy to announce the GA of those Sync connectors along with the Tasktop Dev connector for developers accessing Serena from Eclipse and Visual Studio. We’ve also extended the Sync bus to support time tracking federation between Agile and PPM, enabling time on task to flow between your Agile system and CA Clarity.

Sync 3.0: Example

Finally, the big news for both ALM vendors and customers is a beta program of the new Tasktop Connector SDK. You may think that SDKs should be old news given that Tasktop created and maintained the Mylyn SDK, which became one of the most extended SDKs on Eclipse. But it turns out that in order to support the real-time lifecycle bus architecture of Sync, an entirely new integration extensibility layer had to be created in order to support robust and easy-to-implement 3rd party extensibility. Along with it we created a bridge to support Mylyn connectors, so if you created one of those you’ll have a head start. If you’re interested in being an early adopter partner of the SDK, please get in touch.

Tasktop Sync 3.0 Bus

We’re thrilled that the tremendous customer demand that we saw for connecting the service desk ships today, and look forward to bringing the voice of the customer into the enterprise software lifecycle.

Want to learn more about Tasktop Sync 3.0? Register for an upcoming webinar:

When: Thursday, January 23rd, 2010: 12 noon ET
Presented by: Mik Kersten, CEO of Tastkop
Register now: Webinar – Introducing Tasktop Sync 3.0

The double-sided nature of requirements

Friday, July 26th, 2013

Bad requirements are often cited as the biggest reason why software projects fail. Badly understood or missed requirements drive business executives to despair. The business and development all blame each other for why things went wrong, and ultimately the end users don’t get the system they want. Over the last 20 years, the industry has tried many different ways of solving the requirements problem. Improvements range from formal methods and model-driven approaches to team organization and customer engagement. For many Agile projects, formality is discarded and replaced with strong customer interaction and the delivery of regular working software that can be reviewed with the end user. The system specifications are replaced with stories and epics that encourage collaboration with the customer, focusing on observable acceptance criteria, instead of describing in detail what the system does.  So has Agile solved the requirements problem?
I would argue in part Agile has provided a great way for teams to engage with customers, but for many complex, large systems requirements, management is still needed. In fact, for large projects or products, by encouraging no specification and formality, Agile methods have often undermined project success. I believe that for complex software projects, organizations still need to invest in requirements techniques and associated tools, but they need to understand the difference between requirements management and definition. Definition/management is an area that gets very confusing as we talk about requirements in project management and software delivery terms. A requirement is both a plan item and a specification, and unfortunately tool vendors have only amplified this problem. The Agile community has all but given up on the definition side of requirements, focusing instead on the project management or work planning perspective. Unfortunately, the truth is that requirements are both, and we need to effectively treat them in both ways.

At Tasktop, we work with this [inherent duality] of requirements daily when we are asked to create a real-time connection between the most traditional of requirements management tools to the most cutting edge of Agile and developer-centric tools.  For the purpose of illustration, I will describe how Tasktop builds our products and how requirements definition has risen as a formal discipline in support of our requirements management approach.

Tasktop has a simple mission: to connect the world of software delivery. That mission means that we build tools that help organizations connect their software delivery lifecycle. One of our products, called Tasktop Sync, is an integration hub for software delivery tools. Over the last four years, Tasktop Sync has evolved from a point-to-point integration to an infrastructure tool that integrates numerous software development tools and supports multiple artifacts and platforms. Tasktop engineering has always used Agile methods with stories being allocated to sprints, releases being X number of sprints and story points and velocity being used to plan. But as the complexity of Tasktop Sync grew and as we engaged with more partners, we found that engineers were increasingly asking ‘what does Sync do?’, not at the macro level, but at the detail level. For example, how does Sync transform a particular field type or handle a particular error condition? This problem was made even more intense as we built more and more connectors. Those connectors implemented similar functionality for Sync but with different product end points. We needed to describe a specification for integration. This specification describes how we expect a connector / integration to work. The implementation for each connector would be different, but the specification would be the same. Stories were a fantastic way of describing the item to be planned but gave the development and test teams very little in the way of details to ensure that each connector would implement this feature in a consistent way. Thus, we uncovered the double-sided nature of requirements.  Requirements are both a specification (and asset) and a task (or work item).

But as we explored this problem more, we found that the tools we were using to capture stories did not provide us with a great way of describing the specification; even worse, once we described the specification in the tool, we found we had no way to find it again – after all, a story is used to drive development, and once completed it’s banished into history, being only used for historic velocity information. We had to describe our specifications in a tool that allows version management and supports being able to find the information, and because we are an engineering company that is very focused on productivity and automation, a specification that can automatically build acceptance tests. A story is linked to this specification in the same way that code, tests and ultimately test results are linked to this artifact, but it is not the same artifact. In fact, we found that the stories described the creation or change to that specification and held meta-data associated with the work, not the details of the capability. As a result, we found that we could capture historic velocity not only about the teams, but also the feature we were supporting.

So what does all mean? In short, we need to think about the practice of requirements management as different from the practice of requirements. The two disciplines are linked but are different. Tool vendors who historically have merged these two activities need to stop and evaluate their products and try to separate the two approaches. That would allow the industry to have tools that allow the management of work and creation and maintenance of assets to be separate.

What do you think about this interesting double-sided behavior?  How have you dealt with it when deploying Agile at scale?

Keeping Our Eyes Wide Open

Tuesday, May 21st, 2013

There was more going on in San Francisco than the Bay to Breakers race this past weekend (May 18-19). The 35th International Conference on Software Engineering, the premier software engineering conference, also began and will run from May 18-26. ICSE, as it is known in the research community, has attracted more than 1000 people from 50 countries to the Bay Area for over a week of communicating new advancements and best practices in software engineering. Tasktop is a sponsor this year and will be participating in events such as the student-industry lunch, where 300 students will have a chance to exchange ideas with and hear about opportunities at sponsoring companies. With Tasktop’s current growth, we are eager to meet these high-caliber students!

But Tasktop has even deeper roots with ICSE. A fundamental aspect of Tasktop’s vision has always been to improve communication and collaboration amongst the people involved in software development so as to truly connect the world of software delivery. The initial step Tasktop took towards this vision was to embed the concept of a task into the IDE as part of the Eclipse Mylyn project. When Mik Kersten, our CEO, started the Mylyn project in the UBC Software Practice lab, the need for tooling to connect the IDE to common issue repository systems quickly became evident. Luckily, a connector that allowed issues from Bugzilla to be brought into the Eclipse IDE was available within the Software Practices Lab. This connector had been built as part of the Hipikat project . Hipikat recommends items from a software project’s history, such as past bug reports, source code commits and email messages, that might be useful to a developer currently trying to perform a task on the project. In essence, Hipikat serves as a memory of the entire project built from the project repositories so that it can answer a question that you might have asked someone at the water cooler if they had only not left the project. The starting point for many Hipikat queries is an issue or a bug. For instance, a developer may select a bug he or she wants to work on and ask Hipikat for similar bugs that have been solved in the past. As a result, Hipikat needed a means of having bugs in the IDE, which caused the initial development of a Bugzilla connector. Shawn Minto, who built the Bugzilla connector, is one of Tasktop’s most experienced software engineers.

On Friday of the conference, Davor “ubrani”, who conceived and built Hipikat as part of his Ph.D. work at UBC, and myself, will receive the “Most Influential Paper 10 Years Later” Award for the paper about Hipikat. Our paper is receiving the award, as it catalyzed substantial work on recommenders for software engineering, some of which are finding their way into practice today. For example, more and more sophisticated code completion recommendations are finding their way into the Eclipse Java editor.

Hipikat’s name means “eyes wide open” in the West African language Wolof. Keeping your eyes wide open is as critical today for tackling the hard problems of software engineering as it was ten years ago. Each day, Tasktop strives to keep its eyes wide open when tackling the challenges that come with with connecting the world of software delivery. Will you be attending the ICSE Conference? If so, please tweet me at @gail_murphy.