Agile

This is how I work in my career.  Some of these are counter-intuitive and require explanation.

1. Shipping code wins.
2. On schedules: Picking an arbitrary deadline is often more efficient than carefully planning things out.  I’ve spend 20 years decrying this, but if you add up the time you spend planning, negotiating schedules, then executing, it’s less pain if you just work-to-deadline and throw features overboard in the process.
3. On teams: A disciplined team of professionals cultivating mutual trust will outperform a team of talented jerks.  There are exceptions, but only if you’re writing the Linux kernel or something requiring 10x insights daily.
4. On technology selection: Always pick the technology 1 step behind the bleeding edge, because it’s mature and documented For example, when everyone was going to Rails, use Spring MVC.  This will reduce your technical risk profile in every single case. 
5. Treat everyone as though they might be your boss someday.
6. Code only exists if it’s checked-in to version control.
7. If your team mostly cares about efficiency, run.  Now.  You don’t care about customers and growing.
8. The truly insufferable don’t last long.
9. Managers are much smarter than you think they are.
10. Project managers can help, if you let them.
11. You are not your code.  
12. You don’t own your code; your employer does.

There are many more, but that’s off the top of my head.  Mostly what I’ve learned in 20 years is “the people who came before us weren’t idiots.”

Herein, I shall commit heresy.

I’m going to suggest that “Software Strategy” is useless:  Enabling success involves the very large, and the very small, leaving “Strategy” in the useless middle.

Who am I to say this?  I’ve been in software for 18 years, and I’ve been in a leadership role for the last 8.  I’ve spent innumerable hours in “Strategy” meetings.  I’ve had just about enough of that and I’d like to suggest a better way.

Let’s imagine you’re a Program/Product Manager, SDM, or Lead Engineer/Architect.  You’re starting a program to develop tech thingie ‘X’.  You’ve read all the books.  You’ve looked into Agile, from the brevity of the Agile Manifesto, to the what-are-you-selling nonsense that is the Scaled Agile Framework.

In all that, you come to the same decision that people have had since Amenhotep designed the first pyramid:  How do you organize yourself?  That is, how do you set-up your group of people to accomplish the task?

A few quick thoughts on a subject I’ve seen at least 10 times in my career:

“Okay, when are you done enough for me to test this thing?”

Let’s parse that a bit, because the ensuing arguments are one of definition

• “Okay,” Acknowledging that stuff is just great or else I wouldn’t be talking.
• “when” I’m going to ask you for a date.
• “are you done” Done as is: Things won’t change between the time I hit submit on the bug and I go to the bug review meeting and look like an imbecile.
• “enough” I’m not a total douche.  I’d like to test this, not make you look like a fool by filing 15,000 bugs.
• “for me” Hi, I’m a professional software tester.  Yes, we do exist.
• “to test” I was born to test and break things.  I can make your code cry.  You need me.
• “this thing?” At the end of the day, your work of art is a piece of business value and I’ll not insult both of us by implying otherwise.

The above is the way a real QA professional sees that question.  I think.  Because, I’m not a QA professional, and God HELP YOU if I were.  I maintain my decade-plus assertion that great testers are born, not made.

So, I’ve had a few rants thoughts on process in the past.

I’d like to revisit those with my Big Boy pants on.  For one thing, during my current job search process, my experience in Agile in the past 4 years always comes up, so I thought I’d parrot here what I generally say in the interviews, on why you’d choose one versus another.

If you’ll allow me, I’m going to argue that both are valuable, and both should be in your organization.

I’ve been a software developer throughout the “Agile Revolution.”  My first team lead, back in 2001 said these words to me and I’ve always taken them to heart:

I think the world’s pretty done with us [Software Developers].  I feel like we’ve got about 5 years to get our act together or that’s it.

Apropos, that same year a highly influential group of practitioners signed the Agile Manifesto.   Amid waves of Dot-Com-Bubble-Bursting, offshoring, and right-sizing, they kept it simple:  Here’s what works; apply liberally.

Ah, the Spotify Engineering Culture.

We’ve all heard the gloss:  Small, independent Squads organized into buzzwordy terms like “Tribes,” and “Guilds.” These terms hearken to days past in humanity, days of community and craftsmanship.

Here’s what I take from the above:  None of that fricking matters.  What really matters is a throwaway blurb at the very end of the video, starting at 12m 30s.  Transcribed here:

We’ve learned trust is more important than control.  Why would we hire someone we don’t trust?  Agile at scale requires trust at scale, which means NO POLITICS.  It also means no fear.  Fear doesn’t just kill trust; it kills innovation.  Because, if failure gets punished, people will be afraid to try new things.

Way back in 2004, I wrote a short review of Tate’s Bitter Java

Basically, when this book appeared, Java was ~8 years old, and was at the peak of its hype cycle.   Embraced by both the enterprise software world (okay, IBM) and the nascent open source community, Java was the golden hammer, fit for any problem.

Except, it wasn’t.

People who could program, but who weren’t familiar with domain requirements began writing Enterprise Software, and they began making a mess of it.  My own company had to write-off about $7.4 million on a “failed software project” back in 2003.  Suddenly, the C-levels stopped saying “Maybe we should rewrite our stuff in Java.”  Historians term such retrenchment the Thermidorian Reaction, predictable after every revolution.  For us in the industry, it was the heart of the doldrums between the Y2K largesse and the onslaught of Web 2.0.

http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

Engineers are hired to create business value, not to program things:  Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs.  Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things.  (That can, but does not necessarily, entail actually doing them.)  The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs.  Producing beautiful software is not a goal.  Solving complex technical problems is not a goal.  Writing bug-free code is not a goal.  Using sexy programming languages is not a goal.  Add revenue.  Reduce costs.  Those are your only goals.

I’ve been part of two SCRUM rollouts so far.  One was a grassroots effort, the other organizational.  I have some thoughts I’d like to share, in no particular order.

• It’s no silver bullet.  Repeat that last sentence 10, 50, 1000 times until you believe it.  If your work habits, talent, training, and support roles suck, your (insert work product here) will still suck using SCRUM.  On the bright side, you’ll understand that in 2 weeks to 2 months, instead of years after the product is in the field
• SCRUM teams: 10 people max, and that’s pushing it.  Five is better.  I was on a 6 person SCRUM team, and it was great.
• Team of Specialists versus Team of Generalists?  I’ve no idea.  I’ve arguments for either approach, and no one answer fits everywhere.  Yay, “It depends.”  I could be a consultant.
• The team must see the value in SCRUM.   It’s a lightweight process, but it requires them to think and communicate on a level they haven’t before.  If it’s a drag AND they have to communicate to one another, they’ll abandon both.
• Don’t B.S. the acceptance criteria.  If you don’t complete a user story, you don’t get credit, period.  This sort of boundary helps focus the SCRUM team when it’s committing to a story.
• Enable the team to organize itself once it’s gelled.  Yes, that means kicking the dead weight overboard, too.
• Empower the SCRUM master to do his/her job.  Measure if s/he does it.
• Project Manager != SCRUM Master.  The skillset and attitude is different.
• For heaven’s sake, DO NOT MAKE THE TEAM LEAD THE SCRUM MASTER.  I was a team lead and a scrum master for about 2 weeks.  Disaster ensued, and I got help for my team.  Basically, anything that lets the team lapse into a parent/child relationship will destroy a SCRUM team–they must feel like they have the power to make something happen.

Some things that I don’t think SCRUM wholly solves (nor seeks to, if you seek a cop-out):