Friday, March 31, 2006



And then it hits you. All the stories are important! The customer says I want everything done yesterday! Then you start thinking that writing the stories down are a waste of time, and consider solving the problems on your own. Then you start thinking that you shouldn't do Agile anymore because you can't do it right the first try.

Hold your horses there... Giving in to all your customers whims all the time is not really good business. But the customer is always right! Right? Technically, yes... But nothing is stopping you from telling your customer: "Look... We can do this given enough time. Now yesterday's gone, and we only have today. And tomorrow will be gone, because it will become today tomorrow. Now what do you want done first?"

Being firm is not bad business -- but being inconsistent and unreliable is. When your customers know that you're working on it and that they see constant and verifiable progress then you now have chips that you can play with. If you've given your word before and you pushed through, then you have a reputation of delivering -- and that's what you want. The problem is when you have given your word before, and failed to deliver: then that's another point of discussion.

Allowing your customer to evaluate what is of most value to him alleviates the risk from the technical team of telling the customer what is important (and being wrong). The User Stories that have already been written should have the priority as an attribute -- meaning, the most important things are done in the beginning of the project. However, the priority doesn't have to be written down on the index cards -- though it would be nice to put them down somewhere else.

This post is about prioritizing stories which is not the job of the technical team. The customer should tell the technical people what they need, when they need it, and which needs should be addressed first. When the technical team already has all this information, then they can start working on providing the solutions and working with the customer to fulfill the needs.

If your customer still wants things done yesterday, then tell them the reality of things -- or charge them a little more so that you can put in more resources, but nonetheless involve them in the solution process. Building software should not be like a fast food drive through service -- where people just line up, tell the programmers what they want, and wait at the end for the delivery. It's more like a "I'll build your house" shop, where you tell the architect and engineers what you want, and be there every step of the building process -- that way, when your house sucks, then it's not the builders fault because you made the decisions on how it should look.

Allowing technical people to be creative on solving the problem doesn't mean you let them determine the priority of the deliverables. It means you allow them to solve the right problem at any given time. It's like leading a pack of wolves and directing them to the right flock of sheep.

How do you lead a pack of wolves? That's another discussion.

Continuing on to the prioritizing of stories, it also allows the technical team to solve the harder problems first. You ride the productivity wave by allowing the most productive people to do the most demanding tasks first, and not worry too much about the plateau in productivity later in the project.

The last thing you want in a project is delivering the non-important features of the software while leaving out the more important ones. I as a customer would rather have the important parts there than have the extras first without the core functionality. I wouldn't mind too much if I see that the extras will come later, but the really core functionalities are already there.

Prioritizing stories allows project managers to determine a lot of things at the start of the project, as well as while the project is on-going. It allows customers to communicate exactly what they want in the order that they will be satisfied in. It also allows the technical team to be productive and creative in the most efficient manner.

First things first. One after another. You don't get to the next one if you don't start with the first one.

Thursday, March 30, 2006


Now What?

Okay, you have the stories written down containing enough details. You've told the developers about the necessary details, without setting them on stone. Is there anything else to do?

A good story is one that usually leaves the reader satisfied -- may it be a fairy tale, a suspense novel where the bad guy is revealed, or something that ends in "happily ever after". But we all know that there are some stories that need a sequel. Think of a story when you were a kid that you loved to extend, and expound upon, or make up stuff about.

Role playing games rally around the notion that stories are built around quests. When you finish a quest, you're sucked into another one. It's no different from stories that we write for the software developers -- since fulfilling a story leads to another story.

In the previous days, I wrote about writing clear simple stories, and writing complete simple stories. Today, I'm writing about sequencing these simple stories.

Defining which stories are related to each other is nice -- you can make a great big story built of many different small stories. You can mix and match these small stories and reorder them to make completely different big stories. But you'll run into a brick wall when you find out that these stories don't necessarily need to be told in sequence.

What?! You just told me we're going to put them into a sequence?! I did. But that doesn't mean that the sequence of the small stories to form the big story will determine the sequence in which they will be built. It does however tell us about which stories are related, to allow us to determine which set of stories are most important.

