Author Archives: Daniel Markham

Culture is Corrosive

I’ve been trying out the local coworking scene for the past month, and I’ve really enjoyed it. Thursday I had lunch with the woman who is responsible for putting all of the pieces together. I had a lot of fun talking about startups, entrepreneurialism, and financing.

We reached the point that I’ve seen many times when talking to local folks about startups. The “Silicon Valley” moment.

“People say that we couldn’t be another Silicon Valley, but I don’t believe that,” she said, “we could make it happen here”

This made me both very sad and happy at the same time. Sad: we have a better chance of teaching pigs to be ballerinas than creating another Silcon Valley in sleepy little Southwest Virginia. Happy: it’s a worthy cause, and even by “failing” we could end up helping a lot of people. Sign me up, coach!

I tried to explain these things, but probably did a very poor job of it. I told her about Y Combinator, how it now has thousands of folks who have gone through their training. Many of them are still in the area and they all help each other out. I talked about how SV success stories are usually willing to take their time to try to help the next generation out. They’re not in it just for the money. There is a spirit of cooperation. I talked about how “failure” is not a bad thing: people work hard and stick with an idea until it either works or they pivot. I talked about how people share and support each other because even the success stories know what it’s like to be plugging away at something that doesn’t appear to be working. I mentioned how tough it was for people who did well in one startup to recapture the magic — and how that was okay. I told her that both chance, preparation, and tenacity play a big part in startups, perhaps chance more than preparation and tenacity, but you had to have all three. About how important the team was compared to the idea.

There’s a lot of things to understand about startups. I kind of felt like a parrot. All I was doing was repeating what I’ve heard much better people say.

But then I hit it, a way of capturing this huge hunk of important information into something more like a slogan. Culture is corrosive.

You take somebody just out of school who doesn’t know any better. If they’re in a team of friends who are able to execute and stick it out, they have the greatest chance of success. Why? Because they don’t know any better. They’re not indoctrinated in what “winning” and “losing” looks like. They’re willing to try anything. They understand sharing and how being open and sharing with each other helps everybody out.

Take those same guys, put them in a corporate job for a few months? It’s like night and day. Suddenly “work” and “life” are two different things. You’re not supposed to like work, you’re supposed to want more free time. You have your team and other people have theirs. You don’t help the other guys. You measure success in dollars. There are rules and ways to do things. You stick to these in order to reduce or eliminate risk.

Culture is corrosive. When we talk about forming new Silicon Valleys, there’s a lot of things to get our head around, but this is the big one. This is the enemy we fight. Culture is corrosive.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Weight Loss 2 – The Roux En Y


You just know that’s going to hurt



My journey towards bariatric surgery as a way to control my weight has been steadily moving along. It’s taking a lot longer than I had imagined!

We finally have a surgery date, though — June 5th at 8am.

For two weeks prior to that date, I’ll be on a liquid diet. The doctor says it’s important to do this in order to shrink my liver. Turns out he’ll be doing a lot of work behind my liver, and in some cases the liver can be so big he can’t get his work done.

It’s a pretty incredible piece of surgery if you think about it. It’s called a “Roux-en-y“, and what they do is 1) chop off most of the bottom part of my stomach and sew it closed, 2) connect the tiny remaining stomach into the small intestine a good ways down from the stomach.

This does two things. It decreases the size of the stomach dramatically, and it prevents your digestive system from absorbing all the nutrients you send it.

As you can imagine, this is a pretty big deal, and I have spent quite a bit of time thinking about it. It is definitely not a decision you make lightly. I chose the best doctors I could find within 700 miles or so, and i have a 4-hour drive each time I go see them.

After the surgery things will be much different. It’s not a magic bullet. In fact, once you are physically prevented from eating so much you can easily end up in depression. It’s a completely new way of living. Or as the nurse told me last week “Your eating is going to get pretty boring for a long while”

I’ll keep the reporting going. A grand adventure awaits.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

It’s All Bullshit

