As our list of customers continues to expand, understanding the evolving needs of our current customers as well as taking into account the needs of new customers has become a more demanding task. To consolidate this information and to ensure our product roadmap is in line with what the Targetprocess community wants, we conducted a few customer surveys throughout 2015. Here we would like to present the major findings and provide an overview of what we plan on doing next.

Here’s what you told us you like about Targetprocess. Most frequently you mentioned:

1. Natural and out-of-the-box support for the Agile methodology
2. Flexibility and customizability: it is possible to configure Targetprocess to support any process and to build any custom workflow, no matter how quirky. This frees you up to work with any variations and flavors of Scrum, Kanban, other Agile approaches, traditional project management or your own custom workflows.
3. Visual approach to project management. Many of you said that you appreciate the ability to access and view any data in any way that you want. Having the power to view data from different angles gives you superior visibility into priorities, tasks and dependencies across teams, projects and your whole company.
4. The boost in productivity Targetprocess gives in comparison to other established products like Jira Software, IBM Rational, Rally Software, and ThoughtWorks. We believe this is due both to the flexibility and visibility mentioned above.
5. Customer service and product support: we heard “fantastic”, “instant”, “rapid”, “second to none” so often that we felt obliged to share some tips on how we achieve this.
6. Slick, straightforward and appealing user interface. One customer even reported that their CEO wants to steal our UX team 😉
7. QA & issue tracking functionality - you stressed it significantly improves your focus on quality
8. Tempo of updates and product development

These strong points of Targetprocess are also often reiterated in reviews at third-party websites.

What you asked us to improve

Thanks to your critical remarks and suggestions, Targetprocess is getting better all the time!

Most frequently we heard the following requests:

• more flexibility with access rights (ideally you want licenses of different types: standard, read-only, read&comment)
• easier onboarding for new users
• improved notification functionality
• polished search functionality
• more intuitive Report Builder & Historical Reports
• improved Help Desk module for your own customers
• enhancements for mobile apps
• extended PPM functionality

What we’re doing next

The customer surveys have helped us to prioritize our product roadmap: https://tauboard.com/v/804e592912fa37b7ced3d467fed0cf83.

Keeping in mind the Agile Manifesto's principle of “responding to change over following a plan”, we would group our next steps into the following categories:

1. Polishing various existing functionality (please see the improvement requests above)
   We have already assigned two development teams to these activities and one additional team is working on improvements for the mobile apps. As for the sequence of improvements, first, we are going to add the Split Entity action and Batch Actions in order to simplify the management of various entities. Then we are going to remove the remnants of Targetprocess v.2 (which are often the cause of complications in the existing functionality). Afterwards, we will focus on easier permission management to provide licences of different types and to improve access levels.
2. Extending the Project Portfolio Management (PPM) functionality
   While many customers already use Targetprocess for program management and Agile project portfolio management (PPM, Agile PPM) we are going to add advanced Resource and Capacity Management functionality, including Custom Metrics. In this regard, we are actively looking for customers to validate new ideas as well as for beta testers for our upcoming PPM features. Please email ppm@targetprocess.com to participate or for more information.

If you missed our surveys or have new requests, please make sure you post new suggestions or vote for the existing ideas at our User Voice portal which is our main source of information for prioritising the work for our development teams.

If you want to learn more about the global trends you can expect from agile management solutions, here is our view on it.

Is there anything you want to say about Targetprocess to other companies?

Check out what else people are saying about Targetprocess at these third-party review and product comparison sites. Even better, leave your own review and let everyone know what you think about Targetprocess. It only takes a few seconds!

• G2Crowd.com
• CapTerra.com
• StackShare
• GetApp.com
• Software Insider
• Quora.com

This is my personal humble feedback on Agile Conference. I do make broad conclusions though, so feel free to provide your vision in comments.

I haven't visited Agile conferences for like 5 years, the last one was in Chicago. It was pretty good. The main innovations were Kanban and UX+Agile. Many sessions were still quite boring to any experienced agile practitioner. Now I'm in Orlando. Conference becomes huge. There are so many people around. But what about sessions? In 3 days I visited exactly one session that was really interesting and useful, it was about Netflix culture at DevOps track. All the others I visited were not useful, boring, kinda OK, way too abstract or completely trivial. Maybe I was just unlucky and missed all the good talks. Maybe, but I picked carefully, to be honest. I talked to some people and received mixed feedback, but in general it looks like conference content is not great. DevOps track looks very good, BTW, and I heard many good words about it.

