The cloud has rapidly gone from “that thing I should know something about” to the “centerpiece of our five-year corporate IT strategy.” However, cloud computing is still in its infancy. The marketing materials ignore or gloss over the many risks present today in the cloud-data loss, security leaks, gaps in availability, migration costs, and more. Ken Johnston and Seth Eliot share new research on the successful migrations of corporate IT and web-based companies to the cloud. They lay out the risks to consider and explore the rewards the cloud has to offer when companies employ sound architecture and design approaches. Discover the foibles of poor architecture and design and how to mitigate these challenges through a novel Test Oriented Architecture (TOA) framework.
Have you ever delivered an application with functionality that was not what the stakeholders really wanted-or needed? Have you ever discovered that you were listening to the wrong people? Has your team ever developed a really beautiful application that no one uses? A truly successful project delivers what is most important to the business, the sponsor, and the key stakeholders. Carol Askew shares ten requirement-related tips she uses at her large healthcare organization. For example, to keep her projects on track, Carol developed specific requirements checkpoints to review throughout the software development lifecycle. She describes what to look for in project initiation documents, requirements elicitation sessions, user stories, scope issues, and project schedules. Take back ideas that you can use right away to help achieve success in your own projects.
It is easy to find a million ways that software development and project managers can let down their teams and their projects. Ken Whitaker has identified seven pragmatic leadership tips and techniques you can use to build and sustain a great team that consistently delivers great software. Specifically, Ken discusses how to keep project management jargon and bureaucracy to a minimum, what your role as a project manager really is, how to take action to lead rather than just manage, how to mitigate losing your best performers to competitors, how to design in quality from project inception, how to realistically set schedule expectations, and some great ways for simplifying your communication to stakeholders. You'll find this presentation to be useful, exciting, and motivating. These habits are powerful-yet so simple you can put them into practice immediately.
Software development projects are just different. They’re often high-risk ventures with extremely complex interrelationships, filled with uncertainties, dependent on scarce knowledge workers, and much more. So, the leadership style and skills needed to be successful are quite different from those needed in simple, stable projects that run through organizations. Kent McDonald introduces his Context Leadership Model, an important managers’ tool that uses the project characteristics of uncertainty and complexity to provide guidance for project leadership and governance. Kent demonstrates how to assess the characteristics of a project, how to choose the project leadership approach based on those characteristics, and how to tailor it for unique situations.
There are many paths to innovation. At one extreme, many large companies create research labs, staff them with world-class Ph.D.s, and set them working for years to solve complex technical problems. At the other end is the proverbial "two entrepreneurs in the garage" working on a shoe-string budget. Between these extremes are all sorts of organizational structures, team sizes, budgets, and time horizons to encourage innovation. Patrick Copeland introduces basic models for innovation-top-down, democratic, and his personal favorite “eXtreme”-and describes how Google's core beliefs, culture, organization, and infrastructure have successfully encouraged and enabled democratic innovation throughout its growth. From the now famous “twenty-percent time” offer to engineers to its culture of trust, Google is famous for its innovation and out-of-box thinking and execution.
How often have you been in a situation where you could see the solution and yet did not have the authority to make a change? You tried persuasion; you tried selling your ideas; you might have even tried friendly manipulation to get your way. And nothing worked. Here’s a new plan. We can learn to develop and use personal power and influence to effect positive changes in our companies. Johanna Rothman describes how we can be specific about the result we want, look for what’s in it for everyone, and consider short- and long-term options to foster change while acting congruently and authentically. Although it’s not easy to do, with preparation and persistence you can transform yourself into a person with personal influence. When you’re influential, you build your power and, by extension, your informal authority in the organization.
The best software development teams find ways for programmers and testers to work closely together. These teams recognize that programmers and testers each bring their own unique strengths and perspectives to the project. However, working in agile teams requires us to unlearn many of the patterns that traditional development taught us. In this interactive session with Nate Oster, learn how to use the agile practice of concurrent testing to overcome common testing dysfunctions by having programmers and testers work together-rather than against each other-to deliver quality results throughout an iteration. Join Nate and practice concurrent testing with games that demonstrate just how powerfully the wrong approaches can act against your best efforts and how agile techniques can help you escape the cycle of poor quality and late delivery.
Kata is a Japanese word describing detailed, choreographed patterns of movements one masters through practice. Unfortunately, in software development we use the term "practice" very loosely. Tom Perry shares the latest research into how performing deliberate practice-actually practicing a new skill to become proficient-works. As a representative example, Tom explores the techniques you can use to practice and hone your agile team leadership skills. Through individual exercises and collaborative games, learn how to refine and improve your leadership skills. Take back an understanding of what the impact of practicing new skills has on the performance of individuals and teams while you gain hands-on experience with different models of practice. As a bonus, you'll have a set of exercises to form your own deliberate practice for improving your leadership ability.
For agile adoptions that fail, you may not be sure of what went wrong or exactly where but you know something is broken somewhere. And with success, you often do not know what went right. Rajeev Singh shares his experiences regarding emotional and behavioral problems on teams trying to embrace agile values and practices. Join with your peers and hear Rajeev's tales of timid managers, ineffective product owners, poor agile coaches, and self-organizing teams that attempt to "run the asylum." He offers case studies of times when agile adoption has put organizations’ strengths and will to the test. Rajeev will help you develop an acute awareness of your organization's pathologies and offer specific paths to resolve these issues. If your agile team or teams are having "people problems" and sometimes seem to be in chaos, this session is for you.
As a tester on an agile team, are you still creating lots of scripted test cases the old way? Are you still caught in the classic waterfall-always behind-while the rest of the team is doing Scrum and looking forward? Then, change course and work with your team to become a test specialist, coordinating testing rather than only doing testing. Henrik Andersson describes his experiences on a Scrum team and their transition to his test specialist role. To orchestrate such a change, they needed new tools and approaches. So, Henrik gives a short introduction to behavior-driven development. For developing automated unit tests, he describes how their team learned to write tests in English-like Gherkin notation. Then, he demonstrates Developers’ Exploratory Testing, in which the entire team tests together and shares joint responsibility for the quality of the software.