What does it mean to let a team self-organize? I am guessing that it varies some from team to team, but I tend to think of concepts like managers trusting the team's opinion on what they need to get things done, empowering them and giving them the freedom to determine their best composition, structure, and timelines.
I have read a lot lately about why that makes sense; how letting the people closest to the work make decisions about it makes sense, and how empowering the teams allows for the best decisions to be made.
So .... why would people say this? Well, again, I am sure you can read all about it from the Ron Jeffries, or Ken Schwaber, or Mary Poppendieck people of the world. Following my precedent, let me be the one to give you a whole bunch of reasons why preventing self-organization *doesn't* work (speaking from experience, of course).
What about team composition? Recently, one member of our team was taken off the team by upper management. That team member had previously been "voted back onto the island" by the team. It bothered me that after our team had chosen for that team member to be included as part of the team, that a member of management would just decide to take them off. What concerned me more was the motivation for doing it (as reported by mgmt): the team has complained that we don't focus enough on the project that has been pounded into our heads as our number 1 priority. This team member focuses mainly on other things, so by removing him from the team, the rest of the team should feel more focused.
The team's response was predictable. They felt like their decision had been undermined by mgmt. The team does not feel empowered to make decisions about what is best for them, and worse, recognizes that the root problem has not been addressed. Removing people from the team does not magically fix the fact that the team is not allowed to focus on the number 1 goal.
A team that is not empowered to make decisions feels disrespected. They feel like they are not trusted and cannot do their best job. These teams do not give their best effort. They stop taking the time to think through everything as thoroughly as they do when they feel passionate, trusted, and empowered. Nobody wins in this situation.
Friday, August 15, 2008
Why not removing impediments does not work
What goes wrong when impediments are not removed? Let me put it simply: the team can not succeed! Our team has gone sprint after sprint after sprint saying the *same* things over and over. Here's an example: we use TFS for source control. The box that houses TFS is DOG SLOW .... for those who use the web interface, you click a link, and then go get a cup of coffee ... Every sprint for 9 months, the team has said "we need a better TFS box".
When we didn't get one, it didn't take a lot of time before people resisted using it. And when some people stopped using it (for tracking things like Product Backlog Items and Sprint Backlog Items!!), *that* behavior became an impediment to other team members. Over a few sprints, we eventually dropped the electronic tracking of user story cards altogether!
Back to index cards we went ... but *sigh*. Rather than work toward solving the original problem (faster TFS box!), we started trying to solve the problems that we had with index cards. We have remote employees, and they couldn't see the cards. Worse, the cards lacked detail, and we never have yet solved the problem of several team members not knowing more than just a few words of information about a card.
Our team has spent sprint after sprint trying to work around problems that we have previously identified but not been able to solve, so much so that we are losing sight of our original problems, and are starting to work around problems that some of us have forgotten about.
When we didn't get one, it didn't take a lot of time before people resisted using it. And when some people stopped using it (for tracking things like Product Backlog Items and Sprint Backlog Items!!), *that* behavior became an impediment to other team members. Over a few sprints, we eventually dropped the electronic tracking of user story cards altogether!
Back to index cards we went ... but *sigh*. Rather than work toward solving the original problem (faster TFS box!), we started trying to solve the problems that we had with index cards. We have remote employees, and they couldn't see the cards. Worse, the cards lacked detail, and we never have yet solved the problem of several team members not knowing more than just a few words of information about a card.
Our team has spent sprint after sprint trying to work around problems that we have previously identified but not been able to solve, so much so that we are losing sight of our original problems, and are starting to work around problems that some of us have forgotten about.
Tuesday, August 12, 2008
Why not having an available Product Owner does not work
This one seems like a no-brainer, right? Summarizing how I interpret many of the basic ideas behind agile development, a reasonably dedicated, always available product owner is key, right? I feel like agile teams are largely about collaboration and integration of team members, rather than the separation of skills in previous methodologies.
For anyone who for, whatever reason, hasn't read the agile manifesto ... here's a link:
http://agilemanifesto.org/
So, *why* is that the case? *Why* did all of those people get together and publish these ideas, much less advocate for them?
Well, there are plenty of resources out there describing, advocating, and downright fighting for the *why*. I will take the opposite approach and describe why *not*. Here are some of the things that I have seen happen when a team does *not* have a clearly defined, available product owner:
My team has struggled for many many months without a product owner. As we first tried incorporating Scrum into our organization, our first planning meetings were grueling, at best. We had poorly defined ideas of what we should work on. We spent hours asking questions and trying to answer them right there in the planning meetings! We definitely wanted a clear idea of what we were going to do as soon as the planning meeting was over. So we talked through logistics of features and we made decisions.
LET ME TELL YOU .... people in the company who have ideas about what they would like developed DO NOT LIKE when a team makes a decision by themselves! The problem was, they were not around for answering questions. They are located at other geographical locations, and generally do not respond to emails or phone calls in a timely manner. What's a team to do?
So ... we went through a BIG requirements push ... we even hired someone to fill this gap: a dedicated, full time, requirements person. It was partly her job to get the details of desired functionality documented, so that when the team went into planning meetings, they would have the answers to the questions they came up with.
Well, it turns out that "product owners" who are not available to answer questions on the fly, ALSO do not have the time to write requirements. Many planning meetings were entered with still incomplete requirements, or "product owners" promising that they would finish them in a day or two. I guess that maybe having all VPs as your product owners isn't really meant to be the point. Planning meetings became very difficult, as the team started pushing back with saying that they could not estimate incomplete requirements.
Why do I keep saying "they"? Because one of the reasons that having a bunch of product owners is a bad idea is that when they conflict with each other, how can a team solve this problem? We had something like 8 product owners, and each one had an interest in getting *their* features into the development team. Sometimes the team chose what they thought they could do, but were quickly told they were WRONG.
About this time, scrum master #1 had started to burn out, and we had hired a Project Manager (yes, the Gantt chart type). Upper Management decided that the roles should shift, and the previous scrum master would now be a product owner proxy (product owner of product owners, if you will), and the project manager would be the new scrum master (another post soon about why the Gantt chart type has difficulty in scrum master roles!). So ... to solve the "too many product owners" problem, we would funnel everything through one!
Hmm. As it turns out, doing that will not work as long as the product owner proxy does not have any authority to prioritize backlog items. Our PO proxy found himself bringing conflicts to the attention of the other POs, and nobody could make a decision. When he would try to make decisions himself, he even got told "You don't have the authority to make that decision!!"
During this time, upper management decided to create the Sprint Governing Board. The SGB was to meet regularly to decide the priority of story cards. OH WHAT A MESS! In what can only be the most ridiculous planning, the SGB met immediately *after* the planning meeting, and at least 2 sprints in a row, they rearranged the story cards within HOURS of the team spending a day in the planning meeting. This did nothing but make the team angry and tip the scales for a few of the developers into sheer bitterness and outrage.
Most recently, a different person has been given PO responsibility. It's another off-site and unavailable person, previously titled a "product manager". An example of how this goes now ... On Thursday, myself and another team member hit a roadblock; well, a point where we could not proceed without an ok from the PO. We sent her an email (she's not in our office) and told her that we needed help, a decision.
Then ............ we waited. And waited. Thursday night, she sent an email and detailed a whole mess of documentation that we would need to write in order for her to make a decision, and that once that documentation was written, she would be willing to have a conversation about it. To make that frustration even better, a VP followed that up by saying that we *should not* write such documentation, that we should all meet. Then, we waited again. In Monday's stand-up, I said that I was impeded by the fact that I had conflicting instructions from people above my pay grade, and that I needed a decision. After the stand-up, our scrum master scheduled a meeting for Wednesday morning at 10:30.
Do you see the direction this is going ..... ? Even better, do you see the root of the problem? I think I do ... but rather than speculate, I will let you draw your own conclusion. For now, I think I have covered plenty 'o reasons why the lack of a product owner is NOT GOOD.
For anyone who for, whatever reason, hasn't read the agile manifesto ... here's a link:
http://agilemanifesto.org/
So, *why* is that the case? *Why* did all of those people get together and publish these ideas, much less advocate for them?
Well, there are plenty of resources out there describing, advocating, and downright fighting for the *why*. I will take the opposite approach and describe why *not*. Here are some of the things that I have seen happen when a team does *not* have a clearly defined, available product owner:
My team has struggled for many many months without a product owner. As we first tried incorporating Scrum into our organization, our first planning meetings were grueling, at best. We had poorly defined ideas of what we should work on. We spent hours asking questions and trying to answer them right there in the planning meetings! We definitely wanted a clear idea of what we were going to do as soon as the planning meeting was over. So we talked through logistics of features and we made decisions.
LET ME TELL YOU .... people in the company who have ideas about what they would like developed DO NOT LIKE when a team makes a decision by themselves! The problem was, they were not around for answering questions. They are located at other geographical locations, and generally do not respond to emails or phone calls in a timely manner. What's a team to do?
So ... we went through a BIG requirements push ... we even hired someone to fill this gap: a dedicated, full time, requirements person. It was partly her job to get the details of desired functionality documented, so that when the team went into planning meetings, they would have the answers to the questions they came up with.
Well, it turns out that "product owners" who are not available to answer questions on the fly, ALSO do not have the time to write requirements. Many planning meetings were entered with still incomplete requirements, or "product owners" promising that they would finish them in a day or two. I guess that maybe having all VPs as your product owners isn't really meant to be the point. Planning meetings became very difficult, as the team started pushing back with saying that they could not estimate incomplete requirements.
Why do I keep saying "they"? Because one of the reasons that having a bunch of product owners is a bad idea is that when they conflict with each other, how can a team solve this problem? We had something like 8 product owners, and each one had an interest in getting *their* features into the development team. Sometimes the team chose what they thought they could do, but were quickly told they were WRONG.
About this time, scrum master #1 had started to burn out, and we had hired a Project Manager (yes, the Gantt chart type). Upper Management decided that the roles should shift, and the previous scrum master would now be a product owner proxy (product owner of product owners, if you will), and the project manager would be the new scrum master (another post soon about why the Gantt chart type has difficulty in scrum master roles!). So ... to solve the "too many product owners" problem, we would funnel everything through one!
Hmm. As it turns out, doing that will not work as long as the product owner proxy does not have any authority to prioritize backlog items. Our PO proxy found himself bringing conflicts to the attention of the other POs, and nobody could make a decision. When he would try to make decisions himself, he even got told "You don't have the authority to make that decision!!"
During this time, upper management decided to create the Sprint Governing Board. The SGB was to meet regularly to decide the priority of story cards. OH WHAT A MESS! In what can only be the most ridiculous planning, the SGB met immediately *after* the planning meeting, and at least 2 sprints in a row, they rearranged the story cards within HOURS of the team spending a day in the planning meeting. This did nothing but make the team angry and tip the scales for a few of the developers into sheer bitterness and outrage.
Most recently, a different person has been given PO responsibility. It's another off-site and unavailable person, previously titled a "product manager". An example of how this goes now ... On Thursday, myself and another team member hit a roadblock; well, a point where we could not proceed without an ok from the PO. We sent her an email (she's not in our office) and told her that we needed help, a decision.
Then ............ we waited. And waited. Thursday night, she sent an email and detailed a whole mess of documentation that we would need to write in order for her to make a decision, and that once that documentation was written, she would be willing to have a conversation about it. To make that frustration even better, a VP followed that up by saying that we *should not* write such documentation, that we should all meet. Then, we waited again. In Monday's stand-up, I said that I was impeded by the fact that I had conflicting instructions from people above my pay grade, and that I needed a decision. After the stand-up, our scrum master scheduled a meeting for Wednesday morning at 10:30.
Do you see the direction this is going ..... ? Even better, do you see the root of the problem? I think I do ... but rather than speculate, I will let you draw your own conclusion. For now, I think I have covered plenty 'o reasons why the lack of a product owner is NOT GOOD.
10,000 ways to not invent a light bulb ...
Having grown up in Central Jersey, Thomas Edison's house was the standard field trip fare. I have been thinking a lot lately about that quote from him .... the one about 10,000 ways to *not* invent a light bulb, but only needing one way to get it right.
Hopefully, with each of the 10,000 failures, Thomas (and most of us, with any luck!) learned why the attempt did not work. So, let me see if I can explain the things that I have seen not work, and then more specifically, explain *why* it did not work.
Immediately after our team's stand-up yesterday, we were being told about changes that were coming, set down to us from our "Release Plan Steering Committee" (formerly the Sprint Governing Board). We were told that we were going to try a technique wrt our user story cards that we had not tried before. Some people wondered why we don't handle these things the way(s) that we have all read about, involving user story cards, and breaking the highest priority ones down into tasks in the planning meeting to determine what we thought we could reasonably get done in a sprint.
What I found was the veteran team members started explaining all of the reasons that doing things that way had not worked for us. I started thinking of our original scrum master, and how passionate he had been ... and of Ken Schwaber saying that the average burnout is 18 months. Well, we are on scrum master number 2, and he is trying the same things that this team has already tried, repeatedly ..... So, let me start with the obvious.
Why not having a single, prioritized, and clearly defined product backlog does not work
Here is how this process has (not) worked for us.
When we started trying agile, we had "stuff" that we needed to build. We didn't have user stories, but we did have cards. We tried to go through this process of going into the planning meeting with cards, breaking them down into tasks to complete them and estimating how much we could do. But here was the problem: The team didn't understand enough about the desired functionality to break it down into tasks. As a result, we would spend the better part of a whole day trying to answer the questions we had.
Simple to solve, you say? Just have the Product Owner there, and he/she can answer those questions, and hopefully after a time of two of LOTS of questions, he/she will learn to start thinking through those kind of questions *before* the planning meeting!
Ah, there it was .... that word: "just". Our team has banned that word, among others.
Problem 1 with that statement: To this day, there is not a clear "product owner". There are several, and they conflict with each other, and ALL of their stuff is the Toppermost Toppermost priority. So I will have to write a "Why not having a product owner doesn't work".
At some point, our upper management decided that a *whole day* in planning meetings was too much. So we started having a shorter planning meeting - 1/2 a day. Well, since the lack of defined backlog items problem had not gone away, this just made things worse. We went into even *less* detail in planning, and we were WAY off of our estimates.
Next, they brought in a consultant, a scrum "expert", if you will. He suggested that we stop breaking things down into tasks and that we start writing better user stories. He suggested that we try to break each user story down into some detail on the back of the card, asking the questions of the product owner(s) before the planning meeting. He suggested that in the planning meeting, we just estimate the whole user story.
Okay ..... well, we have been dong that. And, we have struggled with estimating a user story card in story points, and then assigning a number of days to that story card. As one of our team members has said repeatedly, "when you estimate in hours, you are off by hours. when you estimate in days, you are off by days" (I don't know how much I agree with that, but ... it's not a bad concept).
So, the dictate that the team got yesterday from the Steering Committee says that we will no longer put days estimates on story cards. We will only worry about user story points and try to pick off the top points in the planning meeting.
Can you guess how well this will work? I can .. and I think the way to fix the problem, is to fix the problem. We need a single backlog, and it needs to be well-defined and prioritized.
Hopefully, with each of the 10,000 failures, Thomas (and most of us, with any luck!) learned why the attempt did not work. So, let me see if I can explain the things that I have seen not work, and then more specifically, explain *why* it did not work.
Immediately after our team's stand-up yesterday, we were being told about changes that were coming, set down to us from our "Release Plan Steering Committee" (formerly the Sprint Governing Board). We were told that we were going to try a technique wrt our user story cards that we had not tried before. Some people wondered why we don't handle these things the way(s) that we have all read about, involving user story cards, and breaking the highest priority ones down into tasks in the planning meeting to determine what we thought we could reasonably get done in a sprint.
What I found was the veteran team members started explaining all of the reasons that doing things that way had not worked for us. I started thinking of our original scrum master, and how passionate he had been ... and of Ken Schwaber saying that the average burnout is 18 months. Well, we are on scrum master number 2, and he is trying the same things that this team has already tried, repeatedly ..... So, let me start with the obvious.
Why not having a single, prioritized, and clearly defined product backlog does not work
Here is how this process has (not) worked for us.
When we started trying agile, we had "stuff" that we needed to build. We didn't have user stories, but we did have cards. We tried to go through this process of going into the planning meeting with cards, breaking them down into tasks to complete them and estimating how much we could do. But here was the problem: The team didn't understand enough about the desired functionality to break it down into tasks. As a result, we would spend the better part of a whole day trying to answer the questions we had.
Simple to solve, you say? Just have the Product Owner there, and he/she can answer those questions, and hopefully after a time of two of LOTS of questions, he/she will learn to start thinking through those kind of questions *before* the planning meeting!
Ah, there it was .... that word: "just". Our team has banned that word, among others.
Problem 1 with that statement: To this day, there is not a clear "product owner". There are several, and they conflict with each other, and ALL of their stuff is the Toppermost Toppermost priority. So I will have to write a "Why not having a product owner doesn't work".
At some point, our upper management decided that a *whole day* in planning meetings was too much. So we started having a shorter planning meeting - 1/2 a day. Well, since the lack of defined backlog items problem had not gone away, this just made things worse. We went into even *less* detail in planning, and we were WAY off of our estimates.
Next, they brought in a consultant, a scrum "expert", if you will. He suggested that we stop breaking things down into tasks and that we start writing better user stories. He suggested that we try to break each user story down into some detail on the back of the card, asking the questions of the product owner(s) before the planning meeting. He suggested that in the planning meeting, we just estimate the whole user story.
Okay ..... well, we have been dong that. And, we have struggled with estimating a user story card in story points, and then assigning a number of days to that story card. As one of our team members has said repeatedly, "when you estimate in hours, you are off by hours. when you estimate in days, you are off by days" (I don't know how much I agree with that, but ... it's not a bad concept).
So, the dictate that the team got yesterday from the Steering Committee says that we will no longer put days estimates on story cards. We will only worry about user story points and try to pick off the top
Can you guess how well this will work? I can .. and I think the way to fix the problem, is to fix the problem. We need a single backlog, and it needs to be well-defined and prioritized.
Saturday, August 2, 2008
Deprecated ScrumMaster
I should be writing this blog ... but I am not. It's got some good stuff about how scrum and agile can be twisted until they are no longer recognizable. I know that feeling oh-so-well .....
A little off-topic .... GTD?
I was looking just now at all of the tabs that open as my "home pages". One of them, that I'd like to talk about and perhaps get comments on, is Toodledo.
A few months ago, I got all into the whole GTD thing again. I started trying to find GTD software that would help me keep the things I needed to do organized. I read about everything from text files to settings in Outlook to full-fledged standalone software.
Eventually, I chose Toodledo (www.toodledo.com). It's free and web-based. Here are the reasons I liked this particular method:
A few months ago, I got all into the whole GTD thing again. I started trying to find GTD software that would help me keep the things I needed to do organized. I read about everything from text files to settings in Outlook to full-fledged standalone software.
Eventually, I chose Toodledo (www.toodledo.com). It's free and web-based. Here are the reasons I liked this particular method:
- First and foremost, it was about portability. It's web-based, and usually I don't like web-based things for interface reasons, but in this case, the portability outweighed clunkiness. Biggest reason I liked it: It has a mobile site, and I know that I *always* have my Blackberry with me. This way, if I wanted to add things as I thought of them, I could hit the mobile page in the BB Browser and enter my item.
- Portability, part 2: I have a Mac at home and a PC for work. The Mac is not allowed to go to work. Therefore, any standalone software package that had to stay on one computer would only be available for me to enter items or clear items while I was at home.
- Features I liked, off the top of my head: short-term goals, long-term goals, contexts, folders, tags .... I could organize things any way I want and customize my view to show me my items in the ways that were applicable to the organization method I chose.
- Other features: collaboration, due dates, hierarchies ..........
Wishing I was going to Agile 2008 ....
I am most definitely wishing I was going to Agile 2008. I have seen on the Yahoo groups and on the web page that there will be many people there that I would love to listen to and learn from. I saw that someone is posting constant updates from there and I will certainly be following that.
http://friendfeed.com/rooms/agile-2008
I'll be watching the Twitterers as well. To the people I know who are going, I'll be there in spirit!
http://friendfeed.com/rooms/agile-2008
I'll be watching the Twitterers as well. To the people I know who are going, I'll be there in spirit!
Subscribe to:
Posts (Atom)