Over the last 17 years of my career I'd like to think that I've learned a lot. I've learned from positive role models, from experience of what works well, by studying my craft, and from my own trials and tribulations. However, I believe the lessons that I have learned that had the biggest impact is learning from failures.
One such failure occurred at a previous employer. By telling the story of a past failure, we can reflect and see what can be learned from it. No names will be mentioned, no embellishment or poetic license will be will used. As a matter of fact, I will make every attempt to be objective and accurate as possible. The truth of the matter the story doesn't need it; it speaks for itself.
Some time ago I worked for a company that, among other things, had a software product. There was a small team of software developers, and someone that acted as the manager of the team. I was brought on board, as a software engineer, to help with the software product as it was not meeting expectations, and deliveries were most often late.
From early on I could see several significant problems with how things were being done. For one, the team was not working as a cohesive unit. There seemed to be a lack of communication and coordination within the team. As a software developer, the product was difficult to work with, as in my opinion, it was poorly engineer. Upper management was not happy with the results, and there were rumors that the team might replaced if results didn't improve. In short there were a lot of areas that I felt needed to be addressed to help turn things around.
In terms of process, we had "daily stand-ups", user stories, and demos after a release. From what I could tell we were doing something that resembled Scrum. However, we didn't have sprints, sprint planning meetings, or retrospectives. The manager had what appeared to be an assistant, that helped with creating the user stories. After the first few weeks of being on the job I learned that the "assistant" was really the scrum master.
Now before I go further, I should mention that before I was hired, I made it clear to the hiring manager that in addition to being a software developer, I wanted to have a part in defining our processes. I'd worked for several organizations in the past that had poorly implemented practices, and it hurt the output of the team. As a certified scrum master, and more importantly a student of agile practices, it pained me to see obvious problems that could be fixed, but not having the ability to do anything about it. Conversely, I'd also had positions were it was part of my job to implement the processes, and it had led to tremendous results. So just to be clear, prior to my hiring I expressed my desire to the hiring manager and he responded by stating that he would be looking for my input.
Back to the story. After having observed the problems with how the projects were being run, and getting more familiar with how things worked, I approached the scrum master. I asked him why we were running things that way, and if he would be open to changes. To best of my recollection he stated that he was open to changes, and he agreed that things could be improved. He was familiar with how Scrum should be run, and the reason that we didn't do most of the Scrum ceremonies and processes is that the manager didn't think it was necessary. I suggested that we follow a more pure Scrum approach, with sprint planning meetings, planner poker, two weeks sprints, and retrospectives. He was very open to the idea, and we bounced a few ideas back and forth about how best to run things.
Sometime around the time I was hired, a new VP of engineering was brought on board. After a few weeks, he took over some of the responsibilities of the "manager", and the manager was put into more of a pure product owner role. The VP was somewhat hands off, but would attend our stand-ups and often attend the demos. Around the time the manager was put into more of a PO role, we started to adopt the more formal structure.
It took a sprint or two for us to fully get into a grove, but we immediately saw improved results. In sprint planning, everyone got a clear idea of the requirements. Ideas were discussed and shared. We had a second part of sprint planning, were we broke stories into tasks, and as a dev team collaboratively delegated out the tasks. We were able to address most of our past issues, and the improved results were apparent to the team members.
Another practice that we adopted were retrospectives. About 4-5 sprints in, we had a great retrospective were a lot of good ideas came up. Unfortunately the PO didn't attend, but we wrote down our thoughts on the whiteboard. One of the ideas was to work directly with the subject matter experts, so that we could better understand how the app would be used.
The meeting was about to conclude, and seemingly at the last minute the PO entered the room. Prior to sitting down, he looked at the the notes on the white board. He responded by asking, in a rather agitated manner, who said some of the things on the whiteboard. I responded that I had the idea of working with the subject matter experts. Frankly speaking, the app wasn't for laypeople, it was for people with specific scientific knowledge.We, as developers, didn't have that knowledge. We had some high level understanding of what we were building, but it was difficult to make judgements calls on what would be helpful to the end users.
He was angry, made a statement something to the effect of "you don't trust me", and continued to press me on my suggestion. I made my case for why I thought it was a good idea, and he continued to look upset. At this point it was obvious that anything I said wasn't going to make him feel any better, so I tried to let it go. However, he continually pressed me and the meeting was extended by an uncomfortable 45 minutes. During the whole time he was visibly upset, and spoke in a loud/angry manner.
Now this type of thing should never happen in a retrospective. It's meant to be a safe place to share ideas. However, I came to learn that my time at that employer would be anything but typical. Over the next few months there were more emotional outbursts to come from him. To make matters worse, eventually there was retribution. I won't get into the details, but things got pretty ugly. Eventually I decided that it wasn't the place that I wanted to be, and decided to move on.
All that we tried to do was to improve our situation. The team more or less had failed in their mission, and it was obvious that things needed to be changed. I saw the opportunity to change things, and took the initiative. I worked directly with the scrum master, and my understanding was that part of what I was there to do was to help improve the processes. We even ran our changes by the VP and he seemed to be onboard. The results were all positive, and yet it somehow came back to bite us.
Out of all of this ugliness, I do think there are some lessons to be learned. To begin with, I made an assumption that there was a desire to improve our processes. While I worked with the scrum master, and thought I had the green light to make changes, the manager/PO never asked for changes to the process. Now in Scrum the scrum master is the one who ensures that we follow scrum, but it doesn't change the fact that former manager never asked for it.
At some point of my time working there, after this incident, I asked the PO if everything was ok. In addition to this incident, there were other signs that the he was not happy. I scheduled a meeting with him, asked him if everything was ok, and with a smile he said yes. Not only that but he was happy with me and that I was doing a good job.
Looking back, I have a hard time believing this is truly how he felt. I can speculate as to why he might say something that was contradictory to how he most likely felt, but the truth is that I most likely will never know. However, I still could have approached the situation different. Instead of asking if everything was ok between us, I could have asked questions more like "How are you feeling about the ways things are going?" and "Do you have any ideas on how we can improve things?" While logically they are similar, the latter approach makes it much more easier for someone to open up about how they are feeling. While it was good that I sought him out when I sensed a problem, by asking more open ended questions we could have better addressed the problem.
As I'm writing this blog posting one other import aspect comes to mind that I simply didn't consider before. Prior to the new VP coming onboard, the manager turned PO was more or less running the show. He was the most senior person in the department. He had his chance to run things and was more or less demoted to a lesser role. I'm can't say how it made him feel, but I know it wouldn't have felt good if it were me. In addition to his demotion, someone new (me), and in a lower position made a bunch of changes and essentially fixed the issues that he was unable to fix. Again, from an emotional standpoint this could have had a significant effect. During the whole process, I never thought about how he felt from an emotional standpoint. Perhaps it made him feel embarrassed, inadequate, and maybe even threatened. I only saw the need for change, what needed to be changed, and assumed everyone would be happy when things got better.
To summarize there's a lot that can be learned form this experience. There were definitely things that I could have done better, even thought I don't necessarily think I did anything wrong. We all do our best, and in the end we learn from our experiences. If I had to do it all over again, I think I would have made him feel more involved in the changes, and solicited his feedback. Having said that I also think that his reaction was totally unprofessional, and was in no way warranted. Frankly I'm happy now that I work with people that I consider to be honest and trustworthy. And if I make a mistake, they will let me know, and still have my back.
Until next time ... onward and upward!
One such failure occurred at a previous employer. By telling the story of a past failure, we can reflect and see what can be learned from it. No names will be mentioned, no embellishment or poetic license will be will used. As a matter of fact, I will make every attempt to be objective and accurate as possible. The truth of the matter the story doesn't need it; it speaks for itself.
Some time ago I worked for a company that, among other things, had a software product. There was a small team of software developers, and someone that acted as the manager of the team. I was brought on board, as a software engineer, to help with the software product as it was not meeting expectations, and deliveries were most often late.
From early on I could see several significant problems with how things were being done. For one, the team was not working as a cohesive unit. There seemed to be a lack of communication and coordination within the team. As a software developer, the product was difficult to work with, as in my opinion, it was poorly engineer. Upper management was not happy with the results, and there were rumors that the team might replaced if results didn't improve. In short there were a lot of areas that I felt needed to be addressed to help turn things around.
In terms of process, we had "daily stand-ups", user stories, and demos after a release. From what I could tell we were doing something that resembled Scrum. However, we didn't have sprints, sprint planning meetings, or retrospectives. The manager had what appeared to be an assistant, that helped with creating the user stories. After the first few weeks of being on the job I learned that the "assistant" was really the scrum master.
Now before I go further, I should mention that before I was hired, I made it clear to the hiring manager that in addition to being a software developer, I wanted to have a part in defining our processes. I'd worked for several organizations in the past that had poorly implemented practices, and it hurt the output of the team. As a certified scrum master, and more importantly a student of agile practices, it pained me to see obvious problems that could be fixed, but not having the ability to do anything about it. Conversely, I'd also had positions were it was part of my job to implement the processes, and it had led to tremendous results. So just to be clear, prior to my hiring I expressed my desire to the hiring manager and he responded by stating that he would be looking for my input.
Back to the story. After having observed the problems with how the projects were being run, and getting more familiar with how things worked, I approached the scrum master. I asked him why we were running things that way, and if he would be open to changes. To best of my recollection he stated that he was open to changes, and he agreed that things could be improved. He was familiar with how Scrum should be run, and the reason that we didn't do most of the Scrum ceremonies and processes is that the manager didn't think it was necessary. I suggested that we follow a more pure Scrum approach, with sprint planning meetings, planner poker, two weeks sprints, and retrospectives. He was very open to the idea, and we bounced a few ideas back and forth about how best to run things.
Sometime around the time I was hired, a new VP of engineering was brought on board. After a few weeks, he took over some of the responsibilities of the "manager", and the manager was put into more of a pure product owner role. The VP was somewhat hands off, but would attend our stand-ups and often attend the demos. Around the time the manager was put into more of a PO role, we started to adopt the more formal structure.
It took a sprint or two for us to fully get into a grove, but we immediately saw improved results. In sprint planning, everyone got a clear idea of the requirements. Ideas were discussed and shared. We had a second part of sprint planning, were we broke stories into tasks, and as a dev team collaboratively delegated out the tasks. We were able to address most of our past issues, and the improved results were apparent to the team members.
Another practice that we adopted were retrospectives. About 4-5 sprints in, we had a great retrospective were a lot of good ideas came up. Unfortunately the PO didn't attend, but we wrote down our thoughts on the whiteboard. One of the ideas was to work directly with the subject matter experts, so that we could better understand how the app would be used.
The meeting was about to conclude, and seemingly at the last minute the PO entered the room. Prior to sitting down, he looked at the the notes on the white board. He responded by asking, in a rather agitated manner, who said some of the things on the whiteboard. I responded that I had the idea of working with the subject matter experts. Frankly speaking, the app wasn't for laypeople, it was for people with specific scientific knowledge.We, as developers, didn't have that knowledge. We had some high level understanding of what we were building, but it was difficult to make judgements calls on what would be helpful to the end users.
He was angry, made a statement something to the effect of "you don't trust me", and continued to press me on my suggestion. I made my case for why I thought it was a good idea, and he continued to look upset. At this point it was obvious that anything I said wasn't going to make him feel any better, so I tried to let it go. However, he continually pressed me and the meeting was extended by an uncomfortable 45 minutes. During the whole time he was visibly upset, and spoke in a loud/angry manner.
Now this type of thing should never happen in a retrospective. It's meant to be a safe place to share ideas. However, I came to learn that my time at that employer would be anything but typical. Over the next few months there were more emotional outbursts to come from him. To make matters worse, eventually there was retribution. I won't get into the details, but things got pretty ugly. Eventually I decided that it wasn't the place that I wanted to be, and decided to move on.
All that we tried to do was to improve our situation. The team more or less had failed in their mission, and it was obvious that things needed to be changed. I saw the opportunity to change things, and took the initiative. I worked directly with the scrum master, and my understanding was that part of what I was there to do was to help improve the processes. We even ran our changes by the VP and he seemed to be onboard. The results were all positive, and yet it somehow came back to bite us.
Out of all of this ugliness, I do think there are some lessons to be learned. To begin with, I made an assumption that there was a desire to improve our processes. While I worked with the scrum master, and thought I had the green light to make changes, the manager/PO never asked for changes to the process. Now in Scrum the scrum master is the one who ensures that we follow scrum, but it doesn't change the fact that former manager never asked for it.
At some point of my time working there, after this incident, I asked the PO if everything was ok. In addition to this incident, there were other signs that the he was not happy. I scheduled a meeting with him, asked him if everything was ok, and with a smile he said yes. Not only that but he was happy with me and that I was doing a good job.
Looking back, I have a hard time believing this is truly how he felt. I can speculate as to why he might say something that was contradictory to how he most likely felt, but the truth is that I most likely will never know. However, I still could have approached the situation different. Instead of asking if everything was ok between us, I could have asked questions more like "How are you feeling about the ways things are going?" and "Do you have any ideas on how we can improve things?" While logically they are similar, the latter approach makes it much more easier for someone to open up about how they are feeling. While it was good that I sought him out when I sensed a problem, by asking more open ended questions we could have better addressed the problem.
As I'm writing this blog posting one other import aspect comes to mind that I simply didn't consider before. Prior to the new VP coming onboard, the manager turned PO was more or less running the show. He was the most senior person in the department. He had his chance to run things and was more or less demoted to a lesser role. I'm can't say how it made him feel, but I know it wouldn't have felt good if it were me. In addition to his demotion, someone new (me), and in a lower position made a bunch of changes and essentially fixed the issues that he was unable to fix. Again, from an emotional standpoint this could have had a significant effect. During the whole process, I never thought about how he felt from an emotional standpoint. Perhaps it made him feel embarrassed, inadequate, and maybe even threatened. I only saw the need for change, what needed to be changed, and assumed everyone would be happy when things got better.
To summarize there's a lot that can be learned form this experience. There were definitely things that I could have done better, even thought I don't necessarily think I did anything wrong. We all do our best, and in the end we learn from our experiences. If I had to do it all over again, I think I would have made him feel more involved in the changes, and solicited his feedback. Having said that I also think that his reaction was totally unprofessional, and was in no way warranted. Frankly I'm happy now that I work with people that I consider to be honest and trustworthy. And if I make a mistake, they will let me know, and still have my back.
Until next time ... onward and upward!
Comments