Need training, coaching, or help leading an agile transformation?
email: mike@cottmeyer.com or call: 404.312.1471

Monday, June 28, 2010

Ro-Sham-Bo... Shoot!

I had a fun experience last week that I want to share with you guys. It was my first week with an awesome new client. The plan was to start with two days of general agile training, followed by a day of release planning workshops, and then iteration planning. Once the team starts sprinting, I'll come back for a day a week to do a little coaching, and to help keep everything on track. All in all, a pretty standard engagement.

This team has a solid product vision, and a pretty good understanding of their features and needs. The features and needs were pretty easily translated into high-level, value driven epics. We spent some time breaking down the first set of features into finer grained user stories. Because the team was new to agile, and really had no idea of their capacity, we took the extra time to break their user stories down into tasks.

Okay, so you guys know the drill. User stories get estimated in points, tasks get estimated in hours. We decided to use the Fibonacci series for the user stories, but the team wanted to use a binary sequence for estimating task hours. I'm okay with either... and since it's really not my call... we went with binary. The only problem was that we didn't have enough binary planning poker cards so that the entire team could get involved. We had to get creative.

The ideas came quick, but what we ended up with was a version of the old rock-paper-scissors game. Someone realized that each of the allowable estimate values, could be represented as a single digit, using a power of two...

1 = 0
2 = 1
4 = 2
8 = 3
16 = 4
32 = 5

...and, we could each vote with one hand by throwing the exponent, rather than the entire estimate value. Only, in a room full of software developers would someone come up with that. It was elegant... it was geeky... we could do it without supplies... so we went for it.

Since there was no way to hide your estimate using fingers (say, by putting the card face down on the table) the developer leading our session introduced the rock-paper-scissors idea. But... rather than saying rock-paper-scissors-shoot... he went with Ro-Sham-Bo-shoot. I had never heard that version, but once again... it was funny... it was geeky... and the team loved it... so it stuck. Each time, after they talked about a task, someone would look around and ask... 'rochambeau' ?

Once everyone agreed... they played their hand... literally.

It was an awesome... fun... emergent experience, and we came up with a new approach that I am sure I'll want to use with other teams. The estimating went really fast, faster I think than messing around with physical cards. Either way, it was a great team building experience. It was a creative and effective way of playing planning poker. I'm curious if anyone has every played planning poker this way? Is it documented somewhere?

If you happen to be interested... here is a link to the Wikipedia entry for Rochambeau.

http://en.wikipedia.org/wiki/Rock-paper-scissors

The Urban Dictionary had a much more colorful explanation... this one made me laugh out loud.

http://www.urbandictionary.com/define.php?term=ro-sham-bo

Give this approach a try and have some fun with it!


Subscribe to Leading Agile

Sunday, June 20, 2010

Interesting Post... 6/14/2010 through 6/20/2010

Okay... so get this. When I go to my Google Reader feed and look at all the stuff I've shared over the past week, I get one list. When I go to my Twitter page and pull all the 'Interesting Post..' articles I've shared over the same time period... I get a different list. There is some overlap but neither is a subset of the other. My guess is that what I've actually shared over the past week is a superset of both lists. Oh well, again... maybe one day I'll spend some time trying to figure out what's up. Either way, this is a pretty good list of all the stuff that I noodled through over the past week.

Hope you like this week's installment of 'Interesting Post...'.

Corporate stuff http://bit.ly/caURkK

PMBOK, Agile, and Some Tips http://bit.ly/bA10TB

Connecting the Dots to PMBOK http://bit.ly/aQXo1w

Are things getting to complicated? http://bit.ly/93cV9r

8 Habits of Highly Excellent Bloggers http://bit.ly/cnIbX5

Getting Ahead, Really? http://bit.ly/cSG3D1

8 Transformational Leadership Lessons From Seth Godin http://bit.ly/dcdLxA

Stop Whining and Get Started! http://bit.ly/aWtuJZ

What Does It Mean to Be Agile? http://bit.ly/daoMJc

Using Agile To Scale Agile – Part 1 http://bit.ly/cbMJ3M

Fridays Digest #18 Scrum vs. Kanban http://bit.ly/968w3L

The Pepsi Challenge of Waterfall Agile or Kanban http://bit.ly/clDBr7

Agile in Everyday Life http://bit.ly/8ZJNly

Your Software is not a House http://bit.ly/a98OPH

Scrum and the PMBOK http://bit.ly/daxNlc

New to agile? Learn how to fail well http://bit.ly/d6wVj3

The Context Machine: The Essence Is Context http://bit.ly/adHbT3

T-Shaped People http://bit.ly/92aQK9

Change Without Motivation http://bit.ly/c7amuo

