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!

 

Don't have coding standards

I’m doing a new thing now!

If you’re currently on my eZine and announcements opt-in list–and you should be, because it’s usually not boring–you found out about it this morning.

Long story short, and not to kill the suspense, the main thing is that if you send me some problematic C# code, along with a very reasonable amount of money, I will turn around a solid code review, complete with prose narrative, suggestions, and maybe even bug fixes. (I’ll put all the details up next week, but that’s next week’s problem. You should be on the opt-in list!)

One thing I won’t do, though, is impose “coding standards.” I don’t think you should have them.

Why you shouldn’t have “coding standards”

Okay, that’s actually wrong. I do think you should have coding standards, even if you work by yourself as a lot of my fans do. Have a regular, standardized way of naming things. Of indenting. Of when to break something into more than one class. Of when to unroll loops.

Sure. There’s nothing wrong with that if it makes you feel better.

The benefit of having standards is that you don’t have to think about them. That’s why I’m saying… don’t have them.

Here’s what I really mean.

Again I’m going to play the “I’ve worked in sixty development shops” card. I’ve seen a lot of single developers, startups, growing concerns, flailing concerns, and mega-corporations do software development to a WIDE range of success. And pretty much always, someone senior at some point calls a meeting and says…

…Let’s Have Standards.

In practice, that means you spend a few hours in more meetings going over the oh-so-important issue of whether to name your classes in camelCase or PascalCase. Where the curly brackets go. You know, all that stuff that ReSharper already does for you.

I’m saying those meetings are not a productive use of time. Your deliverable becomes a set of rules that everyone either has to try hard to remember, or rules that nobody bothers to follow at all. And I keep asking, what is the problem you are trying to solve here? Nobody’s totally clear on that.

  • If your architecture is too complicated, reduce the architecture.
  • If you lack unit tests, build code with unit tests.
  • If your code is too tightly coupled, think about where the seams should go.
  • If it’s hard to find the class you want, pick better class names.
  • If you have a lot of duplicated code, refactor it to remove the duplication.
  • If your problem is excessive defects, then “standards” aren’t going to help at all.

So either you think about these rules and they get in your way, or you don’t follow them and they don’t help you. In any event, they don’t solve any actual known problem. Come on, when was the last time you honestly couldn’t get something to work because the curly braces were in the wrong place? Ever?

Here. Let’s make it easy.

Why not save everyone some time and annoyance and just use ReSharper? You can leave the default ruleset, which is a pretty reasonable one, or customize it if you really really want to, but the important thing is to set it up and not worry about ever again.

The main thing is to know what the problem is that you are trying to solve instead of getting excited about a solution that may not help you at all.

I’ve found that the shops that take more than about fifteen minutes, ever, to discuss “coding standards” are the ones with pretty severe process issues that “standards” won’t at all fix. The right path is directly to the source of those problems, not one of avoidance.

 

It's a buzzword if you make it one

I saw this on LinkedIn a few years ago:

The bulk of my professional career has been spent working on software solutions for start-up companies. These projects typically (1) do not have established coding practices, (2) have tight timelines, and (3) have requirements that can change on a day-to-day basis.

With this in mind, I am always interested in learning about more effective approaches to software development. So my question is: “Is agile development yet another buzzword, or is there substance to this approach?”

Here’s how I responded:

Think about Agile as a means to get solid, well-tested software that is designed well, solves problems, and is amenable to change. You don’t need to have every coding standard determined up front–perhaps you’ll want to use an Agile process and mindset just to develop those standards–but your efforts will definitely fail if you think of Agile as a mess of shortcuts.

If it’s slapdash, it ain’t Agile. If it’s a shortcut, it ain’t Agile. Agile probably feels like the long way, actually, because you have to pay more attention as you go along.

Agile usually means less design up front in exchange for continuous design as the project evolves. The exchange part is important: there’s still no free lunch. But it’s not design-design-design-code-code-code. It’s design, code, design, code, design, code. (Or better still, it’s design, test, code, design, test, code…)

Your item #3 in particular (daily requirements changes) could point to managerial dysfunction, which makes Agile really hard; or it could point to a dynamic business model, which makes Agile incredibly useful. Or both. You may well find that a well-executed Agile development process draws attention to poor executive management. (Whoops.)

