How Project Management tools kill more companies than any other SaaS out there

“If only we had an option to create sub-tasks and use templates, we’d be x10 more productive. We could build more features. We could win!” — Everyone, all the time.

Sadly, it’s all lies.

In the recent years, there is a huge blossom in the Project Management area: “This tool is great for implementing Kanban!”, or “This tool has a great intuitive UX!” and “Yea, but this tool actually follows the Lean Startup principles” are thrown into the air faster than you deploy code to production these days.

I call bullshit.

I believe that focusing your time around Project Management tools is a premature optimization and probably #1 killer of many startups. Why? In a single word: “Focus”. In two: “Wrong Focus”.

In order to build a great company, here is what you need:

  • Internal Purpose – Which kind of company are you trying to build? VC-backed? Small & Bootstrapped? Why does building this company matters so much to you? What are the core values you believe in? How would these values manifest in the way you hire people? 
  • External Purpose – Why does it matter to the world? Who do you help by building this product? Is it really valuable to them?
  • Communication & Trust – Do people feel comfortable sharing feedback and ideas? Do they understand the motivation behind the decisions made  in different parts of the company? Are you willing to argue and fight for you believe in? Are you willing to eventually let go and help the person in charge to succeed in executing upon her beliefs, even if they’re opposed to yours? Are different individuals in the company allow their peers to learn faster by enabling experimentation (via tools and teaching) rather than guarding against mistakes (via checklists and roles)?
  • Focus –  Are you saying “No!” enough times a day? Are you building momentum for the critical parts in your business? 
  • Alignment – Are you building an organization that aligns all individuals to a greater goal, instead of optimizing locally (team level)?
  • Hiring – Are you making sure that you don’t hire a “ninja” or a “hacker” that could not emotionally connect to the type of company you are trying to build? Are you hiring people who are better than you?

And here are some things you don’t really need:

  • Tasks hierarchy to the 5th level.
  • Gantt-like dependency visualization.
  •  Template-based for repetitive tasks.
  • 100% accurate Velocity tracking.
  • Single-click Gmail calendar integration.
  • A mobile app that also works on your iPhone 3GS and your iPad 1.


Project Management tools may help you to manage your work more smoothly, but the question is not how fast are you able to deliver things but how fast are you able to learn that you’re delivering the wrong things and make the adjustments.

These adjustments will never be driven by using a better tool. It’s about your attitude, your culture, your DNA.

“But hey, I thought that it’s all about Execution!” It’s not. Well, it’s not the “Execution” you’re referring to anyway. This mantra is so popular today because we tend to read articles covering the top companies out there: Facebook, Google, Dropbox, Amazon etc. These companies already have a solid definition of purpose. They figured out how to scale their communication and hiring. These companies thrived because they were able to focus on customers, growth or revenues over time. Most chances, you’re not there yet.

This doesn’t mean Project Management tools are bad or evil. You may want to invest more in them, when your foundations and product are solid. Just don’t let “imperfect” Project Management tools to be an excuse for a failed business.

It’s like blaming a poor relationship with your spouse due to a lack of decent calendar app for your iPhone.


p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.



Sprint Planning versus Version Planning

Should you start with planning your sprints and then see how it fits your versions? Maybe start with versions and understand how your sprints look like? Maybe planning versions by themselves is enough? How do you start?

Decouple external planning from internal planning

External value (features your customers will enjoy) moves the organization. It is why you get paid. No one will pay for “let these kids develop for fun only”, this is why open source projects were born, for developers to write some code that may or may not be used by others. Versions are communicated out to your customers, named in a language your customers can understand “in version 1.0 we will allow our customers to upload their profile image” rather “we will integrate jQuery and develop highly scalable upload mechanism over Amazon Cloud”.

