Agile Chronicles

Oredev 2009 Malmo Sweden

I got an interesting invitation to head to Malmo, Sweden this year for the Oredev 2009 conference. I'll be doing two talks in the agile track... one on scaling agile and the other an experience report based on the coaching gig I did earlier this year. Regular readers will recognize some of the topics I plan to speak about.

The Manager’s Guide to Agile Adoption

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 – An Experience Report

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.

Speaker Bio

Mike Cottmeyer is a product consultant and agile evangelist for VersionOne. Prior to joining 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 and a founder of the Lean Software and Systems Consortium. Mike speaks internationally on the topic of Agile Project Management and writes for several blogs including http://www.leadingagile.com and http://blog.versionone.net and occasionally for http://www.agilesoftwaredevelopment.com.

Agilepalooza!

Are you going to be anywhere near San Francisco, CA on May 29th? You need to find a way to get to AgilePalooza.

AgilePalooza is the first of a series of not-for-profit community events presented by VersionOne. It is meant to be a fun, low cost gathering that brings internationally recognized coaches and trainers into community for a day of learning and advancing agile methods. None of the speakers are paid to present or participate...they are offering up their services simply to support the agile community. For the ridiculously low price of $69... attendees will get a full day of agile learning, breakfast, lunch and good times. If there are any funds left over after the event they will go directly back into the AgilePalooza program or be donated to the local agile user groups supporting AgilePalooza.

Go to http://www.agilepalooza.com for more information and to register. Where else can you get this kind of Agile love for only $69?

Books I Recommend Often...

Quite frequently I am out talking to traditional project managers or new agile teams that want to learn a little bit more about all this agile stuff. Inevitibly I get asked what books I recommend for folks trying to sharpen their agile chops. Thought I would share a few that I recommend the most with a few words on why I think they are important:

Extreme Programming Explained - Kent Beck

This was the first book on agile I ever read and it really is foundational to the whole agile movement. The practices behind XP are the the secret sauce that makes all the agile project management and leadership stuff really hum.

Managing Agile Projects with Scrum - Ken Schwaber

How can you talk about agile nowadays without knowing something about Scrum? This book does a great job explaining the project management side of Scrum and is a great resource for someone just getting their feet wet with agile.

Agile Estimating and Planning - Mike Cohn

No one explains agile planning better than Mike Cohn. Release planning... got it. Velocity... got it. Planning poker... got it. If you understand the fundamentals and want to put planning structure around agile, read this book. It is essential for running a disciplined agile project.

User Stories Applied - Mike Cohn

Two and a row from Mike Cohn. User stories tend to trip people up. Understanding how to write requirements as functional threads valuable to a customer is hard... this book helps you do it better.

Agile Software Development - Alistair Cockburn

I can't have a list of agile books without one from Alistair Cockburn. I probably like this book best, but don't usually recommend it first. It describes software development as a cooperative game... similar to musicians improvising on stage. A bit esoteric, but a brillant piece and a must read for the more advanced practitioner.

Software Project Manager's Bridge to Agility - Michele Sliger and Stacia Broderick

This is really the first book that mapped the processes behind the PMBOK with agile methods. These ladies and I really see the world the same way. I am a PMP and this is the one I always recommend when talking to the PMI crowd. It is a must read for the PMP trying to manage an agile project.

Scaling Lean & Agile Development - Bas Vodde and Craig Larman

I am not as sold on this one, but it is one of the few that addresses agile at scale. There are a few things I disagree with and I think it is a little dogmatic about taking the feature team approach. It is well written and provides a valid perspecitve on how to scale agile to the enterprise.

Scaling Software Agility - Dean Leffingwell

In my opinion this is the only book that adequately addresses dealing with agile at scale in a complex enterprise... period. If you are building complex applications, systems of systems, in a large organzation... this book is a must read. This is the one I find myself recommending most frequently as of late. Its the only book that really challenges the idea of a feature team and provides a credible alternative.

Managing Iterative Software Development Projects - Kurt Bittner and Ian Spence

This one is a little non-agile... almost RUP... but I think it does a solid job of explaining iterative and incremental software project management... with a bit of a nod to the agile practitioner.

Any others that should be added to this list? Put your recommendation in the comments... but make sure to explain why it needs to be added. 

Throttling the Agile Enterprise