How do I feel about all these things you ask me? I personally see a serious stagnation and the lack of innovations in agile community. Don't get me wrong. There are bright people with brilliant ideas, but it seems they are in opposition to the main trends. How's that happened?

Agile is about helping businesses to kick ass. To do that, there should be innovations in various directions. We, as an agile community, should invent new ways to help business understand what is valuable and what is not. Invent new development practices and try them in various contexts. Inspect organizations as a whole and invent new ways to detect problems and solve them on a system level. But what we have at the moment?

There are many topics about Scaled Agile frameworks. I visited several sessions and I have an opinion that speakers have no clue how to really scale agility. Proposed frameworks are kinda prescriptive and heavy. They reminded me RUP-days. You really can create a good framework based on RUP, but there were few successful cases.

SAFe looks complicated and it does not address root problems on my opinion. We need real structural transformations, while SAFe implies specific receipts and says that it will work in almost any context. How is that possible? Everything is context-dependent, and that is why many agile transformation initiatives failed and will fail. People just apply a recipe without deep thinking, ignoring context-specific things and expect it to work. It won't work in many cases, and you can't fix it without context-awareness.

SAFe has many good practices inside. It can help companies initially and you will see some tactical success, but I also think that in the long run SAFe is a strategic disaster. It may take 5+ years to feel that, but I don't believe that company will inject a true agile mindset starting with SAFe. It can happen, but it will be exceptional cases mostly. The really bad thing is that companies will not notice the problem. With waterfall the problem is (now) obvious, while with SAFe they will have an illusion that they are truly agile, while they are not.

So at the end of the day I have a perception that majority of speakers present some abstract theoretical frameworks with extremely poor argumentation. Why this might work? In which context? No clue.

I also wonder why we have no talks about Kanban here? Is Kanban agile or not? Agile community have personal troubles with Kanban approaches? C'mon, folks, this separation is childish.

All that sounds like rants without solutions so far. So I have some actionable proposals for the next Agile Conference. Here is my feedback:

1. Add a decent mix of various disciplines. We can learn from complexity science, biology, sociology, sport, physics and other disciplines. Try to intrigue people from these disciplines to really mix their practices with our practices and invent something new finally. At least invite them to speak about things they know to stimulate our imagination and analogy thinking. Invite Dave Snowden, finally, to see his controversial view on scaling. There should be more perspectives. We need greater diversity.
2. Have more real-life experience reports with real practices that work in some contextes. It will help to learn from each other and spread good practices. I know many good discussions are firing up between people, but why don't do that on sessions as well?
3. There should be more science. People over the world do great research about group dynamic, development practices, cooperative games, etc. Invite them to share their researches.
4. Invite bright business people to talk about marketing, agile workspace, new hiring practices, strategy, etc. It will finally help merge Agile and business together. Nothing is separate. We should see high-level pictures and learn from them.
5. 75 minutes talks? Are you kidding me? Nobody can control attention for more than 45 minutes. Split these talks and make workshops longer, since 75 minutes are not enough for a decent workshop. I'd like to see more TED-like talks, short and precise. Experiment with that at least. Inspect and adapt.

In short, Agile Conference demands more inventions, real-life reports, more science and different format. Conference organization is just perfect, it really is. I can't imagine better. Content, however, is below average, and that is embarrassing for agile-minded community. We can do better.

The final thing is the slogan I saw yesterday. It is just unbearable to me: "Allow agile and waterfall work together" WTF?

I thought we were working on replacing waterfall and change the ways organizations work. Do we, as a community, still think it is a good idea? Or are we starting to agree with a status quo? I believe we are fucking not. There is no limit to perfection.

"Pirates are bold not safe" — These guys are doing something good

