Okay, I am pro- Agile and may be a little anti-waterfall. I work on the UI side - JSF, J2EE, AJAX, Web Component and so forth. We started the following the Agile methodology roughly 24 months ago. Where are we now?
When we started the process change and started implementing Agile, it was quite a challenge. Management was very skeptical -even a few developers were. A few managers were quite resistant to change. It was a quite an educating and convincing period for those of us who really bought and believed in the Agile process. It took a lot of commitment and a drive to convince a well -seasoned waterfall organization to try out a change. And luckily I got to be in a position of key observer. I got to see a lot of perspectives, debates, opinions, resistance. I was in the middle of a major process change. I experienced every little success, every frustration, every feeling of accomplishment, every disappointment, every setback, every feeling of increasing confidence in my coworkers. It was(is) wonderful to feel alive at work. It is wonderful to experience such things at work.
And it has been 24 months since it all started. The fire was ignited. There is no stopping now in our organization.
What do developers feel about this? Every day, we stand for 15 min as a team and talk about what we worked on yesterday, and what we are going to work on today. Everyday, I put out our quality charts before the 15 min meeting. A few of my team members come a minute or two before the 15 min meeting to see how much we have progressed. The smile or the frown on seeing the charts drives the day. We plan a course of action on the spot. The results are visible. It is a continuous process improvement. Some may not agree with the term. But it is what it is. It is continuous feedback and adapting and learning. Human mind learns through continuous learning and feedback. AI is also based on such theories. I believe this is what makes Agile lovable. The feedback is continuous and we can learn and adapt immediately. It is what we do best - learn and adapt. There are limitless "learn and adapt"opportunities in this process. No wonder my fellow crew members embraced agile pretty quickly. A majority of them do not like to go back to the waterfall process. (More about this later - see another upcoming blog).
Let us turn our attention to scrum masters and managers. Do they like it? Do they buy it? I am not a Scrum Master, nor a Project Manager. I certainly get the vibes from them that it is a change - a change that has to be adapted. Some of them love it just like the developers too. Others are okay with it - not entirely thrilled though.
The role of scrum masters is different from project managers. Still both the roles require a skill in management and an acute sense of judgement. Project managers estimate and draw up schedules, identify tasks and assign it to individuals. They pull the project team together and resolve any issues. They are on top of the status on each and every task. They are also responsible for the communication/coordination of various pieces of a project. Lastly they have to make sure that the project is on time and on(or under) budget. Scrum Masters oversee a "self-organized" team. Their primary role is to make sure the team functions to their highest capacity. The team is ready to go because the Scrum masters prioritize work, remove impediments, and sometimes even handle distractions. In my org, most project managers are trained to be Scrum masters. They bring a project management perspective to the agile scrum process.This is the norm rather than the exception even outside my org. Is this beneficial? The answer to the question is the classic one. It depends. One role is not better than the other, nor it is the same. Developers are developers whether in agile development process or traditional software development process, whereas there is a role change for a person who oversees or manages the development process.
One main talent whether it is a Project Manager or a Scrum Master is to get a sense of where the project is heading and how the project is currently doing. This is what differentiates between a great one and a good one. A few of them are attuned to the success of the project from the start till the end, constantly adapting. A few of them get attuned just in time, while a few others very late in the game. Is it the responsibility of the Scrum Master to oversee the entire project, identify impediments, roadblocks , dependencies, resources, constraints and line them in order for the team to function effectively? Or is this the role of Senior Managers? Let us go with the classic answer . It depends. I believe it is a shared responsibility, though having no experience in this arena would make my argument ineffective. As a self-organized team would raise impediments if it is not resolvable, so should a scrum master raise concerns appropriately whether it is related to the current sprint or related to the whole project. And yes, a scrum master agrees with me. I may not be off-base after all.
Back to the question - Where are we now? We have started implementing Agile 24 months ago. Is it much better? Is it cheaper/faster? I go into one of the unofficially required, yet not mandatory All-Hands meetings to find out. Three years ago, when I was sitting in one of my senior boss's All hands meetings, I could relate to the frustration experienced about producing quality software. He wanted his organization to produce quality software. None of the numbers that our department produced at that time was promising. Cost of producing bug-free software was not cheap. It was not easy on the developers either; it was a lot of pressure. We tried everything from six sigma to the Agile process over a period of three years. The results from the six sigma process was promising, encouraging and motivating. And agile results...(I would like to keep the suspense going!). We had a few initial numbers released that were related to Agile projects. However, something in the meeting held me by surprise. It was not the agile results that they presented. It was the enthusiasm of the presenters on the agile process, not the results ( which by the way made this blog possible). They wanted to see that the crew loved the agile process, and listen to the crew feedback about this process. They were excited to share the view and feedback of the other crewmembers regarding this. They were actually excited to see that we loved the process. It is not to say that the numbers don't matter. It matters, but it is not the only thing that matters. When crewmembers are given the opportunity to be their best, the numbers actually show.
When I walked out of the meeting, I gained a new perspective on the number one agile manifesto - "Individuals and interactions over processes and tool". It truly is something.
When we started the process change and started implementing Agile, it was quite a challenge. Management was very skeptical -even a few developers were. A few managers were quite resistant to change. It was a quite an educating and convincing period for those of us who really bought and believed in the Agile process. It took a lot of commitment and a drive to convince a well -seasoned waterfall organization to try out a change. And luckily I got to be in a position of key observer. I got to see a lot of perspectives, debates, opinions, resistance. I was in the middle of a major process change. I experienced every little success, every frustration, every feeling of accomplishment, every disappointment, every setback, every feeling of increasing confidence in my coworkers. It was(is) wonderful to feel alive at work. It is wonderful to experience such things at work.
And it has been 24 months since it all started. The fire was ignited. There is no stopping now in our organization.
What do developers feel about this? Every day, we stand for 15 min as a team and talk about what we worked on yesterday, and what we are going to work on today. Everyday, I put out our quality charts before the 15 min meeting. A few of my team members come a minute or two before the 15 min meeting to see how much we have progressed. The smile or the frown on seeing the charts drives the day. We plan a course of action on the spot. The results are visible. It is a continuous process improvement. Some may not agree with the term. But it is what it is. It is continuous feedback and adapting and learning. Human mind learns through continuous learning and feedback. AI is also based on such theories. I believe this is what makes Agile lovable. The feedback is continuous and we can learn and adapt immediately. It is what we do best - learn and adapt. There are limitless "learn and adapt"opportunities in this process. No wonder my fellow crew members embraced agile pretty quickly. A majority of them do not like to go back to the waterfall process. (More about this later - see another upcoming blog).
Let us turn our attention to scrum masters and managers. Do they like it? Do they buy it? I am not a Scrum Master, nor a Project Manager. I certainly get the vibes from them that it is a change - a change that has to be adapted. Some of them love it just like the developers too. Others are okay with it - not entirely thrilled though.
The role of scrum masters is different from project managers. Still both the roles require a skill in management and an acute sense of judgement. Project managers estimate and draw up schedules, identify tasks and assign it to individuals. They pull the project team together and resolve any issues. They are on top of the status on each and every task. They are also responsible for the communication/coordination of various pieces of a project. Lastly they have to make sure that the project is on time and on(or under) budget. Scrum Masters oversee a "self-organized" team. Their primary role is to make sure the team functions to their highest capacity. The team is ready to go because the Scrum masters prioritize work, remove impediments, and sometimes even handle distractions. In my org, most project managers are trained to be Scrum masters. They bring a project management perspective to the agile scrum process.This is the norm rather than the exception even outside my org. Is this beneficial? The answer to the question is the classic one. It depends. One role is not better than the other, nor it is the same. Developers are developers whether in agile development process or traditional software development process, whereas there is a role change for a person who oversees or manages the development process.
One main talent whether it is a Project Manager or a Scrum Master is to get a sense of where the project is heading and how the project is currently doing. This is what differentiates between a great one and a good one. A few of them are attuned to the success of the project from the start till the end, constantly adapting. A few of them get attuned just in time, while a few others very late in the game. Is it the responsibility of the Scrum Master to oversee the entire project, identify impediments, roadblocks , dependencies, resources, constraints and line them in order for the team to function effectively? Or is this the role of Senior Managers? Let us go with the classic answer . It depends. I believe it is a shared responsibility, though having no experience in this arena would make my argument ineffective. As a self-organized team would raise impediments if it is not resolvable, so should a scrum master raise concerns appropriately whether it is related to the current sprint or related to the whole project. And yes, a scrum master agrees with me. I may not be off-base after all.
Back to the question - Where are we now? We have started implementing Agile 24 months ago. Is it much better? Is it cheaper/faster? I go into one of the unofficially required, yet not mandatory All-Hands meetings to find out. Three years ago, when I was sitting in one of my senior boss's All hands meetings, I could relate to the frustration experienced about producing quality software. He wanted his organization to produce quality software. None of the numbers that our department produced at that time was promising. Cost of producing bug-free software was not cheap. It was not easy on the developers either; it was a lot of pressure. We tried everything from six sigma to the Agile process over a period of three years. The results from the six sigma process was promising, encouraging and motivating. And agile results...(I would like to keep the suspense going!). We had a few initial numbers released that were related to Agile projects. However, something in the meeting held me by surprise. It was not the agile results that they presented. It was the enthusiasm of the presenters on the agile process, not the results ( which by the way made this blog possible). They wanted to see that the crew loved the agile process, and listen to the crew feedback about this process. They were excited to share the view and feedback of the other crewmembers regarding this. They were actually excited to see that we loved the process. It is not to say that the numbers don't matter. It matters, but it is not the only thing that matters. When crewmembers are given the opportunity to be their best, the numbers actually show.
When I walked out of the meeting, I gained a new perspective on the number one agile manifesto - "Individuals and interactions over processes and tool". It truly is something.
