-- John Lennon
We won't be right, but we can avoid foolishness with a few simple
tools. We can get better by refining things. To do that, we have to have
something to refine. So we plan and estimate.
[There's way too much in this chapter… we need to break it down and
reorganize]
Planning the XP way formalizes and reinforces the separation between business
decisions and technical decisions. (Who says XP is totally informal?). It lets
customers and developers learn their roles and teaches them how to talk to one
another. This is essential to your project success.
Setting a course and steering is the way we plan XP projects. In fact, XP
projects are one long drive. Steering keeps us from crashing in the present due to our
bad guesses in the past.
Perhaps most important, communicating about planning and estimating is the
primary means of helping customers and developers to embrace change without fear.
Learning Roles
At OOPSLA 2000, someone asked Kent Beck to boil XP down to its essence.
The first thing out of his mouth was "Separating business and technical decisions."
We agree. Planning is the first step in that direction. It is where developers and
customers learn and practice their roles.
Alistair points out that two people at a whiteboard is the most effective means of
communication. We would suggest that a business person and a technical person
manipulating story cards on a table is a close second.
Customers write stories (or even just a good name for the story) on cards and
prioritize them in the Planning Game. This gives them continual practice in
specifying what the system is supposed to do and in prioritizing business value for
developers. When developers ask for clarification on something, the customer gets
developers honestly as partners.
Developers break stories into tasks and estimate them in the planning game.
This gives them continual practice in understanding what customers are saying. It
helps them learn how to estimate as accurately as possible, based on past experience.
It helps them get used to probing for the customer's meaning underneath the words
on index cards. When in doubt, ask the customer. These exercises force developers
to learn how to talk to customers honestly as partners.
These roles are one of the important points at which XP lays down the law.
Customers decide what gets done, and in what order. Developers decide how long it
will take. Unless all of the players respect these roles (and play their own), XP won't
work. Prepare for lots of problems down the road.
Developers cannot assume a given feature is necessary unless the customer tells
them so. A developer can't make stuff up. If the customer doesn't put it on a card
and prioritize it, it doesn't exist. If the developers don't understand a requirement,
they ask the customer. If they have more time than they thought, they ask the
customer what to work on next. If they have less time than they thought, they ask the
customer what to defer. When in doubt, ask the customer. Then follow instructions.
As Kent Beck says, "Requirements is a dialog, not a document."
Customers must accept developer estimates without question, trusting that the
estimation process will be self-policing over time. When the developers tell the
customer that something has to fall off the plate in order to satisfy the customerestablished
priority of stories, the customer has to tell them what falls off. There
can't be any bickering. You'll get it next iteration if it's the first priority of what's
left, end of story. No fair "holding their feet to the fire" to get more in less time.
That's against the rules. It's also against the rules of reality.
An Introduction To Reality
Everybody needs at least one CASE tool. No exceptions. If you don't have a
CASE tool, you are doomed to failure. You are living in a fantasy world. And, if you
buy your CASE tool from a software vendor, you paid too much. Don't buy the
training either. All the training you'll need is write here in this chapter.
The best CASE tool is found at office supply stores everywhere and it comes in
a variety of sizes, colors, and designs. If you don't currently have at least one variety
at your disposal, chances are good you can get your hands on it in short order
without having to fill out a purchase requisition form. Oh, how foolish of us, we
broke the rule and used an acronym without defining it first…
cards. The resulting product may not look as polished as those produced by your
favorite software-backed tool that produces pretty diagrams, but the positive effect it
can have on your project is quite remarkable. Index cards, when used correctly by a
trained professional, have the power to make both business and technical people face
reality!
(NOTE: It does not have the power to make them like "reality" or deal with it
rationally, it just makes them face it).
Let us share several stories that we've dealt with over the last few years.
I'd Really Like to Help
Remember how Ken shared that he really messed up when he introduced XP to
his first client. Well, that is only partially true. He messed up in that he wasn't as
gentle and patient as he should have been and sometimes was focused on the wrong
thing. It was at the same client that Ken began to see the power of XP to chart a
course to the land of reality.
The client was under a lot of pressure to raise his next round of capital from
Venture Capitalists. They only had 2-3 months worth of money remaining. It
seemed pretty obvious to Ken and the founder that the Framework he was working
on for them was the foundation to their long-term future.
In the first few weeks of Ken's engagement at the company, his task was to learn
the prototyped framework and some of the technologies it was exploiting as well as
make recommendations for where to go with it. After doing so and spending a bunch
of time in discussion with the founder, it was clear that the framework needed to be
tightened up. The client agreed to this and the direction had been somewhat clearly
set before they left for a three week trip to California for a series of shows, sales
calls, and fund-raising efforts. It was agreed that Ken would work with Duff while
they were gone in "XP fashion".
Those three weeks were considered "Iteration One" even though the client didn't
call it that. We had to create our own stories based on what the client had said
verbally before they left. We've already shared what great progress was made and it
was clear that the footings for the foundation were laid. Not only had we
accomplished a tremendous amount in those three weeks, but we had gotten quite
good (relative to where we started) at XP. We had broken down the stories into very
small tasks and estimated them before we started them. We paid attention to how
well we estimated and were getting pretty good. And we had a lot of candidate
stories to share with them that we felt would be needed to finish the foundation in
the next few iterations.
While the client was in California, we had occasional conversations. They told
us each to work on a couple of different things until they could go over the details of
what we had done with them. Duff and Ken were not convinced that they needed to
Pair program all the time, so they went their separate ways and tried to communicate
with each other several times a day. (They were both working from their houses at
the time). After a few days of working by themselves, even with frequent
communication, they were both getting a sense that they were working more slowly
and that the quality of what they had produced had gone significantly down… Duff's
significantly moreso than Ken's (who was more seasoned), but both were noticeable.
The client came back from California and were "ready to meet" a few days later.
By this time, Duff and Ken were ready to propose doing XP exclusively until proven
why they shouldn't. The client was thrilled with what we produced, but felt we'd be
better off working on our tasks by ourselves. "We can't afford to pay two developers
to do one thing. It's just not realistic." (see Pair Programming section).
Ken and Duff both accepted this for a while, but as they saw both of their
quality going down and their work getting harder to sync up they started pushing
harder to work together and do XP. They also wanted the founders to join them,
telling them how much they'd learn by doing it. The client's said that they didn't have
time, so they asked Ken to produce a document describing the framework, while
Duff was supposed to work on a Configuration application for the framework.
Ken and Duff's attitude got worse, and the clients started to try to build stuff on
top of the framework. Unfortunately they were building there stuff late at night and
in the wee hours of the morning. (They were too busy with business things during
the day). Occasionally Ken and Duff started getting e-mails that would say
something like, "I was having problems using the framework last night. Finally, at
around 2 AM, I figured out how I could use the Bus to X, but I'm not sure how to
make it do Y."
We thought we had documented it well, so we pointed them to that point of the
document and said that if their questions weren't answered, we should just sit down
together and work it through. They "didn't have time to sit down together… but
thanks for the pointers". Eventually their frustration with the framework was getting
higher but communication was getting worse. We suggested pairing with them and
they started getting upset. "No, we told you we can't afford to have two people
working on one thing."
In addition to this, most communication came in the form of directives or
suggestions. "Could you add this feature from the prototype back in.". "I need the
framework to do that". "It would be good if you could…". "Flush out the
documentation more." When Ken asked for help in understanding what they were
asking for, it was difficult to get an answer, but he'd often get a couple of more
directives. He was also told to watch his hours, because money was getting tight
until they could secure the next round of funding.
It was pretty frustrating. He wanted to help but felt unable to. So, he came up
with a plan. He put everything he was asked to do on index cards in the smallest
chunks he could imagine and put an estimate of number of the number of days he
thought it would take to complete each. Most of the numbers ranged from 0.5 days
to 2.0 days. The ones he wasn't clear on had significant question marks next to the
number, usually meaning that he needed more information about exactly what they
wanted because there was some inferred ambiguity. He had between 40 and 50
cards. Duff started making his own set of cards. At times it wasn't clear whether
Ken or Duff were supposed to be working on a task because they were both asked
similar things in different conversations.
Right around the same time, the founders said that they could only commit to
about 200 more hours of work. So Ken took advantage of the opportunity. "I
appreciate your limited funds and would like to sure you get the best out of these
200 hours. I've been writing down all of the things you've asked me to do and it adds
up to a lot more than that. Can we get together sometime in the next couple of days
for an hour or two and prioritize the tasks? That way we'll both know exactly what
we are expecting and aren't expecting."
The meeting was arranged. It started out pretty amiable. Ken explained that each
card just had a sentence or two about each thing he had been asked to do, and
explained the numbers. He further explained that those numbers didn't include any
time for communication with them or any other "overhead" so that they might want
to multiply by a fudge factor of 2 or so to figure out how much he could actually get
done. He asked them to sort out the higher priority items first to narrow down the
list, and then prioritize within them.
The poor clients, who were already overwhelmed trying to keep the business
running while trying to raise funding, were even more overwhelmed. It started out
OK as a handful of cards were obviously not urgent. That left them with about 40
cards to sort out, most of which they felt HAD to be done in the next two months or
sooner. We worked through the ones with question marks, attempting to clarify what
was being asked for. Often it was simple. Sometimes it was "we'll just need to hold
off on that one. I'll need some time to think about it and then get back to you."
Occasionally our estimates were challenged, and on one or two occasions it got ugly.
The bottom line was that, in a few hours, we had a plan that everyone agreed to.
Some tasks had been reassigned. We also had a few action items. One of them
would keep a master list of the tasks, and if others were added, they would have to
explicitly say where that task fit in the list of items and what would slip out.
We wish we could say that communication immediately improved and that XP
got accepted and we all lived happily ever after. It didn't happen that way. However,
for the next two months, everybody did a pretty good job of living in reality,
whether they were happy about it or not. We did pretty well at hitting our estimates,
and that was acknowledged as a good thing by the client.
By the way, about a year later, the founder called up Ken and asked forgiveness
for how he had treated him. He recognized that he had often not been thinking
clearly due to lack of sleep and was under a lot of pressure, but that it wasn't an
excuse. He shared that the work we had done, especially the work Duff and Ken did
together had stood the test of time and he had grown to appreciate it more and more.
Did they become an XP shop? No. But they hired us to do some more work and
didn't have an issue with us doing it in "XP fashion".
Welcome Back to Reality
At our first large XP client, we had a problem that no one from the business side
seemed to be that concerned about an end date. They enjoyed steering, and
understood that everything had a cost. They would ask for something new and we'd
give them an estimate. Most of the time they would say, "OK, it's worth 5 days" or
"N days". Our iterations were released internally. People liked progress but we had a
growing concern that the scope creep was going to keep us from getting the product
out externally.
All of the old stories were kept around, but nobody was really checking whether
they were still necessary or whether the estimates on them were accurate or not.
The question was asked of management, "Is there a date we need to target for
shipment release 1.0?". Although there had been no firm commitment to the market
yet, they did feel that they should set a target. "March 2001". OK, then what we need
to do is resort all of the stories and figure out what goes in the release.
The big "recommitment meeting" was planned. Before we all showed up, the
designated customer and the project manager went through the list of stories and
made sure they were all still relevant, and the customer came up with a few more
that hadn't previously been captured. Then the big day(s). We planned several of
them because we didn't know how long it was going to take until we had a new plan
together.
We felt that the first thing we needed to do was to make sure everybody
understood the gist of each story. So, we started at the top of the pile and worked our
way down. For each story title, if anyone had a question about what it was, they
would raise it. Many passed without explanation. Often, if someone asked for
clarification, a one or two sentence answer would be sufficient. For about a fifth of
them, someone would recognize an inconsistency with a previous story or an
overlap. Every once in a while a new one was added because of issues that were
raised. After the better part of the day, we felt we had a pretty comprehensive list of
remaining stories: over 200 of them. It was clear that we wouldn't get all of them
done in the three or four iteration we had before we had to get it to system test (in
this highly regulated environment, this hand-off was not negotiable). Time to
prioritize.
We started by redefining the three categories of stories:
High - We don't have a marketable product without this.
Medium - A significant portion of the market would not buy the product without
this.
Low - Nice to have. Some potential customers would like it, but it isn't likely to
be the thing that will make or break their decision.
So, we started at the top again. The plan was for the customer to declare whether
they were high, medium, or low. She could ask for clarification to help her make her
choice or break them up into parts. E.g. We had a "user must be able to configure
the system" story. It was clear that this was a high, but we could get by with
allowing them to only configure a couple of pieces of the system necessary for it to
physically work in their environment (a smaller story), and then make the remaining
things they might want to configure a low. If the categorization the customer made
didn't make sense to someone on the development team they could challenge it. It
was possible that the development team didn't understand it, or the customer had a
different picture of what it meant than the developers did, or that the customer wasn't
thinking clearly. After being challenged and the ensuing discussion, the customer
still had the final word about what category it was in.
This took the better part of another day.
At the end of it, the project manager said, "OK, now we estimate.". Ken
interrupted. "May I make an observation? We could certainly pass these cards
around and estimate each one of them, but I think there is something important we
should not ignore before we do that. I'm holding about 50 high priority cards in my
hand. We've all heard what they are, and there are very few one or two day stories
in here. Let's say that the average story size in here is six days, which I think might
be conservative but is probably in the right ballpark. Do you all agree?" (nods and
other forms of affirmation). "OK, so if it's in the right ballpark, we're talking about
300 days worth of stories. Over the last few iterations, we've been pretty consistently
hitting around 50 days per iteration. Therefore, the chances are slim to none that we
can hit the target date even if we only stick to the highs." "So, are you saying we
shouldn't estimate them?" "No, I'm saying that we shouldn't fool ourselves into
thinking that there is any way that target date is realistic, especially since we've
already been told we can't add any more resources to the project. And I've heard the
customer say that she didn't want to settle for just the highs in release one, but
wanted to get at least a good chunk of the mediums before it got out there." (NOTE:
The client has an existing product out in the field that this is supposed to replace.
The customer felt it wouldn't be good to introduce a new product with less
functionality even though it had a lot of other features that their old product did not
have).
There was a lot more ensuing discussion, we'll save some of it until a later
chapter. The point here is that there were some people living in a fantasy world (or
at least hoping that the reality they were suspecting wouldn't unfold). Once they had
the stack of cards in front of them, they were all living in the same reality.
It's a Bigger Project Than I Thought, But We Can
Get Something Out Quicker Than I Thought
A long term client of ours had previously used us mostly for prototypes and
sanity checks while they were exploring entering some completely new markets in
the health care industry. They had spent a long time exploring a lot of different
angles to entering the new market. It was tough to wait while we were all confident
that the longer they waited to start something, the better the chance that someone
else would beat them to it. Finally, one day the phone rang.
"Ken, I think we might finally be ready to go forward. Can we spend some time
talking about what we want to do and come up with a plan to get there?"
"You bet. Thursday is the only day I could do it this week. If that doesn't work,
we can try to juggle my schedule next week."
"I'd really like to get going on this. I can meet you Thursday afternoon. At least
we can get started even if we don't finish it, we'll at least have a better feel for it."
The setting was perfect. The client, Ken at the studio with others to draw on if
necessary, and a $1 shrink-wrapped CASE tool.
He cut open the tool and gave the client a 15-minute training course in "The
Planning Game" and the use of the CASE tool. The client said, "I think I get it, but
I'm not sure what kinds of things you want me to write on the cards or what
granularity of detail you want me to write down." Ken said, "I'll tell you what. Why
don't start by describing the things you want the system to do. I'll take notes by
writing stuff on the cards and ask you for clarification as we go."
In the next couple of hours, we talked and recorded about 40 cards. Ken then
asked him to prioritize. Then Ken said that we would start to put ballpark estimates
on them. He asked for some clarification on some of them and quickly realized that
some would take quite a while, so he asked how they might be broken down further
into "minimum necessary functionality to demonstrate the capability", "functionality
necessary to really add value" and "nice to haves". He could put rough estimates on
most of them, but there were a lot of questions about the possible user interface
approach.
So Ken called a couple of the other guys in and we discussed some user
interface issues. He seemed to want a web interface. We discussed a couple of
approaches to that and raised some performance concerns due to the environment he
expected the users to be working in. (On the go with a basic portable and
intermittent connection… often via a phone line).
We ended up with about 60 cards with numbers on them, a few of which were
big unknowns. We adjusted for the big unknowns by adding a couple of 8 craft unit
(similar to an "ideal engineering day" from XPE) cards that said "revisit [X]" since
we suspected that the first thing we tried would not be sufficient but would uncover
issues. Ken asked him how fast he would want to move in terms of how much could
they spend per month. He said, "I'm not sure, but let's go with $X/month". "OK, how
long do you want each iteration to be: 2, 3, or 4 weeks?". "Let's go with 4. You
know our company, there's no way we could respond to something you produce any
faster than that."
"OK. That means you get 12 craft units per iteration. The numbers are on the
cards. Start with iteration one and pick which cards you'd like to tackle first. Once
you've got 12 craft units, start iteration two, and so on."
In about 15 minutes, he had 13 piles (the 13th being only partially full). Based on
some of the things he had deferred in our earlier discussion, Ken told him that he
might want to be conservative and assume the whole thing would take 18 months at
that pace. He could shorten it by picking up the pace, but he probably couldn't make
it under twelve months without losing a lot of efficiency if he could get it shorter
than that at all.
"Wow. This is a lot bigger project than I thought. And you are pretty confident
in your numbers?"
"As sure as I can be without getting into a lot more detail. Based on my
experience, I'd say we're not off any more than 50% to get something out that does
all that you've asked for in some way. That's why I suggested figuring 18 months
even though we had just over 12 iterations here. But let's face it, we're just guessing
at what this is really going to look like. We should probably work on the first two or
three iterations and we'll have a much better clue.
"Would what we put in those first three piles be enough for you to show it to
someone and get some real feedback?"
"Yeah. I'm pretty sure it would. I'm pretty excited about that. I was hoping we
could get something to show people in three months, but I was doubtful that it would
be possible. That's really good. It might make the whole project easier to swallow if
they know that they can have something to shop around in 3 months."
"OK, where do we go from here? (tongue firmly planted in cheek) Can we start
Monday?"
"I wish. But I think I have enough to go on to present this to some people next
week. Let me write down the stories and the time frames. I'll turn it into something
more polished and present it to some senior management people.
"I was real impressed with this process, but I don't think they'll give me that
much money if I come into there office with nothing but a handle of cards."
"Go figure."
"But really. I can't imagine any other process I've seen giving me this much
information in this short amount of time. It's pretty powerful."
"Yeah. It's powerful because it's simple and there are no smoke or mirrors
involved."
By the way, they still haven't gotten the funding for that project, but they were
back the next month to scope out a different project in half a day. That one worked,
too.
You may not be able to do as good a job of Ken in getting this all down in half a
day. On the other hand, you may be able to do a better job. If you have a process
that sets reality in front of your eyes in an easy to manipulate way please let us know
what it is. If you have one that works as good and is cheaper, let us know that, too.
Otherwise, use the $1 CASE tool.
The Xtreme Hour
Several years ago, somebody [look up who] came up with the concept of the
ExtremeHour. The idea was to get people used to the idea of many of the concepts
of XP.
Recently, we've been making pretty good use of this. We've modified it from its
original form slightly, but it fundamentally is the same.
The premise is that you divide into groups of 6-10. Part of that group plays the
role of the development team, and part of it plays the role of the business team.
Together they are tasked with building a product from concept to delivery in one
hour. (Really they just deliver a picture of the product in one hour).
You can do this with people whose natural roles are business or technical or a
combination. It is ideal when you have a mix of these people and you make the
business people play the role of development and the technical people play the role
of business. That way they get to walk an hour in the other's shoes. But, the point
usually comes home whether or not you mix them up this way.
At the end, ask them what they've learned. Here is the paraphrase of a VP of IT
Operations at a large multinational bank:
"I learned how important it is to have more collaboration and to spend more time
communicating. I also learned that when I ask for something, that I should specify
whenever possible parameters for testing how they will know that it works. In an
environment like this, I can clearly see the confusion that vague requirements make
and how hard it is at times to figure out how to do something even when the
requirements are clear because it has to work with all of the other requirements and
often, they seem to be contradictory or at least difficult to implement such that both
requirements are met."
Would you like to hear someone in your management chain say something like
that. Ask them if they've got an hour or two to learn about the development process.
Steering
Without a direction, you can't begin to implement XP. If you don't plan, you
will have no idea what to code today, or tomorrow, or next week2. That means the
"programming" piece of XP won't matter. A great system metaphor (of any of the
other practices we talk about in Section Three) without a roadmap for making it real
is worth about as much as sock lint.
As Kent Beck pointed out in XP Explained, XP is like driving a car. Planning is
like steering. We make small adjustments to keep ourselves on the road in our lane.
When we end up in a ditch, planning is how we get out of it. If you don't get good at
steering, you might as well not drive.
When Roy was in college, he loved to watch the men's crew team eat. These
guys burned calories standing still, so they had to gorge themselves often just to get
enough calories to survive. Since nobody else in school was quite this weird, the
crew team ate as a pack. They would sit at a big table, heads down, attacking their
food like hyenas at a kill. Every once in a while, one guy would lift his head to look
around and check the environment. We work and plan like that.
Planning and short iterations (Chapter 11) work together here. We start by
planning. We lower our heads and go for broke for a short time. Then we lift our
heads up and plan some more. We learn from what we saw during the last sprint. We
fold the lessons into the revised plan. Then we're heads-down again, sprinting
through the next iteration. We never go too long between planning sessions, usually
two to four weeks. The plan isn't reality, it's just a guide. The act of planning is the
important thing. So we do it so often we that we feel uncomfortable when we go too
long without it
Embracing Change Fearlessly
XP is dead without trust. It requires brutal honesty all
the time. The planning process in XP lets customers and developers learn their roles,
and gives them a forum for being brutally honest with each other. The customer and
the developers know their roles. They act them out every time they plan. And they
plan all the time. This takes fear out of the equation. It makes a change an
opportunity to learn, to do the right thing, and to make the results of the project
better faster.
Most people have lived outside the XP world at some point in their professional
careers (perhaps you still are, poor soul). Think about the interactions between
customers and developers without XP.
Does this exchange sound familiar?
CUSTOMER: "We need to segment our customers differently, based on the new
marketing strategy. The old way just won't work anymore."
DEVELOPER: "That wasn't a requirement."
CUSTOMER: "It wasn't a requirement when we started, but it is now."
DEVELOPER: "Well, put in a change request, but I can't make any promises."
CUSTOMER: "@#$%#* !!!!"
Where did this change request idea come from? It came from developers who
got tired of being asked to make changes without being given the time to make
them. Why weren't they given the time to make them? Business people would learn
new things were important, but they were never given a system that would allow
them to easily trade one requirement for another. The development process was just
a black box with one input and one output with no controls on it. This system pits
one side against another. It's foolish. You can't play to win with this kind of system.
You've got both sides playing not to lose. Development can't get started until the
business people are satisfied they have enough input to do it right. Business people
aren't confident they have it right, so they don't let developers start. But the market
demands a product now. Developers finally get started and they are already under
the gun. Under pressure like this to produce everything quickly, why would you
expect anything other than them making it hard for business people to make requests
that impact their time.
Change is a given. Most methodologies are set up in a way that makes
customers and developers fear change. Fear kills projects. Customers fear not getting
what they want, and not being able to change their minds as requirements change.
Developers fear not having a life, and being whipsawed all the time as requirements
fly all over the map. This is a recipe for conflict and distraction.
You should know by now that the horizon changes as you travel, so trying to
design everything up front is nuts. Well, requirements are the customer perspective
on design. It is the only "design" customers really know, or care to know. Expecting
customers to be able to know all the requirements up front is just as silly as
expecting developers to know the whole system design up front, but this happens
every day.
Developers don't fare much better. They are like the British Light Brigade in the
Crimean War. They charge into battle knowing full well that they'll be butchered.
They are coding obsolescence. They are producing code of questionable quality that
nobody really likes. It might not even be used. And they feel like they've been shot
to pieces by all the overtime heroics they put in trying to do the impossible.
XP is different, because its approach to planning is different. XP Installed used
the analogy of the "circle of life" to describe how work gets done in XP (we've
amended it slightly):
The customer defines business value and creates stories to translate it
into system function.
Developers estimate costs for each story, usually in some unit of time.
Developers tell the customer how fast the team can move (the team's
velocity), which dictates how much work can get done per iteration.
The customer picks a group of stories to do next, with estimates that add
up to the development team's speed for an iteration.
Developers build those stories.
The process repeats.
Developers get to produce great code. They get to estimate effort and stick to
their estimates (customers can't quibble). They get to tell customers how much they
can eat at the buffet, given the available time. They don't get slaughtered.
Customers get to set priorities. They get enough information to make intelligent
decisions about what to do now and what to defer. They get to change their minds.
They don't feel locked in.
XP lets you move past the petty wars over turf and CYA management (which
are really other words for "fear") to getting things done.
No comments:
Post a Comment
Your comments are welcome!