Come Play Innovation Games for the Agile Developer Skills Project! http://bit.ly/c5omCk

ScrumMasters Now Earn More Money Than Project Managers http://bit.ly/92ahVw

Kanban: What are Classes of Service and Why Should You Care? http://bit.ly/aodC4t

The Oath of Non-Allegiance http://bit.ly/91Pxhh

Your Product Is Done http://bit.ly/dmn9aT

And as an added bonus for making it all the way to the bottom of the post... here is my last update from summer camp. I am home now, we came back yesterday, but the last night I did an update was Thursday. I feel a little guilty for not doing one the last night, but I got back to camp late and we had a campfire to go to. Anyway... this is Day #5... Family Night!

Subscribe to Leading Agile

Wednesday, June 16, 2010

Let's Define Our Starting Place

I'm telling you guys... if you're not participating over on the AgilePMI Yahoo! Group, you are missing out on some great conversation. Think about it... this is THE issue going on right now impacting the agile community. We talk about agile and transformation... but the traditional establishment holds the keys in most of our organizations. Unless we can show them how to transition safely, we are relegated to bottom-up, grass roots agile initiatives... most of which have a very low probability of making any kind of meaningful difference in our companies.

That said, one of the problems I think we have... not just on the Yahoo! group, but as a community in general, is that we often talk past each other on pretty key issues. I was going back and forth with Dan Mezick and Dennis Stevens on the idea of team authorization. All of a sudden it dawned on me that Dan and I agreed in principle on where we wanted to take the organization, but Dan wanted to discuss the organization as it should be... I wanted to talk about the organization as it was, and how we can be successful in it.

It seems to me, that in any conversation, we have at least three possible starting points for debate:

1. The current state
2. The future state
3. The transition state

My guess is that most people in the group agree that something is wrong with the current state of software project management. That is why they spend time reading and posting and exploring how to do things differently. I'd also guess that most folks in the agile community agree on the ideal end state. We might have some differences of opinion around Scrum or XP or Lean or Kanban, but I think we all value the idea of empowering teams, respecting individuals, and helping organizations deliver the most value possible.

Some of us are so passionate about the way things should be, that point of view becomes the starting place, and they argue for change right now. Others of us have heard those messages and found that they don't resonate given the current regulatory climate in our companies. These people want to talk about what they can do today... without some sort of massive transformation. They don't have any clear way to make the kinds of changes that the 'future state' people are advocating. Others, like me, want to talk about how to get from point A to point B as safely as possible.

Understanding the point of view from which the other person is arguing from can be really valuable as we're trying to move this discussion forward. I hate seeing us run in circles with each other when there is probably more we agree on than we really think. The futurists hold the vision, the today people have the current reality, and the transition folks want to find a way to bridge the two. Maybe if we can start our conversations by clearly stating our starting point... and have more meaningful discussions around all three different viewpoints... we might have a way of moving this thing without constantly going around and around, without ever really increasing our understanding.

By the way... here is a link the Agile PMI group if you are interested in joining the conversation:

http://finance.groups.yahoo.com/group/pmiagile/


Oh, by the way... here is day #3 and day #4 of Summer Camp... have fun!

Summer Camp Day #3



Summer Camp Day #4

Subscribe to Leading Agile

Monday, June 14, 2010

Fundamental Attribution Error

Anybody ever heard of this phenomenon? Here is the definition from Wikipedia:

In social psychology, the fundamental attribution error (also known as correspondence bias or attribution effect) describes the tendency to over-value dispositional or personality-based explanations for the observed behaviors of others while under-valuing situational explanations for those behaviors. The fundamental attribution error is most visible when people explain the behavior of others. It does not explain interpretations of one's own behavior - where situational factors are often taken into consideration.

When we talk about methodology and roles, how often do we attribute to the methodology... or the role... some sort of evil bias? How easy is it to dismiss traditional project managers as command-and-control, when in reality, these people are doing the best they can, given the situation in which they find themselves? Do we acknowledge that these people are only doing what the organization expects of them?

How often do we give a failed Agile project a pass, maybe on the basis that they 'tried' or were 'fighting the good fight', but view every failed waterfall project (and the traditional project manager running it) as incompetent? Do we ever acknowledge that people in these projects might just be playing the hand they were dealt? Working within the system they were hired to support? That the very structure of the organization around them accommodated no other way of moving forward?

If we want people to behave differently, we have to be able to influence the systems that are driving their behavior. I'm telling you guys, much of what we talk about in the agile community does not play well in the environments where many traditional project managers find themselves. Company culture and organizational structure drive behavior. Until you address those fundamental structures, meaningful change will be hard to come by.

