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

by Neelan Choksi, 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

by cynthia.mancha, 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.

EclipseCon 10 years old

by Andrew Eisenberg, April 17th, 2014

This was the tenth year of EclipseCon and my fourth time attending. I have been using the Eclipse IDE for over 12 years and so much has changed with technology and developers’ expectations. At the beginning, just having a single Java IDE that was smart enough to edit, compile, run, and debug your code was a major breakthrough. And for many years, the trend was to integrate into the IDE, with the expectation that all tools be absorbed into the IDE. Now, this trend is reversing and developers are starting to expect IDEs that can seamlessly connect to tools, allowing developers to use the tools in the way that makes the most sense for them.

The most interesting theme for me at this conference was trying to figure out how developers will be working another 10 years from now.

The future of the IDE

The Orion IDE is a prime example of this reverse-integration trend. Orion is a hosted IDE with a light-weight plugin model. One way that the plugin model allows integration with third party tools is by linking out to them in other browser pages. This allows developers to do programming tasks in the IDE, but still have easy access to external tools for deployment, testing, and monitoring. Ken Walker gave a good talk showing this, cheekily called Browser IDEs and why you don’t like them.

Another example of this is the Mylyn hosted task list, which Gunnar Wagenknecht and I introduced in our talk Unshackling Mylyn from the Desktop. The main idea is that current Mylyn task lists are restricted to working inside of a single Eclipse instance, but developers are looking to interact with tasks outside of the IDE (in the browser, on the desktop, on their phones, etc). The hosted task list provides developers with this capability using different kinds of clients that all operate on a single notion of a task list that is hosted remotely. We provide a simple API so that third parties can provide their own clients. What we presented at EclipseCon was early work and we are looking forward to showing more of this at future conferences.

Lastly, Martin Lippert and Andy Clement, my former colleagues at Pivotal, introduced Flux, a novel approach to a more flexible development environment. The main idea is that developers may want the simplicity of developing in the cloud, but also don’t want to give up the possibility to develop in a more traditional way on the desktop. Flux allows you to connect your local workspace to a cloud host that provides services like editing, compilation, and refactoring. This way, you can work in the cloud while still being able to drop down to the desktop whenever you need to. Watch the screencast.

It is still early work, but it is quite compelling and I’m looking forward to seeing how this progresses.

Java 8

It shouldn’t be surprising that the Java 8 track was the most popular at EclipseCon this year. Java 8 was released in the middle of Alex Buckley’s The Road to Lambda talk. What I thought was most interesting about this talk was that it focused on the design decisions around implementing Java 8 lambdas, why it took so long many years to do so, and why Java is now a better language because of its relatively late adoption of lambdas. I found Let’s make some 0xCAFEBABE particularly interesting with its deep dive into byte code. Lastly, API design in Java 8 showed how libraries and APIs can improve by taking advantage of new language features.


This year, I helped organize an Eclipse hackathon. It was a great experience. We had over 50 attendees, split roughly evenly between project committers and new contributors. The goal was for new contributors work on some real bugs in Eclipse, while being helped by project committers who guided them through the process of setting up a workspace, choosing a bug, and submitting a patch. By the end of the evening we had 7 contributions accepted to the code base. It was encouraging to see so much passion about working with open source.

Everyone's hacking!

There are plenty more photos from the event on the Eclipse Foundation’s Flickr stream.

It was truly a wonderful conference and there was so much more including 3 excellent keynotes and of course lots and lots of beer.

Now that I’m back, I need to catch up on sleep, but I’m already looking forward to next year!

Tasktop Dev 3.5 and Mylyn 3.11 Released

by Sam Davis, April 14th, 2014

Tasktop Dev 3.5 and Mylyn 3.11 are now available. These releases include some cool new features that result from the combined efforts of many people in the Mylyn community and at Tasktop.

