Archive for the ‘Tasktop Sync’ Category

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

Watch Tasktop webinars

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.

Watch Tasktop webinars

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

Watch Tasktop webinars

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?

Watch Tasktop webinars

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.

Watch Tasktop webinars

Tasktop 2.7 Has Been Released

Monday, May 13th, 2013

On Friday, May the 10th, Tasktop released 2.7 for both Tasktop Sync and Tasktop Dev. This continues to demonstrate our desire to put out a major release every six months and a minor release every three months. This regular cadence helps manage scope and deliver value to our customers in a managed and controlled way. Version 2.7 was a major release with many new features, bug fixes and improvements, but I want to focus on two main themes.  The first is the release of our first PPM connector for CA Clarity PPM, the second is improvements to our IBM Rational Requirements Composer connector. Both demonstrate our continued desire to connect the world of software delivery by enabling different tools and disciplines to work from the same data and collaborate more effectively.

Support for Clarity PPM

For many developers, the world of the project office is an alien one, with its staff talking about investment portfolios, resource pools and demand management. The same can be said of the PMO when trying to understand developers who work in scrums and talk about CI and GitHub. But with the advent of faster delivery times and Agile methods, development and the PMO need to work together in more dynamic, flexible and aligned ways. That means traditional integration approaches, such as spreadsheets and email, need to be replaced with automated integration. This need led us to develop a connector for CA Clarity PPM, which enables the two teams to work together more effectively sharing work across organizational and tool boundaries. The development of this connector also reinforces our strong partnership with CA and demonstrated our support for CA Clarity Agile and CA Clarity requirements.

Building the connector has reminded us yet again that the technical side of integrating the process and data is often the easiest part. It also reminded us that getting agreement on how the artifacts flow between these two organizations is actually much harder. As we worked on the early version of the connector with a customer, it became very clear that though at the highest level the PMO and development had shared objectives, the reality of day-to-day operation was very different for the two groups. We learned a lot about how the PMO and Development can work together during this process. This learning will form the basis of a webinar titled ‘Connecting CA Clarity PPM with Development Tool Stacks from IBM, HP MS and more’,which not only will demonstrate CA Clarity PPM integrating with the development stack, but will also describe the integration patterns that make sense and the key decisions you need to focus on when building the integration. The best practices of integration continue to drive our investment in Software Lifecycle Integration, where we hope to codify and share these ideas.

Improvements to the RRC connector

As more and more people improve their requirements processes and start adopting tools like IBM RRC, it is clear that requirements can never exist in isolation and that integration is key to delivering software effectively. Requirements tools are great at improving the discipline of requirements, but without linking them to a broader ALM tool stack, the requirements start wrong and just get worse. The key to good requirements is flow and collaboration; flow, meaning that the requirements seamlessly flow between management, the business, development and test, and collaboration, meaning that every stakeholder involved has the ability to comment, discuss and more importantly disagree with the how and why a requirement adds business value. We at Tasktop are heavily involved in this dialogue and continue to improve our requirements connectors as we understand how this interaction plays out. For example, a key improvement in the 2.7 release is the ability to sync into folders between RRC and HP QC / ALM. For many organizations, a folder is more than a way to group large list of requirements; it actually includes some level of business semantics. By adding this capability, we now can share context across tool boundaries.  This is a great example of something that we learned from our customers and partners as we enable better requirements flow and collaboration with Tasktop Sync.

Watch Tasktop webinars

Choice is where it’s at ….

Monday, April 22nd, 2013

As I’ve been putting together materials for my upcoming webinar, I’ve been trying to figure out … What is the single most important thing we’ve learned thus far while “drinking our own champagne”? There have been so many lessons learned.. But what would I say is the single most important thing? Very simply, the most important lesson learned is choice. Give people choice and you will have teams that flourish. That is what we experienced in phase 1 of our journey, and we have continued to see that in phase 2 of our journey.

Our partnership with IBM forced us to re-think team collaboration from the perspective of inter-organization communication while we were implementing an outsourced testing model. We know many of our customers are attempting the same model — but how do you accommodate different tools, different processes and different styles of communication inherent in different companies? That’s where Software Lifecycle Integration (SLI) principles come into play. SLI allows for choice — choice of tool which allows for choice of process which results in better communication and collaboration. And happy teams.

But it is not without its challenges. The greatest challenge we faced in our second phase was the recognition that when data is being shared across companies, you have to be careful about what and how you share that data. Confidentiality responsibilities became front and center as we figured out our SLI strategy for the outsourced testing integration pattern. Come join me for part 2 of our series on “Drinking Our Own Champagne” and learn how we overcame these challenges — and proved again the fact that choice results in flourishing teams and great products!