The problem isn't the people involved, or even the leadership... the problem is the system in which those people are operating within. People want to be successful, but if the system around them is not conducive to empowerment and self-organization, people are going to change until the system changes. Authorized teams, without the appropriate organization to support that authorization, will expose both the company and the individual to an unacceptable level of risk. We've got to acknowledge that risk and help people deal with mitigating it.


(Those last two sentences were for you Dan!)

More scout stories from our brutally hot week... I think my 14 year old son has gone insane... Watch out... this clip is PG-13!


Subscribe to Leading Agile

Sunday, June 13, 2010

Interesting Post... 6/6/2010 through 6/13/2010

Okay... so this has been one HOT Sunday afternoon. Today is the first day of Boy Scout camp... our annual trek to a really HOT and humid place to spend the week living outdoors. It was about 96 degrees today and probably about 96% humidity. I smell like a barn animal, there are showers, but that squeaky clean feeling DOES NOT last long.

Fortunately, there is an administrative building up the dirt road that has AC and Internet access. I'm going to try to get some writing done tomorrow while the kids are out working on merit badges. I hear they have a coffee pot too. If you are interested, scroll down to the bottom of this post for a little video log from our days adventures.

Enjoy this week's installment if Interesting Post...

Your Product Is Done http://bit.ly/dmn9aT

Silly Saturdays: Mac vs. PC http://bit.ly/cGd2ve

The Reality of UI Test Automation http://bit.ly/9Oi0sS

Projects that are NOT Agile Software Projects http://bit.ly/akTOJa

Fear of shipping http://bit.ly/9xjhna

Agile Isn't Latin http://bit.ly/9WFS22

The new CST application process http://bit.ly/ccsNrW

Status Reporting Intervals http://bit.ly/d5VSTs

Are you being creative? http://bit.ly/dwR69w

PMBOK is NOT a Method - Part Deux http://bit.ly/cka0ND

Kanban and When Will This Be Done? http://bit.ly/cohJ0n

Big Binders And Checklists http://bit.ly/ci0Sk3

The 19 Keys to Successful Agile Projects http://bit.ly/aEBXnJ

Scrum Gets Going In Bangalore http://bit.ly/aHrrQZ

PMBOK is NOT a Methodology http://bit.ly/cUyJVm

Artificial Critical Paths http://bit.ly/cypzpC

Base lining Story Points http://bit.ly/ajF9ix

Why Is There Still Talk About Agile v. PMBOK? http://bit.ly/9ojMy9

What DONE Looks Like? http://bit.ly/9gFksS

Schizophrenic Use Of Methods http://bit.ly/aQ7xy7

Agile is in the PMBOK so it must be true http://bit.ly/c4pw7L


Subscribe to Leading Agile

Hyperproductivity in Scrum

Last year sometime, I had the pleasure of hearing Jeff Sutherland speak at the Agile Atlanta group here in town. One of the things that Jeff always brings up in his talks, is that Scrum creates hyper-productive teams. I asked him how he defined hyper-productivity, and how he measured it. He told me, but rather than explain my recollection of what he said, I want to reference how he explains it in print.

According to his paper Shock Therapy: A Bootstrap for Hyper-Productive Scrum:

"We define Hyper-Productivity here at 400% higher velocity than average waterfall team velocity with correspondingly higher quality. The best Scrum teams in the world average 75% gains over the velocity of waterfall teams with much higher quality, customer satisfaction, and developer experience."

Pretty impressive, but I am curious what the improvement is measured against. Going deeper into the Shock Therapy paper, the results from their MySpace experience say that:

"The baseline velocity (100%) is established for a team during the first Sprint. The Product Owner presents the prioritized Product Backlog in the Sprint Planning meeting. This is estimated using Planning Poker and story points. The team selects what can be accomplished during the first Sprint and the Product Owner determines exactly what is "Done" at the end of the Sprint. The number of points completed is the baseline velocity."

When I first read that, I was like "what am I missing here". Hyper-productivity is defined as improvement over the first iteration of a brand new Scrum team. That didn't strike me as a very fair metric, you'd think *most* brand new teams would get dramatically better after a few weeks of working together, using Scrum or not.

But here is their key assertion that supports the measurement:

"At MySpace, the baseline velocity is often significantly higher than their previously chaotic implementation of waterfall, so the baseline is conservative"

I don't know about you guys, but I'm kind of bothered by the assumptions, and the numbers that support them. Can we always assume the first sprint of a Scrum team is better than the same team doing Waterfall? I'm not sure. Are all Waterfall projects chaotic? I can tell you first hand they aren't. It might also be interesting to see the team stabilize first, and then see how much better they'd get by systematically removing impediments.

These numbers have been nagging me ever since I read this paper and first heard Jeff explain them. Is it only me? What am I missing here?


