Simplify Your Thoughts For Uninterrupted Flow April 24, 2013Posted by ActiveEngine Sensei in ActiveEngine, Agile, Coaching, New Techniques, Open Source, Personal Development, Problem Solving.
Tags: fluency, new thinking, Philosophy, productivity, software development
add a comment
Sensei recently gave up FogBugz. This was not because of FogBuz, as it is a great product. But Sensei realized that it was not meeting his needs. It was too much. When on the hunt, you can’t be slowed down, and sometimes you have to jettison the extra weight. To be fair, the context here is a prototyping project, where errors / foibles / new features need to be captured. FogBugz is great a teams, but it does require, well, too many clicks. You should always ask yourself this question: which James Bond do I want to be?
Which Bond gets the babe? Pretty easy choice. The unfettered thinker makes them swoon. The guy with the helmet …not so much.
Keeping It Real By Keeping It Simple
Yep – Sensei sounds like a whiny Apple-simplify-your-life-and-wear-a-black-turtle-neck Zen iPad fan boy. Well, that’s not right either. There’s just the right tools for the the right job. So when in the fight with the development environment, brain firing on all cylinders, Seseni uses Workflowy. You can quickly categorize your lists / sentences / thoughts as you go. Just typing, no modal dialog boxes, no creating an item, waiting for it to save, clicking, scrolling, more dialog boxes.
Before you attack, Sensei is not saying this will work for teams, for bug resolution, and other endeavors that FogBugz does very well. But it’s all about eliminating the tactics that get in the way of you achieving your goals. This is critical. And when prototyping you need as much room in your head as possible so you solve the bugs, but not spend more time tracking the bugs. Below is a sample. Issues and features, pretty easy. Click it to see the details.
So What? Well, How About Taking It a Step Further
Sensei hopes that the enterprising readers out there can take this idea and run with it: Why not create system that parses the format shown above? When you edit, each line gets a Guid. Then, start at the top level. Each item at that level is story or a deliverable, maybe broken down by screen or function. A child of each story will have an Issues or Features item, and the child items of Issues naturally belongs to Issues. All else would be ignored when converting to a database record, yet retained in your notes.
This would be your starting pointing. Because each of these items has an identifier, later you could parse them into a database format, assign people, etc. The point is that the starting point is easier, is more productive because you just type. That way your work gets done, and you feel more like him.
Fail Often, Fail Fluently March 27, 2010Posted by ActiveEngine Sensei in ActiveEngine, Agile, Fluent, Mythology, Problem Solving, software economics.
add a comment
What do you when your Scenario or User story just sucks? You’ve haggled with your peers over how to implement, the user has changed tunes and come over to your side of things by realizing that they want two things at the same time, but now that you’ve listened to everybody and re-worked your logic, you’ve just spend 6 or 7 extra hours testing. Now, you doubt that anybody really knows what the original intent of your use case was because there are so many different variants and vagaries from all the meetings, emails, hallway tests.
Now succumb to the brain death of Sarbanes-Oxley. Where is the traceability in all the discussion threads? How do you prove that you have what you want and that transactions are preserved and yada-yada-yada it just works? Before the project you thought that your team was like these guys:
Sensei won’t pretend that there is a cool Zen technique to avoid hard work or failure. Maybe this type of failure of communication is a test of your core skills and your “fluency”. Look at the Elvis’ team. They’re practicing. They’ve been over the material again and again and again. That’s three again’s for each of the yada’s. To get to that point where they can adjust to his direction they’ve done much on their own time acquiring skills. Years of practice and adjustment.
Your project is like that path to acquiring a skill set, gaining mastery, being fluent. You have to build for flexibility, for
change. You CAN NOT give in to YAGNI just because this week you think you know all the answers. You won’t create a fan base that way. And just because something is written down does not mean that it’s set in stone. Remember Moses and the stone tablets? Even though he could part the waters he still had to go up the hill twice. Things will go wrong, but if you put in the time your adjustments, while painful after a long haul, won’t be that bad. 6 hours could have been 6 days. Be thankful you have good partners.
Revenge of the Fallen July 21, 2009Posted by ActiveEngine Sensei in ActiveEngine, Agile, Agile vs Waterfall, Business Processes, Problem Solving.
Tags: ActiveEngine, bad software, communication, focus, Problem Solving
add a comment
Did you think you were constructing this: but you were actually delivering this instead: (more…)