XP: open office, promiscuous pairing, very little remote work, 4-6 teammates, 2-3 30-minute breaks throughout the day to do whatever, regular lunch n learns, honest retrospectives, continuous deployment, powerful tools (Haskell, Elm, postgresql), daily company-wise “standup” with 70 people that averages 5-10 minutes, bi-monthly team get-togethers to play games and watch movies, regular lunches together, good code review practices, entire team constantly striving to improve.
Software engineers somewhat involved with most relevant business decisions. We are empowered to respectfully question decisions.
I hate standups that are just status updates, that's what the board (Kanban or scrum) is for, if you don't have anything interesting or blockers to raise just say "pass" and save us all
We tend to keep it to important stuff only that the entire company needs to hear. But this past week we had a standup where everyone was supposed to answer a question (I forget what) and we did it in 10-12 minutes. We've been practicing for a long time, many of us come prepared. But even when everyone was expected to say what they were doing that day, we still averaged 10-15 minutes with 70 people. Just come prepared, don't dilly-dally.
- I have a family and friends outside of work. I’ve gone out of my way not to mix my work life and personal life. I have no desire to “play games” and “watch movies” with my coworkers. I come to work to work. I have friends who are former coworkers.
- regular lunches together - again, my lunch time is my time to get away from the office and recharge.
I've been at places that do those too. But they weren't the environment that has enabled my best work.
In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.
And it isn’t a context switch to have someone right next to you hovering while you are trying to develop? What context switch? You do a high level design before you start. Do you really need someone over your shoulder to make sure you can turn requirements into code?
> someone right next to you hovering while you are trying to develop
The pair is a collaboration. They develop together.
> Do you really need someone over your shoulder to make sure you can turn requirements into code?
I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.
I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.
Do you really need to “develop together” to do most features? Most work that developers do isn’t writing complex leetCode algorithms. Are you really saying you aren’t capable of turning requirements into software design by yourself?
You seem resistant to the idea of pair programming. I'm assuming you've done very little of it in your impressive career. As a fellow software engineer, I'm surprised you would be so resistant to something you have so little experience in. I'm not trying to convince you to pair program, I'm trying to convince you to read up on it and find out why others think it's great. 'Others' including some very skilled software engineers like Kent Beck. But from his own mouth, "pair programming works best with a large uncertain search space of problems and solutions. the closer to a solved problem, the less it helps" https://twitter.com/kentbeck/status/253532726714580992?lang=...
Most problems that developers face every day are solved problems just in a different domain or with changes around the edge based on requirements.
I have no problem with collaboration - ie I’m working side by side war room style with one person doing the front end, the other doing the back end, the QA person testing, etc.
Do you really need to pair to write yet another software as a service CRUD app?
My experience is that PRs quickly turn into a chokepoint which breeds delays and rework. Genuine bugs are rarely found, almost all the feedback is idiom and clarity -- valuable, but I can get the same feedback synchronously from a pair.
Note the reference to frequently committing to HEAD. That's not an accident, it encourages everyone to rebase frequently, keep changes small and to surface problems almost immediately. Whereas PRs quickly go stale and it turns into a game to try and get your PR in first.
In my experience of the past 5 years: yes. Substantially better idea-to-production latency, given a high minimum standard for releaseability.
Little's Law is instructive. There are two ways to increase throughput in a system. One is to reduce latency. The other is to increase in-process inventory. They have very different dynamics.
Most software development like everything else is a combination of inspiration and perspiration. How much time is spent in average day coming up with “ideas” versus just doing the work?
Or putting it in production terms, the number of people coming up with ideas for the iPhone in Cupertino is dwarfed by the number of people building them in China.
That you don’t need pair programming to do much of the grunt work that’s involved in development. Do you really need help making sure you write a for loop correctly?
I do if I'm about to do it wrong, or if something other than a loop might be better, or to write the test that drives it out, or to show me a trick I didn't know, or to get me unstuck, or to tell me there's a library function that lets us skip a loop, or ...
Is your argument that I don't know how pairing works? Because my estimate is that I have around 8,000 hours practicing it at this point, which I suspect may be 8,000 hours or so more than your own professional pairing experience. It's possible that I've been sleep-walking through the whole thing, but unlikely. One of the dozens of intelligent, helpful people I've worked with would've pointed it out.
I’ve been writing code for over 30 years including two assembly language instruction sets (one before going to high school), and C on 4 platforms. I’ve been using my preferred language C# for a decade and JavaScript since it was introduced by Netscape in the 90s. I think I’m capable of writing decent performant code without pairing....
In my anger I turned this into a measuring contest.
I think what you're reading is me saying "it's impossible to write good code without a pair", which (a) isn't true and (b) isn't what I said.
What I'm reading is that you say pairing is strictly less effective than soloing, which (a) isn't true and (b) isn't true.
If we were talking about professionally programming in assembly language, I would take your views seriously because of your relevant experience in that matter. In doing so I might not agree and I would very likely be wrong, but I would acknowledge your expertise on that topic.
What I ask is the same courtesy when it comes to pairing.
The opposite of “pair programming” isn’t “developing solo”.
Like I said above, most problems that developers are working on everyday isn’t some complex algorithm it’s translating business requirements to code.
Collaboration is often definitely better than developing solo but it isn’t “pair programming”. But developing solo can be faster. The more developers you add to a feature, the more communication and coordination overhead you have (The Mythical Man Month a book written in the 60s). Honestly, we’ve found that three people working on three separate features solo can get more done than three people working on the same feature over the same amount of time. Again we make it a point to switch up so we can see the whole picture.
When the product owner comes in and realizes we didn’t consider something, it’s almost always faster to have that one person who knows how the change will affect the whole stack - UI/Back end/database/deployment, infrastructure requirements than to have five people trying to coordinate the change.
Collobaration can mean “war rooming” or “swarming”.
War rooming for example is getting your back end and front end developer together in a room along with your QA person, your Devops, and your product owner working on their piece of the feature, rapidly iterating.
I work on a team where each developer can easily go back and forth between the three languages we use (JS/C#/Python), front end development in React, database design, Devops with CloudFormation, CodeBuild, Code Deploy and Code Pipeline sometime we will split up the parts. Other times one person will do a quick design session, do the whole stack, do a post review along with design docs in MarkDown.
If you have well rounded developers, they will often switch roles on the next feature just to have knowledge and a different perspective.
I think I’m capable of writing decent performant code without pairing....
You think you are, but you've never tested this thought and scoff at the idea that you could be wrong, despite being told from experienced people who have tested it that you are wrong?
Is your argument seriously "I've never done it, but it doesn't work" to someone saying "I've done lots of it and it works well"?
Again, seeing that my first experience as a hobbyist was rewriting programs in assembly in the 80s that were too slow in higher languages on a 1Mhz 65C02 based computer, my second job as a professional was dissecting C compiler output to see how I could optimize the code generated or at times rewrite it in x86 assembly (custom printer drivers for industrial printers) and my third job was optimizing a proprietary compiler/IDE for Windows Mobile devices. I think I have a little more experience optimizing code than someone who has been doing it “for six years”.
This is finding your identity as a performance programmer challenged, and defending your identity instead.
"That sounds stupid, but they claim it's good, so I'll try it and see if I can learn anything".
"look at my credentials, don't question me, this other person can't know anything I don't, how dare anyone suggest I can learn anything from anyone else, don't you know who I am? Also they're a n00b."
You act as if I’ve never sat with another developer brainstorming which is different than constant pair programming. I wasn’t the one who bragged about six whole years of experience
I agree that full pairing does make remote working harder, and the hours should be fixed, but we've been doing promiscuous pairing for a few months now to achieve 'beginner's mind' and that has been just as effective as 'flow', and more consistent to achieve. https://engineering.itpro.tv/2018/12/07/our-first-experiment...
Uh, that's empowerment? The right to ask "respectful" questions about decisions that are already made? As everyone else is already pointing out, what you know may be separate from what you (want to) believe.
> daily company-wise “standup” with 70 people that averages 5-10 minutes.
That sounds horrible. Even if half of the people have something to say, that's about 15 seconds per person. Beyond saying, hi, I'm here, I'm not sure what else can be accomplished. It sounds more like a daily pep talk by the leaders to the whole company.
Office standups where I work are of the form: New faces, helps, interestings and events. It's not the same as a team standup. You can get through both in 20 minutes flat.
Sounds like a nightmare. I'm very social but despise the constant efforts to add extra social fluff (team lunches, movies, etc.), much rather prefer learning on my own and don't like "startup culture". I want to work how I want to, where I want to, whenever I want to, no ridiculous team ceremonies, no useless meetings. I just want to do an excellent job and go home early.
I guess this depends on the person, but for me- My boss 100% hands off on my day to day work.
I can chose what I work on for the day, week, month, or Quarter. I have my work area, but within that I have 100% freedom to figure out what I need to do- the only thing I need to do is to be able to justify it. I can select the tickets I want to work on, areas to improve, initiatives to take up, or software to build.
Also, the core business drive of measuring and qualitating your work. So, you can see the impact you are having on the business (positive or negative- NOT in a way that affects your job, but in a way that you can say "I did X which made Y faster, causing a 3% growth in click-though rates).
But I do wish I had a more private workplace. Hexes are better then the nightmare of open offices, and I work on a quiet floor, but sometimes I wish I had a door I could close.
We're large enough where we have a specific DevOps Teams and the Team doing AWS is doing it wrong. If I didn't have the freedom I have now, I would have a very different opinion of this place and be looking for a smaller shop
"DevOps" doesn't mean shit. It's a bullshit term define by who is using it. That team is in charge of kubernetes, and automated application deployment stuff, so they are the team ensures developers can push to production quickly. Which, now that I google it- it's exactly what the "official" definition is.
Well, in our case, dev ops means the developer is also responsible for setting up the CloudFormation template to create any resources, CodeBuild to create packages and CodePipeline or Octopus Deploy to deploy code.
Funny enough I've been obsessing over this concept of "aligning vectors" / measuring the impact of personal KPIs against the total progress of a business.
“Every person in your company is a vector. Your progress is determined by the sum of all vectors.” — Elon Musk
It's quite nice to see the positive impact you have on the rest of the business. It gives value to what you do day to day. Where I work is very data driven, so any chance can be measured if you know how to look
The best work I ever did involved a large collection of computers admin'ed by some serious f-ing idiots. They'd break that system in every conceivable way, every day of the week. So, I ended up writing a seriously fault-tolerant piece of software that could make forward progress on my users' problem no matter what. It turned out to be glorious.
Not much beyond that, except that my users had a clear need, and I was given time to do the work. Had a private office, but that mattered little.
My moral: Sometimes you really can make lemonade out of lemons. Maybe the torrent of shit raining down on you is a gift sometimes.
Small team, offices for developers, open door for free to walk in to chat, close door for don't bother, lots of whiteboards, ah hoc discusson, weekly team planning meeting on Monday, weekly release/resolution meeting on Thursday after lunch, release and recovery from fuckup on Friday.
Release in the morning. Whole day on Friday to recover in case of problem. If nothing's wrong, the time is available to do extra stuff. Incentive for people to get things right before deployment.
Working from home, while having a 10 min daily standup voice call. I work with colleagues but mostly on my own stuff, so I get a lot of freedom to handle things.
Same here. With the added bonus of selecting my own schedule. I have a 25-26hr sleep cycle so it is very unproductive for me to be available at 9am or 11am or any specific time daily. I also prefer to work longer hours late at night. Thankfully everyone I work with as well as my wife/kid totally understand this and accommodate my atypical hours.
The end result is I am extremely happy in my work hours and arrangement as long as I don’t have early morning doctor appointments or something.
Yeah, it's not by choice though. It can really mess people up if they're not aware of it. This NASA TED talk about time on Mars discusses how a different cycle can affect others too: https://www.ted.com/talks/nagin_cox_what_time_is_it_on_mars
Ever since I saw that video, I've worked hard to (1) make sure others aren't negatively affected by my schedule (2) accept that until something brings me back to a 24-hour cycle, I have to persisently keep working on (1). Every other week I will go to bed at 10pm with my wife and wake up naturally at 5am and she'll have a great day being coordinated with my schedule. But within a week I'll be going to bed at 6am and waking up at 12-2pm. Every month or so I will stay up 30-36hrs without even trying.
None of this is due to bad habits, lack of sunlight, or lack of exercise etc. Doesn't matter what I do or don't do, my body just doesn't live in a 24-hour world. So I've learned to let it do its thing and work/sleep/eat/play when I feel like. Never been happier.
I have been mostly working from home for the better part
of 15 years and I an truly beginning to detest it. I am often distracted and lonely. On the other hand, I can avoid the terrible traffic, and I have more time to do side contracts or work on my business. There’s always a tradeoff.
At a studio I worked at once, two others and myself were assigned to a new project. Since we were the only ones working on the project, we got permission to clear out a storage room and convert it into an office.
It was just the three of us in a decent sized room and I feel that my work satisfaction and productivity was double what it was anywhere else in the open plan office space. There were very few distractions, but our office was open-door and just off a commonly used hallway so we weren’t hiding. We had enough space for a whiteboard and a 4th desk that we used for reviewing work together.
A few months later one of the managers saw what we’d done and decided he wanted it for his personal office. We went back to open plan :(
In my first ever job at a startup we were 3 in a pretty big office (probably 300 square feet or so). We had a whiteboard, couch, stereo and 3 desks. I've worked in open plan offices, cubicle farms, and my own office at home. The 3-in-a-room was the sweet spot for me. It helped that we all enjoyed classical music, though...
My first software engineering job was with a big aerospace company about 20 years ago. Back then, budgets were big and the culture was completely different. Even the lowest peon had a huge cubicle with lots of desk space and privacy. Standups were not a thing and Agile wasn’t on the radar. We had lots of time to do anything we were assigned and never had to do much reporting aside from weekly meetings. We all had a general sense of schedule but it wasn’t rushed at all. We also didn’t have rhe always-in communication tools like Slack. Phone calls and face-to-face were it. This all made for a very relaxed environment where no one felt rushed and we had time and space to contemplate and concentrate. This is where I learned and created the most. I basically taught myself Perl, Unix (we had SPARC x-terms), Java, bash, csh, ksh, SQL, Javascript and web application development, and so much more, all of which I still remember to this day. I was happy and relaxed and pretty much always looked forward to learning and exploring more every day. Clearly this type of environment works well for some people, and it certainly did for me. I credit these early years to my success. Fast forward 20 years and I am in a completely different environment - open office
plans that encourage collaboration but also distraction, Agile tools that promote micro-management down to the number of minutes you spend on a task, daily stand-ups (sometimes multiple per day if you’re involved in several projects), and constant reporting to management, SCRUM masters and POs. Oh and chat tools. These constant interruptions often make it impossible to truly do creative and deeply thoughtful work. Most of what I do is rushed and measured and we are always analyzing what we can more efficiently and quickly. Responsiveness to messages are also scrutinized. Oh and all the meetings - Sprint planning, retrospectives, reciews, backlog grooming, etc. I estimate that most of what I do these days is a lot of administrative busy work and useless overhead, which is definitely not conducive to doing what I believe I do best - write code.
This reminds me also of my most productive days. Funny how enough people create their own middle management jobs, and jobs like "scrum master", that literally seek to destroy developer time.
If your Scrum Master is destroying developer time, then s/he is "doing it wrong".
The main function of the Scrum Master is to shield the developers from all the non-development crap. I've worked with one guy who was so good at it he would play interference and defend us from outside interruptions almost literally (actually blocking people from coming to our desks, making sure we could focus, holding meetings only if someone on the team expressed some kind of blocking issue that he couldn't solve by himself, etc)
Sure, probably this was more about him being a good manager than the "process" behind it. But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted.
> Sure, probably this was more about him being a good manager than the "process" behind it.
Of course also that, but you're completely right that that is the exact job of the Scrum Master. To "remove impediments". No matter if the impediment is some process or a manager, it's the Scrum Master's job to remove it.
This actually aligns pretty well with the ideas in Agile Manifesto. And that's why I'm so sad when "scrum master" nowadays mostly seems to mean someone who counts the minutes devs spend on each Jira ticket, and haunt the team when velocity seems to be dropping 10% for the second day in a row.
> But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted.
Why can't it be both? Bad managers can be empowered by a process, just as good managers could be hampered – no?
Agile provides so many tools for bad managers to micro manage, so that even if the process itself is well intended it still could lead to hell – no?
jobs like "scrum master", that literally seek to destroy developer time.
We can’t really ever hope to make progress with improving productivity or work environments if people contribute to be this reductive.
A “scrum master” role does obviously not “literally seek to destroy developer time” - it’s a patently ludicrous assumption. But if you are in a situation where this is happening - rather, where a “scrum master” role is getting in the way of work - then it does point to something else going wrong in your organisation.
So, I didn't mean to offend anyone, only speaking from my experience.
I feel most jobs, at some companies in some situations, are absolutely justified. The problem is that then every company thinks they need to follow suit, and it ends up being a giant time sink. I'd wager most scrum masters are viewed by their team as a net negative (my opinion). But of course no person whose job acts as a hindrance will admit as much.
I’ve recently started a job where my time isn’t measured. My time was measure 2012 until 2018. 3 different jobs. Utter misery. Now I’m having a lot more fun and feel very productive in the true sense of the word. There is still stand ups and slack etc. but I don’t mind that so much. Having a stopwatch constantly ticking against you is the main hell I hate in modern tech culture.
(not OP) it seems to me it is now "normal" for remote companies to track every second; is it really as soulcrushing as it sounds? Do you have any real world experience with crossover? (I am seriously considering applying with them)
Did you have time budgets or quotas? I’m curious how these companies used the measured time, what made it feel so oppressive. (I have no doubt it feels oppressive, just interested in the details.)
When I’ve done contract work, and when I ran a startup, I started tracking my own time. I find it helps me focus and account for my time and understand my own habits. It’s not very good for open problems or exploratory work, other than to find that they take a lot of time. ;)
Other than tracking myself, I’ve never had a job that measured my time directly. I had one job that did measure when employees were at work, but they didn’t show it to employees nor set any quotas, they just wanted to understand work patterns.
It’s more of a case of being dragged into a room to discuss why task X and take Y took 6 hours instreas of 2, or 4 weeks instead of $what-manager-coulda-dunnit-back-in-the-day. At those companies I had to let a lot of shit go through code reviews and take shortcuts. That stuff wasn’t measured.
Ah, thank you. Sounds not very fun. May your new company celebrate goals accomplished in years rather than worry about tasks not accomplished in hours.
I keep reading about how scrum,agile,openspace,slack,oncall,whatsup outside of work has ruined developers productivity and life after work.
WHY dont we do something about it? why are we going like cattle to the slaughter house? We are developers right we are supposed to be smart, intelligent yes, we have let this come all over us step by step until we have lost our life.
Developers - it's time to raise to the basic work environment, we need space, we need to do our work with focus, and YES we need separation between work and home.
If a company needs work-after-work they should hire people for these after-work hours, if messages are sent after work, and it's just this additional answer this mail, it should either be handled by workers who work over these hours or just wait to tomorrow
We have let this on us, and it's our duty to bring back the focused work environment and the joyful home environment without interruptions from work or being oncall or answering messages.
Companies would rather hire less-talented, less-perceptive, less-skilled workers if they will express fealty to mandated bureaucratic marching orders, even if it means paying more money, letting projects fail, losing business, etc.
Companies _will not_ negotiate things like letting developers have autonomy over the process by which the work is managed and delivered, or letting developers have private offices.
This is just standard Moral Mazes 101 stuff. Preserving the property that employees behave like obedient dogs instead of free thinkers is the absolute number one mandate, to the detriment of all else.
Here is a counterpoint. I worked with software development at Ericsson for about 10 years before XP and agile came out. I too had a private office, and I recognize a lot of what you describe. While it was nice, it was not a very productive environment. Each release of new SW was enormous and typically took a year or more to get out. The developers had no real idea of how things worked in production. Lots of useless documentation was produced. Later on, RUP and tools like Rational Rose were introduced that made things worse. Basically, things worked out despite the process and tools, not thanks to them.
In all my jobs since, I have worked in a more agile setting. By that I mean that the team is small (less than 10 people) and sits together with some sort of product owner. Not private offices, but rooms where only people working on the same thing sit. Frequent releases, fast feedback. Very few meetings, most issues can be worked out in the team. In my view, this is a quiet environment, but occasionally there are dicsussions that you overhear (but that is not a problem). In these types of environments I have been much more productive than I was at Ericsson.
The thing is, you can have development standards that require small iterations that are immediately deployable and this are immediately tested and deployed, without pulling all the overhead of some PMs interpretation of scrum.
I often find the power is generally with the wrong people and they promote the things that matter to them at the detriment of everything else.
I don't personally believe this is by design, it's just people in $foo management position tend to have the soft skills to make their job easier, when many of the developers often don't. And managers, who tend to control budgets and define departments, tend to give those departments to more managers and there's not a lot of people in the room telling them that a software person should probably run a software team.
What you describe looks how agile was supposed to be. What the op described looks like a perversion of agile perpetrated by managers who either don't understand why agile was born, or do understand it, but only care about increasing their power instead of getting things done.
I know. When I first read the XP book by Kent Beck it was a revelation. That was the first time I saw a methodology that I felt worked and agreed with my own experience. Planning everything out in advance is hopeless.
There are two great quotes that I think capture this:
“A complex system that works is invariably found to have evolved from a simple system that worked.”
John Gall
“Enlightened trial and error outperforms the planning of flawless intellects.”
David Kelley
It is really sad to read about how often the agile ideas have been misused!
How about "a team of skilled developers is likely to be successful with any software development approach; an inexperienced or untalented team is doomed regardless of the chosen methodology"
Yes. But unfortunately not every team can be made entirely of rockstars. So the purpose of a methodology is to increase the probability of success for a moderately talented team.
Have you asked people who work at Ericsson today? From what I have heard it is hard to think that things are better today despite moving to things like agile.
I work at Ericsson today. Unfortunately, the environment is very much like the one described by the OP: open plan office, noise, chit-chat, interruptions, daily stand-ups (which are mostly a waste of time), scrum meetings which take place far too often, retrospectives which turn into blamestorm sessions. All of this makes the office a rather unpleasant place to be. Which is a shame, because whenever I get to actually sit down and get some work done, I tend to enjoy it.
You'd think I could cope with this by working from home, but that option is limited, too.
Between you and what OP is saying, I think there is this something thing else also. Core software development activity (UI, databases, messaging, web servers, configuring legacy systems, testing, release and delivery, etc) is helped by people sitting together on an agile track. However for some software development this also means architecting the product itself, an aspect that is crucial to a company's survival too. In a company building a demand management product, I need to learn and understand the market, consumers, sales processes, our internal systems that manged these before drafting the demand models, fine tune the methodology, etc before anyone really build the software product/services that reach the end-user. And there is a cycling back and forth between the two activities as we move ahead to get things right. I had no product manager or analyst who could really help with the product itself that the company wants. This latter part is where where I have a very hard time sitting in an open space with 10 people talking on the phone or getting pulled into frequent meetings.
I work in an open office environment. This is great for rapidly communicating with co-workers and having people eavesdrop and chime in when necessary. However, this can be a big impediment to productivity for some people.
What has worked for me to facilitate my best work is to reserve a meeting room to myself for one or two hour slots during the week. This allows me to close the door, put my back to the window and get focused. What's great about this is this limits visual distractions, restricts uninvited visitors, and reduces auditory distractions (I will usually wear headphones and listen to non-lyric music).
Often I find that I will get more work done in this period of time than I would if I was sitting at my desk.
Last few years I've been working for a company I already knew, by myself, on a codebase I built from scratch. Telecommuting. Customer-facing, when stuff is done, I hand it over to their ops team. Don't think I've ever been more productive.
I worked at a national laboratory. There were 125 staff to one group leader and one assistant group leader, and they had their own projects too. Everybody who worked together was in the same hallway. Real offices, two people each. Zero remote. Core hours. Gym, cafe, and doctor on site. There were no meetings, just presentations you could go to. I didn’t use my calendar. Project matching was a natural process; you just had to report a rough fraction of time for each thing you were working on. Performance conversations 1:1 once a quarter with group leader based on feedback collected from project leads. 1-page writeup once a year. Projects always require senior staff to work with junior staff. Constant in-house education in scientific computing. Full access to journals and site licenses for just about any software. In general, you knew everybody that controlled any resource you might want access to.
I had an interior office with a solid door, walls covered in whiteboards, excellent monitors, good hardware, and a fast net connection. If I needed to ask someone something, I could send an email. If it was urgent, I could knock on someone's door. If I wanted, I could work outside on a patio or in an office with a giant window. There was an excellent BBQ joint on the same block.
We are 100% remote with an optional co-working space that is available if you ever want to work at an “office” environment.
Project is managed mostly through airtable with quarterly goals with weekly’s and daily’s (not standup) to check on progress. Then we have a company/team wide call every tues for the weekly brief.
All the above enabled me to have the best environment by then investing in my home office. A space that has a good desk (multitable sit/stand), chair (aeron), and good lighting, not to mention a beautiful machine (iMac Pro).
The issues that followed were more of the focus issues when doing work at home, so I got a pomodoro clock which then made everything seamless.
My most joyful (work wise), efficient and productive 5 weeks ever were:
* in a remote place, visiting and living with my grandparents
* in a village with little civilization but tons of nature around
* when for a break I could just go outside house, hike around the barn, watch village folks going about their business in the farm or around the kettle
* with big time zone difference from the rest of the team that allowed only occasionally for 1 hour of overlap to sync up
* with my wife being away for her studies in a different country (told ya it was joyful only work-wise!!) with fixed limited hour to catch up on a phone.
In those 5 weeks I’ve built the major part of the scalable distributed OLAP Cube that had proved to be very simple, robust and reliable and was still in use to support telemetry of over hundred of customers after 5 years.
The biggest distractions were a cat, incredibly beautiful rain showers, and warmest ever discussions at the dinner table.
During med school I would ride my bike on a scenic trail to a campsite on a bluff overlooking a massive river. There was a camp store with snacks and beverages and a Thai restaurant served out of a trailer. The campsite had a bonfire and featured live musicians in the evening. I only had a couple bars of internet through my phone.
Never had more productive study sessions in my life. 1 hour bike there (listening to lectures on my phone) + several hours studying at a picnic table, eating Thai food + 1 hour bike back (w/ audio lectures).
I think there's something special about the combination of being 1) in a small community, 2) relatively disconnected from rest of the world, 3) surrounded by natural beauty.
I've never been able to replicate that environment since. I've read a lot about summer shifts on the Antarctic bases--sounds idyllic for the same reasons as above.
My best experiences, as I think about it, tend to have these patterns:
- No Slack for non remote
Slack is cool, but I remember thinking that if I needed to talk to someone, it's over email or in-person. This really encouraged face to face or email conversation. There was also Skype for remote workers, but if you're not doing remote, you could kill Slack. Now that I think about it, Slack is more of a vitamin than a pain killer for non-remote organizations. Slack is great for remote though and love it.
- No Agile
Ah, I remember when I had my first job using Agile. It was cool the first few weeks and that was it. Again, it's not a pain killer, it's a vitamin. I had the best time ever just sitting in meetings on Tuesday mornings to demo everything in person then do code review with my CTO after. Talk with the whole team including marketing on what we'd work on. I loved it. No agile, was completely in the know and performing.
- Support with Tools
It sucks not having the right tools to do the job. Receiving the appropriate hardware, desk, and software has always been useful and makes me happy to come into the office. It really sucks when you wake up, look at your amazing at home desk, then go to a lousy work desk. Bling out the work desk. You can do anything from getting a top end work computer, a great monitor, an eGPU (may actually save a company money from AWS bills), a DAC/AMP (cause devs usually have a thing for headphones and the budget for great ones), or a desk goes up and down and has memory settings and it's fast.
- Minimum Friction
If you get told you need to change up your landing page, change up the tooling, or do a big refactor on something, always take it seriously. Some people marry a concept or an ideal and it can often cause friction between the team. Giving up the consistency and letting others use what best let's them get their job done should be given time and thought. All in all: be fluid with company practices and not letting a "mono-culture" take root is usually best.
My best experiences have been when a single employee can happily recommend a new way that could radically change the initial experience of a customer or a company culture. The fluidity maximized sales and development.
- Wrap up
We have so much now with tools that can be categorized as pain killer or vitamin. My best recommendation is to have less vitamins and more pain killers.
Note: This is just me though. I know a lot of other people have different ways they prefer to work. This is just me.
> I had the best time ever just sitting in meetings on Tuesday mornings to demo everything in person then do code review with my CTO after. Talk with the whole team including marketing on what we'd work on. I loved it. No agile, was completely in the know and performing.
I know I'm discussing Scotsmen here, but: what about this is not agile?
• Agile as a faddish silver bullet marketed to people who don’t know any better
I assume OP is thinking mainly of the latter two. It sounds like their business avoided formal standups and sprint planning, and didn’t generally care about Agile/Scrum etc. buzzwords. But I tend to agree with you that from a values perspective that seems perfectly Agile.
Agile has a dirty name now, but it's well-deserved, because most folks have had legitimately terrible experiences with stuff sailing under that banner.
I've had a legitimately awesome experience and I can't really use a different word, because it either creates confusion or sounds like sneaky wordplay and/or self-marketing hoopla.
I had a job where, due to the technology, I could not TDD. There was no sane way to version control. No CI/CD, changes had to be made in dev and then copied & pasted into prod. Before that I was in a job with pairing, TDD, CI/CD and an avowed commitment to agile.
Of the two, the ostensibly-not-agile was more agile, because it hewed closer to the values of talking to people and focusing on doing the most valuable thing first. I would work on projects by myself. When I wanted to learn more about my customers, I walked across the campus and talked to them. If I had something I wanted them to give their opinion on, I would ring them and tell them to take a look.
At the ostensibly-agile job we had a manager who talked to a middleman who talked to a board of directors who heard from a line manager who talked to his employees. It didn't matter how well we did the inner loop, because a lot of the time we just produced beautifully-engineered diversions.
This was before we grew to 200+, but the best snapshot was:
- <80 person team (total); ~60% engineers
- 0 product managers: design and engineering are equally empowered to make the site nice within general business/product definitions defined by GM who would constantly get excited about the work you showed her, making you feel good about yourself and your work
- 0 project managers: business understands that there is no magic formula for delivering products that haven't been built yet and so long as we try our best to hit dates and cut scope as needed, it's on us to track our progress and determine priorities
- gm, cto, and head of hr all supportive of growing team and individual members in a non-political way
- politically-driven employees (typically a head of sales or marketing) shut down and churn out quickly
- engineers talk directly with customer service
- engineers perform rounds helping out in support forums
- domain specialists, but no fences. i might be a web engineer, but if there's a sql query i feel compelled to optimize, nobody is going to stop me.
- company regularly interacts with, and hosts local events for, an engaged user base. engineers actually end up having in person conversations with our users, gathering honest feedback for improvements while simultaneously being told how great the product they contribute to is overall
- relaxed hours ("you're an adult; we trust you to get your work done")
- when dining out or getting drinks, even paying by cash a large group is able to come up with the right amount of money, with no one person needing to chip in more than necessary
- anyone in the company can deploy the site with a single chat room command
I'm very surprised you could have no managers. Personally I always thought it wad good to have a management level person to filter out content from customers or Product.
One of my most productive sprints I ever had at a job was after a couple months working on an internal tool that was going nowhere. After being frustrated for a long time with a project's management, I cut the middle-man and went directly to the customer, did my own user research, brainstormed either on my own or independently with others, and kept direct contact with the users to keep a tight feedback loop when shipping features.
Management and middlemen can as much help velocity as they can hurt it. More hands doesn't always mean faster work ¯\_(ツ)_/¯
The adage "good leaders make themselves unnecessary" applies.
If you have people under you, or can coach your people to take parts of your responsibilities off you, I think that's a great outcome. If your ICs are so good that they can actually do that, you should give them a raise and be glad you get to focus on other things in the meanwhile.
Of course, if the manager is unable to then broader their own scope, they indeed become disposable.
Oh certainly. There are a lot of managers that add value. I was talking more about the 5 layers of confusion (product manager, project manager, business manager, business architect, designer) that exist between our customer and the developers. There may be more that I haven’t yet discovered.
We recently spent quite a while on developing a feature only to find out the customer didn’t actually want it.
When I was an intern at Big Bank, I was literally put into the printer room. Hardly anyone used the printer/copy machine so I was left alone in there for the most part, other than my boss peeking in once in a while to make sure I was still breathing. The door closed and there were no windows.
It was the most productive I've ever been. The code I wrote was mostly garbage, but I got my reps in that summer and learned how to program.
A top-notch VP of Engineering who knew when and how to reduce scope (because he was an active contributor to the code base) and was also one of the best coders in the room.
1) Pair programming, with the VP stopping by every couple of days asking "where are you guys stuck" and would actively try to solve our problem.
2) Story prioritization - each PM would write product stories for the backlog in an effort to get them in the next sprint. The same VP (above) would review each of those stories in front of the PMs and developers. If it were really lazily written, the PM was shamed, it was thrown out, and could be resubmitted for the next week. Developers got to ask questions, add tidbits regarding prior work that may need to be studied to complete the story.
3) If a bug made it out in the release, it was no-one's fault. Everyone worked as quickly as possible to either create a patch or roll back the feature completely.
P.S. That VP of Engineering is Andres Camacho. He's in San Francisco. And he's amazing. Work with him if you have a chance. He's well known for hiring Jr developers, training them via pairing with them intensively, getting them up to speed quickly and having them contribute meaningful code within a few days. He's now the CTO of Better Therapeutics.
I'm a PM and didn't have any negative feeling when I read that part of the comment. I was reflecting a bit on why. I think it's three things:
1. If I've not done my job as a PM, then it's much better to figure it out earlier rather than later. If engineers struggle on without the right support from a PM (whether that's stories/requirements, oral clarification, ...) then that can slow things down or create worse outcomes. So I'd rather someone call out holes in my work at the earliest possible opportunity, then be polite so the problem can get larger.
2. In a high trust environment, people can take criticism of their work without taking it personally. It's hard to achieve this type of relationship (with specific people) or environment (with a group of people), but can make things much smoother.
3. I feel the job of the PM is to make the team successful through whatever means possible. Feedback/criticism directed at me is a valuable source of information to support that, whether or not I am the correct target.
Agreed. Often the most challenging part of being a PM (besides coercing xfn collaborators to care about your priorities) is getting agreement on the amount of research that needs to have been done to justify a new feature, product or user journey. This is usually either business case development + ethnographic user research OR confronting of technical debt and engineering limitations/opportunities ... and it's rare to get everything right the first time. It's also rare to work in a place where a PM has the luxury of dedicating enough time & resource to create a complete requirement before the tech teams start working.
I also read "shot down" as a constructive and expected feedback mechanism. In small teams, it might be the TL or eng mgr who provide this feedback, but for larger product business cases are often required for review by executive stakeholders, and they will always be terse, hopefully constructive, but frequently come across as overly negative. Why? Because they're gatekeepers and it's their job to ensure the best opportunities are pursued and the rest are either back burnered or sent to the graveyard.
shaming is not criticism. criticism is an expression of disapproval of an idea not the person. But shaming is personal. This is not constructive to improve.
But people often choose whether or not to take something personally, and their reaction determines the outcome. Consider the following situations:
A. (Bad case) You criticise my idea/proposal, and I interpret that as you criticising/shaming/blaming me (i.e. I take it personally). I then decide to ignore your criticism, because I feel it is based on your personal opinion of me, which I know is incorrect.
B. (Better case) You criticise me personally (e.g. "you're a bad PM, as evidenced by X"), and I take it dispassionately, trying to understand why you feel that way, use that to inform my understanding of the situation, and find a way to make things better.
In A, my idea was criticised, and there was no positive outcome.
In B, I was personally shamed, but there was a positive outcome.
I cannot change how people communicate (at least in the short term) but I can change how I react, and hence what impact I have on the outcome.
people reacting to situations is about individual. but we know every individual is unique and different. Team should be encompassing and not assuming. CEO or Project Director's boundary is only with the idea and not the individual.
Idea can be criticised, never individual. Your argument may sound right, but it is not considering everyone. Your argument is saying how one should react, but is not answering what if one reacts differently. How can we mend it.
Leader is one who is compassionate and has ability to differentiate idea from individual. Work is not entirety. Idea will never define a person. whenever we critique, it is best to keep it till the idea and never to person. my few cents.
When I criticise a piece of work, someone can still choose to interpret it as shaming or a personal attack.
-- yes agree. this is not the mistake of the person commenting.
When someone criticises me personally, I can still choose to focus on the useful part. I don't have to feel offended/upset.
- This as mentioned before, this we cannot make a rule but a guidance but this is very personal to the individual and most inidividual even if he is not offended, will not work under him for a long time to come. which is not good either way.
If a proposal is bad because the idea has flaws, it's appropriate to express disapproval of the idea.
If a proposal is bad because a decent idea is lazily written (as the original post states), it's appropriate to express disapproval at the person - if the only thing that was needed to change in order to make this proposal better was the person's attitude (do your homework properly before submitting the proposal instead of wasting everyone else's time), then it is constructive to target that attitude.
I live in Bali and occasionally consult for companies back in London. I’m on UTC+8 so if I start early I get most of the day uninterrupted and then an hour or so of overlap.
It’s incredibly productive for me but I’m lucky that I enjoy programming enough to rarely get distracted by my picturesque surroundings during the day.
At the macro (yearly) level I am most productive with:
1) condensed higher intensity blocks followed by larger breaks
2) distinct "seasons" of work that differ in projects/pace
At the micro (day-to-day) level:
3) no logging of hours
#1 and #2 are a product of the academic calendar. I find the regular 9-to-5 work week paradoxically draining. I'll trade a good chunk of my weekends and evenings for longer breaks between "ON" periods.
As for #3, one company I worked for simply trusted that you'd put in your 40 hours a week. It was more flexible and quite simply freeing. If I were in a good flow state I might work late to finish up a feature, then sleep in the next morning (provided there were no meetings). All without the tedium of counting quarter-hours.
Well managed code reviews. I care little for open spaces, slacks or deadlines. Code review done by peers with good faith and deep knowledge is the only thing that moved the needle and forced me to rise up as a developer.
I don't want to be managed. Tell me the objective and give me the freedom to meet it for you. I'm smart. You don't hire smart people and tell them what to do. You hire smart people and let them tell you what to do.
199 comments
[ 2.9 ms ] story [ 224 ms ] threadSoftware engineers somewhat involved with most relevant business decisions. We are empowered to respectfully question decisions.
- open office - impossible to concentrate.
- constant pair programming - ughhh
- I have a family and friends outside of work. I’ve gone out of my way not to mix my work life and personal life. I have no desire to “play games” and “watch movies” with my coworkers. I come to work to work. I have friends who are former coworkers.
- regular lunches together - again, my lunch time is my time to get away from the office and recharge.
I prefer less ceremony, remote when I like, no open office, etc etc
Pairing removes many barriers to development:
* built-in code review
* knowledge sharing: removes silos
* helps avoids overengineering (few pairs have the same overengineering idea, so you tend to settle on a decent un-overengineered solution)
TDD, which I'm not fully convinced on, acts a clock for pairs: one person writes a test, one person writes the implementation, flip roles, repeat.
Other XP practices: everyone works at HEAD, deploys from HEAD, retrospectives.
Small features went from discussing with customer, to writing the implementation, tests, monitoring, and deploying it in half a day.
The disadvantages of ~full pairing: remote is harder to support, I missed getting into flow, fixed working hours.
- code reviews as part of a pull request system
- knowledge sharing - design sessions for features to make sure nothing was missed and architectural overviews with wiki documentation.
- avoid overengineering - again architectural “previews”.
In particular, PRs and design sessions were/are a context switch which add friction. Even when pairing, however, we'd occasionally have team-wide design sessions, depending on the problem.
The pair is a collaboration. They develop together.
> Do you really need someone over your shoulder to make sure you can turn requirements into code?
I listed numerous advantages (and some disadvantages), none of which implied pairing was necessary. I'm merely answering OP's question on which environment has enabled my best work.
I'm not advocating pairing (I'm no longer in a pairing team), not even saying it's the environment that will enable the best work for other people. Our hiring process included a pair programming task to try to gauge how well that person would work in a pairing team, though it's also something you get better with in time.
I have no problem with collaboration - ie I’m working side by side war room style with one person doing the front end, the other doing the back end, the QA person testing, etc.
Do you really need to pair to write yet another software as a service CRUD app?
Note the reference to frequently committing to HEAD. That's not an accident, it encourages everyone to rebase frequently, keep changes small and to surface problems almost immediately. Whereas PRs quickly go stale and it turns into a game to try and get your PR in first.
Little's Law is instructive. There are two ways to increase throughput in a system. One is to reduce latency. The other is to increase in-process inventory. They have very different dynamics.
Or putting it in production terms, the number of people coming up with ideas for the iPhone in Cupertino is dwarfed by the number of people building them in China.
Is your argument that I don't know how pairing works? Because my estimate is that I have around 8,000 hours practicing it at this point, which I suspect may be 8,000 hours or so more than your own professional pairing experience. It's possible that I've been sleep-walking through the whole thing, but unlikely. One of the dozens of intelligent, helpful people I've worked with would've pointed it out.
I think what you're reading is me saying "it's impossible to write good code without a pair", which (a) isn't true and (b) isn't what I said.
What I'm reading is that you say pairing is strictly less effective than soloing, which (a) isn't true and (b) isn't true.
If we were talking about professionally programming in assembly language, I would take your views seriously because of your relevant experience in that matter. In doing so I might not agree and I would very likely be wrong, but I would acknowledge your expertise on that topic.
What I ask is the same courtesy when it comes to pairing.
Like I said above, most problems that developers are working on everyday isn’t some complex algorithm it’s translating business requirements to code.
Collaboration is often definitely better than developing solo but it isn’t “pair programming”. But developing solo can be faster. The more developers you add to a feature, the more communication and coordination overhead you have (The Mythical Man Month a book written in the 60s). Honestly, we’ve found that three people working on three separate features solo can get more done than three people working on the same feature over the same amount of time. Again we make it a point to switch up so we can see the whole picture.
When the product owner comes in and realizes we didn’t consider something, it’s almost always faster to have that one person who knows how the change will affect the whole stack - UI/Back end/database/deployment, infrastructure requirements than to have five people trying to coordinate the change.
Collobaration can mean “war rooming” or “swarming”.
War rooming for example is getting your back end and front end developer together in a room along with your QA person, your Devops, and your product owner working on their piece of the feature, rapidly iterating.
I work on a team where each developer can easily go back and forth between the three languages we use (JS/C#/Python), front end development in React, database design, Devops with CloudFormation, CodeBuild, Code Deploy and Code Pipeline sometime we will split up the parts. Other times one person will do a quick design session, do the whole stack, do a post review along with design docs in MarkDown.
If you have well rounded developers, they will often switch roles on the next feature just to have knowledge and a different perspective.
You think you are, but you've never tested this thought and scoff at the idea that you could be wrong, despite being told from experienced people who have tested it that you are wrong?
Is your argument seriously "I've never done it, but it doesn't work" to someone saying "I've done lots of it and it works well"?
"That sounds stupid, but they claim it's good, so I'll try it and see if I can learn anything".
"look at my credentials, don't question me, this other person can't know anything I don't, how dare anyone suggest I can learn anything from anyone else, don't you know who I am? Also they're a n00b."
Good!
> ...to respectfully...
Sure.
> ... question decisions.
Uh, that's empowerment? The right to ask "respectful" questions about decisions that are already made? As everyone else is already pointing out, what you know may be separate from what you (want to) believe.
What do you mean, 'As everyone else is already pointing out, what you know may be separate from what you (want to) believe.'?
That sounds horrible. Even if half of the people have something to say, that's about 15 seconds per person. Beyond saying, hi, I'm here, I'm not sure what else can be accomplished. It sounds more like a daily pep talk by the leaders to the whole company.
It's just work.
I can chose what I work on for the day, week, month, or Quarter. I have my work area, but within that I have 100% freedom to figure out what I need to do- the only thing I need to do is to be able to justify it. I can select the tickets I want to work on, areas to improve, initiatives to take up, or software to build.
Also, the core business drive of measuring and qualitating your work. So, you can see the impact you are having on the business (positive or negative- NOT in a way that affects your job, but in a way that you can say "I did X which made Y faster, causing a 3% growth in click-though rates).
But I do wish I had a more private workplace. Hexes are better then the nightmare of open offices, and I work on a quiet floor, but sometimes I wish I had a door I could close.
I also have a great deal of influence over my hobby horses - infrastructure (AWS) and Devops.
“Every person in your company is a vector. Your progress is determined by the sum of all vectors.” — Elon Musk
Not much beyond that, except that my users had a clear need, and I was given time to do the work. Had a private office, but that mattered little.
My moral: Sometimes you really can make lemonade out of lemons. Maybe the torrent of shit raining down on you is a gift sometimes.
The end result is I am extremely happy in my work hours and arrangement as long as I don’t have early morning doctor appointments or something.
Ever since I saw that video, I've worked hard to (1) make sure others aren't negatively affected by my schedule (2) accept that until something brings me back to a 24-hour cycle, I have to persisently keep working on (1). Every other week I will go to bed at 10pm with my wife and wake up naturally at 5am and she'll have a great day being coordinated with my schedule. But within a week I'll be going to bed at 6am and waking up at 12-2pm. Every month or so I will stay up 30-36hrs without even trying.
None of this is due to bad habits, lack of sunlight, or lack of exercise etc. Doesn't matter what I do or don't do, my body just doesn't live in a 24-hour world. So I've learned to let it do its thing and work/sleep/eat/play when I feel like. Never been happier.
Also: a great manager who advocates for my product and career and shields me from politics.
It was just the three of us in a decent sized room and I feel that my work satisfaction and productivity was double what it was anywhere else in the open plan office space. There were very few distractions, but our office was open-door and just off a commonly used hallway so we weren’t hiding. We had enough space for a whiteboard and a 4th desk that we used for reviewing work together.
A few months later one of the managers saw what we’d done and decided he wanted it for his personal office. We went back to open plan :(
Tobias Funke, is that you?
The main function of the Scrum Master is to shield the developers from all the non-development crap. I've worked with one guy who was so good at it he would play interference and defend us from outside interruptions almost literally (actually blocking people from coming to our desks, making sure we could focus, holding meetings only if someone on the team expressed some kind of blocking issue that he couldn't solve by himself, etc)
Sure, probably this was more about him being a good manager than the "process" behind it. But no matter the process, if a manager is destroying productive time from the developers the fault is in the individual, not the environment or process adopted.
Of course also that, but you're completely right that that is the exact job of the Scrum Master. To "remove impediments". No matter if the impediment is some process or a manager, it's the Scrum Master's job to remove it.
This actually aligns pretty well with the ideas in Agile Manifesto. And that's why I'm so sad when "scrum master" nowadays mostly seems to mean someone who counts the minutes devs spend on each Jira ticket, and haunt the team when velocity seems to be dropping 10% for the second day in a row.
Why can't it be both? Bad managers can be empowered by a process, just as good managers could be hampered – no?
Agile provides so many tools for bad managers to micro manage, so that even if the process itself is well intended it still could lead to hell – no?
So, no. Bad managers should not be empowered by Agile. They should be weeded out, by other people first and, failing that, results second.
We can’t really ever hope to make progress with improving productivity or work environments if people contribute to be this reductive.
A “scrum master” role does obviously not “literally seek to destroy developer time” - it’s a patently ludicrous assumption. But if you are in a situation where this is happening - rather, where a “scrum master” role is getting in the way of work - then it does point to something else going wrong in your organisation.
I feel most jobs, at some companies in some situations, are absolutely justified. The problem is that then every company thinks they need to follow suit, and it ends up being a giant time sink. I'd wager most scrum masters are viewed by their team as a net negative (my opinion). But of course no person whose job acts as a hindrance will admit as much.
When I’ve done contract work, and when I ran a startup, I started tracking my own time. I find it helps me focus and account for my time and understand my own habits. It’s not very good for open problems or exploratory work, other than to find that they take a lot of time. ;)
Other than tracking myself, I’ve never had a job that measured my time directly. I had one job that did measure when employees were at work, but they didn’t show it to employees nor set any quotas, they just wanted to understand work patterns.
WHY dont we do something about it? why are we going like cattle to the slaughter house? We are developers right we are supposed to be smart, intelligent yes, we have let this come all over us step by step until we have lost our life.
Developers - it's time to raise to the basic work environment, we need space, we need to do our work with focus, and YES we need separation between work and home.
If a company needs work-after-work they should hire people for these after-work hours, if messages are sent after work, and it's just this additional answer this mail, it should either be handled by workers who work over these hours or just wait to tomorrow
We have let this on us, and it's our duty to bring back the focused work environment and the joyful home environment without interruptions from work or being oncall or answering messages.
Companies _will not_ negotiate things like letting developers have autonomy over the process by which the work is managed and delivered, or letting developers have private offices.
This is just standard Moral Mazes 101 stuff. Preserving the property that employees behave like obedient dogs instead of free thinkers is the absolute number one mandate, to the detriment of all else.
But yeah, what the other commenter said. Just do it!
In all my jobs since, I have worked in a more agile setting. By that I mean that the team is small (less than 10 people) and sits together with some sort of product owner. Not private offices, but rooms where only people working on the same thing sit. Frequent releases, fast feedback. Very few meetings, most issues can be worked out in the team. In my view, this is a quiet environment, but occasionally there are dicsussions that you overhear (but that is not a problem). In these types of environments I have been much more productive than I was at Ericsson.
The thing is, you can have development standards that require small iterations that are immediately deployable and this are immediately tested and deployed, without pulling all the overhead of some PMs interpretation of scrum.
I often find the power is generally with the wrong people and they promote the things that matter to them at the detriment of everything else.
I don't personally believe this is by design, it's just people in $foo management position tend to have the soft skills to make their job easier, when many of the developers often don't. And managers, who tend to control budgets and define departments, tend to give those departments to more managers and there's not a lot of people in the room telling them that a software person should probably run a software team.
There are two great quotes that I think capture this:
“A complex system that works is invariably found to have evolved from a simple system that worked.” John Gall
“Enlightened trial and error outperforms the planning of flawless intellects.” David Kelley
It is really sad to read about how often the agile ideas have been misused!
After 20 years that's been my experience
Inexperience is easy correct if you have skilled developers and the inexperienced person is willing to learn.
I do have to admit, I'm not sure about what to do with untalented...
You'd think I could cope with this by working from home, but that option is limited, too.
- those who like open office can sit together, but for the rest, provide a semi-isolated quiet/dark area to concentrate in and a whiteboard.
- plenty of conference rooms.
- if expecting to work with new tech/framework, allow reasonable time to learn during work hours. - allow time for documenting
- allocate time for fixing tech debt every sprint
- provide training on the product being built
- give good insight into product decisions
- if unexpected work has to be added mid-sprint, pull something else out!
- acknowledged that when someone worked all weekend to finish something that they get a bonus day off some other time
- keep process meetings to minimum
- when a developer brings up a security flaw, take him/her seriously
Good funding
People with multidisciplinary skill sets
Python
No silos
Access to agile contractors when a burst of effort is needed
Good reach and visibility within the organization
What has worked for me to facilitate my best work is to reserve a meeting room to myself for one or two hour slots during the week. This allows me to close the door, put my back to the window and get focused. What's great about this is this limits visual distractions, restricts uninvited visitors, and reduces auditory distractions (I will usually wear headphones and listen to non-lyric music).
Often I find that I will get more work done in this period of time than I would if I was sitting at my desk.
Really didn’t value that place enough.
Project is managed mostly through airtable with quarterly goals with weekly’s and daily’s (not standup) to check on progress. Then we have a company/team wide call every tues for the weekly brief.
All the above enabled me to have the best environment by then investing in my home office. A space that has a good desk (multitable sit/stand), chair (aeron), and good lighting, not to mention a beautiful machine (iMac Pro).
The issues that followed were more of the focus issues when doing work at home, so I got a pomodoro clock which then made everything seamless.
In those 5 weeks I’ve built the major part of the scalable distributed OLAP Cube that had proved to be very simple, robust and reliable and was still in use to support telemetry of over hundred of customers after 5 years.
The biggest distractions were a cat, incredibly beautiful rain showers, and warmest ever discussions at the dinner table.
Never had more productive study sessions in my life. 1 hour bike there (listening to lectures on my phone) + several hours studying at a picnic table, eating Thai food + 1 hour bike back (w/ audio lectures).
I think there's something special about the combination of being 1) in a small community, 2) relatively disconnected from rest of the world, 3) surrounded by natural beauty.
I've never been able to replicate that environment since. I've read a lot about summer shifts on the Antarctic bases--sounds idyllic for the same reasons as above.
- No Slack for non remote
Slack is cool, but I remember thinking that if I needed to talk to someone, it's over email or in-person. This really encouraged face to face or email conversation. There was also Skype for remote workers, but if you're not doing remote, you could kill Slack. Now that I think about it, Slack is more of a vitamin than a pain killer for non-remote organizations. Slack is great for remote though and love it.
- No Agile
Ah, I remember when I had my first job using Agile. It was cool the first few weeks and that was it. Again, it's not a pain killer, it's a vitamin. I had the best time ever just sitting in meetings on Tuesday mornings to demo everything in person then do code review with my CTO after. Talk with the whole team including marketing on what we'd work on. I loved it. No agile, was completely in the know and performing.
- Support with Tools
It sucks not having the right tools to do the job. Receiving the appropriate hardware, desk, and software has always been useful and makes me happy to come into the office. It really sucks when you wake up, look at your amazing at home desk, then go to a lousy work desk. Bling out the work desk. You can do anything from getting a top end work computer, a great monitor, an eGPU (may actually save a company money from AWS bills), a DAC/AMP (cause devs usually have a thing for headphones and the budget for great ones), or a desk goes up and down and has memory settings and it's fast.
- Minimum Friction
If you get told you need to change up your landing page, change up the tooling, or do a big refactor on something, always take it seriously. Some people marry a concept or an ideal and it can often cause friction between the team. Giving up the consistency and letting others use what best let's them get their job done should be given time and thought. All in all: be fluid with company practices and not letting a "mono-culture" take root is usually best.
My best experiences have been when a single employee can happily recommend a new way that could radically change the initial experience of a customer or a company culture. The fluidity maximized sales and development.
- Wrap up
We have so much now with tools that can be categorized as pain killer or vitamin. My best recommendation is to have less vitamins and more pain killers.
Note: This is just me though. I know a lot of other people have different ways they prefer to work. This is just me.
I know I'm discussing Scotsmen here, but: what about this is not agile?
• Agile as a set of values
• Agile as a set of practices
• Agile as a faddish silver bullet marketed to people who don’t know any better
I assume OP is thinking mainly of the latter two. It sounds like their business avoided formal standups and sprint planning, and didn’t generally care about Agile/Scrum etc. buzzwords. But I tend to agree with you that from a values perspective that seems perfectly Agile.
Agile has a dirty name now, but it's well-deserved, because most folks have had legitimately terrible experiences with stuff sailing under that banner.
I've had a legitimately awesome experience and I can't really use a different word, because it either creates confusion or sounds like sneaky wordplay and/or self-marketing hoopla.
I had a job where, due to the technology, I could not TDD. There was no sane way to version control. No CI/CD, changes had to be made in dev and then copied & pasted into prod. Before that I was in a job with pairing, TDD, CI/CD and an avowed commitment to agile.
Of the two, the ostensibly-not-agile was more agile, because it hewed closer to the values of talking to people and focusing on doing the most valuable thing first. I would work on projects by myself. When I wanted to learn more about my customers, I walked across the campus and talked to them. If I had something I wanted them to give their opinion on, I would ring them and tell them to take a look.
At the ostensibly-agile job we had a manager who talked to a middleman who talked to a board of directors who heard from a line manager who talked to his employees. It didn't matter how well we did the inner loop, because a lot of the time we just produced beautifully-engineered diversions.
- <80 person team (total); ~60% engineers
- 0 product managers: design and engineering are equally empowered to make the site nice within general business/product definitions defined by GM who would constantly get excited about the work you showed her, making you feel good about yourself and your work
- 0 project managers: business understands that there is no magic formula for delivering products that haven't been built yet and so long as we try our best to hit dates and cut scope as needed, it's on us to track our progress and determine priorities
- gm, cto, and head of hr all supportive of growing team and individual members in a non-political way
- politically-driven employees (typically a head of sales or marketing) shut down and churn out quickly
- engineers talk directly with customer service
- engineers perform rounds helping out in support forums
- domain specialists, but no fences. i might be a web engineer, but if there's a sql query i feel compelled to optimize, nobody is going to stop me.
- company regularly interacts with, and hosts local events for, an engaged user base. engineers actually end up having in person conversations with our users, gathering honest feedback for improvements while simultaneously being told how great the product they contribute to is overall
- relaxed hours ("you're an adult; we trust you to get your work done")
- when dining out or getting drinks, even paying by cash a large group is able to come up with the right amount of money, with no one person needing to chip in more than necessary
- anyone in the company can deploy the site with a single chat room command
Management and middlemen can as much help velocity as they can hurt it. More hands doesn't always mean faster work ¯\_(ツ)_/¯
If you have people under you, or can coach your people to take parts of your responsibilities off you, I think that's a great outcome. If your ICs are so good that they can actually do that, you should give them a raise and be glad you get to focus on other things in the meanwhile.
Of course, if the manager is unable to then broader their own scope, they indeed become disposable.
We recently spent quite a while on developing a feature only to find out the customer didn’t actually want it.
It was the most productive I've ever been. The code I wrote was mostly garbage, but I got my reps in that summer and learned how to program.
1) Pair programming, with the VP stopping by every couple of days asking "where are you guys stuck" and would actively try to solve our problem.
2) Story prioritization - each PM would write product stories for the backlog in an effort to get them in the next sprint. The same VP (above) would review each of those stories in front of the PMs and developers. If it were really lazily written, the PM was shamed, it was thrown out, and could be resubmitted for the next week. Developers got to ask questions, add tidbits regarding prior work that may need to be studied to complete the story.
3) If a bug made it out in the release, it was no-one's fault. Everyone worked as quickly as possible to either create a patch or roll back the feature completely.
P.S. That VP of Engineering is Andres Camacho. He's in San Francisco. And he's amazing. Work with him if you have a chance. He's well known for hiring Jr developers, training them via pairing with them intensively, getting them up to speed quickly and having them contribute meaningful code within a few days. He's now the CTO of Better Therapeutics.
1. If I've not done my job as a PM, then it's much better to figure it out earlier rather than later. If engineers struggle on without the right support from a PM (whether that's stories/requirements, oral clarification, ...) then that can slow things down or create worse outcomes. So I'd rather someone call out holes in my work at the earliest possible opportunity, then be polite so the problem can get larger.
2. In a high trust environment, people can take criticism of their work without taking it personally. It's hard to achieve this type of relationship (with specific people) or environment (with a group of people), but can make things much smoother.
3. I feel the job of the PM is to make the team successful through whatever means possible. Feedback/criticism directed at me is a valuable source of information to support that, whether or not I am the correct target.
I also read "shot down" as a constructive and expected feedback mechanism. In small teams, it might be the TL or eng mgr who provide this feedback, but for larger product business cases are often required for review by executive stakeholders, and they will always be terse, hopefully constructive, but frequently come across as overly negative. Why? Because they're gatekeepers and it's their job to ensure the best opportunities are pursued and the rest are either back burnered or sent to the graveyard.
But people often choose whether or not to take something personally, and their reaction determines the outcome. Consider the following situations:
A. (Bad case) You criticise my idea/proposal, and I interpret that as you criticising/shaming/blaming me (i.e. I take it personally). I then decide to ignore your criticism, because I feel it is based on your personal opinion of me, which I know is incorrect.
B. (Better case) You criticise me personally (e.g. "you're a bad PM, as evidenced by X"), and I take it dispassionately, trying to understand why you feel that way, use that to inform my understanding of the situation, and find a way to make things better.
In A, my idea was criticised, and there was no positive outcome.
In B, I was personally shamed, but there was a positive outcome.
I cannot change how people communicate (at least in the short term) but I can change how I react, and hence what impact I have on the outcome.
Idea can be criticised, never individual. Your argument may sound right, but it is not considering everyone. Your argument is saying how one should react, but is not answering what if one reacts differently. How can we mend it.
Leader is one who is compassionate and has ability to differentiate idea from individual. Work is not entirety. Idea will never define a person. whenever we critique, it is best to keep it till the idea and never to person. my few cents.
And I always aim to criticise the work/behaviour and not the person.
However:
- When I criticise a piece of work, someone can still choose to interpret it as shaming or a personal attack.
- When someone criticises me personally, I can still choose to focus on the useful part. I don't have to feel offended/upset.
When someone criticises me personally, I can still choose to focus on the useful part. I don't have to feel offended/upset.
- This as mentioned before, this we cannot make a rule but a guidance but this is very personal to the individual and most inidividual even if he is not offended, will not work under him for a long time to come. which is not good either way.
If a proposal is bad because a decent idea is lazily written (as the original post states), it's appropriate to express disapproval at the person - if the only thing that was needed to change in order to make this proposal better was the person's attitude (do your homework properly before submitting the proposal instead of wasting everyone else's time), then it is constructive to target that attitude.
It’s incredibly productive for me but I’m lucky that I enjoy programming enough to rarely get distracted by my picturesque surroundings during the day.
1) condensed higher intensity blocks followed by larger breaks
2) distinct "seasons" of work that differ in projects/pace
At the micro (day-to-day) level:
3) no logging of hours
#1 and #2 are a product of the academic calendar. I find the regular 9-to-5 work week paradoxically draining. I'll trade a good chunk of my weekends and evenings for longer breaks between "ON" periods.
As for #3, one company I worked for simply trusted that you'd put in your 40 hours a week. It was more flexible and quite simply freeing. If I were in a good flow state I might work late to finish up a feature, then sleep in the next morning (provided there were no meetings). All without the tedium of counting quarter-hours.