vegetarian scotch egg
26 November, 2012
23 November, 2012
another successful tree hunt
arrived home with a fine mn fraser fir. the family peeps were excited to go get it, but everyone lost their momentum on the drive home. looks like it'll have to sit naked (undecorated) for a while until we get the ornaments out.
22 November, 2012
we are humans, let's add some value
repeat after me: i am a human.
you really are, unless you're a bot, and, then... screw you. ok, though... you are a human. what value do you add value to a process? you can add a ton of value. sure there's not a ton of original thought these days, but you're a human and you have a chance (maybe rare) to actually produce original thought. computers--those things we use to get answers--get answers already thought of and answered by other humans. computers are really good at accessing data that other humans already thought of.
if you are a human, and, trust me if you read past the first sentence, you're a human. a bot would've totally moved on by now. if you are a human, take your damn mind and all of its potential and add value to every situation you are in. if you are a human and you're in a conversation in which data you know of is relevant and... could affect outcomes, please share that information!!!
don't assume you are just a search engine or a database client who'll just provide answers to questions. people in the conversation may not have anywhere near the context you have for the problem set. they may not even know the questions to ask to get the information they need to solve their problem. you, however, have the context and the knowledge and the ability to produce original thought. you can add value to the situation by recognizing that the other person in the conversation is trying to solve a problem for which you know the answer, and providing that answer.
don't wait. if you are aware, you can add value. machines don't have morals, even if they have answers. you have morals. you have a conscience. you need to make your knowledge known. machines may not care about outcomes, they are just vehicles toward outcomes. we care about outcomes because we can see beyond our current situation. we have perspective. if people need your knowledge but don't know how to ask for it, you still need to provide it. even if you're not holding back for nefarious purposes, failing to answer based on the fact that the other person didn't ask is a form of a lie. you know it, you've experienced it as a kid.
the real thing i want you to think about is, what are the consequences of not adding value as a human? the consequence is that you can be replaced by a computer or another simpler machine.
be human and add value, please.
you really are, unless you're a bot, and, then... screw you. ok, though... you are a human. what value do you add value to a process? you can add a ton of value. sure there's not a ton of original thought these days, but you're a human and you have a chance (maybe rare) to actually produce original thought. computers--those things we use to get answers--get answers already thought of and answered by other humans. computers are really good at accessing data that other humans already thought of.
if you are a human, and, trust me if you read past the first sentence, you're a human. a bot would've totally moved on by now. if you are a human, take your damn mind and all of its potential and add value to every situation you are in. if you are a human and you're in a conversation in which data you know of is relevant and... could affect outcomes, please share that information!!!
don't assume you are just a search engine or a database client who'll just provide answers to questions. people in the conversation may not have anywhere near the context you have for the problem set. they may not even know the questions to ask to get the information they need to solve their problem. you, however, have the context and the knowledge and the ability to produce original thought. you can add value to the situation by recognizing that the other person in the conversation is trying to solve a problem for which you know the answer, and providing that answer.
don't wait. if you are aware, you can add value. machines don't have morals, even if they have answers. you have morals. you have a conscience. you need to make your knowledge known. machines may not care about outcomes, they are just vehicles toward outcomes. we care about outcomes because we can see beyond our current situation. we have perspective. if people need your knowledge but don't know how to ask for it, you still need to provide it. even if you're not holding back for nefarious purposes, failing to answer based on the fact that the other person didn't ask is a form of a lie. you know it, you've experienced it as a kid.
the real thing i want you to think about is, what are the consequences of not adding value as a human? the consequence is that you can be replaced by a computer or another simpler machine.
be human and add value, please.
13 November, 2012
12 November, 2012
03 November, 2012
agile practitioners, are we waiters or doctors?
In the opening session at yesterday's Agile Day Twin Cities (url or #adtc2012 tweets), David Hussman and Jeff Patton introduced a metaphor for the sake of conversation. The metaphor was to give agile practitioners a way to describe their own role in the software development processes they use. The question was: are you more like a waiter or a doctor in your agile process? This, of course assumes that waiters take orders (specifications) and deliver food (features) while doctors participate in a discovery process to solve problems. The thing with metaphors is you can torture the heck out of them and render them meaningless, but I feel there's something to this and I want to hash it out a little, here.
I am now in my 8th month at a company who is committed to using Scrum for their development process. I was a certified scrummaster a couple of years back, but my employer at the time didn't practice, so I let certification lapse. Between that employer and my current employer, I took a short stint at a software company that had some big quality issues which they'd asked me to come in and help solve. We didn't have the same view of what might solve the problems, so put a few things in place to help, but ultimately decided to let them get back to handling things without me. I have done a number of agile-flavored things in my career, but had yet to practice a formal agile method before this.
Now, I'm in my 8th month of practicing full-on scrum with a product team. There have been ups and downs, but they're neither as high nor as low as I've experienced at other places. It feels extremely sane, but I have been feeling, lately, like I just react to "priority." Admittedly, until yesterday, I hadn't been able to put a name to it, and, while I had a sense that something was off, I wasn't sure what.
I've wanted to work in an agile process for quite some time, why didn't it feel perfect? Things are working very well, we get our product work done, we meet our deadlines, so what could be wrong? When in an afternoon openspace session about the Doctor-Waiter metaphor, Hussman asks those of us sitting around, "So, are you a Doctor or a Waiter?" It hit me, "oh wow, I'm a waiter." That's what I've been missing.
Anyway, in that openspace session, we kicked the metaphors around and while people were in the process of torturing it, it occurred to me that there are good waiters too. In fact, I had a chance to eat at a great tapas place a few weeks ago in which a waiter guided us through the experience. Could waiter and doctor not be two discrete things, could they, instead exist on a continuum of maturity from waiter to doctor? So, my contribution to the metaphor torture was, "Considering there's a continuum from waiter to doctor, are we working our way through med school by waiting tables?" It got a couple of snickers, but we didn't explore the thought.
Here's what I was trying to get at with the question, just because we're being waiters, doesn't invalidate what it is. It serves a purpose. I am gaining my experience with scrum as a participant, but now that I know there's a higher purpose, I'll be working toward doctor status. Admittedly, my mojo isn't being completely fed or this metaphor wouldn't have resonated so well with me. Some participants (including me for a few moments) in the open space session talked like they were victims of the process, which is why I wanted to kick the metaphor a little longer. Now that we know the names, now that we've identified the healthy state, let's work through it. It's kind of like the start of a 12 step program: admitting the problem.
Except, I won't go so far as saying it's a problem. It may work very well for organizations to feed bite sized chunks of product information through teams working in short iterations. This keeps teams from burning out and it does get things done (still way better than waterfall). What's missing, though, is a feeling of empowerment and engagement for the entire team.
Is being a scrum waiter an organizational thing or is it an individual choice? I will admit, that, as the new guy, I have sat back and observed. I'm working in a new language (yeah, only 8 months with grails too), the lead who hired me has left the company, and I'm experiencing a new development methodology. It didn't take me too long on Agile Day to come to the conclusion that I've chosen to be a waiter. It has served its purpose, giving me exposure to the process, time to absorb a new language and framework, and a breather to embrace the organizational change around me. I have to admit, I've probably even been a little purposefully dysfunctional about my waiter status by pushing all responsibility for prioritizing the backlog on my product manager. Rationalizing it with statements like, "he knows the business."
Now that I am cognizant of that sense of doubt--no... let's call it unease--about where I am in my maturity around scrum, I own the outcome. So, I'm going to start working my way through "med school." I'm not sure of the exact path, but I do know that I have more to contribute to the process than just writing the code. I'm starting to really internalize the product space, so I can begin to help dig into those areas, but I am, for sure, able to be more of an active participant in grooming the backlog and story planning to represent areas in which I do have significant knowledge and the ability to control, e.g., performance and architecture.
As I'm beginning to understand, a healthy scrum process probably expects me to be acting doctorly. So, choosing just to participate with a small pad of paper in my apron and a pencil behind my ear, I'll be the one breaking the rules, not the victim.
I am now in my 8th month at a company who is committed to using Scrum for their development process. I was a certified scrummaster a couple of years back, but my employer at the time didn't practice, so I let certification lapse. Between that employer and my current employer, I took a short stint at a software company that had some big quality issues which they'd asked me to come in and help solve. We didn't have the same view of what might solve the problems, so put a few things in place to help, but ultimately decided to let them get back to handling things without me. I have done a number of agile-flavored things in my career, but had yet to practice a formal agile method before this.
Now, I'm in my 8th month of practicing full-on scrum with a product team. There have been ups and downs, but they're neither as high nor as low as I've experienced at other places. It feels extremely sane, but I have been feeling, lately, like I just react to "priority." Admittedly, until yesterday, I hadn't been able to put a name to it, and, while I had a sense that something was off, I wasn't sure what.
I've wanted to work in an agile process for quite some time, why didn't it feel perfect? Things are working very well, we get our product work done, we meet our deadlines, so what could be wrong? When in an afternoon openspace session about the Doctor-Waiter metaphor, Hussman asks those of us sitting around, "So, are you a Doctor or a Waiter?" It hit me, "oh wow, I'm a waiter." That's what I've been missing.
Anyway, in that openspace session, we kicked the metaphors around and while people were in the process of torturing it, it occurred to me that there are good waiters too. In fact, I had a chance to eat at a great tapas place a few weeks ago in which a waiter guided us through the experience. Could waiter and doctor not be two discrete things, could they, instead exist on a continuum of maturity from waiter to doctor? So, my contribution to the metaphor torture was, "Considering there's a continuum from waiter to doctor, are we working our way through med school by waiting tables?" It got a couple of snickers, but we didn't explore the thought.
Here's what I was trying to get at with the question, just because we're being waiters, doesn't invalidate what it is. It serves a purpose. I am gaining my experience with scrum as a participant, but now that I know there's a higher purpose, I'll be working toward doctor status. Admittedly, my mojo isn't being completely fed or this metaphor wouldn't have resonated so well with me. Some participants (including me for a few moments) in the open space session talked like they were victims of the process, which is why I wanted to kick the metaphor a little longer. Now that we know the names, now that we've identified the healthy state, let's work through it. It's kind of like the start of a 12 step program: admitting the problem.
Except, I won't go so far as saying it's a problem. It may work very well for organizations to feed bite sized chunks of product information through teams working in short iterations. This keeps teams from burning out and it does get things done (still way better than waterfall). What's missing, though, is a feeling of empowerment and engagement for the entire team.
Is being a scrum waiter an organizational thing or is it an individual choice? I will admit, that, as the new guy, I have sat back and observed. I'm working in a new language (yeah, only 8 months with grails too), the lead who hired me has left the company, and I'm experiencing a new development methodology. It didn't take me too long on Agile Day to come to the conclusion that I've chosen to be a waiter. It has served its purpose, giving me exposure to the process, time to absorb a new language and framework, and a breather to embrace the organizational change around me. I have to admit, I've probably even been a little purposefully dysfunctional about my waiter status by pushing all responsibility for prioritizing the backlog on my product manager. Rationalizing it with statements like, "he knows the business."
Now that I am cognizant of that sense of doubt--no... let's call it unease--about where I am in my maturity around scrum, I own the outcome. So, I'm going to start working my way through "med school." I'm not sure of the exact path, but I do know that I have more to contribute to the process than just writing the code. I'm starting to really internalize the product space, so I can begin to help dig into those areas, but I am, for sure, able to be more of an active participant in grooming the backlog and story planning to represent areas in which I do have significant knowledge and the ability to control, e.g., performance and architecture.
As I'm beginning to understand, a healthy scrum process probably expects me to be acting doctorly. So, choosing just to participate with a small pad of paper in my apron and a pencil behind my ear, I'll be the one breaking the rules, not the victim.
Subscribe to:
Posts (Atom)