Leading Agile in the Top 200

Jurgen Appelo has released the latest installment of his Top 200 Blogs for Software Developers. Leading Agile has managed to creep it's way up to the number 30 spot. Just to put this into perspective... just two quarters ago Leading Agile was sitting outside the top 100 at the 105 spot. Last time around Jurgen had Leading Agile at 56. This blog has jumped 75 places in just about 6 months. That is pretty cool. I appreciate all you guys for making this blog what it is... and I appreciate Jurgen for continuing to keep score ;-)

Subscribe to Leading Agile

Stability first... then speed!

So many folks want to flip a switch and magically become agile. They want all the benefits without any of the hard work that comes along with really transforming the organization. People think that just because they read a book... or took a few days of training... that they can expect instant productivity. They don't realize that agile methods only show you your problems... it is still up to you to fix them.

I'll often see this thinking manifest in questions like "how many iterations until I can expect my team's velocity to start going up". There is so much underneath a question like that, it's hard to give a solid answer. Is there a prioritized product backlog? Is there a product owner grooming the backlog and available to the team? Is the team cross-functional? Are they dedicated to the project? Do they have everything they need to be successful? Are there external dependencies?

All those things matter... and right out of the gate.. you are not quite sure the kind of impact those answers will have on the team's ability to deliver.

My recommendation is generally to look at team performance in three phases. The first goal is to measure what is... to establish a performance baseline. Next start thinking about getting stable... stable performance is key to running a predictable agile project. Once you are stable... now you can start thinking about getting faster. Adopting agile is a learning process and you can't improve a system when you don't understand what is broken.

And that is really the key... it isn't about getting a better velocity. It's about fixing the broken parts of your organization. It's about looking at where you are and comparing it against where you would really like to be. It's about understanding the impediments standing in your way and dealing with them in a meaningful way... in a way that really, truly helps the team get better. It's about getting more efficient at creating value and really improving the processes that allow value to be created.

Those kinds of answers don't translate into a great marketing pitch. How long will it take to get agile? I don't know... how many iterations will it take to remove the organizational impediments that are slowing the team down? How many iterations will it take until you are willing to fix what is really broken? How many iterations until we are ready to stop applying labels and start REALLY transforming the organization?

Subscribe to Leading Agile

Change is the only constant...

Last week I mentioned that I was pretty much consumed with some big things going on in my life. Well... I am finally ready to share some really big news. This week I am leaving VersionOne and joining Pillar Technology. It is a bittersweet announcement... so I want to accompany this announcement with a little backstory.

Two years ago when I joined VersionOne... I set off on a journey. At the time, joining VersionOne felt like a huge risk. I was going from a company that had twenty thousand or so employees to a company that had less than 100. I was going from a company with a diverse product set to a company that really only had one. I was going to stop managing projects for a living and become a trainer and consultant.

My wife and I talked about the fact I would now be on the road more... sometimes with only a few days notice. I'd be travelling overseas and going to conferences. We talked about what this change would mean for our kids... my career... our finances... and my employability should I ever decide to do something different. It was just a huge unknown... but it was exciting. It felt like the right thing to do and the risk seemed manageable.

Looking back with a little hindsight... it was the best of all possible opportunities. I've had the chance to work with some great people... the VersionOne folks are truly the best in the industry. I've had the chance to work with some excellent companies... companies who recognize that the status quo is no longer going to be enough. I've had to the opportunity to work with, and become and expert on, the best agile project management platform on the planet. I've had the opportunity to become a public speaker... find my voice as a blogger... and now as an actual author.

I really love working for VersionOne but for the past few months I've been thinking that it might be time to get back into the world of delivering projects. Even though having exposure to a diverse set of companies is huge and my pre-VersionOne experience was still extremely relevant... I wanted to get back out and build longer term relationships with people that are in the thick of building agile organizations. I wanted to get in and help lead change in a more meaningful way. I wanted to be a part of building the enterprises that I write about here on Leading Agile.

I didn't really know what life after VersionOne might look like. I always felt that if I worked hard and made a positive contribution to the community... things would play out. I recently started toying with the idea of becoming an independent coach or possibly starting a boutique consultancy. Having a stay at home wife... a mortgage... and three kids that like to eat... those options always felt pretty risky. I wasn't sure as a start-up that I'd be able to have the kind of impact that I really want to have. I need to be able to scale... and scale fast.

Enter Pillar Technology.

I first encountered Pillar Technology last year at the Agile Coaches Camp in Ann Arbor. I was impressed with them from day one. Everyone I have ever met from Pillar has been top notch... not just from a technology perspective... but as human beings. Pillar does great work and has fun doing it. I liked these guys before I ever started thinking about working for them... so when we started talking it felt like it could be a good fit.

What makes this move more interesting for me is that I am not going to Pillar as just an agile coach... I am going to build an agile consulting practice in the Southeast. Pillar is already the premier agile consultancy in the Midwest... I am going to help them go nationwide. I'll have the resources... and the talent... at my disposal to really help organizations lead the kind of transformations I am so passionate about. Now when I talk about learning to do small team agile... I can bring in the developers and coaches to help make it happen. I will be able bring in the kinds of leaders that can help organizations learn what it means to do agile project and portfolio management. We can help lead real... enterprise level transformations.

While the move to Pillar comes with some mixed feelings... joy over the new opportunity... sadness over leaving my friends at VersionOne... I am convinced this is the right 'next move' for me and my family. Pillar Technology is a VersionOne business partner and I am still just a few miles away from the VersionOne offices. I am looking forward to co-branding a few white papers and doing some joint webinars over the next year. I'll still be representing VersionOne at the PMI Global Congress and helping out with the upcoming Agilepalooza in Boston next month. There is tremendous synergy between our shared missions.

I will say though... if you ever thought... hey! it would be cool to have that Mike Cottmeyer guy come and do some work for my company... now might be a good time to reach out. For now... you can contact me on my personal email mike [@] cottmeyer [dot] com. Let me know what I can do to help. Even though I am going to focus on the Southeast US... there is no limit on where we can work together.

One last story and then I'll let you guys get back... when my wife got pregnant with our first son, we were living in Michigan. We knew that wasn't where we wanted to live so we started making plans to move. During that time, we were saving a down payment on our first house, getting ready to move to Georgia, getting ready to have a kid, Kimi was going to be a stay at home Mom, and I was going to start a brand new job within my company.

