DONE vs. Complete...

From time to time this topic comes up. Today it was raised in my RSS feed by Boggin of the EscApologist blog. He posits "When is a task Done"? He's on the right track, but I was worried his list was too prescriptive. I see DONE criteria as a specific area of coaching and focus for all agile teams, and I think it is more important for people to understand the reasoning behind DONE than have a solution handed to them. This will allow them to find the right answer for themselves. So, here is the nugget I left for him:

Simply put, “DONE” is the full list of stuff the team needs to complete to put the story (set of tasks or full work effort) behind them. If there is work still remaining then it isn’t done because this work will either become technical/business debt, or will delay the next work while it is being completed. This is why done can’t be measured by deployed.

This is also why teams I work with are allowed to use the word “complete” somewhat freely, but they use the word “DONE” with respect and reservation.

For every team, this list is unique… and every team should manage/evolve it as they mature. It is a critical part of agile success.

Oh yeah… and it should be filtered through the lens of business value (not tech complete), but this isn’t an issue if your team is cross-functional.

Anything you would add?

Post agile, one third of you will be gone...

About 6 years ago, I was at a company going agile... I didn't know much about it yet. I didn't realize how it was going to affect me and my career path. I had no idea that it would invigorate me and show me a better way. But there was one thing I heard immediately that I did understand, and it excited me.

The head of the division stood in front of 3,000 employees and stated

"... and after we are done going agile, I won't be surprised if one third of you will be gone."

You could have heard a pin drop. I rarely hear deafening silence, but I heard it that day.

He went on to explain...

"...some of you are managers. You are not the type of managers we will need. Some of you are employees, you won't be comfortable working this way. The pressure will go up, but the motivation and reward will also."

And finally...

"This is okay. It is where we are going. We are committed to it. I accept that this will happen and am respecting you enough to say it right now. Many of you worked hard to help us get to here, but that doesn't mean it will continue to be a good home for you."