BTW - I loved the image here... seemed pretty much with the Shock Therapy theme. Check out the artists website at http://llynhunter.blogspot.com/2008/05/electricity-if.html

Subscribe to Leading Agile

Saturday, June 12, 2010

Is Kanban just Waterfall with Small Batches?

Often when I introduce Kanban to teams that are just getting familiar with Scrum, one of the first comments I'll get is... it looks a lot like waterfall. So, here is the question, is Kanban just waterfall with small batches? Let's say you kept all your functional silos in place, and simply started running smaller projects... small to the point of being a feature or an MMF... would you get better business outcomes?

I haven't been in a situation where I could actually try this approach at any kind of scale, but my gut tells me that you would get better performance. You'd increase the rate at which the organization created value, you'd decrease the amount time spent doing up front planning, and you'd decrease the number of in-flight dependencies you're managing at any one time. Decreasing the batch size would make it easier to change direction when business conditions changed.

My guess is that's why some folks are so excited about Kanban... you get better overall performance, without having to change anything about how the organization is currently structured. You get incremental improvement without the transformation and change issues that come along with a Scrum adoption. In addition, you'd now have a way to explicitly visualize the work, manage the flow of value, and drive conversation that incrementally improves how the overall system behaves.

So... what do you think? Is this the preferred way of working? Do we abandon teams and transformation? Is adopting Kanban as simple as working on smaller batches, value stream mapping, and setting work in process limits to create flow? If we took this approach, what would be our tradeoffs? Would we be leaving anything out by not transforming?

BTW - It is worth marking the occasion... this is my 300th post on Leading Agile. That's kind of a cool milestone.


Subscribe to Leading Agile

Friday, June 11, 2010

Motivation, Insight, and Introspection

I've had the idea for this post noodling around in my head for the past few months. To be quite candid, there was a part of me that wasn't quite sure how much of this I wanted to share. Even though I don't know all 2400 of you personally, I've always had this desire to be transparent. My hope is that that my experiences, agile or not, could somehow help you guys get better doing what ever it is that you do.

It's not been any secret, at least I don't think it has been a secret, that these last few months after leaving VersionOne have been really challenging for me. Working for VersionOne was a great gig. Someone else sold my engagements, and I just showed up where I was supposed to show up, when I was supposed to be there. When I wasn't on client sites, I did papers and blogs and attended conferences. It was a pretty fun way to make a living.

When I joined Pillar, all that changed. Now I was working constantly to build a business here in Atlanta. My life became all about generating sales. Rather than trying to solve the big problems in the agile community, I was trying to solve the big problem of managing a sales funnel and running a small consulting business. Much of what I'd been doing was brand new to me. I was like the guy that loved to make bread that opened a bakery. Now, rather than making bread, he was running a bakery. Not quite the same thing.

The time between the Scrum Gathering in Orlando and the LeanSSC conference in Atlanta was pretty tough psychologically. I spent a lot of my time stressed out, and sick to my stomach. There was so little correlation between the effort I was putting in, and the outcomes we were seeing, the stress was really getting to me. I wasn't writing, I wasn't connecting, and I wasn't enjoying life. To some degree I felt like I had lost my way... I had somehow lost sight of the big picture and what was really important. I needed to refocus.

Four books that helped me refocus

One night at the LeanSSC conference, I was sitting in the lounge having a drink with Jean Tabaka and Dennis Stevens. Jean was telling me about some of the books the folks at Rally were reading, and about how several of them were having a profound impact within their company. Jean turned me onto the first two I want to talk about today: Seth Godin's Linchpin and Daniel Pink's Drive. I like Jean, and I think she's smart, so I took her advice and started reading them.

Come to find out, some of the guys at Pillar were reading Drive too, and turned me onto a third book, by Chris Anderson, called Free. I think the Pillar guys are smart as well, so I picked up Free and starting reading it also. The fourth book was Gary Vaynerchuk's Crush It. I'm not sure where that one came from, but I'm really glad it showed up in my life. For me, these four books were the right four books, at just the right time. Together, they really helped me see, and articulate the core problem that I was struggling with.

I want to first highlight a few simplified takeaways from each book, and then tell you guys why there were meaningful to me.

Drive by Daniel Pink - The main point of this book is that creative people are intrinsically motivated. That means that they create for the joy of creating. They love being in a state of flow. They love being challenged. They love helping people. The idea behind this book is that people need to have their basic needs covered, but once that happens, extrinsic rewards don't increase performance. More often than not, they decrease performance. I have found that while I want to earn a boatload of money, it's not really about that. It's all about the intrinsic motivators. The money is a distraction.