Over the past 10 or 15 years our family has probably experienced at least two more... maybe three... periods of extremely disruptive change. Some periods centered around kids... some around jobs.. and others around changing location. Most seemed to have something to do with all three. So while we don't have any more kids on the way... I am still planning to birth my book... build a business.. and maybe a few other things I've been noodling on. When I decide to shake things up... I really like shake things up ;-)

Subscribe to Leading Agile

Interesting Post... 9/13/2009 through 9/20/2009

Sunday morning... still raining here in the ATL. Let's get down to business. Here are all the most interesting posts from this past week. Hope you enjoy.

Interesting posts from 9/13/2009 through 9/20/2009

Project Management 2.0 - How Can It Be Described http://bit.ly/HUj8F

Does the productivity decline if you don’t time box? http://bit.ly/lvlxj

How do you measure software quality? http://bit.ly/9LRfD

KanBan Redux http://bit.ly/2ZD6n4

Do What’s Effective For You http://bit.ly/2kUxh

I have heard of kanban! http://bit.ly/9XvTF

Have you heard of KanBan? http://bit.ly/TRH19

Theory of Constraints and Big Agile http://bit.ly/3H4K9M

The Only Lean Path is an Unclear Path? http://bit.ly/COw1f

The Poppendiecks on Lean http://bit.ly/Seb4E

How to Be Childlike http://bit.ly/1ayQJX

Creative Solution Finding and Big Agile http://bit.ly/2eXSYr

Top-down and Bottom-up Project Management: Leveraging the Advantages of t.. http://bit.ly/VDYbe

The Problem With Planning http://bit.ly/4GfuJc

The empowered consumer yesterday, today, and tomorrow http://bit.ly/KtV3g

Scrum and Kanban - Like Chocolate and Peanutbutter http://bit.ly/EkR8A

What Does It Mean To Have A Plan? http://bit.ly/7J5NB

Agile Mentor Newsletter http://bit.ly/9MXRZ

Thoughts on Lean Thinking http://bit.ly/oHbDL

More on Servant Leadership http://bit.ly/FnASl

Performance without Appraisal: Build Feedback into the System http://bit.ly/1ZvJYO

Time, Budget, Scope http://bit.ly/2pmJ

against kanban part 2 http://bit.ly/TowCZ

Using User Stories http://bit.ly/3ExoxY

Ssssh….Agile Is All About Micromanaging http://bit.ly/Rig4G

Mockups and Simulated Data helps with Agile Development http://bit.ly/Fx5It

One Piece Flow -- Transitioning from Scrum to Kanban Part II http://bit.ly/AsgGM

Transitioning From Scrum to Kanban, Part 1 of 3 http://bit.ly/17lqGd

Subscribe to Leading Agile

Writing on a Rainy Saturday...

It was kind of a weird week. Had lots of stuff going on that really took all my attention. I hate to go all five days of the work week without being able to manage even a single blog post. That said... I have been able to get down a few ideas that I plan to write on next week. The only wildcard will be a trip I've got booked to Portland.

Sometimes travel results in more writing... sometimes less... we'll just have to see.

For now... I wanted to point you guys at some work Dennis has been doing on our book over the past week. The week before last I did a few posts documenting some of the major themes of our book. This past week, Dennis did some of the same.

• An Irrational Approach to Change Management
• A Model for the Agile Enterprise
• The Fifth Discipline and the Agile Enterprise
• Creative Solution Finding and Big Agile
• The Theory of Constraints and Big Agile

I'm just about to the point where I feel good about putting together the first and second level outline of the book. Hopefully that will result in some momentum and maybe a chapter or two over the next few weeks. We'll see how things play out.

Subscribe to Leading Agile

Coming to Consensus

It's one thing to do stuff... it is quite another to write about what you do. It is tough to be clear and articulate; always making sure to leave your reader in a better place than when you got them. I've learned that the hard way over the past few years while doing papers for VersionOne and writing this blog. That said, collaborating with Dennis on the framework for our book has taken this challenge to a whole new level.

Over the past few days I stopped writing about the book because we hit a bit of a wall. We knew some of the words we were using were overloaded. What we didn't realize was how much that overloading allowed us to have a conversation without having any idea what each other were talking about. Okay... that might be a little strong... but getting through it was pretty frustrating. Having two strong willed, capable dudes... both with a strong vision and sense of direction... trying to merge complex ideas into something simple and digestible has proven pretty challenging.

That said, I think we made some headway this week around our use of the word Capability.

Last week I talked about three types of capabilities: Value, Core, and Supporting. I had described Value Capabilities as the stuff we provide back to the business... stuff we might sell to an actual customer. Our problem wasn't that Value Capabilities don't exist... it's just that in our model all capabilities have a value attribute. I inadvertently overloaded the word Value as well as the word Capability. From here out we are going stop using the expression Value Capabilities and replace it with the idea of Product Capabilities. Same concept, different language.

I've never been a big fan of how we were using the expression Core Capabilities. Again... it's not that these kinds of capabilities didn't exist... its just that describing them as core didn't prove descriptive enough and led to some confusion. We'll keep the category basically the same... it will include all the stuff we directly do to deliver the Product Capabilities... stuff like writing software and testing... but we are going to call them Delivery Capabilities. It seems a little more descriptive for the purposes of our conversation.

Finally, we talked about the idea of Supporting Capabilities. I had described these as the things you need to be good at to support your ability to deliver Product Capabilities. I had included environmental things like building CI environments, invoicing and collecting payments. I had also included stuff like managing the project and communicating status. Dennis has convinced me that we need to separate these into two categories. To that end, we are now going to think about these in terms of Supporting Capabilities (CI environments, invoicing and collecting payments) and Controlling Capabilities (managing the project and communicating status).

Again the specific capabilities in each section might ebb and flow as we get deeper into the conversation but I think we have the major categories right. The story around capabilities is really important to our core message. As you adopt and scale agile... the core things you DO to deliver product get expressed differently at each level of the five phase adoption model. For us and for the book... this was an important idea to get worked out early in the writing process.

Subscribe to Leading Agile

Interesting Post... 9/6/2009 through 9/12/2009

Time for another (almost) weekly installment of Interesting Post. Every week I feel like the number of agile related articles was pretty light... but then I go to build this post... and realize there was a ton of great content out there. I guess I just want more ;-)

One thing to keep in mind though. I think these are ALL great articles... very insightful... very interesting... but I don't necessarily agree with every point they make. I chose the tag "Interesting Post..." very carefully. I share these posts because I think they contribute to the conversation in a meaningful way... sometimes I agree... sometimes I don't. So with that...

