Tasktop

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.

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.

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!

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.

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.

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

Today the IBM Rational Lifecycle Integration Adapters Tasktop Edition appeared on the IBM price list. This OEM version of Tasktop Sync makes the technology broadly available to IBM clients using Rational Team Concert (RTC), who can now get all of the benefits of Tasktop Sync’s real-time and collaboration-centric ALM integration infrastructure. This helps IBM clients to successfully unify heterogeneous tooling environments with RTC capabilities.

Tasktop’s mission is to connect the world of software delivery by providing the cross-repository integration and infrastructure tools that weave together the numerous Agile, enterprise, and open source Application Lifecycle Management (ALM) tools present in today’s software delivery stack. To achieve this, Tasktop has been working very closely with the ALM community to help define the APIs and standards, such as Open Services for Lifecycle Collaboration (OSLC) and W3C Linked Data, which form the boundaries of the software value chain within your organization. Integration has become the main bottleneck to connecting the software lifecycle, and Tasktop has emerged as the “Switzerland of ALM”, with Sync becoming the equivalent of an Enterprise Service Bus for artifacts of the software delivery process.

We are thrilled to have this relationship with IBM to reduce the friction of getting the benefits of Tasktop Sync to the growing number of IBM Rational clients leveraging a rapidly evolving portfolio of enterprise Agile and ALM capabilities. With the Tasktop Sync infrastructure in place, RTC clients will be able to collaborate directly with other parts of the lifecycle, ranging from developers using lightweight issue trackers like JIRA and Bugzilla, to software development and testing suppliers using HP ALM or Quality Center. And the organization will get that critical unified traceability across the heterogeneous toolchain provided by RTC. Tasktop Sync is rapidly becoming the tool of choice for connecting software silos within the firewall and across the enterprise software supply chain.

The Tasktop and IBM relationship started during my PhD thesis, when Erich Gamma, a member of my thesis committee, one of the RTC architects, and I started to see how primary a role tasks (aka “work items”) had in connecting ALM artifacts. With tremendous effort going into creating the new systems of record for Agile and large-scale software delivery, which eventually led to RTC and the other modern ALM capabilities, we realized that Tasktop’s big opportunity was in using our common Mylyn-based model for weaving the various ALM systems of record together. That’s what developers see when they open up Tasktop Dev or Mylyn, and what the Sync bus is connecting when deployed in your ALM stack. Today we are officially connecting those dots by expanding our OEM partners to include IBM.

View the IBM product offering details, IBM product page or contact us to learn more.

In 1995 the Standish Chaos report cited the lack of good requirements practices as the principle reason why requirements fail. Since 1995 our industry has strived to improve the practice of requirements with approaches ranging from the Rational Unified Process to Scrum techniques such as storyboarding and JAD sessions. But there is still one frontier left to cross. That frontier is the ability for practitioners to access requirements in the context of their different tools / disciplines. For example, a developer seeing requirements in their IDE or a tester getting access to the requirements in their test tools. Improving the discipline of requirements only goes so far without the ability to make these requirements available to everyone working on the project. Availability is not just about communication and comments, but also includes context to the requirements and updates the process associated with the requirement.

With Tasktop Sync’s 2.4 release, we have extended our integration ecosystem to include requirement tools, allowing software developers, testers and project managers within their tools to access the same requirements that the business analyst or product owner is working on in their tool of choice. To put this into context let me tell you a story about a project that Tasktop worked on with a vendor where requirements were held in two disconnected systems and the pain it caused us. Of course, I have changed the names to protect the innocent (or guilty for that matter).

Time for a bit of dog fooding…

