Archive for the ‘Tasktop Sync’ Category

Tasktop Teams up with Appfire – A Leading Atlassian Platinum Expert

Wednesday, September 17th, 2014

We’re delighted to be kicking off a new partnership with Appfire to more effectively deliver DevOps integration to the Atlassian JIRA community. Atlassian has always done things a little differently from other vendors in this space. For example, while most companies’ top leadership wear suits, at Atlassian you can identify the most senior people by their Converse sneakers and hoodies. Another way Atlassian operates differently is by offering an almost entirely self-service model with no salespeople. Yes, Atlassian is dipping its toes into the world of sales with new Enterprise Advocates and Technical Account Managers. But there are currently only 7 of these folks in a 1000+ person company with a massive customer base and they are just scratching the surface.

So let’s say you’re a big bank with 60+ instances of JIRA and you need a little more help than just purchasing the software off the website with a credit card. Where do you get enterprise-level consulting to make this work? This is where the Atlassian Platinum Experts come in. The Experts are companies that partner with Atlassian to provide enterprise sales and services for large customers. And Appfire is among the very top providers for the Atlassian community.




Me and George Lannan from Appfire at Atlassian Summit 2014

Because Atlassian and their customers do things a little differently, it makes a lot of sense to partner with an organization that knows both the products and the community inside and out, including the dress code. Our new partnership with Appfire will make it easier for this community to discover and deploy Tasktop integration technology. More importantly, we’ll work together to help customers benefit from the ability to connect JIRA with the rest of the enterprise development tool stack without ripping and replacing existing investments. Exciting times.

For more information check out the news release or contact us.

CAST 2014 Retrospective

Friday, August 29th, 2014

I recently had the pleasure of attending CAST 2014, the annual conference of the Association for Software Testing, a conference that Tasktop sponsored. If you couldn’t attend the conference, you can watch some of the sessions and get some of the flavor of the conference in the comfort of your home or office via the Association for Software Testing’s YouTube channel.

I’m a proud Tasktopian and wore my Tasktop shirt every day. Since there were no areas reserved for sponsors, that was the only way folks could find me to ask about Tasktop and how we help testers … more on that later. This blog is really about the art and science of testing (which was the conference theme this year) and some of the other controversies that exist within the testing community.

In truth, the thing that’s interesting about CAST is the level to which there is active discourse on the controversies within the testing community. If you’re not immersed in that community, you may think it a very homogeneous discipline. It is far from that; it is LOADED with controversy and differing opinions.

There were many sessions on the central topic: “The Art and Science of Testing.” There are folks that believe that testing software is an extension of the liberal arts, heavy on the use of skills learned by studying psychology, sociology or philosophy… such as developing and using various heuristics. And there are practitioners who feel strongly that testing software is best left to those that have studied engineering or computer science… using the knowledge of how the application was constructed to approach the challenge of testing it. But that was the least of the controversy!

There was quite a bit of heated discussion around a software testing standard being proposed by ISO (the International Standards Organization) and IEEE (the Institute of Electrical and Electronics Engineers). ISO/IEC/IEEE 29119 proposes to define “an internationally-agreed to set of standards for software testing that can be used by any organization when performing any form of software testing.” But much of the conversation at CAST was firmly against this standard, as embodied by a petition to suspend the standard’s publication. It can be difficult to represent a consensus against a particular idea, but it seems that the fundamental concern is that the implementation of standards can easily create dogmatic adherence to a particular process. And the view of software testing as a definable process, flies in the face of the “context driven testing” school of thought. According to CDT, there are no particular best practices that fit every situation – what is required is the expertise of a professional software tester that can bring to bear the right techniques for each particular situation.

This controversy lead right into the discussion around automated testing: with some practitioners claiming that test automation signals a demise of the professional tester and some practitioners with more moderate views. The moderates propose that test automation has important applications, but agree that it is not a panacea. In particular, it’s no silver bullet for overcoming the challenges inherent in organizations seeking to increase the velocity of release cycles through Agile or DevOps initiatives.

One “controversy” that tends to be fairly universal no matter what practitioner-oriented conference I attend, is the schism between testers and developers.

To be honest I never understood the developer – tester antipathy. Everyone on the team has a common goal to deliver the right software, on-time, with the agreed-upon level of quality. As a developer, I never wanted to be viewed as the person who delivered “crap code.” I never checked in code late Friday night, enjoying my weekends, while others were left dealing with the fallout from a broken build. But more selfishly, I never wanted to be awakened in the middle of night to fix my broken code. I tested my code and helped my tester buddies, because to me they were an equal part of the team and, selfishly, the line of defense between me and a 3AM wake up call.

So, it actually gives me great joy that Tasktop helps bring developers and testers together by eliminating some of the tedium introduced because testers and developers use different tools to manage their work… making the little time they have to collaborate “face to face” even more productive and (gasp) enjoyable. The fact of the matter is, most testers DO use tools to manage their plans, test cases (when appropriate) and the defects they find. And these tools are often not the same tools that their dev colleagues use to triage, fix and report the status of defects. And the same is true for the development and management of requirements and user stories.

Tasktop Sync integrates these tools, allowing everyone to use their tool of choice, while collaborating on project artifacts. Moreover, Tasktop Sync can help testing teams turn their existing tools into the “single source of the truth” of project health. (To learn more, read the white paper).

There will never be a shortage of differing opinions among practitioners in software development and delivery. But presumably we’re all in agreement that working together to solve our mutual challenges HAS to be more effective than working at odds.

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 http://tasktop.com/connectors.

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.

RequirementsTraceabilitySLIpattern

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.

zendesk-versionone

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