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

Saturday, November 21, 2009

Agile... and the Pursuit of Happiness

I want to turn you guys onto a new blogger in the agile community. His name is Victor Hernandez and he blogs at http://agilehappiness.blogspot.com. Victor comes from a QA leadership background... he is here in Atlanta... and he active in the local agile community. I am anxious to hear what Victor has to say, especially as it relates to integrating the QA role into the team. His first post is excellent and you guys should all head over and check him out.


Subscribe to Leading Agile

Managing to the Constraint

There is a part of me that is a little uncomfortable with my conclusion at the end of the 'Velocity in the Enterprise' series. Using a Kanban metaphor at the team, project, and portfolio level makes sense... I also think it is the right way to look at things... but I have a hard time recommending things that I think are really, really hard to actually do... at least without providing some sort of transition state to help you get there. I want to explore another mechanism for accomplishing basically the same effect, but without having to fully re-factor your entire organization.

For the purpose of this post, we are going to make some assumptions about your organization. We'll assume that in some form or fashion you are organized around small cross functional teams. These could be either feature teams or component teams. As long as we have a team that can establish a velocity, that's sufficient for our discussion We'll also assume for the time being that each team is working in a many-to-many fashion across several projects (or some combination of projects and non-project work). In short, we have assumed ourselves into the exact environment where velocity at the enterprise level doesn't work.

What if... rather than introduce a new planning framework... and a new language around Kanban, constraints, and cycle time... we just handled things a little more implicitly?

Managing Projects

Here's what I mean... Let's say that we have a project with a backlog of 'value features'... items that will actually create value for an end-user... something our customer is willing to pay us for. What would our project goal be? Just like a team wants to establish a stable velocity, to be able to use past performance as an indicator of future performance, the project needs to be able to do this too. Our goal is to be able to reliably and consistently deliver value features. As a project team, we pull the next set of value features into the iteration. Next we break down those value features into user stories that get allocated out to the various team level backlogs.

As a project, we know that we're only going to start things we can finish. We know we aren't going to tee up work that isn't going to get done in the next iteration or so. What we'll find is that some teams will have too much work and other teams won't have enough. Those teams with too much work are our constraints... they are our critical path. How do you shorten your critical path? You apply resources or you figure out how to do things in parallel. Shortening the critical path is the only way to actually shorten the project. At the project level, our job will be to groom backlog up to the point we have consumed all the resources on our most constrained team. The availability of capacity at the constraint limits how fast we can deliver value features as a project team.

What we have (in effect) done, is create an abstraction layer between team performance and project performance. At the team level I care about velocity because I can use it as a metric for continuous improvement. I can use my velocity to predict throughout and make commitments. At the project level I am not trying to map team level performance to project performance... I have abstracted them from each other... because at the end of the day, all I REALLY care about is project level velocity... it's the project level velocity that delivers value. I will also have to pay attention to the velocity at the constraint too... but not because it is directly correlated to project performance... but because that is where I need to focus resources and improvement initiatives to get my project to go faster.

Managing Portfolios

Now here is the deal... projects need to be prioritized just like we prioritize user stories. The number one project in the queue needs to get all of the resources at the constrained team. Okay... maybe the first and second interleave a bit... but in general... the constrained team should always be working on the most important stuff. This is going to force some amount of serialization of the project portfolio... we are only going to have one or two of the most important initiatives going at any one time. We'll be able to have that conversation because we know what subset of the organization is constraining our ability to build software. Giving them more stuff to do will only slow them down.

But what about those teams that have extra capacity? We learned earlier that some of the teams are gong to be less busy than the constrained team. True... but here you have a few hard decisions to make. You can either redeploy those people to work at the constraint... or... you can give them features to build that can be delivered independent of the constraint. Here is the hard part... if you a team work to do, work that requires resources at the constraint... and the constrained resource isn't available to do the work... your taking a pretty significant risk that the team is building the wrong product or that teams will get out of sync with each other. You risk that they are creating waste and distracting your organization from it's highest priority objectives.