In Why Agile Estimates Don't Work - Part 1 I've explained why estimates don't work if someone sees them primarily as a commitment to timing. And, just as I expected, some aficionados rushed to educate me on the subject of estimates in agile, that they are not a commitment but, in short, a discussion of chances and odds of how the development will go, considering the challenges of this particular production environment. Probably, some of those aficionados have accused me of the gravest sin ever, and namely, not reading Mike Cohn's "Agile Estimating and Planning". Relax, guys. I studied Cohn's book long ago, and time after time I would flip its pages to refresh things in my memories, not to mention other books, articles and from-the-trenches stories. My most reliable source for making conclusions, however, is my work. If someone stays out-of-the trenches and theoretizes about estimates, this is just theory. My view on estimates lies in the practical, pragmatic context: if they don't work as commitment to timing, but as a discussion of chances and odds, why most companies continue to play this game? What makes them go on with it? Why spending lots of time on discussing chances is valued more than action itself?

What Is an Estimate? (take 2)

I've cited two options to answer this question in Part 1. Some people, who are, likely, not educated in agile theory, look at agile as a next best silver bullet to complete projects on time and they might wrongly view estimates as a promise of that. They genuinely believe that agile estimates will give them so much sought after reliable reference point about the time of completion. The second group of believers consciously accepts that estimating is a discussion of chances, a probability forecast. The burndown chart provides such forecast based on velocity. Let's refresh the classical definition of velocity in our memory, quoting from here: "The main idea behind velocity is to help teams estimate how much work they can complete in a given time period based on how quickly similar work was previously completed". Does it ring any bells now? If we never build the same feature twice, just as you can't step twice into the same river, then why velocity-based forecast should be relied on? In general, this stands true for all the forecast techniques based on past performance, including forecast models. Yes, there are cases when a team's work is monotonous, iteration in, iteration out, but from what I've been able to observe, it happens very rarely. Mostly, in any company and team, the tasks to be done and challenges to be resolved are unique, for each iteration, and for each release. You never know when something pops up and kicks this neat forecast in the butt.

The Devil Is In...

.. not only in the details. The second most common habitat of the said devil, which goes after the details, is human nature itself.  Nothing else explains this better than the good old Parkinson's Law:

Yes, indeed. Having all the time in the world is loose. It's either you have time, or you don't have it. It's either you have the guts and sixth sense to define what should be included to the minimal viable product, for instance, or not. Let's not forget that no one cares about software development for its own sake, except the software developers who view their work as craft. We do things for the market. For the customers, and they don't care about the development kitchen constraints, challenges and brilliant solutions. Same stands true for UX.

Now, how this reasoning fits into the subject of estimates, someone might ask? Here's the astounding truth. Teams and companies start playing around and messing with estimate rituals when they have some extra fat to burn. There's no room for activities that are waste in a bootstrapped, mission-oriented, do-or-die start-up squad of several people. If you are in such a team, and tempted to start a planning poker session, don't do this. Rather than waste your time on playing with probabilities, get some real work done. Write code, do a UI sketch,  instill clarity to the work of your team. Some mathematical forecast model surely has it that a brick will fell on your head one day. But you'd hardly be wasting your time to estimate how many more bottles of champagne are likely to slip out of a torn plastic bag, when one of those bottles has already hit the concrete, and there are 3 more in the bag. You'd rush to catch the rest of the bottles, not to let them slip, right? Or will you freeze and estimate the probability of all of the bottles being shattered? This reminds me of the fact, that some business people who are skeptical about shamanism, astrology and other such things, devotedly indulge into what is, in essence, shaman rituals with estimates. Come on, the estimate of completion based on burndown or a planning poker session, is as valid as an astrological forecast. There's no big difference. It's either you're "fat" enough as an organization to afford wasteful rituals or not. In fact, even in large companies that seem to be so safe and secure there's always the bottomline point of "do or die". That's what a recent story with massive job cut by Microsoft proves. Ritual is a waste. If there's time for rituals left, this is a sign of unhealthy fat. Burn it. If a workgroup discusses development, there's no need to wrap it in the ritual of estimating, because when a discussion turns into a draining debate of "how probable" this timeframe is, the work suffers. Someone said, there's a limited number of brains to do the job, and they should be used efficiently. One can suffice with a draft estimated timeframe, there's no use trying to gauge on the likelihood of this happening, when there's real work to be done.

Worship the Idol: How Do I Tell My Higher-Ups ..?

