Let's Define Our Starting Place

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

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

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

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

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

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

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

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

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

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

Summer Camp Day #3

Summer Camp Day #4

Subscribe to Leading Agile

It's About Context, People!

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

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

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

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

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

Subscribe to Leading Agile

Can I Do Perfect Scrum and Still Fail?

If you're not keeping up... you've got some homework to do. My last post called "What Do I Mean by a Complex Product" is required reading before you read this post. If you've got a minute, go read that post and then come back to this one... thanks! - Mike

Okay, so let's explore our Credit Card Processing team a little more. They are in a large organization that is delivering large, complex products. They know that the traditional way of planning and building software isn't really working. The big up front requirements analysis and the the big up front design is really slowing the organization down. It routinely takes 18 months or more to bring any new product offering to market. This company is at risk of having smaller, faster competitors take their market share. This team wants to do something about it.

They've heard quite a bit about Agile and Scrum and like the idea of getting to hyper-productivity in just a few iterations. Let's say that this team moves mountains and gets everything they need to be successful... they get the team through agile bootcamp and bring in a coach... they get a top-notch product owner, identify a scrum master, they build the ideal cross functional team, they do all the right XP practices, they do iteration planning, daily standup meetings, demos, and retrospectives.

This is a team that would make Ken and Jeff proud. No Scrum-but here.

The product owner does a great job working with all the stakeholders... both her external customers and the other product managers in the organization. She balances the needs of her market with the needs of the other products that are dependent on her product to be successful. She crafts a backlog that is full of the right features, in the right order, to get everyone all the features they need when they need them. The team starts building... and starts getting really good at delivering done-done software every two weeks.

Just as it should be... right?

We'll... yes and no. The PO for the Credit Card Processing team is probably doing a great job satisfying the needs of her Credit Card Processing customers... that is a good thing. It also sounds like she is doing a great job meeting the needs of her internal stakeholders. But what about that new Payment Processing product that the business is counting on for a significant part of next year's revenue? How has Scrum impacted the overall flow of value for the entire company? The short answer is... it hasn't.

Clearly, this Scrum team has done it's part. I'm not even suggesting that this is a Scrum problem. But, if the Payment Processing initiative fails, where does that leave our Scrum team? It leaves them in the same boat as everyone else... downsized, outsourced, and reorganized.

But Mike you say... what else can I do? The only part of the system I own is the Credit Card Processing engine. I'm doing the absolute best I can with what the people and resources I have been given... I have been successful to the best of my ability. You know what... you're right... you have been successful to the best of your ability. That is what is so frustrating with localized Scrum implementations, it just doesn't matter how good you do Scrum. How well your team adopts agile doesn't matter... how well you adopt Scrum doesn't matter... at the end of the day, all that matters is the value the business get's from your efforts.

In this case, they didn't get the ultimate benefit and the Scrum team suffered. Here is what you have to keep in mind... if the system is bigger that your Scrum team... if the enterprise value stream requires more teams that just yours to deliver... you need to take that into consideration as you adopt scrum. Getting good at team based agile is NOT ENOUGH when it comes to adopting agile in the enterprise... it is NOT ENOUGH when you are part of larger, more complex products. All the pieces have to work together.

We'll unpack this more over the next few posts... for now, let me know what you think.

Subscribe to Leading Agile

How Agile is Agile?

Agile ain't just any damn thing - Ron Jeffries

Here is what I want to know... when does agile stop being agile? Is agile only agile when we have 6 or 8 people sitting in one room doing pair programming? Is agile only agile when those 6 or 8 people are delivering cross functional features every week or two? Do I have to pass the Nokia test to be agile? Can agile be agile when I have to blend it with some PMI style practices? Can agile be agile when I have to do documentation to meet our corporate governance standards? Is agile agile when I blend it with RUP or Lean or Kanban? How about when I have 1000 people working across three continents, can that be agile?

Maybe the question really is... how agile is agile?

Maybe it's time to recognize that Ron is right. Agile ain't just any damn thing. Maybe we need a new term for what might be agile-like, but adapted to meet the needs of larger more complex enterprises. I am generally of the mind that agile is about quickly delivering value to our customers, getting fast feedback, being able to quickly respond to change, creating people centric organizations... one where individuals can make difference. One where we plan, but are not beholden to the plan. One where everyone is aligned toward creating the best possible outcomes. For me, it's always been more about the value I am creating than the rules I follow to create it.

So... maybe we are just learning that agile isn't as agile as we thought.

Thoughts?

Subscribe to Leading Agile