(disclaimer: for those who were there with me that day, I know these weren't the exact words... but they were the message!)

9 months later I remembered that statement and I glanced around. I realized I was working with different people. I was on an awesome team. The team I was on before was really good, but they were all like me... the same role. Now I was on a team with really smart hard-working people that weren't like me. We were all different roles and we all have to think and work together to be successful. It WAS harder, but it was ALSO more fun.

And yes, we lost a lot of people. The people that just wanted to tell other people what to do were gone. They either left or were removed. The people who liked sitting in cubes and being told what to do left also.

This is why my first agile experience was so revolutionary. I doubt many of you had such a hard immersion through the transition, but it was wonderful!

The question is, who was left on the sidelines through all of that? Mike Cottmeyer wrote a good piece on this yesterday. How do those remaining managers adapt?

Does a SM have to be technical?

Kyle Smith asked the following question in the Agile Coaching LinkedIn group:

Often job postings prioritize extertise in a specific technology over attributes defined by Agile. Can a CSM succeed w/o being a subject matter expert for a particular technology or industry?

Keith Sterling responded with:

I don't think you need to be a subject matter expert, but I personally believe you have to have some level of understanding of the technology involved, otherwise you will find facilitation extremely difficult.
As a scrum master people will be looking for you for guideance, when you are planning and cutting tasks its important that you atleast know what the team is talking about and why tasks and plans are being proposed in a specific way.

Scott Duncan made several good points including this one:

Sometimes, skill-specific requirements are there because the org's culture will not "respect" someone in a more "mgt" or consultative position without low-level tech'l skills regardless of the fact that the role will not require them to actually use those skills.

My points were the following:

It depends on the team. Without getting into a debate of which is academically better (though I have an opinion), I see two types of agile teams...

1- a team of developers
2- a blended team of roles including dev, analyst, test, usability, etc

In option 1, it is important. You need to speak the language of the team since the team is speaking tech and you need to be the translator to the business.

In option 2, it is not. The team is a holistic group, let the tech folks speak towards business goals and value. Everyone should be focused on what is being delivered in business terms. The non-tech folks need to understand tech and vice versa. In this scenario, the CSM needs to be in between the knowledge of the tech and non-tech groups.

I haven't coded in 7+ years, but I leverage my computer science background to bridge the gap. I'm more effective due to my tech background, but I hardly ever have expertise in the specific language/tools. I have had success without being an SME of the particular technology.

It should be interesting to see if anyone takes the counter point of view.

Agile and offshoring... why it doesn't completely suck.

There have been a few posts recently in various forums about mixing agile with offshoring. At first I had a repulsive taste in my mouth. You see, I've never been in an environment where offshoring has decreased the cost of development while maintaining a similar level of quality or time (or reduced the time with the same cost). I'm not saying that it is not possible, I'm just saying that the companies I've worked in that tried it have not been good enough to make it work in their favor. In my last group, we practically had an A/B test team that proved this for me.

My personal history was then combined with my positive experiences with agile and co-located teams. I saw the huge productivity gains when everyone on the team was moved into a single room together. I saw similar gains with the product owner was moved nearby and the usability and testing roles were given hotel desks in the room to spend part of the day (they were matrixed, so they spent 2-4 hrs a day in the room). To me this was proof that closer was better. Time zone issues, communication issues, latency of conversation, team chemistry.... all of these things improve with co-location. Accountability is much higher because you can see the peer that made whatever statement.

Thus, my view was always... why would I want to work on a team that isn't co-located? I hold high expectations of myself and my work. Why would I want to immediately suppress my potential by being in that situation?

But this week, I had a new thought. Some companies offshore. Clearly the model has to work for them to continue to follow this model (or they are complete idiots). Does agile improve this model?

Yes! It would! Agile is greatly about quicker feedback loops. What better way to uncover communication gaps, quality and time issues, or any other set of problems than by shortening the window of time before you uncover them?

So... I'm suddenly in a new camp. Agile and offshoring is not a bad idea, it doesn't completely suck. Actually, if you feel that offshoring is your necessary way of gaining an advantage, then agile might be one of the only ways to manage it well. Instead of looking at offshoring as a way to ruin agile, I'm looking at agile as a way to improve offshoring.

That being said... I still want to work in a way where I can be face to face with my peers at least weekly.

Disclaimer: In no way do I want to reflect any discrimination or judgement about people in offshoring centers. Many of the people I've worked with in India, Romania, or Germany are equally capable as people I've worked with in the states. I believe the disadvantage of offshoring has nothing to do with the individuals and all to do with the structure/model in which it is set up and managed. The point is that it takes extra cost to manage, and this is a cost that doesn't exist in a co-located setting.

Sprint backlog meets fundraising...

Sometimes I see agile in everyday interactions (see prior post about the Kindergarten Kanban board).

My son goes to a daycare in a church. The other day I was walking out with him and I saw the following (click for larger image):





















We've all seen the "thermometer" fundrasier boards where the local non-profit raises the red bar in the thermometer in the scale to entice people to raise the amount needed. What this church realized is that people will feel more invested if they actually know what the money will be spent on.

Enter the prioritized backlog on the fundraiser board. It is very clear that the group in charge is saying that the first dollars will fix the problems, the next chunks of money will think about the future, and the extra money can be spent on some nice to haves (and the remainder will be saved). It's not about raising X dollars, it is about raising the money for the individual projects.

People will feel invested to get involved. Every week they can look at the board and say "Look, we should help pitch in for that." The customers are getting immediate feedback. An expectation and accountability is being set for seeing these projects happen, because it is what people paid for!

Imagine if you could determine where your tax dollars were spent. What impact would that have on paying taxes and government funded projects?

Prioritizing your backlog and exposing it to your team and customer can be a good thing. I hope you appreciated this example as much as I did!

Early Kills are an Improvement...

It's been a few days since I read it (so I apologize for the missing reference), but it came up in my mind again today. There was a recent discussion about the definition of 'success' in relation to Forrester's or Gartner's research published about projects. It seems that software projects became more successful as agile adoption hit the mainstream market; but project success metrics have decreased in the last few years with widespread enterprise agile adoption. One side of the debate says it is because Agile doesn't work in complex environments (that's ignorance since I learned about agile in one of the largest most complex global 500 companies). The other side of the debate is focusing on the definition of 'success'.

For example, if you were going to work on your project for 3 years in your old model and then it failed... wouldn't it be an improvement if you realized this way in advance? That's a lot of cost savings. It gets those people on something that they can be excited about sooner. It's less "stuff" to throw in the trash. It's less wasted time.

My point is that I agree with the side of the debate that says Agile can help you be successful by shortening feedback loops and creating transparency ESPECIALLY WHEN it leads to the project failing sooner!

Now, I want to take this a step further. Mike Cottmeyer wrote a great post yesterday about Real Option Theory and how to think about risk management. He reviewed an example where he chose to put a deposit on something to extend the window of time where he could gather more information to make the right decision between 3 options. His points surrounded risk management and how every choice (or non-choice) we make affects the economics of the project.

I took this a step further in my comment:

I think there is another piece to this. Some people make the mistake of looking at the deposit as part of your future decision. For example, option 2 and 3 are even choices, but because we paid the deposit... we should not waste it and choose #2 over #3.

The deposit was a payment to extend time (as you described). Some people forget this and see it as a partial payment of the total cost and can't let go of it.

This is how companies keep projects going that should be killed because "they already spent 12 million dollars on it". My response is, "and you want to waste another million?". Instead they see it as "so close to completed, they can't throw it away."

I was once told that the main rule of an MBA education is you decide what to do moving forward based on costs/profit moving forward, not money already spent.

I encourage you to read Mike's post (he's a much better writer than I) and if anyone knows the reference I mentioned above, place it in a comment and I'll add it to this post for future readers!

The Crying Developer...

I've talked about the support team before, but David Bland wrote a very disturbing post about a new hire that ended up crying under his desk due to his abuse on support assignments. The post is short and leaves out some of the details to create a complete picture, but the essence is clear. He summarizes with:

What lessons can we learn from this tragedy?

- Good developers want to create code, not continuously patch it.
- Do not leave a team member isolated on a project with no end in sight.
- Training new team members should be mandatory.
- Single points of failure do not save you money in the long run.

As part of the LinkedIn discussion, I added the following:

A developer shouldn’t be forced to do full-time support indefinitely, especially not on code he didn’t write.

I agree that developer’s need to create AND support, but it is much better when they have to support the things they created themselves. It forces them to reflect on their work and the process around them. In the right environment, this can lead to great improvements as they communicate what this forces them to learn.

When one person indefinitely builds and another supports, it becomes to easy for one person to be motivated and another to become depressed.

A kindergartener's Kanban board...

Literally, a Kanban board in a kindergarten room. David Anderson pulls through once again with yet another insight into Lean and Kanban.

I've been shifting my "work study" towards Kanban and Lean more and more recently. I'm really starting to like it more than Scrum. This example is amazing since it points out the simplicity of managing resources, availability, needs, etc. It does ignore the flow/process/sequence aspect of managing "real" work, but it is really interesting.