Linchpin by Seth Godin - This was a big book with lots of big ideas, but I think what really resonated with me was Godin's take on how society is changing. The social contracts that told us to go to school, get an education, get a job, and conform... and in return society will give you lifelong employment... are broken. To be a linchpin, we need to think outside the lines. We need to be creative. We need to bring our passion. We need to give. We need to make ourselves invaluable by bringing our whole person to our jobs. This book helped me rediscover the path I had been on and why. Excellent book, my favorite of the four.

Free by Chris Anderson - I'm still reading this one, but the general idea here is that, as it gets cheaper and cheaper to distribute information, the cost of that information goes down exponentially... to the point where it is so close to free that it is less expensive to round down than to sell. In an economy of open source software and free services, how does someone run a profitable business. You give away one thing in the hopes of selling something else. Free helps me stay connected to people, to build relationships, until the right opportunity presents itself... and if it never does, that is okay too.

Crush It by Gary Vaynerchuk - Gary V. is a guy that turned a moderately successful local liquor store into a 20 million dollar business, and ultimately an online wine seller called Wine Library. He did this using social media and the power of the internet. His message is about family, hard work, focus. Great businesses are not build in a month or two months or even a year. You have to do what you love, so you can work your ass off while the thing isn't making any money. If you don't love it, you won't have the energy to sustain it. This book gave me a few more ideas for connecting, and reinforced that patience really is a virtue.

What I Learned About Me

Over the last 8 months, I've been in a situation where I've had incentives to do the things that I used to do for free. I could go to a conference, show up and network, try to be smart and polished, and go home. The VersionOne brand hopefully benefitted, but past that... I didn't have any part of my compensation tied to how much software we sold. Sure, I had a paycheck, but at VersionOne, there wasn't any further incentive to go out and sell business. I trained people for a living... I blogged and networked and attended conferences, just for the love.

When those things became direct marketing activities, things that had an impact on how much money I make... they got uncomfortable. Now it wasn't about helping people, it was about finding leads, and seeing who I could impress. It was about making sure I got a business card so I could reach out to someone later, to maybe move some of our consulting services. It felt inauthentic. I struggled to find a way I could sell, that allowed me to keep my personal integrity. More than once I was called out because something about me was different, I wasn't being myself.

If I was going to do this for a living long term, I had to find a way to decouple psychologically, what I love doing, from how I earn a living doing what I love... at least from a direct financial perspective. What I found is that when these things were directly linked... it had a profound negative impact on my writing, my interactions with people, and how I fundamentally viewed the world around me. All in all, it hasn't been a healthy place for me to be. To be successful going forward, I had to think about things differently so I could continue to bring my whole self to my job. What I was doing, wasn't working.

I am fortunate that I love what I do, and I've found a way to make a living doing something that I deeply care about. It's not just about software development, it's about the quality of our human condition, it's about making work/life balance, it's about working in environments that make sense. It's about meaningful work, and creating real value. It's about putting people into systems where they can be successful. The methodology that surrounds that is just a means to an end... not a goal unto itself... no matter how interesting the technical details happen to be.

What I learned through some of these books, is that the stuff that really drives my passion, the stuff I love, is the stuff that I need to give away for free. It can't be tied to a sale. To maintain passion and enthusiasm for my craft, I have to contribute, I have to feel like I am making a difference, and I can't feel like every interaction is something to be monetized. I want to connect with people, in meaningful ways, that aren't always about selling someone something. I feel like the pending sale diminishes the quality of the relationship.

It makes me feel a little queasy and it's not who I want to be as a person.

Rethinking the Sale

I'm getting better at distilling what I like about this field and what has me excited to wake up in the morning. It's not the sale... it's not the chase... it's the connection. It's about helping people connect with each other. It's about helping people connect the dots in their organizations. It hit me a few months ago when I was doing this public class in Atlanta. We had 22 folks representing 12 companies. By the middle of the second day, they were talking to each other and exploring ideas and possibilities. I switched from teacher to facilitator and let the discussion play out. It was awesome.

I've decided that I don't want to sell. I want to help people be successful. I want to help people grow. I want to connect them to each other and to the community. I'm going to bring my whole self every day... try not to worry about quotas and revenue. I have to trust that if I do all the right things, and work really hard, the rest will follow. Integrity is about being internally congruent. What I'm really doing is, I'm learning how to sell with integrity, in a way where I can live with myself.... and do what I love as a result.

I don't know that I have the details worked out yet.. but this feels like the right way to think about things. I feel like I've gotten myself finally on the right path.


Subscribe to Leading Agile

It's About Context, People!