In answer to your question, though, Agility is definitely real. What’s not real is the idea that you can sprinkle Agile fairy dust on a hierarchical mess and everything is all better.

In fact, about the worst thing you can do is to impose Agile practices (such as daily standups, user stories, and sprints) without working the cultural changes that motivate them. For example, I’ve seen the daily standup used as a manager’s checkin and problem-solving session. That’s not a bad thing to do, but it’s not Agile because it makes one person the bottleneck, and it almost always becomes a scorecard situation rather a collaboration.

Likewise, the essence of the sprint (in Scrum) is that you use each one’s retrospective to inform the plans for the next one. The idea is to get rapid feedback from everyone and actually adjust to it. Which explained why I laffed out loud when overhearing a neighboring team’s project manager crow that “We’re really Agile! We have all our sprints planned for the next two years!” Sure, she got her Gantt chart filled out, but she precluded all meaningful input from the team.

Long story short: it’s real. But the key is to forget about the Agile practices and “tricks” you want to learn. Stop, pay attention to what your team is (overtly or covertly) asking for, and go about changing things in response to how your team really works. There are no buzzwords or shortcuts to it. You have to be willing to listen, to give up power, and in many cases to find out you are totally wrong.

If you’re up to that? Then it’s not a buzzword. But that’s up to you.

Adventures in version control

Branching in source control isn’t just for big shops. It also allows small shops to do big things without holding up the small things.

So I spent a lot of the weekend refactoring my Healthy Homes database system. (I know, what a party animal.) And after getting some solid work checked in, I realized it was definitely time to do a major refactoring of the Data Access Layer (DAL) code.

Continue reading “Adventures in version control”

Is it worth it?

It’s rarely a good deal to invest much cash into technology when you can easily hire more actual people to do the job in a cost-effective way. Sometimes the low-tech solution is the easiest and best solution.

I got a kick out of today’s XKCD comic strip. (Chart: “How long can you work on making a routine task more efficient before you’re spending more time than you save?”) It reminds me a lot of a conversation I had last Friday with an entrepreneur who’s trying to automate some, but not all! of his information business.

See, “Allan” gets a lot of documents that are not so well standardized, puts their contents into a database, and essentially gets paid by his client companies to let them know when and where they–or their subsidiaries–are mentioned. (There’s more to it than that, but this is the relevant part right now.)

Continue reading “Is it worth it?”

"Minimum Viable Product" jive

Marketing is part of the actual product. The actual product is part of the marketing. You can’t separate them!

My college homie Dave is working on the “Minimum Viable Product” (MVP) version of his Baqbeat product. I’m always interested in what old friends are doing, so I asked him about it.

Baqbeat is a little hard to describe. Dave filled me in:

Baqbeat generates timelines of configuration changes to all the servers in
your development and operations environments – version control, build
servers, app servers, databases, and others. It automatically infers
related events on different timelines. So for example, you can see problems
in your production environment and immediately trace it to the code change
that broke it.

Continue reading “"Minimum Viable Product" jive”

Help right now for tech-dependent startups!

Your startup depends on a web project or custom software application. Doing it alone isn’t working out. I can help.

(tl;dr: Answer a few easy questions to see if I can help your startup!)

Do you have a startup company that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Are you still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?

I’m hearing you.

So you have this small business. You probably just started it. You’ve got a pretty good business plan, you’ve stashed some money to keep it going until it breaks even and can pay you, you’ve worked out health insurance and stuff… or maybe you’re keeping your day job and working a lot of nights and weekends to get it together. And it’s a cool idea: some product or service that people are definitely going to want to pay money for. It’s exciting and terrifying, because you don’t know what could go wrong, but you’re also a little apprehensive about how it will go right in the end.

Continue reading “Help right now for tech-dependent startups!”

Pre-Announcement: Help for your tech startup!

Well! I just spent a lot of time with various tech-related startup companies. Some of them have Projects That Suck; others are simply getting started with new things. I’ve learned a lot more about what does and doesn’t work, and I’m ready to share the results with you.

Do you have a startup that’s not yet all the way started up? Not quite done with the software tech product that defines you? Not sure how to finish it, or where to go next? Still stuck for a platform? Worried about funding? Afraid of making expensive mistakes?

If this sounds like you, watch here next Wednesday for the plan and the details. We can work together to get your startup project on track, within budget, and under control. I’m really excited about this. I think you will be too.