When: Wed, Apr 24th, 2013: 8 – 8:30am PST, 11 – 11:30am EST
Presented by: Nicole Bryan, Director of Product Management at Tasktop Technologies
Register now: Webinar – Drinking Our Own Champagne: And the Party Never Ends

Watch Tasktop webinars

Neelan’s excuse as to why no one talks to him at parties anymore

Thursday, March 7th, 2013

Lets be honest. I dread the “What do you do?” question in a bar or party setting. If I ever have to go beyond the “business manager in a private software company” line when introducing myself, the reaction is one that, at best, is an “Oh…” More likely, the person just looks for the first opportunity to walk away. Even the “but… but… I was a professional blackjack player…” or “I helped make a really cool ebook app…” or “My daughter really loves baseball…” usually doesn’t salvage the day.

The real answer to the question of “What do you do?” is that I work for a company that provides an integration platform to connect up the tools and people that produce software from idea to coding to deployment. Our customers are some of the largest companies in the world, and in nearly all cases, they build software not for the sake of commercializing it, but rather as a means to solving a problem or driving a competitive advantage in their respective industry, from banking, to insurance, to healthcare, to retail, to manufacturing, to government. We’re helping traditional businesses turn into software delivery organizations. Cheers to that.

When you think of integration, its just not sexy. Period.

Even though we are participating at SXSW Interactive this week as a stop on the SXSW Startup Crawl, and our CEO Mik Kersten has a talk on Monday evening, the reality is that we just aren’t as cool (or as young, truth be told) as a lot of the folks who do social or mobile or cloud. We do know what those words mean but our lot is all about creating a new kind of collaborative infrastructure for software delivery. We are at SXSW because our US HQs are located in Austin and because of my love of the SXSW event, even though Tasktop doesn’t fit neatly into an event that I often joke is short for “SeXy SoftWare”.

I promised Mik that I would pitch his SXSW talk, so here is the pitch… We’re also here to demonstrate how crucial it is to create a multi-vendor platform for software delivery collaboration if we are to make the next order of magnitude improvement in our ability to deliver software, as Mik will outline in his talk Social Code Graph: The Future of Open Source. Seriously, it is a marriage of a geeky topic with cool visualizations, and I would encourage you to attend and experience some of Mik’s passion and boundless energy.

So, this blog is my feeble attempt to explain what we do and explain why it is important. I wish it was containable within 140 characters. I wish it was containable in some pithy one-liner that I could use at the bar that would result in me being the life of the party. Every time I get it to 140 characters, it sounds like some sort of marketing jargon. So, what we have at Tasktop is great business that solves a really big problem that still takes too many words to explain.

So, if your company produces software in any sizable scale, I’d encourage you to at least give this blog the ten minutes it takes to read, even if you aren’t directly or even indirectly involved in the production of software.

What is Integration?

When we talk about integration, we are talking about moving data from one system to another and keeping each system synchronized. That is exactly what we do at Tasktop. It’s all about the flow of information between the constituents who drive the creative processes around software delivery. We help companies automate the flow of information between all of their tools that are used in the production of software, ensuring that the right information is at the right place at the right time.

When you think about how software is produced, especially in large companies, it generally involves some hair-brained idea from a manager (I am a manager, so I feel comfortable making this assertion), some business analysts who have to convert that idea into a semi-sensible set of requirements, a product/project manager who must convert those requirements into a project plan, developers who get the pleasure of struggling to make it a reality, quality assurance personnel who figure out where they screwed up, and operations who determine why it won’t scale.

Generally speaking, each constituent above uses their own tools, often times from different competitive vendors. The various disciplines are often separated geographically, commonly with cultural and language barriers. The vendors are usually not interested in effective integration, as each is competing for grabbing as much of the software lifecycle as possible. Even if the products are from one vendor, they often are not integrated with each other. Adding fuel to the blaze, culturally, the different disciplines of software do not always get along. It is no wonder that, despite all of the great advancements in each silo, software projects fail or are delayed 24-68 percent of the time. At Tasktop, we do integration, specifically the integration to make information between the five disciplines of software delivery (requirements, development, testing, deployment and project management) flow between the various tools that each discipline uses. Whether you call it Application Lifecycle Management (ALM) or Software Development Life Cycle (SDLC), we are putting the “L” back into this business process of software delivery.

Why is Integration Important?

