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

Monday, August 31, 2009

The Double Loop Learning Conversation

Another theme we are going to see throughout our book is the idea of individual and organizational learning. One of the most eye-opening ideas... but looking back one of the most obvious... is that people have to go through steps in the learning process. We can't come along and say... go be agile. We can't just explain what it means to be an agile leader and talk about the principles behind agile teams... we need an action plan.

This idea hit me in the face like a sledgehammer a few years ago when I brought a new project manager into our organization. I spent hours talking to this guy about principles and patterns and how I wanted him to think about doing his work. What I really needed was to give him guidance on what to do... he would learn the principles and practices while DOING. Cockburn talks about the Shu-Ha-Ri principles... we have to go from having one way... to many ways... to blending ways. From apprentice... to journeyman... to mastery.


On some levels we have to start people off with practices... but practices that work in THEIR particular situation... not the situation we'd like them to have. We can't recommend agile practices that are not going to work in the organizational context in which we introduce them. Using that approach, we might be able to get pockets of agility... but what we REALLY need is sustainable organizational change. Pockets aren't good enough. It's up to us to create a context where... not just individuals... but entire organizations... can learn to be agile.

Dennis and I talked about the idea of single-loop learning and double-loop learning in last month's Cutter paper. The idea comes from Chris Argyris and Donald Schon writing about their research in the 1970's. Argyris and Schon looked at three elements of learning: Governing Variables, Action Strategies, and Consequences. Governing variables are the constraints we operate under and action strategies are the things we do to get our desired outcomes.

Single loop learning involves monitoring consequences and changing action strategies to improve our desired outcomes.

Double loop learning involves monitoring consequences and reassessing our governing variable to open up more possible action strategies to get even better outcomes.

Let me give you and example Dennis and I were bouncing around yesterday. The following is an example that Dennis provided:

Governing Variable: We need better Project Predictability to meet the needs of our clients.

Action Strategy: To get better predictability we need to design and plan the entire project up front

Consequence: Projects are slower and more expensive then planned, have more customer expectation and product quality risk, and result in low trust people hostile environments.

In single loop learning, we go back and try to improve design and planning to manage the governing variable.

In double loop learning, we go explore the false assumptions we have made regarding the governing variable about how to meet the needs of our clients.

Here is my rather cynical response... Dennis' example is better:

Governing Variable: We need Product Owners assigned to every team

Action Strategy: Tell the Product Managers they need to turn into Product Owners and sit with the team.

Consequence: Product Manager/Owners are not able to dedicate their time to the team and we end up with no product owners and no documentation.

In single loop learning, we might try to pressure the organization to dedicate the product owner or maybe provide product owner training to our Product Managers.

In double loop learning, we go explore the false assumptions around the idea of the single-wringable neck and take a look at implementing product owner teams.

We see examples of single-loop learning and double-loop learning in both traditional and agile organizations. We believe that you have to intentionally create an environment for this kind of organizational learning to take place. We are going to explore some of these governing variables... we are going to look at our false assumptions... we are going to put together a framework that embraces this idea of double-loop learning and reinforces sustainable organizational change.

References:

Single loop and double loop learning discussion summarized from Infed.org, the images come from this site as well.

Subscribe to Leading Agile

Sunday, August 30, 2009

The Capability Conversation

A week or so ago, I did a post called Agile Adoption and Scaling Patterns. In that post, I introduce a five phase framework for bringing agile into an organization. This adoption and scaling framework is going to guide the fundamental structure of our upcoming book. We haven't decided if these phases will be chapters or entire sections... right now I am thinking sections... but the primary story is going to be around incremental adoption and scaling in the enterprise.

There are going to be several major themes that run orthogonal to the primary adoption and scaling discussion... ideas that cut across all the chapters. The most important of these ideas is something Dennis calls Capability Analysis. Our premise is that at each level of your agile transition, there are a series of conversations that have to take place. Fundamentally... these conversations are around identifying the most important capabilities we need provide back to the business.

The word capability is pretty overloaded... untangling the language is something that we are working through right now. As I see it, organizational capabilities come in three major flavors:

First, we have Value Capabilities. This is the stuff we provide back to the business that the business might sell to an actual customer. Here I think about things like Projects, Epics, Features, and User Stories. Value can be defined in several ways depending on the environmental context and the consumer of that value.

Second, we have Core Capabilities. These are the things that we have to do well and directly impact our ability to create Value Capabilities. Here you have things like defining requirements, prioritizing requirements, architecting systems, writing software, testing software, frequent delivery, and deploying builds.

Last, we have Supporting Capabilities. Supporting capabilities are things like managing the project, communicating status, building CI environments, invoicing customers and collecting payment. These are the capabilities of your business that enable the Value Capabilities and the Core Capabilities.

Like I said, we are untangling this a bit right now... so we might shift our thinking around as the book becomes more concrete. Categorization might shift around depending on your context and we want to be really clear about that context when having the discussion. The point is... our conversation about agile transitions shouldn't start with what practices we want to adopt... that is how we fall into process thinking. We've got to start thinking about what capabilities are most important to focus on first.


We can think about capabilities across all three dimensions... what creates the most value... what do I need to get better at to deliver that value... and what do I need from the supporting organization to enable that delivery. The intersection of the highest priorities across all three capability areas is the basis for deciding what to improve first. This is where we start our agile adoption initiative and choose what practices we want to focus on first.

Subscribe to Leading Agile

Saturday, August 29, 2009

Thoughts on #Agile2009

I've been sitting here for the past few hours... in my favorite coffee shop... thinking through this past week... contemplating my upcoming week... and trying to decide how to get back into the groove of writing. My intent coming here was to share some thoughts on the conference. Right now, I just don't have the energy. The week was full of late nights... early mornings... lots of meetings... lots of sessions... talking to customers... debating ideas... reconnecting with old friends... and making a few new ones.

It was awesome meeting some of you guys that follow me here and on Twitter. It's always a hoot when a tiny little 64x64 picture... one that speaks in 140 character bursts... turns into a real... living... breathing... human being you can go drinking with ;-)

