Archive for the ‘Tasktop’ Category

Tasktop 3.6 released: IBM DOORS, Jama, integrating “things”

Monday, July 21st, 2014

Nothing catches the technologist’s eye like an elegantly designed gadget, with software and hardware flowing together in design harmony. The trouble is that traditionally, the way we build software and the way we build physical things have had very separate lifecycles. The V-Model of systems engineering provides the predictability needed to assemble little things into bigger things along a broad chain of bills of materials and suppliers. Contrast that with Agile development and Continuous Delivery, where constantly shipping the entire system. For the few companies that have managed to wire together their own internal processes for making hardware and software work together, the results have been spectacular.

For the past couple of years, customers have been asking us to extend the integration that we’re known for to their hardware systems and teams. With today’s announcement of Tasktop 3.6, we’re thrilled to announce our first step in this with Sync support for the most established product requirements management tool, IBM DOORS, and one of the newest and most innovative, Jama.

Tasktop - Jama to JIRA Sync

Over the past two years, Tasktop Sync has transformed from ALM integration technology to an end-to-end DevOps integration bus. We’ve watched in amazement as some of our largest manufacturing customers created DevOps environments for hardware. Service virtualization is replaced by hardware simulation, continuous integration spans to hardware testing, and new software can be deployed to things that we drive. While some Tesla aficionados were annoyed when their cars were no longer as low to the road as they might like, the ability for Tesla to push out such updates has signaled the sign of things to come. DevOps is being extended to physical product delivery, and the lifecycle of hardware and software will become increasingly connected. For this to happen, we need to create a new software-centric backbone for the product lifecycle. One which supports the Product Lifecycle Management (PLM) backbone while supporting the continuous delivery of software and firmware. The first infrastructure software for that backbone is the new release of Tasktop Sync.

It will now be possible for organizations to have a single view of requirements in DOORS and Jama, synchronized in real-time across all the leading Agile development tools that we already support. This is the magic of Tasktop Sync and our integration factory. Once Tasktop’s integration bus is extended to understand a new concept or set of artifacts, such as a hardware requirement, and a connector that has full API-based read and write access to a repository is created, and our integration factory is updated to continually test that integration against all others we support, we enable the seamless flow of information across yet another tool boundary. But the Holy Grail for systems is not just the benefits of collaboration; it’s end-to-end traceability between requirements, defects, and the hardware and software that implements them (to the delight of users). And, the only way to automate this traceability is to integrate the stakeholder tools. That’s exactly what we’re doing, all thanks to the new Artifact Relationship Management support that we release with Tasktop 3.6. Because the cost of not having traceability might be front page news in the form of car recalls and airplane delivery delays.

Tasktop 3.6 also includes a set of incremental improvements to help you get the most out of Sync. Most notable: the Sync bus has been extended to support Test Case synchronization. If you’re a ServiceNow user, you’ll be happy to know we now support Sync to all “task” artifacts, which dramatically extends the number of ServiceNow tables that you can connect to your software delivery and DevOps activities. In addition, we’re releasing time tracking synchronization for Rally, and updates to integration Microsoft VS Online, HP ALM 12, IBM RTC an RRC 5.0, Rally OnPrem, VersionOne 14 and Bugzilla 4.4.4. For the full list of improvements see the New & Noteworthy.

Tasktop - Rally to CA Clarity PPM Time Tracking

As always, we look forward to seeing you deploy this new functionality for use cases that we have not yet imagined. When we first created Sync, we didn’t realize that it would soon be getting deployed for connecting the software supply chain of one of the world’s leading car manufacturers. We can’t wait to see how you deploy this new functionality in your systems engineering and Internet of Things (IoT) efforts, and to hear your thoughts about the other systems engineering and Product Line Management (PLM) tools that you want us to support in upcoming releases. So please stay in touch!

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.

IBM Innovate: DevOps grows up. Agile loses weight. Collaboration gets its groove back

Tuesday, June 10th, 2014

Last week, Tasktop had a wonderful week at IBM Innovate in Orlando. We were honored by the conference organizers who invited us to present, or co-present, in eight sessions. We were delighted to win the IBM Business Partner award for Innovation in IT Development . We’re especially proud that this was the second year in a row that we won this award. We had terrific meetings with our customers, potential customers and IBMers. Aside from the fact that I’m responsible for managing Tasktop’s conference presence, as a former member of the Rational team… and later as a former IBMer… going to Innovate is a bit like coming home. It was wonderful seeing how many of my former colleagues are still with Rational… and better yet, were willing to spend a little time with me to catch up.

