Getting “on board” with Agile

Someone asked this recently on LinkedIn:

What are some good ways in which to most quickly transition from a waterfall environment to an agile environment in such a way that (most) everyone gets on board with the transition?

My response went something like this.

By far the most common reason why development teams don’t get “on board” with Agile, in my experience, is that management isn’t on board either.

Continue reading Getting “on board” with Agile

How To Make The Whole Organization Agile – Forbes

Source: How To Make The Whole Organization Agile – Forbes

This thing here, from veteran management guy Steve Denning–it’s Forbes, so of course there has to be an infographic that makes less sense than just explaining things.

All mockery aside, I’m seeing an important point here. The lowest-functioning corporations depend on coercion, threats, and “fiat” to get stuff done. If you’re a little more sophisticated and higher functioning, you evolve into “management tools” that aren’t so dependent on brute force to work: measurement systems, strategic planning, that sort of thing. That’s a lot better in many ways, because people respond better and feel better when they’re not being ordered around.

If you’re in that upper realm of “leadership tools,” using persuasion and role modeling to show your people the corporate goals and how to achieve them… that’s a fantastic step forward. But it only works if you discard those lower-level techniques that rely on intimidation.

Inspire all you want! But if the person at the bottom of the stack, doing the real work on the assembly line, at the customer service desk, or in a programming cubicle, is routinely coerced or punished–you have a bigger problem than can be solved with one or two workshops or planning meetings at management level.

I like this chart and plan to use it!

Read the full article though. Denning has some great insights on why Agile software development fails in organizations that don’t adapt on a larger scale. You have to cut out hierarchy and privilege, and if you’re not emotionally ready to let go of those things you are better off not pretending your development shop is “Agile.”

The daily standup is for the team.

“Sucks” rules

Something I like to do regularly to keep my brain “agile” is to take something I like, add the word “sucks” to it, and Google the result. I found this on a search for “Agile development sucks”: Your Daily Scrum Is Killing Your Team, by J.B. Rainsberger. I didn’t know about J.B.’s work until now, but I’ll try to catch up.

Continue reading The daily standup is for the team.

Why I don’t trust development managers

I’ve been doing software development professionally for the last 25 years, almost exclusively in the Cleveland-Akron area, mostly with medium-size to large companies, and over the past ten years mostly with .NET Microsoft shops. About two thirds of them are proud to proclaim they’re “Agile.”

All told, I’ve seen how about eighty different organizations approach development. Narrowing down a bit, I’d say I’ve done relatively long-term projects with about a dozen reasonably large companies with “Agile” shops (generally all Scrum-based) in the past ten years.

And you know what?

I don’t trust any of them. Neither should you.

At one recent gig, I was a bit confused as to why the team manager kept imposing a list of tasks—excuse me, stories—for every sprint. I said, “We’re supposed to meet with the customer, share story sizes, listen to their priorities, and then see what will fit into the sprint, right?” The manager said no, his manager already told him what the “phase one” features and stories were… and furthermore, that we had to finish them all in the next three sprints.

Sprint planning meetings became a formality, because the results were dictated by a person who wasn’t even there to argue with. Sprint demos didn’t even have a customer. And worst of all–here’s where the mistrust comes in–all the individual team members were evaluated based on whether they hit deadlines, er, I mean, on how well their story completion matched those (coerced) predictions.

The key here is accountability. When the team doesn’t own the scope of work, then they can’t own the result. Further, we can’t possibly fulfill customer requirements when we’re not anywhere near the customer.

This is an incredibly common scenario.

Each of those dozen shops has been organized in a similar way. The details are different:

  • In one place, the manager simply insisted on adding work during the sprint by creating “bucket” tasks in advance. You can’t own the result of a “to be determined” work item. But it did help the customer fit things in when there was time.
  • Another manager required everyone to “burn down” exactly eight hours per day, even if that meant distorting the burn chart by burning on tasks that we hadn’t touched to leave times for the ones we hadn’t finished yet. If we can’t give real feedback during the sprint, we can’t adjust expectations. But it did reassure upper management that we weren’t slacking.
  • And in one organization, aborting a failed sprint wasn’t even possible because all the teams shared a Jira site on which sprint durations were set throughout the enterprise. It literally wasn’t possible not to be in lock step, even if (for example) an unexpected production disaster pulled us all off sprint tasks and forced us to start over. If declaring “failure” isn’t an option, we don’t have a way to recover from it. But it does avoid the stigma of reporting that we missed a target.

I think I’ve seen one time a development team that was allowed to self-organize within a sprint. Once since about 2006. It’s not terribly common.

So why don’t I trust development managers?

Because their sense of responsibility is one way. They’re still committed (upward) to hitting imposed deadlines, and that’s what they get evaluated on. So they evaluate us in turn in the same fashion.

Agile isn’t about hitting deadlines. It’s about early and continuous delivery of valuable software! If your shop is deadline driven, and if you’re evaluating developers based on making those deadlines, then Agile artifacts (such as burn charts) and methodologies (such as Scrum) are illusory… and we don’t trust you with them.

Do you want trust and commitment from your team? Then understand that accountability has to work both upward and downward. Most of all, and first, stop evaluating team members by external deadlines and start evaluating based on contributions to the team.

 

How to Mess Up Scrum, Part 5

This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…

Overcomplicating the Objective

Let me give you an example. A few years ago, I was on a Scrum team that was assigned to develop a “retail portal” for the services this company already sold at old-fashioned store locations. In “phase one” the goal was to put up half a dozen or so static pages, plus one “contact” page to capture basic information so our sales rep can call you soon. That’s all.

It took three developers six months.

How the hell does that happen?

Continue reading How to Mess Up Scrum, Part 5

Agile Excellence, Part 1

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!

 

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.

Rules for nothing

One blog entry from last year, “Look. This SOPA/PIPA Thing,” started out as an offhand blurb on my Facebook status. I think I spent two whole minutes writing it, which can be pretty effective when you know exactly what you want to say:

Rather than doing their own damn work chasing down copyright violators, they want to keep everyone off sites that *might* be used for unauthorized copying.

My favorite comment came from my old Grinnell College homie, Laura Allender Ferguson, who said simply: “Go Agile.” She was responding to my side-whine about the ever-changing requirements that we always get from software development clients.

Continue reading Rules for nothing

Solving the right problem

For several years now, I’ve been describing my business as “Making Your Software Project Not Suck.” Here’s where that catchphrase came from, and how I actually go about doing that.

Where it came from

Maybe twelve years ago… yeah, okay, that would have been in the lull after the post-Y2K slowdown and just before 9/11… I was pretty much in between major projects. As was almost everyone else.

It was time to Work on Marketing! Which if you’re smart, is something you do all the time, but in some ways I’m just not that smart. Or more to the point, I do know what I have to do but there are always competing priorities that appear to be more urgent. You know how it goes. Fire-fighting often trumps planning.

Continue reading Solving the right problem