Internal value (features your organization will enjoy) keeps the organization fully operational, doing its best over time. It is usually not communicated out (your customers don’t really care if you’re using C# 4.0 or C# 3.0) and not named in customer’s lingo.

Versions are more tangible

Most of us stick to planning versions and our sprints actually look the same as our versions. We’re results oriented and we want to please our customers. Moreover, no external power is actively pushing us toward internal value.

Sometimes internal value > external value

If you’re strictly results oriented, you might produce great results but only for short, unpredictable periods. Sometimes you’ll need to delay customer’s value to handle broken “machine” in your factory. Your customers won’t like this delay, but they will understand it if you’ll offer tradeoffs and communicate “we are fixing internal machine to keep our high level of production steady”. They will prefer stable producing rather than insane, poor quality or unpredictable results.

Use Sprints to prioritize internal value with external value

Maybe you can devote 5% of the sprint to maintain your ability to produce fast? Maybe 10%? Maybe 1%? It’s really up to you to figure out what you want to push every sprint. Be careful of dismissing internal value, it’s your role to actively push for it.

How do I start?

I prefer to set some goals for my sprint first: (a) is there an internal value I want to push? (b) Are there people in my team that I want to push by leading features? (c) What is my team availability for this sprint?

With this in mind, I’m starting to plan my versions for the sprint and next one, making sure I understand perfectly what should enter the sprint and when. This is the first time I validate my plans. If the planned versions fully occupying my sprint (or even more than that), I raise a flag and trying to figure out if something can be shifted without causing damage. If not, and I have some “buffer”, it leaves me with understanding how much of my internal value I can push inside the sprint, alongside external value. This is the second time I validate my plans. Did I manage to push my goals to the sprint while producing external value? If I notice there is a big need for internal value that cannot wait, I will try to understand alternatives with our product team and supply tradeoffs.

Then, all is left is to organize when should each feature start/end and making sure external value (versions) are released on time while internal value is keep moving. Keep your head above the water, plan to last.


Should you allow changes during Sprint?

Sprint is a planning unit, keeping it stable during that time allows a pretended piece of mind for the developers from marketing/product ever-changing demands. So it feels anyway. We developers signed up a virtual contract with our product teams saying “we will be Agile enough to allow you to change your mind every 1-3 weeks, but don’t disturb us during that time! We want to work, not wasting our time on talks!”.

Does it make sense to you? Is this the true notion behind Agile? Would it be acceptable for a great business?

Well, it makes sense only if you think that waste is more valuable than your attention. Delaying smart decisions or cutting off bad ones after 2 weeks, 2 days or even 2 minutes is simply counterproductive. If you know that a feature selected for the sprint became a waste due to priority change, why should you move forward with it? why throwing the problem to the other side of the fence: “well, my product team should have been wiser with their priorities. We’ll do it anyway just to teach them a lesson so they won’t do it for next sprint!”

Priorities tend to change. It happens constantly. Don’t panic, be open-minded and make sure your team leaders can handle priority shift. It’s perfectly okay to say no, but make sure it’s a “reasonable no”. If you see it does make sense to move out some features and move in some others, do it with care, offer tradeoffs (“this change might mean we won’t be able to release the version on time, let’s delay it in 2 days”) and make sure motivation passes to your team. Your teammates need to realize that providing organized waste is plain dumb; they also need to trust you doing these changes with full attention, clarifying tradeoffs and setting expectations. Practice your agility!


Why tracking actual work hours is so imperative

After bashing prediction systems, claiming that measuring performance of your teammates to predict release dates or personal behavior is inherently wrong, you might deduce that I meant “measuring Actual Hours is pointless”. On the contrary my friend, I believe that tracking Actual Hours is imperative for better planning and cutting off waste.

Translate internal units (Story Points / Ideal Days) into external units (Calendar)

How can you translate a 3 Story Points or 3 Ideal Days to “it will be ready next Tuesday”? By using the actual time it took to perform a task or a feature, you could actually see a correlation between Story Points size (internal to the organization) to the total amount of actual work hours range (external as you can put it on the calendar). For example, you might notice after a few sprints that 3 Story Points (based on latest 5 features), are usually taking 23-28 actual work hours to complete. Assuming you pick a number, say 6, as the amount of “effective” work hours in a single day, such features will translate to 4-5 working days.

Story Points can be translated quickly, based on empirical knowledge, to a range of working days. This will make release dates predication much easier, assisting your Project Manager and your marketing team to communicate it within their roadmap.

Tracking your actual work hours will help you to quickly balance effort in a Sprint

You’re on the first day of the Sprint and you’ve got seven Features (/ User Stories) in your “Not Started” column. You also made sure that your teammates’ availability is updated as some have vacations and some got exams during the sprint.

How can you balance your tasks effort, in hours, between your teammates?

By looking at your actual work hours history, from the example above, you can see that a 3 Story Points feature translates into 23-28 hours of work. You can immediately add to all features worth 3 Story Points one task called “TBD” with 25 (average) hours and assign it to one of your teammates. That way, you can add a “TBD” task to each one of your features, simply by checking their Story Points -> actual work hours range.

Next, you slowly break these big TBD tasks, in each feature, into multiple smaller tasks, each with different owner and estimation, until you see that the effort is balanced between all of your teammates. When your team is mature enough, they can break down their tasks and provide their own estimation at the beginning of the sprint.

Two flows for example:

a. 3 Story Points (range: 23-28 hours) -> 1 task worth 25h for Joe -> 1 task worth 10 for Joe, 1 task worth 5 for Jim and 1 task worth 10 for Annie.

b. 2 Story Points (range: 10-18 hours) -> 1 task worth 14h for Jim -> 1 task worth 10 for Jim and 1 task worth 4 for Annie.

c. [ … until all work effort are balanced by availability and optimal ownership … ]
d. Make sure that your breakdown makes sense in terms of people availability. Make changes if needed.


Tracking your actual work hours is imperative as it (1) provides a way to translate internal work units to external work units and (2) enable fast estimation of large features. The key is to clearly explain how using internal estimation can help with these goals. Asking your teammates to remain open and honest about their actual effort (versus rough estimation) requires a lot of trust from their side. Don’t break it and don’t use it against them.

p.s. check out my latest side-project, SoftwareLeadWeekly – A free weekly email, for busy people who care about people, culture and leadership.


Story Points over Ideal Days?

Many teams going into Scrum, have internal debates around whether or not moving to Story Points or sticking with Ideal Days. It seems that there is a lot of personal feelings involved.

Ideal Days – what is it all about?

Just imagine a work day without any meetings, phone calls or people bothering you. It’s a full day of making things done, full day working solely on your tasks, whatever that means.

Story Points – what is it all about?

Story Points are a bit more abstract notion. It includes 3 parts: Work Effort (how much effort the work will take), Complexity (implementing known yet complex code) and Risk (3rd party integration, POC required etc). It inherently abstracts away the “who” to allow you to consider the “what”.

Estimation is expensive

I’ve said it before – estimation is expensive. You should find ways to make your estimation faster, unless you were specifically required to execute the Feature or bringing a super detailed estimation. If it’s not the case, and you were asked for numbers to determine Product Roadmap or feasibility of features, stick to fast gut feelings, may it be private hunch or collaborative hunch.

Fibonacci size – what is it all about?

To make estimation faster, it’s easier to have smaller list of options to pick from. For example, instead of picking a size from 1-100, you should pick from a smaller numbers range, like Fibonacci: 1,2,3,5,8,13 and then go to 20, 40, 70, 100. Why the jumps? Because the bigger the estimation, the bigger likelihood of being wrong or wasting too much time discussing how wrong. So instead of arguing on whether it’s 6 working days or 7, you just pick 8 or 5, depending on the specifics (effort, complexity, risk). The purpose is to estimate fast, not to be 100% precise.

Using Anchors

Usually, the idea is to price Features (or User Stories) against other Features *like* them. “This feature is around the same effort as that feature so it will be 3 Story Points as well”. After picking a few Features as “baseline”, it’s easier to estimate faster others features against them.

Ideal Days baggage

I personally believe that Ideal Days brings too much baggage into the discussion (making estimation slower):

1. Who’s Ideal Day? How long is one Ideal Day? Each member will consider her/his Ideal Day. Instead of focusing on fast estimation, everyone passing in their head “well, Joe is new in the team, it will take it twice as much! Let’s price it as twice as much then”. Story Points “don’t care” who is implementing the Feature. This is exactly how it should be done as you never really know who will actually be the implementor until you start working on it.

2. Ideal Days are not strongly correlated with estimating Complexity and Risks: People have in mind, when using Ideal Days, mostly effort involved. Story Points, due to its abstraction level, allows better focus on Complexity and Risk.

Matter of flavor, I guess

Anyway, I feel that it’s not really important whether you’re using Story Points on Ideal Days, as long as you (1) remember to price Complexity and Risk as well; as long as (2) you understand that estimation is expensive. I feel that Story Points offer better abstraction which allows faster estimation, but it’s really matter of “whatever works”.

Write down Estimation Reasoning!

Make sure you keep your estimation reason. “We said its 5 Story Points because it’s ~3 Story Points for effort and ~1-2 for Complexity and Risk. We felt good enough with 5 Story Points.” Why? If you would like to use this estimation as an anchor in the future, while trying to estimate a new feature, you should remember what the original 5 Story Points meant for you: “Was it 5 Story Points only because of effort?”


Why should you strive for moving Features to done?

If Sprints are not execution unit, what is the rush of moving Features to done as soon as possible during a sprint? Why should you care about it if you’re not limited by end of sprint deadline?

Other than the fact that done is fun ™ (obvious sense of accomplishment), striving for done features will push the entire team to excel. I’ll try to cover it from two angles, manager and developer.

Nothing new, you commit to version instead of Sprint

The only difference of introducing versions to decouple execution from sprints, is that you commit to version rather than sprint. So far, no big change, you need to release on time to allow fast feedback by your customers. It’s the same “Agile attitude”, the same fuzzy feeling in your tummy.

From Developer’s point of view

1. Prefer small amount of WIP (Work In Progress) – we are poor with multi-tasking and we hate to get back to things we thought we already finished. If you aim to move Features to done, you can be more confident moving forward without leaving some concerns behind you.

2. Practice Growth – the more features you’re estimating, breaking (into tasks) and leading, the more you’ll improve your communication and leadership skills. Because all of the above is so hard to get right, you need to practice as much as you can to feel comfortable leading bigger features over time and later on, if desired, leading your own team. Great leaders not only know how to push features but they also can explain to others how to get better at it, to share feedback. For that, you’ll need to practice enough, to reflect enough, until you really grasp the complexity behind it.

From Team Leader’s point of view

1. Prefer small amount of WIP – you should prefer 7 features done from 9 planned rather than 15 features in progress from 20 planned. You cannot deploy half-baked features thus 15 features in progress means zero value to your customers.

2. Create predictability by making Velocity graph stable – If you want to plan your sprint faster and with more confidence, you’ll need to understand how many Story Points / Ideal Days you’re able to do each sprint. For that, you’ll want your Velocity graph to avoid spikes every sprint (example: 30 SP, 2 SP, 87 SP, 40 SP) but rather have a “stable” Velocity graph (example: 30 SP, 27 SP, 34SP, 29SP). Constant spikes mean that you won’t be able to say how many Features (by Story Points) you’re able to perform. Less confidence => more time spent on planning.

3. Create predictability by making Features Size Completion stable – again, if you want to plan your sprint faster, you’ll need to know how many big / medium / small features you’re able to pull off every sprint or every version. Try to strive for known throughput per feature size to increase confidence.

Planning Sprint, just like estimating features, might be very expensive and hard to nail down. The trick is to create solid picture that strengthen your gut feeling about what you can actually do. With this in hands, you’ll spend less time breaking everything to little pieces or worry about the quality of your plan; instead, you’ll have solid empirical history behind you to back you up. More time for you to get some tan!


Estimating Features: options, context and God

“We need to support registration in the application. Here are some details, how many days to develop?” — Where should you start from? Should you simply throw a number? Maybe read it first and use your gut feeling, your experience? Is there a trap here? Although there are no recipes for estimating successfully™, I want to elaborate on the options in front of us, before we dig into the details.

Guesstimate everything months in advance by 20 seconds of thought

If you are able to read a Feature specification and give estimation based on “whatever works for you”, you win! For small features this should probably be as simple as pie, but what about the big ones? Still easy?

“We have someone who can do it with some sort of dark magic ball !”

I call him (or her) God. If you have God in your company, you win!

(1) Estimate by detailed breakdown

Giving proper estimation without feeling bad about it 10 seconds later is not cheap. I don’t care how much experience you have. So, are you ready to invest? You should not only consider coding effort, but also organization time – testing, deployment, monitoring, bug fixing etc. After you have this in mind, did you consider risks? What about 3rd party integration? What about inexperienced developer who might work on this feature?

One way to provide detailed estimation is by actually doing the Design (of the solution) and bring one to the table; This means doing a Design Review with your peers, break the feature into tasks, estimate hours needed per task and give very solid numbers. You can do it by yourself, you can do it with others; the price is not 20 seconds, but this is highly useful for solid estimation.

Wait, Context is king!

Before you start throwing numbers into the air or diving into an expensive design to come up with estimation, what is expected of you?

1. Purpose – how your estimation is going to be used? To determine roadmap? To understand feasibility? For prioritization between 2 Features? Each might require different “estimation plan”

2. Size – is it good enough to say “it’s a big feature” or maybe “it’s around 20-40 days” or maybe “it’s 24 hours”?

Back to your options list

Well, you could estimate by detailed breakdown, if you really need low granularity. Sometimes, rough estimations might be enough. What now?

(2) Estimate by personal hunch

You can obviously estimate based on your personal hunch, taking into consideration organization time, risks and what not. In many cases, assuming you’ve got enough “gut feeling” built by your sheer experience, this should suffice to build roadmap or understand feasibility. If this is the expectation, it’s probably the cheapest way to provide numbers.

(3) Estimate by collective hunch

You can improve (or at least feel more confident) granularity by adding one or more experienced teammates into the mix, double-checking your hunches and forming a collective hunch.

(4) Estimate by team hunch

Again, more people involved might mean better estimation, due to larger feedback. There is the obvious risk of “2 people, 3 opinions”, but at least you’ll have some other, non imaginary, voices of sense.

What does it all mean?

Each method offers some advantages and suffers from some inner faults. Understand the context and pick wisely. Accept the fact that things change and features might be thrown away – do not waste time on estimation more than is really required. More about features estimation to follow…


Planning your Sprint

With a given time window and people, how much can you pull off?

Many managers are requested to offer a plan. Knowing how much you can actually deliver is one of the toughest question managers need to face with. It’s too elusive to measure it correctly, and there are many moving parts. You need to please your customers and your teammates, creating a plan to deliver external and internal value, picking wisely what is really feasible.

I tried to come up with a few tips to make this process a bit more structured, making it less elusive, less daunting and less “we’ll see as we go”:

1. Pick by External Priority – what will make your customers happy? Make sure you have the right priority from product / business teams and give it high consideration in your planning. At the end of the day, you are here to provide value to your customers.

2. Pick by Internal Priority – making sure you are building confidence as part of your Sprint. You want to excel over time, you must devote the time to allow it.

3. Pick by Features Size – try to see how many features of each size you can deliver in a Sprint. For example, after 2-3 Sprints, you might notice that you’re usually able to do X big features, Y medium features and Z small features. Usually there is a connection between feature size and QA effort or deployment effort, thus making this size estimation very useful.

4. Pick by Velocity – if you know you’re able to complete X Story Points (or Ideal Days) every sprint, based on your last 2-3 Sprints, use this information to pick Features to fit this number give or take. I always believe that you should aim for ~120%, to allow positive pressure which encourages self-improvement ideas, but don’t aim for failure or naïve success. There is nothing to gain there.

5. Pick by Personal Growth – you might pick some features to allow inner growth in your team. For example, you might notice a need to strengthen one of your teammate’s leadership skills by allowing her/him to lead bigger features. It doesn’t mean you should act naively; organization needs is more important than personal whims, but the organization will never actively push toward personal growth as a goal. It’s up to you to make time for it.


Visibility over Progress

After talking quite a bit about how to break a Feature into tasks and avoiding leftovers, I would like to address the natural habit of what I call “blindly moving forward”. How often do you find yourself after 3 days of coding, still unclear of how many days are left or whether or not you’re closer to the end? How often you tend to forget what exactly you originally meant by “the end”? How often you find yourself feeling too invested to stop and figure out what the hack is going on?

We are, naturally, very outcome oriented. “I need this Feature done until tomorrow” or “I need to see your plans for next Sprint until end of day” keep pushing us during our daily effort. We are driven to supply outcomes, losing the ability to track the big picture because of vast, ever growing demand for results. Just like multi-threading coding, it’s not enough to throw some languages, tools or IDE with cool debugging options to the mix; we need to change the way we think and act, to supply visibility rather than mere progress.

When breaking a Feature, ask yourself these questions:

  1. Do you fully understand the Feature business value?
  2. Do you have Risks mapping (what can go wrong and what to do on such case)?
  3. Do you have the right people in-sync? (QA, Operations or other relevant team members)
  4. Do you break the Features by layers or by verticals? Are you OK with that?
  5. Do you have low granularity of tasks (up to 3-4 hours)? Enough to make you feel good about “no surprises”? Enough to allow others to join you?
  6. Do you know when you’ll be code-ready? Can you commit to a date?

As a Team leader, you should ask for visibility from your teammates. They should earn your confidence by offering a complete plan, knowing what the expected outcome is and communicate their status during the development time. If you ask me, I will always prefer better understanding of current status over naïve “I managed to progress today”.

As a developer, you should aspire for complete visibility to make sure you’re moving in the right path. This will allow others to give you honest feedback, join you if you’re a bit behind schedule and practice leadership in a way that is building confidence in your organization: people will feel that you know what you’re doing and will trust your good judgment and commitments. They will feel more confident when you’re behind the wheel.

If you feel that this is an overhead, you probably in a misconception of the time it will take you versus the time it will save you. Answering the above shouldn’t take 5 days; it should take couple of hours. This will ease your mind regarding “did I miss something?”, saving you hours of juggling between building confidence with your manager(“Can you update your progress?”, “Where are you standing?”) and actually building the software.


Adjusting big Features to Sprints

Many times when picking Features as execution unit, it’s hard to fit a big Feature into Sprint. This always cause the feeling of Features is too big as an execution units, leading some organization to prefer User Stories over Features, wrongfully neglecting Features over time. User Stories as execution unit are not the optimal way to go as they don’t provide enough value by themselves – you need to have “enough” Story Points to release a valuable version to your customers. They are also too abstract to understand the big picture, missing the overall why behind them. I believe that Feature broken into Tasks is a better approach and better execution unit. Obviously, there are multiple approaches to deal with big Features. You should pick the right tool according to requirements and people involved.

Breaking Big Feature, some options:

1. Extract design from execution: You can complete the design of a big Feature in Sprint 1 and implement it on Sprint 2. This way, instead of having a very big design effort and implementation effort on the same Sprint, you can use the first Sprint to understand effort and risks and use the second sprint to implement and deliver the goods, after understanding ROI better.

2. Extract framework from client: User Stories, just like Scrum in a way, introduce too many “Do’s and Don’ts”. For example, it’s considered a “bad practice” to have Technical User Stories. I believe that if the framework has specific needs (raised by the Feature) and it’s easy to break it out from the Feature itself (user behavior), it’s perfectly okay. It’s actually another step in the right way to build confidence as part of your Sprint!

3. Break big value to multiple smaller values (*caution*): Features, by nature, bring a value to your customers. It is possible though, to break the value into multiple Features, each carries only part of the value, without damaging the overall behavior. Instead of creating a “Search Engine” feature, it’s perfectly fine to define “People Search” and “Articles Search” as different features, each bringing different value. It’s even better to define sub Features inside “People Search” to enrich user experience over time, according to feedback by your customers. Caution: you need to do it carefully, sometimes breaking a Feature into multiple Features is silly as each doesn’t bring enough value by itself, until all of the pieces come together. Still, this is a powerful question to use: “Can we deliver real value to our customers by breaking this into multiple parts?”.

Most of the time, your Features should be small enough to fit a Sprint. It’s that simple – if the features are usually estimated in 2 weeks, don’t have a 1 week sprint. That being said, you should have the right (or at least some) tools to handle big Features. If it wasn’t obvious so far, don’t be afraid to “twist and mix Agile”. You owe it to yourself to understand why you’re doing things and adjust it if needed, even if it’s written in some book that it’s a “bad practice”. It might be bad for them, but it might be perfectly fine for you.