Speaking as a Tasktop Dev and Mylyn user, I am already loving the new support for finding text in the task editor. It was originally contributed to Mylyn Incubator a few years ago, but unfortunately the implementation suffered from serious performance problems. Recently I had the pleasure of supervising a Co-op student at Tasktop, Lily Guo, as she reimplemented it with dramatically better performance and improved the UI. Thanks to her efforts this very useful feature is now released and the task editor supports searching for text within the comments, description, summary, and private notes.

Screnshot of Find in the Task Editor

Another long-awaited feature in this release is task-based breakpoint management, which extends the concept of task context to include Java breakpoints. This was implemented as part of a Google Summer of Code project by Sebastian Schmidt, a graduate student at Technical University Munich. It provides several important benefits for Java developers. First, the debugger will not stop at breakpoints that aren’t related to the active task. Second, only breakpoints created while the task was active will appear in the IDE – when working on a task, the breakpoints view and Java editors are no longer cluttered with dozens of irrelevant breakpoints. Because the breakpoints related to a task are only present while that task is active, there is no need to delete or disable these breakpoints – which often contain valuable information such as which lines of code and which runtime conditions trigger a defect – when a task is complete. Finally, breakpoints can be shared with other developers as part of task context.

Screenshot of the context preview page showing breakpoints in the context

In a single view, the Hudson/Jenkins connector provides quick access to status information about selected builds across multiple build servers, even when you are offline. This includes information about build status, build stability, and test failures. But one thing I realized was missing was a quick summary of how many builds are passing, unstable, and failing. This information is now displayed at the top of the Builds view and, when the view is minimized, in a tooltip, making it really easy to tell when there’s a change in the number of failing or unstable builds.

Screenshot of builds view showing summary of build statuses

This release also includes a number of bug fixes and enhancements to the Gerrit connector. Among them are support for comparing images, buttons for navigating to the next/previous inline comment in the compare editor, and a code review dashboard that lets you see which of your changes have been reviewed and whether they have passing or failing builds. The connector also remembers your previous votes on a patch set, so that posting additional comments doesn’t reset your vote. Thanks to Jacques Bouthillier and Guy Perron from Ericsson for their work on comment navigation and the dashboard.

Screenshot of the Code Review Dashboard

To help you prioritize the tasks you are responsible for, a “Show only my tasks” filter has been added to the task list, and the tooltip uses the gold person icon to accentuate those tasks.

Screenshot of the task list showing the new filter button

Tasktop Dev 3.5 is built on Mylyn 3.11, including all of the above features. This release includes a number of bug fixes as well as support for VersionOne 2013. We have also upgraded Tasktop Dev for Visual Studio to support Visual Studio 2013, bringing the benefits of a unified task list to users of that IDE.

For more information, see Tasktop Dev New & Noteworthy and Mylyn New & Noteworthy, or try out Tasktop Dev and Mylyn for yourself.

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

by Mik Kersten, 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

When it comes to Software Delivery, The E in Email Stands for Evil

by Dave West, March 27th, 2014

Dr Evil - Photo courtesy of New Line Media Most organizations will experience failed software projects. They won’t necessarily crash and burn, but they will fail to deliver the value the customer wants. In other words, the software projects will not deliver an appropriate level of quality for the time and resources invested.

The extent of failed software projects is calculated every year in the Standish Chaos report– reporting software failure as 61% in 2013. There are many reasons for that kind of project failure rate. They range from poor requirements processes, to badly managed deployment, and a collection of other issues. Many authors have written about this, from the industry changing first work by Fred Brooks, The Mythical Man Month, to more recent works by the Agile and lean communities, but I don’t wish to re-hash these ideas here. I do, however, want to point out something that causes much trouble, pain and confusion in software projects– Email when used as a primary collaboration and process tool.

Imagine the following situation…