Getting Started with Agile... Two of 'Who Knows'

Okay... way too big a gap between meaningful blog posts. Since it has been so long, you might want to go back and take a look at the first post in this series called "Getting Started with Agile... One of Five". There is a bit of irony here around how this post came to pass.

I did almost all of this post two weeks ago. The post got really long. There were a few parts I was still hammering out, a few parts I still am as a matter of fact. The whole post sat on the shelf waiting for the unfinished parts. This morning I decided to break the post in smaller parts and start releasing it in chunks... pretty smart huh? ;-) Amazing how sometimes it is hard to eat your own dog food!

Here goes...

At last year's Scrum Gathering in Orlando, I heard Ken Schwaber make the comment that in his opinion, over 75% of all organizations using Scrum won't get the benefit they hope from it. That is a pretty depressing perspective, especially coming from one of the guys that invented Scrum. I don't know about you, but I am pretty convinced that this agile stuff works. I've seen it work, and I've seen it work well. If we know agile works, why do we have so little confidence in our ability to make it stick in most organizations?

Personally, I am not prepared to believe that Scrum's failure rate is because people don't implement Scrum properly. That's the whole Scrum-but argument. Scrum is such a light framework, if you give it a serious go, it's pretty hard to really do it wrong. That said, I do believe that many organizations aren't prepared to fix the organizational disfunction that Scrum is going to show them. Scrum's primary benefit is that it shows you the stuff you need to fix. If you aren't willing to fix the problems, you aren't going to get the benefit.

How many companies using Scrum are really trying to transform the entire enterprise? I'd wager that most Scrum teams live within a larger, more traditional enterprise. In these organizations, structure and culture are going to trump anything that a single Scrum team does with people, process, or tools. You could have the best team members, run a perfect Scrum, have big visible charts everywhere, and I bet you still stand a chance of falling into Schwaber's 75% statistic.

For everything we do to build a high-performing agile team, the organization is going to work to pull that team a part. The pull might be intentional, led by people that are threatened by any change to the status-qou. More than likely, the organization just doesn't get it. The value delivered by the Scrum team just get's lost within the larger underperforming organization. Even though the team was effective, it just never really translated to any kind of measurable value for the larger organization.

So therein lies the problem. What does it mean to have a successful Scrum team in an organization that isn't performing very well? What do you do when Scrum helps you identify an impediment that can't be solved by the team, but no one outside the team seems to care? Scrum ends up being a local optimization within the larger enterprise value stream. Unfortunately, it doesn't matter how hyper-productive your team becomes... getting higher team velocity isn't your biggest problem.

The trick to adopting agile is to form a team around a business problem the organization actually cares about solving... one that will increase bottom line performance. And this is where the conversation get's interesting. Many of us aren't responsible for improving the whole system. We are only empowered to do our part. We can only operate within our circle of concern. Our challenge is to figure out a way to make our local improvements, but in a way that is respectful of the whole.

There are a few things I want to suggest that will help you understand how your company looks at value delivery. For the rest of this post, I want to talk about aligning your agile pilot team to something your organization actually cares about. The important thing to realize is that not every company has the same kind of goals. If we are going hook ourselves up to big business problems, we need to understand how our companies look at value... how they look at the unit of production. For most, a unit of production is not a single user story delivered by a single team.

Next post we'll talk about a few 'units of production' that I see larger organizations really care about.

Subscribe to Leading Agile

