Write Legacy Code and Secure Your Job

If you happen to be in the unfriendly situation of not getting a chance to mess up any real product development, you may at least follow Per Lundholm’s advice to Write Legacy Code and Secure Your Job. Per provides some excellent tips on how to approach a legacy system. Like by documenting the architecture in just The Right Way:

Use a tool like Word and document the architecture. Yeah, really, just be sure to write at least 100 pages. Perhaps you can find some examples on the internet.

So, it’s hard work. But it pays off. Writing legacy code will not just secure your job, but also make you look better. And it surely helps to make the world more fragile. One line of code at a time.

/via Antonio Lucca (@tonyxzt)

Super Fragile Storage Service

Truly fragile development frameworks are not set in stone. They evolve over time to make sure that their agility is reaching a new level of perfection sooner than anyone of us can get something useful done.

The same holds for any fragile set of tools. While there is some value in picking one’s toys once and using them until they fade away, there are clear upsides for constantly keeping an eye open for great new tools that help to kill any constructive productivity that may be showing up.

And this Super Simple Storage Service is definitely an excellent piece of useless project show stopper:

It’s a write-only, non-cloudy, and bleedingly fast piece of storage service. And it’s even more competitively priced than 3.5″ Floppies.

10 Ways To Lose Your Team

Pawel Brodzinski had a creative break and came up with a list of 10 Ways To Lose Team. Here is the essence:

1. Forbid one-on-ones.
2. Don’t share information.
3. Cut discussions.
4. Blame others.
5. Usurp success ownership.
6. Micromanage.
7. Don’t praise, criticize instead.
8. Squeeze.
9. Everyone can be replaced.
10. Be an asshole.

It is all just so true and doesn’t get much simpler than that. Go and check the original for some details on each of the points.

The only fragile business book you ever need to have heard of

A truly fragile project needs a truly fragile business to be based upon.

And thanks to Kenny Meyers we now have a business book that tells us how to get up and busy via businessing:

No more excuses! Get up. Grab a copy. Dive through. And start businessing. As fragile as you can.

The New Fragile Manifesto

What can I say? Kent Beck is right. In principle at least. Like when he says that a manifesto is there to be revised from time to time. Which is what he just did at the Startup Lessons Learned conference by coming up with a new Agile Manifesto.

He errs content-wise, of course. So, here we are – revising the Fragile Manifesto and creating The New Fragile Manifesto:

A hidden agenda and chaos over jail-like isolation (or individuals and interactions)
Constant ignorance over strict rules (or working software)
Namby-pamby confrontation over healthy ignorance (or customer collaboration)
Screaming out loud over simply telling others to Shut Up (or responding to change)

No big deal? Very true. Time to live up to it.

19 Keys to Successful Fragile Projects

Some people not only seem to be locked in to the believe that the agile world is still alive. No, they also keep running around sharing their error with everybody who isn’t up on the tree by three.

Like Señor Pete Deemer did. And someone even listened. Like Jesse Fewell who wrote about some 19 keys to successful agile projects.

Well, we are here to help. So, this is our corrected list of 19 keys to successful fragile projects:

1. Do it for the right reason: You are the hero. You are strong. You know what to do. You do it. No questions asked. Just make sure to ban those Harry Potter books from the office. They spread some bad karma.
2. Start with teams that want to try it: If your team screams for agile, just smile and teach them a lesson. Open the door to your truly dark basement and simply nod your head. If they know you they know what to do. And shut up.
3. Set realistic expectations: You are the hero. Never forget that. And make sure that nobody around you does. Which guarantees: everybody is expecting your projects to fail. With pride and honor.
4. Call it final from day one: Grace periods and pilot programs are for wimps. You know what you want, so do it. Now.
5. Change is scary to many people: We completely agree with Señor Pete here. So use their fears and scare them by changing the ground rules just about as often as you can.
6. Go for all or nothing: Patience is for wimps, again. The right path is the right path. So you might just as well go and get all teams on board right off the start. They are desparately seeking out your help, anyway. Even if they don’t even know so, yet.
7. Keep Scream as pure as it gets: Some may argue that half a scream is better than no scream at all. But it’s all wrong. You want to make them scream, so make them scream! This is fear-driven development, after all.
8. Scream is hard: Very true! And we couldn’t put it much better than Darwin did: Only the fittest survive!
9. Get experienced help: Ideally, this is you. You are the hero. You know it best.
10. Get high quality trainging: This is what we developed the DisasterMaster certification for.
11. Your enemy is your enemy: That’s where he got his name from. So fight him as hard as you can. If there is someone who wants to prevent your ship from sinking, throw him overboard.
12. Be prepared to use Guerilla tactics: Very true! We are at war, afer all. And we make sure to keep it unfair. As we are fragile and plan to fail, our mission is doomed to win!
    