So what happens at the portfolio level? Just like the project velocity is abstracted from team velocity... the portfolio will establish a velocity that is independent of the team as well. At some point we'll be able to measure how many 'project points' we are able to get done a quarter. We still care about team velocity... we still care about value feature velocity... it's just that we don't count on these metrics to be directly related to portfolio performance. We are in effect applying the same principles of abstraction between individuals and teams to team and projects and ultimately projects and portfolios. Each layer in the management hierarchy has its own velocity but it is not directly related to any of the velocities of the lower order management structures.

Managing your organization by managing to the constraint allows this to work.

Velocity in the Enterprise, redux

You see... we are really applying many of the same TOC (theory of constraints) principles we talked about when we talked about enterprise Kanban, but rather than try force a whole paradigm shift... we are leveraging much of the same language and all of the same principles to actually make velocity work. The difference is that we are leveraging the management team... or the project management team... maybe even the product owner teams... to allocate (or limit) work based on knowledge of the constraint, and to stop assigning work when teams are at capacity. We are dealing with the constraint implicitly using shared understanding of the methods and principles rather than the explicit constraint of a Kanban board.


Subscribe to Leading Agile

Thursday, November 12, 2009

What We Call Stuff Matters...

In my post 'Organizational Myopia' we talked about an increasingly common problem with the language we use. We 'talk' quite often like we are delivering a cross-functional end-to-end feature of the overall system, when in reality... we are really only delivering a subset of the solution. We are delivering a 'feature' that has to be integrated with other 'features' in order to deliver real customer value. Why does this matter? It matters because when we allow ourselves to only care about... only track progress on... only get better at our little slice of the world... we risk investing money and time building 'features' that might never get sold to an actual customer. Focusing on end-user value is critical to overall organizational success.

Part of our problem is that the language we use to describe value is ambiguous... it's open to interpretation. Exactly what is a user story? We can go with the Ron Jefferies definition... a card, a conversation, and a confirmation. What is Ron saying? A user story is a placeholder for a future conversation about the requirement. That conversation is supposed to be with the 'customer' and we've already discussed that a 'product owner' is not necessarily our end 'customer'. What about Bill Wake and the INVEST model? A story should be independent, negotiable, valuable, estimate-able, small, and testable. This definition is more specific as long as we are clear about what adds value. Valuable to the customer? Maybe... but again... who is the customer?

Back in my project management days... we were blending methodologies all over the place and had to get really specific about the language we used. People were learning and we couldn't take anything for granted. The default corporate methodology was RUP so we talked a bunch about use cases and I spent a lot of time explaining how to break down requirements in that language. During that time we had the notion of a use case, a use case scenario, and a system level use case. Use cases were an umbrella description... an aggregate maybe... of some number of use case scenarios. Each use case would have a primary success scenario and some number of alternate scenarios. A single success scenario and some number of alternate scenarios were typically the minimal increment of business value.

Our applications were complex and quite often any given use case scenario would touch several significant system components. We might have a use case scenario that hit the mainframe transaction processing engine, the enterprise data warehouse, a statement processing engine, a set of web-services, a message bus, and a java based customizable front-end. Each component would have a series of system level use cases that expressed the changes that had to be made for each of our components. Whereas the 'actor' for the use case or use case scenario was likely an end-user, the 'actor' for the system level use case was likely another system. It was only by building out a number of system level use cases that I would have a scenario, and only some number of scenarios before I had a 'feature' that was relevant to an end-user.

Given this as our backdrop... where does a user story live? Is a user story a use case? How about a use case scenario? Could it be a system level use case? I think that in practice most folks would agree that a top level use case is too big for a user story. A top level use case is more like an epic or a feature group. I tend to think of a user story more like a use case scenario. There is a primary scenario, and some number of alternate scenarios, that each individually provide some capability to an end-user of the system. We can prioritize these items, decide what is minimally marketable (how much error handling for example) and be potentially shippable when we are done. Sound like user stories to me. Lately though... and this is the nut of the discussion... I've talked with lots of teams that are using the idea of a system level use case as the definition of a user story.

System level use cases ARE an increment of working software. They do have 'value' in the sense that they are meaningful to the overall system. They are potentially shippable. The problem is that your customer doesn't care about them. Another problem is that a team's velocity delivering these system level use cases is not in any way related to your ability to deliver an end-to-end use case scenario. So... here we have the language problem. If my backlog is filled with system level use cases... but I talk about these use cases as if I were delivering a use case scenario... and measure my performance like I am delivering a use case scenario...then I am only pretending that I am delivering value and my team based metrics are pretty much crap. Many, many teams are starving their organizations... not delivering real value to the business... but think they are doing great agile.

