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

Tuesday, December 29, 2009

Stephen King's On Writing... A Memoir Of The Craft

My wife always tells me that I am really hard to buy for. Why? Because I tend to go out and get the things that I want or need... and when I don’t, I am pretty particular about what I want... things like make, model, and color matter to me. She had all but given up when a year ago I decided I had to have a Kindle book reader. I told her that it wasn’t something that I’d buy for myself, at least not yet, and that it might be a good thing to get me for Christmas (wink, wink).


Well, she came through and I haven’t been able to get my nose out of it for the past four days. It was well worth the wait. The first book I downloaded was Stephen King’s On Writing. I used to be a huge Stephen King fan but haven’t read any of his stuff in years. To be honest, I am not even sure how I found On Writing, but given the fact I am embarking on a rather large book project this year, the title caught my attention. The book is an interesting mix of autobiography, personal retrospective, and tips on how to become a more effective writer.

If you are the least bit interested in writing... I think this one is a must read.

While the book is not long, and it isn’t deep when it comes to advice, there was one key takeaway that I want to share with you guys. Toward the end of the book, after we got through King’s opinions on passive voice and the overuse of adverbs, he talked about how he tries to cut the first draft of his books in 3 months. 3 months! Have you ever read a Stephen King book? Most of them are really, really long. How could you do an entire first draft of a novel in only 3 months?

The general idea is that he spends those three months focusing on telling the story. He doesn’t get hung up on plot or symbolism. He doesn’t worry about dangling characters and making sure the dialog is exactly right. King wants to tell the story while it is fresh in his mind and while he feels a strong connection to the characters. The second draft he goes back and tightens everything up. He’ll look at how the plot emerged and reinforce it. He’ll look for the symbols that emerged and reinforce them too.

The idea is that the first draft is about telling the story, the second draft is about making sure it is an internally consistent, well written book. Funny... sometimes all you need is a little permission to start. When I look back toward the end of 2010 and Dennis and I have pounded out 150,000 words... we might very well owe Mr. King a credit for helping me get out the first 5000. Again... it was a great book for any aspiring writer... it almost had me wanting to go off and write some fiction... it was that good.

So... the Kindle was a hit... very inspiring... and I am very thankful for my wife getting it for me. Thanks Kimi!

Subscribe to Leading Agile

Wednesday, December 23, 2009

My Life is a Project?

When I'm giving talks or teaching a class, I often talk about how I think about nearly everything in my life as a project. So much so that my wife sometimes complains that she is not a project that I have to manage! She get's tired of talking about risk mitigation strategies and desired outcomes. She isn't particularly interested in understanding our assumptions or constraints and really does not like being called a primary stakeholder.

In all seriousness... I don't quite take it that far... but I do tend to see things through a 'project' lens.

Earlier this morning I came across a great post by Scott Berkund titled 'Everything is a Project'. I liked the post so much (for obvious reasons) that I sent it out as an 'Interesting Post...' over Twitter. Several folks re-tweeted my tweet and a few folks commented. One of the comments came from Bob Marshall, aka @flowchainsensei. Here is what Bob had to say:

@flowchainsensei Way too many things are projects - especially projects. Projects are dysfunctional, wasteful and anti-flow. Let's put an end!

And my response...

@ mcottmeyer I think that the project metaphor can be useful when we don't have level investment across product lines.

Clearly this was way too deep a topic to explain in 140 characters, so I wanted to share my thoughts around projects and where I think they are useful... and where I think the concept is overused.

First... the simple definition of a project goes something like this... 'a project is a temporary endeavor, with a defined beginning and end, that is created to achieve some particular goal or desired outcome'. I'm pretty sure that definition came from the PMBOK, but I lifted the language from Wikipedia. Pretty basic and seems to make sense, but does it fit the way that our organization really does work?


My personal opinion is that we often take the project metaphor too far and call too many things projects. Calling things a project isn't so bad unless it drives us to put too much project management overhead around the work or leads to dysfunctional organizational behavior. If you and I are working to get a few bugs fixed for the upcoming release... is that a project? If we can do the work in the same amount of time it would take me to assign a project manager, write a charter, create a project management plan, and develop even a simple WBS and schedule... I probably don't need to treat it like a project.