Interesting posts from 9/6/2009 to 9/12/2009

Friday Round Up http://bit.ly/1sKBAb

Plan the Work - Work the Plan http://bit.ly/OR1aU

Agile is never 'no process' http://bit.ly/3fEVO6

ScrumBut – Part 5 – Retrospective after every sprint http://bit.ly/MhIJW

Leading by saying No – The New CIO Series http://bit.ly/30nEuL

An Irrational Approach to Change Management http://bit.ly/1vBKbn

Proceedings of Lean & Kanban 2009 http://bit.ly/35bx0d

Business Agility – Dynamism or Stasis http://bit.ly/kvNhn

ScrumBut – Part 3 – Daily Scrum http://bit.ly/4u5Ql0

Managing Leaky Organizations http://bit.ly/fWEr5

Download "Do It Yourself Agile" For Free! http://bit.ly/fzBR3

Eliminate Architecture http://bit.ly/baNJx

Time, Budget, Scope - Pick Two - NOT TRUE http://bit.ly/3qYL0g

For $65/pp, Send Your Whole Team to Agile Training in Boston Oct 5th http://bit.ly/4DVVHx

Many Contracts Have Wrong Focus http://bit.ly/xssNm

The faster we go, the tighter we cling http://bit.ly/96DHE

Achievable avalanche opportunities http://bit.ly/lDIGT

Applying the Decoupling Principle to Scrum http://bit.ly/3nuaLB

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

Project Failure Sins and How to Stop These Sins http://bit.ly/2BaI4d

ScrumBut – Part 2 – Team members sit together http://bit.ly/3OkVAB

Why I Hate Document Templates http://bit.ly/CMwU3

ScrumBut – Part 1 – Timeboxed Iterations http://bit.ly/REacd

ScrumBut – Part 0 – Introduction http://bit.ly/c4z9R

Toward a Next Generation Capability Maturity Model http://bit.ly/UHNZI

On Paper I Was Once a Millionaire http://bit.ly/imPmb

Run this one through Babelfish... http://bit.ly/ERKHK

Shu Ha Ri for Kanban systems http://bit.ly/fI5fx

The Best Leadership Is Good Management http://bit.ly/2bL1lN

'All About Agile' Is No More! http://bit.ly/R3fVj

D = V * T : The formula in software DeVelopmenT to get features DONE http://bit.ly/12KDvF

Subscribe to Leading Agile

My Open Space De-brief at Agilepalooza Charlotte

You guys might get a kick out of seeing me in action. This video is me debriefing an open space session at Agilepalooza Charlotte a few weeks back. The topic is on scaling scrum in the enterprise. Our group discussed the four scrum of scrum patterns we've talked about here over the past few months.

It is totally weird watching yourself on video...

Subscribe to Leading Agile

Managing Expectations about Uncertainty

One of the biggest differences between the PMI crowd and the Agile crowd has to do with our expectations about uncertainty.

The PMI crowd generally believes that a Project Manager is supposed to manage uncertainty out of the project. The Agile crowd tends to believe that uncertainty and change is something that should be embraced. Rather than managing OUT uncertainty, the agilist chooses to manage FOR uncertainty.

This difference fundamentally influences how we go about the business of planning projects... the artifacts we create... and how we interact with and manage our teams. The reality is that both worldviews have a place depending upon your context and problem domain. It's up to us [as Project Managers] to recognize the nature of the projects we are working on and choose the strategy most likely yield a desireable outcome... for both our project stakeholders and our external customers.

We cannot check our brains at the door and blindly follow ANY methodology. It's up to us to assess our situation and choose an approach that is suitable for the task at hand.

Subscribe to Leading Agile

Leading Agile... 200 Posts and Counting!

I wanted to take a minute this morning and mark a pretty cool milestone for Leading Agile. Yesterday I published my 200th post.

As you might imagine, I put a ton of energy into creating content for this blog. It has become a passion... a hobby even. It has been extremely rewarding to see how you guys have responded to all that effort. It's not just about traffic and stats... although we'll get to that in a minute... it's about the quality of the interaction. I love it when people leave comments or repost something I've written out to Twitter. The conversation is what makes it all worthwhile.

The first six months I was writing Leading Agile it was called Applied Agile Leadership. I had like 10 subscribers and I am pretty sure they were all people that I worked with at CheckFree. My sister might have subscribed just becuase she felt sorry for me. Those first few months were pretty lean... if you go back and look I did a whopping three posts between June 2007 and December 2007. I was too busy in the thick of managing a pretty large program and I was commuting to Portland every other week.

The turning point for me was when I started working for VersionOne.

Not only was I working for a company that encouraged me to write... I also became a trainer and a consultant. My interactions with our customers have been a huge influence on my writing. They have helped fuel the passion... and when I've felt like I had nothing else to say... they have always come through with some new set of problems to solve. I've mentioned here before why I like to write... but a big part of it is having real people that I am trying to help. So... 2008 blew 2007 out of the water. That year I did 80 posts... averaging about 6-7 posts a month. I've always felt that if I was able to do two a week... that was enough.

Even though my writing went up in 2008, it took a long time to for my pageviews and subscribers to catch up. On October 2nd, 2008 I hit an inflection point. That day I jumped a few hundred subscribers... and as you can see from the chart below... my velocity of new subscribers increased as well. Looking back... I wish I knew what I did to make that happen. I had just published my 63rd post... and around that time I had just spoken at Agile 2008 in Toronto and the Agile Business Conference in London. I had also been doing a bunch of international engagements. Maybe it was just a matter of becoming better known in the community, but that day seemed to be my tipping point.

Feedburner Statistics

Actual pageviews during that time did not change as dramatically, but you can see that there is definitely some correlation between traffic and subscribers. That certainly makes sense just from a common sense perspective, but it is interesting to see the correlation in the actual data.

Google Analytics - Pageviews

Yesterday my good friend Martin Olesen from Denmark asked me to pick my favorite three posts from all 200. Intrigued... I decided to see if I could do it. I ended up picking 10. The funny thing is that unless you have gone back through my archives... most people probably have not ever read many of these. At the time many of these were written... I was writing to maybe 70 people. Rather than try to rank them by preference... I mean how can you choose between your children... I am going to list them from oldest to youngest. That seems fair... don't you think?

• Does the Agile Project Leader Exist? - Your first is always the most memorable... not necessarily the best!

• Strategy as Simple Rules - Here I starting to shape my understanding of Scrum/Agile as a simple rules framwork.

• Inverting the Iron Triangle - This is where I start trying to rationalize my background in traditional project management with my agile message.