Part of my challenge writing about the conference is that I'm still not really clear on how I feel about it. There were so many great sessions... so many excellent topics... so many excellent speakers... but how many of their ideas can actually be implemented when people go back to their real worlds? It is great to get pumped up at a conference... but how long will that enthusiasm last when we take these ideas back and meet crushing resistance?

If I were king for a day... I'd like to see an entire stage next year dedicated to organizational agility and scaling. We need to start talking about how these ideas get applied in real companies... with real management hierarchies... with real PMO's... with real planning cycles. I want to talk about agile ideas in the context in which the ideas were successful and explore how we can do them at scale. Alistair pointed out during his keynote that agile was designed for small teams working with discretionary funds... but that is seldom where we find it applied.

I'd like to see experience reports from people that are really doing this. I'd like to hear from CEOs and CIOs who have been able to lead sustainable change. I'd like the talks to be vetted in advance by a real person and accompanied by a proceedings paper. I'd like to have breakout sessions and workshops that allow us to explore these Big Agile problems together. It just seems that we don't really have this worked out yet.


We all bring pieces of the puzzle. How do we pull it all together?

Aside from that... some of my bright spots happened outside the session rooms. I personally want to thank Kent McDonald for his 3 minute overview of Feature Injection and Karl Scotland for the great discussion on Kanban and Drum-Buffer-Rope over way too many drinks. I really enjoyed Alistair's opening keynote and Jared's closing keynote. Both were very entertaining.

Thanks to Dennis Stevens for the 20/20 presentation on Capability Analysis. Thanks to DZone for the interview and all those that attended my session on the Agile PMP. Thanks to all the folks that came by the VersionOne booth... it was great talking to you. Thanks to the Agile PMI crew, especially Michele Sliger for putting up with me Sunday night. Last but not least... thanks to Eric Guitar Davis and the Troublemakers... you guys totally kick ass!



Subscribe to Leading Agile

Sunday, August 23, 2009

Interesting Post... 8/17/2009 through 8/22/2009

Only have a minute today... all packed and ready for Agile 2009. Heading to the airport in an hour or so and need to spend a little time with the family ;-) Anyway... if you missed any of these posts on Twitter this week... here is your chance to catch up.

Interesting Posts from 8/17/2009 through 8/22/2009

Thanks for leading http://bit.ly/PzIXG

An Open Challenge http://bit.ly/C0do7

Getting to Business Value http://bit.ly/sDPTn

Top 10 reasons why you want your boss to read your blog http://bit.ly/mJmPq

Not every question has a right answer http://bit.ly/17CNRF

Reviewers for a Distributed Scrum Book http://bit.ly/ji3Fb

Conference wiki http://bit.ly/cPZuJ

I come to bury Agile, not to praise it http://bit.ly/OBHIo

Feature vs. Component Teams: Another Perspective http://bit.ly/3go3Ax

Using our kanban board for continuous improvement http://bit.ly/1TvU43

Come and play at Agile 2009 http://bit.ly/IrLxO

It's all a game...but that doesn't mean it's "play" http://bit.ly/B53CR

Defect Prevention http://bit.ly/E4B7V

Quote of the Day http://bit.ly/RSvdj

Is Project Management a profession? http://bit.ly/2OoDb4

Percent Complete? http://bit.ly/xwpTM

PMI coming to learn at Agile 2009 http://bit.ly/49C9J1

Facebook is our second sexual revolution http://bit.ly/3rQ6yf

Agile Fixed Price revisited – part 2 http://bit.ly/3JaoBn

Advantages of Agile Software Development for Testers http://bit.ly/q2q9q

The Secret To Delivering On Time http://bit.ly/4A19Z8

Agile 2009: 1-on-1 Consulting - Get free Assistance from an Agile Expert http://bit.ly/3oMoeF

PMI Agile Launch Event @ Agile 2009 http://bit.ly/2lFuGo

Beating fear http://bit.ly/XrIml

Do you have the perfect process? http://bit.ly/fCEpK

Use personas to find your way in the program http://bit.ly/Tq9uN

7 Reasons Why Pair Programming Makes Sense http://bit.ly/T7621

Real Engineers http://bit.ly/zVmjk

A simple rule to rule them all http://bit.ly/cuFGO

What's a good measure of an Agile project manager's success? http://bit.ly/WOTFs

Agile Tour Toronto http://bit.ly/teruH


Subscribe to Leading Agile

Thursday, August 20, 2009

Come find me at Agile 2009

Okay... I used my nifty little Thoughtworks iPhone app and created a preliminary list of stuff I want to attend at the conference. Like anything else... I plan to inspect and adapt and change direction as I learn more by being there with you guys. For now though... here is what I plan to attend... and these were NOT easy decisions:


Sunday

Getting in town around 4:00... AgilePMI kick-off stuff all night. All behind the scenes stuff

Monday

9:00 -12:00 Helping the team setup the VersionOne booth. I am a pro at this... attendance was not optional

1:00 - 2:30 What's an Agile PM Anyway? This is a session led by the AgilePMI leadership team. I will be facilitating a session so... if you are in town early... come by and let's talk.

4:00 - 5:30 Zen and the Art of Agile Testing by Jim Highsmith. Might be the only time I get to hear Jim speak... certainly don't want to miss him.

5:30 - 7:30 Ice Breaker Reception. Another great opportunity to meet people and do a little networking.

7:30 - ???? Party time... TBA

Tuesday

8:00 - 9:00 Private meeting to talk about my forthcoming book

9:00 - 10:00 I have come to slay agile... not to praise it by Alistair Cockburn. Alistair doing the keynote???? Totally rockin'... can't wait

11:00 - 12:30 Risk and Risk Management, Theory and Practice by Chris Matts. I don't care how many times you have heard Chris speak... it is always entertaining

12:30 - 2:00 VersionOne Booth Babe. Come by and I will personally give you a demo of VersionOne Enterprise... the best Agile PM tool out there!

2:00 - 3:30 What can Agile learn from Complexity by Jurgen Apello. I have been following his blog for quite a while... and even made his Top 200 (number 56 I think)... so I need to meet this guy and hear him speak

4:00 - 5:30 How to Develop Your Leadership Power Daily by Christopher Avery. I have Christopher's Responsibility Redefined Process on my refrigerator... what more can I say.