In any given situation, there are a ton of things that could possibly work. One of the most successful projects I ever managed was delivered using a mix of Waterfall, Agile, and RUP. We had a existing product that our customer wanted to enhance. The customer knew exactly what they wanted and never changed their mind. The teams involved had built the original product, and they knew the code like the back of their hand.

We used a big-up-front-design, traditional estimating, and Gantt charts... even on the agile side. We did 'black box' the agile teams, but they had to inspect and adapt their way into the overall project plan. We delivered the project on the promised due date, within something like 1% of the original cost estimated, and with everything the customer had originally asked for. My company made the money they expected to make and our client made the money they expected to make.

We didn't do a death march, there were no 11th hour surprises, the deployment went exactly as expected.

Scrum is an empirical process control method. When you have a high degree of variability, and predictive planning methods are likely to fail, empirical process control can help manage and constrain the chaos and complexity, and optimize your project outcomes. It's a more expensive way of managing project outcomes, but works better when variability is high. If variability is not high, and the system is well known... it's possible Scrum is not the best choice, even on a software project.

I think part of our problem right now is that we've somehow decided that Scrum is the way to go no matter what the project characteristics. We get so enamored with the benefits the team gets from adopting Scrum, sometimes we forget that Scrum might not be well suited to the business needs of the enterprise. That's not a knock on Scrum... it's just that Scrum might not be the best tool for the job. It is up to us as organizational and project leaders to understand our options.


Subscribe to Leading Agile

Thursday, June 10, 2010

The Gist of My Agile Dev Practices Talk

I know this is really high level... but I want to see what kinds of questions this level of description generates. Does it make sense? I'm really trying to figure out how to explain some of these ideas with fewer words.


Talking Points

1. Scrum works under certain conditions, if it works... use it.

2. Scaling scrum works under certain condition, if it scales... do it.

3. Scrum requires significant transformation for most organizations.

4. People underestimate what it really means to transform.

5. Transformation is too disruptive for many companies, these people will fail.

6. We need a credible transition strategy for everyone else.

If you are an 'everyone else', go read my last post... I'll wait.

7. Define a static organization model.

8. Find the constrained capability, create an agile team there.

9. Do agile for a while with that team, do it again with a few others.

10. Define your first agile multi-team project. Use expand and collapse Kanban, across teams, to limit WIP.

11. Define your next few multi-team agile projects, now you have a portfolio. Use expand and collapse Kanban, to limit projects in progress (PIP?), and manage WIP across teams.

12. Define capabilities outside of IT... extend agile to them.

13. Wash, rinse, and repeat

Key Concepts:

1. Scrum will break in complex product organizations.

2. Use a Static Organizational Models as the basis for agile pilots.

3. Use Lean and Kanban to intentionally limit WIP at the project level and the team level.

In general the talk was well received. A handful of people walked out... maybe this wasn't what they expected, maybe they just needed to use the restroom ;-) A few folks challenged the ideas I presented... Bob Galen and I had a follow-up conversation. More than a handful stayed after, talked to me in the hallway, and took business cards.

This is not everyone's problem... but if it's your problem, you need to go into your agile transformation with your eyes wide open... and some credible strategies for incrementally adopting agile.

Subscribe to Leading Agile

You Need a Static Organizational Model

Okay... I want to make an assertion here. In order for agile to work, you've got to understand the static organizational model for your company. Why? If you are organizing around things that are transient, like projects, you are doomed to fail. Agile requires teams that stay together, period.

Most organizations are organized around one static model, the resource team. This is our much beloved organizational pattern where we pull all the BA's into one group and all the developers into another group. People are assigned to project teams, but the resource organization is the strong side of the matrix, the project organization is the weak side. Resource teams don't deliver value by themselves.

Agile asks us to organize around the parts of the business that deliver value, and in common practice, that is usually the product. It makes sense, we make products, let's organize around the stuff we make. This is where we get the whole, give the team what they need to deliver, and they'll give you working software at the end of every sprint routine. Single PO + Single Team = Delivered Business Value.

That works awesome in small product driven organizations. In the complex organizations we've been talking about here, this approach is problematic. Why? Investment is not always level across products. Sometimes I need a full staff and sometimes I don't. Sometimes I want to improve one set of product capabilities and just keep the other capabilities in more of a steady state.

Uneven investment in products over time is what drives our obsession with project work. We know that we don't need the same people doing the same thing all the time, so let's deploy 'teams' to go build some value for us. When they're done, we can break them up and have them go do something else. From an agile perspective, the problem is that this approach doesn't keep teams together over time, and that makes it really hard to really do agile.

I'll admit, you could create multi-disciplinary teams and run your project work through these static teams. This is on the right track, but still breaks down when the skills required project to project ebb and flow. I'm all for building teams around specializing generalists and bringing work to teams, but in complex organizations it is a stretch that every team is going to have every skill they need to do every project.