• Managing Too Much Complexity - People make things way to hard. Part of the key to being agile is reducing complexity... not managing it.

• Agile or Iterative and Incremental - Let's call it what it is... there is alot of benefit to being iterative and incremental... let's just not call it agile if it isn't. This is also the post I did on October 2nd... the day that my blog starting getting significant attention.

• Evolution of a Project Schedule - This became the nucleus of my Agile PMP talk

• The Secret to Organizational Agility - This post has shaped almost everything else I've written about since.

• Are Scrum Roles Really Sufficient? - This was the kick-off post for my whole Agile PO team rant. This post will go down in history of the predecessor of the book Dennis and I are writing. At least from my point of view.

• Is your Organization out of Alignment? - I think this is the biggest problem to agile adoption. Again... another major theme of the book.

• 7 Tips to Get Started Blog Writing - I think I like this one becuase it marks the first time I felt confident enough in my writing approach to give others advice.

When I look back over the past 200 posts... I don't think that my writing style has changed all that much. I may have gotten a little more conversational as I have gotten more comfortable talking to my readers. The biggest change is that I am better able to get ideas out with fewer words. I haven't done the math but I think my average post length has probably gone down. I also think I have gotten faster getting ideas on paper. The average time I spend writing a post has gone from around 4 hours to probably less than 2. Maybe that is becuase I am writing shorter posts than I used to ;-)

Anyway... thanks for humoring me here. I sincerely appreciate that you guys are along for the ride and I am really looking forward to doing this again at post 400!

Subscribe to Leading Agile

Rethinking Scrum and XP

Lately we've been exploring the idea of moving past the specific practices of Scrum and XP and focusing more on what we are doing rather than how we are doing it. Rather than focusing on having ScrumMasters and Product Owners, we need to start thinking about the value these roles are delivering and how we can deliver that value at scale. Meta-Scrums and Chief Product Owners might be part of the solution... but our organization might require more.

To that end... if we are going to create situationally specific strategies at scale... we can start by talking about the core capabilities these roles have to deliver at the team level:

Product Owner

• Set Product Vision
• Define Product Roadmap
• Define Requirements
• Sequence Work
• Communicate Requirements to Development
• User Acceptance Testing
• Manage Stakeholders
• Set release date

ScrumMaster

• Ensure Process Adherence
• Remove Impediments
• Ensure Internal Communication
• Ensure External Communication
• Maintain a Productive work environment
• Team Building

Development Team

• Assign work to team
• Make commitments
• Throttle work
• Design the solution
• Write software
• Maintain code quality
• Take corrective action
• Deliver features
• Deploy the Solution

Everybody

• Continuous Improvement
• Define working agreements
• Resolve Conflict
• Manage Risk
• Set delivery heartbeat

Over the next few weeks we'll explore how these core team capabilities get expressed at each of our five levels of agile adoption. For now I'd like know if you guys think we've got this list right. Is there anything we need to add? Anything that needs to be removed? Your feedback is really appreciated.

If you have a minute... head over to Dennis' blog to see his take on this. Similar content... different presentation.

ADDENDUM: Almost forgot to mark the occasion... this was my 200th post on Leading Agile!

Subscribe to Leading Agile

Big Agile Book Structure

I've been consumed lately thinking through the story our book is going to tell. Great stories have a beginning... something that gets the reader hooked. They have a middle where the reader gets some background and begins to develop a relationship with the characters... they begin to care. Great stories have a climax and a resolution... that place where the drama reaches its peak and everything gets packaged up neatly in the end.

When I'm reading a good book... I always wonder if the author knew exactly where they were taking the characters when they started... or if the whole thing was just an emergent stream of consciousness? I'd have to figure it can go either way... depending on that writers individual style and approach to book writing. Since this is my first book... I don't know that I have a style yet... but I am definitely gravitating toward the more purposeful approach.

If you spend more than a few minutes with me... you'll find pretty quick that I am a big picture guy. I'll do the details with you... but only after I have a framework to hang them on. I have to understand the big picture first so all those details have a place to live... an anchor point... in my brain. My learning style is heavily dependent on pattern recognition so I get impatient if I don't have a pattern to understand what is relevant and what isn't.

Just a quick aside... if you write a blog post and I can't tell what you are talking about within the first few sentences... chances are I won't finish your post... just sayin' ;-)

Images Courtesy of Jeff Patton

Anyway... because I will probably assume that everyone else's brain works the same way... or maybe just because I need to be able to understand my own book... the structure of the book is really important to me. I've gotta have a place to hang all the details. To that end... I see three primary sections in our final manuscript. The first section will tell the entire adoption and scaling story. If you read these first few chapters... you'll have the big picture... all you need to give the details a home.

Next... we'll get into the real meat behind our model. There will be a subsection for each of the five adoption phases. Each section will describe the problem... the common challenges... and who will likely care about the things we are going to talk about. After that we'll explain the relevant capabilities in pretty good detail and suggest several practices that might be effective developing the capability.

We want to address how the organization facilitates the conversations by talking through a pretty detailed capability analysis model. We'll then deal with common risks and impediments that might get in your way. I imagine that each subsection will end with a discussion... maybe a case study... that ties everything together and highlights the key learning outcomes for the manager and the organization. We might add a few tables explicitly mapping capabilities to practices to help out all those folks out there that like to think in pictures.

Finally... we'll close the book with a section that wraps up the entire story. I think we'll have a few closing chapters... maybe appendices... that talk about several tooling approaches we've used to enable these kinds of conversations... and maybe even some discussion around advanced applications of our approach.

So there goes... a beginning... a middle... and an end. Any feedback?

Subscribe to Leading Agile

Updated Agile PMP Deck on Slideshare

I did a final cut of my Agile PMP deck right before Agilepalooza Charlotte. I finally have one that I like so I loaded it up to Slideshare. If you were at my talk at Agile 2009 and want the actual deck I used... this is it!

The Agile PMP V3

View more presentations from Mike Cottmeyer.

Subscribe to Leading Agile

Building an Agile Book with Agile

If you were going to write a book using agile methodologies, what might that look like? You might be inclined to create a backlog of topics... maybe play a little planning poker to get some idea of how big your book is in story points. You'd start writing the book in sections... chapter by chapter... burning down your backlog as you delivered. Since you understood the size of your backlog, and you know your average writing velocity, you'd start to get a pretty good idea about when the final draft could be delivered to the publisher.

