I got into the registration line at SXSW around 4:30 PM. It had opened at 3 PM, and I was warned that I might want to stay away for a bit as it was a bit of a madhouse. Much like at Disney, the line went pretty far back, and once you got into the main room, there was even more line to enjoy.

Thankfully, the conference was well organized, and striking up a conversation with the guys from Backupify made the time go quickly.

Here’s a quick clip of my time in line.

Other Posts That Might Interest You

1. ADS Wins Contact with SaySwap
2. Yay Google Is Helping Kill IE6
3. Business Checklist for Selling a SaaS Application

Robert Dempsey talks with Richard Sheridan, the CEO of Menlo Innovations, about his experience developing Agile teams, and building Menlo Innovations from the ground up to be an Agile organization. If you would like to have your company featured in the Agile Success Series please contact me and let’s talk!

You can find Richard on Twitter, and blogging on the Menlo Innovations blog.

Menlo Innovations is very open about their process. You can get a lot more information about it with these links:

Twitter:

http://twitter.com/menloprez
http://twitter.com/menloinnovation

Fun YouTube videos about the Menlo approach:

http://bit.ly/ckspAW
http://bit.ly/cCCpIo
http://bit.ly/br56uF

Other Posts That Might Interest You

1. Agile Development Demystified: Come Learn What They Never Tell You
2. The Failure of Do-It-Yourself Agile
3. Agile with Scrum talk at RailsConf 2008

I’ve got an idea for you. If you try this let me know how it works.

We’ve all seen the pictures of team spaces. Some are open spaces with a single, long desk that everyone sits at. Others are cube farms. The rest are typically some variation.

What I’ve found though is that someone in management determined how to group everyone. It might be by team, department, or some other means. But it was management that decided this.

What if we threw out that concept and let everyone sit wherever they wanted to?

I picture the same type of space you have now, only people can be free to sit at whatever computer they want.

Having a background in IT and experience setting up big corporate networks, I know it can be done. It’s called roaming profiles. It might take some time to be sure that everyone has the same applications, but it can be done.

Heck, you can even store TextMate configs in a git repo. You are using source control aren’t you? I thought so.

What I’m curious about is how people will self-organize at the group level, not just the team level. Who will they sit by? Will a dev working with a BA sit side-by-side? Will developers and designers sit beside each other while working on a feature?

I can imagine the speed at which collaboration could take place in an environment like this.

If you’re network is up to the challenge and you try this, let me know.

Other Posts That Might Interest You

1. Product Owners and Scrum Teams Can Get Along
2. Don’t Mess With the Team
3. Building Trust with the Agile Team

Due to travel to SXSW I need to move the Introduction to Kanban webinar to tomorrow at 2 PM EST. I’ll be broadcasting from sunny Austin, TX, and hope to see you there.

If you haven’t signed up for the webinar, subscribe to my newsletter to get the link.

See you tomorrow.

Other Posts That Might Interest You

1. Introduction to Kanban Webinar March 9th
2. Introduction to Agile for Managers Webinar Tomorrow
3. Introduction to Agile for Managers Webinar Slides

Aside from drinking coffee and traveling with my family, I have two passions in life – Agile, and Internet marketing.

My passion for Agile comes from my desire to help companies and teams find a better and more effective way of working, a way that is based on trust, collaboration, and enablement.

My passion for Internet marketing comes from the fun I’ve had for 3+ years of learning to market by own business through online and offline channels.

The Focus Of This Blog

Or perhaps lack thereof if you’ve been a reader over the years.

We’ve covered a lot of ground here, from Ruby on Rails and Java tutorials, to marketing, to management, to Agile. For a number of months I’ve tried to keep the focus of this blog to Agile, and based on how I’m listed on Twitter, I’ve done fairly well at that. And this blog is in addition to the Agile resources I have on my main company site, where I offer Agile coaching as well as web development.

The Non Marketer

So to keep that focus I created another blog where I keep all of my Internet marketing information and services – The Non Marketer. The purpose of The Non Marketer is to help small businesses and independents learn how to use Internet marketing to improve their businesses, all from a business person’s standpoint. On that blog I get to test out all the latest I’ve learned in the internet marketing world.

The Problem With Having A Split Personality

Both of these sites reflect different sides of the same me. But keeping up two identities is difficult. I spend a majority of my time reading and testing things out, and then posting about it. Each of these is a full-time job, and those of you who have met me, know I don’t sleep much (though there’s time for that later).

Is A Marriage Of The Two Possible?

In the spirit of kaizen – continuous improvement – I am looking for a better way. If I can marry the two worlds, I would be a happy man. It is that which I am struggling with right now.