7:00 - 10:00 PMIAgile kick-off even at the Thoughtworks studios... right across the street. It's where all the cool people are going to be... seriously! This is one you have to register for.

10:00 - ???? More PMIAgile talk with the Leadership Crew

Wednesday

9:00 - 10:00 Recording an Interview with DZone

11:00 - 12:30 I am doing my talk called the Agile PMP: Teaching an Old Dog New Tricks. This is definately the must see talk of the conference ;-) The talk is going to be recorded by InfoQ.

12:30 - 2:00 More VersionOne booth babin'. My demo offer still stands!

2:00 - 3:30 Flirting with your customers by Jenni Dow. Jenni is an awesome presenter... if only I could attend her talk BEFORE I do mine. I am sure I could learn a thing or two.

6:00 - 10:00 The VersionOne Annual Boat Cruise. This is an invite only event.

10:00 - ???? Party time... TBA

Thursday

7:30 - 9:00 Get to be a VersionOne booth babe again... if you come by for your free demo... bring me a cup of coffee.

9:00 - 10:30 Only Dead Agilists Don't Ask Questions by Ole Jepsen. Ole is one of the people I am most anxious to see again at the conference.

11:00 - 12:30 Beyond User Stories by Ellen Gottsediener. I've had a chance to talk to Ellen a few times over the past months... I think she is really cool. Can't wait to learn a few things about user stories here.

12:30 - 2:00 Booth Babe... come get your demo... I should be awake by then!

2:00 - 3:30 User Stories for Agile Requirements by Mike Cohn. I haven't heard Mike speak in years... I am anxious to get another chance.

4:45 - 5:30 Agile by the Numbers by Scott Ambler. Love Scott or hate him... he is interesting... has a lot to say... and DOES NOT pull any punches.

7:30 - 9:00 Agile 2009 Banquet. Good food. Good friends. Good fun.

9:00 - ???? Party time... TBA

Friday

9:00 - 11:00 Tearing down the booth


Subscribe to Leading Agile

Adopting Agile... the Video Podcast

A month or so ago I put together a video podcast for VersionOne on adopting agile in the enterprise. Given our discussion yesterday around the five adoption and scaling patterns... I thought the link seemed timely. You will have to register on the VersionOne site to get access to the video... but I think you'll get some value out of it and it will be worth the obligitory sales call ;-) Click here to request the link...

Team Based Agile

Horizontal Scaling


First Order Agile Scaling

Second Order Agile Scaling

Third Order Agile Scaling


Enjoy!

Subscribe to Leading Agile

Wednesday, August 19, 2009

Agile Adoption and Scaling Patterns

Over the past few months of writing Leading Agile... doing the Cutter Paper... and now preparing to write this book... we've talked a lot about different agile adoption and scaling patterns in the enterprise. Specifically here we've talked about team based agile, first order agile scaling, and second order agile scaling.

As Dennis and I have noodled around on this... talked to clients... implemented and consulted... and tried to build out this framework... I think we've landed on a five phase roadmap that can be talked about with some degree of clarity. We'll go into detail on these over the next few weeks... but for now... I want to just put the model out there and see what you guys think:


Team Based Agile is what we mostly talk about when we talk about agile. We have Product Owners and Customers... we have ScrumMasters and Teams. We are 6-8 people... maybe all in the same room.. maybe not. We focus on solid engineering practices... collaboration... teamwork.

Horizontal Scaling is the next step. As the name implies... horizontal scaling is taking the team based model and replicating it in different parts of the organization. We see this quite a bit... pockets of agility across the enterprise... but no one is really working together in a coordinated way. Pretty much the same as team based... just more of it.

First Order Agile Scaling is basically Agile Project Management. It is the first time we start talking about how to get multiple teams working together to deliver an integrated product or project deliverable. This is where we first start thinking about the various Scrum of Scrum patterns we talked about a few posts ago.

Second Order Agile Scaling takes a collection of teams from the single project space into agile portfolio management. How are we going to break up projects and throttle them through the teams? This is where we really start to focus on lean and TOC and have to focus on enterprise priorities and investment decisions.

Third Order Agile Scaling is an area we haven't talked much about yet. This is where we take agile outside the product delivery organization. Getting projects out the door isn't our problem anymore... it's not our constraint. We need to start focusing on the integrating the value stream across the entire enterprise.

At each level of adoption and scaling... we plan to introduce a new set of organizational capabilities... and new set of desired outcomes... a new set of WHATs. At each level... we'll explore the agile practices... the HOWs... that can help enable those desired outcomes.

Think about this for me a bit and let me know what you think.

Subscribe to Leading Agile

Tuesday, August 18, 2009

The Agile PMI Community of Practice

The Agile PMI Community of Practice officially launches next week at the Agile 2009 conference... and there are LOTS of things going on!


For the full scoop on all the week's happenings... visit the PMI Agile Wiki to get all the details about receptions... events... and speakers. If you are going to are be in Chicago for the conference... if you are interested in Agile Project Management... you NEED to show up... and more importantly... learn how to get involved. I am planning to be at all the kick-off events and many of the sessions. If you happen to see me... please come up... say hi... and let me know if you have any questions.

On a related note... way back when Jesse Fewell decided to start this project... I had been involved helping to create a space for some discussion and arranging a little kick-off cash. When it came time for the real work... my schedule was too crazy... and I had to bail. Jesse let me off the hook the first time around... but now that the organization is a reality... he has asked me to come back and help the team.

For the next year... I have agreed to serve as a deputy Product Owner for the team... with the plan being to assume primary Product Owner responsibilities in year two. My schedule hasn't settled down at all... maybe with the book gotten a little crazier... but this was an opportunity I just couldn't turn down.

At the end of the day... no matter what I do... no matter where I am in an organization... I am a Project Manager. I think like a Project Manager... I act like a Project Manager... and I really like Project Managers. So... I accepted this role because I want to help Project Managers... and organizations... have more effective project management.

My goal is to evangelize to the PMI membership... help them understand why agile works... and why they need agile tools in their toolkit. I am also interested in bridging the gap the other way. I want to help the agile community get some value out of this relationship and learn where and when some of the stuff from the PMBOK can actually be useful.