So... back to our static organizational model. If we are going to keep teams together, we need to organize the teams in our complex product organization around the things that aren't likely to change over time. We need a static model for the organization that is resilient. One that reflects the core delivery capabilities of the enterprise, capabilities that can be staffed and deployed to solve specific business problems

In our complex product example, the delivery capabilities might be the various products delivered by the organization. The services they provide to external customers, or to other internal products, become the capability the organizations is expecting them to deliver. A capability could also be something like marketing, or sales, or support, or even some external service provider that you depend on for a fully functional product.

Before you begin your agile transformation, you need to think about your organizational structure. Ask yourself if you are building teams around stuff that will predestine them to be broken apart when the work is done. Are you piloting something that has no chance of long term successes when it get's out into the wild? It is important to understand what the non-transient, static model for your enterprise looks like, first.

Then, and only then, should you decide where to pilot your first agile team.


Subscribe to Leading Agile

Wednesday, June 9, 2010

Scaling Agile Past the Team - Agile Dev Practices Edition

If you guys have been following my updates here and on Twitter, you know that I'm out at Agile Development Practices in Vegas this week. I'm speaking in about an hour... and just putting the final touches on my presentation. The content is not fundamentally new, I think though I'm learning how to talk about this stuff better. So... here is the slide deck I plan to go live with. Have fun, and let me know if you have a group that would be interested in this topic. Depending on your schedule and mine, I might be able to come out and do the talk for you live and in person!

Subscribe to Leading Agile

Sunday, June 6, 2010

Interesting Post... 6/1/2010 through 6/6/2010

Twitter search won't seem to give me any of my tweets from before 6/1 today, so this installment of Interesting Post... is going to a be a little short this week. Hope you enjoy...


Interesting Posts from 6/1/2010 through 6/6/2010

Why Is There Still Talk About Agile v. PMBOK? http://bit.ly/9ojMy9

What DONE Looks Like? http://bit.ly/9gFksS

Schizophrenic Use Of Methods http://bit.ly/aQ7xy7

Agile is in the PMBOK so it must be true http://bit.ly/c4pw7L

Real Men of Agile Genius Sweepstakes http://bit.ly/9AnaMY

Agile Scrum, Or Not-So-Agile Scrum? http://bit.ly/aPpbam

Is this noise inside my head bothering you? http://bit.ly/bjVgt8

Kanban and Conversations http://bit.ly/ahdSUd

Subscribe to Leading Agile

Saturday, June 5, 2010

Big Pie in the Sky... And Other Stuff!

Time has been absolutely flying by the past few weeks. Lot's going on here in Atlanta, some of which I want to share with you guys this evening. First of all... I've got to tell you about the place we went to dinner tonight.

Big Pie in the Sky


We are big Man v. Food fans in our house. Somehow, me and my boys get a kick out of watching Adam Richman travel the globe looking for the biggest, greasiest meals... and then watching him eat the entire whatever in under an hour. A while back, Adam hit three places in Atlanta, one of which was a place called Big Pie in the Sky. That's where we ate tonight.

The challenge was for two people to eat a 30 inch, 11 pound all-meat pizza in under an hour. Needless to say... that was out of our league. We did order the 30 inch, 11 pound all-meat pizza, but it took seven of us to put a dent in it. We still came home with leftovers. The kids got a kick out of driving across town to eat at a place we saw on TV. It was really fun... and definitely out of the ordinary.

ATdL100

I got a great invitation to attend an executive networking meeting last week called Atlanta TechDev Leaders (ATdL100). Van Williams, my former SVP at CheckFree/Fiserv was the host, and put together an excellent panel to talk about Innovation. It was really cool hearing these senior leaders talk about what factors contribute to innovation in their companies. More often than not I heard colocation, collaboration, and iteration. If I didn't know better I would have thought I was at an agile meet-up.

Dan Pink - Drive, The Surprising Truth About What Motivates Us

I've been doing quite a bit of reading the past few weeks. This one I actually downloaded from Audible.com and listened to on my iPhone. This is a game changing book, and a must read for anyone that needs to get the best out of their team. The main takeaway from the book is that knowledge workers tend to be intrinsically motivated, the are more inclined to perform for the sheer joy of the work. Offering extrinsic rewards often results in lower performance and gets us exactly the behavior we don't want. Again... a must read

Seth Godin - Linchpin, Are You Indispensable?

I don't even know where to start with this one. First, excellent book. Next, go read it. Godin starts off talking about how our schools and our society are setup to get people to conform. He explains how the old social contracts, the ones that rewarded conformity with lifelong employment, are no longer in place. Workers are doing their part, but the security that we used to have in return is no longer there. Godin makes a strong case that successful people are those that make themselves indispensable. Success comes from giving, being part of communities, and shipping.