The Tasktop Crew at Innovate

Of course we talked about the Good Old Days. But we also talked about the changes in the industry. Yes, I’m a marketing weenie… but the reason I love my job so much is that as a former developer (and engineering manager) the act of crafting software has always been, and always will be, near and dear to my heart

For me, the Biggest Thing at Innovate was that DevOps has grown up. In its original incarnation, the idea behind DevOps was that the entire software delivery process would go so much better if, instead of lobbing applications over the wall at Operations, there was some (pre-delivery) collaboration between the Development and the Operations teams. As bad as long waterfalls were, they were made worse by a discontinuity between the team building the software, and the team responsible for its care and feeding in production. Perhaps, I hoped, if the two teams collaborated right from the start, the promise of Agile would flow all the way into Operations.

But, I was so very disappointed when the movement seemed to narrow down to only Continuous Delivery/Continuous Integration and the tools required to automate the delivery of code to production. Sure, that’s better than just tossing a build at Operations and hoping they can figure out what to do with it, but REALLY… what happened to the COLLABORATION between the Development and Operations teams?!

Instead, Continuous Delivery seemed to be all about getting the bits into production. But unless two developers are working on the same sub-system, there isn’t all that much collaboration on the code per se. The real collaboration is around all the development artifacts… the requirements/user stories, models, defects, plans… and no one seemed to be talking about that. Until now. Finally, DevOps in the broader sense, is coming into its own.

I’m happy to report that during this Innovate, the notion of DevOps took center stage. The sessions were divided into three “streams”:
· Innovation – emerging technologies

· Continuous Engineering – the delivery of complex and connected products (where “products” are a combination of software and hardware), and

· DevOps!!

Oh sure, the words “continuous delivery” were used during the DevOps stream, but not as the sum-total of the conversation. In this incarnation of DevOps, continuous delivery is an outcome of using lean and Agile principles, of continuous planning, continuous testing and of continuous collaboration! Finally, the DevOps movement is morphing into what it could have been from the start.

And speaking of morphing, over the years, Innovate itself has changed and evolved. When I was with Rational, our user conference was called RUC (the Rational User Conference). After we were acquired by IBM, it became RSDUC (the Rational Software Development User Conference) and had about 2,500 attendees. This year there were 4,000 attendees at IBM Innovate. All along, this has been a user conference for Rational products. But next year, there is yet another evolution. IBM plans to meld several of their conferences together. We don’t know the name yet, we only know that it will be in February, in Las Vegas, with an expected attendance of 20,000. With several of their Software Group brands working together (some that concentrate on Development and some that concentrate on Operations), I’m sure there will be yet another evolution on IBM’s take on DevOps. And I’m looking forward to another terrific week.

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 Dev 3.5 and Mylyn 3.11 Released

Monday, April 14th, 2014

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

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

Screnshot of Find in the Task Editor

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

Screenshot of the context preview page showing breakpoints in the context

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

Screenshot of builds view showing summary of build statuses

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

Screenshot of the Code Review Dashboard

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

Screenshot of the task list showing the new filter button

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

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

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

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

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

Thursday, March 27th, 2014

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

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

Imagine the following situation…

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

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

Email is evil because it:

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

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

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

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

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

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

I encourage you to do two things:

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

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

Cheers from Tasktop Boston’s New Office!

Friday, September 27th, 2013

Finally Tasktop Boston has an office!

As a company in the “growth phase” Tasktop has remote employees all over the world, which is particularly beneficial in terms of our customer meetings, speaking engagements, and conference participation. Tasktop is pretty unique in that sense; we are able to pursue numerous international opportunities even though we are only a company of about 60 people. But we are at the point where we are starting to think about which of our remote locations makes the most sense for brick-and-mortar expansion.

Boston was a pretty obvious choice for several reasons. While we are headquartered in Vancouver, many of our customers are on Eastern Standard Time. Here we are also able to act as the “middle time zone” if you will, for our colleagues and customers in Europe. Boston is also known for its association with start-ups and tech companies. It is a unique environment; the city and suburbs are very supportive of small companies’ growth, and local employees tend to be ambitious and energetic and definitely practice the “work hard, play hard” mentality.  Based off that alone, Boston was a perfect cultural fit for our small company! We’ve grown to four employees out here in the past year. We are not a big group (yet), but with that kind of growth, I’m sure there will be more Boston Tasktopians soon!


