Welcome to “Agile” the methodology where everything’s made up and the points don’t matter

Story points are a common practice in agile planning and in this article I wanted to talk about some of the theory and my personal experience with pointing. I’m going to assume that all readers are aware of what story points are. But, if you’re not, take a quick peek at the wikipedia article.

I wish I could write more about the history of story points but I’m strugging to find information on that. I heard a rumor that a famous consultant was sick of being asked for deadlines so they came up with idea of points instead. Because the points don’t directly relate to units of time, it drove the concept home that these estimates are just estimates.

Whether or not this is historically accurate, it still explains why you should avoid estimating with units of time. Here’s a case study where a team tried to estimate in hours instead of points:

With hours, we measure our progress and declare something like “we’re doing 22 hours per week”. This can annoy (why aren’t we going faster?), confuse (wait, is this in actual hours or ideal hours?) or even anger (this is a team of slackers!). But a statement like “we’re doing 22 points per week” doesn’t generate these same emotions. It may elicit initial confusion (what’s a point?), but that’s just an opportunity to explain what’s really going on.

Even though points don’t directly relate to time, they can still be used for projections by a Product Manager. If you know the average number of points the team completes per iteration you can leverage this to project when milestones will be reached.

But points aren’t just a compromise to giving specific deadlines. The act of pointing stories is a useful process to the development team. For example, if I think a story is really simple and easy and I say it’s a 1 but my peer says it’s a 5, that means there’s some disconnect that needs to be ironed out. Without story pointing, this disconnect is never discovered. This creates situations where a developer says, “I’ll have it by lunch” but it takes 2 weeks. Or, “This is so hard I think we should consider if the effort is worth it” and the story ends up taking a day.

Paradoxically, story pointing can be used to keep meetings short. If you calculate the average points you complete per iteration and in a pointing meeting you’ve already pointed 2x that average, you know you can end the meeting early: It’s highly unlikely that you’ll be able to get through the work you’ve already pointed so there’s no point in staying in the meeting.

Slight tangent: Sometimes Product Managers like to point as many stories as possible because they think it gives them better projections. In practice I see the opposite being true because once you get two weeks out the points stop being based on reality. Stories start to depend on other stories being completed first. The prerequisite stories can effect the level of effort on future stories in ways you can’t predict. In my opinion, I don’t see a lot of value in pointing more than 2 weeks in the future.

Lets assume that after that 1 vs 5 point discussion, we agree that the story is a 5 pointer and that 5 points is very high. How can that be interpreted and leveraged? Well when a story is pointed very high that usually means there’s a lot of uncertainty in it. Sometimes that means the requirements aren’t clear and the story needs to be rewritten. Sometimes that means the team has no idea how to implement the story and it will be a research task.

Be wary of working on high point stories. They often take much longer than anyone could have anticipated. It should send the message that even though this will be started this iteration, it may not be finished this iteration.

I wanted to end this article by mentioning that there is a “No Estimates” Movement. My interpretation of this is every story is 1 point. I have to admit the concept is appealing when I put my developer hat on. But when I put my Product Manager hat on, the idea doesn’t seem very appealing. I’ve yet to experiment with “No Estimates” so I don’t know how it would play out in practice.

I hope this article helped you think of story points in a way you hadn’t thought of before. If you have a different perspective, please let me know via a comment to this article.

A Bad PM Communicates like a Food Chain

As we discussed last week, A Good PM is a Communication Gateway. This is a diagram of how communication flows to and from a good PM (Product Manager):

Stakeholders talk to PM. PM talks to Devs. And vice versa

If you want to know more details about how a good PM interacts people around them, check out my previous blog post.

This time I want to talk about how bad PMs interact with people around them. The communication flows look more like a food chain. If you’ve never seen a food chain before, it looks like this:

Food Chain

Similarly, a bad PM communicates like this:

Everyone talks to devs. Communication mainly flows down

I call this a food chain communication style because communication flows in one direction and the arrows at the top often point to multiple layers below.

The PM usually transfers the messages from the stakeholders/customers directly to the developers with no translation or pushback along the way.

This lack of translation means that the developers have to spend time converting stories into use cases themselves. As I said in the previous article, translating requirements into use cases is easily a part time job. This takes away from the time that the developers are building software and instead makes everyone into a mini-PM. These raw requirements may not make much sense or be unclear. The developers will waste even more cycles trying to get clarification.

Getting this clarification is not always easy. A bad PM tends to not understand “why” they’re asking the development team to implement something. This means the developer has to ask the PM who to ask (wasting more cycles). In a worst case scenario, the PM will actively interfere with the developer communicating with a stakeholder to get clarification. As a result, the wrong thing is often created, has to be undone, and created again the right way. This is very demoralizing and a waste of time for the company.