Chris Anderson - Free, Future of a Radical Price

This is the one I am reading right now. The book explores the economics of the Free economy... from open source software to illegal song downloads. It's another one that challenges conventional wisdom and shows you how to make money by giving stuff away. The general premise... remember I'm only just starting... is that as the cost of delivery goes down, it is almost impossible to make money from the distribution of information. Give the ideas away for free and make money off of something else. Again, a very powerful and very radical idea. Somewhat counter-intuitive.

Pillar Southeast

We've spent a bunch of time and energy investing in relationships with a few dozen companies here in the Atlanta area. That investment is starting to pay off, and we are beginning to sell some business here in the region. I love this new gig, but the sales cycle for some of these deals has taken much longer that I ever thought. It is really nice to start seeing the other side... the light at the end of the tunnel you might say. I love getting out and helping people, and I'm excited to be on the ground working with clients on a more regular basis.

Kanban Training

Dennis Stevens and I just wrapped up the first ever Kanban course in Atlanta. We had an excellent group of people... almost 20... attend the class. The class went very well and everyone learned a lot. I think some of us get desensitized to how fast new ideas are emerging from our community. Many people are still just hearing about Kanban... if they've heard anything about it at all. It is cool to introduce people to such new and powerful ideas for the first time. It is very rewarding to see that light go on as people discover that there ARE solutions to some of these problems they have been wrestling with for so long.

COHAA Conference

A week or so ago, I was up in Columbus, Ohio... reprising my Agile PMP talk for 350 (or so) agile practitioners. The Central Ohio Agile Association did a great job organizing the conference and I really, really enjoyed hearing Ken Schwaber, Michael Mah, Patrick Wilson-Welsh, and Isreal Gat speak. It was one of the first conferences in while that I actually went to attend sessions and learn. It was interesting hearing Ken Schwaber's take in the new Scrum.org group. Ken had quite a few great lines... but one of the things I really respected was when he said 'whatever we do will be wrong... but we have to do something'. I can live with that.

Agile Development Practices West

I'm heading to Vegas next week to do my talk on Scaling Agile past the team. This talk is really about applying Scrum (and Lean and Kanban) to manage agile delivery in complex product organizations. My thinking on this has gotten clearer over the past few months, so I am putting some effort this weekend into refactoring my slide deck. I speak on Wednesday and am tied up Monday and Tuesday... so I better get busy. If push comes to shove, I can always fall back to the original presentation.

Agile 2010

Lowell Lindstrom asked me to produce the Enterprise Agility stage... this was first for me and quite a good experience. I also had my talk on scaling the product owner role on large complex products selected, so I'm happy I'll get to speak too. It's funny, I think the material in my scaling agile talk, and my talk on product ownership in the large, are starting to converge. There are a couple of core themes that keep coming out. I think they are really important and stuff that our community needs to understand... so I'm geeked. That said, I'm bummed we had to move from Nashville, but Orlando is always an excellent place to have a conference... and of course it will be fun to see old friends!

Agile Development Practices East

Lee Copeland was gracious enough to allow me to do my Scaling Agile talk in Orlando too. Again, I think this is a strong message that people need to hear. I am happy to have a forum to spread the word.

Raising Boys

As my kids get older, I am constantly amazed watching them grow. My oldest turned 14 this year. He is a great kid, plays percussion in the marching band, and is a straight A student. That said, he is pushing his boundaries and trying figure out his limits with his Mom and me. A few weeks ago, he got busted making out with his girlfriend in the dugout at the high-school. It was totally awesome watching the consequences come down from the school system, and seeing him learn a lesson that I didn't have to impose. I love watching these guys grow up... totally awesome!

Stephen King - Wizard and Glass

If you follow me on Twitter, you may have caught that I am slowly working my way through Stephen King's Gunslinger series. I just finished the 4th in the series called Wizard and Glass. I wasn't sure what I thought of it as I was working my way through, but now that it is done, I think it was probably my favorite of the four so far. I've decided to take a few weeks off before I start reading book 5.

Scout camp coming up

Last but not least...after Agile Dev West, I'll be up in Gainesville, GA at Scoutland chaperoning 10 teenage boys at Summer Camp for the week. Once we are done, Zach should be a Life Scout and Daniel should be a Star Scout. I am personally looking forward to a relatively relaxing week. I plan to take that time to get going on our book again. I am anxious to get back into the habit of writing daily, I really miss it. It has been tough being creative when there is literally no space in my life.

All good stuff... just freakin' busy! If you made it this far, thanks for coming along for the ride!

Subscribe to Leading Agile