It will be an interesting year! I hope to see you all in Chicago.

Subscribe to Leading Agile

Falling into the How Trap

Yesterday I talked a little about how companies focus too much on process... how they are doing their work... rather than the actual business outcomes they are trying to deliver. This is a really big problem that impacts all levels of the organization. I bet if you took a good look at your company you'd find great examples in your corner offices... and in your team rooms.

I'd like to take a moment to go over a simple example that I see over and over in the agile community. I hate to pick on Scrum again (the price of success?)... but Scrum is basically a HOW solution... a process... that solves a particular organizational dysfunction. We need things like business alignment and servant leadership... we need the ability to inspect and adapt and respond to changing business conditions. What Scrum gives us is Product Owners, ScrumMasters, Iterations, and Retrospectives.

If Scrum works though... why does this matter?

When we start thinking that the goal is to have a Product Owner... even a trained CPO... the focus shifts from WHAT we are trying to accomplish to HOW we are going to accomplish it. I need the business to be able to make prioritization decisions... I need clear direction on what to build next... I need clear requirements definition... I need user acceptance. The Product Owner is merely a HOW that satisfies the WHAT... in some contexts. What if my context changes?

What if I can't have a dedicated Product Owner for every team? What if in my company... the Product Owner role is too big for one person? What if I need to guide and coordinate multiple teams across multiple timezones? If I focus on implementing a HOW... the Product Owner role... I lose the opportunity to create new strategies that deliver the right business outcomes. If I focus on the WHAT... I am now free to craft a strategy that delivers value... AND operates within the constraints of my business environment.

Re-thinking the Agile Enterprise takes a systematic look at what we are actually trying to deliver... the core capabilities of our business... and lays out a strategy... a framework... for creating situationally specific strategies to scale agile in the enterprise.


Subscribe to Leading Agile

Monday, August 17, 2009

Why the Re-think?

"Re-thinking the Agile Enterprise: A Manager's Guide to Building an Adaptive Organization"

One of the consistent areas of feedback Dennis and I got on the book proposal was that folks didn't like the title. The initial reaction from our publisher was that many folks haven't even 'thought' about agile in the enterprise... never mind being in a position to 're-think' about agile in the enterprise. We decided to leave the title for now with the understanding that we might change it later on.

Just in case the title totally goes away... I want to explain why we chose 'Re-thinking the Agile Enterprise' for the Cutter paper... and ultimately for the book. First... I am a sucker for subtle jokes and puns. I know it's low humor... but I can't help it... it's the way I am wired. Second... the 're-think' in the title is actually a reference to something meaningful to the premise of the book. It's a subtle little play on words that I'd like to take a minute to explain.

Dennis Stevens and I have been working on the ideas behind this book for almost a year now. Prior to our partnership, Dennis worked with Ric Merrifield and Jack Calhoun on a Harvard Business Review article called 'The Next Revolution in Productivity'. Without going into too much detail... the article is about understanding your desired outcomes... understanding the stuff you do that supports your desired outcomes... identifying the capabilities supporting each activity... figuring out which are most important... and ultimately designing a more efficient operating model for your business.

On the success of that paper... Ric Merrifield published 'Re-Th!nk: A Business Manifesto for Cutting Costs and Boosting Innovation'. Ric's book builds on the ideas in the HBR article and establishes a new language... a new framework if you will... for thinking about the performance of our organizations. The basic premise is that most organizations spend way too much time, money, and energy thinking about HOW we get work done and not nearly enough time thinking about WHAT the value is we are actually trying to deliver.

The idea is that companies often fall into a HOW trap... where they get so focused on process improvement... they forget what the heck they were trying to accomplish in the first place.

So... with that as our backdrop... let's get back to the title of the book.

Dennis and I are writing a book to help software professionals... Development Managers, Project Managers, Directors, and Vice Presidents... get past the dogma of methodology... past the dogma of best practice... and start thinking about WHY they are doing the things they are doing... and back to the WHAT they are actually trying to deliver. The agile practices we talk about are often really HOWs... HOWs that allow those primary WHATs to manifest in our organizations.


Its the value behind the practices... the WHAT behind the HOW... that is really important. We believe this is the secret to sustainable agile adoption in the enterprise.

We'll see how the book title plays out... for now I wanted you guys to understand the reference and why we thought it was important.

Subscribe to Leading Agile

Sunday, August 16, 2009

Scrum of Scrums

Well... we got Agilepalooza in the bag. It was a great day. We had David Hussman, Guy Beaver, Jeff Sutherland, and Joe Little do talks. I did my Agile PMP talk... and FINALLY feel like I've got the slide deck telling the story I want to tell.


Good timing too.. I am doing that talk at Agile 2009, the PMI Global Congress, and Agile Dev Practices. About time I got it right ;-)

The day before the 'palooza... I got to do a talk on Agile Project Management with VersionOne for a local client. Jeff Sutherland was in the audience... and I've got to say... it was a little disconcerting talking about Scrum with Jeff in the crowd. He is a good guy and had nice things to say... but still.

Getting to spend some time with Jeff was pretty cool. One of the questions that came up had to do with handling a Scrum of Scrums. Jeff had an interesting take on the Scrum of Scrums concept that I had not heard before. He described the Scrum of Scrums as an abstraction mechanism. The Scrum of Scrum 'hides' the Scrum teams from the rest of the organization.

So often I hear people talking about the Scrum of Scrums as a place where the ScrumMasters get together to coordinate and share information. I don't think that definition is wrong... but it is incomplete. Jeff's description was big enough to accomodate some of the coordination teams I talk about here on Leading Agile.

The amount of coordination required is dependent on the number of dependencies between the teams:

No dependencies? Use a basic Scrum of Scrums. A basic Scrum of Scrums is where the ScrumMasters get together daily to go over impediments and coordinate activities between teams. This team is the abstraction layer between the Scrum teams and the rest of the organization.

Requirements dependencies? Use a Product Owner team. In addition to the normal coordination activities... the product owner team is reponsible for managing requirements across the Scrum teams. Any decisions that cannot... or should not... be made at the individual team level get made by the Product Owner team.

