We were stuck.
There we were, a few iterations into new product development, and there was still no deliverable.
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?
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.
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.”
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.
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.
I don’t trust any of them. Neither should you.
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.
This is another item in my ongoing series of “How to Mess Up Scrum.” This time, I turn your attention to…
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.
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.
Fake reporting is endemic in dysfunctional Scrum shops. Here are some examples:
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.