|
|
|
|
|
|
|
|
|
|
|
Johanna Rothman, Rothman Consulting Group |
 |
|
If you’ve been trying to change your organization so that
your projects are more agile, you may have encountered several problems—one
is that it’s difficult to have product management, senior management, and
functional managers work together to lead in a way that makes sense for your agile
project. You’re also probably working with other parts of a large program
that isn’t agile; you have a geographically distributed team; your management
wants to know at the beginning when the project will end; or you might have a project
team that does not share a common vision of what “done” means. Johanna
Rothman explores common organization, management, team, and individual team member
issues. She offers suggestions for making the changes more acceptable and helping
people work with you in a way that enables your projects to succeed.
Learn more about Johanna Rothman |
 |
|
|
|
|
|
Mitch Lacey, Mitch Lacey & Associates, Inc. |
 |
|
"Are you done yet?" The answer to this question may
sink your career, your team, and your project. If you respond with a "yes,"
you may be forced to take on additional work you can’t handle. If you say
"no," you may be branded as someone who can't get things done. Mitch Lacey
notes that this innocent question is asked countless times on almost every software
project. Establishing an upfront, common understanding of "done" can save
teams and businesses countless hours of rework, process-thrash, unclear communication,
and hidden work. Mitch describes what a “done list” is, how it adds
value, and the value it communicates to stakeholders. Mitch takes you through an
exercise on how to establish a common understanding of done and provides an exercise
that you can use with your project teams.
Learn more about Mitch Lacey |
 |
|
|
|
|
|
Gerard Meszaros, Solution Frameworks, Inc. |
 |
|
Many agile methodologies start with a product owner walking
into a room with a pile of money and a stack of prioritized story cards and then
telling the development team to start building a system. These same methodologies
often eschew any form of “big upfront” activities and leave us in such
a rush to deliver business value that we don’t have time to do architecture,
user/task research, etc. While a pile of story cards may be the first thing the
development team sees, this is rarely the first set of activities in a project.
In reality, the customer usually comes with a problem and some vague idea of how
to solve it with technology. Someone must help the customer crystallize his vision,
design the product, get the necessary funding, and populate the initial product
backlog. Gerard Meszaros provides an overview of what needs to go on “behind
the scenes” from project conception to the start of development in earnest.
Learn more about Gerard Meszaros |
 |
|
|
|
|
|
David Hussman, DevJam |
 |
|
When you hear people talk about test-first or test-driven, you
probably think of testing the code. Test-driven practices help developers reduce
defects and increase the value in the code and the designs they deliver. Sadly,
“test-driven” is too often confined to the coding trenches, and project
communities miss the value of test-driven as a way to produce more value and less
waste in other areas. David Hussman challenges you to think about test-driven beyond
the coding realm. In addition to test-driven development, it is possible to test
drive projects, meetings, and more. David begins by describing test-driven development
and why it is often devalued or even dropped. Then he explains about using project
chartering and story test-driven development as concrete tools for infusing test-driven
everything across your project community. As a result, you will find defects, remove
duplication, and discover dependencies sooner.
Learn more about David Hussman |
 |
|
|
|
|
Niel Nickolaisen, Headwaters, Inc. |
 |
|
What are the factors critical to the success of a CIO? How can
a CIO consistently deliver business value? Do development teams, in general, and
agile teams, in particular, understand how to contribute to this success? In this
interactive presentation, Niel Nickolaisen presents the metrics and drivers that
influence CIO behavior and longevity. These metrics and drivers also influence the
organization’s decision to embrace agile methods. Niel shares his experiences
and the survey responses from his CIO peers on how development teams and CIOs can
work hand-in-hand to make agile the preferred development method. Niel introduces
and describes immediately-implementable, proven tools that dramatically improve
IT and business value while reducing project risks.
Learn more about Niel Nickolaisen |
 |
|
|
|
|
|
|
Many processes used to implement an enterprise architecture
are in conflict with the agile development approach. An effective enterprise architecture
framework represents the organization as it is today and as it is envisioned in
the future. However, a key agile concept is that we design and build for today—and
worry about the future only when it arrives. Steven Driver has found that a small
change to the Scrum process flow allows easy integration of an enterprise architecture
into the agile development of new systems. The translation of enterprise architecture
into application architecture requires critical touch points within the Scrum process
to emphasize service-based development required within the sprints. By combining
an enterprise architecture approach using SOA (service-oriented architecture) and
the Scrum development methodology, an organization can achieve effective system
development—in both the short and long term.
Learn more about Steven Driver |
 |