Technology dependencies? Use a Product Owner team with Architects. Adding the architect allows the Product Owner team to take into consideration the critical technology decisions that are going to span teams. In real life, this coordination can be as simple as lightweight design notes on the user story.. or as heavy as a simple architectural representations that the team uses as a baseline.

Integration dependencies? Use an Integration team. Integration teams are like feature teams that consume components or features generated by other Scrum teams. If you are in this place... you are almost guaranteed to have requirements and technology dependencies. The integration team has an actual staff of developers and testers that pull everything together.

While I have no idea if Jeff would agree with these four Scrum of Scrum models... I think they are consistent with his vision of the Scrum of Scrums as an abstraction mechanism between the teams and the rest of the organzation. For a little more on the whole Product Owner team idea... take a look at the post I did earlier this year on that very topic.

Photo source: flickr.com/photos/32286042@N00/3292030662/

Subscribe to Leading Agile

Leading Agile on Alltop

Have any of you guys ever heard of Alltop?


It's a pretty neat site that aggregates some of the best content on the net. They have custom pages organized by topic... you can create an account... and setup a custom page with all the stuff you are interested in reading about. Months and months ago I submitted Leading Agile for consideration for their site... today I got selected. Not a huge deal... but cool none the less.

If you haven't had a chance to visit the main site... or the agile site... head on over and take a look.

Subscribe to Leading Agile

Interesting Post... 8/10/2009 through 8/16/2009

It's Sunday morning and I'm enjoying my first cup of coffee of the day... decided it was time to do the third installment of my "Interesting Post..." update.

Every week I am amazed at the amount of great content out there just to be had for the taking. Thanks very much to all the great bloggers out there taking time to share their thoughts with the rest of us!

Interesting posts from the week of 8/10/2009... through 8/16/209

Friday Round Up http://bit.ly/Awl1A

Quote of the Day http://bit.ly/TBEP0

The Minimalist Principle: Omit Needless Things http://bit.ly/1p1s9v

Kanban for process improvement http://bit.ly/ce8xz

Agile Project Management: Risk Management http://bit.ly/NwUu5

The PO is part of the team, get over it! http://bit.ly/ee6PJ

Project Charter – Agile Project http://bit.ly/124qjJ

13 Scalability Best Practices http://bit.ly/2d32Bj

10 questions with Mike Cottmeyer http://bit.ly/15APJb

I come to bury Agile, not to praise him http://bit.ly/uoxCI

Interview with Alistair on InformIT 2009 http://bit.ly/4rRp7m

What is a large project? http://bit.ly/11eaw5

Top People in the Agile Business Intelligence and Agile Data Warehousing .. http://bit.ly/k1dYB

Running for the Agile Alliance board http://bit.ly/LWal8

Work as Play http://bit.ly/7hmwa

Follow the Baton Not the Runner http://bit.ly/24dWQi

Managers are not Super-You's... http://bit.ly/xjAnN

PMI Agile - Debate or Learning Opportunity? http://bit.ly/2Mj18b

5 Wrong Reasons To Apply Kanban http://bit.ly/2fnnVG

Defining Agile Management – part 1 http://bit.ly/OMsL0

Agile Project Management: Project Initiation - by Scott Ambler http://bit.ly/9lsbV

COBOL: Everywhere and Nowhere http://bit.ly/469Sft

Married to the Mob http://bit.ly/2A2SAe

Keeping Unscheduled Time http://bit.ly/8s7yi

The effect of values on system development project outcomes http://bit.ly/vOMJW

Subscribe to Leading Agile

Wednesday, August 12, 2009

Leading Agile... the Book?

I have some pretty exciting news... both for me...and hopefully for the regular readers of Leading Agile. A few months ago, Dennis Stevens and I pitched and idea for a book to Addison-Wesley. Well... today we hit the jackpot... we got a contract. The book is tentatively titled 'Rethinking the Agile Enterprise" and... like the Cutter paper... covers much of the material I talk about on this blog.

What's the one-line pitch?

This book lays out a lean strategy… and an actionable framework… for organizing teams, projects, and programs for successful enterprise software delivery

What's the book about?

This book marries three core concepts into an actionable guide for building an adaptive organization. First… the book asserts that adaptive organizations are built around teams. We explain how to form teams… why teams work… and how agile and lean concepts can help managers establish high performing teams. Second… we explain how teams work together to deliver against the larger goals of the organization. This gets into lean project management, program management, and portfolio management. Lastly… we discuss a specific tool called capability modeling that helps organizations decide where to focus their energy to get the greatest return on their investment.

Why is it Important?

Companies are interested in becoming more adaptive… more agile… not because they have an interest in Scrum or XP… but because they are trying to deliver value to market faster than their competition. Most of the current agile literature does not address the real problems facing complex organizations. The literature assumes everyone is organized around small cross functional teams that build software features. Many of these books advocate transition strategies that are not practical for the enterprise and cannot be implemented at scale. The market needs a book that meets business leaders where they are… and helps them get to where they need to be. We are advocating a targeted and disciplined approach to becoming more agile across the entire enterprise.

Why will anyone care?

Business leaders are trying to implement agile methodologies but are not fully aware that their underlying organizational structure is negatively impacting their ability to change. This book provides a starting place for sorting through the complex set of decisions required to implement widespread organizational change. Mike and Dennis explain the strategies… principles… and tactics required to systematically build a more adaptive enterprise.


How you can help

Clearly... clearly... over the next year... Dennis and I will be blogging around the topics we are writing about. Please give us your feedback and share your ideas for making the book better. As chapters are ready... we'll need reviewers. When we get that far... I'll reach out to you guys for your help.

This is going to be quite an adventure and a REALLY, REALLY busy 15 months!

Subscribe to Leading Agile

10 Questions with Mike Cottmeyer

Last week I did an interview with Bob Williams from The Merchant Stand blog.


Bob and I go back a ways... he was the Product Manager for a team I did some project management for many, many years ago. He and I have stayed in touch... and it's been fun to watch as his interests have moved from product ownership and into e-Commerce and Internet Marketing.