That is a problem.

So... a few posts ago... when we were talking about program level Kanban, project level Kanban, and team level Kanban... this is what we were talking about. We might have any number program level use case... small projects moving its way through the system. These use cases are broken down into any number of use case scenarios and then ultimately system level use cases [that are assigned to teams]. The teams are responsible to deliver the increment of software... the enterprise is responsible for prioritizing that work, planning that work, sequencing that work, and making sure that the work comes together into some sort of aggregated deliverable. If the work of the team is not ever aggregated... in a systematic, disciplined way... we run the risk of having great team velocity and really poor organizational velocity. We need both.

The main takeaway here is that language matters. What we call stuff matters. Thinking about the entire enterprise like and end-to-end system matters. When we allow organizational myopia... when we bend the words to make things work... when we play games with language, we are going to have problems. You need to know what these words mean for your organization... how all of this works together... and what it takes to ensure we are driving real value for the business.

Subscribe to Leading Agile

Monday, November 9, 2009

Reuse Creates Bottlenecks

Here is something to think about. Is re-use always good? Is it always a good idea to have shared services and rely on common components? I jotted down a great quote at Oredev this week but can't seem to recall who said it. "Reuse Creates Bottlenecks". Isn't that what we have really been talking about over the past few weeks? When you have a team... or a department... or a division... or a business unit that has everything it needs to deliver... it sure does make planning easier. Why? Because you reduce dependencies on the rest of the organization. There is less coordination... there are less constraints.

But is that how we tend to think most of the time? We seem to think that we'll pull out all the stuff that is common and share it across the enterprise. That might make sense... it might be the best use of our resources... but it might create unnecessary dependencies that we're going to have to manage for the life of the product. So here is a word of caution... if you are going to move toward shared services, have you considered the impact that decision will have on your ability to be responsive to your external customers? Have you considered what you are optimizing for?

Organizations that have people in functional silos are, in a sense, reusing people. They believe that having folks with similar abilities working for the same manager is the best way to optimize their limited resources, to get the most out of their investment dollar. Agile teams know that optimizing for throughput is better and tend to rely more on specializing generalists to level variations in the need for talent over time. Reusing system components has a similar effect on the organization as resource silos... and leads to the same kind of behavior. More documentation... more up front planning... and more managing dependencies.

So... if reuse is essential... or strategic... go for it. Just understand your trade-offs. If you are doing it because you think it is going to lower costs... you might want to think about it. If you trade shared systems for increased coordination and management overhead... you might not save as much as you think. Anyway... something to think about.

Subscribe to Leading Agile

Sunday, November 8, 2009

Interesting Post... 11/1/2009 through 11/8/009

Got a interesting story for you guys...

Arrived in the Copenhagen airport today for my 11:10 AM flight back to Atlanta. I looked up on the board... no flight to Atlanta. I went over to the Information Desk and the lady tells me that there was a flight on the 7th... and another scheduled for the 9th... but no flight on the 8th. Hmmmmmmmm. Since Delta does not have local gate agents, we head over to the servicing organization that handles Delta ticketing. Apparently, Delta has decided that they aren't going to fly direct from Copenhagen to Atlanta on Sunday anymore. Kimi and I are booked on the Monday flight.

Well... we had a VERY helpful agent in Copenhagen that called and talked to a VERY UNHELPFUL agent in Atlanta. I am starting to see a CLEAR pattern with Delta phone agents. Apparently, there was only one other flight back to Atlanta today , and unfortunately the gate for that flight had just closed. Delta was willing to move us to a SkyTeam partner, but not to another airline to get us home as planned. Come to find out, the agent in Atlanta was wrong and there WAS another flight back to Atlanta, through Paris, that was going to leave in a few hours. Our agent in Copenhagen got us on that flight. This guy was my hero today... he was seriously dedicated to providing outstanding customer service.