One of the key indicators of reaching mastery level in any field is realizing that’s it’s all bullshit — and moving forward anyway.

Take one of my fields, technology development, as an example.

Did you know that 70% of all IT-related projects fail to meet their objectives? Or that Winston Royce was the man that created the waterfall development model? Or that the military uses “command and control” to tell soldiers what to do? (and that this is a bad thing) How about that Use Cases are going to destroy your productivity?

These factoids, and many more, are commonly used in presentations dealing with technology development.

And they’re all bullshit.

Success and failure as measure by the 1994 CHAOS study, is a relative thing. Winston Royce never wanted people to use the waterfall method; he was just describing sequential activities. In fact, he said you should iterate through again. The military, especially ground combat units, give most operational responsibility to people on the ground engaged in combat, not generals — exactly the opposite from what a non-military person would think. Use cases are a form of process analysis, not a huge MS Word document template to be filled out. As a form of analysis, you can complete them with any level of formality or documentation you like: lots of meetings and paperwork, or a napkin and a 15-minute conversation over lunch.

It was a recent conversation on Google+ that got me thinking of this. Internet friend Laurent was complaining that the statistics used by academics discussing technology development were bad, mungled, and meant nothing. He seemed very upset that such arbitrary numbers could be used.

This piqued me, because I never thought of academics (or any other thought leader) in the technology development arena to be doing anything more than quasi-informed guesswork. And that was fine with me. But to Laurent it was very disturbing.

One of the things I’ve learned as I’ve gotten older is that there’s theory, then there’s the real world. In the real world you can use any kind of theory you’d like. Just pull it down, apply it, and see if it works for you. Keep what works. Throw away the rest. But you can’t focus on the theory. You always have to focus on pragmatism: is this working for me right now. It’s this two-track approach, where academics and other thought leaders scope out a possible path forward, then millions of us try it out in practice, that slowly moves us forward.

Most things we do are not physics. We don’t need a theory of life, the universe, and everything. We have work to do. These things do not exist in the absolute, easy-to-digest way we might want them to. We need a solution to the problem we’re working on right now.

Some people just give up on all theory — all they want is results. Some people, many times without realizing it themselves, start focusing on how things ought to work based on their pet theories without looking at how it’s really working. Confirmation bias is a powerful thing.

People screw up when they focus either too much on how a few teams worked or how the theory works. You need both tracks.

But this is true in many more areas aside from technology development. There are things we can do that work most all of the time, there are things that are going to be highly contextual, and there’s the system of common understanding about why things work they way they do. These are completely different areas!

So yes, at some level you realize that, heck, even physics isn’t physics. Physics has many more unanswered questions than any sane person would be comfortable with. The soft sciences are a lot more soft than you were taught, and that evolutionary behavior theory sometimes can amount to a lot of speculative bullshit while hand-waving than the TV science shows let on.

But then you realize that it’s this way everywhere else too. And you move on. After all, you have work to do.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Why I Finally Joined Mixergy

I’ve been looking at the mixergy site for a year or two now with a jaundiced eye. Mixergy is a site created by Andrew Warner, self-made millionaire. Its goal is to have a site dedicated to people forming their own startups. It’s a fee site. You can pay so much every month or an annual fee.

The reason I’m so skeptical? 1) Everybody and their brother wants to charge me for making my startup awesome. By painful experience, most of these sites and applications do not live up to their hype. 2) Andrew seemed like a nice guy, but, frankly, another rich guy with a successful startup wanting me to join in on his next successful startup didn’t seem like so much fun.

But I have changed my mind.

Why?

As it turns out, this is a good lesson for all startup founders.

Warner has been doing interviews of other founders and people in the startup community for a while. Every time he does an interview, he sends it out free to community. But if you want the older interviews and content, you have to join the site. So every so often, the people on his site consume his content and share it. That means I’ve been constantly exposed to his work.

Eventually, every now and then, I’ll click over and consume the content. Each time I do that there’s a small chance I’ll look around.

