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

by Dave West, March 27th, 2014

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

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

Imagine the following situation…

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

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

Email is evil because it:

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

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

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

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

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

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

I encourage you to do two things:

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

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

Business DevOps is really what we want…

by Dave West, January 8th, 2014

I remember the famous blog by Mike Gualtieri, an analyst at Forrester stating, “I don’t want DevOps, I want NoOps,” creating a passionate debate in the DevOps community about the importance and value of operations. After reading all the comments, it seemed that the solution was a sensible one: Organizations need balance – releasing software requires the skills of both operations and development. For some organizations, this means developers taking on more of the deployment burdens. For others, it’s operations creating automation that is used by developers. And in some companies, it’s Agile teams including operations specialists that focus on both deployment and operations. The bottom line is that DevOps calls for a balanced, thought-through discussion about the role of operations and development. It also calls for collaboration between these two groups.

But hang on a minute – aren’t we missing someone from this discussion? DevOps has focused on connecting development and operations – but mostly in terms of the technical, discipline-oriented work – such as defining techniques that allow builds, deployments, installs and configurations to work seamlessly. DevOps has even promoted the idea that the developer’s work management tools and the organization’s service desks should be integrated. But what DevOPs often misses is that it takes a village (or small city) to deliver software, and a key set of people called “managers” need to also be involved. We need to connect portfolio management to the practice of DevOps – we need to make DevOps, BusDevOps (Business-Dev-Ops).

OK – I can hear the skeptic saying “why do management need to be involved?” Well, “management,” specifically portfolio management and the PMO, are responsible for making strategic investment decisions. They are also, in many organizations, responsible for the financial management of projects/ programs and portfolios. Thus, the process and work done by DevOps need to be managed, and more importantly, reported on by the PMO. This management might be as granular as deciding which trouble tickets to work on, or as macro as seeing the aggregated ticket cost grow and shrink over time and allocating resources accordingly. Depending on your organization, the governance and oversight provided by the PMO needs to be integrated into the process of DevOps allowing improved reporting and decision-making.

We’re bringing Business DevOps together

As part of the Sync 3.0 release we added ServiceNow and JIRA ServiceDesk connectors. These connectors allow tickets to be integrated into both ALM and PMO processes. For example, a service ticket in ServiceNow can generate work items in Clarity, which then are planned in Rally, allocated in TFS to be worked on, and tested in HP QC – all the time being the same “single source of the truth” even if living in many systems. Thus, consistent reporting, collaboration and workflow can be executed against this artifact in real time. With Tasktop Sync 3.0 we allow comments to stream seamlessly from different systems allowing developers, operations, project managers and testers to freely collaborate without leaving the comfort of their own tool. In addition to collaboration by integrating the data across discipline and application boundary, software delivery professionals can generate reports in the system that makes sense to them and of course, get cross discipline and artifact traceability. Integration between operations, development and portfolio management gives organizations the information infrastructure to be more efficient, collaborative and replace the need for manual processes and email and spreadsheets. In fact, one of our missions at Tasktop is to replace the need for email and spreadsheets on software delivery projects and this is just another example of how we can replace those tools.

The creation of the ServiceNow connector was driven by customer demand. When looking at these customers there were two things that unified them:

  1. Increase the lifecycle feedback – Agility highlights the importance and value of feedback. For projects, getting feedback early allows problems to be uncovered earlier and corrective decisions to be made earlier. Though the adoption of Agile methods is widespread, most organizations still suffer from a disconnect between operations, development and the project office.
  2. The need for delivery speed – For many organizations software is crucial for their survival and success. Getting new features and products to market earlier has real impact on the bottom line. But as delivery cadence increased, many of the manual processes that glue together the different disciplines start to break. And while data exchange needs to happen in real time, spreadsheets and email actually start to fracture communication, rather than enable it.

Many organizations talk about Agility, but without automated feedback, Agility really only resides within the boundary of the development team. By connecting development, operations and project managers, organizations have the chance to effectively break down the barriers between those groups, moving to one integrated agile process without assuming that having one process means needing only one tool (which for many organizations is just impossible).