The project was a simple integration project between Tasktop and Vendor X. The Vendor was developing some additional capabilities to their tool and we were providing integration between their tool and the wide ecosystem of tools we support. In other words, a project we have done many times before, and have a lot of experience with. Because of time constraints and not yet having Vendor X’s integration available as a Sync end point, we did not use our own technology to connect their requirements tool to our development tool. In the past we, have bootstrapped on almost all of our ISV partners’ solutions when delivering an integration the moment it was showing tasks. Instead, we agreed to the practice of sending a spreadsheet every week to describe the progress of work and discuss any dependencies. Everything looked like it was working fine. Progress was being made and both their development and ours was running on schedule. That is what we thought until testing got involved.

Both our companies have testing teams, with Tasktop’s testers using the same tool as our developers to log defects, while the vendor’s team uses a different tool. Suddenly chaos started creeping into our project. Things that we assumed were working and that we understood were being debated. Defects on the requirements started popping up and both teams started blaming each other. The spreadsheet, which was used to discuss the work suddenly, became a thing of terror and argument. And emails started flying around to resolve issues and problems. Often it was hard to tell what the true state of the project was without searching through emails, the spreadsheet and your own defect and requirements system. The pain level on the project reached epic proportions and we almost missed the release date, a hard thing to swallow for a team that prides itself at always delivering on time. We did deliver, but it required heroic management by both teams and relied on two people keeping everything in their heads. Ironic that a company that helps its customers to integrate their ALM systems of record did not follow their own advice. Version two of the project did not make the same mistake with all three systems being sync’d, allowing our tools tracker and their JIRA and HP QC systems to be integrated. Email is only used now to remind people to look at these systems and for a regular ‘thank-you’. We learnt the following key points:

1. Ensure that you have one view of the truth even if it is in two or three systems. The overhead of managing a spreadsheet in addition to each organization owning a system of record was too much for both our teams. By getting both teams to work on the same stories, even if they are in two different software tools, it helped us ensure that everything was on track and many debates about what version of the truth can be negated.

2. The “e” in email stands for “evil”. Replace the heavy use of email between the different teams with a real system of record. That means that the number of emails can be used as a measure of system success. The larger the required number of emails the less the system is working. Emails seem like a simple solution to collaboration and communication, but too often emails are answered out of order, different people are emailed and there is no way to get a true picture of the truth.

3. Spend time up front even if you are very smart to define the flow. We have been building integrations for years, and so thought that we did not need to spend time creating a working system with the vendor up front. But actually deciding on the process flow, and resolving process issues such as what we mean by BP1 or Priority A allows for a much more simple life. I am not saying that disagreements will be removed, it is a software project after all, but at least you will be arguing about the right things.

4. Get real time information. The weekly spreadsheet and email became slow, with teams looking for other processes to get the right information, and because of time zone differences those processes often meant yet more email. By connecting the systems in real time our two companies created a continuous communication model. Also because the comments and discussions were being held on the original stories we had one place to look for history.

The cynical amongst you are saying “well that is a great story to sell your product” and yes you would be right, but there is nothing better for a product company than to experience the same pain as their customers. But immaterial of if you use Sync or just adopt one tool throughout your organization the value of concentrating on flow up front, and putting the process front and center is immense. Adding requirements to the Tasktop Sync story allows you to extend the flow into the requirements processes and helps to ensure that requirements are not to blame for project failure.

If you’re interested in hearing more from me and others on the topic of Agile and how traditional requirements management has created a world of Water-Scrum-Fall, see the EclipseCon 2012 Analyst Panel with myself, Melinda Ballou of IDC and James Governor of RedMonk.

In Total Quality Management, the 1-10-100 rule states that prevention is 10x cheaper than correction, and 100x cheaper than failure in the field. We usually apply this principle to our thinking around defects and as a driver for continuous delivery and feedback loops. However, in much of the Agile discourse these days, the traditional requirement gets left behind.

Development has been transformed, from the bottom up by open source and inexpensive tools like JIRA, and from the project management level down by the Agile movement. But in large-scale software delivery involving very complex products and supply chains, requirements are the tasks that connect strategy to shipping software. The trouble is that the tools that we use for requirements management are completely disconnected from the modern Agile delivery process.