Here is another example where I think projects are misused. If I am a small company that is developing a single product, and my primary mission in life is to keep that product updated with new features and defect free... is the work I am doing project work? I may be inclined to have a "UI redesign project" or a "Revise the login and authentication project". Are either of these projects? They could be, but because of the nature of my environment, what we are really doing is ongoing product development.

These kinds of work would probably be better considered product development or operations.

But... what if I am building a custom solution that will be handed over to the customer at the end of the contract period. I may provide ongoing support, I may not. In that kind of environment, it might make sense to have a project manager and a charter... a formal risk mitigation plan and at least a high level schedule... even in an agile environment. I have touch points with my primary stakeholders (no, not my wife) and they have certain expectations about how their money is going to be spent. This sounds like it could be a good place to have a project.

Let's consider another example... What if my product company grows up and now we are supporting 20 different products and have 40 to 50 teams. Your product sets are not all the same level of maturity. Some are established and don't need incremental investment.. some are less mature and require new features to be added to meet market demand. The point here is that the investment in each product is not level and the business is making strategic decisions about where it will spend its money to get the greatest return. I think that projects make sense here too. We are making an increment of investment, over a pre-defined period of time, to get some desirable outcome.

So... do I think that projects are overused? Yes. Am I willing to say that all projects are bad and that the entire metaphor is outdated and always inappropriate? No. Like most everything we talk about here... you have to understand your context and not apply concepts blindly where they don't make sense. If your work is more operational and ongoing... that is not the sweet spot for project management. If your work is well defined and discrete, and it lends itself to the problem that project management is designed to address... I think the concept is valuable.

It is not a one size fits all world. I look forward to the conversation.

Subscribe to Leading Agile

Sunday, December 20, 2009

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

It seems that with a teenager... and an almost teenager in the house... there is no such thing as getting an early start anymore. What is it with teenagers and sleep!? The kids and I are getting ready to head out for a little day hike... and I had a few minutes to kill while everyone was getting ready... so you guys are getting a pre-holiday edition of 'Interesting Post'.

There was some really good content out there this week. In particular... scroll down to the post 'Something in Agile Needs Fixing'. That one probably got the most Twitter action this week. Oh, and also... is anyone else enjoying Glen Alleman's 'discussion' of Project Management 2.0 as much as I am?

How Did We Miss the Idea of Project Collaboration in PM 1.0? http://bit.ly/8Lro0X

Designing For Agile http://bit.ly/6d0V8x

Beyond the Hype http://bit.ly/7vlff9

Agile Scaling Model (ASM) White Paper http://bit.ly/6Aec7H

All stories are created equal http://bit.ly/82oFBV

SEMAT (Software Engineering Method and Theory): A Call for Action http://bit.ly/5s0U2l

What’s Your Point of View? http://bit.ly/5RHNb5

Kanban Psychology. Can You Say No? http://bit.ly/6HvIQ6

Project Distribution http://bit.ly/7TH27V

Building trust http://bit.ly/7D0qUt

Agile Tenet #1 – Satisfy the Customer http://bit.ly/6Cr0bD

6 Simple Questions for Bob Martin http://bit.ly/4DQ75C

sidebar ~ agile business analysts http://bit.ly/5jsPVi

The big picture of software development http://bit.ly/6sCLcr

Do I Know You, Can We Collaborate? http://bit.ly/8vTWFN

effective team membership ~ leadership http://bit.ly/5QVrBQ

Architecture All the Way Down http://bit.ly/8mGdqL

Something in Agile needs fixing http://bit.ly/7gSwo2

Agile antipattern: Burndown “wall” http://bit.ly/8QNyRJ

Make the Product Backlog DEEP http://bit.ly/7V2Me1

An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility http://bit.ly/709sJR

Subscribe to Leading Agile

Friday, December 18, 2009

Project Management 2.0

I put Project Management 2.0 as the title just to give Glen Alleman a moment of pause ;-) Actually, Andrew Filev has posted 33 of his favorite thought-provoking blogs on Innovation, Project Management, and Web 2.0. Since Andrew was kind enough to include Leading Agile... and he is asking his readers to vote for their favorite... I thought I would include a link to his post here.