A call to action for Business DevOps

The idea that the way to increase Agility is to reduce the number of disciplines and replace everything with a super developer who can manage the team, work with the business, write great code, test it and then manage its deployment and support, is a pipe dream. Even the most capable developers cannot do everything and specialist practitioners, using the tools that make sense to them, will always be the reality. But that does not mean you have to give up on the dream, organizations can better integrate these groups and disciplines. By focusing on information federation rather than control all groups involved in development can get a better view of what is happening.

Here is a three step program for business DevOps:

  1. Understand the information flow of the primary artifacts – for example, how does a ticket flow through the process from operations to the project office and then into development and test.
  2. Understand the transitions between the artifacts – for example when does a ticket become a new user story or defect and what information would make sense to share across those artifact boundaries.
  3. Replace spreadsheets and manual processes that connect the disciplines today.  Connect up the end tools or adopt a software lifecycle integration business such as Tasktop Sync to make the transition smooth and happen in real time.

Tasktop Sync 3.0 released, service desks get support

by Mik Kersten, December 10th, 2013

Open source projects have it good. Their issue tracker serves as the single system of record for all development, support, quality management and planning activity. The result is a theoretical ideal in terms of a connected software lifecycle. For example, every vote that a user makes for a particular bug is immediately visible to developers. As soon as a new feature is added, users watching the corresponding task are automatically prompted to try the latest build and report back. This kind of real-time connectivity between users, developers and project leaders makes for an incredibly efficient build-measure-learn loop, which explains why so many open source project are able to deliver so much value so quickly. Having lived it day-to-day, it continues to inspire me in wanting to bring these benefits to software delivery in the large, where these benefits can make a tremendous difference.

Tasktop Sync 3.0: Defect Unification

The problem is that this open source project management approach doesn’t scale to the enterprise. It’s fine when you’ve got one stakeholder playing multiple roles. For example, on Mylyn I played the role of developer, product manager, tester, and support desk. I spent so much of my time triaging and commenting on bug reports that, in order to help me get through the tickets fast enough to have enough time for coding, I ended up adding features to Mylyn to make it work as a developer’s inbox for triaging tickets. The experience of other open source projects leads that I know is very similar, in that a tremendous portion of their time is spent triaging and responding to users. This direct touch with end users enables open source developers leverage the collective wisdom of their community so quickly.

However, the developer’s issue tracker does not scale to meet the demands of commercial software support, such the need for SLAs and ITIL processes. So a separate help desk tool is required, once that separation is made, real-time collaboration between the developer and support team stops, and reverts to inefficient channels such as email and meetings. The result is a chasm between the people who are user facing and those who are developing the application. The knowledge of the customer’s experience gets siloed into the help desk and voice of the customer gets diffused by the time that the next sprint planning session comes around. Given the increasingly primary role that the service desk plays in the software lifecycle, as evidenced by the amazing growth of ServiceNow, we need to fix this.

Tasktop Sync 3.0: ITSM

Our goal with Software Lifecycle Integration is to unify the ALM stack while allowing software stakeholders to use the systems that make them most productive. With today’s Tasktop Sync 3.0 announcement, we are very happy to reveal that the Sync bus now supports ITSM artifacts such as tickets and problems, and can connect service desk tools to the large and growing number of Agile and ALM tools that we support. Tasktop Sync makes it possible to extend the popular Defect Unification SLI pattern to the service desk, meaning that tickets matching specific criteria, such as those marked as problems, are automatically created as issues in the issue tracker or defects in the quality management system, and synchronized bidirectionally from that point on. For example, if the defect is Synced to IBM’s RTC, developers can schedule them onto a sprint, and the support team will instantly know that it has been assigned. And as soon as it’s completed, the workflow transition will happen on the service desk indicating that the fix is ready to review or deploy to the customer. Comments and activity streams are federated in real-time. And then it’s smiles all around.

We are launching two service desk integrations with Sync 3.0. Our integration for ServiceNow integration is fully certified by ServiceNow, and will support the many uses of the ServiceNow platform ranging across its ITSM and lifecycle capabilities. We are also launching support for Atlassian’s recently announced JIRA Service Desk, which builds on our comprehensive support of JIRA versions including the latest JIRA 6.1. And as usual, there will be more to come so please let us know what other support desks you would like to see integrated.

