Join the DZone community and get the full member experience.
Join For FreeAdopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.
I 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.
Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.
Like This Article? Read More From DZone
Topics:
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}