The “office location courtship” was a unique process for me. Every office looked GREAT on paper, and when heading over for each building tour, I found myself hoping that this would be “the one” so that we could set our roots down somewhere!  I quickly realized that no office was going to be the perfect space I had pictured in my mind.  We weighed the pros and cons and learned what qualities we could and couldn’t live without. Tasktop is a pretty social company, so we wanted to be in an office with a lot of activity, and being in the midst of other start-ups would be ideal.  With some help from the City Economic Development Department, we finally found a location that fit our needs well and signed on space in the Alewife section of Cambridge, Massachusetts. Sure, we had to give up the glamour and prestige of a Harvard, Kendall, or Back Bay address. But we are still extremely close to the city and are in a brand new office, a beautiful space to call our own, and that’s all we need! Alewife is definitely an up-and-coming area, especially for tech companies, so we look forward to seeing how the area changes as the construction projects progress! Who knows, maybe we’ll look back in ten years and think, “We were working at Alewife before it was the cool place to be!”

Day One at the office was last Monday, and we moved in so seamlessly that Betty, our VP of Marketing, remarked, “I’m worried because this was just too easy.” Sure enough, on Day Two we realized that we were going to have some serious kinks with our internet. I don’t come from an IT background, but let’s just say that I’ve become pretty well-informed on internet speeds and what will and will not make you a fully-functioning employee.  We (hopefully) solved the problem earlier this week, and we are quite relieved to be able to resume business as usual.

Dave, Betty, Kristie, and Katelyn celebrate the opening of our newest office

Several “firsts” in the new office were particularly exciting for me: our first All-Company meeting in the same room together, and our first Happy Hour! Our colleagues were so excited to get the video tour and see pictures of our new space.  Tasktopians are serious team players, so I was often asked for updates on how the office search was going for us.  They are so thrilled that we were able to find such a great office space and are interested to see how we make it our own as we get comfortable. In true Tasktopian champagne-toasting fashion, we celebrated our first Happy Hour at the conclusion of our first successful week in the office.  I always look forward to these get-togethers with my colleagues because they provide a different environment to get to know each other outside of working hours.  Of course it was the highlight of my week!

I’m so happy to finally be in an office with my coworkers. I can say with absolute sincerity that I have established some great friendships with my colleagues in Vancouver and not many people can say that they have made connections like that over video conferencing alone! But after working from home for almost a year, I am thrilled to see what bigger and better things we can accomplish while sitting side by side. Tasktop Boston is about to take over the world, and you’re hearing it here first!

Enjoy more integration options with Tasktop Dev 2.8

Tuesday, September 3rd, 2013

Tasktop Dev 2.8 was released on August 8 and has several interesting enhancements to note.

This release introduces new capabilities that leverage Tasktop Sync to provide new SCM traceability capabilities across disparate tools. Imagine ACME co. has a development team that has adopted HP ALM. They’ve also adopted HP Application Lifecycle Intelligence (ALI) which includes SCM integration and Tasktop Dev (OEM’d by HP as HP ALI Dev). When ACME’s developers commit code, ALI provides full traceability between the code and defects or requirements managed with HP ALM. All is well with the world until ACME acquires a subsidiary that uses JIRA and wants to integrate it into ACME’s existing infrastructure. Now, code committed against JIRA issues is no longer visible in HP ALI reports, wreaking havoc on the unified visibility and reporting ACME had been getting from ALI.

Commit Traceability

Not to worry, ACME can restore order with Tasktop Dev 2.8 working in concert with Tasktop Sync. By synchronizing HP ALM with JIRA, each JIRA issue becomes associated with a corresponding HP defect or requirement. When committing code against a JIRA issue, Tasktop Dev 2.8 automatically inserts the corresponding HP ID into the commit message. This establishes the link between the code and the HP artifact, thereby restoring the HP ALI traceability and reporting ACME had come to rely on.

Other key improvements for Tasktop Dev 2.8 include support for Tasktop trims in Eclipse 4 such as the working set trim, web search, starred list and task timing counter.

E4 Trims

With the Gmail Connector, developers can bring messages with a given label into the integrated Task List, providing a single “inbox” that unifies both email and incoming notifications from ALM systems. For Tasktop Dev 2.8 the Gmail integration has been enhanced with the ability to jump from a given point in a Gmail message thread in the IDE to the corresponding expanded message in the browser where the full Gmail functionality is available.

Check out Tasktop Dev 2.8 or contact us about the cross-ALM source code traceability feature which is currently available as part of an Early Access release.