ServiceNow Visualizer

Connecting the help desk and bridging the task management gap between Dev and Ops is the most exciting Sync 3.0 news in terms of our mission to scale the efficiency of open source development to the enterprise software lifecycle. In other news, we’re releasing new template support for inheriting and extending mappings, making it dramatically easier to manage large numbers of of projects with different schemas. For those customers using Rally and Serena Business Manager, we’re very happy to announce the GA of those Sync connectors along with the Tasktop Dev connector for developers accessing Serena from Eclipse and Visual Studio. We’ve also extended the Sync bus to support time tracking federation between Agile and PPM, enabling time on task to flow between your Agile system and CA Clarity.

Sync 3.0: Example

Finally, the big news for both ALM vendors and customers is a beta program of the new Tasktop Connector SDK. You may think that SDKs should be old news given that Tasktop created and maintained the Mylyn SDK, which became one of the most extended SDKs on Eclipse. But it turns out that in order to support the real-time lifecycle bus architecture of Sync, an entirely new integration extensibility layer had to be created in order to support robust and easy-to-implement 3rd party extensibility. Along with it we created a bridge to support Mylyn connectors, so if you created one of those you’ll have a head start. If you’re interested in being an early adopter partner of the SDK, please get in touch.

Tasktop Sync 3.0 Bus

We’re thrilled that the tremendous customer demand that we saw for connecting the service desk ships today, and look forward to bringing the voice of the customer into the enterprise software lifecycle.

Want to learn more about Tasktop Sync 3.0? Register for an upcoming webinar:

When: Thursday, January 23rd, 2010: 12 noon ET
Presented by: Mik Kersten, CEO of Tastkop
Register now: Webinar – Introducing Tasktop Sync 3.0

Mylyn 3.10 Released

by Sam Davis, November 18th, 2013

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

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

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

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

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

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

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

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

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

Mylyn 3.9: Improved Code Review Tooling

by Steffen Pingel, October 3rd, 2013

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

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

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

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

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

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

Cheers from Tasktop Boston’s New Office!

by Katelyn Alfano, 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

by Wesley Coelho, 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.

Agile 2013 Retrospective

by Betty.Zakheim, August 21st, 2013

… or, “work isn’t supposed to be this much fun”

I’m just about recovered from our whirlwind trip to Nashville for the Agile Alliance’s conference Agile2013. There were 1700 attendees, 200 sessions, keynotes, parties, and a little controversy.

On a personal note, I was gratified to see the number of women in technology there… most specifically, the number of women who gave talks. Encouraging women to take leadership roles in technology is a side project of mine – I help run a blog and mentoring program at ALineAtTheLadiesRoom.org.

So for me personally, Agile2013 was a blast!

I bumped into so many people I know from various “former lives” – a former engineering manager, a former engineering colleague… folks I know from Agile New England – as well as hanging out with my colleagues at Tasktop (into the wee hours of the morning :-) ).

It was also terrific to meet Tasktop partners, customers and prospective customers. I had the opportunity to spend a bit of time in our booth, chatting with people who often started the conversation with, “My friend told me I had to stop by your booth. Can you really integrate <product A> with <product B>? We’ve got so many systems that don’t talk to each other and… “

This kind of conversation is HUGE fun for me; I haven’t cut code, fixed bugs or managed a software deployment in a while, but still love helping those that do.

Mik presenting

Mik delivering his session

I also had great time listening to Tasktopians give their talks. Mik Kersten, Tasktop’s CEO presented: “As distributed as it gets: 10 Agile best practices from open source” and Dave West, our Chief Product Officer presented: “Agile ALM – A horror/feel good/fantasy story“. Check out their slides; unfortunately it’s not like hearing the talk itself because both Mik and Dave are such great speakers. (If you create an account on tasktop.com, we’ll put you on our mailing list so you can find out about our upcoming talks and webinars).