Here is the lesson learned. About six weeks ago, I did get an email from Delta telling me that my fight had been changed. I get these messages all the time, but up until this point they had only communicated small schedule changes or seat assignments. I didn't catch that they had canceled my flight and moved me to an airplane on an entirely different day. I am not sure if I should be mad at Delta or mad at myself for not paying more attention. I guess I'll take responsibility and be mad at myself. Kimi and I are going to be a few hours late back to Atlanta tonight, but I am very happy to be going home.

With all that drama as a backdrop... this weeks installment of 'Interesting Post' is coming to you from the Startbuck's in CPH Terminal 3. Hope you guys enjoy!

Dean Leffingwell's User Story Primer http://bit.ly/2SoOT6

Oredev 2009 - LIVE (now recorded) Closing Panel Video http://bit.ly/pJ3mB

Fun with Release Planning http://bit.ly/3TOHhC

Technical Debt http://bit.ly/2pzmoB

The "decline" of Agile is our own fault... http://bit.ly/2lQU27

The mistake most developers and development organizations make http://bit.ly/3uvTQH

Why Agile? Why Now? http://bit.ly/opmxS

Five Myths of Agile Development: Myth #4 - Agile Development Does Not Scale http://bit.ly/2m1LJR

Balancing Anticipation and Adaptation http://bit.ly/3c9hSN

Agile Release Planning Musings http://bit.ly/175Ydu

Agile isn't Just About Change http://bit.ly/482noY

Making Agile Requirements Work-No 4 http://bit.ly/35lGAz

Seth Godin Misunderstands Dunbar's Number http://bit.ly/32knNw

Agile Projects and Project Management http://bit.ly/4vEuCK

Subscribe to Leading Agile

Thursday, November 5, 2009

Organizational Myopia?

Okay... I want to write a quick little post here to point out something that is becoming increasingly obvious to me. I've talked quite a bit over the past year about the ongoing feature team/component team debate. We talk about how agile teams are supposed to deliver an end-to-end cross-functional slice of the application architecture. When applications get big, I've talked about how sometimes we have to organize around large scale system components or services. So here is the deal... I think that in practice... most people actually get this. It seems that the more I talk to people doing agile in large organizations... the component team model might be THE primary organizational model in the enterprise.

Great right... no debate? Well... actually no. The problem is in the language we are using. If we are only building component features... software that is theoretically 'valuable' to the business... we are not building software that is sellable in and of itself. It is only the integration of multiple services or components that our external customers really care about. To some degree we are deluding ourselves about what we are really creating for the business. We get better at building our feature subset... our component features... but as an enterprise we are not getting any better at getting value out of the overall system. We are not getting better at delivering the end-to-end apps that our customers care about.

I think that to some degree we are guilty of a sort of institutional myopia. Because we can't control anything outside of our team... because we don't own, or have influence over, the PMO... over management... over the architecture group... over the integrated feature set... we control what we can control... we pretend the rest doesn't exist. We focus on our team. We desperately want to be good at what we do and we want to deliver value. We want to do valuable work. So what do we do? We change the rules. We redefine value and call it a backlog item. We redefine our customer and call him a product owner. We say that we are delivering working software that our 'customer' wants... but at the end of the day... we are just delivering a piece of the overall puzzle.

Subscribe to Leading Agile

Monday, November 2, 2009

Velocity in the Enterprise, Part 7

Okay... we've been going on a while now with this whole Velocity in the Enterprise series. Let's see if we can get things wrapped up with one final post. Last time around we talked about the idea of extending the Kanban metaphor to the enterprise. Just like agile user stories and teams are extended into agile projects and agile project portfolios... Kanban can be extended past the team to drive the flow of value across multiple teams working in concert to deliver multiple projects. Let's explore this a little further... starting with the team... then considering the project... and then looking at the project portfolio. We'll wrap by looking at cycle time and the role of management in enabling the organization to deliver.

The Kanban Team

We've already talked a bit about the Kanban team explicitly defining the states associated with getting a user story from backlog to done. These states are represented on a board... work in process limits are set for each state... and the stories move from state to state until they are accepted by the customer. When work gets backed up at any one process step... either due to an impediment or a constrained resource... the team has to deal with the underlying issue in order to get back to work delivering value. The work in process limits ensure that intermediate work-products get finished before new work comes into the system.

The Kanban Project