It feels like a year ago I did the post Enterprise Constraints and Feedback. The past few weeks have been filled up with the Lean & Kanban conference and some client work that required my undivided attention. Toward the end of that post, we talked about 6 principles that allow your organization to properly throttle work through your agile enterprise. I wanted to take a moment this afternoon and explore those a bit and see where it takes us:

Make small bets by approving smaller projects

How many of you guys have been on an 18 month project? How many of you have been on an 18 month project that got killed or totally re-scoped after a year or so? The reality is that in today's economy the uncertainty associated with large scale software development projects is just too high. The longer it takes to get product to market, to get real customer feedback, and to start generating revenue... the more risk you accept as an organization. Given our track record of project failure... smaller projects are less risky projects... and therefore better projects to approve.

Prioritize for finishing projects rather than starting projects

This is a complicated one. It gets into this whole discussion around keeping work in progress to a minimum and optimizing for the overall throughput of the organization... rather than for optimal resource utilization of the individual. If you are an agile organization, and have bought into the idea of organizing around teams, you should be pretty good with the idea of 'done done'. 'Done done' means that we don't deliver partially completed work. The only features that count are the ones that are ready to be shipped to the customer.

Interleaving a bunch of partially complete projects just makes the overall system deliver value less effectively. If we have three projects in the portfolio that are all planned to take three months each... and I do them one at a time... when will they be done? The first one will be done in three months, the second in six months, and the third in 9 months. What happens if I try to do all three at once? Best case you might deliver the first in 7 months, the second in 8 months, and the third in 9 months. More likely you'll deliver the first one in 12 months and the other two will get killed.

Don't start projects that you are unable to finish

Building on this idea of prioritizing for finish rather than start... if there is more than one team that has to work together to deliver a project... or even a MMF... and we can't get all the work 'done done' within the time-frame allotted, don't start it. We usually use some form of logic that goes something like... well, we have this person or this team with nothing to do... let's get them working on the next project. Keeping people busy is not a good reason to start project work.

The problem is that starting the next project dilutes the organizational focus from working on the projects that are already in process. Chances are pretty good too that when the other teams free up requirements will have changed or we'll learn something that leads to significant rework. This is tough pill to swallow... but I would rather that idle team go help another constrained team... or even do nothing... rather than start work on a project that is underfunded and low on the priority list.

Work on the highest priority projects first

All of these are pretty closely related, but if we always prioritize the project that is most valuable to the business... and we always focus on getting projects to 'done done'... and we don't waste effort by working on things that don't have the support of the rest of the organization... we know that we will always be delivering the most valuable features to the business with the least amount of waste from building software that might not ever be consumed. This might mean that teams are idle at times... it might mean that teams need to be redeployed... and it might mean that you need to let some folks go.

Make sure to read the next section before you go and start laying folks off from your team... there is hope!

Provide support for those teams that are slowing down your ability to deliver

If you find that a large part of your organization isn't busy because one particular team is slowing everyone else down... cool, you have just found where you need to go help. An enterprise full of teams building software is a continuously shifting set of constraints just waiting to be optimized. Someone at the Lean/Kanban conference said that a perfectly optimized organization has only one constraint optimized at a given time. An organization with every team optimized is actually the least optimized overall system.

Having identified the team that is slowing down your ability to deliver, you have identified where you need to go get better as an organization. By focusing your attention on the team that is preventing the other teams from delivering valuable work to the organization, you are focusing on the area of your development organization that is going to yield the most productivity gains for the overall system. It does not make any sense for a team to get better delivering software if they are not your primary constraint.

Establish an enterprise level velocity

If each team has a velocity sprint over sprint... and we start making smaller bets... and we prioritize for start... and we don't start things we are not able to finish... and we start working on the highest priorities first... and we elevate our constraints... you know what happens? We can start measuring project velocity across the enterprise just like we measure point velocity within the team.

Pretty cool idea... let me know your thoughts on this one.

AgilePalooza - An All-Star Engagement!

 

May 29, 2009

Not very often does a speaking engagement like AgilePalooza stroll along where so many Agile All-Stars are available for an intimate session! Not only was I fortunate enough to hear about it, but I was also asked to speak on a topic that is very near and dear to me. I think we all feel that we either spend too much time meeting or the meetings we have been asked to have are becoming mundane and outdated. The content is not often what we would expect and often times the right participants are not presesnt..