Leading Agile is in some pretty good company... so if you have a moment... head on over and take a look.

Subscribe to Leading Agile

If Value is the Problem, What Can I Do About It?

Wednesday I published a post called "Why is Agile so Hard to Sell?". If you haven't checked out the comment thread, you should really take a look. Most of the comments were really supportive and added serious value (no pun intended) to the conversation. One comment caught my attention, not because it was negative, because it said something to the effect of "nice problem statement, now tell us what to do about it". After thinking about it, I wanted to elevate my response to more than a few lines in the blog comments.

One of the tough things about writing a blog is that you really only have 500-1000 words to make a point. Blog posts are better if they are short and get right down to business. For me, that often means that my posts don't stand alone. Sometimes I get an idea in my head and I'll noodle around on it for 5-10 separate articles. Often these will start off as an intentional series, sometimes they just end up that way.

As I look back over my writing the past few years, my content related posts tend to fall into one of two different categories.

Sometimes I am writing to help clarify a problem. Understanding that we have a problem is often half the battle. This last post on selling agile fell into that category. I am not convinced that on the whole, we all are on the same page regarding what value means and how to map team value to enterprise value. I see too many folks applying simple process to complex problems and doing some goofy stuff along the way. I am trying to figure out how to clearly communicate that something just isn't right.

Sometimes I am writing to help clarify a solution. It's not uncommon when I start out writing a series of posts, that I don't know 100% where I am going. I may have a general idea where the solutions space lives, but I am thinking it through and exploring language around how to solve it. Sometimes I know exactly how I think a problem should be solved and I am using Leading Agile, and your feedback, to help me figure out how to communicate the idea. Ideas have to be simple and resonate with the community for them to be effective.

So to answer the commenter's question directly... the solution to the value problem lies in how we go about our agile transformation. It lies in the scope of what we are able to impact. It lies in how we think about roles, and process, and artifacts... in how we give guidance to our teams and what we train them to do. It lies in project management and portfolio management. It lies in Lean, and Kanban, and Theory of Constraints. It lies in thinking less about keeping people and teams busy and more on getting products out the door. It lies in doing less instead of crowding out our highest priorities.

Many of my posts over the past year have dabbled in this space. The book that Dennis and I are writing is going to be all about applying what we know and directed right at the solution to this problem. The challenge is that the solution doesn't fit into 500 words or less... not even 1000. We are hoping to fit it into around 140,000. We have the tools at our disposal to make this work. We have the knowledge of how to focus an organization on it's highest priorities. We know how to make investments that are going to really matter. We can talk about incremental adoption and value based agile transformation and put together a roadmap for making this all happen.

So... you have several options:

1. Go back and re-read Leading Agile to see how we are thinking about this.
2. Wait for the book... where this will all be in one place... eventually.
3. Stay tuned to Leading Agile where we'll continue to explore both the problem space and solution space around this value issue

And, just so you know... this is really what the folks at Pillar and I do for a living. If you are interested in having someone help you jumpstart this process... give me a call. I'd be happy to have a phone conversation with you, we could setup a Q&A or a webinar, or come onsite to talk about the issues you are struggling with. We can help you identify some very tactical next steps that will bring attention to this problem... and how we can work together to fix it.

My team and I have some availability over the next few months, so if you are interested in talking, let me know.

Subscribe to Leading Agile

Wednesday, December 16, 2009

Why is Agile so Hard to Sell?

What I find incredibly interesting is why defining value is so hard. Agile proponents have been beating the value drum since the very beginning. Put the customer in the room... understand their needs... build what ever they want... deliver software in small increments... get constant feedback... converge on the optimal solution... deliver value early and often. Agile is all about delivering value. Why wouldn't a management team embrace a set of methodologies so focused on giving them what they need the most?

Here is my take...

Agile is (in large part) a reaction to misapplied waterfall development and naive application of project management principles in ways that are inconsistent with how software actually gets built. It was is a reaction to dehumanizing, process and artifact driven management approaches... processes that assumed with enough procedures, we could somehow commoditize the practice of software engineering. We wanted to take the uncertainty out of a craft that is really a blend of engineering and art. Our desire was to make everything predictable and repeatable.