|
|
|
|
|
Bob Hartman, Agile For All |
 |
|
A prevailing myth in the software industry is that business
analysis requires a bloated requirements elicitation and documentation process.
Although the Business Analysis Body of Knowledge (BABOK) is considered to be process
agnostic, many business analysts create heavy requirements when they follow this
document’s guidelines. Bob Hartman busts this myth by explaining how to use
generally accepted practices from the BABOK in an agile way. Drawing directly from
the BABOK, Bob bridges the gap that many business analysts have regarding lightweight
process, especially as it relates to larger projects and organizations. Gain the
ability to use BABOK practices in an agile environment and develop an understanding
of how to use them in more agile ways in traditional software development. Learn
to eliminate waste in any bloated process and become comfortable regardless of the
development methodology you use.
Learn more about Bob Hartman |
 |
|
|
|
|
|
|
Agile methods put a great deal of emphasis on trust, empowerment,
and collaboration. Agile moves us away from command and control project management
toward an approach designed to harness the passion, creativity, and enthusiasm of
the team. A successful transition to agile project management hinges largely on
how well traditional project managers are able to adopt new ways of thinking about
project structure and control. Building on the principles of PMI® and the Project
Management Body of Knowledge (PMBOK), Mike will explore how a PMP can adapt their
knowledge and experience to become an effective agile project leader. Mike will
tackle the hidden assumptions behind the PMBOK and explore a more agile approach
to managing time, cost, and scope. He will take an in-depth look at the PMI Processes
and Knowledge areas and explore how to adapt them to agile projects. Project managers,
business analysts, and other stakeholders will leave with a new way of thinking
about project management best practices and new tools for delivering value in the
face of uncertainty.
Learn more about Mike Cottmeyer |
|
|
|
|
|
Rachel Weston, Rally Software Development
Chris Spagnuolo, Rally Software Development |
|
|
Many software development organizations work within the bounds
of contractual agreements where the limitations imposed by the “Iron Triangle”
of fixed timelines, budgets, and scope challenge their ability to embrace change
and focus on value delivery. Agile practitioners often comment that agile contracting
is a difficult problem, but proven solutions are rarely presented. Rachel Weston
and Chris Spagnuolo offer some tools they have used in their own agile contracting
work to help agile practitioners deal with different contracting scenarios while
promoting agile practices, protecting the development organization, and still providing
value and protection to the client’s organization. Through a combined workshop
and facilitated collaborative session, Rachel and Chris present new agile contracting
tools that can be added to your toolbox. You will gain a deeper understanding of
the problems associated with agile contracting as well as practical solutions for
dealing with contracts in an agile manner.
Learn more about Rachel Weston
Learn more about Chris Spagnuolo |
  |
|
|
|
|
|
Mary Poppendieck, Poppendieck, LLC |
|
|
The Empire State Building—the tallest building in the
world for over forty years—took just 13½ months to build. Amazing as
this may seem today, it was not remarkable at the time; most skyscrapers were built
in about a year. How did they do that? In those days, cash flow was more important
than cost, and schedule routinely trumped scope. The paradigm was the inverse of
Parkinson’s Law—work should contract to fit the time
allotted. Today, Parkinson’s Law is alive and well in current scheduling approaches
that break work down into tasks, estimate the tasks, and sum up the result. This
approach invites work on each task to expand to fit the estimated time. Mary Poppendieck
will show why you should not ask, “How long will this take?”, but ask
instead, “What can be done by this date?” You will learn how to accomplish
more with less by applying cash flow thinking and turning Parkinson’s Law
upside down.
Learn more about Mary Poppendieck |
 |
|
|
|
|
|
Andy Hunt, The Pragmatic Programmers |
|
|
What is agile software development all about? Why is it fundamentally
different from other approaches and will it work for you and your organization?
Join Andy Hunt, one of the seventeen original authors of the Agile Manifesto and
a founder of the Agile Alliance, for his pragmatic answers to these and other questions.
Examine the foundations of agile software development and learn what problems agility
seeks to address. Don’t be distracted by dogma—take some time to explore
the core aspects of agile development. Andy presents the real foundations of agility
and walks you through a typical day in the life of an agile developer. Find out
what's really important about the agile approach, and take back new ideas to help
you transition to agile while avoiding common stumbling blocks. Join Andy to find
out how to make agility work for you.
Learn more about Andy Hunt |
 |
