Success in adopting an agile culture depends on the organization’s ability to adapt, while at the same time establishing common objectives and principles across the organization. This experience report observes this theme via the lens of a project team at Liquidnet, specifically through the user experience group.
{"title":"Adopting an Agile Culture","authors":"Lily Cho","doi":"10.1109/AGILE.2009.47","DOIUrl":"https://doi.org/10.1109/AGILE.2009.47","url":null,"abstract":"Success in adopting an agile culture depends on the organization’s ability to adapt, while at the same time establishing common objectives and principles across the organization. This experience report observes this theme via the lens of a project team at Liquidnet, specifically through the user experience group.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"54 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128814408","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In a large agile organization (more than three teams or 30 team members) with self-organized empowered teams, R&D leadership roles are still needed to support teams through topics including resource management and strategic vision. This experience report will highlight these R&D leadership roles, describe flat, hierarchical, and matrix R&D organization structures, and then illustrate the influence of these organizational structures on key leaderships behaviors for an agile environment. These behaviors include leading versus managing, flexing existing team boundaries, driving both team and project success, and balancing team versus individual needs. The report concludes that while some organizations structures are more supportive in an agile environment, the organization structure is less important than identifying leaders who demonstrate those key leadership behaviors.
{"title":"Influence of Large-Scale Organization Structures on Leadership Behaviors","authors":"Erik L. Moore","doi":"10.1109/AGILE.2009.14","DOIUrl":"https://doi.org/10.1109/AGILE.2009.14","url":null,"abstract":"In a large agile organization (more than three teams or 30 team members) with self-organized empowered teams, R&D leadership roles are still needed to support teams through topics including resource management and strategic vision. This experience report will highlight these R&D leadership roles, describe flat, hierarchical, and matrix R&D organization structures, and then illustrate the influence of these organizational structures on key leaderships behaviors for an agile environment. These behaviors include leading versus managing, flexing existing team boundaries, driving both team and project success, and balancing team versus individual needs. The report concludes that while some organizations structures are more supportive in an agile environment, the organization structure is less important than identifying leaders who demonstrate those key leadership behaviors.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"28 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"126695981","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
This paper is an experience report describing Abbott’s adoption of agile software development practices in its molecular diagnostics division. We will compare two medical device projects; one before agile and one after. Both of these projects required submission to the FDA (the U.S. Food and Drug Administration). We will describe the adoption of agile practices from realization of the need to the selection of a mentor to implementation and fine-tuning and finally to results and lessons learned. This experience has convinced us that an agile approach is the approach best suited to development of FDA-regulated medical devices.
{"title":"Adopting Agile in an FDA Regulated Environment","authors":"R. Rasmussen, T. Hughes, J. Jenks, J. Skach","doi":"10.1109/AGILE.2009.50","DOIUrl":"https://doi.org/10.1109/AGILE.2009.50","url":null,"abstract":"This paper is an experience report describing Abbott’s adoption of agile software development practices in its molecular diagnostics division. We will compare two medical device projects; one before agile and one after. Both of these projects required submission to the FDA (the U.S. Food and Drug Administration). We will describe the adoption of agile practices from realization of the need to the selection of a mentor to implementation and fine-tuning and finally to results and lessons learned. This experience has convinced us that an agile approach is the approach best suited to development of FDA-regulated medical devices.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"12 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116773200","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In 2008, our organization successfully implemented an agile software development approach (Scrum) across the Application Development department after piloting Scrum in 2007 with a few projects. In just four months, our department consisting of over 200 contractors and 70 full time employees transitioned from a traditional waterfall-style approach (RUP) to Scrum. Less then 2 months later, we were running 40 development projects that were time boxed to three months. In the previous year, we had 20 active projects with duration of 9 to 18 months. After a year of introducing Agile, members of our organization were well aware of what Scrum was, but growing weary of training. There was a clear need to create excitement around the adoption and scaling of Scrum within the application development group. This led us to develop what we called ‘The Amazing Team Race.’ This experience report is about how an agile transition team used a team-based approach for creating excitement while scaling Scrum in a globally distributed organization.
2008年，我们公司在应用开发部门成功实施了敏捷软件开发方法(Scrum)， 2007年，我们在几个项目上试用了Scrum。在短短四个月的时间里，我们的部门由200多名承包商和70多名全职员工组成，从传统的瀑布式方法(RUP)过渡到Scrum。不到2个月后，我们运行了40个开发项目，时间被限制在3个月内。在前一年，我们有20个活跃的项目，持续时间为9到18个月。在引入敏捷一年之后，我们组织的成员都很清楚Scrum是什么，但却越来越厌倦培训。很明显，我们需要在应用程序开发团队中创造对Scrum采用和扩展的兴奋感。这促使我们开发了所谓的“The Amazing Team Race”。这份经验报告是关于敏捷过渡团队如何在全球分布式组织中使用基于团队的方法来创造兴奋。
{"title":"The Amazing Team Race A Team Based Agile Adoption","authors":"Gabino M. Roche, Belkis Vasquez-McCall","doi":"10.1109/AGILE.2009.67","DOIUrl":"https://doi.org/10.1109/AGILE.2009.67","url":null,"abstract":"In 2008, our organization successfully implemented an agile software development approach (Scrum) across the Application Development department after piloting Scrum in 2007 with a few projects. In just four months, our department consisting of over 200 contractors and 70 full time employees transitioned from a traditional waterfall-style approach (RUP) to Scrum. Less then 2 months later, we were running 40 development projects that were time boxed to three months. In the previous year, we had 20 active projects with duration of 9 to 18 months. After a year of introducing Agile, members of our organization were well aware of what Scrum was, but growing weary of training. There was a clear need to create excitement around the adoption and scaling of Scrum within the application development group. This led us to develop what we called ‘The Amazing Team Race.’ This experience report is about how an agile transition team used a team-based approach for creating excitement while scaling Scrum in a globally distributed organization.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"16 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123681647","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
When charting new territory – enterprise-scale Agile – traditional roadmaps only take you so far. When landscapes change in weeks, product management must find a way to reconcile sprint plans and backlogs from multiple teams with longer-term product direction. In this paper, I will share how my teams tackled the roadmap challenge during Borland’s Agile transformation. I’ll cover how roadmaps became a barrier to scaling Agile, how we adopted Agile road mapping, the challenges we faced and the impact the new practices have had on our Agile transformation.
{"title":"Roadmap Transformation: From Obstacle to Catalyst","authors":"David Wilby","doi":"10.1109/AGILE.2009.71","DOIUrl":"https://doi.org/10.1109/AGILE.2009.71","url":null,"abstract":"When charting new territory – enterprise-scale Agile – traditional roadmaps only take you so far. When landscapes change in weeks, product management must find a way to reconcile sprint plans and backlogs from multiple teams with longer-term product direction. In this paper, I will share how my teams tackled the roadmap challenge during Borland’s Agile transformation. I’ll cover how roadmaps became a barrier to scaling Agile, how we adopted Agile road mapping, the challenges we faced and the impact the new practices have had on our Agile transformation.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"61 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"129352151","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In this paper we describe our Project Team’s journey from a process where design and planning work was performed away from development team to one where small cross-functional Feature Teams self-organized to complete design, planning, and construction within the same sprint. We introduced a process that allows User Interaction Designers and Business Analysts to work in sync with the Developers and QA Analysts within a sprint. Each member of the Feature Team is involved in getting READY, planning, executing and being DONE. By introducing this process, we observed an increase in team morale, better, more predictable results and accumulation of less debt, while at the same time maintaining a constant velocity. Our process is a deviation from the established approach where upfront work needs to be ready before starting a sprint.
{"title":"Feature Teams Collaboratively Building Products from READY to DONE","authors":"André Frank, Charles Hartel","doi":"10.1109/AGILE.2009.51","DOIUrl":"https://doi.org/10.1109/AGILE.2009.51","url":null,"abstract":"In this paper we describe our Project Team’s journey from a process where design and planning work was performed away from development team to one where small cross-functional Feature Teams self-organized to complete design, planning, and construction within the same sprint. We introduced a process that allows User Interaction Designers and Business Analysts to work in sync with the Developers and QA Analysts within a sprint. Each member of the Feature Team is involved in getting READY, planning, executing and being DONE. By introducing this process, we observed an increase in team morale, better, more predictable results and accumulation of less debt, while at the same time maintaining a constant velocity. Our process is a deviation from the established approach where upfront work needs to be ready before starting a sprint.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"4 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"121039445","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
A properly implemented Scrum framework enforces a few simple constraints that cause a team to self-organize into a state that achieves 5 to 10 times waterfall performance. Yet the majority of Scrum teams never achieve this design goal. Teams do not know how to sequence work to deliver working software at the end of a sprint. They do not know how to work with a Product Owner to get the backlog in a ready state before bringing it into a sprint and do not know how to self-organize into a hyper-productive state during a sprint. A pattern is emerging at MySpace in California and Jayway in Sweden, for bootstrapping high performing Scrum teams. Rigorous implementation of Scrum by an experienced coach creates a total immersion experience akin to Shock Therapy. Teams are trained on exactly how to implement Scrum with no deviations for several sprints. These teams consistently achieve better than 240% improvement in velocity within a few weeks. They are then able to self-organize on their own to continue to improve performance. For many developers and managers, the experience is a wake up call to agile awareness. Unfortunately, management tends to disrupt hyper-productive teams by disabling key constraints in the Scrum framework. Team velocity then falls back into mediocrity. Velocity data is provided on five hyper-productive teams at MySpace and one team at Jayway. In all but one case, management “killed the golden goose.”
{"title":"Shock Therapy: A Bootstrap for Hyper-Productive Scrum","authors":"J. Sutherland, Scott Downey, Bjorn Granvik","doi":"10.1109/AGILE.2009.28","DOIUrl":"https://doi.org/10.1109/AGILE.2009.28","url":null,"abstract":"A properly implemented Scrum framework enforces a few simple constraints that cause a team to self-organize into a state that achieves 5 to 10 times waterfall performance. Yet the majority of Scrum teams never achieve this design goal. Teams do not know how to sequence work to deliver working software at the end of a sprint. They do not know how to work with a Product Owner to get the backlog in a ready state before bringing it into a sprint and do not know how to self-organize into a hyper-productive state during a sprint. A pattern is emerging at MySpace in California and Jayway in Sweden, for bootstrapping high performing Scrum teams. Rigorous implementation of Scrum by an experienced coach creates a total immersion experience akin to Shock Therapy. Teams are trained on exactly how to implement Scrum with no deviations for several sprints. These teams consistently achieve better than 240% improvement in velocity within a few weeks. They are then able to self-organize on their own to continue to improve performance. For many developers and managers, the experience is a wake up call to agile awareness. Unfortunately, management tends to disrupt hyper-productive teams by disabling key constraints in the Scrum framework. Team velocity then falls back into mediocrity. Velocity data is provided on five hyper-productive teams at MySpace and one team at Jayway. In all but one case, management “killed the golden goose.”","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"24 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116900029","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Imagine yourself with a team that flies in from AU, the UK, and the US in bi-weekly shifts to work with a communications firm. Mix in inexperience, bad behaviours, vague program direction, and a mandated intro to Agile in a silo-ed non-agile environment. Couple this with a capability driven team whose focus is to assist other teams to drive out SOA: and you have a recipe for a Team in Flux.
{"title":"Iterating a Team in Flux","authors":"Sharlene McKinnon","doi":"10.1109/AGILE.2009.39","DOIUrl":"https://doi.org/10.1109/AGILE.2009.39","url":null,"abstract":"Imagine yourself with a team that flies in from AU, the UK, and the US in bi-weekly shifts to work with a communications firm. Mix in inexperience, bad behaviours, vague program direction, and a mandated intro to Agile in a silo-ed non-agile environment. Couple this with a capability driven team whose focus is to assist other teams to drive out SOA: and you have a recipe for a Team in Flux.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"33 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"134031756","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
In replacement projects one of the biggest questions is what strategy to use in replacing the old system. The simplest strategy is to wait until the new system is “at least as good as the old one” before switching. Although this strategy sounds compelling it has many serious drawbacks. An alternative strategy is based on what I call a “Minimal Deployable Entity”. Switch systems when you have just enough to be able to survive with the new system. The concept is similar to “Minimal Marketable Feature” but more focused on deployment strategy. This paper uses two projects as concrete examples of patterns and principles that can be used to define a strategy for a Minimal deployable entity.
{"title":"Strategies for Replacing Systems in Agile Projects","authors":"Niklas Bjornerstedt","doi":"10.1109/AGILE.2009.15","DOIUrl":"https://doi.org/10.1109/AGILE.2009.15","url":null,"abstract":"In replacement projects one of the biggest questions is what strategy to use in replacing the old system. The simplest strategy is to wait until the new system is “at least as good as the old one” before switching. Although this strategy sounds compelling it has many serious drawbacks. An alternative strategy is based on what I call a “Minimal Deployable Entity”. Switch systems when you have just enough to be able to survive with the new system. The concept is similar to “Minimal Marketable Feature” but more focused on deployment strategy. This paper uses two projects as concrete examples of patterns and principles that can be used to define a strategy for a Minimal deployable entity.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"44 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122703974","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
Menlo Innovations adopted agile software development practices in order to build highly effective software development teams that could produce software for Menlo’s clients. As client needs changed during projects, it was often appropriate to change the size of the team working on the project. In order to accommodate the effective integration of new staff, and to remain productive when staffing was reduced, knowledge transfer skills became critical. Menlo found that many of the agile engineering practices, when performed well, form the basis for effective knowledge transfer. What Menlo did not expect was that the flexibility provided by being able to move resources from project to project would ultimately allow the ability to offer creative human resource policies. These policies have resulted in Menlo winning many awards, including the Alfred P Sloan Award for Workforce Flexibility.
{"title":"How Being Agile Changed Our Human Resources Policies","authors":"Clement James Goebel","doi":"10.1109/AGILE.2009.49","DOIUrl":"https://doi.org/10.1109/AGILE.2009.49","url":null,"abstract":"Menlo Innovations adopted agile software development practices in order to build highly effective software development teams that could produce software for Menlo’s clients. As client needs changed during projects, it was often appropriate to change the size of the team working on the project. In order to accommodate the effective integration of new staff, and to remain productive when staffing was reduced, knowledge transfer skills became critical. Menlo found that many of the agile engineering practices, when performed well, form the basis for effective knowledge transfer. What Menlo did not expect was that the flexibility provided by being able to move resources from project to project would ultimately allow the ability to offer creative human resource policies. These policies have resulted in Menlo winning many awards, including the Alfred P Sloan Award for Workforce Flexibility.","PeriodicalId":280848,"journal":{"name":"2009 Agile Conference","volume":"36 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"2009-08-24","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123949853","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
京公网安备 11010802042870号
京ICP备2023020795号-1
扫码关注我们
求助内容：
应助结果提醒方式：