And while it’s not the same as hearing his talk, you can hear a bit of Dave’s perspectives in two video interviews that were done at Agile. One by DZone and one from BigVisible.

While at Agile, Tasktop made a couple of announcements. On Monday, we announced our partnership with Serena, and on Tuesday we announced the GA of Tasktop Sync 2.8. Our CEO Mik blogged about this release, time tracking and how we’ve connected the worlds of Agile ALM and Project Portfolio Management (PPM)… it’s definitely worth a read.

So, were you at Agile2013? What was notable for you?

Tasktop 2.8 released, Serena partnership announced, death to timesheets

by Mik Kersten, August 6th, 2013

Filling out time sheets is about as fulfilling as doing taxes. This mind-numbing activity is an interesting symptom of what’s broken with the way we deliver software today. What’s worse than the time wasted filling them out is the fact that the numbers we fill out are largely fictitious, as we have no hope of accurately recalling where time went over a course of a week, given that we’re switching tasks over a dozen times an hour. As Peter Drucker stated:

Even in total darkness, most people retain their sense of space. But even with the lights on, a few hours in a sealed room render most people incapable of estimating how much time has elapsed. They are as likely to underrate grossly the time spent in the room as to overrate it grossly. If we rely on our memory, therefore, we do not know how much time has been spent. (Peter Drucker. The Essential Drucker, ch. 16. Know your Time)

Tracking time is not a problem. When done well it’s a very good thing, given that time is our most scarce resource. Done right, time tracking allows us to have some sense for what the burn downs on our sprints are, and to predict what we will deliver and when. It allows us to get better at what we do by eliminating wasteful activities from our day, such as sitting and watching a VM boot up or an update install.

Effective knowledge workers, in my observation, do not start with their tasks. They start with their time. And they do not start out with planning. They start out by finding where their time actually goes. (Effective Drucker, ch 16. Know your Time) (Peter Drucker. The Essential Drucker, ch. 16. Know your Time)

Drucker was a big advocate of time tracking systems for individuals. With Agile, we have now learned how effective tracking story points and actuals can be for Scrum teams. Yet all of this goodness feels very distant when the last thing that stands between you and Friday drinks is a time sheet.

What we need is a way to combine the benefits of personal and team-level time tracking with those needed by the Project Management Office (PMO). With the Automatic Time Tracking feature of Tasktop Dev (screenshot below), we validated a way to combine personal time tracking with team estimation and planning. I still use this feature regularly to be a good student of Drucker and figure out where my own time goes, and many Scrum teams use it to remove the tedious process of manually tracking time per task.

While that automation is useful for the individual and the team, it did not help the PMO, that works at the program, enterprise and product level. PMOs use specialized project and portfolio management software such as CA Clarity PPM. So now, in our ongoing effort to create an infrastructure that connects all aspects of software delivery and to keep people coding and planning to their hearts’ content, we have stepped out of the IDE in order to bridge the divide between the PMO and Agile teams.

The Tasktop Sync 2.8 release includes updates to the leading Agile tools, such as support for RTC 4, HP ALM, CA Clarity Agile and Microsoft TFS 2012. It also ships the first Sync support for Rally and the TFS 2013 beta. The other big news is that we now are announcing a partnership with Serena in which both Tasktop Sync and Tasktop Dev will be OEM’d as part of the Serena Business Manager lifecycle suite. This new integration, which further cements Tasktop’s role as the Switzerland of ALM, will be showcased at Serena xChange in September, and ship this fall.

With Tasktop Sync 2.8, we have finally managed to connect the worlds of Agile ALM and PPM both in terms of task flow, and time reporting. While the support currently works for CA Clarity only, integrating these two worlds has a been a major feat in terms of understanding the data model and building out the integration architecture for connecting “below the line” and “above the line” planning (Forrester Wave). For the individual, it’s like having your own administrative assistant standing over your shoulder filling out the PPM tool for you, only less annoying and easier to edit after the fact. For the Agilistas, it’s about getting to use the methods that make your teams productive while making the PMO happy. And for the organization, it’s the key enabler for something that Drucker would have been proud of: automating the connection between strategy and execution.

The double-sided nature of requirements

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