Tag Archives: agile adoption

Whatever Happened To Software Engineering?

map-clip-artI’ve been working some on my mailing list to help Agile teams do better and one of the recurring topics from readers has been how to fit “normal” software engineering principles into an Agile framework. How can you do database design, for instance, if every 2 weeks the database is actually being used?

Of course there’s an easy answer: we incrementally do things in Agile. So, for instance, you might use all those database design skills, but a little at a time, instead of all at once. The first sprint you sketch out the tables, maybe add a few fields. Second sprint you change up the tables some, add some more fields. Third sprint you’re working a bit with cardinality. And so on. The concept is that we do the same stuff, only a bit at a time instead of becoming a bottleneck.

This is a good enough answer, and it works for most stuff. But I think it’s also masking a conflict that many people have: software is supposed to be engineering, not just little dips and drabs of stuff added in here or there. To hear many YAGNI pundits and others, you don’t actually do anything until the last minute, and then only in support of the exact thing you’re working on. Most engineering disciplines, however, encourage you to solve the entire problem. If you’re building a bridge, architect the bridge first, dang it. If you’re going to the moon, you’d better have some technical work around the entire trip. You don’t just launch into orbit and figure it out from there. Building incrementally is fine. But there exists fields of inquiry where there’s a long sequential process of refinement over the entire problem domain — one in which you gain execution advantages by working the entire problem at once. We seem to either have tossed this fact away or are purposefully ignoring it.

I began noticing a problem. When we talk about these things, people shut down. I suspect many folks in software engineering, especially Agile coaching, don’t have an engineering background! This can lead to a severe disadvantage when dealing with certain areas:

  • Modeling I don’t see many teams sketch, much less model. That’s a shame, because visual information is a much more effective way to discuss technical matters. Add in a bit of formal training, say 30 minutes, and teams can sketch in UML. Then you can link diagrams. There’s something to be said for lightly sketching problems on the whiteboard. Take a picture if you want to keep it. Start using a modeling tool if you realize that you’re having a group discussion around highly technical stuff. You can sketch, you can use UML, you can use a modeling tool, all without having to become a waterfall BDUF project. Really, you can. It’s the only way to go for complex projects.

  • Process Analysis Does anybody remember structured process analysis? Not to see most teams. The way most people teach Scrum and Agile is that a list of stuff appears — I guess from the sky, brought down by a dove to the Product Owner. The team only works on the stuff in front of it. Don’t spend a minute thinking about the big picture! After all, your project could end at any point in time, and you don’t want to spend one minute on things that you’ll never need.

    Of course, there ARE projects that could end at any moment, but for most of us, we’re brought on to address some kind of system: a website, a business problem, an internal need, and so on. The team, and project, has some cohesion. You’re going to be here in six months, and you’re going to be working on the same thing. For those kinds of projects, spending some time doing process analysis is a no-brainer. You get back much more than you put in. I’m not talking about anything waterfall-like. I’m simply talking about building a process model, over time, of who does what with the system and why. This can help you cut to the chase and decide which stories should be prioritized first. It can help you define and have a common understanding of your stories. It can help the Product Owner make economic decisions about the backlog, and it can help the team interject creativity into the solution, instead of just being a bunch of order-takers. Great stuff for couple hours or so each sprint.

  • Lean Startup Another one of those end-to-end, outside-the-team areas where the team and the Product Owner need to work. What hypotheses is this work supposed to be testing? What are the revenue streams? How are we addressing the gap between market and PO? In a startup world, all these things are critical — and there’s a sequential engineering-type endeavor that can take you from point A to point B. It’s a mistake not to do it.

When we teach things like good architecture or proper database design, many times we view the developer as the center of the universe and the engineering practice as something that’s completed in toto before any other work can occur. This has caused tremendous pushback from Agile teams, rightly so, because it creates handoffs, bottnecks, and unecessary documentation. But are we overreacting the other way? Isn’t there a place for long-format, sequential, detail-oriented work, even in Agile teams in complex domains? Especially in Agile teams dealing in complex domains?

Each of these has a few areas in common: 1) they’re about more than the work directly in font of the team, 2) they’re about having the experts, the team, assist the organization in its work, 3) they’re sequential, 4) they build on themselves as work gets done, 5) they’re not the work itself, and 6) they end up discovering things for the PO and the organization that wouldn’t be discovered otherwise. Because of these attributes, they tend to “fall between the cracks” when teams adopt Agile practices. They are traditionally part of what people employ engineers to do.

How about you? Are there engineering processes you miss seeing in your Agile teams? What are you doing to make up for it?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Edge Cases are Where you Really Learn

I was thinking last night that Agile Edge Cases — the situations where multiple principles collide and it’s difficult to choose one over the other — make the best learning experiences for people.

So I decided that they would make a good topic for this week’s Tiny Giant blog series on Agile principles. Once again this time, I came in at over 1500 words. I was shooting for half that. I think I either I desperately need an editor, or I just have a lot to say about Agile. Probably both!

Hope you like it.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Four Steps from Perdition