13. Find your guardian angels: Can’t agree more. Go out and find some manager who is eager to try something new. And fail her great.
14. Make bad information more accessible than good information: That’s just the way it is. Señor Pete just erroneously turned it upside down. Reality is fragile and good news is a synonym for day-dreaming.
15. Ignore results early and often: Keep results to yourself. Resist the urge to publish every number you happen to stumble across. Metrics are for losers who just try to distract from the fact that they are not doing the work they got assigned from you.
16. There is no room for tinkering: To tailor means not to do what The Genius came up with. And The Genius is you, of course.
17. Change your tools as often as you can: A tool is a tool is a tool, after all. And, honestly, all a tool is there for is to play with it until it bores the hell out of you. Change them early, change them often, have your fun. Just make sure that your team stays in constant fear of what you may be coming up with next.
18. Don’t stop with just the members of the Scream team: Scream is for everyone. Make your team scream first. Then aim for the next. And the next. And the next. The sky is the limit. True fear is a civil right.
19. Scream will always be messy: A healthy level of chaos is essential to keep all your team members in fear. Some in big fear, some in small fear, and some in fear without even knowing where it came from.

Stick to these 19 keys to successful fragile projects and you’ll eventually mess up every single project that will ever cross your way.

Go Fragile!

(image by prward at sxc)

Only a fragile fan is a true fan

Some really smart bloke just came up with a very smart notice on Identi.ca, or Twitter if that’s what you prefer:

And just because Señor Mark is so absolutely and truly right, we all need to join the Facebook fan page for Scream! Fear-driven Development.

Now!

Advance without becoming successful

Your project is in danger of  meeting with success?

Simply turn you next Sprint into a mess. Don’t know how?

Become a DisasterMaster

Your Fragile Friend: Procrastination

Sometimes, you really are in trouble. Like when you have an excellent team that flawlessly produces outstanding results, you have an overly proactive environment that simply puts the resources where they fit the best, every impediment that jumps your way gets removed faster than you can blink your eye or open your mouth to scream out loud, and every demanding idea you have gets responded to by an immediate implementation thereof, that is working flawlessly, comes without any bugs, is accepted by users who never knew that this is precisely what they’ve all been waiting for so long.

Sometimes, you are in big trouble.

The only chance to escape is to mess it all up yourself. You are in charge! If you mess around, nobody will really be able to make up for it.

One fine way of doing so is procrastination. And just in case you don’t know what it is all about or how best to achieve it, click the image below for a video that clears is all up:

Never forget: today is the day to mess something up. If you want to get something done, tomorrow is your time. Always.

The hidden Fragility

Sometimes, you need to play a little to win the game in the end.

A good chance that his may happen is when everybody in your organisation has been mind-washed and suddenly wants to go agile. Silly, of course. But they may still be asking you to do the same.

So, what do you do?

You take your team and comply, of course. At least officially. And in order to hide your true intentions you do it as perfectly as it gets. Which means: deliver the maximum business value at the end of the sprint. This is where your focus is: the next sprint. And this is precisely where you put your focus. The next sprint. And only the next sprint. Naturally, you control your team. Thus, they all do the very same: concentrate on the next sprint. That’s what they want you to go for, that’s what you do. The next sprint. The very next sprint. All for the next sprint. Who cares about anything with a more broad horizon than your one-sprint-timeframe? Nobody, right. Just build what you have been asked for over the next few weeks. But build it as fragile as it gets.

Eventually, your hidden beast comes out. Suddenly, the whole building magically implodes. Everybody realises that the time you need for implementing any new feature will exceed the whole sprint’s length. By magnitudes. Even adding a second button to your login screen doesn’t fit into a single sprint any more. That’s how fragile you got your whole system over time by following the mantra of a one-sprint-only focus for so long. If you now start to talk about refactorings, the whole team will just stare at you blatantly for hours and then suddenly cry out loud and scream and run away like mad.

As soon as your upper management does the same, you’ve succeeded at full length.

You know how it is: those who make everybody scream the last, makes them scream the loudest. And wins the game.