How much project management is needed in an agile project using scrum? In terms of collaboration - what are the main differences in running one scrum team versus 11 scrum teams?
We have been part of a large Norwegian SCRUM project, SPK Perform, for almost two years. This has provided us with fruitful experience with project management in large scale system development projects using scrum.
Practicing what we preach. We shall conduct a daily retrospective of the conference, before we end a day. Assemble the willing participants to share their feedback: what is working well, what needs improvement, etc.
This will provide valuable feedback to conference organizers as well as speakers to make the rest of the conference even more valuable for participants.
We, as Agile coaches, have faced our biggest challenge in May 2009. Energy sector waterfall project of 30 people in Norway, Sweden and Finland organized into regular 6 sub-applications wanted to achieve quite challenging targets. To grow to 70 people by setting up another teams in Czech Republic, to transfer 15 years legacy system knowledge and to be up and running with this all in 6 months.
Session’s topic is about how we fought and won over the challenges by implementing Agile to the project and how we have transferred the service to offshore location according to Agile principles.
In early 2008, leaders within Thomson Reuters decided to use an agile approach to improve their ability to quickly deliver high quality products on large, complex projects, with distributed teams. Before the first few agile projects were complete, many others had started and the excitement for agile adoption quickly spread. Although we’ve had many successes, we have experienced some challenges along the way. This presentation will describe our approach to organizational agile adoption, what we’ve gained from it, and where we are still facing challenges.
Flow-based software development (FSD, aka “lean”, pull-based, or kanban) is software development paradigm that can have a profound effect in certain software development projects, e.g. maintenance projects. This experience reports shows one project team’s experience when moving from a timebox-based development process (scrum) to a flow-based process.
Experimentation is one way to gain insight into how processes perform for a team, but teams rarely do experiments, fearing such educational excursions will incur extra costs and cause schedule overruns. When facing a stalemate concerning pair programming, one team performed a lightweight experiment evaluating pair programming and programming alone with inspection. Through the experiment, the team learned that pair programming was faster than programming alone, required less effort, and had more predictable quality. Lightweight experimentation is easy, cost effective, and fun.
A presentation that compares and contrasts 3 unique experiences across 3 distinct organizations implementing Agile. The presentation will illustrate the constant variables of context, culture and collaboration and how they interrelate when implementing agile. From a large traditional financial company in Dallas: Nurturing a newly formed collaborative team in a competitive environment to a competitive hierarchical advertising company in New York: Navigating land-mines of anti-scrum sentiment; to Google: Giving structure to chaos with the freedom to create options.
This paper is about the process that the Launchpad team went through to improve the usability if a large application, while still having the ability to respond quickly to change and provide adequate support for quick iterations and delivery to users.
Service design and sustainability in agile projects. I want to demonstrate that we need to raise our heads and look beyond the product we are making to see the environment in which it will live and the consequences of producing, operating and dispose of the product.
TDD is promoted as a powerful technique for combining software design, testing, and coding to increase reliability and productivity. However the transition to TDD is not always easy. Is it worth the effort and what can really be gained from it? This report describes a useful transition strategy based on different TDD styles and identifies key elements required for each style. It identifies differences found on code that developed using these TDD styles. The differences are striking in their consistency and give a strong indication that TDD is well worth the effort.