Customers & Business Value
You’re negotiating a project with a client or internal customer, but they balk when you don’t present a fixed budget and a predefined list of requirements. How do you convince them that the benefits of an Agile team outweigh a top heavy and fragile requirements document? Based on Agile experience with government and commercial clients, we will discuss ways to make your customer feel comfortable with process changes that don’t always result in the same set of documents they are used to.
Peter Coad’s Color Modeling method is a simple, effective technique for building robust, elegant object models. One of the best ways to learn the Color Modeling approach is through an interactive demonstration. In this session, Daniel Vacanti and David Anderson will solicit examples from the audience and—with no preparation and using the Color Modeling approach—build a real, working model for each selected problem domain in the short time given. Both David and Daniel have used this demonstration technique with great success at previous conferences, tutorials, and commercial engagements.
This tutorial, the “small card game”, is a simulation game introducing the concepts of Agile planning, story value, and story cost. Learn to manage scope and optimize return on investment. The students practice planning a project with varying levels of information about the features needed, and experience how “nature” deals with their plan. Again, very appropriate for all team members, in-house customers, marketing, and management, to learn how the process works and what their part in it is.
The technique of expressing requirements as user stories is one of the most widely applicable techniques introduced by the agile processes. User stories are an effective approach on all time constrained projects and are a great way to begin introducing a bit of agility to your projects.
The off-shore model for IT services is held up as the most cost effective delivery model. As companies gain experience with the out-sourced model, it is becoming clear that there are serious flaws even using Agile methodologies.
The presenter will directly compare the productivity metrics of off-shore distributed Agile teams with co-located Agile Teams. Co-located teams are far more productive and cost effective even accounting for the relative lower resource cost. Companies should be rediscovering co-located project teams as the paradigm for delivering real value for their IT projects.
This tutorial will provide you with a proven process for how to prioritize a backlog for profit. It will debunk the mistaken theory that you can prioritize a backlog for ROI and provide concrete examples of how to structure backlogs to meet the needs of key stakeholders, align your backlog to corporate strategy, and show how your release will drive profit. By following the process described in this tutorial, agile product managers / product owners can create backlogs that support the company’s longer-term goals as well as short-term development needs.
This tutorial teaches how to use a simple 5 component model to identify and prioritise stories on a project. The five elements to the model are: Business Objectives (value and goals) Business Actors (who does this) Business Events (when does this happen) Business Process (what needs to be done) Business Objects (what do we do it with - information and/or tools) The tutorial introduces the model as a tool for understanding current (“as is”) and future state (“to be”), identifying the stories for the future state and teaches the participants how to use it on a mock project.
How do agile teams account for backlog items that do not fit the user story paradigm? Aside from user stories, what are ways you can represent product needs? Teams struggle with incorporating quality attributes (sometimes called “quality of service” requirements), external interfaces, design and implementation constraints, and team or technical “stories” into their backlogs. Without these items, you will not build the right product, or build it right. This tutorial will introduce you to ways that agile teams represent these nonfunctional requirements and other items in the backlog.
Flirting is about connecting. A German university now requires their IT engineers take a flirting class—not to attract a partner, but to learn how to interact more effectively in the workplace. We will explore how flirting techniques translate to use in a business setting—inspiring us to create stronger connections with our customers. Our 8 Steps to connecting with your customers will help teams better understand customer requirements and build business value. “Flirting” With Your Customers creates the connection that can make a significant difference in a project’s success.
Scheduling should be done independent of and orthogonal to workflow. In fact, you don’t have to create a schedule for a flow system. It will flow all by itself, and work will flow much faster and much more reliably than it could possibly follow a schedule. But take a closer look at that workflow: Just when you thought it was obsolete, the V model reappears. This talk will step through systems design, approval processes, and scheduling, development workflow, depolyment, from a completely different angle.