After a year or two of coming over now and then, consuming content and looking around a bit, I decided to take a look at his interview archives.

Jiminy Cricket! There’s almost 700 interviews in there. While “getting rich quick from your startup” has been done to death, 700 hours of interviews with successful founders is something I’d really like to take in. Even if their advice never directly makes a difference in their startup, just listening to their stories can help me get a better sense of context for where I am in my startup. And that’s worth money.

But the bigger takeaway? It’s one thing to have an idea and chase after it for a while. People see what you’re doing and say “That’s interesting, but are they really serious? I don’t think so”

After a while, though, it starts sinking in to potential customers that you’re not going anywhere. Then they start taking your seriously. For transactions involving money, just being out there isn’t enough. You have to be committed.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Dividing My Internet Content

The more I see of how the internet works, the more I want to totally control my own content. While I enjoy many places like Facebook or Twitter, the people who run these “walled gardens” are selling one thing — the stuff we all create every day. That’s what draws in other members, that’s what gives them places to sell stuff, that’s what search engines use to bring people back to their site later.

And while any particular piece of content you or I might produce averages about one-thousandth of a penny in worth, it adds up. There’s also a normal distribution curve: on average content is worth mostly nothing but every now and then one of us might write something that has several dollars, or even several hundred dollars, of value. And it’s all owned by somebody else.

I don’t mind sharing, but more and more I’m feeling used by these clowns. So I’ve decided to do something about it.

I’m slowly creating web properties that represent the things I like to post online. My diary, of course, is here. There’s my funny pictures collection. (needs more cats), my Agile coaching and practice information, and now my summaries of libertarian news stories and commentary.

There’s no master plan here, aside from my wanting more control over what I create and collect. I guess that’s enough of a master plan for now.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Why I’m Leaving My Home Office

When I’m not helping a large client, I work from my home office. I’ve been working this way for around ten years.

Today I’m leaving my office for a while to try coworking.

Why would I leave the comfort of my home to travel an hour to the nearest town to work with a bunch of strangers?

Productivity, that’s why. Random human encounters, being around other people working, the social atmosphere of an office — all things you don’t find in a home office.

It occurs to me that if co-location is so good for Agile teams, it might be good for sole founders as well. And in this business, there are no universal rules, only what works and what doesn’t work.

So for the next month or so, I’m going to try coworking.

I’ll let you know how it goes.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

No, You Probably Can’t Work Remotely

Agile sucks when it’s about stuff you don’t like. Just ask the guys at Yahoo.

The good news is that there is no “standard” Agile. It’s best practices around iterative and incremental development. We write books and list out a bunch of stuff, people try them all, and we compare notes. Somethings apply most all of the time, so we keep those. Some apply every now and then, so we keep those too — but keep them in our back pocket. We’re always just interested in what works for us, right now.

The bad news is that a lot of stuff that works most of the time is stuff we might not like. Being an old dinosaur, I was never a fan of TDD. Didn’t care much for fluffy charts on the wall, or playing with crayons and glue again. Did enough of that in kindergarten. This thing where you get together standing up every day seems the height of lunacy. Why not just talk like normal human beings?

It turns out we do a really bad job of trying to figure out ahead of time whether something works or not. Many times when we don’t like something, we just don’t try it. Or we try it a little bit and then give up on it without “getting it”.

Which brings me to the number one thing that we’re finding in Agile that works most of the time but people don’t want to hear about: co-located teams.

Everybody and their brother wants to work remotely, you know, in their pajamas. And it’s slowly turning out that for many types of technology work, distributed teams aren’t going to cut it.

Yahoo is bringing all their remote workers back. Startups have long found that their odds of success are dramatically multiplied when they are physically together. These aren’t just business opinions, these are moves in the marketplace that we’re seeing from groups that succeed.

Big business is still trying to crack the nut of offshoring. Yes, it’s possible, but you always end up either breaking the work up in to such small pieces as to have done it yourself, or training up a bunch of experts in how your company operates who don’t work for you. Either path is problematic.