As life has it, however, most of us have to cope with the fallacy around estimates being employees in fat organizations, and, hard as you might, a mere human being can not move a mountain. There's no way to persuade a higher-up non-developer manager, or a client, or a stakeholder in the vanity of estimates. That's why people go on playing games, as they attend to those who expect a feature or a project to be done on time, as derived from estimate-related shamanic rituals. And, that's where another interesting booster for evolution is hiding. Luckily — and, yes, I mean it, luckily — there are more non-developers in the position of authority than developers. There's always a point of litmus test, when someone with a developer background (a project manager, team leader, or someone in middle management) meets the non-developer stakeholder. Why I call it a booster for evolution? If every stakeholder were a developer, they would have probably ended up whining on each other's shoulder about how difficult life is, and how impossible it is to commit to any timeframe. Having to deal with a non-developer stakeholder about a deadline is stimulating. If you've been thinking that something has changed from the hunter-gatherer times, I have bad news for you. The seeming "comfort" guises the basic instinct to act. You either act, or you rot. There's no other option. No one cares for reactive rants. It's your actions that define you. It's your choice to agree to play the estimate game by the rules and accept this as a given, or to quit and find a job where they will not f...k your brain with estimates. If you choose to deal with ruthless stakeholders that are oh-so-not-understanding of how hard a life of a true software craftsman is,  move the conversation from the level of rant to the level of action. Use every opportunity to spread the awareness of the challenges that software development portends, and why this domain is un-deadline-ifiable by nature. Amazingly, there are so many people in this world who sincerely believe that an estimate is a credible measure for completion date. Write articles, speak on conferences, join the "no estimates" movement. Fix the gap between what you know, and what they know. If everyone has their say, this world will become a better place, with less projects and software screwed. And, even if you'd still have to deal with the waste of estimates, you'd feel better inside, because you'd be doing your all to change things, instead of ranting.

Enough of thought boosters (or busters?). In Part 3 of the series I will give an outline of some techniques, commonly regarded as techniques for estimates, that might work as a tool for workgroup discussions in some teams. Keep in mind the waste-value balance, though.

Related articles:

Why Agile Estimates Don't Work - Part 1

As you read this headline, many things came to your mind, probably. You might have recalled those many hours of meetings as you tried to come up with a time estimate for a project or for a product release. Or, you might have remembered the planning poker sessions, which were intended as a spot-on pragmatic business activity, but in the long run proved to be nothing else than a child's game, because the estimates attained as a result of planning poker sessions differed 2 or 3 times from what the actual work really took. The sharp question that I want to ask is: how many times did you feel deep inside that when they make you do an estimate (them being managers, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate proved to be that different from how things actually turned out, and feeling guilty in the process, though probably nothing of it was actually your fault?

Don't get me wrong. My initial intent was pure and well-behaved. I humbly wanted to write an article to sum up techniques for estimation used in agile, describe their pros and cons, and provide people with a single-point reference for all those techniques. However, as I went deeper into the research,  I was astounded. It turned out that there are many more articles and write-ups out there in orthodox agile circles on "How to estimate?" as opposed to "Why estimate at all?" In those few cases, where I saw some attempts at explaining "why?", they stroke me as incongruent and built on some very loose logic. This very fact of the looseness of "why?" puts a big question mark on the validity of the "hows", because the "how" is a product of "why?" or "what?' I've cited this in one of my previous articles, and I'll repeat it one more time, because this axiom is universal, and works for all things life and project management alike: The hows will appear if the what becomes clear.

Let's take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.

What is an estimate?

Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they've proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I've seen this in project-by-project software development and in product development. A slightly modified quote from here:

It's impossible to estimate something that is being built for the first time.

We never build the same feature twice.

The only viable example of valid use of estimates that comes to my mind goes as far back as to the early 2000's, when people wanted simple e-commerce web-sites, or dating sites, or something of that kind. Having built a handful of such web-sites, software vendors were more likely to give their clients a realistic estimate of completion, because these web-sites didn't have a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline "get the sh..t done on time" stuff.

Next, if any attempts at estimating are futile, then why do most companies continue to play this game, which resembles courting, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive and unaligned with the only goal that matters: get the job done well and on time?

Stay tuned for the answers and even sharper disclosures in the upcoming part 2 of this article.

Related articles:

5 Reasons Why You Should Stop Estimating User Stories

Joy Spring and Estimated Deadlines

2 Meta-Principles for User Interface Writing

UX: Why User Vision Design Matters

Why Agile Estimates Don't Work - Part 2