When a PM doesn’t know “why”, it is very difficult to prioritize requirements. Without knowing “why”, the loudest stakeholder/customer goes first. And if there are multiple squeaky wheels, then all requirements get to go first. Everything becomes top priority. In other words, the developers’ bandwidth, workload and velocity is rarely considered and new requirements are added to the beginning of the pile of work that’s already in progress. These usually come in the form of interruptions to the developers who are unable to wrap up the stories they’re working on because there’s always something new that’s more important.

Usually when a PM doesn’t know “why”, they don’t push back on stakeholder deadlines. When a stakeholder learns that the PM prioritizes the loudest person first and doesn’t push back on deadlines, the stakeholders often take advantage of this by creating a bunch of artificial deadlines so that their features get worked on sooner. The PM will pass these deadlines off to the development team who will suffer as a result.

In these environments, it can be common for stakeholders to reach out to developers directly. As I said in my previous article, this can be advantageous sometimes but it causes a lot of issues if it’s habitual. When the PM is bypassed, they get out of sync with the stakeholder and the product vision. The PM will know less and less about what’s going on in the project and why. The dev who talked to the stakeholder may be working on something that the PM has no idea about. This is another way prioritization issues occur because the developer is being told different things should be worked on by different people.

Finally, a bad PM tends to involve and include the developers in lots of meetings. They do this because they’re not putting any forethought into what needs to be worked on next so they place the burden on the development team. These meetings interrupt a developer’s train of thought and take away time that could be better spent developing. Some meetings are necessary, but most can and should be avoided. Better to have face to face contact whenever possible.

If you’re at a company and have experienced these symptoms, the PM needs to provide more value to the team. They need to understand the project, understand “why” all requirements are requested and act as a communication gateway between stakeholders/customers.

A Good PM is a Communication Gateway

I was taught this concept by one of my managers many months ago but it didn’t really click for me until I had an opportunity to be a Product Manager (PM) for a few weeks. This experience gave me the empathy to articulate what I, as a developer, want from a PM. The original diagram came from a white boarding session in our conversation.

A good Product Manager is a communication gateway. In fact, I would say that this should be a PM’s primary responsibility. What is a gateway? A gateway is “a means of access or entry to a place.” So, when a PM is effectively doing their job, communication should look like this:

Stakeholders talk to PM. PM talks to Devs. And vice versa

Lets describe these arrows by starting at the top and working down. The stakeholders and customers are talking to the PM so that he can gather requirements that the development team could work on in the future. The PM is talking back to the stakeholders and customers to clarify requirements, set expectations (e.g., other higher priorities, “we’ll have to wrap up x before we can start work on this”), and pushing back (e.g., “I know you want this end of month, but the devs say this will easily take two months even if they dropped everything else on their plate. We can either cut scope or increase the deadline”).

The PM talks to devs after the PM has converted the stakeholder/customer requirements into use cases and prioritized the work. This is easily a part time job as stakeholders/customers often suggest implementations when they think they’re suggesting requirements. Also, three individual stakeholder/customers may tell the PM that their requirement is the highest priority. The developers can’t always work on all three at once, so the PM needs to figure out a reasonable way to pick the order and communicate new expectations back to stakeholders/customers.

In these PM to Dev communications, it is extremely important that the developers are told why they are being asked to work on these use cases. With that information in hand, they can suggest better ways of approaching the problem and have a better chance of reading between the lines correctly when they have to make a technical decision that the PM won’t be able to answer.

Developers talk to the PM to clarify and change use cases. Developers are also the ones estimating the level of effort to complete these use cases. The PM will bring those estimates back to stakeholders/customers to set expectations.

I’m sure there are developers who have communicated directly to stakeholders/customers and felt that was more efficient than going through a PM. This can be true and these direct communications should be set up by the PM when they see that it would be more efficient to do so. But to do this habitually will slow the developers down as they’ll be spending their time gathering requirements and turning them into use cases instead of developing software. When this developer to stakeholder/customer communication needs to occur, the developer should bring the requirements to the PM so that the PM can convert them to use cases for the team. This is also important because the PM needs to be kept in the loop.

When a PM is doing their job, they act like a communication gateway. But what about PMs that aren’t doing their job? They act more like food chains. I’m going to talk more about this in my next blog article, but here’s a sneak peak of what the problem looks like:

Everyone talks to devs. Communication mainly flows down

11 podcasts that will make you a better software engineer

These podcasts are sure to make you a better software engineer. They are in no particular order but I’ve found each one useful in their own way. I usually listen to these as I’m driving to and from work. It’s a great time to grow when you aren’t really doing anything else productive or mentally intensive at the same time.

Hansel Minutes

Site: http://hanselminutes.com/

Feed: http://feeds.feedburner.com/HanselminutesCompleteMP3