Now imagine a project that involves several agile teams all working toward a common set of requirements. Remember... our scenario here is that these teams are in some way dependent on each other to deliver an end to end feature. When teams must work together, it is important that one team not get too far ahead of the others before value gets delivered from the entire system. Imagine that the overall project has a Kanban board... one where the steps required to deliver the value feature include not only the normal design, develop, and test activities... but also include columns for the work delivered by each of the individual project teams.

The teams themselves limit the number of user stories they can have in play before and end-to-end feature is delivered on behalf of the overall project. Likewise, the project limits the number of value stories that can be in play at any one time. Let's be explicit... this can create a scenario where some teams may have to stop work while other teams on the project catch up. This forces the system to deal with the team that is going too slow before they can move forward. We need to focus our resources on speeding up the constraint rather than building inventory of partially competed value features.

The Kanban Portfolio

So... we have suggested that teams limit the number of user stories that can be in play at any one time. We have also suggested that projects limit the number of value features that can be in play at any one time. In a Kanban portfolio... we introduce the idea that the organization limits the number of projects that can be at play at any one time. The Kanban board for projects might have columns like initiation, iteration 0, release planning, execution, and deploy... each with their own work in process limits. These limits inherently result in fewer projects active across the organization... forcing the PMO to get projects finished before new projects can be started. Projects can't be started unless there are sufficient resources available to actually finish.

Cycle Time instead of Velocity

If we look at each level of the organization having only a limited number of work items (user stories, value stories, or projects) that can be in play at any one time... understanding that we are going to intentionally slow down some teams to speed the performance of others... velocity isn't going to be our ultimate measure of throughput. What we are going to start measuring... the metric we are really going to care about... is the amount of time it takes to get any single work item through the system. The team will have a cycle time... the project will have a cycle time... and the portfolio will have a cycle time. The question isn't how we can increase velocity... the question is how we can decrease the amount of time it takes us to deliver value back to the business.

Managing to the Constraint

Now we have a system that is laser focused on the delivery of value... not just at the team level... but across the entire project portfolio. No one team can get too far building user stories before they have to aggregate into a value story. No single project can go on too long with insufficient resources before it gets stopped in its tracks. The portfolio cannot keep approving projects that the organization does not have the capability to deliver. As managers, our role becomes understanding the flow of value across our organizations... understanding where that value is constrained... and redeploying people or teams to do the work that is most likely to actually speed up our ability to produce working software. Only by applying people and money to those areas that are slowing us down can we really get better at delivering faster.

In closing...

Okay... I think we have hit all the major points I wanted to address with this series. We've talked about where velocity works and in what kinds of organizations it is an effective measure. We've also explored where velocity doesn't work and where it can't be used as a measure of overall enterprise performance. With some of the Kanban, cycle time, work-in-process limit discussions, we've proposed an alternative to velocity that will help us measure our overall ability to deliver value.

I am concerned that we still have a problem in that this whole Lean, value stream analysis... this whole manage to the constraint idea is a pretty drastic shift in thinking about how to manage teams and projects. It really asks us to take a whole new approach to planning and delivery in our organizations. The more I think about it... I want to do one more post... an epilogue if you will... to maybe bridge some of this thinking with conventional wisdom to see if we can make a compromise that is easier to understand and implement. Either way... this is not the end of the conversation around this. I sincerely believe that Lean is the secret to scaling agile in the enterprise... but you know... we have to make this stuff simple and easy to understand.

Thanks for hanging in with me as I explored these ideas. As always... open to your feedback!

Subscribe to Leading Agile

Saturday, October 31, 2009

Our Halloween Jack-o-Lantern

Every year we head up to Burt's Pumpkin Farm to pick out the biggest pumpkin we can carry. We usually end up with one BIG one... one for each of the boys... and a few that we can bake up and turn into pies. Just for fun... I thought I would show you guys the results of this year's pumpkin carving activities.



It's hard to tell size with these dark photo's... but this is our big family pumpkin. I work with the kids on the design and the approach... but the carving duties are mine. We went with a design we have used in the past... pumpkin in flames!



The pumpkin on the left was carved by my seven year old son, Noah. The one on the right by my twelve year old son, Daniel. Daniel has started off wanting to carve a pug face on his pumpkin, but ended up with something more abstract.



