
The MBA Guide to Software Development - tschiller
https://toddschiller.com/the-mba-guide-to-software-development.html
======
throwaway2016a
Some observations...

The section "Signs of a Dysfunctional Software Development Lifecycle" ignores
a very common reason for "Your team is always in crunch mode" mainly that the
stakeholders insist on unreasonable goals even though the team says it's not
realistic because individual team members are not empowered to make decisions.

And under "Post-Mortems and Retrospectives" something doesn't seem right. I'm
not sure how I feel about focussing on individual team members failings that
way. You can't change who a person is as quick as you can change policy. I
feel it is better to have the policy gently nudge John in a direction that
discourages destructive overconfidence.

Edit: the appendix also seems a bit dangerous in that I'm now envisioning a
bunch of MBAs going to their chief architect... we have data scaling issues?
Why don't you just encode that field as a 0 or 1 instead of male/female.

~~~
tschiller
Thanks for the observations.

Other people have made the same observation about the signs of the
dysfunctional process table. When I wrote it, I was including stakeholders and
managers as part of "team". So the scenario you describe would be the business
side of the team not managing the scope properly. I'll need to update the
table to be clearer.

I agree that people don't change quickly. In those cases, you need to adapt
the process to guardrail them (e.g., add a check in the workflow) or put a
different person in that role. If you don't, you're just going to get the same
result again in the future.

For your edit -- is that a bad thing? Presumably a architect should be able to
explain their decisions. The major theme of the guide is that communication is
a good thing, especially when the different people are likely working with
different information and expertise.

~~~
throwaway2016a
Thank you, great article. I enjoyed it and I wish all managers would read
this.

Fair point, the manager should be considered under the team umbrella. The
stakeholder isn't always a manager, though. Sometimes it's a client. And one
of the hardest things to do is say no to a client.

I think all my criticism boils down to: guiding the discussion can be great,
dictating the discussion is not. Some MBAs (any managers, really) have a hard
time drawing that line.

One of the toughest things when you're starting a company is to let go and
trust your team. You don't have to solve every issue personally if you hire
smart people and empower them, which I don't think this article quite gets
across. I'm not saying there aren't times you have to personally step in,
because there certainly are.

One thing this does not touch on is prioritization. How do you decide what
gets built and what doesn't? But there are countless article and books on
that.

------
g4k
I would like to think that an MBA typically goes much deeper. This article
instead is pretty shallow.

It might suffice to ramp up your knowledge in the direction of knowing enough
to be dangerous, though.

~~~
tschiller
You're correct that a class on software project management would go deeper
into some of the topics.

This article is more aimed at getting a baseline conceptual understanding so
that you can figure out where and when to dig deeper.

