You're not alone. I definitely feel like this is / will be a major adaptation required for software engineers going forward. I don't have any solutions to offer you - but I will say that the state that's enabled by fast feedback loops wasn't always the case. For most of my career build times were much, much longer than they are today, as an example. We had to work around that to maintain flow, and we'll have to work around this, now.
(I am not a lawyer)
It’s ok in the US to have a goal to hire more women or URMs, and to do sourcing, etc. to bring in more candidates like this.
I think the potential concerns here are the use of “must” in the spreadsheet, and what activities you’ll be expected to perform, OP.
I’d recommend advocating for changing “must” to some other goal-based language.
If you’re doing the sourcing, I’d also think about setting goals here (x% of candidates moved from stage 1 to stage 2 are women/urms, for example).
What’s not ok:
* not interviewing or hiring someone because they are not a woman
* giving someone a different interview for any reason (barring accommodations for disabilities, etc)
* saying “we are only hiring women for this role” (for example)
* saying “we are not hiring any men for this role” (for example)
* having a quota that must be met. (i.e. a target, not a goal).
There are ways that this can play out that might seem discriminatory but are not. For example, if your goal is to have X% of final stage candidates be women and you haven’t gotten there yet, not hiring a non-woman final stage candidate that is otherwise hirable is not discriminatory. See the “Rooney rule” and other examples.
What I think you should do:
* assume positive intent. No one person is responsible for this systemic shitshow / imbalance, and people are doing the best they can to fix it. Understanding how to do that in the context of the law is sometimes difficult.
* advocate for the use of appropriate goals that support the initiative.
* politely object when someone asks you to do one of the “should not dos” above. Ask them to restate in the context of goals.
* don’t get caught up in culture warrior nonsense that circulates around this issue. You’re an engineer, recruitment is a system. Treat it like a systems problem.
* support your women colleagues and women in tech in general. Systemic bias is real. People who believe women shouldn’t be in tech exist. Do what you can to help overcome these obstacles.
Went to github, saw the word “sprint”, closed window. I really appreciate any effort to return us to basics. However, we should have a firm grasp on what the basics are first. Today, you wouldn’t batch all of your team’s code together this week and then do a build - you would build and integrate continually. Why would you adopt large batch, non-continuous process for your overall development process?
Every time there's a discussion on estimation the Planning Fallacy is brought up as a kind of trump card.
But it's not. First, psychologists have done research on how to ameliorate it. See the "unpacking effect" paper I linked elsewhere. Kahneman and others have also pushed using "reference classes". In the estimation literature this is called "estimation by analogy" and it is a well-established technique.
Which reveals the next thing about the Planning Fallacy; it comes from the psychological literature. There are at least two other bodies of literature which need to be dealt with before we give up entirely. The first is ordinary project estimation literature; most of the advanced stuff is by people from the Operations Research field. The second is work done by Statisticians working on what they call forecasting which is essentially parametric estimation of timeseries data.
These 3 bodies of literature seem to have evolved largely in isolation. I haven't see OR papers talking about the psych research, I haven't seen the psychologists citing the International Journal of Forecasting and so on.
tl;dr: author of the article is laboring under many false assumptions about Kanban (and lean software development in general) likely due to a combination of inexperience using such methods personally and unfamiliarity with the available literature. The following is a rather long attempt to correct the base misunderstandings in the article, with pointers to relevant source material. Enjoy!
First, an operational definition: Kanban as it's used in lean software development is 1. visual representation of the work that's in the system and what state it is in and 2. an opportunity to limit the amount of work that can be in each state.
That's it.
Almost every organization that writes software uses something to keep track of the work, and what state it is in - by this logic the title of the article could be "spreadsheets - the secret engineer killer", or "JIRA - the secret engineer killer".
According to the article though, Kanban is ruining engineering teams in "nearly every company" that has adopted Kanban out of the 150 companies the author talked to in the last 60 days. (Some numbers on how many of them are using Kanban, and for how long, would have been nice facts to include, btw.)
So, let's unpack some reasons why this is:
"Engineers are not assembly line workers" - Implying Kanban and pull-based systems only work for "widget producers" and forces engineers to focus on the individual trees, not the forest. I think this sort of highlights the author's misunderstanding of Kanban (and to an extent any pull-based system) and what role it serves in an organization. Kanban isn't magic - it not an organizational design, it's not a product development strategy, and it's definitely not a substitute for leadership. It's a chart on a wall that shows what the work of the product development organization looks like, right now.
For an example of an overall software product development strategy that incorporates pull-based systems as one component, I recommend checking out "Principles of Product Development Flow" by Don Reinertsen.
"It teaches you that you and your engineers cannot be trusted to estimate work or handle complex multi-faceted projects." - How does it do this? Nothing about Kanban implies no estimates. In fact if you use Kanban and measure cycle time, you will be doing evidence-based scheduling which will allow you to make better estimates. As for "complex multi-faceted projects" - I don't know what the author is talking about. Please read "Scaling Lean & Agile Development" by Craig Larman and Bas Vodde for some actual evidence and lessons learned on lean / agile approaches being used on huge software projects. Also "Scaling Agile at Spotify" by Henrik Kniberg is worth a read, as Kanban features there (by team choice!) as one small component in a lean software development org design / product development strategy.
"Kanban forces a 'one work item at a time' mentality and resists milestones."
This is simply not true and such a basic misunderstanding I have to wonder if the author of the article has taken the time to read any of the introductory literature. If not, I suggest the aptly titled "Kanban" by David J. Anderson.
Kanban wants you to limit work in progress, which is one of the basic goals of any product development system. It doesn't say how much it should be limited, or where it should be limited. Every system, everywhere, already has limited-WIP in the form of bottlenecks. The hopeful goal of pull-based systems in general and lean software development specifically is that you'll use these simple tools to look at your process and eliminate wasteful activities and streamline those bottlenecks that must exist to deliver maximum value to your customers. In this sense, you can use Kanban as a tool to maximize the whole of the product development process which is certainly a macro (org level) goal and outcome that stands in stark contrast to the claims in the article that Kanban in general promotes micro optimizations and misses the big picture.
For more general reading on why limiting work in progress is a good idea, I suggest "The Goal" by Eli Goldratt or more recently "The Phoenix Project" by Gene Kim.
As far as milestones go, nothing in a pull-based system is incompatible with milestones of fixed date or fixed scope. If your idea of milestones is chucking arbitrary dates on a calendar based on an estimate before work begins and then stubbornly refusing to adapt those milestones when the situation on the ground changes (i.e. milestones of fixed date and fixed scope), then I could see the potential nature for conflict, but surely you're not out there doing that in real life, right? (Right???) If you are, and that's the issue - Kanban isn't the problem, the problem is the assumptions you are operating on are faulty - nothing will work for you. Smarter folks than me have written about the perils of fixed date and fixed scope development, I suggest googling for Neil Killick's thoughts on the matter.
"High performance individuals and companies are goal and date driven."
Citation needed. I know many people really, really believe this but you should really verify. Also, see Fred Brooks "Mythical Man Month".
"Kanban was never intended for software development" - What? Again, the guy you quote actually wrote a book on using Kanban with software development teams. You should read it, as it would probably correct 90% of the misunderstandings in your article.
Those are the key arguments in the article about why Kanban is "the secret engineer killer". Hopefully by now it's clear that these arguments aren't very good and it certainly wasn't any trouble for me to refute them along with a bibliography for further reading. That doesn't mean Kanban or lean are perfect though - there still is no silver bullet. Hopefully this inspires some folks to launch a more throughly-researched critique of lean, kanban, or pull-based systems in the future as I think that kind of discussion can be really beneficial.
Well said. I find it is very common to use the straw-man criticism technique http://en.wikipedia.org/wiki/Straw_man about bad management practices. The quality of management is often bad. The quality of management, even of good practices, is often bad.
Criticizing those implementation of the practice is perfectly fine. But claiming that the practice is suppose to be something different than it is, is not fine. I agree with you here, that is the biggest problem. If you understand how kanban for software is suppose to be done, the criticisms don't make sense.
nice to see Ray Dalio's principles get a shoutout, although I wouldn't necessarily describe it as a "culture guide". Seems like there could be a section here on "system building".
