How to Mess Up Scrum, Part 4

Another way to mess up Scrum, since I’ve already gone into adding work during a sprint, scheduling future sprints, and failing to prioritize, is…

Fake Reporting

Fake reporting is endemic in dysfunctional Scrum shops. Here are some examples:

  • “My meeting ran late so I burned an hour off the memory pooling story.”
  • “The boss didn’t want to sign off on DevOps integration. I just rolled it into the story about dropdowns on the UI because it has too many hours anyway and called it “refactoring.”
  • Using “defect bucket” as a recurring Sprint Backlog story. Seriously!
  • You can’t submit your time sheet to get paid without assigning all your time to an assigned task.

Continue reading “How to Mess Up Scrum, Part 4”

Legacy Code: Wrap a method

I’m a big fan of Michael Feathers’s book Working Effectively With Legacy Code, and now and then I reread it because there’s always something to refresh or remind me.

Right now I’m looking at the “Wrap Method (67)” technique. It’s really simple. I’m just restating it here.
Continue reading “Legacy Code: Wrap a method”

.NET people make everything so difficult

I do lots and lots of development with the .NET platform, mainly because the corporations in the Cleveland area that have money to fund large projects are Microsoft shops.

I used to have a real problem with Microsoft development, back when it was all Windows 95; the tools were expensive, flaky, and unreliable. Since then, the tools have improved to an amazing degree; now I can write code that actually works consistently on more than one computer, and it’s not utterly ridiculous to run Windows on servers anymore. So there’s that.

But in just the last couple of days, I’ve gotten back into the Ruby on Rails environment. Partly, I’m jamming with my college homie Dave Stagner on his amazing Congruence product; and also, I had to update this old Perl script that I’ve been using for years to sort my incoming email.

Continue reading “.NET people make everything so difficult”

How to Mess Up Scrum, Part 3

When you don’t prioritize the Product Backlog, you’re forcing everyone to think about all the backlog items at once rather than allowing them the blessed luxury of thinking about only the most important items right now.

In prior installments, I described a couple of ways to mess up Scrum: Adding work during a sprint and scheduling work for future sprints. This time, I direct your attention to another closely related way to mess up Scrum:

Failure to Prioritize

You know what? Humans aren’t that smart. We can think a lot about a given thing, but we’re not good at thinking about everything at once. Agile development recognizes that by letting us do just one, or perhaps two, things at a time and put aside the things that aren’t immediate. “Do today’s work today!” we say. “Do the simplest thing that could possibly work!” we say.

Those aren’t just cute slogans. They are reminders of how limited we are in our brilliance.
Continue reading “How to Mess Up Scrum, Part 3”

"You're Doing Agile Wrong"

Someone who fears reprisal will withhold information.

I saw this and just wanted to share it. What a great summary of how Agile development so often goes wrong!

I love this part in particular:

There needs to be an absolute lack of fear around punishment or reprisal for negative information.

Someone who fears reprisal will withhold information. This is especially significant on under-performing or troubled teams.

Look at teams that are behind schedule (and not by a small amount), and you’ll tend to find that people usually know what the problem is. Yet if they’re not able to communicate that, well, things go south quick.

 

How to mess up Scrum, Part 2

Scrum is not designed to provide certainty about the future. People who use Scrum are making a decision that they value other things. If you want to know with any degree of precision what will get done a month from now, or six months from now, that is fine but then Scrum is not for you.

Continuing in the series of How to Mess Up Scrum!

Last time I explained how adding work in the middle of the sprint wrecks the rhythm of the team and undermines the concept of setting priorities.

Long story short, if you’re management and your highest-priority requirements repeatedly become visible to you in a shorter time frame than the length of a sprint, your sprints are too long! Finally, if you can’t make your sprints short enough to accommodate changes that are truly of the highest priority… then Scrum is not for you.

But let me talk about another great way to mess up Scrum, if that’s what you insist on doing.

