My First Agile Project Part 4: How to lose credibility and jeopardize your project with lack of management buy-in
Originally published on AgileSoftwareDevelopment.com
Welcome to Part 4 of My First Agile Project. If you haven’t read the others in the series, don’t worry. Each part should stand alone. If you want to read the whole story though, the other parts are available: Part 1, Part 2, Part 3.
In Part 3 of this series, I talked about our demos and I mentioned how they unfortunately turned people off the demo with presentations about mostly behind-the-scenes features. My first instinct was just to say that those people lost their right to have input since they weren’t involved in the demo. In reality, the business world just doesn’t work like this, much to my chagrin.
What happened was the people who didn’t care to come to the demos just came later with changes and “suggestions” for new work we had to do. Also, since a lot of the ones who were supposed to be coming were upper management, their lack of knowledge about the Agile processes we were using led to a lot of problems and misunderstandings later in the project. Read on to hear more about how we failed to get our management on board as much as we should have. Hopefully you can avoid that mistake and some of the problems we’ve faced.
Consequences of Boring Demos
Our tendency on the project was to demo everything. We wanted everybody to get credit for their work and the audience to get to comment on everything. We wanted to be transparent so we showed everything, even though we knew it was sometimes boring for the business people in the audience.
At first, I didn’t think this was as big of an issue as it really was since I thought people understood the process and would pay attention because this was their chance to give feedback. Instead, we got comments from people like “I’m not going to waste 2 hours sitting there listening to IT clap for each other.” This wasn’t to our faces but behind our backs when higher-level people were asked to explain why they didn’t bother coming to the demos.
I’m not sure what the answer is to this. It’s valuable to have these kinds of demos so people can show off their hard work and get the team on the same page. And it does give people the chance to give feedback, but in practice, demos for stuff that happens behind the scenes can turn people off the whole process, which we learned can be worse than just not getting some feedback. Once somebody decides they’re not going to come to the demos any more, it’s hard to get them to reconsider when you get to the stuff they should be seeing. What ended up happening was that we would get feedback many sprints after we thought we’d “finished” some piece of functionality as word got back to somebody about what we’d built. We had to do a lot of rework due to this. Even things like finding out later what paper we were going to use for printing invoices came back and caused rework.
Getting Management Involved
Beyond rework, not having management involved is an even more important consequence of turning people off the project. At our company, managers and directors do a lot of the work so we invited a lot of upper level people to our demos. Getting these people on board and understanding the process is more important to an Agile project than I originally thought. Our project was the first exposure that our company had to Scrum and Agile processes so we tried to explain what it all meant so everybody would know. It was clear early on that the Agile ideas weren’t being understood at the higher levels of the company so at our second or third demo I gave a small presentation about the Scrum process and thought that some upper management people would be there to learn about it but they didn’t end up coming. We tried as we went along to get everybody on the same page as well but we mostly used the demo as the communication channel so with people not attending the demos knowledge of the problems didn’t get out there like they should have. In retrospect we were not as forceful as we should have been in getting the information out there. You just can’t expect that business people will be interested in something like Agile without a lot of hand-holding about it.
When we got down the line and were in trouble with problems on multiple fronts our management just saw the project was late and we were responsible. The clash between how a company wants to work with big projects (set deadlines, set budgets, etc.) and how Agile deals with big projects is real and if you don’t work hard to get people to understand the differences, you can’t come in after the deadline has been blown and expect to educate anybody. You need to start early with planning and estimating, make sure everyone involved knows where the project is at all times, only then can they reconcile how the project is going with the budgets and the deadline. See Part 1 of this series for more on the problems we had with not estimating and planning correctly. But you can do all the planning in the world and if the information isn’t getting to management or if they don’t know what it means, it’s just noise and people will ignore it, to your peril.
If we’d been communicating all along, we’d be in a much better place. As it is now, I can see that we as a team have lost a lot of credibility and I believe our ability to continue using agile processes is probably in jeopardy.
Team Responsibility
We can argue that a lot of the problems we’re having are because of bad 3rd party vendors, complications in the product we were integrating, problems converting data, etc. but at the end of the day we’re a team and this is our project so the responsibility is on all of us. Agile isn’t just about getting management off your back or freeing the team from over-documenting. It’s about the team taking responsibility and part of that is not giving up power over your project any more than you can help. Good managers don’t just shrug their shoulders and let things happen to their projects and that includes self-managed teams. We should have insisted that certain people attend our demos and keep up on our project status just like we insist that our fellow team members don’t slack off and endanger the project. That takes some courage, to be sure, but it’s important. When you’re building a product for internal use, the users and management are a part of the development process just like the development team is. This is a change for a lot of people but the team has to insist that everybody participate if the outcome is going to be a good one. We’ve certainly learned this lesson the hard way but sometimes the hard way makes the best teacher so we won’t soon forget.
If you’ve had issues with getting management involved on your project, please share. I think it’s in the nature of most developers to not place the importance on management participation that the issue deserves so if you’ve learned this lesson, or if you think I’m putting too much emphasis on it, I’d like to hear about it. Thanks.
Welcome to Part 4 of My First Agile Project. If you haven’t read the others in the series, don’t worry. Each part should stand alone. If you want to read the whole story though, the other parts are available: Part 1, Part 2, Part 3.
In Part 3 of this series, I talked about our demos and I mentioned how they unfortunately turned people off the demo with presentations about mostly behind-the-scenes features. My first instinct was just to say that those people lost their right to have input since they weren’t involved in the demo. In reality, the business world just doesn’t work like this, much to my chagrin.
What happened was the people who didn’t care to come to the demos just came later with changes and “suggestions” for new work we had to do. Also, since a lot of the ones who were supposed to be coming were upper management, their lack of knowledge about the Agile processes we were using led to a lot of problems and misunderstandings later in the project. Read on to hear more about how we failed to get our management on board as much as we should have. Hopefully you can avoid that mistake and some of the problems we’ve faced.
Consequences of Boring Demos
Our tendency on the project was to demo everything. We wanted everybody to get credit for their work and the audience to get to comment on everything. We wanted to be transparent so we showed everything, even though we knew it was sometimes boring for the business people in the audience.
At first, I didn’t think this was as big of an issue as it really was since I thought people understood the process and would pay attention because this was their chance to give feedback. Instead, we got comments from people like “I’m not going to waste 2 hours sitting there listening to IT clap for each other.” This wasn’t to our faces but behind our backs when higher-level people were asked to explain why they didn’t bother coming to the demos.
I’m not sure what the answer is to this. It’s valuable to have these kinds of demos so people can show off their hard work and get the team on the same page. And it does give people the chance to give feedback, but in practice, demos for stuff that happens behind the scenes can turn people off the whole process, which we learned can be worse than just not getting some feedback. Once somebody decides they’re not going to come to the demos any more, it’s hard to get them to reconsider when you get to the stuff they should be seeing. What ended up happening was that we would get feedback many sprints after we thought we’d “finished” some piece of functionality as word got back to somebody about what we’d built. We had to do a lot of rework due to this. Even things like finding out later what paper we were going to use for printing invoices came back and caused rework.
Getting Management Involved
Beyond rework, not having management involved is an even more important consequence of turning people off the project. At our company, managers and directors do a lot of the work so we invited a lot of upper level people to our demos. Getting these people on board and understanding the process is more important to an Agile project than I originally thought. Our project was the first exposure that our company had to Scrum and Agile processes so we tried to explain what it all meant so everybody would know. It was clear early on that the Agile ideas weren’t being understood at the higher levels of the company so at our second or third demo I gave a small presentation about the Scrum process and thought that some upper management people would be there to learn about it but they didn’t end up coming. We tried as we went along to get everybody on the same page as well but we mostly used the demo as the communication channel so with people not attending the demos knowledge of the problems didn’t get out there like they should have. In retrospect we were not as forceful as we should have been in getting the information out there. You just can’t expect that business people will be interested in something like Agile without a lot of hand-holding about it.
When we got down the line and were in trouble with problems on multiple fronts our management just saw the project was late and we were responsible. The clash between how a company wants to work with big projects (set deadlines, set budgets, etc.) and how Agile deals with big projects is real and if you don’t work hard to get people to understand the differences, you can’t come in after the deadline has been blown and expect to educate anybody. You need to start early with planning and estimating, make sure everyone involved knows where the project is at all times, only then can they reconcile how the project is going with the budgets and the deadline. See Part 1 of this series for more on the problems we had with not estimating and planning correctly. But you can do all the planning in the world and if the information isn’t getting to management or if they don’t know what it means, it’s just noise and people will ignore it, to your peril.
If we’d been communicating all along, we’d be in a much better place. As it is now, I can see that we as a team have lost a lot of credibility and I believe our ability to continue using agile processes is probably in jeopardy.
Team Responsibility
We can argue that a lot of the problems we’re having are because of bad 3rd party vendors, complications in the product we were integrating, problems converting data, etc. but at the end of the day we’re a team and this is our project so the responsibility is on all of us. Agile isn’t just about getting management off your back or freeing the team from over-documenting. It’s about the team taking responsibility and part of that is not giving up power over your project any more than you can help. Good managers don’t just shrug their shoulders and let things happen to their projects and that includes self-managed teams. We should have insisted that certain people attend our demos and keep up on our project status just like we insist that our fellow team members don’t slack off and endanger the project. That takes some courage, to be sure, but it’s important. When you’re building a product for internal use, the users and management are a part of the development process just like the development team is. This is a change for a lot of people but the team has to insist that everybody participate if the outcome is going to be a good one. We’ve certainly learned this lesson the hard way but sometimes the hard way makes the best teacher so we won’t soon forget.
If you’ve had issues with getting management involved on your project, please share. I think it’s in the nature of most developers to not place the importance on management participation that the issue deserves so if you’ve learned this lesson, or if you think I’m putting too much emphasis on it, I’d like to hear about it. Thanks.