The General Sessions were divided into five areas of interest or tracks that ran concurrently on Wednesday and Thursday of the Fall Scrum Gathering.
The five Programme tracks were:
- Scrum in the Large
- Human Side of Scrum
- Scrum Skills
- Product Owner Issues
- Scrum Experiences
Track A: Scrum in the Large
Wednesday, 14 November, 10.45-12.15
"The Manager's Role in Scrum"
Presenter: Henrik Kniberg, CSP, Crisp AB, Sweden
Scrum defines only three roles, and none of them is Manager. Yet the middle manager is often the person best positioned to introduce Scrum in the organization. Middle managers need to understand that their role in Scrum is as important as ever, but that some aspects of the role will be fundamentally different. Some managers will love the new role description, some will hate it. It is important that managers don't feel lost and forgotten, as this will create unnecessary resistance and hamper the adoption of Scrum. As Scrum practitioners it is our job to help managers understand that they are as important as ever, but that their role will be different in many aspects. In this session we go through the manager's role in Scrum and identify ways to address the most common questions and objections.
Wednesday, 14 November, 13.30-15.00
"Why Scrum Projects Fail"
Presenters: Joseph Pelrine, CST, MetaProg & Jiri Lundak, CSP, Löwenfels Partner, Switzerland
Scrum projects fail. All the semantic maneuvering around the definition of "failure" still can't hide the fact that some Scrum projects do "crash & burn." Why does this happen, how can we recognize it, and what can we do to prevent this from happening? The more popular Scrum and other Agile methods become, the more we as a community will have to address, and find answers for, these problems. This talk presents a taxonomy of project failure modes and causes, and presents a forum for attendees to share their experiences, be they failure, or success.
Wednesday, 14 November, 15.30-17.00
"Using Scrum to Deliver a Phase of a Waterfall Project: Experiences & Warnings"
Presenters: Matt Roadnight, CSM & Toby Barber, Conchango, United Kingdom
This session looks at Scrum experiences over 2 ½ years for two companies adopting Scrum at different points in a project lifecycle, reviewing the challenges they faced, the actions taken and impacts of those actions. We look at how one company used an offshore team to deliver a site that was referenced by Forrester as a benchmark of how to build and design great financial websites, and discuss how another company scaled Scrum in order to regain business confidence and align local decision making with global strategy.
Thursday, 15 November, 10.45-12.15
“Scaling Scrum”
Presenters: Rachel Davies, CSM, Agile Experience Ltd., United Kingdom & Colin Bird, CSM, Conchango, United Kingdom
Scrum is the simplest possible agile method so it's easy to get started with a small team of software developers. What happens when you try to apply Scrum to large projects? This talk shares experiences of working with large projects with multiple scrum teams and distributed scrum teams. This talk explores how to scale Scrum without losing the essence.
Thursday, 15 November, 13.30-15.00
"The Enterprise & Scrum"
Presenter: Ken Schwaber, CST, Advanced Development Methods, Inc., USA
Agile development methods, such as Scrum, have been shown to produce improvements in speed, quality, and cost. However, the practices within Scrum, such as self-managing teams, are often so different from the norm at most enterprises and cause an organizational reaction. The productivity and quality benefits of Scrum pose a compelling reason to make such changes—moving it from the small team to the enterprise level. And as Scrum crosses to the mainstream, executives need to know how to manage the necessary change processes. In addition, managers and employees alike want to know what the change means to them, personally. With case studies and pragmatic approaches, this presentation shows development managers and developers how to extend Scrum from one or two projects within an engineering organization to the larger enterprise. It also addresses the questions that newcomers have regarding process, interaction, reports, habits, tradeoffs, and more.
Track B: Human Side of Scrum
Wednesday, 14 November, 10.45-12.15
"Why Scrum Intimidates"
Presenter: Alexandre Magno, CSP, aXmagno Consulting, Brazil
Topics explored include:
1. Cultural resistance in Scrum adoption: What are the cultural problems that obstruct the adoption of Scrum in companies all around the world? Using this question we visit many bad habits that exist in companies’ culture worldwide and we understand why Scrum is intimidating for people used to this viciousness routine.
2. Why Scrum intimidates? In this part we make an evaluation of some Scrum practices and cross this information with the main cultural problems and we understand why Scrum intimidates some teams.
3. Traditional techniques to Scrum promotion: With the main bad habits mapped, we analyze many facilitation strategies used today for the community promote Scrum and we see how they attack (if so) those cultural problems.
4. Alternative techniques to promote Scrum: In many projects and companies, always finding cultural problems in different teams, I tried many different alternative techniques to promote Scrum, sometimes successfully, not in others. In this part we understand the importance of, before any Scrum facilitation or promotion, understand the company’s culture... know the teams. We see how we do it.
5. An example: Kingsoftware – The Novel: Novels are part of my country’s culture, Brazil. And through them I could elaborate one of my successful Scrum promotion techniques. The “Kingsoftware” slide novel tells the story of a software development company, in Jamaica, which is starting the development of a new product, but using traditional methods (waterfall). During the novel, we follow the different problems found by the characters in the project’s routine. In this point the team identifies itself with the novel... and see themselves inside it. From this point on all “spectators” have the mission to save Kingsoftware project... adopting Scrum.
6. Initially using slides (.ppt), the Kingsoftware novel received different formats in different companies and projects, including a theatrical version.
7. Achieved results: Here I explore the advantages I had adopting facilitation and promotion practices directed to specific company, city and/or country culture. How did it change the receptivity to my services and to Scrum?
Wednesday, 14 November, 13.30-15.00
"The Ethics of Scrum & Agile Software Development"
Presenter: Ken H. Judy, CSM, CSPO, CSP, Oxygen Media, USA
Are Scrum and XP inherently ethical? In the face of contradictory beliefs over what we do and how we do it, we software developers, agile or not, experience pressure to compromise our work and our due care for others. Meanwhile, as our products become more beneficial, more pervasive and inter-connected our potential to harm grows. Attempts by the ACM and IEEE to engage us in a dialog on norms of conduct has resulted in a controversial code of ethics that borrows heavily from established engineering disciplines – mandating specifications to ensure effective software. We, agile software developers are making an underappreciated contribution to ethical practice in our field. Whether our work is a profession or craft, we need to engage the larger community in a conversation about how our day to day actions affect our employers, our peers, and our society. This presentation attempts to frame professional ethics in the context of agile values and practices.
The discussion over norms of ethical conduct happens outside the earshot of most working developers. The day to day experience of Scrum practitioners is at a distance from those who concern themselves with software ethics. As a Scrum community, we have a responsibility to help shape the expectations placed upon us by others. We cannot delegate our integrity nor defer concerns over negligence, recklessness, or intent to harm the human beings who use the systems we create. We openly discuss our projects, our working conditions, and our advancement but to protect those very interests we often deal with issues of conscience privately. Yet the passion behind Scrum is, in part, an idealistic one – a hope that by dealing openly and responsively with our stakeholders we will build something of real value. We need to harness this idealism to encourage each other make better decisions in the interests of stakeholders who do not pay us and do not always have a seat at the project table. Given the downstream effect large and small ethical lapses have on society we need to engage in this discussion or have the wrong solutions imposed upon us by employers, institutions, and regulatory agencies.
Wednesday, 14 November, 15.30-17.00
“Succeeding with Agile: A Guide to Transitioning”
Presenter: Mike Cohn, CST, Mountain Goat Software, USA
Transitioning to an agile development process is unlike most transitions an organization may make. Many transitions begin when a strong, visionary leader plants a stake in the ground and says, “Let’s take our organization there.” Other transitions start with a lone team thinking, “Who cares what management thinks, let’s do this.” The problem in transitioning to agile is that neither of these approaches alone is likely to lead to the long-term sustainable change required. Transitioning to agile is harder than many other corporate transitions because the transition process must be congruent with development process we are trying to adopt. We cannot, for example, wish to adopt an agile process because we believe in the power of self-organizing teams but then use a transition process that is not itself self-organizing. Nor can we adopt agile because it acknowledges the inherent uncertainty in precisely planning a project but then hope to precisely plan the transition to agile.
Thursday, 15 November, 10.45-12.15
"Pragmatic Solutions to Agile Real-Life Problems"
Presenter: Sabine Canditt, CSP, Siemens AG, Germany
The introduction of agility in big companies like Siemens face typical challenges like:
Complex lifecycles (Portfolio Management, Sales, Marketing, Service…)
Many dependencies (Related projects, disciplines within one project, …)
Many stakeholders
No direct customer access
Big teams, distributed teams
Outsourcing / offshoring
Although it is advisable to start small (optimally with pilot projects that can be handled by small, collocated teams), it is necessary to provide a perspective that there are solutions to these challenges. This presentation outlines some real-life solutions, that have been developed as answers to questions like:
How to set up a (distributed) team structure?
How to prioritize and break down requirements?
How to integrate regarding complex dependencies?
How to ensure quality?
How to synchronize with the non-agile world?
Some of these examples have obvious drawbacks but still are feasible evolutionary steps directing towards an agile enterprise. They don’t provide “one size fits all” solutions but shall encourage teams and organization to think about own ways considering their specific conditions and needs.
Thursday, 15 November, 13.30-15.00
"This Will Never Work in Our Organisation!”
Presenter: François Bachmann, CSP, Itecor, Switzerland
Corporate culture: diagnosing decision making structures. Your company has a history and this will influence how you need to go about introducing change. Finding out what has gone wrong in the past, who was responsible for it, and who is now calling the shots (regardless of your org chart) will greatly enhance your chances of introducing any new process. Change, risk, insecurity, and other threats. Every company faces change, be it internal or external. The company's unique perception of risk and insecurity will inevitably shape its way of dealing with upcoming threats - and Scrum is perceived as such! We look at some common risk handling strategies and communication efforts you can make to align the perception of Scrum with these. Common impediments to Scrum: In impediments to corporate change, it's important to distinguish objections from obstacles and to "put the fish on the table" in a constructive way. This is a review of some common "Scrum smells." Where do I start? A pilot (or seed) project is a good thing, but it needs to be followed up with focused communication to multiply. Some advice is given on how to avoid staying in the Scrum sandbox. Introducing Scrum in any organisation by just sending a group of people to CSM training is a bit naïve at best, irresponsible at worst. Some Scrum "failures" are based in the inability of the new ScrumMasters to get the need for profound change across. Participants take away an enhanced aptitude to diagnose how ready their organisation is for introducing an agile process like Scrum. Concrete examples are provided to enable them to communicate this need to Management in a non-threatening way, in order to bring about the attitude change needed for a successful introduction of Scrum.
Track C: Scrum Skills
Wednesday, 14 November, 10.45-12.15
"Sharing More than Deodorant for Scrum Smells"
Presenter: Rowan Bunning, CSP, Wizard Information Services, Australia
Agile practitioners are constantly being challenged by method implementation issues - things that just don't smell right. Whether it be missing, poorly implemented or inappropriate practices, dysfunctions, misaligned pathologies or lack of expertise, the root cause of these impediments and the best way to go forward is often unclear. Even with a good understanding of the guiding values and principles, the absence of guidance at a more practical level means that the practitioner must often re-invent solutions from first principles. It would be helpful if we could readily draw on the practical experience of others who have successfully overcome similar problems. Unfortunately, this material is hidden in multiple books, papers and online postings and is time consuming and difficult to find and assimilate. Clearer and more accessible guidance could help to make the agile journey less arduous and more successful - particularly for less experienced new adopters. This session embarks on an exploration of agile process smells, causes and possible solutions. To do this, it draws on a varied body of existing smell catalogs and experience reports spanning XP and Scrum, and builds on this with observations from the presenter's own experience and that of the audience. This material is presented with a health warning: use only as appropriate to your unique situation. There appears to be much room for improvement on better sharing our answers to agile implementation challenges. This session investigates what role a catalogue of agile smells and solutions might have in addressing this. It aims to stimulate sharing of common agile smells and possible solutions as a way of collaborative learning about how to assist teams in succeeding with agile at a practical level.
Wednesday, 14 November, 13.30-15.00
"Testing and Scrum"
Presenter: Dr. Ralph van Roosmalen, CSM, Planon, The Netherlands
Scrum is a project management framework; it doesn’t contain any developer or test practices. In most companies Scrum is used in combination with XP, Scrum is used for project management and XP practices are used to guide development. If you’re a traditional tester and you start in a project that is going to use or is using scrum you will have a hard time to find out what you have to do. Scrum doesn’t say anything about testing and XP does say something about testing but it is not a guidebook for a tester. I share our test experiences with the audience as we have used Scrum for two years and I think we have a good test process that is interesting for everyone who is involved in building software. In this presentation I share our experience from Planon about testing and Scrum. I will answer the following questions:
• Do you need specialized testers in Scrum?
• How did we introduce testers in the development teams?
• What is the role of the tester in our team?
• How do you recruit testers for a Scrum team?
• How you do organize the testers over the teams?
• Do you write a (master) test plan?
• What about formal testing techniques in Scrum?
• What kind of test automation harness do we use?
• How do we report about testing?
The audience is given a good overview of the test activities we do at Planon and gets tips on how to improve the testing process in their own projects.
Wednesday, 14 November, 15.30-17.00
"Piloting of Test-driven Development in Combination with Scrum"
Presenter: Christian Schmidkonz, CSM & Jürgen Staader, SAP AG, Germany
After a short introduction into Test Driven Development (TDD) the goals, aspects and results of piloting of TDD (XP methods test first, pair programming, refactoring and continuous integration) in combination with Scrum in an international and distributed project team are presented, based on experiences of the first known combined usage of Scrum and TDD. At first the very interesting effects and impacts in the project team are elucidated as well as new expertise on how TDD and Scrum fit together. On one hand the effects of test first, pair programming in particular to the social environment of the team is highlighted including how the remote collaboration worked, on the other hand the effects of the temporary collaboration of the team with the external trainer is pointed out. Finally, the improvements of the software development in the project are emphasized including clear recommendations.
What changes in a Scrum project by doing TDD in addition and how to do it, as well as how does TDD impact the team and the project and what are the positive results/effects are presented.
Thursday, 15 November, 10.45-12.15
“Agile Estimating”
Presenter: Kenny Rubin, CST, Innolution, USA
Perhaps the most dreaded question asked any developer is "How long will this take?" No wonder we dread this question--it's fundamentally flawed. Rather than directly estimating how long something is likely to take we should really be estimating its size. "How big is this compared to that?" is a much easier question, and one that leads to more reliable plans. In this session we look at why. We explore and gain hands-on practice estimating size. You learn about story points, ideal days, and how to estimate with “Planning Poker.”
Thursday, 15 November, 13.30-15.00
“Agile Planning”
Presenter: Kenny Rubin, CST, Innolution, USA
Planning is important, even for agile projects. Too many teams view planning as something to be avoided and too many organizations view plans as something to hold against their development teams. In this session you learn how to break that cycle by learning and practicing skills that help create useful plans that lead to reliable decision-making. Both short-term iteration and long-term release planning are covered.
Track D: Product Owner Issues
Wednesday, 14 November, 10.45-12.15
“Prioritizing Your Product Backlog”
Presenter: Mike Cohn, CST, Mountain Goat Software, USA
The biggest risk to most projects is building the wrong product. Regardless of how fast your agile team becomes, how brilliant your technical solutions are, or how many automated tests run continuously, nothing matters if you’re building the wrong product. In this session we look at both non-financial and financial ways of both prioritizing product backlog items and choosing among competing project ideas. Included are relative weighting, theme screening, theme scoring, Kano analysis, as well as financial measures such as return on investment (ROI), net present value (NPV), internal rate of return (IRR), and discounted cash flow. The techniques are easy, the concepts are powerful. You return home with practical knowledge about how to apply these straight-forward techniques to prioritizing your product backlog.
Wednesday, 14 November, 13.30-15.00
“Being an Effective Product Owner”
Presenter: Roman Pichler, CST, Pichler Consulting, United Kingdom
The product owner plays a crucial part in Scrum: The product owner leads and guides the Scrum project. The product owner decides which requirements are implemented and when the software is shipped. Having a strong, empowered product owner is a key success factor for Scrum projects – just like a strong, empowered team is. This talk provides insights into being an effective product owner. It introduces the three key responsibilities of the agile product owner: being the voice of the customer, managing the release, collaborating closely with the team and managing stakeholders proactively. We also discuss important product owner practices that help optimising value creation and customer satisfaction.
Wednesday, 14 November, 15.30-17.00
"The Scrum Product Owner Clinic"
Presenters: Roman Pichler, CST, Pichler Consulting Ltd. & Geoff Watts, CST, Inspect & Adapt, UK
Note: This is a complementary session to "Being an Effective Product Owner." Sequential attendance is recommended.
Product owners play a crucial role in Scrum: Product owners are responsible for creating the product vision, writing requirements, reviewing work results at the end of the Sprint, and creating the release plan. This is where theory stops for most projects we have encountered. In reality, product owners are poorly trained in Scrum, are overworked and difficult to get hold of, are sometimes uncomfortable to work closely with a bunch of techies, and are often not properly empowered and supported by their managers. At the same time, we see a strong correlation between effective product owners and successful software and healthy projects, and ineffective product owners and suboptimal results as well as struggling projects. The objective of this clinic is to gain a common understanding of wide-spread reoccurring product owner issues and their causes. We identify ways to overcome the causes and to develop effective product owners that drive healthy Scrum projects. Participants are fully involved and discuss product owner issues on their own projects together with ways to overcome the problems. Attendees benefit from developing concrete measures how to improve the work on their Scrum project by improving how the product owner role is applied.
Thursday, 15 November, 10.45-12.15
"Product Owner at SAP - a New Job Title Developed"
Presenters: Christian Schmidkonz, CSM & Henrik Stotz, CSM, SAP AG, Germany
Agile methodologies in software development already created several success stories if we talk about increased efficiency, flexibility and quality of projects and code. In this presentation the focus is on another success story, the Product Owner as key figure for a holistic and sustainable Product Management. What is the real challenge of a Product Owner based on experiences of more than 70 projects at SAP? How to educate and support the Product Owner to do an excellent job? What knowledge and skills are required for this important role? A fundamental finding out of the very extensive experiences with Scrum at SAP was that the Product Owner role requires clearly more attention and education. SAP started in January 2006 to integrate a Product Owner specific role in its internal ScrumMaster Training. In the meantime from further experiences a clearly advanced training offer for the Product Owner was developed. This session contains an extensive training with focus on tools, methodology, communication and personality development. The tools for end-to-end requirements engineering are imparted as well as practises for adaptive and user oriented definition of new products, e.g. design lead innovation or phase-oriented feature planning. The so-called mentoring program supports him in addition for the development of personnel skills on how to deal more confident with uncertain facts as well as the optimization of his communication skills for stakeholder management.
Thursday, 15 November, 13.30-15.00
"CEO & Team: Collective Product Ownership at Oxygen Media"
Presenter: Ken H. Judy, CSM, CSPO, CSP, Oxygen Media, USA
Scrum describes a separation of roles; the Product Owner is accountable for achieving business objectives and the team for technical execution. The agile manifesto values conversations over contracts. However, not all collaboration is equal. A collegial relationship between a Product Owner and team can skim the surface of agile practice while barely touching the possibilities of a project and its participants. In this presentation, I establish that deep, unbounded collaboration is at the heart of agile values. That partnerships of high trust and shared risk support value return and innovation. I describe how shared ownership over vision, priorities and execution evolved between our Scrum/XP development team and our CEO/Product Owner – an innovator in the cable television industry and new to software development. Finally, I describe how trust building and reliable performance has begun to change in our organization.
There’s a lot written about roles and core practices. Not so much is written about how a product owner leverages the knowledge and passion of all participants towards the vision and features of their product. This experience report is a 1-1/2 year example of just this kind of leadership. Gerry Laybourne is a significant figure in the history of television, largely responsible for the success of Nickelodeon. She has taken a risk in championing a new mission for her company in software based on research into women’s needs and preferences. This report draws on analyses of collaboration and knowledge creation to describe a process in which Gerry worked with a broad cross section of her company to brainstorm a product, learn about software and the role of product owner, and along the way grew to love her development team and the agile principles they espouse. It is also an example of introduction of agile practices bottom up in a company and how, under the right circumstances, our ways of working can influence the larger organization.
Track E: Scrum Experiences
Wednesday, 14 November, 10.45-12.15
“Overhauling a Failing Project by Using Scrum”
Presenter: Matthew D. Edwards, Ajilus, USA
This presentation discusses the history, decisions and results of a failed outsourced/off-shored software project. Scrum makes intuitive sense to many people when trying to apply it to ground up software/systems solution work and delivery. However, trying to figure out how to convert an in-flight project from one approach to another in an organization that has historical predispositions, processes and procedures – and is already failing - is often strikingly difficult. My assertion is that the perceptions of many software stakeholders, leaders and managers inclusive, ordinarily suggest that ‘trying a new process’ should occur on a future, not yet started, relatively innocuous and ‘safe’ project rather than touching on an already complicated in-flight project with risks, necks and money on the line. What attendees gain from this session is insight into how a new person, equipped with Scrum and previous software experience, can walk into a broken team and project, re-organize it using Scrum principles, and be delivering usable, tested software in two weeks with tangible value validated by business end-users/sponsors/project funders. And the secret to this project’s success can be articulated as having three primary elements: a) out of the box Scrum, b) a conversion to user stories, and c) complete transparency frequently, often and all of the time.
Wednesday, 14 November, 13.30-15.00
"Scrum in Video Game Development"
Presenter: Kevin Shrapnell, CSM & Harvey Wheaton, CSM, EA Games, United Kingdom
The quality of audio and visual presentation demanded in many different software projects is rising significantly. As this bar raises, teams will have to deal with some of the issues seen in video games today. Details of the specific problems encountered in rolling out Scrum to a heavily mixed discipline team with a very intangible or subject definition of what “done” is or what is fun. How we have evolved our thinking and approach in dealing with these problems, and an outline of the approaches tried. We don’t have perfect solutions; getting attendee feedback and ideas as part of a discussion and brainstorming about possible solutions for these outstanding issues is part of the presentation.
Wednesday, 14 November, 15.30-17.00
"Integrating Scrum with the Process Framework at Yahoo!"
Presenters: Karl Scotland, CSM & Alexandre Boutin, CSM, Yahoo!, United Kingdom & France
Like many international organisations, Yahoo! has a Process Group, who's role it is to help manage the huge portfolio of projects. This generally involves prescribing a standard process, which can be challenging for Agile methods such as Scrum that emphasise self-organisation. This presentation describes how Yahoo! have approached that challenge, and what solutions they have come up with. The talk describes how the Process Group has implemented its strategy through its own inspect and adapt cycle. This has seen a move from a position of controlling, to one of championing, allowing for local definition, implementation, coaching and evaluation. Along the way, language has evolved from one of waterfall-based stages and gates, to one of more Agile-friendly checkpoints. This topic is of interest to Scrum Gathering attendees because it presents a real experience report of how a well known brand has met the challenges of scaling Scrum at an international level. By attending this session they gain an insight into how they might approach similar challenges they may face themselves.
Thursday, 15 November, 10.45-12.15
"Practical Experience in Scrum"
Presenter: Martin Kearns, CSP, CSC, Renewtek, Australia
I have spent time researching SCRUM and creating a set of principle slides on SCRUM Principles. The slides are professional with an element of humour and instill the Core Principles. My presentation is to use these slides to re-affirm core SCRUM Principles and also to introduce the concept to the less experienced. This presentation reaffirms core principles, of which even the more experienced certified Scrum trainer can gain something from. I also refer to my experiences in using Scrum in Corporate Australia.
Thursday, 15 November, 13.30-15.00
"The Coaching Trap"
Presenter: Andreas Schliep, CSP, SPRiNT iT GmbH, Germany
When you are working as a coach with new ScrumMasters, there are things you should really keep in mind...
- Don't do their work
- Let them learn on their own
- It's not your code
- Don't push
- Don't take it personally
I've been responsible for other ScrumMasters since 2004. As a leader, facilitator, coach. I started to work as an external Scrum coach one year ago. Time for a retrospective, I thought. When I reflected on my work and the work of my fellow coaches, I discovered quite a couple of pits we've fallen into, common misconceptions and typical reactions. And I started to recollect them, trying to find patterns that might be instructional and helpful for other Scrum coaches in similar situations.