If you think about it, this makes sense. If you are working without a lot of interaction, it’s either because you have a job that’s minutely-defined or you are an expert in this customer, this domain, and can work with little interaction.

But wait! I can hear you say. We HAVE tools for remote work. Chat, Skype, and so forth. We have TONS of tools!

Here’s where it gets a bit tricky, and remember that I’m only trying to reverse engineer why we’re observing that it doesn’t work. I don’t have all the answers.

Technology development — indeed much of human existence — is a social construct. It’s about people, personalities, relationships, teams, and so forth. The technology and the problem have little to do with anything. “Give me a good team,” the saying goes, “and I can do most anything”

Lots of truth in that.

What we want technology development to be about, however, is moving bits of data around. I have a list of requirements in Excel. We have a project plan on the web. I can chat with you online to explain the way this code works.

Our working theory, mainly because we’re all bit-heads living in the digital age, is that with the correct bits flowing the correct way, things happen. So “friends” on facebook are kinda like friends, but kinda not. Email is kind of like having a conversation, but kinda not. I “know” Joe because we follow each other on Twitter, but not really.

Agile technology development, where you are changing the nature of how you work and the definition of success dynamically, has almost nothing to do with bits of data. So it’s not like having a video conference, or emailing a specification. It’s like making real friends, with real strengths and weaknesses, and learning to use each other’s characters in something greater than the sum of the parts.

There’s not an app for that.

I like Agile when it tells me things I want to hear: project management doesn’t have to be dull, endless meetings, we can work faster the closer we work with the customer, and so forth. I don’t like it so much when it tells me things I don’t want to hear, like in many situations I have to be sitting in a room with the rest of my team instead of in my pajamas.



I saw something a month ago I want to share.

I was observing a team of 8 people from across the hall. I couldn’t hear what was being said but I saw one them stop working and look confused. He looked around the room. Everybody else was busy. So he went to the flipchart and started sketching out his problem for himself. When I looked back a minute later two of them were working around the flipchart, the second guy pointing out things to the first guy.

For many minutes everybody else kept working, many with headphones on. Then one guy got to a stopping point, looked up, and saw the conversation. He gets up and walks over. Now there’s three guys talking and drawing.

They talk for a bit, then there’s four, then five people, all around the flipchart, all working on a solution. The fifth guy was interesting. He stands by the chart for a bit, then realizes the conversation is not for him, so he goes back to his work.

They reach a conclusion and everybody goes back to their seats except the first guy, who stays to make sure he’s captured the results.

This all took place in about ten minutes. No meetings planned, no time waiting around for introductions, no stop in the flow of work, no having to bring somebody else in, no hanging threads, no pre-planned agenda, no figuring out who to invite. Just a bunch of people working together organically, naturally.

An hour later they all went out to lunch together.

I don’t know how you do something like that electronically.



the commenting system is currently down. If you would like to comment, send me an email and I promise to publish your comment unedited

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile for Familes

One of the cool things about Agile is how it is a blend of several different disciplines — sociology, applied psychology, sales, marketing, branding, team-building, structured analysis, and so on.

This is also the toughest thing about Agile: it’s not a solid set of principles. It’s best practices around iterative and incremental development. And “best practices” will change over time and in different circumstances. That means that we’re constantly trying out new ideas and seeing what works and in what kinds of situations.

In fact, that’s also the coolest part of Agile. Agile is a community of learning where we’re always trying new things in different situations and reporting on whether they work or not. One set of folks comes up with a big set of best practices, the community tries them out, people publish their lessons, then we all learn.

I thought about that today — the good and bad parts of Agile — as I read about Bruce Feiler’s “The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More

Bruce has gone into the Agile community and used some of our best practices to apply to family life. Things like a stand-up, or goal-setting. He’s also done a high-level review of a lot of self-help stuff from all kinds of disciplines.

