Yeah I cringed when I read this bit. If any managers are reading don't fucking do this. Your intentions may be benign (this person apparently thought they were) but most devs are going to read this as veiled micromanaging and get just as stressed out as the earlier approaches in the article.
Just use scrum as intended, maybe push for more detailed updates if devs are just saying stuff like "still working on x". Or just trust them and don't try to babysit.
Pivotal also has thing where everyone is expected to pair program all the time. I think I would despise the environment but it’s clearly not for everyone, myself included.
I was skeptical too, before I joined Pivotal Labs, but I love it. It's worth noting that it's a skill, or rather a collection of skills, that are much easier to learn from an experienced pair.
At the moment I have been on a solo allocation for about 6 months. It has let me go down a lot of rabbit holes, which can be educational. But I miss pairing pretty badly on days when I am working on straight regular development.
You also need somebody good to pair with. It can be really infuriating to have to deal with someone who can't keep up but on the other hand if you work with someone you respect, it's great.
So true. Not only is it annoying micromanagement, it kills the problem focus, so there goes 15 minutes of reengagement with the problem. Oh but there's a meeting in 30 minutes? Might as well get a snack and read a tech article now instead of finishing the microtask I was working on.
Same. I'd be pissed. I mean, if they have time to come by everyone's desk a couple times a day, WTAF are they doing and why are they getting paid for it?
Engineers got their work done despite the micromanage (to be clear, I mean despite and not because. Just in case any PM or manager is reading this and thinks micromanaging is why tasks get done)
Funny thing is, asking twice a day doesn't even make sense for the manager...
Of course, it relieves stress and stuff, but if you're THAT stressed because of the project and need constant reassurance from the engineers, you're clearly in the wrong job.
I had to lead a few engineering teams (wasn't a PM, though) and the only approach that ever worked for me was to check things out in much larger intervals, a week, sometimes even more. Actually treat engineers like adults and be an adult yourself. Let them come to you if they have a problem. Sample the progress in much larger intervals in order to reduce noise.
Thank you for reminding me how much I dislike working with PMs
I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly
I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup. And they even admit their technical knowledge is not good enough to actually be able to help much if there is an issue. If you are bothering and interrupting every single person on your team multiple times a day just in case you need to increment a number in a JIRA board now instead of tomorrow morning, you are wasting people's time. Leave it to the standup.
Your job as a PM is not to micromanage engineers. If that is anybody's job, that is the engineers' managers. Your job is to make the engineers more productive and make sure they're working on the right things - but not at an hourly granularity.
I mean this is from a company that forces pair programming down everyone’s throat (so that you don’t space out on hn as one of stated reasons) so what did you expect? =)
I don't know how you get the idea that it's forced.
We're known for it, it's part of the interviewing process for Labs and most of R&D. Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them.
That is a good thing.
Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing but currently I'm working solo. If a pair decides they should work solo, they do. Lots of pairs have a rotating arrangement where somebody different works solo for a day or two. I know of teams where they are solo in the morning to review PRs and pair in the afternoon to work on new contributions.
None of this is enforced. There is no manual, no rulebook for The One True Way. Nobody tells you how to work. The way works is: the people are nice and smart and want to do the right thing. The rest is largely details.
It doesn't to me, so this might be a disagreement about the meaning of forced. Nobody is surprised that the default mode is fulltime pairing, we make a point of having candidates experience it beforehand.
And as I noted above, pairing isn't mandated. Teams are free to adopt any process they please, but most folks at Pivotal like the defaults and we tend to gravitate to them.
It's pretty damn near forced if you're on a visa. I had brilliant friends in the Bay area that felt like they were forced to stay at their incredibly toxic jobs since the job market was rough for them and not having a job meant leaving the country.
I don't believe that's the fault of the company, nor their responsibility. There are many people that feel forced to stay at toxic jobs, in the Bay Area as locals, because their lifestyle relies on having zero unemployment windows - e.g., they'll default on credit card and house payments.
Especially to those on a visa, the only one forcing you to remain in the USA / Bay Area / x company is yourself. To put it bluntly, no one is entitled to a job, and this applies to every person. In this scenario, it's not like strangers are being pulled off the streets by Pivotal to pair program.
This is a pretty poor model for how employment should work, morally. Let's put this model to a realistic extreme to see how it falls apart:
Suppose an employer asks a loved one to have sex with them or they lose their job. I mean, no one is putting a gun to your loved one's head to have sex with their employer, but something is clearly very wrong at this level right? Suppose they have an expensive debilitating medical condition that can really only be treated with good insurance (I have seen this firsthand where a medication can cost hundreds a month even with insurance (not great insurance but I was an intern, it was all I could afford)). Suppose they tried searching for a job with comparable insurance for years but always come up empty. Now when it's between whether or not you will go homeless with a debilitating medical condition or basically being raped, what would you choose? Frankly, I would rather be raped. I have been in the hospital with great insurance as well, when my condition was at its worst, and even morphine and norco did nothing to make the pain go away; I can only imagine how much worse it would have been on the streets with that kind of unending pain; I can only imagine never being able to find a job like that ever again because I will always be in unending pain and never be able to interview well. Fortunately, I got really really lucky in that I am an engineer who is an American citizen that can find jobs easily that dont require me to physically be there but, most people are not in my position. Back to the point, if someone is more willing to be raped than to not be raped out of fear of the consequences, that's pretty damned close to forced right?
I thought about this some more and I think the distinction comes down to whether I am made to pair against my will. I'm not. So to me that doesn't feel forced.
But if I worked for Company X and then one day Thou Shalt Pair Or Else, then yeah, it would feel shitty. Labs developers pair with client developers on engagements and sometimes it feels like they've been dropped from a very great height.
Most of the time it works out fine: people are people and we work in the same industry and share many of the same experiences and passions. Sometimes it just doesn't work for everyone, which is also fine.
But insofar as anyone from Pivotal is explicitly or implicitly saying "or else!", I think they are making a mistake and hope they get feedback about it.
We have the usual HR, legal, compliance etc. But product teams exercise enormous autonomy, arguably to a fault. A few years back an R&D mechanism was introduced of pushing triaged security issues directly into team backlogs. Something close to a riot broke out.
R&D leadership otherwise pretty much don't interfere. Their main business is explaining our strategy, keeping the lights on and teams connected and adjusting allocations between different product and component teams.
What I meant is since Pivotal is known for uh voluntary-enforced? subscription to XP religious practices you can’t really expect it not to bleed into all aspects of dev process.
Btw I have nothing against pairing in general, just not the way Pivotal does this.
Speaking for myself, I would give feedback to a product manager that asking during the day is unnecessary. I'd try to understand why the PM feels they need to.
But yes, pairing is very helpful for maintaining context when interruptions occur.
Less distraction? Unless you are doing cookie cutter crap, you sometimes need to be able to walk away from your workplace for an hour or two to have good ideas; frankly, I've worked with some of the best scientists on this planet and it was common to see them leave their desk for an hour and walk around the block to clear their mind once a day or so.
Moreover, I recently fell into the trap of working for an entire week nonstop to solve a really hard problem. Took a few hours off one day to clear my mind and when I came back, I had the problem solved inside of an hour. If I continued down the route I was going down before that time off I can guarantee you it would be more days wasted.
Until recently, I shared your sentiment about product managers, but recent experience has refined my point of view.
IMO a good product manager does not focus on trying to understand _why_ things are hard, but rather _what_ things are hard.
With this understanding they can either 1) work to change scope/requirements so that the bigggest user pain points are solved ASAP or 2) accept that more time than anticipated is required to solve user problems.
Implicit in all of this is the trust that when engineers say something is hard, it is actually hard.
When I see the author talking about paranoia, trust is the first thing that comes to mind.
To be fair, I don’t think that trust is easy. But I also don’t think that effective product management is possible without it
I've found the best way to avoid interrupting engineers is to have a daily sync (a.k.a stand up meeting). My team meets for 30 minutes each morning to give an update, have Q&A, and discuss priorities and issues. We're a small team (3 developers) but it works perfectly because folks either had their inquiry answered earlier in the day or can execute good judgement to try to figure it out and if not ask about it tomorrow. We all receive tickets and if it's critical enough we'll meet to devise a plan. Under this scheme we are rarely interrupted and have been grinding through features all summer.
A daily sync is way too often on teams that know what they're doing. It feels like busy work and is a waste in throughput and stress. Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams.
edit: at the most, I think async are passable via slack or something similar. Otherwise all data on this can be easily done via a Kanban board.
I like daily syncs if they are done quickly (<15m), and if people are working on different-enough things that they don't really know what their teammates are working on. Because that way you can unblock each other and actually use agile the way it was meant to be done in the face of underestimated tasks or changing requirements
In my experience anything more than 10 minutes is a smell. It typically means you've got stories that are too big, have unaired problems, that you dive into implementation instead of just syncing briefly, or the team has too many people.
I personally think brief dives into implementation / explanations of issues is fine. If something takes only 5 minutes to discuss between everyone, I'd rather do it while I'm already in a meeting, and having the whole team there helps opinions get heard. But this is just personal preference
My preferred way to handle this is to explicitly acknowledge that the meeting isn't just sync-up, it's really two meetings:
- sync up / status is 15 mins. Any implementation discussion gets put in the parking lot
- once we've gone around the table, the rest of the meeting is handling the Q&A / parking lot we parked during the status discussion. Anyone not directly concerned by it is encouraged to leave, get out and be productive!
This gets you the double benefits of interrupt coalescing (a single regular interruption instead of 2 smaller ones where one is an irregular surprise), and preserving the quickness and relevance of the stand-up, as it's really just the first 10-15 minutes of the calendar slot, after which you're good to leave.
With a visual system like Kanban, it's quite easy to see what other people are working on. The problem I have with daily syncs is that it's redundant to information already available, and you're forcing people to "meet" without any value. A lot of conversations in that "sync" are just noise to a majority of participants. It's kind of like a bunch of people talking to a wall unless you happen to be associated directly with the update – which is more rare.
In my experience, the need is to provide a clear method of communication and ability to unblock one another. A Kanban board is perfect for this, as well as committing to a definition of done.
Anything else... is very wasteful in my experience.
For me, what is in a Kanban board is not enough info to be able to determine when I can help unblock other people on my team. I think this probably depends on how you use project-management software and what your team works on; for me, a teammate's item might list "Create pipeline to process dataset Y on hourly basis". If they are running into issues, I don't know if it's something I've seen before with that dataset, or that pipeline tech, or the processing script, or end-to-end latency, or XYZ. A standup helps clarify things somewhat
Also if a teammate is actively working on something that is a downstream dependency of something I am working on, then I can passively learn about requirements and expectations for my own work, become aware of issues ahead of time, etc.
1. For transparency any member of the team can identify blockers in Kanban by putting them in the blocked column.
2. If you're blocked, and running into issues, you'd reach out to anyone that can help you. Why would you wait for a standup or "talk to the wall" for that? Just be proactive.
Dependencies should be known before committing to a scope of work (iteration) with the team. Planning stage (minimal time investment for scope of work definition) vs committed work stage (in progress iteration).
> Anything else is just stakeholder over management and or inexperienced teams.
At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about topics mentioned in the article where it's crucial to have the PM there.
Standup should usually be around five minutes. That's the reason it's not a sit-down meeting.
My reaction to this would be the work committed to was unclear. A task should have all the items clarified before being committed to. If there are questions throughout the iteration then the work was poorly planned. It should be a rarity that a task was ill defined.
My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often.
Changing requirements is fine, though, so long as there's a discussion. Engineering explains what it might involve and the PM gets to decide if they think the change is worth it. Generally once a week is fine. Changes at sub-weekly cadence suggest deeper problems that need to be sorted out.
My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.
Yes, I think we basically agree. Normal practice at Pivotal is to hold weekly Iteration Planning Meetings (IPM). Most product managers aim to keep around 2 weeks of ready work in the backlog, based on what Tracker is predicting. Anything more than that will be usually be cards in the icebox.
>Once a week, with committed items with a true definition of done is all that is needed. Anything in-between should be facilitated by the team members to unblock each other. Anything else is just stakeholder over management and or inexperienced teams.
It's not just a status report, it's a casual discussion about the work. We collaborate on strategy, talk about any issues, and coordinate with each other. We front load information sharing so that it's rare to have to share information (ie. interrupt) at other times in the day.
I work for Pivotal. Product managers vary in how they work with a team, so this approach is new to me.
As an anchor (approximately a tech lead) I made it my business to work closely with PMs on the product: giving feedback on how the technical direction was shaping up, asking for stories to be updated or broken apart, giving options for technical seams and so on. Frequently we embed product designers as well, so discussing design options and asking for modifications was common.
But when I was pairing with another engineer we did whatever was on the top of the backlog according to our best judgement and with attention to quality. If it needed refactoring, we refactored. If we felt that would be better to wait, it would wait.
The most important discussion, I found, was about chores -- work that engineers view as paying dividends in future velocity. Our view is that engineering is the ultimate owner of chores and can schedule them according to its considered discretion. The system works because of trust. I trust that product managers and product designers will be diligent in identifying user values and priorities. They can trust us to do what needs to be done to make the software to a sustainable high quality.
I remember once I was rotated in as anchor for a product that had begun to struggle a bit. In particular we had a particular giant tech debt: we had fallen behind on React versions. Worse, there were three parts of the codebase using React, in three different ways. With my peers I decided that we were going to fix it. "I think it will take one pair week", I remember saying.
It took five weeks. But nobody ever said: stop, you work for me, my way or the highway. We talked about the reasons. This tech debt would only grow as time passed. There was no good time to repay it, so sooner was better than later.
We were trusted to do the right thing, so we did the right thing.
It's a dependency for our main visual library, PivotalUI, which is meant to give a uniform brand across all our products. When you get a flagship site falling behind the products that customers have installed, it looks dumb.
But more to the point: it slowed development. I could deal with a bit of visual glitchiness, but my job as an engineer is to create software to solve problems. Piling hacks on top of hacks doesn't do that and it's shitty to the next engineer who joins the team.
You should probably have your management team look at these comments. How much hated it is getting. I can say from experience that I have quit because of a manager like this. Don't do this. You will lose any engineer that can get another job and be left with those that can't jump ship. I'll let you determine the quality of those engineers.
Software engineers aren't special. Literally any job that requires a modicum of concentration, whether it's writing marketing copy or doing complex financial forecasts, means that interruptions are costly.
I once had a boss (legal - so lots of drafting/reviewing) who had a rule: no meetings & no drivebys before lunch. For anyone on the team. Calendars were expected to be clear from 9-1. He'd say "If you aren't sprinting down the hall to talk about it then it can wait until after lunch."
Of course there were "emergencies" and things so it was more like a team standard than a rule but it was phenomenal. When I got to my desk in the morning I always knew I'd have a solid block of time to get through the important work before I had to go to a bunch of meetings and take on more.
I only read the first paragraph and couldn’t read anymore. I’m unsure why he cannot Know when a story will be delivered. A story should fit into a sprint and so he should reasonablely expect that it’s delivered at the end of that sprint. If it’s not going to be delivered then this information should be relayed back to the pm.
Going and pestering the team is only going to slow down development process and increase the likelihood of the team not delivering for the sprint.
Pivotal doesn't use sprints. Stories are pointed by engineers and ordered by the PM, but they're done when they are done, to the satisfaction of both.
Tracker is able to give short-term forecasts of what will be done by when by averaging the last 3 weeks of deliveries (ie, velocity).
Personally I think the idea of sprints is a menace. It creates an artificial deadline that leads to either waste or stress. Deadlines should be reserved for actual meaningful deadlines.
I think that artificial deadlines and stress exist because the team and management allow it to exist. A story should fit into a sprint, but it may spill into the following sprint, but you shouldn't sacrifice quality just because you tried to finish it within the sprint. And a team should stand up for themselves in this regard, as a team, because a team succeeds and fails together. If you sacrifice quality because of some artificial deadline you put in place then you're only going to suffer maintaining that later on.
I think two core ideas of sprints are to
1) combat Parkinson's Law by creating an artificial deadline (the team should try to solve things within the sprint) and
2) protecting the team from changes (avoiding that requirements change all the time)
With that in mind, sprints can work pretty well, and work "spilling over" to another sprint is generally no problem. It starts falling apart if the artificial deadline becomes a forced deadline, or if the protection part is dropped.
> I only read the first paragraph and couldn’t read anymore.
Indeed. I got about that far before I quit reading and started fantasizing about the unspeaking things I would do to the idiot that wrote this if I ever met him. Things involving sharp blades and fire.
> I followed my mentor’s advice and started to check-in at least every half day with each pair of engineers I was working with.
This is monumentally bad advice.
> I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break
So surveill and/or eavesdrop and/or ambush. Nice.
> Hadrien Raffalli is a Product Lead at Pivotal.
Here's me thinking it's probably a more junior PM doing this. Nope, it's a Product Lead.
PMs/TPMs can be great, if they are good. I've worked with some that made my life easier. I've worked with others who really didn't.
Based on this article alone, Pivotal's PMs would make me quit.
Pivotal is well known for having a particularly extreme point of view, bordering on forthright religious fervor, when it comes to pair programming and taking highly bureaucratic versions of Agile development to an extreme.
Pivotal can deliver things to customers in spite of all this (given that it’s surely not because of all this), which sort of makes any advice published out of there fundamentally irrelevant for people working pretty much anywhere else.
As far as I know, Pivotal's process is based on Extreme Programming (XP), a process which deliberately takes an extreme point of view. (It's in the name.) It's not bureaucratic, but it is demanding.
I have a lot of experience with XP. In my experience, XP succeeds because of its extremeness, not despite it. It's not for everybody, but for organizations and teams such as Pivotal who are willing to understand and embrace it, it works very very well.
So I challenge your "given that it's surely not because of all this" comment. Do you have any evidence? Or are you just saying, "I don't like this, so it can't possibly work?"
Taylorism worked -- it decreased costs for companies, but people suffered -- they couldn't find meaning in what they do, their every move was monitored and choreographed, and they were squeezed for the last bit of efficiency possible.
The kind of "pairing all the time" kind of XP that is being preached is similar for programmers. It also works for repetitive work - building yet another web application - at scale, not at scale, not much of a difference. But programmers often get into the job because it is an inherently creative field. There is nothing like this kind of XP to suck it all away and leave them disillusioned about the craft until they escape and find a product role or even a consulting company with more empathy and kindness.
I'm another person who has done a fair amount of XP. Definitely some people feel this way. Some people do not. Personally, I really enjoyed it. I enjoy working with people. I enjoy shared experiences. I found the atmosphere to be challenging yet friendly. Quite often solo programming can be lonely. Sometimes you wonder what people think of your code. Sometimes you hear all too well what people think of your code -- three days after you could have done something about it ;-). In the pure XP teams I was on, I had a lot less conflict overall -- mainly because you are kind of forced to deal with conflict up front.
However, we had a few guys on our team that really didn't like it. They left and I don't think less of them in any way. It's a different way to do things.
As for the "repetitive work" aspect: the most successful XP project I did was a collaborative sketching application using pen input with automatic shape recognition: somewhere around 2000 (when did MS put out those pen based computers??? -- We did it for their unveiling).
This conversation is probably moot in teams where programmers are actually empowered to make their own decisions. In that case XP is fine, if you enjoy it, which makes it sort of a tautology.
The problem though is the Agile Industrial Complex and "thought leaders" who have pushed this as a religion on the industry. I enjoy pairing, and the excitement of two minds working at the same problem in tandem is an experience to be relished. But give it to an Agile snake-oil salesman, most of whom gravitated away from programming a long time ago in favor of making money training others in how to program, and they'll wield it as a weapon by prescribing the only true way to work.
Well, I won't disagree. I've had the moniker "Agile Coach" before it was ever a thing (I though I'd invented the term :-) ). But I have never been a business consultant. My "coaching" was exactly what you would expect from a sports coach: I helped the players, not the management :-).
XP (in its traditional sense) doesn't scale past 8 developers anyway. Anybody selling you XP for a team of 500 is someone to be wary of ;-)
This right here. It changed my outlook on software completely.
There are pains and giving folks the opportunity for change/rotation is refreshing.
Software is a team sport, its a weak-link game where we must communicate and empathize in order to see clearly (often past our own egos) in order to pull one-another up.
I was fortunate that good pairing hygiene was a focal point. Without that it can be disastrous mentally and ruin the experience for everyone. It turned into a highly collaborative sport at that point.
I am a hugger naturally but when I run into those pairs I went through the trenches with, it is a brother/sister hug. Best time of my life.
I feel you. When you pair program with someone you get to know each other deeply as programmers and people too. Not all of us can go into millitary to live dangerously with fellow soldiers, or participate in team sports, but as a weak substitue we have pair programming and high-pressure projects. I have to clarify that I enjoy pairing. It is the greatest thing when it works. But often it doesn't - it is a social activity, and so many things have to come together for that to happen. If you have a company that selects for such fit, and a culture that teaches pair hygiene, then the chances are better. Yet, I would rather reserve the freedom to choose how I work rather than be institutionalized for 8 hours a day into a specific ritual.
How are you so sure? They are so brilliant they can make great stuff despite a terrible process they choose, but they aren't smart enough to not use the process?
Yes, this is quite common. The people who choose the process are not the same as the people who get stuff done despite it.
There’s also a survivorship / selection bias inherent to companies with extreme views like this. Either you both (a) agree to cheerlead & display positive affection for the religion and (b) display effectiveness in the role, or else you will quit or get fired or self-select to never work there in the first place.
So in a large part, it’s literally unknowable to what degree success is in spite of vs because of these extreme practices. There can’t be evidence about it because by definition there is the confounding factor that the employees whose productivity you measure are only from one specific sub-population (likes extreme view & delivers good software). You never get to measure what people with diverse opinions about tbe philosophy would do in the role, and you never get to measure what less successful developers would have done in the extreme philosophy.
The same effect happens with extreme coaching philosophy in sports, where again after you apply the filter that the players are selected to both be very good and accepting of the philosophy, there’s no way to measure the counterfactual possibilities, so it reduces to religion.
> So surveill and/or eavesdrop and/or ambush. Nice.
It's common courtesy or some kind of "office ettiquette" that if Alice wants something from Bob, but doesn't want to interrupt, she waits until there is an opportunity. Returning from a break is an obvious cue.
I just wanted to make the point that waiting for someone to return from a break before talking to them can be considered polite, instead of an impolite ambush as indicated in the previous comment. Of course, there is no one-size-fits-it-all solution.
In my experience, that is not an acceptable solution for everyone. I have worked with people who despise these kinds of scheduled short meeting, because "we are sitting in the same office and can always talk to each other".
That having said, my personal preference is also the scheduled 15 minute meeting.
I don't see the point in getting updates more than once a day. If something could change that you needed to know before tomorrow, isn't something else potentially wrong with the process?
The only case where I want such frequent updates are when (1) there's some P0 bug on production and it needs to be fixed / tested / deployed yesterday or (2) we're trying to pressure the person to want to quit their job or magically improve (more the former than the latter).
From the title I expected to see something a bit more, well, tactical about how to arrange communication by changing "real" interruptions into queued requests. For example, e-mails, or (varying by workplace-cultures) instant-messages that nobody expects immediate answers to.
Judging by all the negative responses do most people see themselves as some sort of vigilante programmer in their company?
I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...
I think lots of people have just had genuinely shitty experiences where they were slowed down in their work by interruptions or made to feel that they were not trusted as professionals.
They see this and it fits a pattern and so they are fairly skeptical.
I have had a mix of experiences in my professional life, Pivotal is by far my favourite, even when I've gotten super frustrated about particular problems (and I have). I've learned that lots of folks on HN or reddit hear about our common practices and suspect that it's at best chicanery and at worse a deception (all for the fiendish end of working fixed hours with enormous autonomy, dun dun duhhh!).
Those responses usually upset me, because I feel that my experiences are being devalued. I read the comments and I compare them to my life of the past five and half years and they just aren't the same. It can be hurtful to have casual snide remarks made when you know that the people you work with are kind, thoughtful, intelligent, hard-working humans through and through.
But I also know that other people have had bad experiences and what they hear sounds like other things they've heard from shitty managers and colleagues, so they're cynical. If I talk down to them then I am devaluing their experiences. So I try not to, even though my personal nature is to be an arrogant wanker.
I dont think it is generally vigalanty programmers, just that routinely and irregularly interrupting knowledge workers is counterproductive. Like, I've been debugging and researching a potential bug and I'm deep in thought about it, then a manager or PM walks up, interrupts your train of thought with something completely unrelated to what you're currently working on.
Context switches are annoying to the engineer and costly for development. Each context switch probably costs between at least 15 to 30 minutes, maybe more depending on what the engineer is working on. If that happens 4-6 times a day, you've potentially burned 1/4-1/3 of the day. I spent close to 3 hours in 3 unrelated meetings. So, 1/2 of my day was spent task switching and not really giving 100% attention in the meetings because of the constant task switches. Frustrating and don't feel like I made any progress today, on my first day back on an overdue week long vacation.
I have had good and bad PMs. The bad PMs can take many forms, but one form is the "control freak who wants to be your manager". There is a happy medium between complete lack of information and thrice-daily status checks
I much prefer to have a daily standup and/or weekly/fortnightly planning session scheduled rather than having someone randomly come to my desk whenever they see that I am having non-work conversation for a bit (we are humans afterall). The project can't go too awry in the intervening periods and if you can't trust your engineers to raise any issues that they have you have way bigger problems.
I think you need to read between the lines to get what the Engineering Community is saying. When you try to micromanage something without any domain knowledge, you are doomed to scorn and in the long-term, failure. You do not follow a process blindly but understand the domain, your people and business objectives to adapt the process to a particular context. That is where the Software Management community has failed. A process which makes perfect sense in a Consulting context is forcibly thrust upon Product Development teams to everybody's detriment. And they can't see it!
Is it really common for software engineers to work under these conditions? As an electrical Engineers I have plenty of deadlines and do plenty of work with PMs, but none of this daily standup and thankfully Jira was recently dropped as it was considered more trouble than it is worth (management just wanted to know the big things going on and not all things). Of course it's better than plenty of other jobs, but the constant treatment of employees like they're on an assembly line sounds rough. I know software development is tough and respect those that do it. I have critical time sensitive tasks and I'm expected to have them completed on time. My manager might check in once a month on a year long 1/4 million dollar project among all the other work I do. I know that's peanuts compared to a large software project, but still.
It depends a lot on the company. I've been fortunate enough to avoid companies like the one posted, but there really are two (maybe three) views of developers:
1.) Treat them as engineers who are capable, able to communicate problems or expected delays, and professionals who want to grow.
2.) Treat them as assembly line workers who constantly want to screw around and need to be whipped back into shape.
I'd argue maybe a third is the startup mentality where you need to sell your life to the company, but maybe that's a mutually exclusive thing.
In my experience, the second comes from the same mentality as the old waterfall companies. Spec everything, trust no developer, micromanage, etc. Developers are a risk, not an asset, and never trust them at a management level. I would never work for a company like that, and avoid them like the plague.
Regardless, both of the views above seem to be a self fulfilling prophecy. Professional shops who treat developers as engineers produce some quality stuff and usually on time. Sweat shops have a lot of failed and over-budget projects and a high turnover.
Thanks for the insight. I like programming and read and write plenty of code, but it is a part of my job (tool in the belt) and not the focus. In my opinion, there are always so many unknowns for any project that scoping something out entirely beforehand seems entirely useless. I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it. I can't do that to start without a better understanding of the problem. I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.
> I'd much rather sketch some diagrams on paper and try to implement something that works but is a little ugly and then make a second pass to clean it up and properly architect it.
Fred Brooks said "plan to throw one away, you will anyhow". He was mostly talking about the value of prototyping or what in some circles is called spiking.
> I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.
Not in my experience, and I'm a pro-estimate loony. A lot of products and problems do have fairly predictable elements and it's possible to give useful estimates (eg, add new form element, needs a new field in the endpoint, new column on the table, some validations, tests for the above, no changes to docs ...).
Other problems are closer to pure research and you just accept someone might come back with something some day.
What we argue about in software circles is how wide valley in the middle is.
I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet."
Why? Speaking from personal experience, when I was a recent grad and got asked for an estimate, said "I don't know" and then got pressed for one, my thought process was "okay... I guess I'll just come up with a number and double it" because thats the advice I'd been given multiple times. This resulted in an estimate that had no relationship with reality and which I knew had no relationship with reality. This was not helpful for communication because...well because it was a lie. Thats the key: unless you give someone the freedom to say "I cannot yet give you an estimate", you can't know if the estimate you get is a lie.
Establishing this freedom is hard:
* One reason that it can be hard to give estimates of simple tasks like adding a new form element/adding a new field in an endpoint/adding a new column on a table is if you don't yet know your tools well. But it can be rather embarrassing to admit this. So the engineer can be reluctant to exercise the backbone to claim this freedom.
* There is a lot of moralizing around estimates. The article On Being a Senior Engineer[1] says "Avoiding responsibility for estimates is another way of saying, 'I’m not ready to be relied upon for building critical pieces of infrastructure.'" so admitting that you don't yet know how to estimate might be admitting that you should be fired.
* This is hopefully an uncommon case, but an engineer might have been unwittingly hired as a senior engineer right out of university because their recruiter told the business he'd known the engineer for years. This exacerbates the previous point.
* A business stakeholder really wants to have an estimate, even if the reality of the world is that engineer can't give them one.
* There aren't any resources for new engineers to learn task-estimation[2]. So if one of your engineers doesn't know how to estimate tasks, you might worry that they'll never learn how, since coaching that engineer to learn estimation is too time-intensive an option for most companies.
* When an engineer is asked "how long will this take?", it isn't obvious from that question that the estimation process requires first identifying the key pieces of the task and the riskiest pieces of this. That relies on knowledge of how to produce estimates: understanding that they key piece of estimation is not the number you get at the end but is the mile-markers you produce along the way.
All of these difficulties hurt the key thing required for a good conversation around estimates: trust. Trust that the person hearing the estimate knows that there is uncertainty. Trust that the engineer will flag up if they run into a pile of complexity.
> I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet."
Absolutely. This is itself a valuable estimate. Very occasionally engineers will give a very high points value to indicate that the proposed story is simply too complex as written and needs to be decomposed further.
> Establishing this freedom is hard:
It absolutely is. Everything we do at Pivotal that works well is actually hard. Our cheat code for bootstrapping these practices is that we already bootstrapped them years ago. But maintaining a culture is harder than building one, which is a trillion times harder than improving one.
In my experience "the old waterfall companies" are the ones where the engineers are trusted with a task and left to do their thing. In such an environment, managers are only there to assist the engineers. I.e. escalate issues, provide ressources etc. and most importantly: fight for their team/department in meetings. We go to our team lead only when it is necessary and he only asks for updates when he needs to report our status to a superior.
What I have witnessed in those hip, agile young companies is that you have to report exactly what yyou have done, what you are plannign to do etc. constantly. At least once a day, plus whatever other weekly meetings you are in. Sometimes your entire day is filled with meetings and you are supposed to fit your actual work somewhere in the breaks. And if you can't finish a task in a day, you trigger extra attention from managers and suddenly you find yourself sitting at your desk with another engineer and a manager looking over your shoulder, wasting hours of expensive time instead of letting you work.
Those are the two extremes I have encountered and they are only annecdotes. But they do serve to show that the development process chosen for a project is not tell you anything about the management style.
Interesting. What I meant by "old waterfall companies" is that there's a few businesses in town that write enterprise software, oracle, etc, for fortune 500s. Those tend to not be kind to their developers, and have been around for a while.
I have worked for another large telecom that treated its developers great that did kanban.
Currently I work for an agency that really does neither. :-D
But I think you're right, the methodology doesn't matter nearly as much as the managers.
What's odd about the "agile" companies, is that while you are a designer or engineer in product mode, you're not supposed to attend any meetings beyond daily standup, weekly IPM, and weekly retro... Maybe the odd town hall. Maybe the odd inception day or cross-team retro every few months for a major new initiative. But that's about it. PMs do attend other meetings mostly as a liaison to the outside world, because that's the gig, but even then, it tends to be limited.
The whole point (at least at Pivotal) is to spend more time coding/designing/testing and not in meetings.
That's how it used to be when I started in the 90s. My first projects were pretty much like "Here is the problem. Come back when you have questions" and me and others would often work for weeks without talking to management. Now it seems a lot of companies are doing more micromanagement. I also sometimes wonder if the younger programmers need more handholding these. When I started there were almost no people with formal training in software development so we were all self starters that had learned on our own because that was the only way to get into the field.
The problem is that a client is paying by the hour, so going away for “weeks” to guess and “work” costs literally thousands of dollars. With XP, there would be a problem that would require weeks of obscurity to solve: it would be broken down into a smaller piece. And, you’d be working with your pair on it with frequent interaction with the PM.
I understand that. However I think it’s counterproductive to get daily status updates. It helps with the insecurities of management but I don’t think anything gets down quicker or better . Instead I believe the constant interruptions and second guessing slow things down.
>Is it really common for software engineers to work under these conditions?
It wasn't like this before fads like XP, Agile, Scrum etc. and micro-management became mainstream. Most of the current management done by PMs and their ilk can be easily categorized under "Bullshit Jobs" (https://strikemag.org/bullshit-jobs). The problem is that once somebody has codified their experience under a catchy title and started marketing it, people blindly follow it without understanding its context and applicability. Given that the barrier to entry to these sort of positions are so low (you can become a PM without any sort of domain knowledge!) people who might not cut it as Engineers seek these jobs to boost their pay, power and egos.
PS: The above might come across as a little harsh but unfortunately is the reality for most Engineers.
Software engineers are constantly delivering products to customers. I assume the timeline for an electrical engineering project can be many months or even years, so this isn't very surprising. When you work in an environment using continuous delivery and you are shipping features to customers every day/week, there's no way you can not have more communication. These things have to be documented, support staff trained, project goals tracked, etc.
Agile, XP, insert-other-methadology, is a way to potentially take a developer who is a 2 or 3 and get them working like a 5.
Problem is it also takes the developers who are 8,9 and 10s and turns them into 5s too.
If you have lots of 2s and 3s this is probably fine. If you have more 7s, 8s and 9s it's a problem. For a start the better developers will end up simply leaving as working conditions are too hostile.
Most developers are < 5 / 10 skill wise, so these silly methadologies become stupidly popular.
I'm a PM and this does not resonate with me. If you're getting status twice a day... I think something is very wrong.
The brutal truth of software development is that the quality of your output is going to vary with the quality of the engineers you work with. Good engineers don't need daily standups to build great products, and bad engineers aren't going to be helped by doing twice-daily checkins.
I think you jumped the shark here. The point of doing multiple checkins a day is to make good engineers feel like they are barely good enough, and make them hungry to please the bosses! Pavlov at work here, I think.
I think you'd need to experience the flow of a place like Pivotal before passing judgement. I find it interesting that you've immediately jumped to "good vs. bad engineers". The mindset at Pivotal tends to be that all engineers are equal. There is no good or bad. This is why they rotate pairs.
Checking in with a pair isn't a status update, it's really about collaboration and visibility. Estimates are often wrong, assumptions get tested, the team dynamic is "let's ensure we all understand this".
Stories in tracker tend to be <1 day, so checking in occasionally isn't exactly a wrong thing (every half day to me is excessive), so priorities can be shifted, or big stories can be broken up.
My manager expects a formal report once a month, but he is always open to conversation about the products we build. We end up talking daily, but it is never forced.
Wow, where do we start here? First of all, it is much more effective to team with a tech lead or engineering manager to remain semi-realtime up to date with the status of where things are in engineering rather than asking status update questions directly. To not understand that is a level of naivete that prevents a product manager from operating at the basic level of competence to be considered a senior IC.
Second of all, I've seen two kinds of product managers. One kind looks at software development estimates as commitments to be contractually adhered to. The other treats software development estimates as assets/investments with risks to be managed.
Which kind is more effective? Well, which computation accomplishes more results, the one that doesn't halt and logs the same line over and over, or the one that does halt and additionally does the thing it set out to do?
I honestly can't tell if this is a terrible practice or just the worst possible way to describe it for the HN crowd.
People who end up in manager roles tend to be people persons and some use very touchy-feely language. I'm personally put off by all the references to his own anxiety as just one example. That doesn't necessarily mean he's actually a terrible manager.
Part of his job is to make sure things get delivered in a timely fashion. If that's not happening, then feeling stressed by it isn't unreasonable, but the article sounds like he's just trying to manage his emotions rather than get deliverables from his people in a timely fashion.
I'm not posting this to dog the author. I'm posting this to suggest that his framing may reflect the fact that his job involves managing people rather than things.
If it were framed differently, the exact same practices might sound much more reasonable and palatable to people here on HN who are overall reacting fairly negatively to this.
I've also seen that programmers who're not really good at the job, but don't have qualms about playing politics often end up managing the teams they were unfit to work in in the first place. They were not necessarily better at people than others. The idea that programmers are not good with people is, in my observation, a self-perpetuating stereotype. Mostly because if you're writing code, you are on a maker's schedule and you don't have much time or bandwidth to think about anything else. Managers on the other hand have more control over their time and can for example spend an hour to decide exactly how a conversation should go before they speak to someone. They can reflect on it, and deliberately improve over time. The programmer on the other hand would be figuring out why a particular technical decision was wrong and how they can identify it next time etc.
More to the point, spending an hour thinking about how to have that conversation so it gets the desired result is literally the manager's job. Dealing with people is exactly what they are getting paid to think about and do.
It's not really about innate social skills per se. A lot of social stuff is learned behavior anyway.
There are some nuggets of wisdom in this article, but I think it's very clouded by a certain perspective. I normally don't comment, but feel that it's important to slice what I feel is useful and what can be detrimental behavior as a PM.
As a PM of about 4-years of experience, I understand the author's concerns and at the same time believe that he has solved for the wrong problem; his own anxiety rather than team cohesiveness and trust. The issues he solves for can be solved in different ways without such a negative impact on the team, actually in a very positive manner that increases trust, cohesiveness, and user context.
I'd first like to point out that I've made the mistakes of micromanagement that he mentions in the first section. I also quickly learned how detrimental that behavior is to team relationships, productivity, and outcomes. I'm certainly not perfect!
The way the author solves the problem of pace is by creating regular check-ins every half day. He then goes on to identify, how these check-ins can be used as open to monitor common slow-downs: engineering struggle and product context (he calls is product debt).
I'd first like to make the point that some other engineers have commented here, estimates are estimates, we are agile, you learn things along the way and need to adapt. I believe your job as a PM is not to hold the team to estimates, it is to come up with creative solution and serve as a master facilitator on your team.
So when the author says the following I can't help but notice the irony. I'd explore us all to practice what we preach. Instead care about iterations (sprints) not task micromanagement:
"As a product manager (PM), I often make assumptions as to when a particular user story will be delivered. This is painful because I don’t believe in time estimates and don’t think I should be involved in estimating the relative complexity of a story since I don’t own its implementation.
I know I shouldn’t but I can’t help doing it anyway…"
So how do you solve the problems that the author points to "struggle" and "context" without adding interruptions?
• For struggle, that is what standup is for. Not only standup, but if you create a culture of trust engineers will naturally reach out if they hit road blocks, make a slack channel for your team. It's even better if you can teach your team about red flags, things that the article says which are true to look out for: complexity is rapidly increasing, not feeling confident in the stack/codebase. For any of this to work you MUST create a culture of questions and answers. Yes, all want to look competent, but what's also great is being able to depend on your team.
• Adding to the previous point, this is why small tasks are soo important, [read this book on product flow](https://www.amazon.com/dp/B007TKU0O0/ref=dp-kindle-redirect?...) if complexity is small to begin with you can avoid that issue AND you get the added benefit of smaller iterations, meaning faster red flags. The author points this out too, this is critically important.
• For context, context is king. Want to avoid "Product debt", get your team/tech lead involved from Day 0 of your quarterly/yearly roadmap, they should know everything about the user that the PM does minus the RAW research effort. Run a Kickoff/Inception/IPM that truly integrates your entire team, every engineer should have product context. Devs will then see tricky edge cases, radiate them up to the PM and you can make a call together if the work is necessary.
All of this is to say that there are some good parts of this article, but I think that adding one more check-in is not necessary when there are other ways to solve the problems identified.
You know what I don't get about status updates? We're all using tools like Jira, Trello, Pivotal Tracker, GitHub issues, etc., where you can see what everyone's working on and the status of each of those tasks. Why do we need frequent status updates like standups and PMs looking over our shoulders if you can just go to the project board and look for yourself? If I'm going to be asked about the status of what I'm doing every day, then don't make me use these systems.
It's like that episode of Seinfeld where Kramer pretends to be Moviefone. "To update the status of your ticket, press 1 now. .......... Why don't you just tell me the status of your ticket?"
Your team needs excellent JIRA hygiene for that to actually work. I’ve been on and managed teams where it’s expected and demanded and others where it was an afterthought.
I think parent’s point stands: if JIRA is hard and requires excellent discipline, why bother in the firth place, and why not go with a rougher board and the micro status checks only ?
Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points.
For actually tracking the progression of the sprint we have a secret Slack channel that management can't see.
This way we don't have to explain to a spreadsheet monkey why the burndown chart looks like a skyline.
> Our JIRA board is being gamed for management. Our sprint burndown chart always looked terrible because management changed things around mid-sprint by adding issues or swapping them around. So we have a fake JIRA board that has a perfect linear downwards progression because we keep changing the story points.
This makes me so sad.
The jagged burndown chart should be the perfect tool to explain management that you didn't finish the sprint BECAUSE MANAGEMENT CHANGED OR ADDED THINGS, and so visualize the cost of such actions.
Yeah but tools almost always provide automation hooks. You can configure status to update on branch creation, PR creation, merge, deploy, etc. Always be automating.
I'm a big believer in "using the tools engineering is already using" but you need to also have a culture of including status updates in bugs. Developers typically are used to putting developery stuff in bugs, not statusy stuff. Crash logs, stack traces, commentary on possible root causes, diffs, etc. you can always find in the bug history. But updates? Not so much. Even a little "UPDATE: Root cause found, fix in progress, ETA 2 days," which takes 10 seconds to write, would make your Project Manager love you and stop him/her from inadvertently interrupting you out of the zone.
Developers don't want to give you ETAs, especially not for bug fixes where 90% of the time they have no idea how long it's going to take. I've never seen developers volunteer such estimates - they always have to be demanded (and are often wrong, hence the reluctance).
I agree.. it’s not something that comes naturally. Encouraging this kind of culture/discipline is hard, but worthwhile. I think it’s better than the alternative of getting hounded by PMs all day. Like it or not, estimation, deadlines and status updates are part of any commercial engineering endeavor. I’ve never worked at a place where “It’ll be done when it's done” is the way.
They are purely for management to feel like they useful and making a contribution when they mostly aren't. And with the stand-up/scrum mindset we get to waste everyone else's time too. I don't have a single example where another developer's stand-up update was useful to me. I don't even pay attention. I almost never know what I'm actually going to be working on at the beginning of the day so I just guess. That too is management's fault as they shift priorities constantly. The whole status update meeting is a waste of time. And it's not five minutes anymore it's thirty to forty five destroying peak concentration time in the morning. Because they are so early, I usually finish early and lose the peak concentration time in the evening instead of sleeping late and focusing on work at peak times. Then managers wonder why things take so long when they destroy every morning and every evening of work. When you treat and mistreat people like robots, you get shitty work. Yet management is oblivious and trying to change or even communicate this to them falls on deaf ears. Well they reap what they sow and it's a shit crop.
Great point. The tools are there to make life easy for developers. Even after using these tools, PM need to do checkins with team then I think something is very wrong in terms how PM is handling the team.
Here is a missing advice in the art of interrupting software engineers: don't. Use asynchronous messaging, not alert-based messaging. Send emails. Make sure they read emails once a day and only interrupt if your question is really more urgent than that.
Thanks.
Daily meetings are not good. They waste people time and constitute an interruption. If you can sync the whole team so that the meeting happens on the morning before people start working, that's better, but still not good as you are imposing a schedule on a team that may know better.
I just finished a deadline at 2 am yesterday. My team is sane and did not expect me in the morning today (joined the slack around 11 am). Would not have done that if I had a daily at 9:30 am. I would not only have missed the deadline but the daily would have even further delayed it. What's more, I would have spent some time preparing it because I would feel I need excuses ready in case someone starts a blame-game.
If developers time is precious, don't waste one hour per day on dailies/daily preparation.
16 people in the daily, 1 hour every day (because we are 16). That means 16 man hours a day are for the daily. 2 people work full time to have the daily. Crazy.
One trick a lot of PMs and other managers don't seem to understand is to listen and really understand what people are dealing with. If people are complaining about something then listen and see if you can improve the situation. It doesn't help to constantly ask "When is it done?" but you should ask "How can I help?". And then really help and don't just set up more meetings that don't result in anything.
Also, learn how to use JIRA or whatever tracking is being used. In my company managers doesn't bother to look at the JIRA board so you end up reporting the same thing five times to different management levels.
In short, be less controlling but try to help and treat people like professionals who know what they are doing.
There seems to be a lot of misunderstanding about this article.
First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams:
1) All production programming is done in pairs, all the time.
2) Everybody sits in a shared team room at dedicated "pairing stations."
3) The atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.
4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.
5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance.
Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view.
This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.
I didn't even get halfway through that description of an XP workplace before the little voice in the back of my head started screaming and it still hasn't stopped.
Haha, me too, the voice in the back of my head pleaded, "Make it stop..!"
Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach.
However, every point in the description of an XP workplace sounds like torture. Paired programming, in a shared room, always a "low buzz of conversation", requirements not written but verbal only.. To be fully engaged and productive, I need the exact opposite.
I'm an engineer at Pivotal, having returned after a few years at startups, both practicing XP and not. The part about verbal-only requirements couldn't be more incorrect. Stories might start as a title and a sentence or two description, but more often than not here they get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down.
Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :)
EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.
Thank you for the perspective! Pivotal does sound like an exciting place to work.
> [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down
Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP.
For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together.
> I also don't really mind interruptions
Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive.
I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.
Yeah I'm not sure where verbal-only came from! We definitely do less upfront specification of say a whole project or months of work - we'd probably call that waterfall style and suggest that likely so many things contained therein will change or be outright wrong that it's better to have just a rough outline, and build definition as work gets closer to being actionable or executed.
I think the interruption thing is interesting - at jobs where I was solo, I probably minded it significantly more. With constant pairing, different interruptions can be handled in different ways. Two-second questions can be answered by the non-driver while the driver continues to focus. Five minute answers should probably stop both members, but having two brains allows you to bounce back into context through re-merging your mental model of where you left off.
Thinking about this though, I realized that in pairing you have internal interruptions as well - if one person needs to use the bathroom or take a phone call, the other can choose to keep working and maintain context. When the breaker returns they can reload their mental models much more easily. Or you can both take breaks and you've already got a built-in ping-pong opponent ready to play :)
> having two brains allows you to bounce back into context
Wow, I never thought of pair programming like that. It sounds nice actually, to let another brain keep the ball rolling while one is busy with something else.
It makes me realize that a big part of my reluctance (preconceived notions about pair programming) is due to having worked alone for most of my career. I never experienced the kind of "mind meld" you describe. I'll remember to keep an open mind about collaborative working methods!
This sounds like the most horrifying work environment I can imagine. I have to assume that all XP developers are extroverts, because as an introvert this would be a living nightmare.
I'm extrovert as hell and I like pair programming...but not having "what are we going to do" written down, combined with a constant hum of conversation in the background sounds awful.
Depends how hard the problem is you are working on? I could totally imagine solving easy to medium problems in that environment. For hard problems I’d probably leave the room and think alone till I have something worthy of discussion
Think of the last time you were in a conversation with 1 person in a busy restaurant. Was it distracting to hear others having conversations? Did it propel your conversation at all, or maybe give you something to talk about? When people talk about the buzz of activity in a busy place, it's really closer to a situation like this.
Individuals doing solo work are often distracted by background noise, and even I do! But in pairs, it doesn't seem to have quite the same effect in my experience.
On the planning part, I know a lot of pairs that set up small daily roadmaps to stay on track. Totally normal, and also totally ephemeral as well. Usually an updated plan is drawn every day since the pair might change.
"constant hum" is quite the understatement. It is often close to a dull roar (from personal experience with "pair all the time in an all-agile open office environment". I quit and went on to better things).
Menlo innovations do pair everything and find most their employees are introverted and like it.
The theory is that introverts don't dislike social interaction but unsafe social interaction. It's why you're generally more social with friends and family.
That's only one type of introvert. The type of introvert that I am wants to be in his own head as much as possible. So even family and friends wear me out after an hour or two and I have to find a place to just be in my head for a while. I love my family and friends and enjoy them, just the experience of being social exhausts me. I don't draw energy from other people.
Left the company for a usual startup setup with your own Macbook, pull requests, and things.
I miss the almost zero friction collaboration.
As a pair. Either of us will point out each other mistakes and suggest an improvements to what we're doing in real time without the ping-pong of pull request.
If both of us can't figure things out. We can just scooch over to other pair workstation, sit in the other chair, use the mouse and keyboard to show part of code we have issue with, point to the monitor, and ask questions.
The whole XP (eXtreme Programming) movement came out of the Consulting domain. "jasim" in this thread explains the context where it makes sense. The company i had worked for had jumped on the XP bandwagon when it came out (we even had Kent Beck, originator of XP himself come out and do presentations!) but i never saw anything unique about it. It was merely a systematic way of working much more closely with the Client and doing rapid implementation iterations towards the known requirements which all experienced Engineers/Managers/Companies were already doing. Except it wasn't a dogma with them but adaptation of a sane process to a context. I always thought of XP and its successors as marketing by successful Consultants rather than any true insight.
You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.
I depends on who you talk to. IMHO, the most important thing is that every single story has to have "business value". In other words, it has to have something where if you put it up on a board and said, "My team did this today", anybody in the management structure would say, "That's wonderful news". I also feel that you should try to have stories that average between a day and two days in length -- so it's pretty darn tough to think of ways to meet both criteria. These days, I'm unable to due pure XP, but I often find that if I manage to build a backlog like that, then it barely matters what else I do: it's going to be successful.
The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience.
Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!"
Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks.
One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now.
For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try.
To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".
I am a huge fan of attaching a "business value" to everything the team does. I also see the value (for everyone involved) to frequently collaborate and think about these things.
But where the article proposes to ask all the developers for updates three times a day, I prefer the approach where the developers "pull in" their product managers when they need them, instead of the product managers "pushing" their views onto them multiple times a day.
This is why I was asking - I still don't fully understand if this is a "XP thing" or not.
I don't know what I'm going to need next week let along 3 months (or whatever) from now.
Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast.
I'd say customers being able to stick to a coherent story about what they want for more than a week would be a key need in any successful IT project.
Not necessarily. The idea here is that the customer has an idea about what he wants, but has only a vague idea about what he actually _needs_, and no idea about what is technologically possible.
Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.
But you can nail those things down before coding begins, just through talking with them. You don't need to literally change the code completely every week - iterating a plan is much easier than iterating a codebase!
Not necessarily, and it really depends on the customer and on the software. You feed the learnings from one iteration into the next - it's not intended to change the code completely every week, but to allow maximum flexibility in the backlog.
There is a difference between not knowing what I need for an API next week and not knowing (vaguely) what I need for the business. My backlog stretches out about 4 months at the moment, but I don't do technical design until much, much later. But as a sibling post rightly points out, not all of the stories on my backlog are going to get done. 4 months is a long time and the business is hopefully gathering more and more data about what it needs. Frequently opportunities arise that overtake what I have in my backlog. Since I always have more in my backlog than I can actually do, that means that the stuff on the bottom drops off. If I were to estimate, I would say that about 1/3 of my 4 month backlog is practically 100%. It drops off to 0% by the end.
This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.
It's on the engineering blog of a company trying to hire a ton of developers at the moment and it reads like the most toxic work environment imaginable to anyone who doesn't have that context, so perhaps the author and the team who approve blog posts should have made that MUCH clearer.
The hardcopy print edition is available from Amazon or directly from O'Reilly, if that's what you mean. There's a link to the Amazon listing at the URL I gave you.
As far as I know, there's only one type of printing, and that's a lay-flat softcover.
4) sounds like a recipe for disaster if the product is large enough. Nobody can remember everything. Heck, I start writing a text document when something gets too big for myself.
But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction?
4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.
There's still something written down, just not massive amounts.
Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development.
Otherwise I just communicate a lot.
Things get differently from what I invisioned, sometimes they're worse sometimes they're better.
An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large.
Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.
Having followed the process as described, i'd agree. If a project runs for more than a few months, you forget why decisions were made. I don't think XP in general has a great story about how to deal with this.
I'd be less worried about "forgetting" and forever worried about a manager just saying "you obviously forgot (something I just decided)". I mean it happens even when there's documentation I can pull up and say "well actually..", I'd hate to imagine otherwise.
I've been reading a lot on focused work and this sounds like the exact opposite of what's supposed to happen. I can't recommend Cal Newport's book "Deep Work: Rules for focused success in a distracted world" enough.
He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science, per Cal Newport, suggests.
He also points out that collaboration is perfectly acceptable during deep and focused work, but this doesn't sound like how it should be at all.
I can second the recommendation for Deep Work, but it’s not the end of the story. Richard Hamming points out in You and Your Research that the researchers who were open to distraction tended to do a better job figuring out what to work on. In Programming as Theory Building, Peter Naur argues that the primary focus on a programming team should be developing a shared understanding of the problem space in which the program will operate.
While I’ve never worked in an XP team, the description here sounds like it’s primarily focused on making sure the individual members of the team aren’t accidentally working against each other. For projects that aren’t reliant on the sort of insight that Deep Work is teaching us to generate, the team cohesion may be able to make up for the hit to individual productivity.
> This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.
No, it isn't. A PM should be having these conversations - briefly! - in front of the rest of the team in the standup, and in more depth in a weekly planning meeting.
If a PM feels a need for updates more often than that, then that is a problem of theirs that they should work in in their one-on-ones with their manager, not something they should dump on their team and then blog about.
It's sad that a PM at Pivotal has gone adrift like this, but it's tragic that this shitty advice has made it to the company's blog.
> 1) All production programming is done in pairs, all the time.
I stopped right there. My personality is such that being social exhausts me. Don't get me wrong, I like people, I just can only do social for short bursts and then I have to recharge. There are people who get energy from other people, so this might work for them, but not for me.
> 4) Requirements are conveyed verbally, not through written documents.
I can't even begin to imagine the sheer amount of meetings and "chats" that would need to take place on a regular basis just to keep things moving along.
I admit to knowing very little about XP but this sounds like my own personal hell.
254 comments
[ 3.5 ms ] story [ 259 ms ] threadHello Peter whaaaat's happening?
Just use scrum as intended, maybe push for more detailed updates if devs are just saying stuff like "still working on x". Or just trust them and don't try to babysit.
https://www.youtube.com/watch?v=jsLUidiYm0w
At the moment I have been on a solo allocation for about 6 months. It has let me go down a lot of rabbit holes, which can be educational. But I miss pairing pretty badly on days when I am working on straight regular development.
That said, it really isn't for everybody. But you may want to give it a chance.
If you put two random programmers together and ask them to "pair program", you'll very likely end up with two annoyed people at the end of the day.
I was lucky in being mentored into it by some very seasoned pros, and I learned the tricks of the trade that way.
However, it's like therapy: being forced to do it instead of doing it by yourself will result in a terrible experience.
I'd rather have breakfast with my family and bring the kids to school.
Harassing engineers
> why are they getting paid for it?
Engineers got their work done despite the micromanage (to be clear, I mean despite and not because. Just in case any PM or manager is reading this and thinks micromanaging is why tasks get done)
Of course, it relieves stress and stuff, but if you're THAT stressed because of the project and need constant reassurance from the engineers, you're clearly in the wrong job.
I had to lead a few engineering teams (wasn't a PM, though) and the only approach that ever worked for me was to check things out in much larger intervals, a week, sometimes even more. Actually treat engineers like adults and be an adult yourself. Let them come to you if they have a problem. Sample the progress in much larger intervals in order to reduce noise.
Micromanagement doesn't do any good for anyone.
I especially can't imagine working with this one. Imagine constantly having to revise estimates and getting micromanaged by someone who isn't your manager. The "role responsibilities" conversation would happen very quickly
I find it especially ridiculous that this person is interrupting people two times a day for fresh updates on top of a daily standup. And they even admit their technical knowledge is not good enough to actually be able to help much if there is an issue. If you are bothering and interrupting every single person on your team multiple times a day just in case you need to increment a number in a JIRA board now instead of tomorrow morning, you are wasting people's time. Leave it to the standup.
Your job as a PM is not to micromanage engineers. If that is anybody's job, that is the engineers' managers. Your job is to make the engineers more productive and make sure they're working on the right things - but not at an hourly granularity.
We're known for it, it's part of the interviewing process for Labs and most of R&D. Folks who don't want to pair generally don't apply. Of those who apply, some try it during the interview process and decide it's not for them.
That is a good thing.
Besides which, solo work is common too. Most of the field org works solo, Spring folks mostly work solo, I love pairing but currently I'm working solo. If a pair decides they should work solo, they do. Lots of pairs have a rotating arrangement where somebody different works solo for a day or two. I know of teams where they are solo in the morning to review PRs and pair in the afternoon to work on new contributions.
None of this is enforced. There is no manual, no rulebook for The One True Way. Nobody tells you how to work. The way works is: the people are nice and smart and want to do the right thing. The rest is largely details.
That... sounds like forced to me?
And as I noted above, pairing isn't mandated. Teams are free to adopt any process they please, but most folks at Pivotal like the defaults and we tend to gravitate to them.
Pairing was optional, but the team chose to do it, so everyone on the team had to do it.
It wasn't "forced" because I "always had the option to quit the job".
It was hell.
Especially to those on a visa, the only one forcing you to remain in the USA / Bay Area / x company is yourself. To put it bluntly, no one is entitled to a job, and this applies to every person. In this scenario, it's not like strangers are being pulled off the streets by Pivotal to pair program.
Suppose an employer asks a loved one to have sex with them or they lose their job. I mean, no one is putting a gun to your loved one's head to have sex with their employer, but something is clearly very wrong at this level right? Suppose they have an expensive debilitating medical condition that can really only be treated with good insurance (I have seen this firsthand where a medication can cost hundreds a month even with insurance (not great insurance but I was an intern, it was all I could afford)). Suppose they tried searching for a job with comparable insurance for years but always come up empty. Now when it's between whether or not you will go homeless with a debilitating medical condition or basically being raped, what would you choose? Frankly, I would rather be raped. I have been in the hospital with great insurance as well, when my condition was at its worst, and even morphine and norco did nothing to make the pain go away; I can only imagine how much worse it would have been on the streets with that kind of unending pain; I can only imagine never being able to find a job like that ever again because I will always be in unending pain and never be able to interview well. Fortunately, I got really really lucky in that I am an engineer who is an American citizen that can find jobs easily that dont require me to physically be there but, most people are not in my position. Back to the point, if someone is more willing to be raped than to not be raped out of fear of the consequences, that's pretty damned close to forced right?
But if I worked for Company X and then one day Thou Shalt Pair Or Else, then yeah, it would feel shitty. Labs developers pair with client developers on engagements and sometimes it feels like they've been dropped from a very great height.
Most of the time it works out fine: people are people and we work in the same industry and share many of the same experiences and passions. Sometimes it just doesn't work for everyone, which is also fine.
But insofar as anyone from Pivotal is explicitly or implicitly saying "or else!", I think they are making a mistake and hope they get feedback about it.
R&D leadership otherwise pretty much don't interfere. Their main business is explaining our strategy, keeping the lights on and teams connected and adjusting allocations between different product and component teams.
We totally did force pairing on client developers, though.
What I meant is since Pivotal is known for uh voluntary-enforced? subscription to XP religious practices you can’t really expect it not to bleed into all aspects of dev process.
Btw I have nothing against pairing in general, just not the way Pivotal does this.
But yes, pairing is very helpful for maintaining context when interruptions occur.
Moreover, I recently fell into the trap of working for an entire week nonstop to solve a really hard problem. Took a few hours off one day to clear my mind and when I came back, I had the problem solved inside of an hour. If I continued down the route I was going down before that time off I can guarantee you it would be more days wasted.
IMO a good product manager does not focus on trying to understand _why_ things are hard, but rather _what_ things are hard.
With this understanding they can either 1) work to change scope/requirements so that the bigggest user pain points are solved ASAP or 2) accept that more time than anticipated is required to solve user problems.
Implicit in all of this is the trust that when engineers say something is hard, it is actually hard.
When I see the author talking about paranoia, trust is the first thing that comes to mind.
To be fair, I don’t think that trust is easy. But I also don’t think that effective product management is possible without it
Edit: why is the trust so one way? I’m just expected to trust them, but I have to earn theirs like some kind of untrustworthy child?
...or even more...
edit: at the most, I think async are passable via slack or something similar. Otherwise all data on this can be easily done via a Kanban board.
- sync up / status is 15 mins. Any implementation discussion gets put in the parking lot
- once we've gone around the table, the rest of the meeting is handling the Q&A / parking lot we parked during the status discussion. Anyone not directly concerned by it is encouraged to leave, get out and be productive!
This gets you the double benefits of interrupt coalescing (a single regular interruption instead of 2 smaller ones where one is an irregular surprise), and preserving the quickness and relevance of the stand-up, as it's really just the first 10-15 minutes of the calendar slot, after which you're good to leave.
In my experience, the need is to provide a clear method of communication and ability to unblock one another. A Kanban board is perfect for this, as well as committing to a definition of done.
Anything else... is very wasteful in my experience.
Also if a teammate is actively working on something that is a downstream dependency of something I am working on, then I can passively learn about requirements and expectations for my own work, become aware of issues ahead of time, etc.
1. For transparency any member of the team can identify blockers in Kanban by putting them in the blocked column. 2. If you're blocked, and running into issues, you'd reach out to anyone that can help you. Why would you wait for a standup or "talk to the wall" for that? Just be proactive.
Dependencies should be known before committing to a scope of work (iteration) with the team. Planning stage (minimal time investment for scope of work definition) vs committed work stage (in progress iteration).
At Pivotal we see the PM as part of the balanced team. The PM, just like designers and engineers, will have the daily standup, weekly retros and planning meeting together. The goal of the standup is to share what of interest happened yesterday, if help or opinions are needed and discuss pairs for the day. Sometimes discussions start about topics mentioned in the article where it's crucial to have the PM there.
Standup should usually be around five minutes. That's the reason it's not a sit-down meeting.
My view is that a PM is available as a resource to clarify as needed. Meetings between the "doers" of a team and the PM should not be forced, especially daily. This leads to micromanagement and changing requirements too often.
But alas, everyone has a different philosophy. :)
My personal preference is for very fine-grained stories rather than giant chunks of acceptance criteria. The latter tend to turn into week-long wanderings and get edited over and over. Whenever I've been able to I've coached PMs towards smallest possible units of value.
Changing requirements should only happen outside the scope of committed work; otherwise you're building churn, poor features, and poor code.
This lever of "committed work" can be adjusted per team (1 week, 2 weeks, 4 weeks, and so on).
It seems you agree with my view of a minimum of 1 week before it can change.
I agree also with fine grained tasks/stories. As small as possible and as consistent as possible. They should all have clear DOD's though.
Definitely agree with smallest possible units of value (that also varies per a person).
Finally! A sane voice appears!
*status report
> My team meets for 30 minutes each morning
That is far too long IMO and IME
> We're a small team (3 developers)
30 mins for 3 devs...
As an anchor (approximately a tech lead) I made it my business to work closely with PMs on the product: giving feedback on how the technical direction was shaping up, asking for stories to be updated or broken apart, giving options for technical seams and so on. Frequently we embed product designers as well, so discussing design options and asking for modifications was common.
But when I was pairing with another engineer we did whatever was on the top of the backlog according to our best judgement and with attention to quality. If it needed refactoring, we refactored. If we felt that would be better to wait, it would wait.
The most important discussion, I found, was about chores -- work that engineers view as paying dividends in future velocity. Our view is that engineering is the ultimate owner of chores and can schedule them according to its considered discretion. The system works because of trust. I trust that product managers and product designers will be diligent in identifying user values and priorities. They can trust us to do what needs to be done to make the software to a sustainable high quality.
I remember once I was rotated in as anchor for a product that had begun to struggle a bit. In particular we had a particular giant tech debt: we had fallen behind on React versions. Worse, there were three parts of the codebase using React, in three different ways. With my peers I decided that we were going to fix it. "I think it will take one pair week", I remember saying.
It took five weeks. But nobody ever said: stop, you work for me, my way or the highway. We talked about the reasons. This tech debt would only grow as time passed. There was no good time to repay it, so sooner was better than later.
We were trusted to do the right thing, so we did the right thing.
I don't want to read any further. Surely it doesn't get worse than that!
/s
But more to the point: it slowed development. I could deal with a bit of visual glitchiness, but my job as an engineer is to create software to solve problems. Piling hacks on top of hacks doesn't do that and it's shitty to the next engineer who joins the team.
As I noted in another comment, I would give feedback to a PM that this kind of checkin isn't necessary and try to understand how to help foster trust.
At Pivotal I have worked with 9 or 10 product managers, none of whom have asked during the day how things were going.
If anything I would be the one interrupting them.
Of course there were "emergencies" and things so it was more like a team standard than a rule but it was phenomenal. When I got to my desk in the morning I always knew I'd have a solid block of time to get through the important work before I had to go to a bunch of meetings and take on more.
Going and pestering the team is only going to slow down development process and increase the likelihood of the team not delivering for the sprint.
Tracker is able to give short-term forecasts of what will be done by when by averaging the last 3 weeks of deliveries (ie, velocity).
Personally I think the idea of sprints is a menace. It creates an artificial deadline that leads to either waste or stress. Deadlines should be reserved for actual meaningful deadlines.
It's just that I've seen the evil twin version of sprints far more than the official version.
With that in mind, sprints can work pretty well, and work "spilling over" to another sprint is generally no problem. It starts falling apart if the artificial deadline becomes a forced deadline, or if the protection part is dropped.
Indeed. I got about that far before I quit reading and started fantasizing about the unspeaking things I would do to the idiot that wrote this if I ever met him. Things involving sharp blades and fire.
This is monumentally bad advice.
> I try to find a time when a pair does not seem to be heavily focused. Some of the cues might be they are having a casual non-work related conversation or are just returning from a break
So surveill and/or eavesdrop and/or ambush. Nice.
> Hadrien Raffalli is a Product Lead at Pivotal.
Here's me thinking it's probably a more junior PM doing this. Nope, it's a Product Lead.
PMs/TPMs can be great, if they are good. I've worked with some that made my life easier. I've worked with others who really didn't.
Based on this article alone, Pivotal's PMs would make me quit.
Pivotal can deliver things to customers in spite of all this (given that it’s surely not because of all this), which sort of makes any advice published out of there fundamentally irrelevant for people working pretty much anywhere else.
I have a lot of experience with XP. In my experience, XP succeeds because of its extremeness, not despite it. It's not for everybody, but for organizations and teams such as Pivotal who are willing to understand and embrace it, it works very very well.
So I challenge your "given that it's surely not because of all this" comment. Do you have any evidence? Or are you just saying, "I don't like this, so it can't possibly work?"
The kind of "pairing all the time" kind of XP that is being preached is similar for programmers. It also works for repetitive work - building yet another web application - at scale, not at scale, not much of a difference. But programmers often get into the job because it is an inherently creative field. There is nothing like this kind of XP to suck it all away and leave them disillusioned about the craft until they escape and find a product role or even a consulting company with more empathy and kindness.
However, we had a few guys on our team that really didn't like it. They left and I don't think less of them in any way. It's a different way to do things.
As for the "repetitive work" aspect: the most successful XP project I did was a collaborative sketching application using pen input with automatic shape recognition: somewhere around 2000 (when did MS put out those pen based computers??? -- We did it for their unveiling).
The problem though is the Agile Industrial Complex and "thought leaders" who have pushed this as a religion on the industry. I enjoy pairing, and the excitement of two minds working at the same problem in tandem is an experience to be relished. But give it to an Agile snake-oil salesman, most of whom gravitated away from programming a long time ago in favor of making money training others in how to program, and they'll wield it as a weapon by prescribing the only true way to work.
XP (in its traditional sense) doesn't scale past 8 developers anyway. Anybody selling you XP for a team of 500 is someone to be wary of ;-)
There are pains and giving folks the opportunity for change/rotation is refreshing.
Software is a team sport, its a weak-link game where we must communicate and empathize in order to see clearly (often past our own egos) in order to pull one-another up.
I was fortunate that good pairing hygiene was a focal point. Without that it can be disastrous mentally and ruin the experience for everyone. It turned into a highly collaborative sport at that point.
I am a hugger naturally but when I run into those pairs I went through the trenches with, it is a brother/sister hug. Best time of my life.
There’s also a survivorship / selection bias inherent to companies with extreme views like this. Either you both (a) agree to cheerlead & display positive affection for the religion and (b) display effectiveness in the role, or else you will quit or get fired or self-select to never work there in the first place.
So in a large part, it’s literally unknowable to what degree success is in spite of vs because of these extreme practices. There can’t be evidence about it because by definition there is the confounding factor that the employees whose productivity you measure are only from one specific sub-population (likes extreme view & delivers good software). You never get to measure what people with diverse opinions about tbe philosophy would do in the role, and you never get to measure what less successful developers would have done in the extreme philosophy.
The same effect happens with extreme coaching philosophy in sports, where again after you apply the filter that the players are selected to both be very good and accepting of the philosophy, there’s no way to measure the counterfactual possibilities, so it reduces to religion.
It would be an inconvenient time for an interruption, and probably looks quite a lot like returning from a break.
That having said, my personal preference is also the scheduled 15 minute meeting.
Maybe that's the idea - "He always ambushes us when we come back from a break... we'd better stop taking breaks!"
Programmer 1: Whoa, that two hour Pomodoro was quite something.
Programmer 2: We got a ton done, though.
Programmer 1: Yeah! I hope they have the lasagna again at lunch.
Project Manager: Hi, are you getting your work done? If you could get back to work, that'd be great.
The only case where I want such frequent updates are when (1) there's some P0 bug on production and it needs to be fixed / tested / deployed yesterday or (2) we're trying to pressure the person to want to quit their job or magically improve (more the former than the latter).
I'm not a PM but I sympathize with how difficult it is to discern where a project is up to when it comes to software, especially when you can't come up with short enough milestones...
They see this and it fits a pattern and so they are fairly skeptical.
Those responses usually upset me, because I feel that my experiences are being devalued. I read the comments and I compare them to my life of the past five and half years and they just aren't the same. It can be hurtful to have casual snide remarks made when you know that the people you work with are kind, thoughtful, intelligent, hard-working humans through and through.
But I also know that other people have had bad experiences and what they hear sounds like other things they've heard from shitty managers and colleagues, so they're cynical. If I talk down to them then I am devaluing their experiences. So I try not to, even though my personal nature is to be an arrogant wanker.
Context switches are annoying to the engineer and costly for development. Each context switch probably costs between at least 15 to 30 minutes, maybe more depending on what the engineer is working on. If that happens 4-6 times a day, you've potentially burned 1/4-1/3 of the day. I spent close to 3 hours in 3 unrelated meetings. So, 1/2 of my day was spent task switching and not really giving 100% attention in the meetings because of the constant task switches. Frustrating and don't feel like I made any progress today, on my first day back on an overdue week long vacation.
1.) Treat them as engineers who are capable, able to communicate problems or expected delays, and professionals who want to grow. 2.) Treat them as assembly line workers who constantly want to screw around and need to be whipped back into shape.
I'd argue maybe a third is the startup mentality where you need to sell your life to the company, but maybe that's a mutually exclusive thing.
In my experience, the second comes from the same mentality as the old waterfall companies. Spec everything, trust no developer, micromanage, etc. Developers are a risk, not an asset, and never trust them at a management level. I would never work for a company like that, and avoid them like the plague.
Regardless, both of the views above seem to be a self fulfilling prophecy. Professional shops who treat developers as engineers produce some quality stuff and usually on time. Sweat shops have a lot of failed and over-budget projects and a high turnover.
Fred Brooks said "plan to throw one away, you will anyhow". He was mostly talking about the value of prototyping or what in some circles is called spiking.
> I suppose if you write a lot of the same kinds of software you can estimate up front pretty accurately though.
Not in my experience, and I'm a pro-estimate loony. A lot of products and problems do have fairly predictable elements and it's possible to give useful estimates (eg, add new form element, needs a new field in the endpoint, new column on the table, some validations, tests for the above, no changes to docs ...).
Other problems are closer to pure research and you just accept someone might come back with something some day.
What we argue about in software circles is how wide valley in the middle is.
I think an engineer needs freedom to be able to exercise judgement say "I don't understand this task well enough to estimate it yet."
Why? Speaking from personal experience, when I was a recent grad and got asked for an estimate, said "I don't know" and then got pressed for one, my thought process was "okay... I guess I'll just come up with a number and double it" because thats the advice I'd been given multiple times. This resulted in an estimate that had no relationship with reality and which I knew had no relationship with reality. This was not helpful for communication because...well because it was a lie. Thats the key: unless you give someone the freedom to say "I cannot yet give you an estimate", you can't know if the estimate you get is a lie.
Establishing this freedom is hard:
* One reason that it can be hard to give estimates of simple tasks like adding a new form element/adding a new field in an endpoint/adding a new column on a table is if you don't yet know your tools well. But it can be rather embarrassing to admit this. So the engineer can be reluctant to exercise the backbone to claim this freedom.
* There is a lot of moralizing around estimates. The article On Being a Senior Engineer[1] says "Avoiding responsibility for estimates is another way of saying, 'I’m not ready to be relied upon for building critical pieces of infrastructure.'" so admitting that you don't yet know how to estimate might be admitting that you should be fired.
* This is hopefully an uncommon case, but an engineer might have been unwittingly hired as a senior engineer right out of university because their recruiter told the business he'd known the engineer for years. This exacerbates the previous point.
* A business stakeholder really wants to have an estimate, even if the reality of the world is that engineer can't give them one.
* There aren't any resources for new engineers to learn task-estimation[2]. So if one of your engineers doesn't know how to estimate tasks, you might worry that they'll never learn how, since coaching that engineer to learn estimation is too time-intensive an option for most companies.
* When an engineer is asked "how long will this take?", it isn't obvious from that question that the estimation process requires first identifying the key pieces of the task and the riskiest pieces of this. That relies on knowledge of how to produce estimates: understanding that they key piece of estimation is not the number you get at the end but is the mile-markers you produce along the way.
All of these difficulties hurt the key thing required for a good conversation around estimates: trust. Trust that the person hearing the estimate knows that there is uncertainty. Trust that the engineer will flag up if they run into a pile of complexity.
[1] https://www.kitchensoap.com/2012/10/25/on-being-a-senior-eng...
[2] Demystifying the Black Art by Steve McConnell is about project estimation, which assumes you can already estimate individual tasks.
Absolutely. This is itself a valuable estimate. Very occasionally engineers will give a very high points value to indicate that the proposed story is simply too complex as written and needs to be decomposed further.
> Establishing this freedom is hard:
It absolutely is. Everything we do at Pivotal that works well is actually hard. Our cheat code for bootstrapping these practices is that we already bootstrapped them years ago. But maintaining a culture is harder than building one, which is a trillion times harder than improving one.
What I have witnessed in those hip, agile young companies is that you have to report exactly what yyou have done, what you are plannign to do etc. constantly. At least once a day, plus whatever other weekly meetings you are in. Sometimes your entire day is filled with meetings and you are supposed to fit your actual work somewhere in the breaks. And if you can't finish a task in a day, you trigger extra attention from managers and suddenly you find yourself sitting at your desk with another engineer and a manager looking over your shoulder, wasting hours of expensive time instead of letting you work.
Those are the two extremes I have encountered and they are only annecdotes. But they do serve to show that the development process chosen for a project is not tell you anything about the management style.
I have worked for another large telecom that treated its developers great that did kanban.
Currently I work for an agency that really does neither. :-D
But I think you're right, the methodology doesn't matter nearly as much as the managers.
The whole point (at least at Pivotal) is to spend more time coding/designing/testing and not in meetings.
It wasn't like this before fads like XP, Agile, Scrum etc. and micro-management became mainstream. Most of the current management done by PMs and their ilk can be easily categorized under "Bullshit Jobs" (https://strikemag.org/bullshit-jobs). The problem is that once somebody has codified their experience under a catchy title and started marketing it, people blindly follow it without understanding its context and applicability. Given that the barrier to entry to these sort of positions are so low (you can become a PM without any sort of domain knowledge!) people who might not cut it as Engineers seek these jobs to boost their pay, power and egos.
PS: The above might come across as a little harsh but unfortunately is the reality for most Engineers.
Damn... is it too late to go back to college and study electrical engineering?
Problem is it also takes the developers who are 8,9 and 10s and turns them into 5s too.
If you have lots of 2s and 3s this is probably fine. If you have more 7s, 8s and 9s it's a problem. For a start the better developers will end up simply leaving as working conditions are too hostile.
Most developers are < 5 / 10 skill wise, so these silly methadologies become stupidly popular.
The brutal truth of software development is that the quality of your output is going to vary with the quality of the engineers you work with. Good engineers don't need daily standups to build great products, and bad engineers aren't going to be helped by doing twice-daily checkins.
Checking in with a pair isn't a status update, it's really about collaboration and visibility. Estimates are often wrong, assumptions get tested, the team dynamic is "let's ensure we all understand this".
Stories in tracker tend to be <1 day, so checking in occasionally isn't exactly a wrong thing (every half day to me is excessive), so priorities can be shifted, or big stories can be broken up.
Second of all, I've seen two kinds of product managers. One kind looks at software development estimates as commitments to be contractually adhered to. The other treats software development estimates as assets/investments with risks to be managed.
Which kind is more effective? Well, which computation accomplishes more results, the one that doesn't halt and logs the same line over and over, or the one that does halt and additionally does the thing it set out to do?
People who end up in manager roles tend to be people persons and some use very touchy-feely language. I'm personally put off by all the references to his own anxiety as just one example. That doesn't necessarily mean he's actually a terrible manager.
Part of his job is to make sure things get delivered in a timely fashion. If that's not happening, then feeling stressed by it isn't unreasonable, but the article sounds like he's just trying to manage his emotions rather than get deliverables from his people in a timely fashion.
I'm not posting this to dog the author. I'm posting this to suggest that his framing may reflect the fact that his job involves managing people rather than things.
If it were framed differently, the exact same practices might sound much more reasonable and palatable to people here on HN who are overall reacting fairly negatively to this.
>The idea that programmers are not good with people is, in my observation, a self-perpetuating stereotype
It was never true. It is a TV/movie stereotype just like the term "Hacker".
It's not really about innate social skills per se. A lot of social stuff is learned behavior anyway.
As a PM of about 4-years of experience, I understand the author's concerns and at the same time believe that he has solved for the wrong problem; his own anxiety rather than team cohesiveness and trust. The issues he solves for can be solved in different ways without such a negative impact on the team, actually in a very positive manner that increases trust, cohesiveness, and user context.
I'd first like to point out that I've made the mistakes of micromanagement that he mentions in the first section. I also quickly learned how detrimental that behavior is to team relationships, productivity, and outcomes. I'm certainly not perfect!
The way the author solves the problem of pace is by creating regular check-ins every half day. He then goes on to identify, how these check-ins can be used as open to monitor common slow-downs: engineering struggle and product context (he calls is product debt).
I'd first like to make the point that some other engineers have commented here, estimates are estimates, we are agile, you learn things along the way and need to adapt. I believe your job as a PM is not to hold the team to estimates, it is to come up with creative solution and serve as a master facilitator on your team.
So when the author says the following I can't help but notice the irony. I'd explore us all to practice what we preach. Instead care about iterations (sprints) not task micromanagement:
"As a product manager (PM), I often make assumptions as to when a particular user story will be delivered. This is painful because I don’t believe in time estimates and don’t think I should be involved in estimating the relative complexity of a story since I don’t own its implementation.
I know I shouldn’t but I can’t help doing it anyway…"
So how do you solve the problems that the author points to "struggle" and "context" without adding interruptions?
• For struggle, that is what standup is for. Not only standup, but if you create a culture of trust engineers will naturally reach out if they hit road blocks, make a slack channel for your team. It's even better if you can teach your team about red flags, things that the article says which are true to look out for: complexity is rapidly increasing, not feeling confident in the stack/codebase. For any of this to work you MUST create a culture of questions and answers. Yes, all want to look competent, but what's also great is being able to depend on your team.
• Adding to the previous point, this is why small tasks are soo important, [read this book on product flow](https://www.amazon.com/dp/B007TKU0O0/ref=dp-kindle-redirect?...) if complexity is small to begin with you can avoid that issue AND you get the added benefit of smaller iterations, meaning faster red flags. The author points this out too, this is critically important.
• For context, context is king. Want to avoid "Product debt", get your team/tech lead involved from Day 0 of your quarterly/yearly roadmap, they should know everything about the user that the PM does minus the RAW research effort. Run a Kickoff/Inception/IPM that truly integrates your entire team, every engineer should have product context. Devs will then see tricky edge cases, radiate them up to the PM and you can make a call together if the work is necessary.
All of this is to say that there are some good parts of this article, but I think that adding one more check-in is not necessary when there are other ways to solve the problems identified.
It's like that episode of Seinfeld where Kramer pretends to be Moviefone. "To update the status of your ticket, press 1 now. .......... Why don't you just tell me the status of your ticket?"
For actually tracking the progression of the sprint we have a secret Slack channel that management can't see.
This way we don't have to explain to a spreadsheet monkey why the burndown chart looks like a skyline.
This makes me so sad.
The jagged burndown chart should be the perfect tool to explain management that you didn't finish the sprint BECAUSE MANAGEMENT CHANGED OR ADDED THINGS, and so visualize the cost of such actions.
Thanks.
Daily meetings are not good. They waste people time and constitute an interruption. If you can sync the whole team so that the meeting happens on the morning before people start working, that's better, but still not good as you are imposing a schedule on a team that may know better.
I just finished a deadline at 2 am yesterday. My team is sane and did not expect me in the morning today (joined the slack around 11 am). Would not have done that if I had a daily at 9:30 am. I would not only have missed the deadline but the daily would have even further delayed it. What's more, I would have spent some time preparing it because I would feel I need excuses ready in case someone starts a blame-game.
If developers time is precious, don't waste one hour per day on dailies/daily preparation.
Also, learn how to use JIRA or whatever tracking is being used. In my company managers doesn't bother to look at the JIRA board so you end up reporting the same thing five times to different management levels.
In short, be less controlling but try to help and treat people like professionals who know what they are doing.
First, you have to understand the context. This person is talking about an Extreme Programming team. Speaking as someone who wrote a book about XP, here are some things that are true about by-the-book XP teams:
1) All production programming is done in pairs, all the time.
2) Everybody sits in a shared team room at dedicated "pairing stations."
3) The atmosphere is highly collaborative and friendly, and there's always a low buzz of conversation in the room. Interruptions are normal and expected, as the team's overall performance is valued more highly than individual performance. Due to pairing, interruptions tend not to interrupt flow.
4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.
5) The team values feedback and wants frequent conversations with their on-site customers (including the product manager) to confirm that they're on the right track, particularly about nitpicky details that are difficult to anticipate in advance.
Given this context, the author is talking about how he, as a product manager, does his job of providing business context and customers' points of view.
This material is not meant for people who aren't on an XP team. It's good advice for product managers who are.
Already from the article title I started to have this reaction. As a software engineer, nothing kills focus and productivity faster than interruptions. From the perspective of a manager, I can understand - and really appreciated the respect and consideration that went into the article and the recommended approach.
However, every point in the description of an XP workplace sounds like torture. Paired programming, in a shared room, always a "low buzz of conversation", requirements not written but verbal only.. To be fully engaged and productive, I need the exact opposite.
Regardless of that issue, XP isn't for everyone, and there's nothing wrong with that. I like it though, that's why I'm back. :)
EDIT: Also, I don't know him, but our writer here seems to think a lot about how he interacts with his dev team, which I appreciate, but think maybe he got into his own head about it a little bit too much here. But I also don't really mind interruptions.
> [Stories often] get written up with gherkin-like Given/When/Then sets of acceptance criteria with additional details/considerations noted down
Very interesting to hear, especially in contrast with the "verbal only" approach mentioned along with XP.
For my personality type, I work best when there are requirements/acceptance criteria clearly specified in writing. Even better if the logic is written in a DSL that all stake-holders can create together.
> I also don't really mind interruptions
Yeah, I see that software engineers come in all colors, and some are able to multi-task while fielding questions and interactions all the while. And others, like me, need more isolation / insulation to maintain silence and solitude to be able to focus and be productive.
I suppose that's a challenge for methodologies like XP. In order to be effective, it needs to take into account the different working styles and personality types that exist in a team of any size.
I think the interruption thing is interesting - at jobs where I was solo, I probably minded it significantly more. With constant pairing, different interruptions can be handled in different ways. Two-second questions can be answered by the non-driver while the driver continues to focus. Five minute answers should probably stop both members, but having two brains allows you to bounce back into context through re-merging your mental model of where you left off.
Thinking about this though, I realized that in pairing you have internal interruptions as well - if one person needs to use the bathroom or take a phone call, the other can choose to keep working and maintain context. When the breaker returns they can reload their mental models much more easily. Or you can both take breaks and you've already got a built-in ping-pong opponent ready to play :)
Wow, I never thought of pair programming like that. It sounds nice actually, to let another brain keep the ball rolling while one is busy with something else.
It makes me realize that a big part of my reluctance (preconceived notions about pair programming) is due to having worked alone for most of my career. I never experienced the kind of "mind meld" you describe. I'll remember to keep an open mind about collaborative working methods!
- Some sort of sound barrier so that I couldn't parse the background conversations.
- To be able to decide "what is our current plan?" and to write that down. Of course you'd change to a new plan in light of new information.
Individuals doing solo work are often distracted by background noise, and even I do! But in pairs, it doesn't seem to have quite the same effect in my experience.
On the planning part, I know a lot of pairs that set up small daily roadmaps to stay on track. Totally normal, and also totally ephemeral as well. Usually an updated plan is drawn every day since the pair might change.
Yes. Its an unpleasantness I endure if I’m not trying to work through anything which is an intense use of my Working Memory.
The theory is that introverts don't dislike social interaction but unsafe social interaction. It's why you're generally more social with friends and family.
Left the company for a usual startup setup with your own Macbook, pull requests, and things.
I miss the almost zero friction collaboration.
As a pair. Either of us will point out each other mistakes and suggest an improvements to what we're doing in real time without the ping-pong of pull request.
If both of us can't figure things out. We can just scooch over to other pair workstation, sit in the other chair, use the mouse and keyboard to show part of code we have issue with, point to the monitor, and ask questions.
You might want to take a look at the original short book "Extreme Programming Explained" by Kent Beck and form your own opinions.
The main thing is that every single change needs to be vertical in nature. You are never making stories where you say, "I'm going to add this functionality to a library. Later we'll add the UI and finally, we'll add the data to the DB schema and then ship". But it means that you need to design your software quite differently in my experience.
Even just from the DB level, you need to have things set up so that you can make very quick changes safely. You need to be able to change the schema, do migrations and make sure that rollouts can be done safely -- and it needs to be done on the order of an hour or so. That probably seems impossible to some people, but it's one of the reasons you can't really take a legacy project/team and say, "From today we are doing XP!"
Similarly, you need to be able to make changes to your infrastructure quickly. So if you have some big set of microservices and each small change requires a signoff from some group somewhere: well, it's not really going to end well. You need to be able to make that change and get everything working end to end in hours, not days/weeks.
One of the things that a lot of people have difficulty with XP is that it's generally incompatible with nailing communication specs to a wall. One day, I may need to add something to the API. The next day I need to be able to change that API. If someone comes to me and says, "You need to know everything you want this API to do for the next 3 months so that we can have a sane versioning system", I'm totally screwed. I don't know what I'm going to need next week let along 3 months (or whatever) from now.
For a lot of people, this stuff is just way too different to deal with. XP comes with the subtitle, "Embrace change". It literally doesn't work unless you decide to go whole hog on it. I've been successful introducing it to some teams, but on others I don't even try.
To try to answer your question a bit more closely... it's probably not what you imagine. It's not like you have people telling you how everything is going to work all the time. However, you are constantly thinking about it. Sometimes you'll have developers say, "I want to work on X" and you'll respond, "Why? How are we going to give value with that work?" And then they think about it and say, "Well, what if we altered the work flow here. That would allow us to remove this stuff. And then if we added this, it would mean that we don't need that library any more", etc, etc, etc. And instead of telling management that today "We removed some technical stuff" or "We got rid of some old libraries", we say, "We improved the workflow for the customer which enabled us to simplify the code at the same time".
This is why I was asking - I still don't fully understand if this is a "XP thing" or not.
Doesn't this reflect some much deeper problem with the product planning or management? If you literally can't plan even a week in advance that suggests there simply is no plan, and even the most scatterbrained business environment doesn't change that fast.
I'd say customers being able to stick to a coherent story about what they want for more than a week would be a key need in any successful IT project.
Methods like XP embrace that by allowing requirements to change over time, to account for the customer accumulating more knowledge about all three areas.
It's on the engineering blog of a company trying to hire a ton of developers at the moment and it reads like the most toxic work environment imaginable to anyone who doesn't have that context, so perhaps the author and the team who approve blog posts should have made that MUCH clearer.
What is your book name? I would like to buy it.
As far as I know, there's only one type of printing, and that's a lay-flat softcover.
This practice is just saving time writing down behaviour that won't be implemented.
What do you do when people forget things?
There's still something written down, just not massive amounts.
Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development.
Otherwise I just communicate a lot.
Things get differently from what I invisioned, sometimes they're worse sometimes they're better.
Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.
Pivotal R&D has struggled with maintaining context. For multi-megaSLOC codebases with many moving parts, organic memory begins to fall a bit short.
Different teams deal with this differently. Some write design notes, some keep architecture design records. But IMO it's one of our weaknesses.
He goes through a lot of psychology and science of how people work better when they're not distracted. It seems that all of the "Extreme Programming" guidelines go quite the opposite of what the science, per Cal Newport, suggests.
He also points out that collaboration is perfectly acceptable during deep and focused work, but this doesn't sound like how it should be at all.
While I’ve never worked in an XP team, the description here sounds like it’s primarily focused on making sure the individual members of the team aren’t accidentally working against each other. For projects that aren’t reliant on the sort of insight that Deep Work is teaching us to generate, the team cohesion may be able to make up for the hit to individual productivity.
No, it isn't. A PM should be having these conversations - briefly! - in front of the rest of the team in the standup, and in more depth in a weekly planning meeting.
If a PM feels a need for updates more often than that, then that is a problem of theirs that they should work in in their one-on-ones with their manager, not something they should dump on their team and then blog about.
It's sad that a PM at Pivotal has gone adrift like this, but it's tragic that this shitty advice has made it to the company's blog.
I stopped right there. My personality is such that being social exhausts me. Don't get me wrong, I like people, I just can only do social for short bursts and then I have to recharge. There are people who get energy from other people, so this might work for them, but not for me.
When do they write documentation?
They solved the problem of breaking flow by banning flow in the first place?
I can't even begin to imagine the sheer amount of meetings and "chats" that would need to take place on a regular basis just to keep things moving along.
I admit to knowing very little about XP but this sounds like my own personal hell.