One of my favorite things about Hansel Minutes is the host is a great interviewer. He has this interesting technique where he approaches the topics from ignorance and as a result seems to ask all the right questions. Of course you can tell he has put in a lot of research before hand, he just seems to know what you would want to ask if you were giving the interview.

Another nice thing about the podcast is the guests are varied and come from a lot of different backgrounds. For example, he will often interview designers and game developers, but there’s also a lot of guests like Uncle Bob or Joel Spolsky.

There are over 500 episodes to catch up on if you aren’t already listening to it.

SE Radio

Site: http://www.se-radio.net/

Feed: http://feeds.feedburner.com/se-radio

SE Radio talks about a lot of software engineering topics I don’t see discussed anywhere else. For example, there’s an episode on Developer Anarchy, a topic I never heard of until I listened to the podcast. Each episode goes into a lot of depth with the topic at hand and the topic is usually very specific.

I do have a few complaints about the podcast, though. A lot of the guests tend to be very dry and that can make the podcast difficult to pay attention to. I find myself listening to a few of them because I feel like I should instead of because I enjoy the speakers.

Another issue is that the interviewers seem to be very hands off. They’ll ask a question and let the guest talk for minutes before the next interaction. I feel like I can be really confused by something that the host really should have asked for clarification about but never does.

The Agile Revolution

Site: https://theagilerevolution.com/

Feed: http://feeds.feedburner.com/theagilerevolution/fxnY

This is an interesting podcast that often has really good guests but I don’t see on a lot of other peoples’ podcast lists. They’ve had a lot of agile thought leaders on their podcast like Mary and Tom Poppendieck.

The problem is the audio quality is not very good and they’re often taking place inside a noisy cafe or a conference hallway. That said, the content is usually very good.

The Cognicast

Site: http://thinkrelevance.com/blog/tags/podcast

Feed: http://feeds.feedburner.com/thinkrelevance/podcast

This is a podcast that mainly talks to Clojure developers about Clojure topics. Even though I’m not actively developing in that language, I find it very interesting to listen to on occassion. They have a lot of very intelligent guests on the show that are doing all sorts of interesting things you may not have ever heard about if you aren’t working in a functional programming language. Another thing I like is that they often have the creator of Clojure, Rich Hickey, as a guest.

One complaint is that the titles of the podcast only say the guest name, they do not mention the topic of the discussion.

Programming Throwdown

Site: http://www.programmingthrowdown.com/

Feed: http://feeds.feedburner.com/programmingthrowdown

This is a podcast where each episode, the hosts discuss some details about a different programming language. This podcast is extremely casual. Sometimes the first 50-75% of each episode chit chat and then the last part is left over for the programming language itself. They don’t usually take a deep dive in the language but talk about enough to get you interested in learning more on your own.

I have a weird complaint about this podcast: The two hosts sound kind of similar and it can be difficult to tell who is talking. Also, I’m more interested in learning about the language so I almost always skip the first 50-75% to find the content I’m looking for. I find the idle chit chat to be a waste of my time because I’m not interested, but that’s my personal preference.

The Changelog

Site: https://changelog.com/

Feed: http://feeds.5by5.tv/changelog

This podcast discusses an open source project, framework, library or language each episode. They go into a lot of depth on each topic and at the end they ask a series of questions to the author about how they want the community to help the project succeed and who their programming hero is. I like to listen to this podcast because it helps me be aware of other software out there that I can leverage when I’m working on my work projects. For example, I may not have heard of Zero DB, Kong, or Redux without listening to this podcast because they are in different worlds from what I’m doing on a day to day basis.

Giant Robots Smashing into Other Giant Robots

Site: http://giantrobots.fm/

Feed: http://simplecast.fm/podcasts/271/rss

This is a good podcast with some usability experience issues: The problem is the podcast titles are a weird phrase used at some point in the podcast. As a result, you have to dig into the description to figure out who the guest is and if you’re interested in the topic. Call me lazy, but this is usually enough to put me off.

That said, the host and the guests are often good. The interview style is very casual and the guests usually feel like they’re very comfortable and talking to a friend. They have had famous guests like Uncle Bob Martin and Chad Fowler.

Ruby Rogues

Site: http://devchat.tv/

Feed: https://devchat.tv/ruby-rogues/feed

This is a podcast where a bunch of returning hosts talk to one or two guests about a topic. The title of the podcast is Ruby Rogues, but the topic isn’t always (or usually) specific to the ruby programming language. For example, they’ll talk about “Programmer Education and Skill Development”. They often have famous guests like Martin Fowler, etc. The big group of people discussing brings a lot of different viewpoints into the conversation.