A tester discovers a bug, he documents this bug in his tool of choice (for this example, HP Quality Center), but because it is an important and interesting bug, he also sends an email to three developers who have worked with him on previous bugs. One of those developers replies directly to our tester with notes. The tester replies, adding a business analyst who is no longer involved in this app. Said analyst forwards the email to another business analyst who replies to the tester and yet another developer. The tester, business analyst and developers all agree on a solution, but the tester does not document this in Quality Center. That night, a CSV comes out of Quality Center and is converted into a spreadsheet by the project manager who allocates the bugs to the team. The special bug that the tester and colleagues were working on is allocated to a different developer, someone not involved in the email discussion. This developer talks to a whole different set of people to build a resolution. Sounds far-fetched? It’s not. I have seen much more complex communication networks created on projects. They resulted in confusion and a general disconnect between teams. And this issue is exacerbated across the departmental boundaries of QA, Dev, the PMO and operations because email is a poor way to collaborate. Why? because the “TO” and “CC” lists vary depending on whom the sender knows. And the original bug is just a memory by the 2nd or 3rd reply. Email isolates teams rather than uniting them. In fact, I would go one step further. If email has become one of the primary ways your project team collaborates/works, I would say email has become Evil, from a project success point of view.

To quote Wikipedia, ‘Evil, in its most general context, is taken as the absence of that which ascribed as being good.’ This description accurately describes email when it’s used to drive development, resolve issues or communicate progress. Most email begins with good intentions–adding additional people, replying out of your goodness of heart–but after the first few replies, it descends into layers of confusion, miscommunication and errors.

Email is evil because it:

  1. Does not automatically go to the right people
  2. Does not always include all the right information
  3. Is easy to drop and add new people, adding to confusion
  4. Is not stored, indexed or reference-able after the fact (unless you are the NSA, but that is a whole different blog post ;))
  5. Holds no status or meta-data that allows for quick search or filtering

Maybe labeling email evil is a bit dramatic, but you get the idea. Email can easily, if not effectively managed, cause problems in your software projects. For that reason, we should reduce our reliance on using email to drive real work.

If you doubt your reliance on email, answer the following question: Can you stop using email for project related activities for one week and instead use your systems, processes and tools to get the work done?

If your answer is no, what can you do instead?

Ideally, use the tools you are meant to be using to manage the artifacts they are meant to manage. For example, a tester shouldn’t need to email anyone. The defects he identifies should be automatically visible to the right group of developers, project managers and fellow testers. Everyone should be able to collaborate on that defect in real time–with no need to send an email, or update a spreadsheet. In fact, testers and their developer colleagues should not have to leave the comfort of their tools of choice to manage their work. Comments, descriptions and status should be available to everyone in the tool they’re using.

Admittedly, the company I work for develops integration software. So I come from that world, but even if you build integrations yourself or use tools that are tightly integrated, the value of working in your tool of choice while the lifecycle is automatically managed through notification the correct people and capturing all collaboration in the context of one set of data, is massive. Miscommunication, misunderstanding and general disconnects among teams and disciplines have a huge and negative impact on projects. How many times have you thought a problem was resolved when it wasn’t because you were ‘out of the loop?’ We would find it unacceptable if our e-retailer or bank didn’t share information across processes, but we accept that our software delivery lifecycle is disconnected and relies on manual processes like email and spreadsheets. This problem is only made more acute with the adoption of Agile methods, lean thinking and dev-ops–movements that encourage smaller batch sizes, faster feedback and more team collaboration.

I encourage you to do two things:

  1. Measure the amount of time/work you are spending/doing in email
  2. Replace that with integration or use of common tools

It is time to use email for what it is intended, sending out happy hour notifications and deciding what pizza to buy at lunch.

Business DevOps is really what we want…

by Dave West, 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

by Mik Kersten, 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

Mylyn 3.10 Released

by Sam Davis, November 18th, 2013

We are happy to announce that Mylyn 3.10 has been released. This release includes a number of enhancements to improve the user experience as well as support for the latest versions of Gerrit and Hudson.

In June, Eclipse upgraded to Gerrit 2.6 in order to support a new, more streamlined IP process. This makes it much easier for committers to accept contributions to Eclipse. Unfortunately, the Gerrit connector did not support Gerrit 2.6 at that time, so Eclipse contributors had to use the Gerrit web UI. Thanks to the efforts of Tomasz Zarna and others, we were able to support Gerrit 2.6 in a service release, Mylyn 3.9.1, which was released as part of Kepler SR1. Mylyn 3.10 includes this support for Gerrit 2.6 and also supports Gerrit 2.7.