We were trying to treat people like machines that could be infinitely sliced across tasks, tasks that with the right level of process and planning, with the right level of project management and oversight, would somehow magically roll up into working software that our customers would want to buy. Guys like Jefferies, Cockburn, Schwaber, and Sutherland were beginning to realize that successful projects were really the result of high-performing, committed individuals, working together in small teams, all directed toward shared outcomes.

XP, Crystal, and Scrum were born through the realization that these small empowered teams delivered the best outcomes and were the most successful over time. As these agile approaches were beginning to emerge, they all shared this disposition toward small teams, close customer interaction, and frequent delivery of value. The funny thing is that if you talk with most folks working for small companies... this is kind of what they do naturally. Folks are not assigned to a single role... you have a team of high-performing individuals working together for the sake of their collective survival. Big companies seem to have messed this up... but I digress.

Fast forward 10 or 15 years...

Now we have pockets of agile within large organizations... sometimes we might even have agile across entire large enterprises. We are exploring agile methods and trying to see if they can deliver on the small team promise... but in the large. The main difference with these larger organizations is that value isn't the same as it is in a small team or a small company. There is not a direct correlation between team performance and business outcomes... there is not a direct connection between what the team delivers and what we can sell to our customers. It takes the output of too many small teams coming together to deliver anything of value.

Agile methodologies have typically treated the team like a black box. We give them a prioritized product backlog as an input and we get valuable working software as an output. But now... we have to coordinate the output of several teams... maybe even dozens of teams... into some sort of coordinated deliverable. We are having to deal with getting tens or hundreds of people working together in a coordinated fashion. When that is our context... the message of teamwork and collaboration... close relationships between the team and the customer doesn't resonate. The only way many of these organizations can get any sense of comfort... any sense they that they are responsibly managing their part of the business... is to ask their teams to commit to the big up front plan

As an organization, we know that we need to deliver value as fast as possible. We know that we need to be able to respond to change. We know that we need to deliver with more predictability and with higher quality. We have an intuitive sense that what we are doing isn't working. We want to get benefits that agile talks about. We suspect that something like Scrum or XP can help... but we can't figure out how to apply the small team concepts to our particular business problems. That's why you get the classic "agile will never work here " comments. There is an inherent disconnect between the team level guidance agile methodologies talk about and the bigger concerns your senior executives are struggling with.

There is a gap between value at the team level and value at the enterprise level.

At the end of the day, our community needs to develop guidance that helps our executives get the benefits of agile but focuses on real, enterprise class value delivery... value defined in terms of real results and real business outcomes. So, why is agile a tough sell? We are asking our leaders to trust a process that focuses on team based outcomes but doesn't give them a credible way to articulate how the development organization is going to deliver on the more complex objectives of the business.

Subscribe to Leading Agile

Wednesday, December 9, 2009

Mike Live at Oredev 2009

I happened to stumble on this video of me doing one of my talks at the Oredev 2009 conference. I knew the Oredev crew had recorded the session, but I was not aware the video had been posted. This particular talk was a one-off for the Oredev conference based on a coaching gig that I did earlier in the year. We explore some of my common themes around product owners and product owner teams and some of the processes we needed to have in place that Scrum doesn't particularly address. The video is long, but check it out and let me know what you think.

Here is a link to the video. Vimeo won't let me embed it on this site.

Subscribe to Leading Agile

Monday, December 7, 2009

Who Cares About Value?

Part of our problem discussing value is that value is a pretty elusive concept. What is valuable to me might not be valuable to you. It is easy to blur the line between what might be considered a valuable contribution and something that actually adds value to some desirable business outcome. Value can be created at many levels within the organization. You have to ask if the value you are creating can be easily translated into something meaningful to the business stakeholders. In other words, can we get the value you are creating within the organization, out of the organization?

Think about this… if you are an internal IT organization, your customers are your internal business stakeholders. The hardware and software solutions you build are enabling business processes that are valuable to the operations of your company. The value created is in the well-executed business process… not the hardware or the software you built. At the end of the day… the well-executed business process is the ultimate value proposition.

