It is sometimes challenging in standups to associate the card to which the speaker is referring to the conversation - particularly for infrequent guests. A low tech solution that I recently implemented for my teams is to use a laser pointer as the token that gets passed around. As the speaker is referring to cards on the wall he/she is expected to point, using the laser, to the cards(s) in question.
An ancillary benefit to this approach is that it can be an early warning sign for scope creep when a team member has no card to reference. It can also be a warning that cards are languishing in the "in-play" section - if nobody is referring to those cards, they may not be getting the attention you desire.
They're pretty cheap too.... you can get a laser pointer for as little as $10.
Thursday, November 22, 2007
Thursday, October 18, 2007
Growing People
I saw a great quote the other day referenced on a blog. I can't stop thinking about it. It's from the book "Powerful Project Leadership" and the quote is:
"Managers use people to accomplish work; leaders use work to grow people".
This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".
"Managers use people to accomplish work; leaders use work to grow people".
This quote captures a great deal of what I think about leadership. It's about really caring about people. You can try to fake it (ala "How to Win Friends and Influence People"), but folks can see through the ruse. True leadership requires, I think, a fundamental desire to develop people to their ultimate potential. It's sort of like the adage "Satisfy the customer; the profits will follow" with a twist: "Satisfy the fundamental needs of your employees to contribute and grow, and the profits will follow".
Sunday, October 07, 2007
Agile Leadership and Typical Management Titles
I worked at a very big company as a software engineer for 15 years. When I began out of college, my title was "junior programmer". The promotion path was well known. Perform at a level between barely satisfactory and outstanding and get promoted in a year to "associate programmer". Keep doing a satisfactory job, get promoted again two years later to "senior associate programmer". Two more years and it was "staff programmer" (and get your own office). Promotions after that were less structured/timed and based strictly on merit.
Well... OK... not just merit.
Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.
I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.
As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?
Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.
So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):
The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.
How do these map to more traditional hierarchical positions?
Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.
Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.
(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.
Well... OK... not just merit.
Of course there was also the management path at this company, but the gig was the same.... keep doing a good job, keep climbing that ladder.
I'm now an agile guy. I look back and can't believe I had to function in such a dysfunctional system. I left that far behind. Or so I thought.
As a consultant, I get to operate in many different environments. Sometimes I get to work with just my team - the enlightened, intelligent, cutting-edge consultants at Thoughtworks and we can build a sort of bubble of rationality - a pseudo meritocracy. More often, I have to manage within the constructs of the company in which I am consulting. Many of them look like my first company where employees are operating on the ladder path.... climbing away. So the question is: when you remove rungs off the ladder in the flattening exercise (whether explicitly or implicitly), what becomes of those who were on those rungs?
Different positions - whether higher (1) on the ladder, lateral, or even lower (1) require different skills and expertise. If you're a developer, you may get promoted to "development manager" because you write great software. The aptitude, skills and motivation to write great software are very different from the aptitude, knowledge, and motivation required to be a good manager or leader. Moving "down" the ladder - say, back to writing software - usually requires missing skills, since technology changes so quickly.
So what aptitude, skills, and motivation do agile leaders need? Here's my list (in no particular order):
- Communication/Collaboration skills - "down" - in coaching and developing people within your organization
- Communication/Collaboration skills - "across" - in collaborating with folks on peer projects, others within IT
- Communication/Collaboration skills - "up" - in managing relationships with higher level IT management/leadership
- Communication/Collaboration skills - "Business" - in managing relationships with the business
- Technical skills - understanding the technology, architecture
- Domain knowledge - understanding the business
- Agile Project Management - from estimation and planning to iteration tracking
- Ability to inspire
- A fundamental philosophy that prefers frequent inspection and adaption to continuously improve
The key for the project, I think, is to ensure that these responsibilities are represented in the leadership team overall, not necessarily in one person.
How do these map to more traditional hierarchical positions?
- development/QA/BA manager (managing a group of folks based on functional alignment)
- lead developer/QA/BA (individual contributor who is annointed with the "lead" adjective).
- architect (might be a member of an architecture team, or may just be a responsibility for someone holding a different title)
- director of development (overseeing everything from requirements to release for a project)
- C-level leader (person who holds the pursestrings, defines strategy, provides the context & constraints in which the project must operate)
Any of the folks in these positions can provide agile leadership. In general, the more of these leadership aspects that are exhibited by folks in leadership roles the better. For example, though the C-level leader is likely to have ability to inspire, having a development manager who can also inspire can be a great bonus for the project.
Stay tuned for more on each of the agile leadership opportunities I enumerated. In the meantime... tell me what I've missed.
(1) Higher and lower are expressed, for the purposes of this conversation, in terms of the typical hierarchical leadership. I'll save the servant leadership and inverted pyramid conversation for another time.
Tuesday, August 07, 2007
Myers-Briggs "Lifestyle" dimension meets Agile & Lean
I was thinking this morning about how Myers Briggs Type Indicators (MBTI) play into our receptiveness and ability to thrive in agile environments and further, into lean approaches to software development.
I think much has been written about the classic programmer profile: INTJ: Introvert, iNtuitive, Thinking, Judging. The poster-child programmer is a loan wolf who uses his analytical skills in a controlled environment to produce excellent software.
From an agile perspective, introverts are, at least in theory, less likely to be amenable to or effective at pairing.I'm not sure this is a particularly apt conclusion, but for now, I'll shelve that thought.
This morning, I turned my thoughts to the last dimension, the so-called "Lifestyle" dimension. That is, Judging vs. Perceiving. From wikipedia:
So: Judging = Waterfall; Perceiving = Agile.
But wait. Isn't Agile just a shorter planning cycle to deal with? "matters to be decided" at the beginning of the iteration; "clear plans", "no distraction". These seem part and parcel of iteration-based development - scrum, for example.
It seems to me that "lean" approaches like not having iterations; just-in-time analysis; polyskilled, adaptable "resources" (aka people) are a "judging" person's worst nightmare. These judgers have already adapted to a shorter planning horizon; now you're asking for a transition from short planning horizon to flexibility - beyond their comfort level.
The challenge is to introduce lean approaches with an understanding of each participant's comfort level.
I think much has been written about the classic programmer profile: INTJ: Introvert, iNtuitive, Thinking, Judging. The poster-child programmer is a loan wolf who uses his analytical skills in a controlled environment to produce excellent software.
From an agile perspective, introverts are, at least in theory, less likely to be amenable to or effective at pairing.I'm not sure this is a particularly apt conclusion, but for now, I'll shelve that thought.
This morning, I turned my thoughts to the last dimension, the so-called "Lifestyle" dimension. That is, Judging vs. Perceiving. From wikipedia:
People with a preference for Judging prefer matters to be decided; to start tasks in good time, well ahead of a deadline; to have clear plans that they prefer not to be distracted from; and they can sometimes seem inflexible in this regard. Those whose preference is Perceiving are happier to leave matters open, for further input; they may want to leave finishing a task until close to the deadline, and be energised by a late rush of information and ideas; and they are readier to change plans if new information comes along. They may sometimes seem
too flexible for their Judging peers.
So: Judging = Waterfall; Perceiving = Agile.
But wait. Isn't Agile just a shorter planning cycle to deal with? "matters to be decided" at the beginning of the iteration; "clear plans", "no distraction". These seem part and parcel of iteration-based development - scrum, for example.
It seems to me that "lean" approaches like not having iterations; just-in-time analysis; polyskilled, adaptable "resources" (aka people) are a "judging" person's worst nightmare. These judgers have already adapted to a shorter planning horizon; now you're asking for a transition from short planning horizon to flexibility - beyond their comfort level.
The challenge is to introduce lean approaches with an understanding of each participant's comfort level.
Saturday, June 16, 2007
10 Attributes of Well-Run Meetings
I love well-run meetings. The key here - well-run. What are the qualities of a well-run meeting?
1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.
2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.
3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.
4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.
5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.
6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.
7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.
8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.
9) Don't call all-day meetings unless you have a plan for how to spend the time.
10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.
I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?
1) Facilitated. Note the distinction between this property and "led" or "managed" or "controlled". The person running the meeting has good skills at eliciting input, tracking progress and action items, and keeping everyone engaged.
2) Non-laptop/PDA focused. I can't recount how many meetings I've attended where one or, usually more, attendees have laptops/PDA's open and are focused somewhere else. Yes, I understand multitasking and the demands on our time, and the usefulness of getting things done while sitting in a meeting. The cause and effect here is not always clear, but I submit that if the meeting was well-run, the attendees would be riveted to the discussion topic to the point where they'd forget they were carrying a PDA.
3) Accomplishment-bound instead of time-bound. Meetings fill the time they are allotted. If you have 26 minutes worth of productive discussion, don't keep the meeting going to fill the whole hour you reserved. Keep focused, accomplish your objective, and release folks early to go do their email.
4) Speaking of objectives.... HAVE ONE! In agile, we talk about having "acceptance criteria" for story completion. We should adopt the same approach to meeting management. An agenda would be nice too - for more formal meetings - but I don't think it's always necessary.
5) Take issues offline. This is easy for an effective facilitator to drive, but is not done nearly enough.
6) Determine if a meeting is the right approach to accomplishing your objective. I was a participant in a weekly meeting for a couple of months for which the only agenda item was to go through an action item list and report status. I stopped going. So did many others. Fortunately, the organizer(s) got the message and canceled it. We can easily update a wiki as needed to update status. If folks have questions, walk over to the other person's office and talk in person.
7) Find a good time for the meeting. I know that cross-oceanic teams sometimes necessitate bizarre meeting times (unfortunately, early morning for me - ugh). If you have to have an 8am (or 7am or....) meeting, at least bring bagels and coffee or something. And don't schedule lame meetings for that timeframe, because your attendance will suffer even more for the time schedule (in addition to the lameness factor). If I'm an attendee to that early morning meeting, and the alarm goes off, I have a choice.... hit the snooze, or wake up excited to attend the meeting. Unfortunately, my snooze-button is well-warn.
8) Cancel if the right people can't attend. Use those "optional" and "required" tags on your meeting invitations and mean it! If someone is required, and they reject your invitation, find out why and reschedule or address the issue.
9) Don't call all-day meetings unless you have a plan for how to spend the time.
10) Don't forget the remote attendees. I find this difficult; the conference phone is dialed to the conference line and the remote attendees are there, but often the facilitator forgets them, or doesn't include them in the discussion as often as possible. Also - make the communication bandwidth as rich as possible. Use Netmeeting or other conference alternatives to share the desktop with remote participants, and set up a webcam if you can. The more you can do to make the remote attendees feel a part of the meeting, the more valuable participation you'll gain from their attendance.
I could go on. What attributes do you find to be important in meeting effectiveness and efficiency?
Friday, March 30, 2007
Thoughtworks is hiring
I work for Thoughtworks, a global IT consulting firm with offices in six countries (US, Canada, UK, Australia, India, China). We hire very good people to work on interesting/difficult problems.
We're hiring.
Most of our development is in Java, Ruby, and C# (with Ruby becoming more and more a staple of our most interesting gigs). We're looking for developers, testers, project managers, client principals, and probably sales folks.
Pluses of Thoughtworks:
- You'll probably not find a more competent/smart group of people in any other consulting company.
- We deliver working software using Agile software development approaches (pairing, TDD, etc.)
- Lots of travel (if you're single and want to see the world, we encourage travel to different countries)
- Amazing level of transparency in corporate activities and a flat organization.
Minuses:
- Lots of travel
If you would like more information, see www.thoughtworks.com, or respond in this blog with your email address and I will be happy to provide more insight.
We're hiring.
Most of our development is in Java, Ruby, and C# (with Ruby becoming more and more a staple of our most interesting gigs). We're looking for developers, testers, project managers, client principals, and probably sales folks.
Pluses of Thoughtworks:
- You'll probably not find a more competent/smart group of people in any other consulting company.
- We deliver working software using Agile software development approaches (pairing, TDD, etc.)
- Lots of travel (if you're single and want to see the world, we encourage travel to different countries)
- Amazing level of transparency in corporate activities and a flat organization.
Minuses:
- Lots of travel
If you would like more information, see www.thoughtworks.com, or respond in this blog with your email address and I will be happy to provide more insight.
Sunday, February 11, 2007
For Dummies
I've always despised the "For Dummies" book series. It's not the idea... the few I've browsed in the bookstore (with suitable disguise in place) seem to be well-written and humorous. It's the damn title. If I buy the "Sewing for Dummies" book, and interpret language literally, the purchase has nothing to do with my novice status as a seamstress (seamster?) but conveys that I'm actually a dummy.
I must admit I bought one once - but it was appropriate: "Golf for Dummies". My golf game is worthy of the term (nothwithstanding my strict grammatical interpretation argument above).
Saw an interesting title on the shelf at the library today: "Beginning Java for Dummies". This begged the question: where is the "Advanced Java for Dummies" book? And does one exist? Can you get to the advanced tier of "Java developer" and be a dummy? Perhaps the library just doesn't carry it. It was, however, a college library (OK, not exactly a top-tier university).
I checked Amazon. No, there's no "Advanaced Java for Dummies". But there is a POJFD book (OK... take off on POJO.... plain old "Java for Dummies"). There's also "Java Programming for Dummies". Not sure what the difference is. If you're not programming with Java, what exactly are you doing with it? Hmmm.... Perhaps the "Java for Dummies" book describes how to order at Starbucks.
Aside=> My favorite Starbucks order: Alok's: "double tall, two splenda, breve cappacino".... I used to pick up coffee for him and the barista would always eye me and say... "Ah, for Alok?". As if to make sure that I wasn't actually ordering Alok's "usual" for myself. Fortunately, at the time, I had no clue what I was ordering.... it could have come with pork rinds as a garnish for all I knew.
A search for the terms java and dummies on Amazon yielded 412 results. There were only 14 results for ruby and dummies. Hmmm.... guess I figured out where the smart people are hangin' out. To be fair though, not all responses were relevant to the specific technology. The Ruby results included a few "dummies" books whose authors included someone with the name "Ruby". And I'm pretty sure "Ballet for Dummies" has nothing to do with Ruby. Not quite sure how that got into the mix. Didn't have the time to peruse the 412 Java results to weed out the chafe.
Found "Management for Dummies"... hmmm, maybe there is an argument for the validity of this series. (Thinking about managers from previous companies of course.... really.... wonder if any of them are still on my Christmas list?)
I must admit I bought one once - but it was appropriate: "Golf for Dummies". My golf game is worthy of the term (nothwithstanding my strict grammatical interpretation argument above).
Saw an interesting title on the shelf at the library today: "Beginning Java for Dummies". This begged the question: where is the "Advanced Java for Dummies" book? And does one exist? Can you get to the advanced tier of "Java developer" and be a dummy? Perhaps the library just doesn't carry it. It was, however, a college library (OK, not exactly a top-tier university).
I checked Amazon. No, there's no "Advanaced Java for Dummies". But there is a POJFD book (OK... take off on POJO.... plain old "Java for Dummies"). There's also "Java Programming for Dummies". Not sure what the difference is. If you're not programming with Java, what exactly are you doing with it? Hmmm.... Perhaps the "Java for Dummies" book describes how to order at Starbucks.
Aside=> My favorite Starbucks order: Alok's: "double tall, two splenda, breve cappacino".... I used to pick up coffee for him and the barista would always eye me and say... "Ah, for Alok?". As if to make sure that I wasn't actually ordering Alok's "usual" for myself. Fortunately, at the time, I had no clue what I was ordering.... it could have come with pork rinds as a garnish for all I knew.
A search for the terms java and dummies on Amazon yielded 412 results. There were only 14 results for ruby and dummies. Hmmm.... guess I figured out where the smart people are hangin' out. To be fair though, not all responses were relevant to the specific technology. The Ruby results included a few "dummies" books whose authors included someone with the name "Ruby". And I'm pretty sure "Ballet for Dummies" has nothing to do with Ruby. Not quite sure how that got into the mix. Didn't have the time to peruse the 412 Java results to weed out the chafe.
Found "Management for Dummies"... hmmm, maybe there is an argument for the validity of this series. (Thinking about managers from previous companies of course.... really.... wonder if any of them are still on my Christmas list?)
Saturday, February 10, 2007
Shoemaker's shoemaker
Sometimes I feel like a shoemaker who walks around life in bare feet. I'm a software development professional... consultant even. I help companies create advanced software.
My colleagues are hot on IPods, Macs, PS2, XBox, fancy cell phones.
What's wrong with CD's? I've got a CD player... a bunch of CD's and I can cycle through them. I know, the IPod and other MP3 players allow you to consolidate. OK, good. I have sparse financial resources (4 kids!) and have to wisely allocate those resources. Do I need an IPod? Focus on the word "need". Do I really NEED it? Yes... I'd like one. (feel free to post a response and I'll give you my mailing address for your to send me a check.... or maybe I'll even figure out how to do PayPal, or whatever the cool version of it is now)
Macs.... I really don't understand this one. OK, it makes some cool things easier.... like creating movies, music, art, etc. I'm a left-brained guy. This is not as important to me. If you're a computer guy complaining to your management/IT department that you can't be effective with a PC.... but if they were to get you a MAC, boy, you'd be smokin'.... check your motivation. I mean, really... as an IT professional.... you can't figure out how to make your Windows experience efficient? Be honest with yourself.... you're after the cool factor. You couldn't get the chearleader in school, so now you're trying to be the "football player" of cool technology. Give it a rest. If you want a Mac, buy one yourself. And stop your bitchin.
Gaming machines.... really. Sounds cool. Why don't you try LIVING life instead of experiencing it vicariously through the imagination of some geeks who create virtual worlds? Reminds me of a guy ... good friend actually.... who claimed he couldn't make our volleyball match because he had to sit at home and watch a Giants game. What's with that. Do you live life, or are you a spectator?
Do you really need to check your email via the phone? Really? Are you that important? Ask yourself ... as you thumb through your emails in mid-conversation with a colleague or employee of yours.... is this more important than human contact? I had a manager once who thumbed through his blackberry as we had a "one-on-one" at a Taco Bell of all places. As I was conveying my career goals and such, he was thumbing through the blackberry and mumbling... "uh huh". Please.
Lastly... this "connectedness technology" does not exist for you ... it's for me. If you expect me to answer my cell phone when you call, you have severely mistaken my motivation for obtaining said cell phone. You see... I bought it to make it easier for ME to connect to others.... not for YOU to find me at all hours of the day and night.
My colleagues are hot on IPods, Macs, PS2, XBox, fancy cell phones.
What's wrong with CD's? I've got a CD player... a bunch of CD's and I can cycle through them. I know, the IPod and other MP3 players allow you to consolidate. OK, good. I have sparse financial resources (4 kids!) and have to wisely allocate those resources. Do I need an IPod? Focus on the word "need". Do I really NEED it? Yes... I'd like one. (feel free to post a response and I'll give you my mailing address for your to send me a check.... or maybe I'll even figure out how to do PayPal, or whatever the cool version of it is now)
Macs.... I really don't understand this one. OK, it makes some cool things easier.... like creating movies, music, art, etc. I'm a left-brained guy. This is not as important to me. If you're a computer guy complaining to your management/IT department that you can't be effective with a PC.... but if they were to get you a MAC, boy, you'd be smokin'.... check your motivation. I mean, really... as an IT professional.... you can't figure out how to make your Windows experience efficient? Be honest with yourself.... you're after the cool factor. You couldn't get the chearleader in school, so now you're trying to be the "football player" of cool technology. Give it a rest. If you want a Mac, buy one yourself. And stop your bitchin.
Gaming machines.... really. Sounds cool. Why don't you try LIVING life instead of experiencing it vicariously through the imagination of some geeks who create virtual worlds? Reminds me of a guy ... good friend actually.... who claimed he couldn't make our volleyball match because he had to sit at home and watch a Giants game. What's with that. Do you live life, or are you a spectator?
Do you really need to check your email via the phone? Really? Are you that important? Ask yourself ... as you thumb through your emails in mid-conversation with a colleague or employee of yours.... is this more important than human contact? I had a manager once who thumbed through his blackberry as we had a "one-on-one" at a Taco Bell of all places. As I was conveying my career goals and such, he was thumbing through the blackberry and mumbling... "uh huh". Please.
Lastly... this "connectedness technology" does not exist for you ... it's for me. If you expect me to answer my cell phone when you call, you have severely mistaken my motivation for obtaining said cell phone. You see... I bought it to make it easier for ME to connect to others.... not for YOU to find me at all hours of the day and night.
Subscribe to:
Posts (Atom)