Predictive Scrum

Continue reading “How to mess up Scrum, Part 2”

How to mess up Scrum, Part 1

If you have to add stories during a sprint, the problem isn’t Scrum or its rules. The problem is that your management can’t think a week ahead. FIX THAT.

I was just reading that 83% of software developers responding to a survey are practicing some form of Agile. Probably, most of those are trying to practice Scrum.

First thing, that’s probably wrong. Dividing all your work into “sprints” and having a daily standup meeting isn’t what Scrum is about, but that’s exactly what I see in the actual industry over and over again.

But rolling with that for a minute, let me talk about one specific thing that you should never do in Scrum…
Continue reading “How to mess up Scrum, Part 1”

Agile Excellence, Part 1

One narrative of a successful Scrum sprint. This really demonstrates how most big organizations are getting value out of Agile methodologies.

So there I was, slogging away on some .NET code at a largish enterprise that was “really into Agile, we’ve been doing Scrum for like three years now!” We were a week into the current three-week sprint.

At that morning’s standup, we’d gone around the table as usual. Jon said he was taking the refactoring story on the WCF middle tier. Ellen, who I think was Scrum Master of some other team, assigned me the task of resolving an exception that was being thrown by client-side code. Jeff said he couldn’t package the database changes because there simply wasn’t anywhere to check them into TFS (version control). I had code checked out, modified, and working to implement a feature in an upcoming release; but I was holding off on checking it back in because, per the team lead’s policy, we can’t have more than one branch “because people keep doing it wrong.”

That afternoon, the team lead’s boss came around and called a quick meeting.

Phase I, he said, was running late and he wanted to know why. And furthermore, when was Phase II of the project going to get done?

Ellen said she had all our burn-downs and they checked out, as everyone had burned down approximately forty hours. She had also added up all the estimates for the stories that were going into Phase II, and they came out to 990 hours, and since we had six team members Phase II should be done in four weeks. In fact, she said, we could put all of Phase II into the next sprint, which would give us just one week of carry-over.

Okay, that’s good, said the boss–but when can we start testing the current release, the Phase I release?

That’s when the team lead told everyone we don’t really have a deploy script for the test server, and there’s not really a production server at all. It can take IT a while to provision the new production server, he went on, but in the meantime we can host the production system on a spare Windows 2003 server. Jeff pointed out that Windows 2003 won’t run .NET 4.5 applications, so we’d have to retool the application to .NET 4.0. He agreed, though, that it wasn’t worth doing until after QA finished testing the current code.

But there were still a few tasks left before testing.

The boss thought my priorities in particular were off. “Look,” he said, “you can’t possibly need to have the API to FedEx done before the Data Access Layer.” I tried to tell him I wanted to hit the FedEx API first because it was a higher risk and thus would benefit from the greatest possible lead time, but the team lead cut me off, saying it was a low priority and wasn’t going to be in the current release anyway. (I later quietly asked, “Why was it in this sprint if it’s a low priority?” The answer: “We had to allocate all your hours and that was the only thing that would fit.”)

The boss whipped out his “to-do list” for the Phase I release. The FedEx thing wasn’t on it.

I was excused from finishing the API to FedEx, because another team needed that Data Access Layer done as early as possible in the sprint. It wasn’t on the to-do list either.

Our sprint ended successfully!

A couple weeks later, my feature in the upcoming release was still not checked in, but since my code was more or less done we figured it had to count. That WCF middle tier compiled and seemed to run okay, but the refactoring broke several unit tests that hadn’t been fixed yet. We added “Fix or comment out failing unit tests in WCF” to the sprint after the next one so we could get Phase II in first. The exception I’d gotten from Ellen took a couple of days to fix, because it had something to do with the Razor version we were using and I don’t know that much about Razor. Finally, Jeff’s database changes were handed over to a special meeting of the SQL Developers team, which was eventually going to build a schema repository.

