Early in our journey from Waterfall development to Agile, we identify 4 pilot projects, each from different product lines, to test the Agile waters via “Pilot Projects”. Even though there were several Agile champions (myself included) in the organization, we decided to take a “let’s try it before we buy it” approach to Agile. Each of the pilot teams consisted of cross-functional team members. Our strategy was to formally train members of the 4 pilot teams as Certified ScrumMasters, Certified Product Owners or Certified Scrum Developers.
As the overseeing Unified Development Process (UDP) Committee, we identified our in-house Agile champions as coaches for each team, but ultimately each team had to self-organize, inspect and adapt, and deliver on their commitments following the Scrum framework.
Once trained, we sent the teams off to build software for a minimum of three two-week long sprints.
When it was all over...
When all Pilot teams completed their the minimum 3 Sprints we conducted a multi-team retrospective. Those of us that were coaching the pilot teams had already observed many of the positives and negatives identified during this retrospective, some of which are recounted in this blog. However, it was very heartening to hear similar sentiments expressed nearly unanimously by all Pilot teams.
What Worked Well?
The teams enthusiastically offered up a long list of “what worked”, but the first two items mentioned are worth noting here. Improved communication was unanimously agreed upon by all teams as the top benefit they experienced during the pilot. [Ironically, this conversation occurred mere hours after I had written my “Hyper-Communication: Scrum’s Secret Sauce” blog! I was mentally smiling as they spoke.] The teams stated that the Scrum framework fostered communication, mentioning that the cross-functional teams, specifically the inclusion of QA engineers, was extremely beneficial. Also singled out was the Product Backlog Grooming - it was a key team communication activity valued by all.
It’s interesting to note that the Waterfall process used in our Product Group does not prohibited nor dissuade people from communicating with others when developing software. I believe it is simply that often there is no immediacy to engage in these types of discussions in a Waterfall environment. The Waterfall process does not foster this type of regular extended team communication. For example, there is often a buffer, perhaps a project leader or supervisor between Product Management and the developers writing the software. Further, with Waterfall, the “are we writing the correct software” check-point is often distant, in terms of time, from the requirements definition, occurring at Beta perhaps, where as Scrum’s are much more frequent, occurring at the end of every Sprint.
The second notable benefit brought up was the feeling of empowerment experienced by the participants in the pilot. This one is interesting and caught me a bit by surprise as it is hard to visually identify. The teams actually appreciated the complete ownership, not only for the delivery of working product, but for user story refinement, quality, documentation, etc. Success (or failure) was almost completely within their, the Team’s, control, and they found this to be extremely valued.
In Waterfall software development, most teams are used to be being led. Often a project leader or project manager is identified as the chief point of contact. That person manages the schedule, works dependencies, reports status for the team, and often runs interference, allowing the team members work on their individual tasks with minimal interruption. Teams are typically not cross-functional and often the onus of communication is often on the individuals themselves.
Scrum’s emphasis on “The Team” was appreciated by all of our pilot teams. The team members valued the empowerment and responsibility - essentially the confidence the organization put in them. As management, of which I am a part, it seems we really did succeed in stepping back and letting the Pilot teams operate without traditional management meddling.
What Didn’t Work Well?
The Pilot teams also brought up a healthy list of things that didn’t work. Being a new process that most had just learned, coupled with introducing Agile in a Waterfall environment, a long list of issues was not unexpected.
The number one issue the teams noted was that most Product Owners did not spend enough time with the team. For our Pilots, we identified Product Managers as Product Owners for each team. Because our Product Managers were few in numbers and had many other responsibilities most ended up being only part-time members of the teams. The teams felt this strongly that the Product Owners needed to participate more as a full-time team member, attending the daily Scrum as well as spending more time creating and refining the Product Backlog and working with the Team on backlog grooming.
This issue was a direct result of mapping a Waterfall role into a Scrum role. In Waterfall, a Product Manager can manage many projects, defining the requirements up front, then moving on to the next project’s requirements. Not so with Scrum, where the Product Owner is a full-time job, a fact that became obvious very quickly for most Pilot teams. It’s clear going forward that our organization needs to re-examine our staffing and role needs, as well as acknowledge that some existing roles won’t readily map into new roles within Agile.
One other notable “didn’t work well” issue was the handling of customer escalations. With a large customer base, an escalation can come in and derail the team’s Sprint commitment. This situation can and does occur during our Waterfall-run projects as well. It’s an issue that likely will need an organizational solution, as it introduces tension between specialized engineers developing new software in time-boxed sprints and the need to support a significant and demanding and customer base.
We thought it was all over, but it wasn’t...
Much to my delight, all four of our Pilot Teams decided on their own to continue with Scrum beyond their initial 3-sprint Pilot. One Team is now on Sprint 7, and has successfully released the output of an earlier Sprint to customers in a Technology Preview program.
Beyond the team enthusiasm and product successes, the biggest outcome of our Pilot effort was that we created new Agile champions. Each Pilot Team has several members who have been positively promoting their Pilot Team experience. As we roll out Agile to more teams, we’ll leveraging these new Agile advocates as mentors and champions to assist with our organization Agile Transformation. To me, that was the biggest “what worked well?” of all.
As the overseeing Unified Development Process (UDP) Committee, we identified our in-house Agile champions as coaches for each team, but ultimately each team had to self-organize, inspect and adapt, and deliver on their commitments following the Scrum framework.
Once trained, we sent the teams off to build software for a minimum of three two-week long sprints.
When it was all over...
When all Pilot teams completed their the minimum 3 Sprints we conducted a multi-team retrospective. Those of us that were coaching the pilot teams had already observed many of the positives and negatives identified during this retrospective, some of which are recounted in this blog. However, it was very heartening to hear similar sentiments expressed nearly unanimously by all Pilot teams.
What Worked Well?
The teams enthusiastically offered up a long list of “what worked”, but the first two items mentioned are worth noting here. Improved communication was unanimously agreed upon by all teams as the top benefit they experienced during the pilot. [Ironically, this conversation occurred mere hours after I had written my “Hyper-Communication: Scrum’s Secret Sauce” blog! I was mentally smiling as they spoke.] The teams stated that the Scrum framework fostered communication, mentioning that the cross-functional teams, specifically the inclusion of QA engineers, was extremely beneficial. Also singled out was the Product Backlog Grooming - it was a key team communication activity valued by all.
It’s interesting to note that the Waterfall process used in our Product Group does not prohibited nor dissuade people from communicating with others when developing software. I believe it is simply that often there is no immediacy to engage in these types of discussions in a Waterfall environment. The Waterfall process does not foster this type of regular extended team communication. For example, there is often a buffer, perhaps a project leader or supervisor between Product Management and the developers writing the software. Further, with Waterfall, the “are we writing the correct software” check-point is often distant, in terms of time, from the requirements definition, occurring at Beta perhaps, where as Scrum’s are much more frequent, occurring at the end of every Sprint.
The second notable benefit brought up was the feeling of empowerment experienced by the participants in the pilot. This one is interesting and caught me a bit by surprise as it is hard to visually identify. The teams actually appreciated the complete ownership, not only for the delivery of working product, but for user story refinement, quality, documentation, etc. Success (or failure) was almost completely within their, the Team’s, control, and they found this to be extremely valued.
In Waterfall software development, most teams are used to be being led. Often a project leader or project manager is identified as the chief point of contact. That person manages the schedule, works dependencies, reports status for the team, and often runs interference, allowing the team members work on their individual tasks with minimal interruption. Teams are typically not cross-functional and often the onus of communication is often on the individuals themselves.
Scrum’s emphasis on “The Team” was appreciated by all of our pilot teams. The team members valued the empowerment and responsibility - essentially the confidence the organization put in them. As management, of which I am a part, it seems we really did succeed in stepping back and letting the Pilot teams operate without traditional management meddling.
What Didn’t Work Well?
The Pilot teams also brought up a healthy list of things that didn’t work. Being a new process that most had just learned, coupled with introducing Agile in a Waterfall environment, a long list of issues was not unexpected.
The number one issue the teams noted was that most Product Owners did not spend enough time with the team. For our Pilots, we identified Product Managers as Product Owners for each team. Because our Product Managers were few in numbers and had many other responsibilities most ended up being only part-time members of the teams. The teams felt this strongly that the Product Owners needed to participate more as a full-time team member, attending the daily Scrum as well as spending more time creating and refining the Product Backlog and working with the Team on backlog grooming.
This issue was a direct result of mapping a Waterfall role into a Scrum role. In Waterfall, a Product Manager can manage many projects, defining the requirements up front, then moving on to the next project’s requirements. Not so with Scrum, where the Product Owner is a full-time job, a fact that became obvious very quickly for most Pilot teams. It’s clear going forward that our organization needs to re-examine our staffing and role needs, as well as acknowledge that some existing roles won’t readily map into new roles within Agile.
One other notable “didn’t work well” issue was the handling of customer escalations. With a large customer base, an escalation can come in and derail the team’s Sprint commitment. This situation can and does occur during our Waterfall-run projects as well. It’s an issue that likely will need an organizational solution, as it introduces tension between specialized engineers developing new software in time-boxed sprints and the need to support a significant and demanding and customer base.
We thought it was all over, but it wasn’t...
Much to my delight, all four of our Pilot Teams decided on their own to continue with Scrum beyond their initial 3-sprint Pilot. One Team is now on Sprint 7, and has successfully released the output of an earlier Sprint to customers in a Technology Preview program.
Beyond the team enthusiasm and product successes, the biggest outcome of our Pilot effort was that we created new Agile champions. Each Pilot Team has several members who have been positively promoting their Pilot Team experience. As we roll out Agile to more teams, we’ll leveraging these new Agile advocates as mentors and champions to assist with our organization Agile Transformation. To me, that was the biggest “what worked well?” of all.
No comments:
Post a Comment