Why is moving data around between various systems something you should pay attention to? As we’ve been doing deployments of our Tasktop Sync integration solutions in enterprise situations over the past couple of years, we’ve learned that the data moving around is really just a proxy for the automation of the software delivery business process. As we kick off the deployments in our customers, we are often bringing the key representative stakeholders of the tools (e.g., QA and development) together for the first time to talk about not just their silo’d business processes, but more importantly, to talk about how the two (or more) disciplines should work together to build better software in a predictable and repeatable manner.

So what does this mean? The best way to think about this is by wondering what the world would look like when the software delivery process is not integrated. Over the past 15 years, we’ve seen each of the five disciplines focus internally as a silo. During those 15 years, each silo experienced tremendous innovations, such as Agile planning and development, Continuous Delivery, DevOps, functional programming languages, and test-driven development. The challenge was that as each of the silos optimized, the valleys between them grew ever deeper. Testers would often batch up all of the defects they discovered in a spreadsheet and share the defects every month or six weeks with the development team. Requirements were often not tied back to the activities that developers did and the tests that QA professionals ran, so a change to a requirement was often not caught. Reporting and analytics across the entire software delivery value chain was impossible without significant manual work. As more industries faced new regulations, increased reporting requirements, compliance from their stakeholders, and demands for more governance, the ramifications of not meeting these needs had real financial consequences. No matter what industry you are in, having an integrated software delivery chain will ensure higher software quality, faster cycle times for application development and delivery, and less rework.

Another reason why integration is so important is because it connects up different worlds. Over the past ten years, we’ve seen some pretty dramatic changes in the power of the individual. Whether it was populism driven by Apple devices being purchased by the individual and brought into the workplace, even though the individual had to pay for it out of their own pocket, or it was the freedom of inexpensive tools that an individual could easily purchase via a credit card (e.g., JIRA, Github or free e.g., open source ala Hudson/Jenkins, Git, Bugzilla, etc.), more and more software development had the inmates running the asylum. Even though Central IT groups or management had mandated the use of a particular tool stack or technology set, individuals were defying those mandates and going with the tools or devices that made them the most productive and effective in their jobs. So, one of the big problems that integration allows our customers to solve is to connect up the world of the individual, where the newest, coolest, most productive, least heavyweight usually wins the day, with the needs of the enterprise and what were viewed as heavyweight tools and technology that were trying to manage risk, gain visibility, ensure governance and compliance, and generally protect the organization. You can see one example of how Tasktop does this in the JIRA / QC webinar.

Hope to See You at SXSW or a Watering Hole Soon

Integration may not be sexy, but it’s now the main bottleneck that we as an industry have on scaling our collective ability to delivery software by 10x.

So if you see me out and about this weekend at SXSW, I am happy to talk about TechGirlz, or my kids, or Capital Factory, or DreamIt, or bootstrapping a business to 50+ people, or professional blackjack, but I hope you also ask me about integrating your software delivery stack. I promise I won’t scare you too much.

Watch Tasktop webinars

The Case for Integration

Tuesday, March 5th, 2013

Putting the L in ALM – Making the case for Lifecycle Integration

I think everyone agrees that software delivery is not an ancillary business process but is actually a key business process, and the ability to deliver software faster, cheaper, and of a higher quality is a competitive advantage. But delivering software is difficult, and if you believe the Standish Chaos report, anywhere from 24 to 68 percent of software projects end in some form of failure.

Even the criteria for success has been questioned by many, as ‘on time, on budget, delivering the functionality requested’ can still mean software that fulfills requirements but adds no business value. Billions of dollars a year are spent on software development tools and practices in the desire to increase project success and reduce time-to-market. Each year, development, testing, requirements, project management and deployment roll out new practices and tools. Many of these additions bring value, thereby increasing the capability of each individual discipline. But ultimately, the problem is not the individual discipline; the problem is how those disciplines work together in pursuit of common goals and how the lifecycle is integrated across those disciplines.

It has been a year since I joined Tasktop, and during numerous customer visits and partner discussions, two things are very clear: 1. the landscape of software delivery tools and practices is going through a major change, and 2. to be effective in software delivery you need to automate flow and analytics.

The ever-changing face of software tools and practices

Add Agile, Lean Startup and DevOps to a large amount of mobile, cloud and open web, and not only do you have the perfect book title, you have all the ingredients necessary for a major change in the practice of software delivery. Agile and Lean encourage rapid delivery, customer feedback and cross-functional teams focused on delivering customer value. Mobile and cloud are changing the landscape of delivery platforms, architectural models and even partner relationships. Never before have we needed to build flexible development processes that encourage both feedback and automation. Imagine spending three months writing a specification for your next mobile application when your competitors deploy new features on a daily basis. Imagine not connecting your new sales productivity application to LinkedIn, where your sales people have all their contacts. Our development approach needs to not only include partner organizations and services but also deliver software at a much higher cadence.