As for rolling out Phase I, well, we had to add a story that simply read “Backfill to .NET 4.0.” The boss said that should only take a day so we assigned it three points. (Each developer was expected to do about twenty points per week, so that seemed about right.) Our scrum master said he’d take care of the test deploy script so it wasn’t necessary to add to the actual sprint. And we added a story (which just said “test”) for the QA department to do. We assigned it one to eight points, depending. And we’re not sure when that backup Windows 2003 server is coming through, but we created a story (“migrate to 2003 server”) for me to do. I don’t have production access but I can probably get an IT person to work with me on it.

You know what?

The great thing about working in a Scrum shop is that everyone’s super flexible and does the best they can without relying on management to tell them what to do all the time. It’s so empowering!

 

The new C++ standard

C++ is still vital. It’s changing and getting better. I like it. I wish I could use it more.

I spotted on Esther Schindler’s Twitter feed a link to the Dr. Dobb’s article on the new C++ 14 standard.

This is exciting for me. I really like C++, even though I hardly ever get to use it. It’s a super-sharp power tool that simply isn’t as useful as C# in the database-heavy applications I usually work on. I have a lot of nostalgia wrapped up in C++. I remember running across the Stroustrup book in the public library (of all places!) and being fascinated by the concept and implementation of object orientation.

Sure, a lot of people would say that ruined me, because C++ is far from a purist’s language, but in its era C++ offered a pragmatic solution to a great many typical development challenges.

What’s new in C++

First of all, you know how you can use that var declaration in C# when it was too inconvenient (or at times impossible) to specify the type of a variable? You can do that in C++ 14 and you can specify the return type of a method the same way!

There’s a new [[deprecated]] attribute. It doesn’t break any code, it just kicks out a warning when you try to call anything that you’ve flagged as deprecated. Good way to soften the transition away from an API or implementation.

Syntactic sugar: You can now have digit separators in constants. You can write a million now as 1,000,000 if you want.

Generic lambdas with auto type parameters! That’s kind of esoteric, but the point is being able to declare lambdas that will figure out for themselves at compile time what argument types they need. It makes them more reusable.

Conclusion

C++ is still vital. It’s changing and getting better. I like it. I wish I could use it more.

Perils of "contracting"

“I haven’t had a real job since 1996.”

That’s what I keep telling people, and that’s largely true. If by having a real job you mean a salary, a long-term connection to a single employer, and company-paid benefits, then no, I haven’t had a real job in that long.

Honestly though, a lot of what I’ve been doing at work in those 18 years has been largely indistinguishable from having a real job.

Much of the time it’s easier and more profitable for me to work with those third-party contracting firms. They take care of a tremendous amount of the work that goes into getting work, and the good ones take a fairly reasonable cut off the top. (Typically it’s 25%, which sounds like a lot but have you seen how much staffing firms in other industries take?) What’s nice about this for me is that these firms have existing staffing contracts, functioning accounts receivable and payable, and a steady flow of open work requisitions. Most of the time, when I’m nearly done with a major project at one client, the same contracting firm goes through its existing client list, finds an open requisition that matches my skills, sets up an interview with the hiring manager, and has me checking in on the very next work day.

When all I care about is remaining “billable,” this is a good system. There are a few downsides though.

Requisitions are pigeonholes.

They are looking for programmers, QA people, project managers, and system administrators. They are looking for these people in either .NET or Open Source flavors. Add one category for network administrators, who seem to be allocated on a platform-neutral basis. (I don’t really know; it’s not my area.) That makes four times two plus one equals nine actual jobs that exist in the world of third-party corporate contracting. There are no coaches, no problem solvers, no interdisciplinary people, no jacks-of-trades. If your background makes you really good at seeing why their waterfall is blocking or at picking out why QA keeps having to look at the same defects over and over again, that job description doesn’t exist to them. So you have to decide which one of those nine things is you, and go with that, even if it’s an oversimplification of what you’re capable of.