There are four steps in making big changes in a group or organization.

Descriptive/Sales. This is the first step. You buy the book, or attend the seminar. It looks hot, it looks like something that could make a big difference. So you make everybody read the book, or attend the seminar.

Instructive/Certification.That works for a while — it might even get a lot of folks excited, but soon enough you realize that the book or seminar always describes things in terms of a desired goal, not in terms of actually how to do your work. So you switch tracks, moving to instructing people and/or certifying them. Trainers come in, you set up systems of training and tracking people.

Coached/Mentored.The next step in your journey is to realize that even once you understand the goal, and understand the skills needed to get there, you don’t have any idea of how all the skills come together. It’s different for every group. This is a critical step: it’s the first step where you realize that applied knowledge and book knowledge are two different things. You don’t learn to play jazz piano by watching a movie about a great piano player, or by taking a test in music theory. You learn by trial and error, having somebody watch and provide feedback.

Pull-based problem lists.The final step is when you can provide your own feedback — you have become your own coach. You find this level of expertise among professional musicians. I’ve always known that no matter how good a musician is, he leaves the stage wishing he could have done a little better. He’s always got a running list of problems, and he’s always working on them. He doesn’t reach a place where everything is perfect — there is no such place in the real world. Rather he reaches a place where he is able to give himself an honest look over and decide what he needs to work on the most. Good teams aren’t good because they’ve mastered technology development: they’re good because they’ve mastered the art of critiquing themselves and working on the most important problems first. When you reach this step, not only are you able to perform, but you also find it a little funny how naive you were in step 1.

This seems like such a simple list, but over and over again I see folks hung up on one of the first three steps, never realizing that the last step is key. Sometimes never even realizing that there is a next step.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

E-Books and Pricing — is $99.99 Okay?

After writing up a small e-book for my wife (shameless plug: Best Hamburger Casserole Recipes rocks!) I decided this past week that I think I’m ready to actually become an e-book author.

Getting started, I found some things were easy to figure out and some things I don’t have a clue about. I’ll share them with you in case you decide to go down this road too. When I got to pricing, I was really surprised at my conclusion.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agilholics Anonymous

I’m a mean-spirited, incompetent, untrained, bad-example-of-a-parent who’s only bigoted goal is to make a buck at the expense of hard-working experts by unfairly trashing their work. I’m the “Rush Lumbaugh” of the Agile movement.

If you listen to some of the comments I’ve gotten after running “Agile Ruined My Life“, that’s probably what you’d think. I deleted the worst and had to ban a couple of folks.

Gee, and the evening is still young!

Oh, I almost forgot the best one: I’m also a liar that made up all the negative feedback I get from folks trying to adopt agile, which was the reason for writing the article in the first place.

So let’s play a little Google game: What was the positive reactions from the developer community? What kinds of sympathy did I get from around the web? Were the reactions mostly positive or negative? For those skimming, I’ve added bold formatting to phrases with the most punch.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Ruined My Life

I read the reply to my comment on a popular hacker board with sadness:

(disclaimer: Agile consultants ruined the software group I work in.)

Making good software is hard, and anyone claiming to have a magical process that guarantees good software is selling snake oil. I can appreciate your wanting to make a buck, but would also seriously appreciate it if you could find some other industry besides software development to go screw up

Reminded me of an email I received back in May:

[We] started working on [agile technique X] when [author]‘s [famous book] was just a draft. I was on that project and worked on Agile Projects for a decade. (Next time you meet [famous guy], ask about me, I just finished reviewing his forthcoming [another famous book]). I am a founding member of the Agile Society of [place] and have organized conferences on Agile. I’ve attended XP Conf as well. I’ve probably worked in more agile projects than you ever have (not that it particularly matters). So let us first dispense with the notion that your notion of what constitutes “true” agile and its scamsters is somehow the only standard….

Do you deny that the whole Scrum Master idea is a scam within the Agile Camp?

Scamster? Ron Jeffries the guru/founder of Agile couldn’t write a Sudoku implementation with his favorite technique “TDD” and refactoring over five weeks. Fraud.

Robert Martin (another “guru” and agile consultant) claims that any code not written with TDD is “stone age ” code including such things as Unix and such people as Norvig and Linus and Zawinski who’ve built more code than he can dream of. Dalke poked holes in his TDD “kata” which never got answered Fraud.

I could go on and on. And these are the gurus. But that isn’t the point. i *saw* “agile consultants” evolve from some naive but well meaning people (like Kent) to scamsters like X and co and tose are just at the top. Practically every single “Scrum MAster” is a fraud. The more intelligent among them admit that two days of listening to a higher level shyster teach nothing and it is just a signal to dumb managers to improve their chances of getting a project. Yet they go along. That in my eyes is a scam like chiroproctors or reiki people claiming to be doctors. Agile was amovement founded by scamsters and propagated mostly by scamsters.

I’ve had many such conversations over the years.There are some seriously pissed off people about Agile out there. Why? Isn’t agile supposed to be warmth, apple pie, motherhood, goodness and all of that? Why so much anger?

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.