|
|
|
|
|
Ronica Roth, Rally Software Development |
|
|
At Yahoo!, the product owner role is defined as the “single
wringable neck” who ensures that software products and projects deliver value.
Many organizations struggle to fill this role that collaborates with stakeholders
to define value and manage a backlog, provides tactical support to the delivery
team, and directs the product and project vision and roadmap. For most organizations,
the reality is that it takes a whole team of people to fill this role. Ronica Roth
begins with a quick overview of the product owner responsibilities, particularly
in the context of the five levels of agile planning. She then presents patterns
and examples for organizing product and customer groups in product companies, consulting
shops, and internal IT departments. Soliciting your ideas, Ronica leads a discussion
of the successes and challenges of those patterns and of your experiences with them.
Gain new ideas about how to organize your product and customer group to support
value delivery.
Learn more about Ronica Roth |
 |
|
|
|
|
|
J. B. Rainsberger, Independent Consultant |
 |
|
Since Martin Fowler completed his now-classic work Refactoring:
Improving the Design of Existing Code, few programming practices have been more
effective—and more controversial—than refactoring. Refactoring is effective
when you study and practice it diligently. It remains controversial because many
development managers think developers should be adding features, not reworking old
code. J. B. Rainsberger takes you deep inside the process of refactoring, including
how to start reaping the benefits of refactoring while minimizing the disruption
of learning a new practice, how to safely refactor code you don't know well, and
the four key elements of simple design that should guide your refactoring. He explains
the hazards of refactoring, when not to refactor, and how to refactor in such a
way as not to upset your boss. After this presentation, you will be able to refactor
your own code more confidently and effectively. You might just impress some of your
colleagues along the way.
Learn more about J. B. Rainsberger |
 |
|
|
|
|
|
Guy Beaver, Net Objectives |
|
|
Implementations of agile and Scrum typically employ user stories
as the primary method for discovering requirements. User stories provide the mechanism
for the fast, flexible flow of ideas into completed increments of software. What's
missing is a practical approach to discovering user stories from top-down, business
valued, and prioritized capabilities. Guy Beaver shares proven approaches to allow
a project-driven organization to transition to business features that can be
predictably estimated and planned for release. The stories unfolded from business
features have clear line-of-sight to business goals and allow for the timely discovery
and management of technical considerations. Learn how to create release plans that
maximize business value while minimizing waste, how to drive accurate enterprise
release plan estimates with story point velocity, the Lean way to unfold user stories,
and how to account for technical constraints in your release planning.
Learn more about Guy Beaver |
 |
|
|
|
|
|
Pete Morowski, Borland Software Corporation |
|
|
While agile practices are starting to make their way into large
enterprises, in most instances this has been a “bottom up” movement
driven through grassroots efforts. But, as success stories draw attention to the
benefits of agile practices, an increasing number of executives are considering
making an organization-wide agile transition. It is an attractive idea, but what
does an agile transition look like when it comes as a mandate from the top? How
do you scale agile principles from a single team to an enterprise with multiple
teams working on multiple projects? Pete Morowski shares practical answers to these
questions, addressing issues such as the role of management in creating an agile
culture, bridging “two worlds” as traditional and agile co-exist in
the enterprise, and rewriting the “rules” to fit the organization. Pete
provides insight that can help you translate agile principles from theory into practice
for your enterprise.
Learn more about Pete Morowski |
 |
|
|
|
|
|
|
Not convinced about agile? Curious about this new approach,
but not sure it makes any sense? Does it feel like agile goes against everything
your experience tells you is the right thing to do? Damon Poole examines your concerns,
doubts, counter-examples, and horror-stories. If you are interested in helping to
answer the concerns of others, then bring your answers, positive examples, and experiences.
In either case, bring an open mind, a sense of humor, and at least one anecdote.
Delegates will share the floor and help to keep the atmosphere fun and relaxed.
Come and learn how some of the practices that may be fueling your skepticism are
either optional or only work when done in conjunction with other practices. For
instance, frequent releases are not required and short iterations work best when
coupled with automated regression testing.
Learn more about Damon Poole |
|
|
|
|
|
|
Dave Nicolette, Valtech Technologies |
|
|
Agile projects and traditional projects are tracked differently.
The key difference is that agile projects track outcomes; traditional projects track
activities. Project managers who are new to agile are often unsure which measures
are relevant to which stakeholders and how to interpret them, and how agile metrics
tie back to some of the more familiar forms of project reporting. Dave Nicolette
explains how agile projects are tracked, which metrics are useful to which audiences,
and how to monitor project health, delivery effectiveness, and the quality and value
of the results. Dave describes the reasons to choose particular metrics, how to
use metrics for informational, diagnostic, and motivational purposes, and the time-sensitivity
of metrics. Dave also explains the meaning and use of measures peculiar to agile
methods, such as “velocity,” “running tested features,”
“earned business value,” and “burn charts”. Bring your metrics
questions and apply the information to your real-world situations.
Learn more about Dave Nicolette |
 |