Bob's questions centered mostly on how I transitioned from traditional project management to agile project management and what I see as the future of the agile movement. Head on over and take a look if you are interested. Here is a direct link to the post.

Subscribe to Leading Agile

Tuesday, August 11, 2009

Is Quality an Absolute?

Last week I did a post called "The Hard Reality". I made the point that anything you build... any document you create... that doesn't result in revenue for the business... is wasting time and money. Personally, unless you build software as a hobby... I am not sure how you can argue with that.

We build software so we can sell software.

One of my readers made a comment that my post was one sided. Peter's point was that we shouldn't subordinate quality, performance, time to market... and any other number of other software metrics... for the sake of making money. Okay... sure... but who says you have to build crap?

My point was that there are lots of teams building great software... teams that think they are doing great work... teams with great culture... defect free code... and terrific velocity... that are still not making any money. If you build crap... I doubt anyone will buy it. On the other hand... what good is high-quality software if no one uses it?

Value is about building a product of sufficient quality that people want to use.

At the end of the day... value is determined by the people who buy our products. Personally... I don't believe there is an absolute here. We have to balance the time, cost, scope, and quality constraints to get products to market so people will give us money to keep going. At the end of the day, selling software is a prerequisite for being paid to build software.


Subscribe to Leading Agile

Sunday, August 9, 2009

Take the 4th annual VersionOne 'State of Agile Development' Survey





It's that time again... time for VersionOne's Annual 'State of Agile Development Survey'. If you haven't had a chance to fill it out yet... please go do it now! This is the 4th time we have done this... and the survey is really generating some great data around how our industry is maturing and what all of us think is important.

Last year we had over 3000 people respond to the survey and we are looking to shatter that record this year. Once you fill out the survey... you are eligible to win one of three Amazon.com gift certificates... top prize is $750 bucks!

Click here to take the survey now!

Subscribe to Leading Agile

Interesting Post... 8/2/2009 through 8/9/2009

Okay... time for the second installment of "Interesting post...". Last week I decided to aggregate all the great content I share over Twitter into a single blog post. The only comment to the post was from one of my regular readers... Kevin Schlabach:


"But having said that... I'm not sure this will work for blog format. The Twitter thing is about knowing where the crowd is forming and talking. Here, it just feels cluttered noisy, and aged... yesterday's information. Try it out... I'm curious how others will feel about it."

Ouch! In all honesty... I might agree with him... not sure yet. The point is that if you like these summaries... I need to hear from you. So... with our little bit of feedback in hand... it's time to get busy. This installment takes us from last Monday through today. There were lots of great articles out there this week. If you missed any of my tweets... now is the time to check them out.

Interesting Posts from the week of 8/2/2009... through 8/9/2009

The effect of values on system development project outcomes http://bit.ly/vOMJW

Should Programming Work be Billed in Hours? http://bit.ly/JToEp

20 Reasons Managers Fail and Ways to Fix Them http://bit.ly/zX1Ap

QUOTE: By far the dominant reason for not releasing http://bit.ly/1ie6uy

Approaching a Minimum Viable Product http://bit.ly/WLy9s

Organizing at Scale: Implementing Spanning Features http://bit.ly/162GuQ

Back Blogging Again http://bit.ly/6R4kB

Earned Value and Agile http://bit.ly/e1P00

A Note on “The Tool is the Method” http://bit.ly/HGaGm

Agile Role playing http://bit.ly/ighJl

The Agile Way - by Scott Adams http://bit.ly/SfxID

Lean Does NOT Turn People into Robots http://bit.ly/Ppb9d

Agile Project Initiation Survey http://bit.ly/a8RkI

What is a Project Manager http://bit.ly/YIfDu

The power of writing http://bit.ly/BsaQb


Agile Documentation, what is it http://bit.ly/4sTapt

Update on Agile 2009, August 4, 2009 http://bit.ly/7SeqG

Before agile came along, life was easier for me... http://bit.ly/4BTcGX

The Early Problem Problem http://bit.ly/MVszb

Why meetings are so disruptive http://bit.ly/9dhhW

Scrum of Scrums: Making it visual http://bit.ly/sIe0M

Risk Management Resources http://bit.ly/18roXj

Your Life, Simplified http://bit.ly/URNjW

Risks and Issues Are Not The Same http://bit.ly/3fvizp

Lean Is Bigger Than We Thought http://bit.ly/p6nko

The Heart of Scrum http://bit.ly/ye8TG

Software Project and Process Measurement http://bit.ly/HsBLp

Strong opinions, weakly held http://bit.ly/3LXmkE

Three Key Principles when Leading without Authority http://bit.ly/E94ft

Subscribe to Leading Agile

Friday, August 7, 2009

Why Blog?

Anybody who pays attention to this blog knows... that for the most part... I write a lot. Its a pretty big commitment... and while I have gotten better over the past few years... I still sometimes spend 2-3 hours on a single post. So... one question I ask myself periodically is why I am doing this... and does it add value?

I wanted to share with you guys my thoughts around the reasons I've made a commitment to blogging:

I want to help others get better...

Somewhere along the way I missed my calling to be a high-school math teacher. Leaving high school... that is what I wanted to do... and really only decided not to teach because teachers overall are so poorly paid. Its somewhat entertaining to me that in my late teens I decided not to get a teaching degree and some 20 years later I have started a small private school and teach software methodology for a living. I think that I have that gene in me somewhere that loves to see the expression on someone's face when they finally 'get it'.

One of the things I consider a hallmark of my writing is that I always try to blend ideas and figure out how to make complicated things simple. I love trying to better understand stuff and present it to others in a way that is straightforward and direct.

I want to learn things for myself...

Most of what I write about is either directly or indirectly related to experiences I've had with clients or stuff I am talking about with folks in the community. Much of what I have been exploring the past few months has come out of my collaboration with Dennis Stevens and my attempt to apply some of those concepts in the wild. At the end of the day I am a problem solver... I need to know why things work. I need to understand where conventional thinking breaks down... and when it is time for something new.

