Personas are no substitute for talking directly to customers, but what do you do when the customer isn’t there to talk to? Learn how to create a persona that helps you keep the customer in mind while developing your product. Tell user stories with confidence because the information is there to back the story up.

About David
Dave has 17 years of experience designing usable applications across a wide variety of industries. Dave’s focus is to increase the usability of any application, including web, through ethnographic research, heuristic evaluations, and rapid paper prototyping. Dave was first introduced to Agile techniques in 2002 and has been incorporating Agile methodologies with User Experience ever since.

The Product Council consolidates feedback, develops the roadmap, and maintains stakeholder buy-in for a continuously evolving plan. In this workshop, i’ll introduce two different Product Council structures and the pros and cons of each. We’ll also talk about voting methods, managing ‘persistent’ stakeholders, using lightweight business cases to avoid waste, and whether your Product Council should be a democracy or an advisory team.

About Alex
Alex Pukinskis has helped over 30 software teams transition to Agile development since giving XP a try in 2001. He has worked as an agile coach through Rally, ThoughtWorks, and as an independent, helping organizations of all sizes succeed with Agile. Prior to coaching, Alex was developer and manager of software teams. Alex is a regular presenter at conferences, including Agile, SD Best Practices, and Better Software. He is a Certified ScrumMaster Practitioner, and holds a B.A. from the University of Connecticut. Alex currently works as a product owner for Rally Software in Boulder, Colorado.

Interesting things happen when you put the words “Agile” and “Architecture” in the same sentence. Some would say that they have nothing to do with each other, others would say that effectiveness in one precludes effectiveness in the other. Still others would say “look, a squirrel”, but we’re not going to worry about them right now.

Rather than wander aimlessly through the vast domains of knowledge that both agile and software architecture imply, the goal of this session is to distill each down to a level where we can observe first-hand the impact that architectural decisions have on our ability to iteratively develop software over time, and vice versa. We will accomplish this by using an iterative exercise as a framework to construct and evolve a generalized application architecture.

Persons attending this session need not be either Agile or Architecture experts, but an interest in both is an absolute requirement. Ideally attendees will be familiar with the common abstractions of complex software applications such as user interfaces, business logic, communication protocols, API’s, frameworks, persistence mechanisms and so forth, but if you are not, we’ll be sure to group you with someone who is so you won’t miss the fun.

At the end of this session attendees should walk out with not one, but two shiny new skills – first is an increased knowledge of both the cost of investment and the price of change at various layers of application architecture. Second is a new sense of “smell” that will help you to detect when an architectural investment is needed, or when too much has been or is being invested.

About Jonathan
At the tender age of 14 Jonathan engaged in his very first “software for hire” contract, for his father who needed a TRS-80 Basic program converted into an Apple II floating point Basic program. This was immediately followed by his first experience dealing with an impossible customer, and being grounded for a month.

Over a career of darn near three decades Jonathan has been at various times a software tester, business analyst, clueless user, project manager, product manager, architect, programmer, and pointy haired boss.
Watching the same mistakes made over and over again in the industry drove him to look for better ways to make software that works, with the result that he now can be found lurking around both the Agile and software architecture communities, generally finding ways to make a nuisance of himself.

Jonathan is currently the Technology Director for Amirsys, a medical informatics company based in Salt Lake City, Utah. As a long-time devotee of Alistair Cockburn’s Crystal family of methodologies, Jonathan has successfully turned Amirsys into a Crystal “crash test” facility while at the same time continuing to deliver software that works and generates revenue with unreasonably small development teams.

Jonathan is also a Cockburn Associate and Certified Crystal Practitioner (and has the hat to prove it), a Certified Scrum Master, long time active member of the Salt Lake Agile Roundtable, and if the stories can be believed, quite possibly the world’s first Agile Sadist.

The starting point of all Agile engineering practices is reproducibly building from source code. If software is delivered on servers, and those servers can’t be reproducibly deployed from bare metal to running services, how Agile can you be? The definition of ‘shipping’ software has changed dramatically in the last decade. In a world where a server is an API call, new tools and technologies can be leveraged to optimize processes where infrastructure is code and deploying software is on demand. These tools can be used to implement dynamic scaling, on demand test environments and disaster recovery. Continuous integration is great, but get ready for continuous delivery…

About Andrew
Andrew Shafer is a partner at Reductive Labs where he develops and evangelizes Puppet, the open source system automation framework. Since 2004, he has been a regular participant in the Salt Lake City Agile Roundtable and a team member or manager in an Agile setting. Andrew has a background in computational science, embedded Linux, database administration, web frameworks, and operations. His new hobby is helping organize events like Agile Roots and Ignite Salt Lake. Follow Andrew at twitter.com/littleidea.

Israel Gat
PhD in Computer Science, executive career spanning IBM, Digital, Microsoft, EMC and BMC,’The Agile Executive’

Brian Marick
Signed the Agile Manifesto, Past Chair of the Agile Alliance, Founded Hermetic Order of AR⊗TA,

Diana Larsen
A specialist in the human side of software development, Chair of Agile Alliance Board of Directors

Mike Moore
Developer, husband, father, podcaster, Ruby zealot, MountainWest RubyConf organizer and first time manager implementing Agile

Christian Hargraves
Agile activist since 2001, original developer of Jameleon, presented at Agile 2007 and 2008, an active mentor in test-driven development and automated testing

Mickey Roos
Part of the team to transition AdvancedMD from waterfall, where Agile is now spreading out from engineering and being embraced by the rest of the company.

Alistair Cockburn, one of the authors of the agile manifesto, will recap the roots of the agile movement, what ideas have entered since the manifesto was written, and what upcoming ideas are making their mark. This march will incorporate lean development, the cooperative game model, kanban, and general laziness.