The Roadblock

On the one hand, I love Agile. However, either the people I want to work with most – small companies – don’t have the money to work with me; or, they don’t know who I am, meaning my marketing efforts are ineffective. And though I have consulted for large companies before, getting into more large companies means I need to have big names in my belt that I can reference.

Internet marketing is an entirely different game. I know how to connect with people online, and currently have 3 students in The Non Marketer School. In addition, I can do this from anywhere at anytime, which brings an enviable freedom. And what’s even more fun, I’ve created Kanban boards for a number of the Internet marketing activities that I do.

I Need Your Advice

So, what’s a guy to do? I love both, and would love it even more if I could bring the two worlds together.

Many heads are better than one, and this is my plea to you for advice.

Please leave a comment below with your suggestions. I greatly appreciate it.

Other Posts That Might Interest You

1. Anonymous Internet Troll About to be Sued
2. Own Your Own Business? Then Your Job is Marketing
3. Inbound Marketing: Nothing Else Works

The schedule for the Agile Central Europe conference, being help April 8-9 in Krakow, Poland, has been announced,

The conference has two packed tracks plus an open space that lasts the duration. Talks range from agile retrospectives to kanban to management.

The lineup of speakers is fantastic, and I’m not just saying that because I am one. See for yourself.

And hopefully I will see you there.

Please help us promote the conference by voting up the conference schedule announcement on DZone.

Other Posts That Might Interest You

1. Visit Europe and Get Agile at the Agile Central Europe Conference
2. Agile Central Europe Early Bird Registration
3. Acts as Conference 2009 Is One Week Away

This guest post was written by Matthias Marschall, Co-Editor of Agile Web Operations, a blog that helps web developers and operations bridge the deployment gap.

You’re used to agile software development. Fast feedback loops, non-bloated specifications, and well-defined acceptance test criteria speed things up and reduce the risk of building the wrong product. Your developers really work closely together with their clients and users to build great software. They even demo their progress regularly to them. But what happens if the client is thrilled with the demo and wants to see the software in production?

System Administration Is A Silo

In most companies the doors to the data center are the place where agile ends. From there, the sysadmins reign. They hate change as it jeopardizes the stability of the systems they are responsible for. They run a closed environment where you can drop in some app and hope they get it running. And if something goes wrong, the blame game begins.

DevOps – Bridging the Deployment Gap

It’s a real problem for a company if their value stream – the complete process from idea to running product – isn’t user-centric end to end. It’s great to use agile for the first half of it (specification and development), but, if the second half (deployment and operations) is not working customer oriented, the whole process is badly flawed.

The good news is: Agile ideas are slowly conquering the data center, too! Sysadmins start to see the benefits of agile practices and want to apply them to their areas of responsibility. This is where the idea of DevOps comes in. DevOps is a set of ideas and tools rooted in Agile Software Development principles and practices. Just as agile development gets the client and developers working more closely, devops helps system administrators and developers work together for the good of the company and its customers.

Learn More

If you want more ideas on how to extend the reach of your agile practices to the data center, check out these DevOps thought leaders.

Other Posts That Might Interest You

1. NFi Is Looking for an Agile PM / ScrumMaster
2. Scrum Alone Does Not Good Software Make
3. The Agile Coach as Anthropologist

I have a Twitter search for the term “agile” in my RSS reader. As you can imagine, I see hundreds of tweets each day – some on topic, some not so much. Some of what I see really ticks me off. And that it what this post is all about.

Why is it that we seek a silver bullet to magically solve all of our problems?

Why is it that we look to find that one system that we hope beyond all hope will cure the woes that have built up over time in our companies?

Much of the disfunction in existence in companies today – lack of trust, communication, and a clear vision – didn’t happen overnight, yet we expect things to turn around on a dime? But it must exist! That one system that will bring the eureka moment. From watching my Twitter stream there are people out there selling THE cure. And they’ll be damned if you tell them their cure isn’t for everyone. And you know what? People are buying, because they believe it will help them. And it might, but for many it won’t. And I’ll tell you why.

Here’s the kicker, the wrench in the works – any system implemented without taking the context in which it will be implemented into account is doomed to failure.

But that’s what people are doing. And they encounter failure? I’m not surprised, only saddened.

Let’s look at Scrum for a second. I see Scrum as a framework, which is how the Scrum Alliance defines it (a number of pages into the site though – why is that?). Framework is defined on Wikipedia as,

… a basic conceptual structure used to solve or address complex issues, usually a set of tools, materials or components. Especially in a software context the word is used as a name for different kind of toolsets, component bases, then became a kind of buzzword or fashionable keyword.