Getting Started With Agile (#agilewebinar)

Tomorrow (Wednesday, February 24, 2010) I am doing a webinar in partnership with VersionOne titled 'Getting Started with Agile'. The talk is going to go beyond some of the basics of spinning up agile teams, and focus more around how to choose a pilot project... and how agile teams can co-exist within a more traditional organization.

I'm thinking of this talk as almost a prequel to some of the presentations I've done recently on agile transitions and scaling agile to the enterprise. If you are thinking about pulling together a team to give agile a try, check out my webinar. You'll leave with some practical advice that will help make sure your first step toward agility is a successful first step.

Head here to register for the event. We are getting started at 12:00 PM ET.

Subscribe to Leading Agile

Working Software or Customer Value

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

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

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

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

The potentially shippable code is always going to win.

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

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

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

Subscribe to Leading Agile

What Do You Value?

Sometimes I think we are missing the point.

I am becoming more and more convinced that building organizations around teams is the real secret to building agile organizations. How we setup our teams, what we have them work on, and how they work together with other teams... all determine how well value will be created for our business and ultimately our customers.

Some things are really important about teams... and some things just aren't. Getting straight about what we are are actually trying to accomplish with our teams will help us get past some of the dogma, methodology battles, and Scrumdamentalism that is preventing us from incrementally adopting agile practices. Is our goal to adopt Scrum or is our goal greater business agility?

Important Stuff about Teams...

Teams Deliver Value

Sometimes this means that teams work on cross functional threads of working software. Sometimes it means that teams deliver services that will be consumed by another part of the organization. Teams might be part of the business and handle billing... or marketing... or sales. I only care about teams being cross functional in the sense that the team needs to have what it need to deliver the value is was created to deliver.

Teams are Accountable

Teams make and meet commitments and are responsible for delivering on those commitments. They are accountable for outcomes. I don't care so much how they deliver those outcomes... assuming that they operate within moral and ethical boundaries... I care that teams do what they say they are going to do and deliver the outcomes that they promise to the business

Teams are Predictable

Over time, the business should be able to provide specific inputs and get reasonably predictable outputs. Throughput should trend up... and we should know why it is trending up. If throughput is trending down... we should be able to assess and understand why it is trending down. If throughput is variable... it should at least have a reasonably predictable rolling average. If teams aren't predictable... we can't plan anything.

Teams get Better

We need to have some mechanism in place for getting better over time. This could be a sprint retrospective... or it might be a Kanban board. We can rely on the knowledge and creativity of the team to improve... or managers can use specific tools that help make problems visible and help the correct the problems. It cannot be okay to accept mediocrity.

Teams are Transparent

The business needs to be able to understand exactly what the team is working on and how the deliverables relate to the objectives of the business. The business needs to understand what problems the team is having so that they can help get them resolved. Team performance metrics need to be visible and explainable

Not so Important Stuff about Teams...

Teams have Product Owners

I am probably going to get myself in trouble here... but I don't think that the Product Owner is all that important. It is important to have a well groomed product backlog. It is important to have someone to answer questions for the team on behalf of the business or the customers. It is important that the business is accountable for making decisions in a timely manner and giving guidance to the team.

If that can be done by a single person called a Product Owner... so be it. All I know is that it needs to happen.

Teams have ScrumMasters

Again... going to get in trouble. What I really need is someone to help the team stay on track... to maintain the vision... to help remove impediments... and to collaborate with the team to help them improve. If this is a ScrumMaster, great. It might be a resource manager that fills this role... it might be a project manager. It might be a good dev lead or a product architect.

Teams do Daily Standup Meetings

What I really need is communication between team members. I have worked with teams that all sat in the same space... worked together daily... and always knew what was going on. If a daily standup meeting adds value... do it. Just remember why you are doing it and if you are getting the outcome that you need. Communication... transparency... shared accountability... those are the important things.

Teams have Planning Rituals

The team needs time to plan. They need time to get their head around the problem and coordinate the work. They need a time to inspect and adapt. This might come in the form of a sprint planning meeting and a sprint review. It might be done ad-hoc as a individual requirement is moved from the backlog into the in-process queue.

Do We Care About What or How?

When folks are just getting started with Agile... it is easy to get caught up in the how. How are we going to plan... how are we going to meet... how are we going to review outcomes... how are we going to ensure accountability. We need to focus on what the team is going to deliver, and the attributes of that delivery that are important to the business.

It is extremely important that a team delivers something of value on short cycles... that they are accountable... that they value predictability... that they get better over time... and that they are transparent to the business. To the extent that Product Owners, ScrumMasters, daily stand-up meetings, and planning meetings help me get there... they are useful tools might get included.

These things could be out of sync with your organization and actually impede your ability to adopt agile. You might need to think about what you're really trying to accomplish and come up with some situationally specific strategy to build teams... and to get teams predictable.

It might be unreasonable to ask the business to take a Product Manager and turn them into a Product Owner. It should be perfectly reasonable to ask them to make sure teams have the requirements they need to build software... requirements that accommodate change... help mitigate risk... and deliver value better and faster back to the business

So my question... are you more concerned about adopting specific agile practices or doing what it takes to build well functioning teams?

Subscribe to Leading Agile

Subscribe to Leading Agile

Adopting Agile Presentation

Last night I had a great opportunity to deliver this slide deck to the Turner Agile User Group here in Atlanta. The talk was on Adopting Agile in the Enterprise. I am still working on the overall message and consider the presentation in beta. This will end up being the deck that I do for the Oredev conference in Malmo later this year.
Adopting Agile

View more OpenOffice presentations from Mike Cottmeyer.

Subscribe to Leading Agile

Subscribe to Leading Agile