Agile Chronicles

The Agile Chronicles blog has moved!

After several years of blogging here at AgileChronicles.com, it’s time to grow. As of August 21, 2009, we have moved our blog to a shiny new location. From now on, you’ll be able to read the latest from your favorite bloggers, find agile development news and leave your comments on our new Agile Management Blog.

This site will remain active so you can come back and read posts you’ve enjoyed in the past. But we invite you to join us at http://blog.versionone.com for current posts.

If you're a subscriber, you can update your RSS feed here.

Thanks…and we’ll see you at our new blog!

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.

Agilepalooza Charlotte

Okay guys... if you are going to be anywhere near Charlotte, North Carolina next week... you have to find your way to the first East Coast Agilepalooza! We have a lined up a great group of speakers for the event... Jeff Sutherland... David Hussman... Guy Beaver... Joe Little... and yep... yours truly... Mike Cottmeyer.

Agilepalooza is a not-for-profit community event sponsored by VersionOne. It is meant to be a fun, low cost gathering that brings internationally recognized coaches and trainers into the 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 community.

For the low, low price of $69... attendees will get a full day of agile learning, breakfast, lunch... and a rockin' good time. If there are funds left over... they will go directly back into the Agilepalooza program or be donated to the local agile user groups supporting Agilepalooza. Go... now... register!

Can Managers Lead Agile Teams?

Oops! This post has moved to the Agile Management Blog. Click here to read it: Can Managers Lead Agile Teams?

Managers are Grown-Ups Too

One of the first things I do when I meet a new team is ask them to introduce themselves and tell me a little about what they do. We go around the room and people say things like "hi... I'm Bob and I am the Product Owner" and "hi... I'm Sue and I am the ScrumMaster". Well inevitibly... once we get going... usually by lunch time... I find out that Bob is really the Director of Development and Sue is the really the team's Project Manager.

Here's the deal... we agilists haven't given our managers anything to do. Many of us believe that there is a role for management on agile teams... some don't... but we never really say just what that role is. Remove organizational impediments... boring. Make sure people have development plans... boring. It's not that those things aren't important... but managers are used to being in the thick of things... they are used to running the show. They are problem solvers.

Because we haven't given manager's a role... they have gone into hiding. They call themselves Product Owners and ScrumMasters but in reality they are still Dev Managers and Project Managers. They are still responsible for the performance of their team members and their organizations are still holding them accountable for the outcomes of their team. Here is my question... is this a healthy pattern or an agile anti-pattern... a smell?

It seems to me that we are asking everyone one else on the team to learn, grow, and adapt. We are asking every one else on the team to learn servant leadership and to be collaborative and inclusive and create safe environments. People on teams are going to have managers... that is just a fact. Is it a problem to ask a manager to serve as a Product Owner or a Scrummaster if having that role makes sense? Can we trust a traditional manager to take agile leadership seriously and learn to behave with a servant leader mentality?

The best managers I've ever had... agile or not... were servants of the team. They knew how to lead and empower... to prioritize and faciliate. These leaders allowed me to decide what I wanted to work on and held me accountable for my outcomes. We talk alot about how agile allows us to start treating our team members like grown-ups... I'd like to see us start treating managers like grown-ups too. Agile teams are going to have managers... let's really start giving them something meaningful to do.

Get Something Done.. Be Agile

How many times has the team decided they would start on every item without getting any items done? One comon Agile myth is that it is ok to start on every task just as long as you get them all done by the end of the iteration. We all know what most comonly happens is that the team underestimates the amount of time it actually takes to get work done, and end up not finishing anything they started.

I am starting to become a believer in the Lean WIP concept! It just seems logical to me that with a WIP limit in place, fewer things move to in progress and more work gets done. This means fewer items get left started and not completed. This means happier product owners and project managers.

The picture that came to my mind as I thought of this was Thanksgiving dinner. What if I started cooking everything all at the same time, but did not agree to finish cooking anything. Then as people became more hungry, I agreed to complete various items at various times. I just could not imagine that the guests for dinner would be pleased with such a concept.

Teams need to get used to the concept that they are not at work to punch the timeclock, nor will they receive recognition for How much work they got underway! Our effectiveness is based on the amount of work that gets completed. One of our goals should be to never leave the turkey half baked! We all need to get in the habit of doing as we say and saying what we will do. We need to do a better job of continuous flow of information and maintaining the highest levels of visibility.

Institute best practices, be Lean, be Agile, enjoy Life!

In the absence of done... there is risk.