In Mylyn 3.10, we released some enhancements to the task list and task editor, including addressing some shortcomings that have bothered me personally for a long time. To improve the initial experience for new Mylyn users on Windows, by default, attachments are now opened with the Eclipse editor for that file type if one is present, or with the system editor if not, instead of opening in a web browser. This removes an unnecessary and annoying window switch and browser prompt. Without needing to configure anything, you can open attachments without leaving the IDE.

On many occasions, I have marked a task read and then immediately regretted it. Sometimes I’ve even marked several incoming tasks or a whole query read, and then realized I should have looked at the incomings more carefully first. Until now, there was no way of knowing which tasks I had marked read, meaning that I would never know what incomings I had missed. Now, I’ll be able to easily undo marking the tasks read by using the standard undo/redo mechanism.

I like to think of user interface design as a delicate balance of providing useful information and affordances without creating clutter or overwhelming users. Unfortunately, this means saying “no” to a lot of cool ideas. But one of the great things about working on an open source project is that anyone can voice their opinions, and it really does help to determine which features get released. After some debate on bugs and code reviews, some important information has been added to the task list and task editor to make it more readily available:

At the top of the task editor, just below the summary, the date of the last comment is displayed, allowing users to quickly judge the relevance of the task without scrolling down to the end of the comments.
The task list decorates tasks that have private notes with a yellow pencil icon, so that you don’t need to open the task editor to find out if there are notes.
The task list tooltip now indicates how many incoming and outgoing tasks each query or date bin contains.

In addition to supporting Hudson 3.1, the Hudson/Jenkins connector now allows you to quickly open a build in the web UI if you need information that is not available through the connector. When clicking a link to a build, the build editor opens immediately while the build is downloaded in the background. Users can click the “Open with Web Browser” button in the toolbar to access the Hudson/Jenkins web UI.

Finally, I think heavy Gerrit users will really appreciate this small change: when adding an inline comment to a review, it’s now possible to resize the dialog, and to select text in the compare editor and copy it without having to close the dialog and discard your comment.

You can find more information about the Mylyn 3.10 release in the New & Noteworthy. You can get the release here.

Mylyn 3.9: Improved Code Review Tooling

by Steffen Pingel, October 3rd, 2013

Two years ago I claimed that contributing to Eclipse is a tedious process and I’m happy to say that this no longer holds true. The migration from CVS to Git last year and the adoption of Gerrit for code reviews by many Eclipse projects, combined with the arrival of contributor license agreements (CLAs), has made it incredibly easy to contribute to Eclipse.

Gerrit is great news for contributors since anyone with an account can now propose changes as Git commits. It’s no longer necessary to attach patches in Bugzilla; changes can be pushed directly to Gerrit. In Gerrit it’s easy to work with the changes and, if the CLA has been signed, merging contributed changes only takes committers a few clicks.

I have highlighted in previous posts how the Mylyn Gerrit Connector integrates code reviews in the IDE. When added CLAs and upgraded to Gerrit 2.6 (which the Mylyn connector didn’t support at the time), I realized how much I rely on the seamless Eclipse integration. Thanks to Tomasz Zarna contributed over 20 changes and didn’t shy away from using the browser Gerrit 2.6 is now supported in the latest Mylyn service release and will soon be available as part of Kepler SR1.

In addition to supporting the latest Gerrit, Bugzilla and Hudson version, Mylyn, and the Gerrit the connector in particular, have seen a number of improvements in the last major release. The code review editors are now complemented by a Review navigator. The navigator view shows all comments in a structured view that simplifies keeping track of parallel discussion streams as code review progress.

Global comments are now embedded in the review editor, with support for spell checking, and comments can be saved as drafts and edited offline. Conveniently, the editor now also supports all patch set operations including rebase.

The Mylyn New & Noteworthy has an overview of all enhancements in the latest release which is available here.