The great news is there is an answer! There is a light at the end of the tunnel! As Agile is becoming more and more lean, the time teams spend together needs to become more and more valuable! My session at AgilePalooza will be focused on making meeting time more effective and meaningful. The description for the session reads:

“Facilitation Foundation”- Not Another Agile Meeting
Many teams struggle with the meaning behind or the value provided from attending Agile Meetings. This session is designed to help people better understand the logic behind Agile meeting patterns and is intended to present a new and more creative approach to meeting facilitation.

This session is geared towards both team members and product/project managers as well as any person who facilitates a session. Each participant will leave with a better understanding of why meetings fail or become painful and what they can put in their toolkit to help engage and bring added value to the meetings they attend or facilitate.

If you are out in the Bay area, I encourage you to attend! If you are not in the Bay area, keep your eyes peeled here as other locations are sure to be made available in the future! See you in SFO!

http://www.agilepalooza.com

Lean or Kanban or Agile

Here I am.. Sunday afternoon.. Mother's day. Just got back from taking the family out for a low key Mother's day celebration and now I've got a little quiet time before the week begins. The conference last week was quite a rush... had a great time... met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing.

A bit of history... Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then... and looking back I can see how much it influenced how I think about agile... and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me... it was just a different way of looking at the same fundamental truth.

A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope... the guy touching its leg says the elephant is like a tree... the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole... they each describe the elephant from their own particular point of view.

As I watch people debate over what it means to be agile... it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams... scrum brings a valid perspective. If your focus is more technical... the practices of XP tend to resonate. If you come from a larger more structured organization... you might need AUP or DSDM. If you have a really small team of experienced developers... let's talk Crystal. Context is everything.

It seems to me that much of our debate is out of context. When we get dogmatic about one methodology... about one set of practices... we are often not taking the other person's context into consideration. That is why the Agile Manifesto was so powerful... it was a set of value statements... it was a set of principles... that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration.

I don't think the Lean/Kanban proponents are saying they have found a better way... I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices... or have adopted them and need something else to increase their productivity.

Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"...

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves"

The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum... nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant.

My personal take...

Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do... and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless... I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it... I'll get rid of it.

My goal has never been to do Scrum... my goal is to build great software as fast as possible. In Scrum process improvement is implicit... the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary.

To me the idea of Lean is a bit broader... lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev... turn it into a product idea... get the work assessed and approved... built... tested... delivered to the customer... billed... and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool... Lean is a philosophy.

A team could use a Kanban board to manage the backlog item through the development phases... analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams... identiying constraints... eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions.

As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember... agile is all about uncovering better ways of developing software by doing it and helping others do it.

Lean/Kanban gives us another set of tools to help that come about.

Enterprise Constraints and Feedback

Last post we talked about two facets of communication in the agile enterprise... constraints and feedback.  Constaints flow from the higher levels in the organization... to give guidance... to constrain the actions and decisions of the lower levels in the organization. At the lower levels the agile teams are empowered to make decisions within the context of the higher order constraints.   

Constrants are established at the right level of abstraction so that decisions are made as close to where the work is actually getting done.  The constraints of the enterprise serve to establish context... product ownership if you will... for the independent agile teams.  Feedback from the teams is essential to influence the actions and decision-making at the higher levels of the enterprise.  

 

The higher order constraints are constantly evaluated against the realities of delivering working software.   

 

At this point it seems we have a reasonable starting place to structure our agile organization.  What we are basically building is an organizational framwork so all our agile teams are working toward the common goals of the business.  We are working on a conceptual model for organizing our agile enterprise so that we can rationally decompose an enterprise product backlog.  

 

Now let's lay down an analagous framework... a conceptual model for prioritizing that backlog and throttling work through the agile enterprise.  To do this... once again we are going to have to discuss a few foundational principles that will enable enterprise agility...

• Make small bets by approving smaller projects
• Prioritize for finishing projects rather than starting projects
• Work on your highest priority projects first
• Don't start projects you are unable to finish
• Provide support for those teams that are slowing down your ability to deliver
• Establish an enterprise level velocity

Over the next few posts we'll explore these ideas and see if we can identify any others.