I really like the content of this podcast but the problem is there’s often too many cooks in the kitchen. One of the hosts tends to go off on a rant for a few minutes that has little to do with the topic at hand or someone will interrupt the guest while they’re talking about a topic that I’m more interested in. These are not frequent complaints but they occur often enough to be noticeable.

.NET Rocks

Site: https://www.dotnetrocks.com/

Feed: http://feeds.feedburner.com/netRocksFullMp3Downloads

This podcast has over 1000 podcasts that are often of interest to me. For example, they have a podcast on “Continuous Delivery” and another on “Learning Haskell”. Although the two hosts are .NET developers, as you can see, the podcasts are general enough for any developer to learn from. If there is something too specific for my tastes, the titles are named well enough that I can identify that without having to listen to it first. Also, the hosts are very charismatic so the podcasts are rarely boring.

Full Stack Radio

Site: http://www.fullstackradio.com/

Feed: https://simplecast.com/podcasts/279/rss

This is a great podcast where the host and guest talk about a single topic in detail. Example topics are, “Unit Testability and the Universal Architecture” and, “Fixing Common API Design Mistakes”. The host comes off as being egoless and is not afraid to ask for clarification if he’s confused.There have been a lot of really good and famous guests on this podcast like Kent Beck and Michael Feathers. My only complaint is I wish the podcasts would come out more frequently.

The InfoQ Podcast

Site: https://www.infoq.com/

Feed: http://feeds.soundcloud.com/users/soundcloud:users:215740450/sounds.rss

This is a brand new but promising podcast. Some of the episodes are titled, “Adrian Cockcroft on Microservices, Terraservices and Serverless Computing” and “Lisa Crispin and Justin Searls on Testing and Innovation in Front End Technology”. As you can see, the host has interviewed some thought leaders in our field. I don’t have any complaints for this one as it’s so new. I look forward to listening to more episodes.

Code ownership is a bad thing

I was reading this great article titled, “The Quiet Crisis unfolding in Software Development”. I found it to be a great read. You should really check it out. But, there was a part of the article that I found interesting:

Your employees like working for you—right?—which means turnover should be low. Don’t optimize for developers leaving which should be the uncommon scenario. For best results optimize for the common scenario.

Optimizing for the common scenario means giving developers primary ownership of portions of the code base and not allowing other developers to change that code without approval from the primary owner. This results in higher productivity since any given developer is more likely to be familiar with the code in which they will typically be working.

As someone who pair programs all day, I completely disagree with this and think it’s dangerous. I can talk about the bus factor, but I also think that staying on one project makes developers unhappy.

The main reason I’ve left companies is because I got sick and tired of knowing what I’ll be working on if I work there for the next 5 years: The same thing I’m working on today. The truth is, it raises morale to work on something new once in a while.

Think about it: When you’re on an interview and you’re asked, “Where do you see yourself in 5 years?”, are you supposed to answer, “Pretty much where I am right now”? No, that would be a terrible answer and the interviewee wouldn’t want to hear it. They want to hear some ambition, about how you’re going to grow with the company, and how you’d be a good investment.

When you have a culture of always keeping people on the same project, you’re sending the message that they’ll always be trapped doing the same thing day in and day out unless they find another job. Nobody wants to keep working on that decade old code base, even if they created it. That’s about 5 generations of web frameworks and techniques. If you keep working on the old code base, your skills are going to become stale and irrelevant.

not allowing other developers to change that code without approval from the primary owner

I also think this is a dangerous policy. First of all, it creates artificial bottlenecks in the system. If I need this bug fix in some code I depend on but the guy who approves the change is on vacation, my progress just became blocked.

Second, this psychologically encourages peoples egos to be tied to their code. “You can’t touch that because that’s mine” / “You can’t critique that because I made it” / “You can’t improve that because it’s mine“. This is unhealthy and uncollaborative. I know it’s annoying when a novice comes into your code base and commits something that doesn’t follow your coding style or even introduces a bug. But, the reaction to this shouldn’t be to quarantine off all code. The reaction should be to teach this person and work with them to improve the (not your) code base in the future.

Third, it makes developers care more about their piece of the puzzle than the big picture. If there’s a problem somewhere else, they’ll only be interested in it if it directly effects their code.

Fourth, siloing code tends to go hand in hand with siloing knowledge and skills. Some code bases are going to be high quality, others are going to be poor quality. And if the owners of each don’t interact with each other, that’s the way it’s going to stay. In a true vacuum, this might be ok, but eventually some of the good code will depend on the bad. This will cripple your company’s ecosystem of software.

A better approach is a policy that everyone is responsible for all code bases. There should be no barriers to making an improvement to any code in the ecosystem. Yes, developers will have varying skills and mistakes will be made. But if you also have a policy that it’s ok to make mistakes as long as you learn from them, the lower skilled developers will improve their skills faster than being left to their own devices.