About Alistair

Dr. Alistair Cockburn is a world-renowned expert in Agile development, having co-founded the Agile movement and co-authored the Agile Manifesto. Dr. Cockburn is the author of the Jolt award-winning books Writing Effective Use Cases and Agile Software Development. He has more than 30 years of experience leading projects around the world, in hardware and software, research and industry, in companies of all sizes and specialties. Much of his material is available online.

View the video of Brian’s session

A problem with the word “Agile” is that everyone already thinks they understand it at a gut level. Worse, everyone already thinks they’re agile in spirit. (After all, the thesaurus tells us the alternative is to be clumsy, stiff, slow, and dull.) So it’s too easy for people to feel free to launch into “doing Agile” without ever having a serious conversation about what that actually means.

This problem is easily fixed. We’ll just stop talking about “Agile” and start speaking of “artisanal retro-futurism crossed with team-scale anarcho-syndicalism.” There is, I think, no danger that anyone will reflexively say, “Yes! That’s just what I’ve been wanting to do all along!”

The new name does more than just encourage conversation. It encourages conversation about those very properties of Agile that have become obscure as Agile has been commodified. In this session, I’ll unpack the meanings of the new phrase and encourage you to rediscover what’s been lost.

About Brian

Brian Marick (marick@exampler.com, www.exampler.com, twitter.com/marick) was a programmer, tester, and team lead in the 80′s, a testing consultant in the 90′s, and is an Agile consultant this decade. Brian is one of the authors of the Agile Manifesto, a past chair of the Agile Alliance, and the author of three books: The Craft of Software Testing, Everyday Scripting with Ruby, and Programming Cocoa With Ruby.

Transitioning 25,000 developers to agile development processes is a challenge on its own—and making the transition during a global recession is even more ambitious. Join Sue McKinney as she discusses her experiences leading the move to agile at IBM, how their agile teams often struggled, and ways leaders provided support and understanding at many levels. Learn specific leadership approaches you need to support distributed teams as they adopt and deliver using agile methods. Discover the tools you can use to inspire and motivate change in a large organization steeped in tradition or a small one stuck in its ways. Find out the new leadership skills that teams must encourage and nurture to build a successful agile enterprise.

About Sue

Currently responsible for development transformational activities with IBM’s software development group, Sue McKinney’s major emphasis is driving adoption of agile and lean principles into the mainstream of software development. Prior to this assignment, Sue was a Vice President of Development for the Lotus Division where she led worldwide development for Lotus Domino, IBM Sametime, and WebSphere Portal. In addition to driving transformational activities within IBM, Sue works with large clients to share IBM’s experience and help them scope opportunities for their own transformational activities.

The principles articulated in the Agile Manifesto make a lot of sense to the software craftsman who dreams in code. They can, however, be quite puzzling to executives who consider Agile software in the context of their company’s established norms and patterns. Assumptions embedded in a business design with respect to customer relationship, competitive differentiation and value capture are not necessarily aligned with the principles advocated in the manifesto. Moreover, the core culture of a corporation might not be hospitable to Agile principles. Corporate culture basically specifies “how we do things around here in order to succeed.” Agile Principles challenge these norms. 

The path an Agile roll-out should follow depends on the core culture of the corporation: control, competence, collaboration or cultivation. Irrespective of the specific culture, the Agile roll-out invariably tests cultural integration, wholeness and balance. In particular, it exposes inconsistencies between approach with customers versus approach toward other constituents of the corporation such as partners and employees. Consequently, corporate reactions to Agile often express the disappointment of an organization when it is forced to take a good look in the mirror. 

Grass roots Agile initiatives can propel a company a long way. However, the creation and capture of long-term value is invariably linked to successful business design and coherent corporate culture. To succeed on a large scale, bottom-up Agile initiative must be complemented by top-down commitment to learn, change and keep a living company. It is the combination of the two, the willingness to apply Agile practices in an indivisible manner that will fulfill the premise of the manifesto.

About Israel

Dr. Israel Gat is a Senior Consultant with Cutter Consortium’s Agile Product & Project Management practice. He is recognized as the architect of the Agile transformation at BMC Software. Under his leadership, BMC Software development increased Scrum users from zero to 1,000 in four years. Dr. Gat’s executive career spans top technology companies, including IBM, Microsoft, Digital and EMC. He has led the development of products such as BMC Performance Manager and Microsoft Operations Manager, enabling the two companies to move toward next-generation system management technology.

Let’s face it, we have all suffered from the tyranny of meaningless metrics. Metrics that are imposed on us as a means to ensure that we are being productive and busy. In this “whiteboard” presentation, Niel Nickolaisen describes a pragmatic approach for finding and using meaningful metrics – metrics that promote accomplishment over activity – as an alternative to meaningless metrics. Niel gives examples as he describes the characteristics of meaningful metrics and then asks the audience to apply these characteristics to their roles so that they can walk away with at least one meaningful metric they can use in their jobs and for their projects.

About Niel

Niel Nickolaisen is the CIO and Director of Strategic Planning at Headwaters, Inc. He has held technology executive and operations executive positions; typically in turnaround roles. He has developed a strategic and tactical alignment model that significantly improves returns on technology and business initiatives (by both improving the benefits and reducing the costs and risks). He writes the “Practical CIO” column for the CIO Leadership Network and a “how to” column for Search CIO. He is the author of an Addison Wesley book on Leadership scheduled for release in 2009. CRN Magazine named Niel one of the top 25 IT Executives of 2008. Niel is also one of the founders of Accelinnova, a think tank focused on improving organizational and IT agility.