by
Join the DZone community and get the full member experience.
Join For FreeI mentioned a while ago that Dennis and I were planning to blog our
way through this book we are writing. We'll, over the holidays I really
got serious about writing this thing, and we dropped a pretty detailed
chapter outline, and almost 7000 words into draft. The text isn't
finished from a content perspective, or from an editing perspective,
but I am going to share some initial thoughts with you guys.
There
were no easy answers. None of the books really told me how to do it. We
had to figure it all out as we went using the principles to create
situationally specific practices. Small team agile doesn't resonate
with me so I tend to write from a big team perspective. That said, I
know there are folks out there that don't share my same set of
experiences. So when I sat down with Dennis to hammer out this first
chapter, I thought it was important to set context. To give the reader
an idea of the kinds of problems we were trying to solve.
To
me, context is so important. There are so many brilliant people in this
community, and we all share our ideas from our own particular points of
view. Sometimes though, we don't share the context where we developed
those ideas. For me, I have never just worked with a single team. When
I got involved seriously in leading agile organizations, I was trying
to deal with over a hundred people, 20 plus projects in flight, and had
to deliver against a complex systems architecture.
There
were no easy answers. None of the books really told me how to do it. We
had to figure it all out as we went using the principles to create
situationally specific practices. Small team agile doesn't resonate
with me so I tend to write from a big team perspective. That said, I
know there are folks out there that don't share my same set of
experiences. So when I sat down with Dennis to hammer out this first
chapter, I thought it was important to set context. To give the reader
an idea of the kinds of problems we were trying to solve. God
forbid someone take some of these things I talk about here and apply it
to a three person team. It would be overkill. To be honest, I am not
sure the things I talk about apply if you have 3000 developers either.
I suspect they do, but I have never managed anything that large. So...
the first few sections of the book are there to help us establish
context. Again, this is not polished material, and I am not sure how
much it is going to make it into the book. That said, this is how I see
the world so I thought I'd share it with you guys.
The Problem with Big
When a company is small people, do what ever it takes to get the job done. There is a sense that you are part of a team and everyone is working toward common goals. Smaller organizations have a strong sense of purpose and a people have direct connection between what they do and the performance of entire organization. There is a camaraderie that comes with having your survival tied directly to your ability to deliver. When this small companies work, success seems to come naturally. People love what they do, they want to come to work, and they are engaged.
This kind of success often leads to growth. Growth often leads to more people joining the team. As our team expands, there are naturally limits to our ability to self-organize (citation). We hire managers and project managers to structure the work. We hire specialists to fill specific gaps in our organizational expertise. We often group our specialists into teams of specialists so we can make best use of their valuable skills and experiences. Teams of specialists end up with their own managers, management hierarchies, career paths, compensation plans and performance incentives.
Over time we end up with functional silos; organization where people are grouped by what they do rather than what they deliver. To deliver an increment of enterprise value, many functions of the organization have to come together to deliver an end-to-end solution. No one functional manager owns the ultimate outcome so we assign accountability to a project manager; the idea being that we need someone who can work across the functional silos. Team members don’t usually report to the Project Manager, the PM is only there to coordinate the work and make sure the business knows what’s going on.
This can be a pretty difficult situation for the project manager, they don’t talk about Projects Managers herding cats for no reason. These Project Managers work with the teams of specialists to break down the work, document all the required activities, provide estimates, develop schedules, get organizational sign-off, and attempt to manage to the plan. Knowing who is doing what all the time becomes a pretty high priority for the PMO. The organization cannot afford to have team members doing any unapproved work. All work ends up being project work and needs to be reflected in a plan.
Because there are so many interdependencies between the teams doing the work, we strive for greater certainty about who is working on what project, for how long, and when they are going to be done. The need for increased certainty results in excessive estimating, excessive task break down, excessive assignment of work and very often, micro-managing behavior. People become overloaded and increasingly separated from the project outcomes. The only thing they can do is focus on their part; the project manager is responsible for making sure everything comes together as planned. Team members become a slave to the tasks on the project schedule. They can no longer help create value.
To make matters worse, specialists are not required full time on every project. To compensate, we time-slice people across several projects to keep them continuously busy. People are in so many project meetings during the regular work day, they have to work nights and weekends to get their real jobs done. If someone does find themselves with extra capacity, that is often license enough to go ahead and start another project. It doesn’t usually matter that there aren’t sufficient resources to get the project finished, the goal is to get started. Starting project that we are not staffed to finish creates dilutes our focus and makes it harder to deliver on our most pressing business priorities.
All of this multi-tasking can lead to a profound lack of teamwork, a profound lack of engagement, and people that focused only on the task at hand; totally disconnected from the value they were hired to create. We end up with a politically charged; do what I tell you or else, corporate culture… a culture that focuses on keeping your head down and staying busy over delivering real results. The solutions to this problem often come in the way of more planning, more project management, more micro-managing activities, more documentation… and of course more sign-off.
The Problem with Big
When a company is small people, do what ever it takes to get the job done. There is a sense that you are part of a team and everyone is working toward common goals. Smaller organizations have a strong sense of purpose and a people have direct connection between what they do and the performance of entire organization. There is a camaraderie that comes with having your survival tied directly to your ability to deliver. When this small companies work, success seems to come naturally. People love what they do, they want to come to work, and they are engaged.
This kind of success often leads to growth. Growth often leads to more people joining the team. As our team expands, there are naturally limits to our ability to self-organize (citation). We hire managers and project managers to structure the work. We hire specialists to fill specific gaps in our organizational expertise. We often group our specialists into teams of specialists so we can make best use of their valuable skills and experiences. Teams of specialists end up with their own managers, management hierarchies, career paths, compensation plans and performance incentives.
Over time we end up with functional silos; organization where people are grouped by what they do rather than what they deliver. To deliver an increment of enterprise value, many functions of the organization have to come together to deliver an end-to-end solution. No one functional manager owns the ultimate outcome so we assign accountability to a project manager; the idea being that we need someone who can work across the functional silos. Team members don’t usually report to the Project Manager, the PM is only there to coordinate the work and make sure the business knows what’s going on.
This can be a pretty difficult situation for the project manager, they don’t talk about Projects Managers herding cats for no reason. These Project Managers work with the teams of specialists to break down the work, document all the required activities, provide estimates, develop schedules, get organizational sign-off, and attempt to manage to the plan. Knowing who is doing what all the time becomes a pretty high priority for the PMO. The organization cannot afford to have team members doing any unapproved work. All work ends up being project work and needs to be reflected in a plan.
Because there are so many interdependencies between the teams doing the work, we strive for greater certainty about who is working on what project, for how long, and when they are going to be done. The need for increased certainty results in excessive estimating, excessive task break down, excessive assignment of work and very often, micro-managing behavior. People become overloaded and increasingly separated from the project outcomes. The only thing they can do is focus on their part; the project manager is responsible for making sure everything comes together as planned. Team members become a slave to the tasks on the project schedule. They can no longer help create value.
To make matters worse, specialists are not required full time on every project. To compensate, we time-slice people across several projects to keep them continuously busy. People are in so many project meetings during the regular work day, they have to work nights and weekends to get their real jobs done. If someone does find themselves with extra capacity, that is often license enough to go ahead and start another project. It doesn’t usually matter that there aren’t sufficient resources to get the project finished, the goal is to get started. Starting project that we are not staffed to finish creates dilutes our focus and makes it harder to deliver on our most pressing business priorities.
All of this multi-tasking can lead to a profound lack of teamwork, a profound lack of engagement, and people that focused only on the task at hand; totally disconnected from the value they were hired to create. We end up with a politically charged; do what I tell you or else, corporate culture… a culture that focuses on keeping your head down and staying busy over delivering real results. The solutions to this problem often come in the way of more planning, more project management, more micro-managing activities, more documentation… and of course more sign-off.
Okay...
that is the first few paragraphs. Like I said, I've got about 7000
words prepped so I post some more over the next few days. Let me know
what you think. Does this sound like the places you've worked? It
sounds like every place I have worked. As always your feedback is most
welcome!
This article was first posted at Mike Cottmeyer's blog.
This article was first posted at Mike Cottmeyer's blog.
agile
Opinions expressed by DZone contributors are their own.
Comments