If we can’t see our work and understand it, how do we expect others to value it? Testing is often undervalued by project managers and development teams, but quality products rely upon it. Often, this is because testing’s day- to- day actions and its unpredictable work load are invisible to others. Jim Benson will show how visualization of work by testers can greatly improve relations and create a less stressful workload.
Jim discusses Personal Kanban in this part tutorial / part social psych lesson / part QA/QC case study extravaganza. Jim also thinks Powerpoint is boring, uses no slides, and prefers instead to actually talk to people. Jim Benson is the CEO of Modus Cooperandi Inc, a collaborative management consultancy that specializes in creating cultures of continuous improvement for knowledge workers. With 25 years of experience in very large project management (building freeways, light rail systems, software, and international development projects), Jim has come to the realization that projects veer off-track because of lack of information and overly aggressive planning. Since starting Modus Cooperandi back in 2007, Jim has worked with the United Nations, the World Bank, NBC Universal, British Telecom, The Library Corporation and others to get individuals, teams, and the organizations they work with collaborating and exchanging information effectively. To this end, he created the Personal Kanban methodology, and recently co-authored the book Personal Kanban: Mapping Work | Navigating Life with Tonianne DeMaria Barry.
Eliminating variation makes sense in manufacturing, where the goal is to make zillions of compatible widgets based on the same pattern. Yet software development isn’t much like manufacturing; it’s more like design. Which activities of design can be standardized? Which ones can’t? What aspects of software development are based on explicit or explicable knowledge? What knowledge do we need in order to apply a standard successfully? What can we learn from other disciplines like art and music? What parts of architecture are standardized, and what parts are not? How can we have “industry standards” without a clear notion of which industry we’re talking about?
It’s harmful variation we want to eliminate, but systematic observational errors and compulsive standardization can make it simple to throw out the baby with the bathwater. In many places where people claim we need standards, at most we need guidance. In many places where people claim we need scripts, at most we need checklists. When we reduce deviation, we reduce opportunities for exploration, discovery, investigation, and *positive* deviation from overly simplified norms. Michael Bolton has been teaching software testing on five continents for ten years. He is the co-author (with senior author James Bach) of Rapid Software Testing, a course that presents a methodology and mindset for testing software expertly in uncertain conditions and under extreme time pressure. He has been Program Chair for the Toronto Association of System and Software Quality, and Conference Chair (in 2008) for the Association of Software Testing. He wrote a column in Better Software Magazine for four years, and very sporadically produces his own newsletter.
Michael lives in Toronto, Canada, with his wife and two children. He can be reached at mb@developsense.com, or through his Web site, www.developsense.com.
Liftoff – it’s the unexplored, often ignored, Agile software development project practice. Liftoff gives impetus to your projects in a way that starts the project team, and the business, on the trajectory to success. Project sponsors, product managers, and product owners use these critical meetings to inform, inspire, and align the people who do the work with the definition of the work to be done.
As the first act of the flight, a rocket launch requires an entire set of systems to successfully lift the vehicle into orbit – not just the vehicle itself, but all the systems needed for smoothly moving off the ground into space. Likewise, your project needs its entire set of supporting systems in place to begin a successful journey to high performance, hyper-productivity, and high value delivery.
In this talk, Diana Larsen explores ways to accomplish Liftoff, including the vital step of chartering the project. She’ll share real-life stories of how others have effectively started their projects; a variety of team activities to fuel your Liftoff; and a framework for effective, “just enough” Agile chartering. Drawing on 20+ years of experience working with technical professionals, Diana Larsen takes a pragmatic approach to consulting with leaders and teams to promote workplaces where innovation, inspiration, and imagination flourish.
As partner and senior consultant with FutureWorks Consulting, Diana Larsen sparks the creation of workplaces where productive teams display resilience in times of change and focus on frequent delivery of high value software customers want and use. She leads system-wide groups in collaborative thinking and planning for agile adoptions, project kick-offs, chartering, and retrospectives. Diana coaches managers and leaders on their role in a changing workplace and presents workshops on topics related to agile transitions and teams. She also directs the Agile Adoption program of the Agile Alliance and serves on the Agile Alliance Board of Directors. Diana co-authored Agile Retrospectives: Making Good Teams Great!
Requirements engineering is a core discipline to product development, whether an organization is large or small; involved in market-driven products, IT development, or contractual work; or using traditional or agile methods. There is no shortage of books, papers and courses on requirements, but what really works, and where to start?
In this session, we’ll examine some of the core questions that govern how much detail is enough, which areas need it, and when to provide it – regardless of what software life cycle you are using. In addition, we will cover some of the practices that have proven most useful across projects of all types.
So, if you are confused about “agile requirements”, can’t find the right balance of detail level vs. cost and deadlines in your requirements work, or just want to see some broadly useful practices that you can start using immediately, stop by for the discussion. Erik Simmons works in the Corporate Platform Office at Intel Corporation, where he is responsible for creation, implementation, and evolution of requirements engineering practices and supports other corporate platform and product initiatives. Erik’s professional interests include software development, decision making, heuristics, development life cycles, systems engineering, risk, and requirements engineering. He has made invited conference appearances in New Zealand, Australia, England, Belgium, France, Germany, Switzerland, Finland, Canada, and the US. Erik holds a Masters degree in mathematical modeling and a Bachelors degree in applied mathematics from Humboldt State University, and was appointed to the Clinical Faculty of Oregon Health Sciences University in 1991.