How does this happen? It's important for the customer to determine which big story to realize first. This is again so that we can determine which set of stories (not necessarily related stories) we want realized first. Important decisions like these come into planning sessions, especially when developers are falling behind in delivering stories for the latest development iteration.

Imagine this (bear with me here, I don't know a lot of fairy tales): Cinderella and Sleeping Beauty are living in different parts of the continent. They both have the same prince (let's just imagine, please) but the prince has only until midnight to slay a dragon and wake up Sleeping Beauty, or do the last dance with Cinderella. This wouldn't be too much of a problem if he had all day to slay the dragon, but unfortunately it's 10 pm and he has to make a decision.

In this situation, the prince can continue on with the "Slay the Dragon" story and do the "Dance with Cinderella" story after that (and leave Sleeping Beauty until the next day). Or if the director wants to finish the "Wake Up Sleeping Beauty" story first, then Cinderella will have to wait until the next midnight taping, and reschedule the bippity-boppity-boop magic for next time (which might cost her a lot).

The point is, someone has to make a decision. In this case, the director (or producer, or someone else) has to make a choice and tell the prince what to do, and which story to finish first. And the prince doesn't have to decide for himself, so that he doesn't get in trouble.

Aha! Yes, that's the point. The developer doesn't have to get in trouble (or too much trouble at least) for decisions that the customer has to make. This way, the developers will know what they should be working on when the end is near -- so that the little time they have will be channeled to the more important things to be delivered.

Grouping related stories together, or those that might depend on each other is a good way of determining which things may or may not come first, as well as attribute priority to these stories. This exercise is usually done to keep everyone's sanity and let everyone in on the big picture -- which is always a good thing.

Important decisions made by people make people important. Keeping important decisions to the important people gives people importance -- and value of the decisions affect the value of people.

Wednesday, March 29, 2006



Now you've got them stories written down, and made really nice and simple to understand. They seem like simple stories, but somehow you feel like they're a little too concise. You feel this compusion to get into detail and get into the technical aspects of things. It feels like you can't stop at telling more about the story, that you find many different ways of putting in more detail than necessary in the tiny index cards you have been given.

This is a common problem encountered especially by customers who want to tell the technical personnel what to do. It's like the time when you have your mechanic looking at your car, and you then telling him what should be done -- instead of telling him what the problem is. This is a symptom of orderitis or a showing of a primal need to order someone around.

This thought process basically impedes the thinking process of most software developers -- telling someone how to do his job leads to the "why don't you do it yourself?" response. And you don't want your software developers telling you that. Or at most, you don't want them not doing their job, which is basically creating software to fulfill the needs.

What do you do then when you have a compulsion to give more than necessary details regarding a story? It's really pretty simple. Just tell your developer(s) about it.

Yes, don't write it down on the index cards, don't write it down in your emails, or print them out on paper. You may print them out on paper, but shredding them afterwads would be great (but wasteful).

It's that simple? Yes. You don't need to bombard your developers with painstaking details to let them do their jobs -- unless you're the lead developer/architect (but even so, it's not healthy). Even if you do know what you're saying, stick to words not written down on paper. That way, it's easy to say them, and it's easy to forget them. The last thing you want is your developer telling you that the way you do things is so much more complex that the reason they're behind schedule is because you wrote down/emailed them to do it a certain way.

Sometimes, the best people who can decide how to solve a problem is the ones facing it. You can give advice, you can lead them somewhere, or you can give them books -- but it's essentially their job to solve the problem. Supporting them in the problem solving process is so much better than telling them what to do.

So the next time you feel the need to direct developers (when you're not a developer yourself, or if you're a developer but not assigned to the project), then just tell them about what you think. Don't tell them what to do but do tell them about the details that may be helpful to their problem solving endeavor.

Learning is not a matter of hearing it, reading it, or seeing it. It's about experience, exercise, and retention. You don't learn if you don't make mistakes. Making mistakes involves doing something.

Tuesday, March 28, 2006


One Time...