If you are a product delivery organization, your customers are the people that buy your software. Your software is only valuable to them to the extent that it enables their business processes. Value for the product delivery organization lies in its ability to build the right product, with sufficient quality, and getting it in the hands of paying customers faster than its competition. Value for the product company is derived from your customer’s willingness to pay for a product that helps them create value within their organizations. Your value proposition is not identical to that of your customer… and at the end of the day… you are one degree removed from where real value is created.

Let’s say for a moment that you are a product manager for that product delivery organization. Your goal is to get software out the door that you think your customers will use. Value is created when you define the right features and are able to engage the organization to get the features implemented into the software solution. Sure, those features have to sell, but the focus is on getting them built into the solution. Delivered end-to-end features equals value into the product. Here your value equation is two degrees removed from the real creation of value. Your software feature has to be sold to a customer and then used to actually enable the right business outcome.

What if you are a product owner working with a single team within a multi-team product delivery organization? Your customer might be that product manager trying to get an end-to-end feature out the door. Your job is to add a new feature into some major sub-component in a large systems architecture. You own that product, but it actually takes several products working in unison to deliver an actual slice of working software across the overall enterprise systems architecture. You are providing services back to the larger enterprise class system. Value to you is created when that service feature is delivered back to the project and you are now three degrees removed from the business enabling value proposition. Your service has to be integrated into the product feature, which then has to be sold, which then can be used to enable a business process.

Let’s keep going… consider for a moment that you are a technical team lead. Your customer is the product owner that defined your backlog and is trying to get enterprise services out to the Product Management team to deliver on the project outcome. Value to you is defined as some increment of working software (a user story) that enables some given transaction within the system to execute. Maybe we are accepting a data value through a system interface, transforming the data based on other system inputs, writing that transaction to the database, and giving the user feedback the operation completed successfully. Here you are four degrees removed from the business value equation. Your user story has to be combined with other user stories to enable the component feature, component features that have to be integrated into a larger value feature, sold to a customer, and then used to enable some desirable business outcome.

What if I am a developer on that team? My customer is my product owner, but it is also my team. My definition of value might be a unit-tested increment of code. If I am a tester on that team, my definition of value might be a passed test case. If I am a technical writer, my definition of value might be updated system documentation or tech manual. At this point, I am at least five degrees removed from actual business value. My work has to be integrated into the user story, which has to be integrated with other user stories at the component level, components which have to be integrated at the value feature level, which have to be sold, which have to then be used to enable our customers business processes.

So… no wonder that value is so difficult to talk about. Value is not only domain sensitive, it is context sensitive… it is role sensitive. It is sensitive to where you live in the overall development lifecycle. We have to either drastically reduce the number of hops between developer activity and the actual real business enabling value proposition OR we have to learn how to align all this lower level activity to support business outcomes that might be up to five degrees removed from the people doing the work. So next time you tell someone that agile focuses on business value… at what level of business value and how many degrees removed are you from what your customer actually cares about?

I think we have trouble selling agile because we are not talking about value at the same level our customers care about value.

Subscribe to Leading Agile

Sunday, December 6, 2009

Interesting Post... 11/30/2009 through 12/6/2009

Hey... it's been a few weeks since an installment of Interesting Post update. I have to apologize for not being consistent with these, but I hate doing these summary posts when I'm not generating other new content... it feels kinda like cheating ;-)


That said, I managed to push out a few real posts this week, so I am feeling pretty good about doing one of these Twitter summaries. It has been a pretty good week for agile content on the net... so sit back... get ready... and enjoy this weeks installment of Interesting Post...

It’s Not Always Easy Doing The Right Thing All The Time http://bit.ly/5uoyZc

Predictive Planning vs Adaptive Planning http://bit.ly/5d3xVd

Agile Design: Intentional Yet Emergent http://bit.ly/4EFSG5

Where's the PM in PM 2.0? http://bit.ly/91Bu0G

Proof that Agile Works http://bit.ly/7air3f

Where's the PM in PM 2.0? http://bit.ly/7swlp8

The Agile Bargains http://bit.ly/794rA1

Double Wake-up http://bit.ly/74mYtK

Preparing for Agile – Modular Writing http://bit.ly/7IBQNi