This final pumpkin was carved by my thirteen year old, Zach. Zach was less than enthusiastic about being asked to participate in our forced family fun... but I do think that once he got started he had fun with it.

Happy Halloween everyone!

Subscribe to Leading Agile

Interesting Post... 10/26/2009 through 10/31/2009

Agilepalooza was a great event this week. It was good to hang out with the crew from VersionOne and all the great folks in Boston. I'm back in Atlanta for a day or so and then off to Oredev in Sweden. Living a bit of the crazy life right now... but all is good.

The kids and I got up early and carved our giant Jack-o-Lantern. We spent the next part of the day at a VERY STRANGE event for Pug enthusiasts (Pugfest... my 12 year old son wanted to go) and now the Florida Gators are on the tube. We are beating Georgia 14-1o and I sure hope they keep the lead. They are looking MUCH better than they have the past few weeks so I am hopeful! Tonight is Halloween so I am sure we'll do a little trick-or-treating in a bit. Nice to have some family time with the kids before I head out for the week.

Enjoy this weeks installment of "Interesting Post..."

Agile Projects and Project Management http://bit.ly/4vEuCK

Why We Delegate: The Darkness Principle http://bit.ly/2ZuUXc

Making Agile Requirements Work-No 3 http://bit.ly/3JZe1S

Ares 1-X Flies http://bit.ly/1hk3fc

Quote from Seth Godin on the Scientific Method http://bit.ly/sStkK

Central Agile Calendar? http://bit.ly/353u9K

Agility and the Motocross Tester http://bit.ly/IkmDM

The Power of Being Personal on Your Blog http://bit.ly/23k2hV

Lean and Scrum - Chicken and the Egg http://bit.ly/3JqcW4

Making Agile Requirements Work-No. 1 http://bit.ly/3nXLJj

"Change isn’t made by asking permission. Change is made by asking forgiv.. http://bit.ly/1sMPHB

A Story, not *the* Story http://bit.ly/2K3fnH

Uses for Google Voice http://bit.ly/2ww0zt

An Strawman Argument for Agile Project Management http://bit.ly/CTF6P

Kanban Drives Culture and Organizational Maturity Changes http://bit.ly/2P2Fnd

Trolls http://bit.ly/4CThIf

Switching stories mid sprint http://bit.ly/jcVJm

How to Give Yourself to Whatever the Moment Brings, and Forget Stress http://bit.ly/40uZB1


Subscribe to Leading Agile

Wednesday, October 28, 2009

Velocity in the Enterprise, Part 6

Okay... so the travel marathon starts today. Spent an hour in the Sweetwater Pub in the Atlanta airport earlier this afternoon. Had a nice Sweetwater IPA and a great bowl of 420 Beer Cheese Soup. Very tasty. Got on the plane and the weather was so bad in Boston, they kept us on the ground for extra hour while air traffic control cleared things out for us. So... I did a little writing... took a little nap (the beer made me sleepy)... and then got up and did some more writing. The good news is that Delta bumped me to first class at the last minute... so while I was late getting into Boston... at least I had a big comfy chair. Here is the result of my flight today... if you disagree... I am blaming it on the IPA ;-)

... last post in this series, we discussed that when we have a many-to-many relationship between teams and projects, velocity is not a meaningful metric at the project level. Velocity CAN be used to establish a steady throughput at the team level. Velocity CAN be used to help the team get better. Velocity CAN'T be used to establish the rate of flow of integrated end-to-end stories at the project level. Velocity CAN'T be used to establish the rate of flow of small independent projects at the portfolio level. In other words, the performance of the team IN NO WAY directly implies overall organizational performance at the project level... or at the portfolio level. Period.

Value Streams and Work-in-Process Limits

To get this worked out... we are going to have to take a look outside of some of our typical agile thinking. I want to explore for a moment some of the recent thought leadership around Kanban and see if there is anything we can apply. What new idea is Kanban fundamentally bringing to the table? To me... Kanban's primary contribution is that it is making the flow of value within the team explicit. We all know that every team has to move a user story from definition, to analysis, to design, to development, and ultimately test and deploy. This doesn't say anything about who does what, or in what order, it's just that Kanban elevates these steps, puts them on the board, and helps the team visually track how the features are being delivered.