I try to not to write about stuff that is half-baked... but there is definitely an element of noodling around and figuring stuff out as I go. If you see me get stuck on a topic... you can bet I have a real life problem I am trying to solve or looking for a way to better communicate something. I call those 'series' ;-)

I want to get better at communicating ideas...

As I am figuring stuff out... writing about it helps me get really clear about what I am trying to say. Some of what I am writing about now are ideas that I have been applying for years... I just didn't always have the language to explain what I was doing to other people. The nature of my job requires that I am clear and articulate about ideas that can oftentimes be very difficult to explain. The act of writing forces me to clarify my thinking and develop language to express my thoughts.

By writing I gain a better understanding of what I am trying to say. I can't tell you how many times I get asked a question where I fall back to language and ideas directly from some post on my blog. Hopefully all this thinking and writing and exploring helps others understand better as well.

I want to promote myself and my company...

While this isn't the primary reason I blog... I am definitely focused on promoting VersionOne as a company and myself as a thought leader in the agile community. I would be lying if I said I didn't care about my Google Analytics and my FeedBurner subscribers. I am very interested in my Page Rank and my Technorati authority. It's definitely cool to see how my writing impacts the community... what gets re-tweeted... what gets shared on DZone. Along the way... I've learned a lot about when to post... how to post... and what activities will influence traffic and interest.

Regardless of that though... I think I would write no matter who was paying attention. It's funny how doing this just kinda becomes a part of you. Blogging has become part of how I process information and form new ideas. I sincerely appreciate that you guys are along for the ride!

Subscribe to Leading Agile

The Hard Reality...

We all want to be really good at what we do... we strive to get better... we want to think that we are making a contribution to the success of our organizations... we want to think that we are adding value. The hard reality... and one we NEED to really come to grips with... is that sometimes we are doing great work... sometimes even building great working software... that has NO market value.

If our activities don't result in marketable, sellable software... we are wasting time and we are wasting money.

We might justify this to ourselves by saying that we can only control within our circle of influence... that we have to be the best we can be within the areas we can control. Maybe... but if you get really good at creating design documents for projects that get killed... it is still waste. If I build features for a system that never gets sold to a customer... it is still waste. If I build services for a component that never gets consumed by the application... it is still waste.

Anything you document... or code... or test... or even deploy... that doesn't get sold to a customer is ultimately waste. It doesn't matter how good... or how fast... or at what velocity you do your work... unless it sells... you have wasted time and money building it. And that... to me... is what makes Lean such an interesting topic right now...

Scrum really brought home some powerful ideas... revolutionary ideas that have changed how we think about product development. We've learned the value of building organizations around teams and the value of self-organization. We've learned to give the business the power decide what and empowered the team to decide how. Scrum helped us learn that real improvement comes from keeping everything visible and removing the impediments that are really slowing our teams down.

Lean brings a relentless focus on value... not just valuable software... but real delivered value to our customers. Lean expands the concept of value beyond just the product delivery organization... it recognizes that the enterprise value stream often includes other parts of IT... and other parts of the business. Lean gives us language and principles to really scale agile out to the enterprise.

Individual performance doesn't matter... team performance doesn't matter... until we can figure out how to bring it all together into something we can actually sell.


Subscribe to Leading Agile

Wednesday, August 5, 2009

Working Software or Customer Value

A few years back when I was still doing hands-on project management work... I used to teach internal classes on iterative and incremental product development. Officially... we were teaching a very light-weight instantiation of the Rational Unified Process. Unofficially... we were teaching agile values and principles within more of an Agile Unified Process framework.

The audience was always full of hard core waterfall folks... developers... testers... business analysts... project managers... one of the main things we'd try to talk about was the idea of frequent delivery of working software. I'd explain that charters and market requirements documents and detailed design specifications were not what provided value to our customers... all our customers really cared about was the working software.

Inevitably... someone from the audience would raise their hand and ask the question: Are you telling me that these detailed requirements documents... the ones I spend months and months creating... are not valuable? Are you telling me that the only one delivering value on the team were the developers?

I'd have to carefully explain that while those things were valuable... to the extent that they enabled communication... to the extent that they helped people understand... they were not the value that our customer's expected. If we had to kill the project 3 months in... would you rather have a detailed specification or an increment of potentially shippable code?

The potentially shippable code is always going to win.

The same idea holds for organizations with multi-part... multi-step value streams... organizations where it takes the activities of several teams working in coordination to deliver value back to the business. Even the smallest organizations... organizations with the simplest value streams... are going to need sales and marketing and support to deliver a viable product to market. Software doesn't usually sell all by itself.

More complex businesses... businesses with more complex value streams... are going to need not only sales and marketing and support... but also the ability to integrate the outcomes of many feature teams and component teams to get a product into the hands of their end-users. Does it do us any good to invest in one part of the value stream if the other parts are falling behind? Value is only created when all the parts are integrated into one cohesive whole.

So... when one part of the delivery organization gets too far ahead of the other parts of the delivery organization.... be it by writing all the requirements up front... or by building out one part of the component architecture too far ahead of all the others... it is easy to start confusing valuable activities with real value delivered into the product. It is especially easy when all that activity results in great team velocity and real working... albeit incomplete... software.


Subscribe to Leading Agile

Tuesday, August 4, 2009

Agilepalooza Charlotte


Okay guys... if you are going to be anywhere near Charlotte, North Carolina next week... you have to find your way to the first East Coast Agilepalooza! We have a lined up a great group of speakers for the event... Jeff Sutherland... David Hussman... Guy Beaver... Joe Little... and yep... yours truly... Mike Cottmeyer.

Agilepalooza is a not-for-profit community event sponsored by VersionOne. It is meant to be a fun, low cost gathering that brings internationally recognized coaches and trainers into the community for a day of learning and advancing agile methods. None of the speakers are paid to present or participate... they are offering up their services simply to support the community.

For the low, low price of $69... attendees will get a full day of agile learning, breakfast, lunch... and a rockin' good time. If there are funds left over... they will go directly back into the Agilepalooza program or be donated to the local agile user groups supporting Agilepalooza. Go... now... register!

Subscribe to Leading Agile

All About Agile... Guest Post