New to agile? Remember the power of automation http://bit.ly/5YfGG9

Why the Performance Measurement Baseline is the basis of project success http://bit.ly/8epPvQ

Making Agile Requirements Work-NO 6 http://bit.ly/8gu7MC

Agile Principles http://bit.ly/8hnuvL

A Social Architecture for Agility http://bit.ly/5V382a

Agile Project Management Questions Answered http://bit.ly/62UKWf

How Many SW Projects Have No Concern About Budget or Schedule? http://bit.ly/7MoQqv

Four Kinds of Trust (2): Earn Trust from Your People http://bit.ly/4sKrwk

Don’t Call it Waste http://bit.ly/4Rrqnk

Agile Requirements Book: Acceptance Testing Chapter http://bit.ly/7NsYve

How to Want Very Little http://bit.ly/4pphSP

Quote of the Day http://bit.ly/72F51E

Subscribe to Leading Agile

Friday, December 4, 2009

Mike Cottmeyer... DZone Interview at Agile 2009

Back in August, I did an interview with DZone author Nitin Bharti . It was a great experience and I want to thank the folks at DZone for making it happen... I had a blast. DZone did an excellent job editing the footage and really captured the essence of what I was trying to say. I also appreciate them editing out all the unintelligible babble at the beginning while I settled down and got comfortable being interviewed on camera ;-)



Here's a link to the original post on DZone as a well as a written transcript of the interview.

Subscribe to Leading Agile

If Agile Isn't the Point, What Is?

For you guys that have been following this blog a while, you know that I am interested in how we become agile in larger, more complex enterprises. Inevitably when I am out doing one of my talks, I'll get the question: How do I convince my upper management that this whole agile thing is a good idea. My advice... you don't. My bet is that your upper management doesn't care at all if you are able to adopt agile. When our play is how to adopt agile... we are focusing on the wrong things.

But, if management doesn't care about adopting agile, what do they care about?

I'd bet your management cares that you can't get any working product out the door. I bet they care that you are consistently late and over budget. I bet they care your product has terrible quality and doesn't satisfy the needs needs of your most important customers. I would bet your upper management would like to be able to change their minds, easily figure out how to insert new projects into the queue, and have some reliable understanding of what products they can deliver to market over the next six months.

Going agile is only relevant to upper management to the extent that you can map your proposed changes to value that is going to drive business outcomes. These may not be the outcomes that you care about... they have to be the outcomes that your manager cares about. We have to use language that is relevant to them and helps them meet their goals. So when I get asked how to convince a manager to let the team go agile... my advice is try and understand how your management team defines success and suggest practices that are going to help them get there.

Unless they can map investment in agile to a specific business outcome, and ultimately financial return, you are fighting a losing battle.

Subscribe to Leading Agile

Back from Edmonton... No More Agile PMP?

I was fortunate last year to have several talks selected for the Agile 2008 conference in Toronto, one for the Agile Development Practices in Orlando, as well as a talk on Agile Certification at the Agile Business Conference in London. The problem was that all this was brand new content... none of the decks were ready made. That meant that in addition to normal client travel, I was traveling internationally for all these conferences, trying to keep up with my blogging, and developing five different ninety minute Powerpoint presentations.

Those few months were pretty stressful and I felt like I spent all my free time creating Powerpoint slides.

One of my goals for 2009 was to get selected for four of the big major conferences, but this time around, get the same talk selected at all four. Furthermore, I wanted to do a talk that I already had prepared. I was pretty lucky to meet that goal and got selected to speak at the Better Software conference in Vegas, the Agile 2009 conference in Chicago, the PMI Global Congress in Orlando, and again in Orlando or Agile Development Practices. The one that got selected was my "Agile PMP: Teaching an Old Dog New Tricks" presentation.

I have to say, this was clearly an example of 'be careful what you ask for'. In addition to delivering that talk at the four conferences I mentioned, I did it for two VersionOne Agilepaloozas, an Atlanta PMI Lunch Meeting, an ASPE webinar, an IT&T SIG webinar... and most recently for the Agile Edmonton group in Edmonton, Alberta, Canada. As passionate as I am about delivering the Agile PMP message... it starts to feel like Groundhog Day saying those same things over and over. The cool thing is that the message resonates, it is something that people want to hear.

