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.


iTextSharp frustrations

I’ve been working a lot with iTextSharp lately. It’s incredibly useful but also sparsely documented, and the design concept is far from obvious. Here’s what I mean.

You don’t instantiate a PdfDocument. even though its constructor is public. You instantiate a Document. It creates a PdfDocument behind your back.

“New Page” behavior is extra bewildering!

If you haven’t put anything onto a page, but call PdfWriter.NewPage(), you will not get a new page.

You can override this behavior by setting PdfWriter.PageEmpty to false. (You can’t set it to true!)

Guess what? Pulling the drawing context so you can position text by the pixel, and then doing so, doesn’t count as putting anything on the page.


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

“Hardening” sprints considered harmful

Some Scrum teams–whether formally or informally–have a recurring “hardening” sprint after every few regular sprints, in which they fix outstanding defects and make the system actually ready for delivery. This is a bad idea. Here’s why.

If you care about why you are “doing Agile,” you should care about the principles of Agile development, which include “early and continuous delivery
of valuable software.” Delivery. If you’re not continuously delivering software, you’re not Agile.

If you have legacy defects, which are any defects not tied to a current story, then those defects need to be made stories in their own right. If your current stories are implemented with defects, they are not done and you have no business considering them completed. If you haven’t integrated a pipeline from development to deployment, that is infrastructure! It’s not part of a sprint!

Make every sprint a “hardening sprint.” That way you always have a product to deliver. That way you are never wrong.

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

.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

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