Automation of Flow and Analytics (reporting) is key.

I have noticed a strange relationship between increased speed, reporting and integration. When you increase the speed of delivery, traditional manual processes for reporting and analytics stop working or become an overhead. For example, one customer spent two days compiling the monthly status report spreadsheet across development, test and requirements. This two day effort required meetings with numerous people and emailing the spreadsheet around for comment and review. When the organization adopted two week delivery sprints, this work was an overhead that no one wanted to endure. Now the company had a choice: drop the status report, or look to an automated solution. Because more frequent releases meant the need to collaborate better, they opted for an automated solution that connected the test, development and requirements tools, providing a report that described the flow of artifacts among these three groups.

The automation not only resulted in creating the report but also improving the flow between these different disciplines. Suddenly there was clarity as to the state of a story or when a defect should move into test. This clarity was avoided in the manual approach, which left large amounts of ambiguity. The report drove the creation of automated flow, which resulted in a better process, which then fed the report with better data.

That means there is a sixth discipline in software delivery

Lifecycle Integration is emerging as a key discipline for ALM. It provides the glue that enables the disconnected disciplines of requirements, development, testing, deployment and project management to connect. It unifies the process and data models of the five software delivery disciplines to enable a unified approach to Application Lifecycle Management (ALM).

Without integration, many of the disconnects go unrecognized, and the flow between groups is never optimized. The larger your software delivery value chain, the more pronounced the impact of these disconnects. Factor in external organizations, either through outsourcing, application integration, service usage or open source, and these impacts can mean the difference between not just project, but business success and failure.

Perhaps we in the software industry are suffering a bit from the ‘cobbler’s children syndrome,’ with integration being a first-class citizen in the traditional processes we have integrated for our business clients for years. But the time is right to apply these lessons and build a discipline around lifecycle integration for the practice of software delivery.

Watch Tasktop webinars

Tasktop 2.5 Released, keeps up with the RTC 4.0, HP AgM and Microsoft TFS 2012 Joneses

Friday, December 14th, 2012

Agile has come of age, gone mainstream and, as evidenced by recent releases from our partners, the ALM landscape has permanently changed. This fall we saw the release of TFS 2012, RTC 4.0, and last week HP’s Agile Manager (AgM). These tools provide large-scale software delivery organizations with the latest and greatest features for each of the software delivery roles that they support. Tasktop 2.5 release is a roll up of new Tasktop Sync and Dev functionality that we now provide in order to allow organizations to make the most of these tools when adopting them for heterogeneous ALM environments. We have worked very closely with each of our partners in order to ensure that Tasktop is able to provide it’s real-time connectivity and collaboration flow for stakeholders whose roles span individual tools.

Tasktop Sync now has full support for Rational Team Concert 4.0. Our partnership with IBM was expanded recently by way of IBM OEM’ing Tasktop Sync (called IBM RLIA Tasktop Edition) in order to support their customers’ integration needs. Tasktop Sync ensures that those deploying RTC into a heterogeneous environment get the benefits of RTC across the myriad of tools being used for end-to-end software delivery.

While Microsoft provides one of the most vertically-integrated ALM offerings, the reality of today’s software delivery is often multi-platform and multi-vendor. This means that some developers will be building the back-end with .NET and Azure with everything tracked in TFS, while the mobile ASP is being built by another team working in JIRA, and the whole lot is being QA’d and requirements managed by HP ALM/QC. Sync now supports TFS 2012, including the hosted version of TFS, which expands our support of cloud hosted integration end-points.

HP just released a brand new, cloud hosted Agile planning tool called Agile Manager. Tasktop Dev, OEM’d by HP as ALI Dev, has been extended to support Agile Manager, and can be seen showcased on stage at last week’s HP Discover conference (see Dave’s post for more on that). This means that developers get the first rate Eclipse and Visual Studio IDE experience for this new slick Agile project management tool.

In our role as the “Switzerland” of ALM, it has been exciting to see Tasktop work closely with each of these vendors, as well as our other partners, each of whom is defining a different angle on the tools that enable Agile software delivery at scale. As always, our goal is to create the task-focused infrastructure that supports real-time flow of information between users collaborating across this new breed of tools.

Get Tasktop Sync 2.5

Watch Tasktop webinars