Agile Chronicles

The Agile Chronicles blog has moved!

Admin — Fri, 21 Aug 2009 14:38:46 -0400

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

Mike Cottmeyer — Wed, 05 Aug 2009 10:16:46 -0400

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

Mike Cottmeyer — Tue, 04 Aug 2009 09:01:53 -0400

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?

Mike Cottmeyer — Mon, 27 Jul 2009 07:19:28 -0400

If we are going to start treating managers like grown-ups... and start asking them to behave like agile leaders... and giving them a real role on an agile team... let's begin by exploring why we excluded them in the first place. Maybe if we can take a step back and think about the original problem we can find a more inclusive solution.

Here is my take...

Agile excluded management because people are sick of being yanked around. They are tired of managers telling them what to do... changing their mind... and then deciding that they want everything according to the original schedule. People are tired of being treated like cogs in a machine and being moved from project to project and team to team like interchangeable parts. People are tired of being micromanaged and having to check their brains at the door.

People are tired of building low quality software just to meet unreasonable schedules... to meet unreasonable budgets... imposed by unreasonable Dilbertesque managers. They want to be connected... they want to be treated like whole... thinking... feeling... creative human beings. They want to be treated like people that have something more to contribute than just two hands and a social security number. People want to do meaningful work and be part of something bigger than themselves.

I always imagine those early Scrum teams sitting around going... hey, this is a bunch of crap! These managers can't make up their minds. Just put us devs in a room... leave us alone... and let us write some code. Give us one person... we'll call him a Product Owner... and we'll build whatever he wants. Oh... and by the way... we need someone to go and run interference and fix stuff for us. Hey you... come over here and be our Scrummaster. But none of you people can tell us HOW to do our work... we are going to self-manage and self-organize!

Think for a minute about what is really being said here:

The Product Owner is the personification of a well aligned business. The Product Owner is the team's answer to getting yanked around. They are the product manager, the project manager, the business analyst, the UX designer, the UAT tester, and in some contexts the dev manager. Can't get the business to make up it's mind? Well... we'll make it simple for you... Frank gets to decide. He can go argue with himself... we are going to build some software!

The Scrummaster is there to make sure the team has everything it needs and that any impediments are out of the way. Tired of petty, controlling, micro-managers... tired of being bartered between teams like a head of cattle... let's take away all of Sue's positional authority and call her a Scrummaster. The Scrummaster is everything good about management... explicitly leaving out the stuff we don't like.

But wait... now that we don't have all these project managers and dev managers... who is going to tell us what to do? Well... I guess we will. We will be self-organizing and self-managing. We'll take charge of our own destiny... our own careers... and earn the right to be left alone. We'll plan together... meet every day to talk things out... and review our work with the Product Owner. When we are done.. we'll figure out for ourselves how to get better and improve.

Sounds nice huh?

The problem is that all these managers that used to be in charge didn't go away... they still work for the organization. And guess what... they liked being in charge. They got paid well for it... it was good for their egos. Why do we think these folks are just going to go away without a fight!? Not giving them something to do only encourages managers to resist... and that resistance puts all our agile goodness at risk.

Product Owners fundamentally address the organization's alignment problem. What if we could use our managers to help really get our organizations into alignment? What if the business could really articulate what was important and managers could clearly communicate what it was that their teams needed to build... would the need for a single Product Owner be so important? Somehow I don't think so.

What about Scrummasters? If we could teach our managers to be servants of the team... to be real leaders... to be facilitators first... would we still need a separate role? What if... once we solved the alignment problem... and managers were no longer given unreasonable deadlines... unrealistic budget constraints... and more work than their teams could handle... they started behaving in ways consistent with a Scrummaster but retained their positional authority? Would that be all that bad?

Going into organizations and telling them that each team has to have a Product Owner and a Scrummaster in addition to a traditional manager doesn't fly in most organizations. Telling managers that they no longer have authority over their teams because their teams are now self-managing really isn't going to work either. Personally... I think we need to slot our managers into one of the two roles... priority and business alignment (the PO) or the management and issue resolution (the Scrummaster).

We should allow for and embrace their positional authority and incent them to encourage more empowering... self-organizing behavior in their teams. Many managers will be able to rise to the occasion... many of them are already there. Those that can't need to be coached and developed just like any other employee of the business. Those managers that cannot or will not change then have the option to stay or move on to a more command and control organization.

Managers are Grown-Ups Too

Mike Cottmeyer — Sat, 25 Jul 2009 20:45:19 -0400

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

Lee Henson — Thu, 23 Jul 2009 15:41:44 -0400

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.

Mike Cottmeyer — Mon, 20 Jul 2009 20:57:25 -0400

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

Mike Cottmeyer — Mon, 13 Jul 2009 09:51:31 -0400

It's been fun the past few months to watch Kanban get some traction out in the community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson... this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.

One of the things I found really interesting over the weeked was the words some folks were using to describe the value of Kanban. They were using words like 'increased visibility' and 'buidling trust' with the business. While I wouldn't argue with any of that... I was struggling to figure out how the benefits of Kanban were any different from how we would describe the benefits of Scrum?

If both methods 'increase visibility' and 'build trust'... there has to be something more. In my opinion... the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.

Let me explain...

Scrum takes the approach that the team is a black box. The business puts requirements in... and after some predetermined amount of time... they get working software out. Within that black box... the team gets to self-organize... they get to self-manage. The business gets to decide what... the team gets to decide how. The processes inside the team are abstracted from the business AND from management.

Kanban takes the approach that the team is a white box. The business puts requirements in... but rather than leave it up to the team to figure out how best to deliver the work... management plays a role in defining the work. There are explicit workflows... work in process limits... and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.

One of the earliest agile books I ever read was Mary Poppendieck's 'Lean Software Development: An Agile Toolkit". Not long after that I read David Anderson's "Agile Management for Software Engineering". Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months... I found myself wondering what was so new.

We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered... we are encouraged to help them get finished before we start on something new.

Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints.

For some teams... in some environments... it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That's where I am not totally sold. For now... for me... Kanban becomes another tool to help teams predictably deliver working software in the face of uncertainty.

But what if I already know everything!?

Mike Cottmeyer — Sun, 12 Jul 2009 16:25:41 -0400

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

Lee Henson — Fri, 10 Jul 2009 10:29:21 -0400

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!