There are folks who might call such books facile — simplistic, formulaic pablum for people wandering from one self-help book to another.

I think if you view these kinds of books as somehow holding the answers to life, the universe, and everything, you’re probably right. But that’s way too high of a standard.

Life’s a buffet, not a Happy Meal. You get to try new things and see what works for you. Looks like Bruce has done a lot of the legwork in putting various ideas together for you and your family — some from Agile, some from other places. Try some, see what works for you. Perhaps then you can write the version 2.0 of this book; ideas that work most of the time with most families. And that’d be a good thing for the rest of us.


ADD: For those of you who are interested in hearing more about the book, I came across Bruce’s book through this NPR story that a friend shared on G+.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Good Coaching Means Being an Example

In the Agile coaching game, many times we coaches work as close as we can to several teams at one time. We’re there to provide structure, feedback, and a mentored learning environment as teams move to more agility. And of course, like any consultant, we’re paid smart friends. The client’s needs come ahead of our own.

But the goal is for the teams to become more Agile: to work better, faster, and have a happier work life and life balance.

So I was wondering how to handle a question we received a few weeks back. A friend and I were doing some Intro to Agile courses, and during one of the free-form discussions somebody flagged me over.

“So which is it?” he asked, “You told me we were supposed to have the sprint close, retro, and sprint planning all in the same day. This other guy says you split them up.”

He pointed at my friend. He was clearly frustrated.

I looked at my friend. I felt that the advice he was giving was not-so-good, but it was also important not to argue randomly in front of the client. On one hand I felt we were going the wrong way. On the other hand if we were to make the training too chaotic, nobody would get anything out of it.

“Hey, i do it this way,” I said, “and here’s the reasons”

“We’ve always told them this other way,” my friend said.

My friend and I kinda looked at each other. Both of us wondering: are we going to get into a long, boisterous discussion here? Is this the place?

So I looked back to the guy. I said “Look, I still feel my way is better, but it’s not that important thing. I like strawberry ice cream, you like chocolate. Let’s do it the way it’s always been done and see how it goes. We can always adapt later.”

There are a lot of coaches that would have a problem with this. Every little thing they coach is terribly important, and it must be done a certain way.

I’m not one of those people, and more to the point, when we coach we need to be an example. Do we want our teams full of people who either a) disagree all of the time and refuse to back down, or b) are so apathetic they can’t have an opinion on anything?

Of course not. And so we shouldn’t model that behavior. We should have “fierce opinions, lightly held” — be willing to explain and advocate, at length, why we feel a certain way. But never let that get in the way of things moving forward or the spirit of the team. Keep perspective.

I think a lot of time coaches (and the rest of us) get hung up on the details of coaching and forget the purpose of coaching.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Weight Loss 1 — The Decision

I’m going to take my blog and keep track of my weight loss journey. I know, I know — it’s not technology, management, or humor, but it’s my blog and I get to do what I want!

:)

As many of you may know, I am a bit overweight. By “a bit”, I mean the doctor said I either had to lose weight or capture an asteroid in my gravity well so I could be declared a planet.

It’s something I’ve struggled with over the years. Tried all kinds of things to help.

After continued failure, I’ve decided to look into bariatric surgery. You know, where the doctor rips your stomach out with a fork. In this fashion, without a stomach, you find it difficult to eat, so you lose weight.

I did a lot of research, and traveled several hours to Northern Virginia yesterday to meet with a doctor. As it turns out, it’s much more complicated than I imagine. They don’t actually use a fork.

Instead, there’s this involved process of tests, double-checks, counseling, and so forth to give this thing the best shot possible. After an initial consult, I was given a list of about a dozen things to do — including an endoscopic examination which requires sedation — just to go to the next step, which is planning for surgery.

There are a lot of pros and cons to having bariatric surgery, and it’s not something I do lightly. One of the guys yesterday asked what my goals for being there were, and I said “To save my life” So, as much as I joke, to me this is a pretty serious situation.

I hope to use this blog to describe my journey.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.