If you were running ahead of schedule, you'd be able to predict an earlier delivery date or maybe include some content that you weren't originally planning to be part of the book. If you were running behind schedule... you'd be able to make solid decisions about what to leave out. Maybe you go back to your publisher with real data about how much additional time you'd need to get the book completed. You could use all this agile goodness to really run a solid 'book writing' project.

Do you think that you'd stop there? What else could you leverage from agile methods to write your book? How would you build in quality? How would you know you were writing the right book? Over the past few months I have been thinking hard about this idea of keeping the book potentially shippable. How would we build the book in such a way that it always tells our story. If the publisher pulled the plug in a few months, how could we self-publish a shorter version of the whole book rather than be sitting on a few disjointed individual chapters.

So here is the plan. Dennis and I are working really hard on the major themes... you saw that last week in my four posts on capabilities, double-loop learning, the 7 Habits, and conversations. These themes are going to be hung on our five phase framework of team based agile, horizontal, first order, second order, and third order scaling. The final bit of work we are doing right now is around the specific organizational capabilities (and by extension, the practices) we see as essential for adopting and scaling agile at each of the five different levels.

This is the basic set of up front design work that we want to do on the book. I think of it as the high-level systems architecture. We are defining the framework, the major themes, and the significant features that are going to blend together to tell the story. Like I keep saying... all these ideas are subject to change but this helps us decide what is in-scope for the book... and what is out. There are zillions of ways to tell this story... we are picking one to start with.

Over the next week or so... you are going to see me blogging a bit around the extended book structure as my way to start telling the story end to end. We'll talk about the order of the topics and the learning outcomes for each section. By the end of this phase, you should end up with a pretty good idea of where Dennis and I are headed. That process will help us decide specifically the user stories we want to put in the backlog with a pretty high degree of confidence we are telling the right story. Then we start really writing the book.

Subscribe to Leading Agile

Interesting Post... 8/30/2009 through 9/5/2009

Wow! Have we been back from Agile 2009 for over a week now? Time sure does fly. You may have noticed that I didn't do an "Interesting Post" summary last week. It's not that there weren't any interesting posts... it's just that my Internet access was so bad in Chicago, I gave up reading blogs and Twittering. So in short... there was nothing to summarize. I came back to Atlanta with over 900 unread posts in my Google Reader. I tried to scan them for highlights... but in the end gave up and decided to 'Mark All Read' and start over!

So now we are back in the game. Here is my list of what was worth reading from over 1000+ posts across over 400 blogs. Oh, and by the way... if your blog never shows up on my Interesting Post list... you might want to check my blog roll and see if you are on it. Every once in a while someone I should be following is noticeably absent. Let me know and I'll subscribe to your feed.

Interesting Posts from 8/20/2009 through 9/5/2009

Agile 2009 and PMI http://bit.ly/fuPNS

The agile BA: lead, follow, and get out of the way http://bit.ly/9xjMN

A chat with Gordon Pask Award Winners @ Agile09 http://bit.ly/Z4X63

Agile 2009 Roundup http://bit.ly/4qhF7c

A question of fundamentals http://bit.ly/XRfdF

Words drive thoughts, thoughts drive actions http://bit.ly/IniiL

The Dangers of Hidden Talent – New CIO Series http://bit.ly/15jOpK

FeatureBranch http://bit.ly/ETdhg

ScrumButs are the downfall of agile http://bit.ly/KXomi

Agile 2009 – The General Highlights http://bit.ly/EE2ri

Agile 2009 Chicago http://bit.ly/2ziUO7

Why Tester Won’t Like Agile http://bit.ly/Na7DW

Passion and Talent http://bit.ly/e8zKN

How To Behave Like a Professional Project Manager http://bit.ly/ZeQ0A

We don't need no stinkin' process http://bit.ly/38Nd8Q

Feeding the Agile Beast http://bit.ly/14FT9r

7 habits and Agile http://bit.ly/uweck

Agile Estimating: The Secret To Delivering On Time http://bit.ly/12yYNZ

It Used to Take Three Highly-Trained Professionals to Make a Presentation http://bit.ly/2GVRXR

Staying A Specializing Generalist http://bit.ly/2N58L2

support Corey Haines http://bit.ly/HJFCn

Simplify, or the problem with Six Sigma http://bit.ly/mOSe2

Swamp Thing http://bit.ly/iScBx

Agile 2009: a retrospective http://bit.ly/9hsb6

Lean is more than a set of tools http://bit.ly/kFvof

Reflections on #Agile2009 http://bit.ly/mvj5D

Agile2009 Trip Report http://bit.ly/1iMyoz

Quote Series Part 7 - Philosophy http://bit.ly/8sTMI

Agile 2009 report: Thursday afternoon http://bit.ly/SHtAW

10 Steps for Setting up an Agile Start-up http://bit.ly/lZPrY

The Power of Simplicity http://bit.ly/2TCkC

Reflections on Agile 2009 http://bit.ly/2XjY0

Agile 2009... Thank You All http://bit.ly/pPZfI

Is software development an art or a science? http://bit.ly/dsIPx

Agile Coach Tour thoughts http://bit.ly/mehpG

Using Earned Value in a Changing Environment http://bit.ly/F4wZD

Testing vs. Checking http://bit.ly/Fn3oQ

Looking back at Agile 2009 http://bit.ly/yMTap

6 Thinking Hats Retrospective Plan http://bit.ly/E76T9

Reality check for Agile projects- working sofware over comprehensive docu.. http://bit.ly/1QhweF

Subscribe to Leading Agile

The Big Agile Persona

A little about our intended audience...

When Dennis and I started thinking about our book, we told the publisher that we'd really like to write for CxO crowd. We want to be able to influence the people that can really effect change in a meaningful way. We want to give them the tools... the language... and thinking patterns to successfully start transforming their organizations toward a more agile way of building software.

The reality... many CxOs are not going to pick up our book... and after really thinking about it... that's not where a book like this is going to have the most impact. We need to write for the mid-level manager who has direct influence over their organization and is able to evangelize these ideas to their peers and their leadership team. We want to enable folks to act locally... but think globally. The book needs to be tactical enough to help the guys doing it and visionary enough to influence the key decision makers outside the team and up the organization.

Armed with that new bit of insight... we decided to take a page out of Jeff Patton's handbook and create a persona for the manager we think might want to read our book. We also created a profile for the target company our persona might work for. We wanted to have a really clear idea of the problems our manager was trying to solve and the resistance they might have to overcome in the process.

So like everything I've talked about the past week or so about framing this book... this is ALL subject to change. We just wanted to have a starting place for the conversation.