By setting work-in-process limits on each step in the value creation process, on each column of the board, the team can easily see where there are constraints and bottlenecks limiting their ability to deliver valuable software. We can see when requirements are piling up in front of the developers. We can see when code is piling up in front of QA. We can see when we are building and testing a bunch of stuff that never gets integrated or deployed. Putting a visual control in place allows us to focus our time and attention on identifying and getting better at the parts of the process that are slowing us down.

When I was doing my 'Noodling on Kanban' series, I spent an hour or so talking to David Laribee comparing and contrasting the various aspects of Kanban with other agile methodologies. He said one thing that really stuck with me. He said that Kanban respects a reasonable division of labor (David's words). Scrum leaves the division of labor up to the team... it assumes specializing generalists. It assumes everyone can do everything and we can therefore treat the development process like black box. Kanban allows for the fact that sometimes we don't have specializing generalists, or at least that everyone doesn't do everything, and gives us explicit tools to manage how value flows across a series of somewhat independent agents (my words).

Bringing this back to our example... we might find a bottleneck between requirements and dev that tells us we need more developers... or maybe the constraint is with testing and we need more QA folks... or more maybe we need more folks that can deploy the code. We might find that we have a persistent problem with the build servers, or the CI environment, that is preventing us from getting value out of the system. I am not saying that we can't figure out these things in a self-organizing Scrum team... it's just the Kanban board helps us visualize it and make it more real. It gives us explicit controls to 'stop the line' when we have a problem rather than leaving that up the chance.

Cycle Time

Another aspect of Kanban that is new to the agile community is the idea of cycle time. Cycle time measures the time it takes to bring a new feature all the way from backlog to final delivery. If you look at VersionOne's implementation of cycle time, the tool can tell you how long (on average) that it takes to complete a single user story, and how that time changes depending on its relative estimate. We might be able to say that an average one point story takes 5-6 days. We might be able to say that an average two point story takes between 11-12 days. If you have cycle time... some folks believe that the iteration boundary becomes meaningless... that velocity becomes meaningless... that the team can get predictable just based on knowing how long it takes us to complete a story of some given size.

There is a bunch of evidence coming from the folks applying these ideas that the approach is working and can actually make the team more effective. To me though... at the team level... it is kinda six in one hand, half a dozen in the other. If the iteration is waste... if you don't need sprint planning, daily stand-ups, or review meetings... don't do them. If you don't need velocity measured at iteration boundaries... use cycle time. But... what if we can't use velocity because in our environment velocity doesn't work? Now it's not a matter of cycle time or velocity... velocity just isn't an option. Could cycle time provide an alternative?

Cycle time in the Enterprise

What I want to in my next post is extend the Kanban planning metaphor outside the team and see if we can apply the same principles across teams. Just like Kanban supports a reasonable division of labor across individuals with various degrees of specialization... Kanban will also support a reasonable division of labor across the teams that make up our product delivery organization. Rather than thinking about the value stream as being made up of specialists delivering on the steps in the development process, think about the value stream as being made up of the components required to deliver a complete integrated feature back to the business.


Subscribe to Leading Agile

Sunday, October 25, 2009

Mike Cottmeyer on Tour

This is the time of year in the agile community, where if you have made the decision to work the speaking circuit, your life spins out of control for a few months.

It started this year with the Agile 2009 conference in Chicago and is going to wrap up mid-November with the Agile Development Practices conference in Orlando. Between now and Orlando, I am heading to Boston to speak at VersionOne's Agilepalooza. This will be my second Agilepalooza and these are really excellent events. After Boston I am heading to Malmo, Sweden for Oredev 2009. This is my first year speaking at an Oredev conference, and my first trip to Sweden, so I am pretty excited. My wife gets to come along for that one so it will almost be like a little vacation! After I get back from Sweden I turn right back around and go to Orlando for Agile Development Practice to reprise my Agile PMP talk.

My goal this year was to reuse as much content as possible so I wouldn't have to be building so many new decks. Last year everything I did was brand new and I thought I was going to die! Anyway... I've gotten a lot of mileage on the Agile PMP deck and even managed to create a little new content along the way. By the way... if you are ever interested in having me come out and speak... let me know... we might be able to work something out. Here are the abstracts for all of my upcoming talks as well as my updated bio.

Agile Adoption and Scaling - Agilepalooza Boston and Oredev 2009

Agile methodologies are helping teams deliver software faster and with much higher quality than ever before. Given the success of agile at the team level, many managers are exploring the possibility of implementing these methodologies across the entire product delivery organization. These managers launch their adoption efforts only to uncover many common myths, misperceptions, and obstacles that derail their efforts before they really get started.

Organizations fail to become agile because they don’t understand what makes agile teams work. Breaking past traditional organizational constraints, even the constraints imposed by some of the better known agile methodologies, will free managers to create situationally specific strategies that support the formation of teams and enable them to deliver both reliably and consistently back to the business. Agile teams become the building blocks of agile organizations.

This talk will explore a roadmap for agile adoption that begins with teams and demonstrates how teams work together to deliver more complex projects and portfolios. Mike will expand the team concept to include capabilities and show how capabilities can be organized to optimize value across the enterprise value stream. At each step of the adoption process, Mike will demonstrate how to choose the policies, practices, and metrics that create learning and drive sustainable organizational change.

Agile Adoption past the Team - Oredev 2009

Discussions of agile often assume that there is a single team, assigned to a single product, with a single dedicated customer guiding all the product decisions. In reality, many organizations are building complex products that require the efforts of more than one development team. When teams have to coordinate to deliver a highly integrated product, the product owner’s job often becomes too big for a single person.

Not all the interesting scalability problems are reserved for the enterprise. Product Owners have challenges when trying to coordinate the deliverables for only four or five dependent development teams. Quite a few organizations are expanding the role of Product Owner to include Product Owner Teams and Product Owner Teams with Architects. These teams work in partnership with the Product Owner to maintain the product backlog and drive integrated decision making.

This talk explores a 3 month coaching engagement where the customer needed to coordinate requirements and design across five highly dependent development teams. Mike will show how the teams went from zero to hyper-productivity in a matter of sprints by implementing solid engineering practices and deploying a Product Owner team to coordinate deliverables across the entire product delivery organization.

The Agile PMP: Teaching an Old Dog New Tricks - PMI IT&T SIG webinar, Agilepalooza Boston, Agile Development Practices, and the Agile Edmonton User Group

Agile methods emphasize trust, empowerment, and collaboration—moving us away from command and control project management to harness the passion, creativity, and enthusiasm of the team. In established organizations, success with agile practices hinges on how well traditional project managers adopt new ways of thinking about project structure and control. Building on the principles of the Project Management Body of Knowledge (PMBOK®), Mike explores how PMPs with experience in traditional development can adapt their styles and practices to become effective agile project leaders. Mike tackles the hidden assumptions behind the PMBOK and explores agile approaches for managing time, cost, and scope. Taking an in-depth look at PMI Processes and Knowledge areas, he also explores ways to adapt them to agile projects. Project managers, business analysts, and other stakeholders will leave with a new way of thinking about project management practices within the agile context and new tools for delivering value in the face of uncertainty.

Bio

Mike Cottmeyer is the Vice-President and General Manager of Pillar Technology Southeast. Pillar Technology is the leading provider of agile transformation services helping companies develop the technical practices and leadership competencies required for sustainable organizational change.

Prior to joining Pillar, Mike was an agile consultant, coach, and evangelist for VersionOne. Before VersionOne, Mike was a senior project manager for CheckFree Corporation where he led a portfolio of projects for their online banking and bill payment business unit. Mike has 20 years of experience leading IT initiatives using a combination of traditional, agile, and lean project management best practices.

Mike is a certified PMP Project Manager and a certified ScrumMaster. He co-created the DSDM Agile Project Leader certification and holds Foundation, Practitioner, and Examiner level certificates. Mike is an honorary member of the DSDM Consortium, a founder of the Lean Software and Systems Consortium, and helping lead the AgilePMI Community of Practice.

Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including http://www.leadingagile.com and http://blog.versionone.com and occasionally for http://www.agilesoftwaredevelopment.com . Mike co-authored the paper "Rethinking the Agile Enterprise" for the Cutter Consortium and is co-authoring a book on Agile transformations for Addison-Wesley.


Subscribe to Leading Agile