Contract-to-hire is a scam.

Another downside, to some of us, is that creepy, weird “contract-to-hire” status. A lot of companies bring on technical people, on a contract basis, with something like a “right to hire” clause in the contract. I’m not clear on what this means exactly, because I don’t even consider those things, but it sounds like they’re asking you to accept a job they haven’t even offered yet. That sounds like a terrible deal. I’m supposed to sign a contract that locks me into a salaried (implied somewhat permanent) job when I’m not clear on what the job is, what it pays, and what the benefits are? What the hell is that about?

I don’t do “contract-to-hire.” It’s designed to put the worker at a disadvantage. Why would I want that?

Sigh, management

Yet another downside came up for me a while back, when I was about halfway through a six-month contract gig doing .NET development. It was going pretty well. I felt like I could have caught on faster to how the client’s ancient version control system worked, and it was clear that they were having some trouble allocating people to their three or four Scrum teams, but I did get to help a lot with a new product launch. My handler at the contracting company called me now and then just to say he was hearing good things about my work.

At one point though, I emailed my team manager (who supervises maybe about two dozen people) to let him know I would have to take an unknown amount of unpaid time off, specifically saying “my partner Jamie”–I used those words–was having gall bladder problems and there would be some hospital time. That week I missed a day and a half. My handler called the following Monday to ask why my timesheet read 28 hours rather than 40, and I told him. You would think that would be good enough, right?

That week I also billed 28 hours with another day and a half off of hospital time. It did turn out to be more than your typical gall bladder issue. Keep in mind that I was always keeping the team manager updated.

This place does three-week Scrum sprints, so missing three whole days is somewhat significant, and I had to scramble a great deal to come fairly close to fulfilling my share of the sprint. (That’s another issue: Scrum is a team commitment. We’re supposed to compensate when someone falters. That’s the idea.) Those three weeks were ugly. My personal burn-down chart looked like a jagged sine wave. But it did hit bottom in the end.

Speaking of hitting bottom,

after that, it wasn’t remotely the same. Even though my role going in was clearly to stick with .NET middleware development because I’m not good at front ends and browser scripting, I got handed a lot of browser scripting defects. (Again: not so great Scrum, right?) Planning meetings for the next big project were carried out in my absence. Standup meetings even got a little hostile. One of my handlers called to criticize me for having a personal life, with some reference to not deserving unpaid time off. It was weird.

What Jamie said after all this:

“Next time, just say it’s your wife.”

All I can figure…

…is that in this shop, they feel that a person who’s willing to work on a contract basis should be so grateful for the opportunity that we should drop absolutely everything else, including family and loved ones, for the opportunity to be micromanaged and disrespected. And pretend to be straight while we’re at it.

I chose to finish the six-month engagement quietly before taking a nice vacation. And if that particular staffing company ever wants that 25% of my billing rate again, we’re going to have a rather direct conversation about who gets to have an opinion about their sense of entitlement to my personal life.

So I don’t do that.

Here’s how it goes. I do a lot of straight-up freelance work–custom application development, coaching, training, and team leadership–directly for all kinds of businesses and organizations. Doing my own marketing and business development is actually a huge amount of work, and it gives me all kinds of respect for the people who do that all the time, but it’s still my job so it doesn’t feel like a distraction.

In fact, what I learned from gurus like “Original Mark” Silver and Robert Middleton is that marketing is inseparable from products and services. Part of delivering great work is letting people know it’s available. Part of publicizing what you do is the act of doing it. It’s actually not realistic to say “I only write code, I don’t do sales and marketing.” You’re doing it whether you know it or not. Whether you like it or not.

Thanks but no thanks

So when the rent-a-geek firms call, and they will, I think I’ll start referring them back to this blog post and thank them for their interest. I like having tons of billable hours handed to me, but at this point the attached strings aren’t worth it.