Frank Michaels, Development Manager

Frank is 34 years old and married with two young children. He has a bachelors degree in Computer Science from the local state university and is currently making just under 100K per year. Frank joined his company a little over four years ago as a senior developer. He is considered by his manager to be someone with excellent technical skills... an open mind... and has consistently demonstrated his ability to get things done.

After only a year, Frank was asked to serve as team lead and was recently promoted to be the team's manager. With this recent promotion, Frank has several teams under his control and more direct interaction with the other managers in his department. He coordinates with the other functional managers to drive work through the organization. He works closely with various project managers to assign resources and track project deliverables.

Frank is frustrated by the whole corporate thing and really questions his decision to become a manager. He spends way too much time in meetings and just isn't interested in all the corporate politics. It takes over a year to bring a new release to market and it seems to be getting slower. Project schedules are unpredictable and cost overruns are common. To make things even worse, quality has been suffering as pressure to deliver has gone up.

StandardCorp's Company Profile

StandardCorp is a public company that has been around for about 20 years. They grew organically for the first 10 or 15 years building software for the insurance industry. Several years ago the senior leadership team launched a strategy to grow through acquisition and they branched into the financial services sector. As of now StandardCorp is just under 5000 employees worldwide with most of their offices in North America. Product Development makes up about a third of their total employees.

As their product lines became more diverse, StandardCorp started looking for ways to leverage common infrastructure components and shared services as a way to reduce costs. The product teams began looking for ways to combine product offerings to create competitive differentiators in the marketplace. Several initiatives spun up to rationalize architectural model but these initiatives have been expensive and success has been sporadic. In fact, these initiatives have slowed down time to market and made products harder and more complicated to deliver.

Product Managers are frustrated because they used to have total ownership of the requirements and the technical teams they needed to deliver features to their customers. As the organization has grown, the delivery model has become more complex and it takes forever to get anything to market. In frustration, the product teams specify larger and larger initiatives in an attempt to get competitive feature sets to market. In response to this inability to deliver... the organization has decided to grow up. In the past year StandardCorp has made significant investment in CMMi, ITIL, and PMI Project Management as a means to get more predictable business outcomes.

Costs are going up... market share and revenue are going down. StandardCorp has already started offshoring some of their development activities and it looks like more offshoring and more layoffs are on the way.

Acknowledgments

Before we wrap, I'd like to give a special thanks to my wife Kimi. She was gracious enough to do some research for me while I was away at Agile 2009. I asked her to find information on about 10 different mid-level manager roles in a typical software development organization. She found information on Project Managers and VPs and lots of roles in between.

Interestingly enough... there were lots of similarities and overlap in terms of age, marital status, gender, and even salary. She gave me names of folks she found with links back to their original sources. Funny thing was, she actually gave me some links back to people I knew in the industry. Anyway... her research was really helpful... so I just wanted to give a nice pubic "THANK YOU" for helping me out. Thanks Kimi!

Subscribe to Leading Agile

Noodling on Kanban... Part Four

Okay... time to wrap this thing up. If you missed any of the first three 'Noodling on Kanban' posts... I included links at the bottom of this one... just to make it easy on you guys ;-)

There is clearly much more to this topic than I wanted to try and address in this tiny little series. We could talk about how Kanban drives culture... how it gives managers a role... how it is more inclusive. Karl Scotland and I debated over Drum-Buffer-Rope and how it applied to Goldratt's Boy Scout story over drinks at Agile 2009. We agreed we were splitting hairs. I tried to get David Anderson to admit that Kanban was just a visual way of managing and elevating constraints... he didn't agree.

There is lots more to say... but for the general agilist or newbie... this should be enough to start. For this post we'll wrap with some of my thoughts on what situations a Kanban might be particularly useful and what I see for Kanban outside the team. To me that is the much more interesting problem.

Time to Use Kanban?

My personal take is that Kanban... even Kanban with a capital 'K'... is not a development methodology. It is not a replacement for Scrum or XP or AUP or DSDM. I do think that Kanban is a powerful tool that can be used when some of our more common agile practices stop making sense. Consider these examples:

Have you ever tried to talk about planning in two week iterations with a team that is responsible for production support? The idea that you can't add anything to the sprint once it is started is going to fail... we'd probably abort every sprint. How about a mature product team that is iterating an existing product? Does it necessarily make sense to stop every two weeks for a few hours to plan... to retrospect? If requirements are generally understood... the team talks over lunch... and they just know how to get things done... probably not.

How about a team that suffers from late delivery in the sprint? A Kanban board can keep them focused on continuously delivering value... even if they don't do away with the iteration boundaries. What about a new team that isn't ready to self-organize or self-manage? A Kanban can give the manager a tool to help the team learn how to self-organize and self-manage. We can use Kanban as a replacement for stuff we don't need or as an addition when we need a little bit more control. Something to consider, huh?

Kanban in the Enterprise

Personally, I find most problems at the team level pretty uninteresting. It's not that team level practices aren't important... they are incredibly important... it's just that most of the teams I work with have environmental problems. If the organization would just create the team... leave the team together... let them stabilize... let them establish a pattern of delivery... most of the coaching stuff we do could work itself out. Coaches could focus on helping competent teams become excellent.

Similarly... at the team level... Scrum... Kanban... who really cares... let the team decide what works for them and go for it.

For me... Kanban gets really interesting at the portfolio level and across the enterprise value stream. Most organizations really struggle to get value flowing in a predicable way out of their enterprise project portfolios. What if we could have an enterprise Kanban... a portfolio Kanban... a project Kanban... and a team Kanban. As you go deeper into the organizational hierarchy... the work in process limits at the enterprise level force value from the portfolio... portfolio limits force value from the projects... and projects force value from the teams. Imagine a system with enterprise cycle time all the way down to team level cycle time.

Thinking about the enterprise as a series of capabilities... capabilities that together form a system... a system that can be managed and subordinated to the constraint... now that is exciting. Now we can focus our enterprise agile adoption dollars at the constrained teams and resource groups to get maximum value from our investment dollars. That is where I'd like to see us to start talking about Kanban.

Hope you enjoyed this series of posts. Make sure to comment if you think I've got this all wrong... I am open to your feedback. Oh... and here are the links for your reference:

Noodling on Kanban... Part 1
Noodling on Kanban... Part 2
Noodling on Kanban... Part 3

Subscribe to Leading Agile

Noodling on Kanban... Part Three