Please draw your attention to the first part of the definition – a basic conceptual structure. And by definition, a structure,

… defines what a system is made of. It is a configuration of items. It is a collection of inter-related components or services. The structure may be a hierarchy (a cascade of one-to-many relationships) or a network featuring many-to-many relationships.

Nowhere in those definitions does it say that a framework or a structure is inflexible or perfect, and must be taken 100% as-is.

But that’s what’s happening. And though I’m incredulous, I’m not surprised. It all goes back to us wanting the silver bullet – we want to be told exactly what to do.

We want this because it takes the responsibility off of us and put it somewhere else. In this case, Agile methods like Scrum.

But I’m not here to relieve you of responsibly implementing change in your company. I’m not here to relieve you of your responsibility to break down the barriers of communication so that business and IT are aligned so that business objectives can be met. I’m not here to tell you that I have the one true way that will make everything better and can help you implement it.

I’m here to help you understand that there are a number of tools at your disposal that can help get things back on track, and that those tools will bring change. And that change doesn’t have to be scary, threatening, or dramatic. It can happen over time. And it will take your context into account, rather than being a blind devotion to what someone wrote in a book or posted on a blog.

Agile methods such as Scrum, XP, and Kanban are flexible systems that can be tailored to help solve business problems.

But if not being blindly devoted to the one true way means that you aren’t “being Agile,” then you have my permission to not be.

Other Posts That Might Interest You

1. Top 5 business benefits of agile development
2. Leave the Agile Manifesto Alone [Rant]
3. If You Don’t Focus on Business Value, Don’t Adopt Agile

With Scrum projects, we have a few units of measurement. User stories, or features, are measured in story points, a relative estimation technique. Tasks are measured in hours. User stories can be estimated well in advance of the actual work being done, and do not depend on the team member performing the work. Tasks are estimated during sprint planning, and are more dependent on who is doing the work. So how do we use these to provide metrics for projects using Scrum?

The end-all-to-be all metric is velocity. Velocity is the number of story points a team is completing each sprint. We use velocity for forward planning. One argument I’ve heard against velocity is that a team needs a few sprints to determine their velocity. I’ve found this to be true, and not too difficult to explain to management. It’s much easier if your cycle times (sprints) are shorter. We develop in one week increments.

Another metric is the number of hours it’s taking to complete tasks, or as a ratio: actual:estimate.

And one more item we can track is impediments – how many impediments are showing up each sprint, how many are we overcoming each sprint, and how many come up over and over again (showing perhaps systemic problems in the organization).

With all of these, the point is to improve our estimates over time. Kaizen – continuous improvement – is a continuous goal in Agile.

But I can’t help to feel something is missing. Are there only two things we can track on Scrum projects?

Nope. There are many more.

Borrowing a page or two from Kanban, I propose that we can use the following additional metrics on our Scrum projects:

• Quality – number of bugs opened and closed per sprint
• Cost – the amount of money it cost to produce a feature or user story
• Lead Time – the amount of time it takes a feature to go from planned to implemented
• Feature Complexity – if you are breaking features into stories, you can measure how many stories it takes to complete a feature

What other metrics are you using on your Scrum projects?

Other Posts That Might Interest You

1. Managing Agile Projects is Now Easier with Scrum’d
2. Scrum’d Updates and Roadmap
3. Product Owners and Scrum Teams Can Get Along

Earlier this week I attended David Anderson’s Kanban Coaching Workshop in Miami. It carried a hefty $3000 price tag. In the end, the value I gained was well beyond what I paid. Not only did I have the chance to learn from a guy who is working to change an industry, I got the chance to meet a group of people that are helping to fix systemic issues inside of their companies.

But that’s not the greatest value I received.

The biggest thing I got out of the workshop was that I need to go way beyond the world of Scrum I’ve been living in. I need to add an entirely new vocabulary if I am to be as effective as I can be in helping dig teams out of the holes they’ve been dumped into. I need to take into account a greater number of factors when dealing with executives, and act more deliberately and thoughtfully than ever before. And finally, I need to expand my body of knowledge both in project management and psychology.

What I received was a paradigm shift, that will fundamentally change the way I approach project management and working with teams.

And that, is worth much more than I paid.

If you’re interested in learning about Kanban I’ll be doing an introduction to Kanban webinar in a few weeks. Space is limited to 100.

Other Posts That Might Interest You

1. Introduction to Kanban Webinar March 9th
2. I Will Meet the Enterprise And My Tool Will Be Kanban
3. When Will IT Be A First Class Citizen?