Is it possible to SCRUM the development of a large software system with contributing teams spread out over three cities, five partners, six sites, and a six hour time difference? It started with vague and ambitious objectives and was built on bleeding edge technologies (grails, flex). By all rights we should have fallen flat on our faces. But a year after its dubious beginning, our project continues. Join us as we present the good, the bad and the ugly of distributed team projects.
Tim and Tim discuss tools and techniques and observations for remotely pair-programming. Various remote desktop-sharing applications and services are discussed, dissed, and recommended along with pointers and practices for logistics. Learn the downside of distant partners. How do you have a flash architecture meeting? How do you collaborate with the team? When do you take breaks? Is it really just like being there, without the smells?
What can programmers learn from the thought of Aristotle, Kant, and Mill? More than you might think. Find out what three of the greatest minds in history think about things like craft, art, virtue, and happiness, and how they would run a software project.
We’ll link philosophical ethics and ideas to the processes, tools, and methodologies of software development as we discuss a critical question: is successful development primarily a matter of finding the right rules, creating the right outcomes, or cultivating the right virtues?
As Agile is adopted by large enterprises, the number of transformation success stories has grown. But, transformation is an ongoing process, and maintaining organizational change is difficult. So, what happens after the success stories? What can IT leaders expect once the honeymoon is over? In this talk, Chuck Maples, SVP of R&D at Borland, will address these questions head-on, sharing his experiences in Borland’s Agile transformation. He’ll discuss the challenges that can emerge after the initial phases of transformation give way a new stage in the journey.
It is human nature to avoid loss. We make rational decisions to improve our situation and respond to circumstances. But are we always rational? Whether it be the tendency of people to hold stocks that have lost value or teams that continue a death march, this irrational fear of acknowledging a loss can cause people to keep investing in a poor undertaking. This discussion is a brief exploration of how our desire to avoid loss can cause us to irrationally make our situation worse in the hopes of somehow breaking even as well as some techniques to identify and avoid these situations.
This is a journey starting in 2005 when establishing a new software company in Bangladesh 7000 km away from Denmark. Hiring 20 people in one week in Bangladesh and start using CMMI processes to integrate development in Denmark and Bangladesh. After some challenging time aborting the CMMI project and switching back to agile and lean techniques to make it work. Experience from implementing global big bang Scrum and building a kaizen culture. From long running projects, technical dept and integration nightmares to small batches, continuous integration and faster delivery of business value.
In 2004, SEP tried adopting Agile practices. However, Agile failed to have the desired lasting impact across the entire organization. Things changed in 2007, when SEP implemented Kanban for the first time. We will explore how Kanban teams at SEP matured through the lens of the Dreyfus Model for Skill Acquisition. We will examine what this pattern has meant for institutionalization of Lean in the organization. We will discuss a counterintuitive technique for higher success and adoption rates of new methodologies. Finally, we will review common pitfalls teams encountered adopting Kanban.
We’ve spent the past year writing a book about Agile Coaching and that’s given us a great opportunity to reflect on what we do as agile coaches. In this talk, we’ll present our top ten tips for agile coaches. We’ll present this like those TV shows that do a countdown to the Number One tip and illustrate the tips with some personal coaching stories.
We also want to hear from people in the audience what their coaching tips are.
The study of Group Relations is important to the development of Agile practice. Software development is performed by groups of individuals. When individuals become a members of a group, behavior changes. The group becomes focal & the individuals become background. The group behaves as a system and exhibits system-level behavior. Groups as a system exhibit very primitive emotional behaviors that can derail the group from its stated primary task.
Group relations theory says that a group behaves as a system, and that the primary task of the group is……
Clear definitions of Role, Task and Authority are essential when people assemble to do work.
Unclear definitions of these items leads to all sorts of waste.
Scrum’s very clear Roles and associated Tasks and Authority are a big part of what makes actually Scrum ‘tick’.
A Boundaries ‘collection’ is an attribute of the Role, Task and Authority ‘objects’. This session deconstructs Role, Task & Authority in terms of associated Boundaries. Note that boundaries can come in many forms, including: boundaries of time, boundaries in terms of access to resources, etc.