Earlier today we noodled on the secret sauce... maybe even THE most important value add... of implementing a Kanban system. Kanban gives us a very visual way of identifying and elevating the constraints in our system. The ONLY way to really get a team to go faster is to increase capacity at the constrained steps in the development process. Building inventory in other parts of the system leads to waste and re-work.

If you get nothing else out of this little series... that is your take-away.

For today... we are going to talk about going iterationless. So far we haven't really talked about the iteration but most Kanban teams have figured out how to live without them. We'll talk a bit about how to measure progress without being able to measure velocity at iteration boundaries. Without iterations... without velocity... we need another measure of team throughput.... and that is where cycle time comes in.

Going Iterationless

While agile is fundamentally designed to accommodate change, the idea of an iteration implies some degree of certainty about what it is you plan to build, even if that certainty is only two to four weeks into the future. In some environments customers can't wait until the iteration boundary to introduce changes. In some environments requirements cannot be neatly fit into a consistently sized window of time.

This understanding has led some teams to abandon the iteration all together and now consider planning at iteration boundaries to be a wasteful activity. These teams have opted toward working directly from the prioritized product backlog and only bringing new work to the team when the work in process limits allow a new feature to begin. Agile introduced the idea of small batch sizes by limiting the amount of work that could be pulled into the iteration. Kanban teams take this approach to the extreme and reduce the batch size at any one time to that of a single user story.

Teams that implement this approach have ad-hoc planning meetings when the team is ready for new work. They conduct periodic operational reviews to asses team performance, communicate with management, and evaluate the overall health of the system. Teams choose appropriate boundaries for traditional retrospectives but they are not necessarily tied to the operational review or any predetermined time-box.

Velocity versus Cycle Time

Agile teams become predictable by stabilizing the size of the product backlog and establishing a consistent velocity over time. We can assess the delivery date of a fixed scope product backlog by dividing its total size by the velocity of the team. Likewise, we can use velocity to make trade-off decisions when trying to manage to a fixed delivery date release. Without the iteration, there is no longer a fixed period of time from which the team can measure team velocity.

Kanban teams replace velocity with the notion of cycle time. Cycle time measures the total elapsed time from when the feature was started until it is marked complete and accepted by the customer. Cycle time can be useful for predicting delivery and making both short-term and long-term customer committments. Becuase features are independent and not allocated to a fixed scope sprint, the team can always work on the highest priorities of the business.

Many Kanban teams will track the cycle times of similarly sized stories, making a distinction between the cycle time of a one-point story versus the cycle time of the other possible story point values. If the team becomes proficient at breaking down user stories into similarly sized increments of work, estimation is no longer even necessary, and cycle time becomes the only metric necessary to measure the delivery capability of the team.

What's Next

The next and final post in this series will talk a little about why you might want to choose Kanban and a bit about Corey Ladas' work on Scrumban... an interesting hybrid of Scrum and Kanban for teams in transition. We'll also hit a little on some work I am doing with a couple clients to introducing Kanban boards for project/portfolio management.

Subscribe to Leading Agile

Agile Chronicles has Moved!

Hey... most of you guys know that I write both here and at Agile Chronicles. But... did you know that I'm not the only one who writes for Agile Chronicles? We've got quite a few folks that post every now and again... and every one of them is worth reading. Here's the deal... VersionOne upgraded our blog and we have a new look... a new URL... and a new RSS feed.

I strongly encourage you guys to head over to blog.versionone.com and pick up our new feed. If you are only reading me here... you are missing out on some great content.

Subscribe to Leading Agile

Noodling on Kanban... Part Two

Okay... time for part two in my Noodling on Kanban mini-series.

Yesterday we talked about the Kanban board and how it was similar, but not the same, as the Scrum task board. We also talked about work in process limits and how they can be used to explicitly control the flow of value delivered by the team. This post we are going to explore the idea of constraints and how Kanban handles the division of labor on the team. So without further adieu... constraints and labor.

Constraints

So this is how it works... we’ve got the board and we’ve got the work in process limits. As work moves through the team it is possible that certain steps in the development process might become bottlenecks and constrain the flow of value through the system. For example, the team might be dependent on a person who is not part of the team to deliver a particular feature. If that person is not available to assist them team, the work in process limits will prevent more work from being started until that constraint is removed and value is able to flow from the team once again.

Constraints are those steps in the process that are limiting the team’s ability to get completed backlog items through the system. The Kanban board forces us to stop taking on more work until we get the problem with our constraint fixed. By focusing all our attention on the constraint... we work together until the impediment is removed. Work in process limits encourage everyone to work as a team and prevent any one individual from getting too far ahead of everyone else.

Fundamental to the idea of managing constraints is the notion that any partially completed features are considered inventory and could potentially lead to waste. Our goal with a Kanban system is to limit the team’s ability to create inventory and increase the likelihood team members are doing work that will result in value in the shortest amount of time possible. Kanban systems elevate constraints and force the team to address them before they can bring additional work into the queue.

For a great visual representation of this whole process, go visit Henrik Kniberg's blog post... One Day in Kanban Land.

Reasonable Division of Labor

Some teams that encounter a Kanban board for the first time note that the columns seem to reflect a waterfall style process mapping. The reality is that requirements have to be analyzed and designed before they can be built and tested. The problem with waterfall is that teams work in large batches, doing all of one phase before beginning the next. In traditional methods, there is typically a high degree of specialization amongst team members and an excessive number of handoffs between teams as work moves through the system.

The Kanban board acknowledges the phases a backlog item must go through in the development cycle, but like mainstream agile, encourages small independent user stories that are developed in small batches. The columns on the Kanban board do not represent strict hand-offs between team members but more the feature's state during that time in its development lifecycle. While Kanban teams can accommodate a reasonable division of labor, Kanban teams are still typically made up of specializing generalists. Having specializing generalists on the team reduces skill-set dependencies and levels the flow of work across the team.

Kanban, like Scrum, leaves it to the team to decide how work moves through the system and doesn’t explicitly assign work to an individual with a specific skill-set. The Kanban board does acknowledge the reality of intermediate development states, and through the use of work in process limits, explicitly controls the amount of work in each state. This allows work to be managed, helps identify constraints, and provides visibility so the team can determine which impediments should be dealt with next.

The next post in this series will address going iteration-less and replacing velocity with cycle time. We'll close after this next one with some thinking about when you might consider using Kanban and maybe even introduce some advanced contexts I find particularly interesting.

Subscribe to Leading Agile

Noodling on Kanban... Part One