A week or so ago Kelly Waters reached out and asked me to do a guest post for his blog All About Agile. Kelly has been writing on Agile topics for a while and was one of the first bloggers that I ever started following. Needless to say it was quite an honor and I was happy to contribute. My post is called "The One Million Dollar Question"... it's about teamwork... and I think you'll like it.


Hop on over and take a look... and if you are not already subscribed to Kelly's blog... I highly recommend you take this opportunity to do so. Happy reading!

Subscribe to Leading Agile

Monday, August 3, 2009

Comparing Value and Velocity

Is there a difference between the value a team delivers and their velocity? Said another way... if I increase the velocity of the team... aren't I getting more value from them over time? Like so many things we talk about here... the answer really depends on your context.

You might be inclined to make the argument that velocity is really just a measure of how many story points the team can complete in a given iteration. There is no explicit dealing with value... only relative size. But... if the Product Owner is prioritizing the backlog... and asking the team to deliver the highest value features first... isn't there an implicit correlation between value and velocity?


My take is that there is a correlation between value and velocity at the team level... it is when we get beyond the team that relationship starts to break down.

Think about this scenario... let's say them team is cranking out feature after feature... adding great stuff to the product... their velocity stabilized a few sprints back and is getting better and better every iteration. The company has a great product but a terrible sales team and even worse marketing. While the product is technically superior to their competition... how valuable is it if no one buys it?

You might make the case that all those really cool features ended up having very little value to the market. Great velocity... not so much value.

Here is another scenario for you... let's say you have four teams that have to work together to deliver a new product suite to the market. Teams A, B, and C have fantastic velocity but team D just hasn't been able to get their stuff together. Team D ultimately delays the release... and the overall product is late to market. In the meantime... the competition just released the latest version of their product and yours doesn't do so well.

How much did the velocity of teams A, B, and C help the overall value of your product? Again... great velocity... not so much value.

Okay... last one. Let's say you have 7 component teams that have to deliver features into several major architectural sub-components. All the teams are rockin'... they have met all their high level milestones... they know where they need to take their part of the project. One of the teams realizes a significant risk and their velocity tanks. The rest of the teams keep going... they are building great stuff... stuff that certainly has to be built someday... but again... that one team causes us to delay the release.

Most of the teams were doing great... one team not so great... where did all the value go?

Lean tends to take a broader look at value delivery across the entire value stream... across the enterprise... Scrum by it's very nature tends to look only at the delivery team. So... at the single team level... you can make a great case that there is a correlation between velocity and value. It's an implicit link, but it is there. When you start looking outside the team... across the entire value stream... that is where the correlation between value and velocity starts to break down.

When the Lean folks say that Scrum focuses on velocity and Lean focuses on value... as I see it... this is the reason why.

Subscribe to Leading Agile

Sunday, August 2, 2009

Be a Get Things Done Guy

I don't want to be a Scrum guy. I don't want to be an XP guy. I don't want to be a Lean guy... or a Kanban guy... or a DSDM guy... or a RUP guy... or a PMI guy. For that matter... I don't even want to be an Agile guy.

As my experience has broadened over the past few years... as I have worked with more and more teams... it seems that most any process can be successful... even Waterfall... with a great team of engaged human beings... passionate... and working toward a common goal.

It seems that most of the time... when we start comparing one way of doing things with another... we tend to compare our best process implementation with the other side's worst. My last waterfall project came in exactly on time... within one percent of budget... with all the scope originally asked for.

And yes... the product was very successful in the marketplace.

Can I please just be a 'get things done' guy? To the extent I can use Scrum or XP or Lean or Kanban or DSDM or RUP or PMI to be a 'get things done' guy... that's what I really want do. To the extent that these labels... or even the processes themselves... get in the way of delivery... we'll figure something else out.

The bigger the tent... the more tools we have at our disposal... the better chance we have to be successful. At the end of the day... it's about delivery.


Subscribe to Leading Agile

Interesting Post... 7/26/2009 through 8/1/2009

If any of you guys are following me on Twitter... one thing you'll notice is that I forward along a lot of great agile content. I've got over 400 blogs that I track on a weekly basis... and while I clearly don't read them all... I do scan them looking for things that might be of interest. When I come across something cool... and I think it will be of value to the community... I share it in Google Reader and the cloud does the rest.


The result is a Twitter update with a link to the blog post I just shared.

I thought it might be an neat experiment to do a Leading Agile article with all those "Interesting posts... " aggregated into one place. I'll give it a go for a week or two... see how big a pain it is to create (and how much I can automate)... listen for your feedback... and we'll see where to go from there. So here it is... your first summary of all the "Interesting posts..." from the week. Let me know if you like it.

Interesting Posts from the week of 7/26/2009 through 8/1/2009

Interesting post... Managing Expectations - Better Agile Managers http://bit.ly/WKz1a

Interesting post... The Daily Scrum Exercise Program http://bit.ly/wz5p

Interesting post... Organizing at Scale: A Basic Scrum Framework for Enterprise Teams http://bit.ly/uAHKQ

Interesting post... Power and influence http://bit.ly/4EhWNa

Interesting post... Structure and composition of agile teams http://bit.ly/IqV15

Interesting post... Connecting Agile Teams with the Business Strategy http://bit.ly/f3B4w

Interesting post... Funding Agile Projects http://bit.ly/Bnbjw

Interesting post... Software Engineering is Dead? http://bit.ly/zDWPv

Interesting post... Project Estimation http://bit.ly/36KgS

Interesting post... Kanban Features in VersionOne http://bit.ly/2xho2

Interesting post... DONE vs. Complete... http://bit.ly/20oVPl

Interesting post... Embrace technical debt http://bit.ly/18I66f

Interesting post... One impediment at a time http://bit.ly/5nJlf

Interesting post... UnTeams and Real Teams http://bit.ly/mvxPd

Interesting post... Lean & Kanban 2009 Videos Available http://bit.ly/Rblqp

Interesting post... Kanban Blogosphere Roundup July 27th http://bit.ly/16pFdk

Interesting post... Post agile, one third of you will be gone... http://bit.ly/VucMW

Interesting post... Running for the Agile Alliance Board http://bit.ly/usPeW

Subscribe to Leading Agile