When you're telling a story about something that's supposed to happen just once -- or something that happened already, once in your life, someone else's life, or something you saw in a movie -- how do you do it? Do you talk generally, or do you talk in specifics?

The answer could be it depends on who you're talking to. If you're telling a story to a friend, then you'll be telling the relevant parts and even the details that are needed for her to understand the story. If you're telling a stranger about it, then maybe you'll tell them about the really general things -- and maybe even exaggerate or obliviate some aspects of the story. Or maybe when you're telling someone about something that you already told that someone about, then you'll use a reference to your earlier story.

It's true that it really depends on the audience -- but there are undeniable reasons why there are some really important parts of the story that have to be there. There are elements to a story that give it a concreteness, even if the details aren't mentioned literally. There are a few important things that all stories will require:

These are the same elements that User Stories should contain. Usually the Setting is well defined in the context of the project, and each story should contain a sequence (if it's required), the actors, and the action in short concise 3x5" index card scribblets. The simpler and understandable (and clear) a story is, there's a less chance of confusion -- and it enables the customer to communicate precisely what they require.

If you look at the stories that need to be made reality, usually these are functional stories. A short example follows:

User Registration

A User enters his personal information into a form. The information is validated, so that the required information is entered. The data is then stored, and made available for future use.
This story is short, concise, and complete in its own right. This can be part of any project, and it doesn't have to be a web based project -- it can be a paper form, a verbal form, a virtual form, or some other form I don't know about. What this allows the customer to do, is define the setting of the whole project -- so that these stories are set in a common setting.

Keeping stories really short and simple allows the developers to ask the most important details from the customer, so that this information can be noted properly, and communicated and discussed in detail. This is done so that all the developers involved in the development process will have a common reference, and so that the customer and the developers are on the same page.

Creating these stories allows the customer to define the functional requirements from the system without having to burden himself of the technical details. This also allows the developers to isolate the customer from the technical details of a system and focus on delivering the functional requirements.

A well said story is one that usually gets told again. A well understood story is one that doesn't need repeating.

Monday, March 27, 2006



It's not rocket science really... It's just about telling someone how your product works. And what better way to do it than with a story?

It's a simple game really of making something (a unit of functionality) sound simple so that the requirement sounds really simple to understand. When it's been understood correctly, it now involves action and careful planning to actually fulfill the requirement.

But what if you're talking to people who do rocket science for a living? What if they already go about it like it's astrophysics or string theory? How do you tell someone who's been doing it for a certain way already to simplify things?

It's actually hard (though it may sound really simple) to get someone to simplify a solution when they're so used to thinking complex terms. It's not really just about simplifying a solution -- simplifying the thinking process and solution formulation process is like trying to unlearn a lot of habits.

I just found out how really complex experienced programmers who have been so used to 'architecture' and 'hack-up' and even 'design-centric' approaches can think. And with the focus on flexibility, speed, and adaptability, the agile methodologies (like XP and TDD) might have to require the rocket scientist to go back to the good old simple arithmetic days. And in this regard, you might (and would most probably) encounter resistance.

Listen to a child when you ask one "how do you think a rocket will get to the moon?" You might get answers like "of course, it will fly!" or "someone in the rocket will push a button and it blasts off into orbit" or even "I dunno, maybe my dad knows...". Okay, the last response is the worst kind of response because it shows a lack of curiosity and a dependency to some "higher power" or "authority" hampering the creative process.

The first response is that of simplicity -- there's an assumption on the functional requirement to reach an end, no matter how that happens. This kind shows the abstract and simplistic reasoning behind problem solving, which sadly gets lost when we start amassing knowledge. People who respond this way are usually people who simplify things as a matter of functional units -- and that's what you want when solving problems. Notice that the response lacked detail, but contained enough information to count as an explanation?

The second response is what you usually get from people who already have a preconceived notion on the solution -- usually these responses come from people who have seen something about the topic, or have read about the topic, or maybe even know a lot about the topic and try to simplify. Usually, children who respond this way already have some idea how a rocket works -- and thus will be more or less boxed in when a new rocket design deviates from his already preconceived notion.

In the next few days, I will be outlining some of the general methods I employ to get people (especially software developers) to simplify the solution to a problem. However, I borrow a lot from the experiences and writings of other authors and colleagues in the field. Some may be new, and others might be prviously proposed/done.

Remember someone telling you a story that dragged on and on that you lose the point?

The simple solution is usually the most elegant solution. Elegance comes at a cost, and usually this elegance leads to considerable value.

Friday, March 24, 2006


Show Me

Have you ever heard the phrase "talk is cheap, I want to see results"? There has been a lot of changes in the way software is being made and being used at least in the past 10 years -- it used to be about creating the latest and greatest one application that dominated the market; now it's about playing well with others and being invaluably useful alone.

In the nineties, a lot of money went into marketing hype and "sales talk" as well as the dreaded press releases. They're all fair in business, and of course you've got to find a way for your product to get noticed. But is all this effort really worth it? Let me put it another way, let's say you get everyone hyped about a product you're working on -- and then suddenly a competitor comes out with a product that's half as hyped as your product but it sells like hotcakes fast now. What do you think will the impact be on your business' bottom line by the time you release your hyped product?

A lot of developers I've talked to can explain the whole phenomenon as "crap". You usually hear the word crap right after marketing. You want to know why? Because these developers know, that unless they see something then there's nothing. It can't be valuable unless it's tangible (or at least, virtually useful -- which is an oxymoron).

So how do you create value with hype? Business has many terms for this -- market share, name recall, mind share, branding, etc. -- but all these have something in common: they all refer to nothing. Not exactly nothing, but something that exists with the white unicorns in the world -- something you make believe in.

Now that's alright in business, but you have a problem when you have a developer telling you the same things: "you know, the software I wrote will do your thesis, his thesis, and the theses of other people for the next 200 years... but I'm still in alpha" or perhaps "I have forseen these problems and have provisioned solutions already in the software I'm writing... but I'm still working on it". Again, talk is cheap but managers and customers want to see results.

The worst thing that can happen is you hype yourself up for the fall. In this situation, you're only going to be disappointing your customers, if your product isn't up to their expectations. And the worse part even, is when they start saying:

Show Me.

Now wouldn't it be better if you just showed your customer a working product and then asked "what do you think?" Your "marketing" is already part of your value development, and feedback will let you build on whatever value you've already produced. It might be a cool new framework that was derived from your initial product, or a cool new user interface which made things a lot easier. At any rate, your initial product already has value and you can build on that value -- and create even more value -- when you just show the customer something they can gauge.

This is the crux of the agile methodologies: solve the problem now, figure out design later. While you're solving the problem, you might stumble upon great design. Maybe designing the solutions is the solution, so it's a cyclic process that benefits from something: results.

The two words show me can also be used by the developers when they're confronted by a customer that says the product doesn't work. And the only way to show that something works or doesn't, is by testing it.

Now the next time you hear a developer tell you "The system I designed is fool proof, it's not my fault that it's not doing what it's supposed to do...", just ask him:

Show Me.

Something that doesn't do what it's supposed to do, is something that needs fixing.

Thursday, March 23, 2006



I have decided to come up with another blog just for keeping tabs on my consulting services for Third World IT Companies. The clients I have aren't really third world companies, but they are companies that are here in the third world.

Now just to set the rationale of the blog, I've written down the bullet points and main issues I will be tackling in this blog. These are the basic assumptions (and constraints as well) that will lay down the foundation of subsequent posts and articles on this blog.

This blog is about experiences, tidbits, tips and tricks, and bite-size articles about Agility in Business -- especially in the business of making software.

You may email questions, suggestions, stories, and comments to dean [at] orangeandbronze [dot] com -- input is most appreciated.

Dean Michael Berris is a resident C++ consultant for Orange and Bronze Software Labs and is doing software development and project management consulting for a number of IT companies in the Philippines. He pushes Agile Software Development Methodologies along with his partners Calen Martin Legaspi and Butch Ladingin to various IT companies in the Philippines.

This page is powered by Blogger. Isn't yours?