So... while I am not going to officially retire the talk... I have decided not to submit the talk to any of the big conferences next year. Next year I am going to focus on new content centered around value driven agile transformations. I've already got several decks together, one on 'Adopting Agile in the Enterprise' and another I call 'Value over Velocity'. Both deal with the challenges that large organizations face adopting agile... especially the challenges staying value focused while they do it. The first talk centers mostly on organizational structure, the second on enterprise agile metrics.

Hopefully these messages will resonate with the conference organizers and I'll be able to get some traction in 2010. I've already got the decks together so let me know if you'd like me to do a webinar for your team... I need the practice ;-) We might even be able to arrange a lunch and learn for your company or possibly a talk at your local agile user group. I've got both the decks up on Slideshare if you are interested in taking a look... http://www.slideshare.net/mcottmeyer.

And... if you are REALLY interested... I'd be happy to reprise the Agile PMP talk ;-)

Subscribe to Leading Agile

Wednesday, December 2, 2009

Adopting Agile Isn't the Point

I spent the first ten or so years of my career living in data centers. I was a network guy... built a lot of servers... installed a lot of operating systems. Before I made the jump into project management, my specialty was email systems... Lotus Notes in particular. The first couple of projects I ever officially managed were things like server upgrades and hardware refreshes. Sometimes we were doing upgrades just to stay current with the latest release... but most of the time, our stakeholders were investing money to get some new capability that was valuable to the business.

Usually I'd have a few guys on the team working with me. One of my pet peeves was when someone on our team would talk about our 'server upgrade project'. From their point of view... we were upgrading servers. From the business' point of view, we were investing in extra storage space so they could store more email messages or have more room for application data. Calling our project the 'server upgrade project' described what we were doing, but it didn't adequately describe the value we were delivering to the business. It's a subtle but meaningful difference.

When we allowed ourselves to define our work in terms of our activities, we risked losing focus on the desired outcomes of the project.

At the end of the day, the business didn't care if we added hard drives, upgraded memory, or installed a new OS... they cared about the value that those activities would give them, and how that value would impact their ability to conduct business. They cared about the return on their investment... not how we got that return. I think there is a parallel here to how we think about our agile transformation projects. Are we adopting agile or are we getting feedback so we can build better products? Are we adopting agile or are we trying to get incremental revenue from our software development investment?

The goal is not to have Scrummasters and Product Owners. The goal is not to have cross-functional co-located teams. The goal is not continuous integration or pair programming or TDD. Those things are the stuff we do to get the desired business outcomes... those things are strategies that we believe will deliver the business value our organizations are investing to receive. Our challenge is not to mistake the proposed solution with the desired outcomes. There are LOTS of people that have Scrummasters and Product Owners that are not rapidly reducing risk... not getting fast feedback... not delivering incremental value... and not building an integrated end-to-end product.

Maybe this is just semantics... but I believe when we put all our focus HOW we think we are going to solve the problem... it is easy to lose sight of WHAT we were really trying to accomplish. It's easy to start focusing on upgrading hard drives rather than the business outcomes those hard drives were purchased to deliver. Our goal is to stay brutally focused on business outcomes and choose strategies that we think will deliver those outcomes. We have to constantly inspect and adapt and be willing to change when we are not getting the outcomes we hoped for.

Because, at the end of the day... adopting agile was never really the point.

Subscribe to Leading Agile

HeraTech... A Blog on Agile Technical Writing

I think it is a sign of a maturing agile community when we start seeing advocates outside the mainstream development community. A former co-worker of mine introduced me to a relatively new blogger in the Boston area named Julie Stickler. Julie is writing on her transition to agile from the perspective of a Technical Writer. When I speak on agile, quite often I get asked question about how Technical Writers fit in. I have my perspective, I am looking forward to hearing what Julie has to say. Her first few posts are excellent and the blog is promising. If anyone out there knows of other bloggers tackling Technical Writing... I'd love it if you'd share a link.

Julie's blog is called HeraTech and she can be found at http://heratech.wordpress.com. Enjoy!

Subscribe to Leading Agile