|
|
|
|
|
Jeff Dalton, Broadsword Solutions |
|
|
Are you convinced that agile development methods and process
improvement methods such as CMMI® don’t go together? Have you been the
victim of a ton of process overhead dropped on your head? It doesn’t have
to be that way. CMMI® and agile methods can work together to supercharge software
development performance, gaining the advantages of agility and the repeatability,
reusability, and infrastructure that process maturity provides. Jeff Dalton presents
an agile approach to CMMI®, both in content and in management of the process
itself. Agile cultures need to approach and perform process improvement activities
within a language and framework that makes sense to them—an agile framework.
Jeff discusses iterations, releases, design slams, integrated teams, and JENTM concepts
(just enough, not too much). If you are interested in agile methodologies and would
like to learn how to apply CMMI® in your organization, this class is for you.
Learn more about Jeff Dalton |
 |
|
|
|
|
|
Alan Shalloway, Net Objectives |
|
|
What if the process improvements you are trying to make are
not where your real problems lie? Assuming where your problems are is often the
biggest problem. Alan Shalloway presents value stream maps, a Lean tool that focuses
on finding waste in your development process. Alan presents an example of a value
stream map that resulted in a twenty percent productivity improvement to the development
team without modifying how the team worked. After this introduction to value stream
mapping, you will create your own maps to learn how to improve your own processes
and to learn the basic lean principles of optimize the whole, deliver fast, and
build quality in. Alan demonstrates how focusing on improving the flow of software
development from a time perspective can lead to a higher quality, lower cost process.
Learn more about Alan Shalloway |
 |
|
|
|
|
|
Pramod Sadalage, ThoughtWorks |
|
|
Agile methods focus on creating executable code quickly and
with fewer defects. But what about the database? The database is “the”
component of the application that is thought to be the least agile and often excluded
from agile development. Pramod Sadalage explains how the concepts of Behavior-Driven
Development (BDD) can be applied to database development to drive the design of
the database using executable specifications. Pramod describes how performing BDDD
(Behavior-Driven Database Design) allows us to specify the behavior of the database
as it is expected by the code running against the database, how BDDD allows us to
easily refactor the database, and how BDDD provides an easy way to document the
database design and behavior. If we encode all the behavior we expect from the database,
then we have a comprehensive set of tests to safely refactor our database in addition
to an extensive behavior specification of the database itself.
Learn more about Pramod Sadalage |
 |
|
|
|
|
|
Ellen Gottesdiener, EBG Consulting |
|
|
Some agile teams rely on user stories alone to articulate requirements,
struggle with requirements rework on large agile projects, and spend too much time
thrashing on requirements during iterations. Requirements expert and agile coach,
Ellen Gottesdiener shares a wide spectrum of requirements practices ranging from
traditional to agile to help you break out of the cookie-cutter mentality that some
take toward requirements elicitation. Practitioners from a traditional environment
learn how classic requirements practices are adapted on agile projects. Agile practitioners
learn how they may lighten, tighten, or incorporate a subset of traditional requirements
practices to mitigate risks associated with missing, erroneous, or conflicting requirements.
Gain an appreciation of ways to adapt requirements practices to fit various project
situations so you can do the right things for your project.
Learn more about Ellen
Gottesdiener |
 |
|
Top of Page
|
|
|
 |
Software Quality Engineering • 330
Corporate Way, Suite 300 • Orange Park, FL 32073
Phone: 904.278.0524 • Toll-free: 888.268.8770 • Fax:
904.278.4380 • Email:
sqeinfo@sqe.com
© 2008 Software Quality Engineering, All rights reserved.
|
|
|
|