Agile methods put a high premium on what it means to be done. But if done is so valuable to our projects... just what exactly does done mean? Is there one universally accepted definition of done... or are there varying definitions of done depending on your circumstances? Personally... I have used and coached several definitions of done and am pretty much cool with all of them.

My favorite definition of done was something that I used back in my CheckFree days. We defined done as a feature that was designed, documented, developed, tested, accepted, ran on the UAT server, could be run from the Product Owner's laptop, and that the Product Owner was proud to show to their customer. We did not specify 100% test coverage or that the software was released to production... were we done?

What about the situation where a team is transitioning to agile and trying to iterate through a big up-front design document to ultimately get ready for a big back-end test effort after all the code has been written. That team defined done as working software with 100% test coverage and deployed to the alpha environment. Were they done?

Here is a situation I was talking through today. What if you are developing a feature that has dependencies with several component teams across a large complex enterprise. If one of the component teams delivers an API that is fully designed, documented, developed, tested, meets the specification, and is ready to be integrated with the other components into the larger feature... is the component team done? What about the feature team?

Done can mean lots of things... and the definition of done needs to be defined by the team doing the work and the organization receiving the work. To me... it is a matter of risk. How much risk are we absorbing leaving the code in it's current state?

While not perfect, I felt pretty good about the definition of done on my CheckFree team. The transitioning team I mentioned is actually absorbing quite a bit of risk with that big back-end testing effort... but given their circumstances... I would accept that definition of done and work to mitigate the risk. In the last scenario... the component team is done but the feature team is not until the code is integrated. Does the component team absorb some risk... absolutely.

The definition of done should be driven by the potential impact to the project. We are assessing the risk that we think ourselves done but really aren't. We are assessing the risk that we have to go back and fix something. We are asking how much risk we're absorbing if we allow partially completed work to move forward in the development process. That could be as little undone work as allowing less than total test coverage or as much as allowing a component team to move forward before their work has been integrated into the larger, customer facing feature.

In the absence of done... we have risk. I am okay defining done differently as long as we address the risk and have a solid strategy for mitigating that risk.

Scrum or Kanban... it's not Black or White

Oops! This post has moved to the Agile Management Blog. Click here to read it: Scrum or Kanban... it's not Black or White

But what if I already know everything!?

But hang on a sec! You might be thinking that you have all the information you need... and if I have all the information I need... there is no need to hold off making that decision. Right?

The problem with making a decision early is that you don't always know what you don't know. By buying some extra time... by deferring an option until closer to its expiry... you create an opportunity to learn MORE information... information you probably didn't even know would come available.

You might even end up with some new options... and guess what... those new options have value too! And that is the real rub... it's not just the value of the of the options that you have now... it's also the value of the options that have not yet presented themselves. There are times when it makes sense to decide early... but make sure you know why. Fear of the unknown is not really a good reason to decide early.

If you are deciding early because you think you know everything... you might be closing off options you didn't even know you had.

The Price of Freedom

How do we measure our freedom? How much does it really cost to make decisions that help us remain free? What steps do we take to endorse continued freedom and what do we sacrifice to make freedom available to everyone?

To some this may sound like pure patriotic banter, rest assured, there is a much deeper message. For some time, I have been advocating empowering Agile teams and allowing them the freedom to make choices that impact the progress on the project they are working on.

I have also at great length discussed the level of accountability that comes with the power to make decisions. After a period of deep retrospection, I have come to realize that for every organization, there is a price to be paid for freedom.

For most, the price is small in the sense that minor adjustments help the team stay focused and on course. For others however, this is not the case. People harness their new found power and create a negative environment where the work takes sidebar to personal and team agendas. This in turn negates the value Agile provides and taints the pool of hope for Agile to succeed.

In order to best take into account the one loose wing nut or rouge team within your organization, it is vital that some organization take place that sets a clear and solid mission with directive that establishes a goal with clear boundaries. Many people may feel like I am discussing Utopia here, I would argue that I am discussing practicality. It is OK to empower the team as long as the outer walls of the room still remain in place. It is more than OK to empower team members to make decisions that allow them to contribute at a higher level. It is not OK for team members to take this power for granted and create a price tag for hijacking Agile. (I wonder if that URL is already taken? http://www.highjackagile.com/?)

At this time of great economic recovery, we need to "let the product lead, make everything visible, and inspect & adapt often". Doing so, will allow for the price of freedom to remain low and afford organizations with Agile Implementations continued success. Now is the right time! Wave your Agile Flag! Consult your product council. Build tangible memories for years to come!