For the next few posts I want to explore some of my thoughts on Kanban. Like many in the community, I started thinking more about this during the Lean/Kanban Conference down in Miami. On the heels of that conference I did an exploratory post on some of the similarities and differences between Scrum and Kanban. The post addressed how Scrum and Kanban (in principle) were not all that different and how Kanban makes some things explicit that Scrum leaves up to the team.

There are a lot of things I consider myself pretty knowledgeable about... but on the whole... I am not certain Kanban is really one of them. David Anderson wasn't sure he agreed with my conclusions about Kanban… but didn’t totally slam the post… so I took that as a small victory ;-) For the real experts... you do need to go hear what David Anderson, Corey Ladas, Karl Scotland, David Laribee, and Henrik Kniberg have to say about all this. These guys are in the thick of the Kanban movement and most of what I know comes through them.

That said... I fancy myself pretty good at figuring stuff out and understanding what is most important. I am also pretty good at communicating complex ideas in a way that others can understand. So with that little bit of confidence (bravado) I am going to take another stab at explaining what I think is essential about Kanban… what tooling and principles I think are most important… and explore a bit how we can use these ideas to help our organizations become more effective.

Kind of like my first post on Kanban… I believe it is helpful to start from a shared foundation and bridge into the new ideas. My opinion is that there are five or six things... right out of the gate... that we need to know about Kanban to be knowledgeable of where it fits and how we can use it to our advantage in the enterprise:

The Kanban Board

The Kanban Board is a tool that helps the team visualize the flow of value through the development process. If you have used a Scrum task board you should be pretty familiar with the general concept behind the Kanban Board. There are sequenced columns that represent the states a work item can have at any one time. As work progresses through the development lifecycle, the card is moved from one state to the other, until it has been accepted by the customer.

The primary difference between task board and the Kanban board is that the Kanban board tracks the flow of user stories through their development cycle and is not concerned with tasks. This is significant because now the team is focused on the value creating item, the user story, rather than the activities required to deliver that value. Only when the entire user story makes its way through the Kanban board have we delivered value to the customer.

A simple Kanban Board might have a column for the backlog, work in process, and the work completed. A more complex Kanban board might break out the work in process column to include dedicated areas for each of the steps in a typical development lifecycle: analysis, design, develop, code, and test. Some Kanban boards will include columns for buffers between the various states depending on the needs and process maturity of the team.

Work In Process Limits

Kanban is more than just a way of visually tracking progress at the user story level. The Kanban board is intended to help the team minimize waste, focus on the most important work, and keep the value flowing through the team. The Kanban team accomplishes this by setting work in process limits for each column of the Kanban board. Work in process limits effectively restrict the amount of work that can be in any one state at any one time.

One common failure mode in Scrum is late delivery within the sprint. Late delivery means that all the backlog items were in process during the sprint but were only fully done and accepted in the day or two prior to sprint closeout. Late delivery introduces risk, tends to destabilize velocity, and results in delayed value delivery to the customer. Scrum addresses this by encouraging team members to work together on only a few backlog items to completion before starting new work.

Kanban takes this implicit guidance and makes it explicit by setting a limit on the number of work items that can be active at any one time. By limiting the amount of work that is in process, the team is forced to focus on getting backlog items fully done before new work can start. These limits can be determined by the team, or by their management, in ways that optimize the flow of value and reduce the number of intermediate work products.

So... What's Next?

The next post in this series will address constraints and a reasonable division of labor. After that we'll discuss doing away with iterations and replacing velocity with cycle time. We'll close with some discussion around why a team might want to consider using Kanban (over basic Scrum) and a little on where I see Kanban being used outside the team in more of an enterprise portfolio context.

Until next time...

Subscribe to Leading Agile

The Conversation Conversation

For the final cross-cutting theme in "Rethinking the Agile Enterprise"... Dennis and I are going to talk about talking.

In other words we are going to explore how organizations talk to each other when delivering work. We plan to integrate the idea that adopting agile in the enterprise involves a series of conversations around how we are going to deliver value back to the business. Within small teams many of these conversations just happen. At scale... there are conversations that we have to make explicit... conversations that we have to plan to have so we can effectively execute.

This post is going to address 10 conversation types that organizations have to address at each of the 5 levels of our adoption and scaling process:

Purpose... conversations about why we are doing the work we are doing. Think about things like visioning... setting the mission... and setting goals. At the team level... this is abstracted behind the Product Owner as a prioritized product backlog.

Understanding... conversations about learning what we are going to do. Think about those conversations we have with the Product Owner before we agree to pull a backlog item into the sprint. These conversations are about getting the entire team all on the same page.

Creative Solutions... conversations about how we might build a particular user story. Think about those times when the team gets together to decide how they are actually going to implement a backlog item. This conversation is about problem solving.

Competing Concerns... conversations about how to make tradeoffs. At the team level we might have to negotiate technical tradeoffs or balance what the Product Owner is asking for with the team's ability to implement. This conversation is about balancing tradeoffs.

Enrollment... conversations about being part of the team. Does the team have the skills necessary to deliver? Are we committed to delivering the sprint objectives? Are we committed to working together and getting better over time? Here we are learning about who is on board and who is not.

Flow... conversations about how we are going to move work through the team. Do we plan to manage this ad-hoc by swarming around backlog items or are we going to use a Kanban and set work in process limits? This conversation is about how we are going to execute the work.

Planning... conversations about how we are going to schedule the work. When are we going to estimate the backlog? Will we track velocity or cycle time? Do we plan to do release planning or only sprint planning? These conversations are about where we need to be and when so we can manage the business' expectations.

Promising... conversations where we say what we are going to actually do. Think about the end of the sprint planning meeting where the team commits to the Product Owner to deliver a specific outcome by the end of the iteration. These conversations are about stating our intentions.

Completion... conversations where we state that the work is completed. In Scrum this happens throughout the sprint as the team works with the Product Owner to accept the backlog items. It also happens at the end of the sprint during the formal sprint review. These conversations are about being done-done.

Status... conversations where we track progress. Here you can think about project burndowns, sprint burndowns, card walls, and daily stand-up meetings. These conversations help our stakeholders know where we are and the chances we are going to be where we need to be.

These conversations happen pretty naturally within a small agile team. They get dicey when you have to conduct these conversations across multiple teams... across projects or programs... across portfolios. Figuring out how to make these conversations happen at scale is part of what we have to address when learning how to adopt and scale agile in larger enterprises.

Head over to Dennis' website for a more detailed treatment of each of the 10 conversation types...

Subscribe to Leading Agile