Consider a requirement to add a web service API to an app. Sounds great when expressed in Microsoft Word with direction from the CIO. After being passed to development, SOAP technology is selected on the merit of being present in other parts of the product line. A few developers comment on the corresponding user story that SOAP is inefficient and could cause serious CPU overhead, but both the business analysts (BAs) and the Ops folks are well out of the loop as they never log into JIRA where the discussion is happening. The solution is deployed, passes basic scalability tests, then after going into production it becomes clear that the SOAP solution will not scale to support the projected user base without a massive new infrastructure investment. So three months after the requirement was defined, the business analyst gets to realize all of this, learns a new acronym (REST) and another round of implementation is scheduled for the upcoming sprints. That’s the 100x cost scenario that we see all too often. Had the BA seen some of the comments in JIRA, a lot of waste could have been prevented.

This problem was partly addressed a decade ago with the Rational Unified Process (RUP), which created a homogenous Application Lifecycle Management (ALM) stack from requirements right down to development. But that approach constrained developers to the point where the Agile and lightweight ALM tool rebellion transformed the landscape. We now know that an efficient application lifecycle is capable of leveraging best-of-breed tools, with stakeholders such as Developers, Business Analysts, Project Managers and Testers working in the individual tools that make them most productive. Until today, only a few brittle point-to-point integrations existed between requirements management tools and the rest of the ALM stack. With today’s release of Tasktop Sync with integrations for IBM Rational Requirements Composer (RRC), IBM RequisitePro (ReqPro), CA Product Vision, and improvements to our existing integrations for HP ALM and QC Requirements Module as well as Accept 360, requirements are now a first class citizen that can span the lifecycle.

While the new support for sync’ing requirements is the biggest part of the story of our ongoing quest to connect the world of software delivery, there are many more highlights to the Tasktop 2.4 release, including major new features for ALM integration administrators such as a web dashboard for monitoring and IBM ClearQuest support. To learn more see:

• Tasktop Sync 2.4 New & Noteworthy
• Tasktop Dev 2.4 New & Noteworthy
• New CA Agile Vision and Product Vision Connectors
• New RRC Connector
• New ReqPro Connector

We are pleased to announce a new partnership with CA to deliver OEM versions of both Tasktop Dev and Tasktop Sync for CA’s Agile Vision and Product Vision products. Over the last decade CA has built a reputation for delivering tools that enable better management of projects and programs. Their Agile Vision and Product Vision products provide focus on visibility, planning and requirements management for projects that require strong customer orientation and speed to market.

These products act as the beach head to CA Clarity, the market leading PPM tool. This allows teams to work in an Agile way whilst integrating into a broader portfolio view managed by CA Clarity. Tasktop Sync and Tasktop Dev for CA Vision extend that story into a broader development ecosystem. Through Tasktop, developers working within their IDE can directly access CA Vision artifacts and connect those artifacts with other development tools used in testing or deployment.

The solution enables customers to:

		Use real-time traceability, visibility and reporting across diverse third-party tools for cohesive management of software projects in heterogeneous IT environments
		Report on accurate development status and time tracking information collected at the source and rolled up to Agile Vision and CA Clarity
		Employ enhanced developer experience and productivity tools for CA Agile Vision developers
		Connect with other ALM products from vendors such as Microsoft, IBM and HP
		Collaborate with distributed teams and tools
		Reduce ALM deployment risk by avoiding rip and replace strategies and extending the life and ROI of existing ALM investments

The partnership with CA continues to re-enforce Tasktop’s mission of connecting the world of software delivery. Over the coming weeks we at Tasktop will continue to post more information on how you can take advantage of this OEM.

The press release can be found here.

Contact us at info@tasktop.com for more information about the new CA integrations or feel free to reach out to me at dave.west@tasktop.com if you have any questions.