I only knew K. Scott Allen in a professional context; as a teacher and developer that loved to dive deep in .NET and teach others what he knew. He was a wonderful teacher, speaker, and a joy to be around. He passed away last Friday.
I met K. Scott Allen at the 2009 Stack Overflow DevDays. He was showing off some features in ASP.NET MVC (this was way back in the 1.0 days), and as invariably happens during a presentation, he hit an exception. So naturally, I tweeted to him:
Going through 404-based development with @odetocode Asp.net MVC talk at #devdays. develop untill you get rid of 404.
And
thus started a twitter friendship that has lasted. He went on from that
presentation to become one of the most popular (if not the most
popular) Pluralsight author, and share his love of programming with
hundreds of thousands of people (if not millions). He was the cohost of
the Herding Code podcast, and maintained a blog at OdeToCode.com
His grace, charm, and the devotion he had to helping others will not be forgotten. I shall miss him greatly.
Enterprise Software Team gets new project. Team rushes into requirements analysis and development. Team gets development environments set up, and team gets closer to deadlines. With the deadline looming, the team realizes they don’t have a deployment pipeline set up — Deploying to a shared development environment was always ‘good enough’.
In a recent example a team was modernizing a system through a rewrite (things you should never do), one of the new team members asked, “How do we deploy this system?”
The answer was that they manually copied files to the shared development environment, and manually ran database scripts for updates, and that there was no pipeline set up to deploy to any test, staging, or eventual production environment.
When that team finally got their application to a staging or production environment, they realized they still had weeks worth of work to do to be able to deploy.
If you’re a software developer or former software developer, that line should shock you.
But, if you’ve worked on an enterprise team, or an R & D software team, that may feel normal.
In reality, not having a deployment pipeline set up first of the riskiest parts of any enterprise project.
In Enterprise software projects (moreso than in product development) deadlines are driven by executives that have an older-school
mindset about work. You set a deadline, and work is done by that date
and the project is delivered. It doesn’t help that waterfall is easy to
understand and therefore easy to gravitate towards.
Software
isn’t a process that lends itself to deadlines well. Unless the team is
doing the exact work, in the exact environment, in the exact political
structure they were working before, any estimate they give is as good as
a guess, and about as accurate as throwing a dart against the board.
Take
this example: Hangfire (a technology for running automated tasks) has a
particular version that has a bug against a particular version of SQL
Server, and in certain environments (like an enterprise environment) it
causes unintended behavior (in this case, a proliferation of
xp_userlocks). No one could plan for that, even if they’ve used Hangfire
before. No one could have planned that the corporate IT team would
strike the use of hangfire, causing the development team to scramble to
rearchitect their solution to make up for this.
But, you know what would have caught that error sooner? The deployment pipeline the team didn’t have.
Enterprise
environments (and organizations growing towards a more rigid governance
model) have these separation of environments to ensure their data and
business remains secure. Software Development is necessarily new
every time a project is created. The software stacks change, the third
party libraries change, and the practices change. As I write this,
Angular (a common client side web application framework) has iterated on
6 major versions (Version 2-8) in the last three years alone. They
release a new major version every 6 months!
Because things are changing so fast and because data security is important, it’s critical
that enterprise software teams set up their deployment pipeline first.
Without integrating their work into the IT Governance infrastructure,
there’s no way to tell what risks will come to fruition without it.
In the beginning it may seem like a waste; but it is a bit like insurance: You’re paying early so that when the deadline gets closer, you have less risk for delivery, and due to the way that software works, that decision will pay for itself many times over.
Where baseball is superstitious, software development is trope-filled. We love metaphors and cliches as an industry, and sometimes those metaphors or cliches get weaponized against that thing Software Developers don’t want to do.
Like architectural diagrams.
Having worked with and around effective teams, I’ve found shared understanding boils down to one or more of the following:
1. Having a vision so clearly communicated that everyone just gets it. (This is shockingly rare) 2. Working with extreme amounts of technical discipline and in very small increments 3. Clearly laying out the path through diagrams and usable documentation as a starting point
It doesn’t help the conversation that one of the pillars of agile is working software over comprehensive documentation. This harkens back to the horror stories of the enterprise documentation process. It is this pillar that lends cover to the idea that if you’re “doing agile”, you don’t need documentation.
In the same way if you know how to drive a car and you know where you’re going, or you’re following someone, you don’t need a map…
…until your GPS craps out, or you hit the first red light and get separated from your party, or a funny light pops up on your dashboard and you have no idea what that light means.
Agile is a specific context; a context where the team is co-located; the customer is readily available; there are a high number of automated unit and integration tests, and the team works in the smallest increment possible.
There are contexts where that work; and lots of contexts where that can fail pretty hard: like when you’re modernizing an existing system through a rewrite.
If you find your developers are often confused as to what they’re delivering, or they keep needing to revisit their design or implementation; then one of the first places to look whether or not the team has chosen to visually diagram how the technical pieces fit together.
P.S., It’s worth noting the agile pillar says “over”, not “Instead of”. Agile teams value working software over comprehensive documentation, but sometimes you need that documentation to get to the working software part.
I’m a big How I Built This fan, and recently I listened through the OtterBox episode. One of the quotes (originally from E-Myth) that Curt Richardson (The Founder of Otterbox) talks about that struck him was:
Systems Run your Business. People Run Your Systems.
If I had to sum up the goal behind the
current DevOps revolution, that’d be it. “DevOps” is the attempt by the
Software industry to systematize what we do. If I had to sum up the why
behind the why behind the work I do, it’d be to help software teams
systematize their process. I’ve helped teams systematize their process
and have seen the productivity gains that arise from that work, and I
believe enterprise software teams can benefit from that as well.
Systematization has several parts:
1. Ensuring relevant information is easily visible and communicated. 2.
Ensuring the methodology used to develop software (Scrum, XP,
Waterfall, RAD) is the best fit for the team and is molded to the
culture of the team. 3. Automating and molding software creation
processes to the business to ensure software creation is low friction
(this is where I spend my time) 4. Ensuring Build and Delivery Systems are seamless and automated (CI/CD) 5. Ensuring the feedback loop from customer to team is effective; allowing the team to respond to change.
For your team, or your larger organization,
how are you doing? Are all those aspects systematized? Can you say that
each part flows into the others without friction? Do your systems allow
your team to move as fast as possible to respond to change?
There’s a particularly relevant quote from the article: “Answering ‘non’ gives you the option to say ‘oui’ [yes] later; [it’s] the opposite when you say ‘oui’, you can no longer say ‘non’!”.
Think about that. When you say yes, you can no longer say no.
And it’s true. We want to be accommodating, we want to give our customers and stakeholders what they want. And we somehow believe that by saying ‘yes’, we’ll be doing that.
What we’re actually doing is we’re adding time or money (or both) every time we say yes to a feature request, enhancement, bug fix. Software is a strange beast that way: If you don’t build a feature, it doesn’t exist. Not building a feature is free. If your business is deadline or date focused, not building a feature helps ensure you meet the deadline.
It’s by no means scientific, but the next time you either ask or are asked to say “yes” to something, think of it this way: Every yes adds time until whatever you’re working on will be shipped.
Big request: 6 weeks Medium sized request: 3 weeks small request: 1 week
That also causes a dilemma: The time you should say no the most is at the beginning of the project, when you know the least. Save the “Yes” for later or late in the project, when you have a better understanding of whether you can afford to add scope. Say no at precisely the point in the relationship where everyone is expecting ‘yes’.
That’s hard. That’s also a crucial way to build trust with deadline-driven stakeholders.
How many times have you heard in the course of a software development project:
I need this by <date>? If we don’t deliver <x> by <date>, we’re going to lose internal political capital? When can you get this to me by? I need it soon so <VP> will greenlight our next project.
This
is a common way to manage. It’s ingrained in management, and it makes
sense — internal management is often driven by deadlines. The trade
show deadline, the Q4 marketing push deadline. The release going out so
<business unit> can meet their deadlines.
Would it surprise you to learn that agile methodologies eschew this worldview for delivering something on a predictable schedule. It may only be a piece of what you want, but it’ll be delivered at a regular cadence. The idea of deadlines goes away for “are we on the right path generally”?
If this is a hard pill to swallow, “goingagile” may not be for you. Especially Scrum.
And you know what? That’s OK.
Your organization doesn’t have to be fully bought in gain some benefit
from adopting some agile practices — but I wouldn’t generally recommend
trying to adopt scrum if your environment is deadline driven. Your team
can get better, your team can deliver faster without adopting Scrum; but it all depends on your team, your culture, and your particular context.
Have a new project coming up soon? Building a new team? Hit reply and let me know, I’d love to talk to you about your culture, constraints, and context. Every software team can be more productive, even if scrum isn’t the method they use.