Not finding the session you were looking for? Want to delve deeper into a session you went to? Have an edgy or groundbreaking topic to share? Got some questions you want to discuss?
Then you want to come to Open Jam, where folks gather to introduce thoughts and take away ideas while building off of one another's creativity.
Anyone may convene an Open Jam session. They are short sessions that run throughout the day, from early in the morning, like Lean Coffee, and sometimes late into the evening! All you need to lead a session is passion and commitment.
We encourage interactive sessions providing opportunities to explore ideas and techniques. Sessions don't need to be formal, in fact, it's more fun if they are not!
So come to the Open Jam daily huddle at 8:30AM in the Jack Daniels space to choose a time slot for your session, then announce it to fellow conference participants so they can join! Feel free to tweet or promote your session using the conference hashtag #agile2013.
Follow @Open_Jam on Twitter for updates to what’s happening at the Open Jam track. Explore more, join Open Jam!
Governments spend hundreds of billions of dollars on technology, but they can adopt modern practices to reduce costs and improve services. And here's the thing: they are.
This is our story of how we built two successful lean startups, http://ifwerantheworld.com/ and https://makelovenotporn.tv/, from the ground up. We will be talking about our process, Cindy’s experience of working closely with our technical team & Pivotal Labs to realize her vision, and Corey’s experience as CTO and leader of the tech team of translating that vision into reality.
Cindy will illustrate the realities of managing a lean startup technical team from a CEO’s perspective. Corey will illustrate the realities of both managing a lean startup technical team, and also managing the CEO. :)
Many CEOs have an opaque window into their technical team. This vantage point can have counterproductive results born from good intentions. We are going to be utterly frank and honest about the trials, the tribulations, the blood, sweat and tears of how two very different mindsets and perspectives can meet, merge and get to awesome.
We will be sharing the solutions that we found for:
* Overcoming the obstacles we faced as lean startup.
* The tooling, data & process CEOs need to gauge the ramifications of their decisions on the development team.
* How to have the right amount of friction (push and pull) to get a polished product
* Which of the weird Agile practices is making your team crazy good or just plain crazy.
* How to write user stories and break them into minimum marketable features.
* How to create a closely collaborative triumvirate between technical, marketing, user experience to maximize the value of each mindset.
We will also be sharing how all of these things become even more challenging when you are working on a startup that is considered ‘adult content’, as per https://makelovenotporn.tv/.
Scaling the Product Owner seems straightforward enough, but how do we accomplish the same goal with the ScrumMaster role? Is it done in a similar vein to the PO, with Uber-ScrumMasters and Scaled ScrumMasters? Is it accomplished differently via Coaches and Agile Anarchists? Is positional authority necessary, as found with Tech Leads & Group Pod Leaders? And how do enthusiasts and communities of practice support scaling the ScrumMaster?
Together we will explore the role of the ScrumMaster within a large agile organization by discussing the merits of the ScrumMaster role, identifying what problems scaling the ScrumMaster solves and then sharing real-life examples and lessons we’ve learned at enterprise agile implementations through our coaching experience at Salesforce, Yahoo! and Johnson & Johnson.
Imagine you are an Agile consultant or coach. You are called by the inhabitants from waterfall island, who haven’t heard about Agility before and want to benefit from your advice. Which practices, principles and values would you pack in your agile suitcase for providing them guidance? What would you leave at home? In this session following experienced Agilists will deliver insights in their Agile suitcases:
Their short, concise and entertaining Pecha Kuchas may give you hints for your own suitcase. Afterwards you will work on your own agile suitcases. This may help you to travel lighter next time.
You are a Product Owner working hard to maintain a value-driven product backlog. That means you continually check in with what you mean by value. For us, that means checking in with your customers in new heartfelt ways. What adds value to them? What provides them function, commodity and delight? How can you act in love and service to them? Designing empathy into your product feature sets brings you into a deep relationship with your customers. Design from your head and heart to your customers' head and heart. Fortunately for all of us as product owners, George Kembel and his team at the d.School at Stanford University have been working for a number of years on approaches to help us develop customer empathy and to act on it. Having had the good fortune of working with George and his brother John, we have created a design empathy approach that draws from the d.School work. We have added some of our own brainstorming divergence and convergence approaches for data collection and knowledge massaging. This session affords you the opportunity to learn how to conduct our set of empathy activities: from empathy interviews all the way through a complete problem statement. Interactively in a workshop setting, we'll work in small teams to complete 2 of the steps of the overall process.
This meeting is a waste of my time. When was the last time you had that thought? Was it because the conversation wasn't focused, or people couldn't agree, or maybe they were in violent agreement, but couldn't see it? How easily do you think you can get this meeting back on track? In this session, you will learn a skill that you can apply on the spot that will help you focus the conversation and drive to consensus. Everything you need is probably already in the room.
This technique is specifically for conversations around the features, functions, and behaviors of your product. Most people are visual thinkers, so give them something visual to focus on. You can do that by walking up to the whiteboard and drawing out what people are talking about. By visually capturing the conversation in a public way, you will help all participants understand each other and come to consensus faster. But I can't draw, you say. Neither can I, and I’ve been successfully using this technique for over 15 years. If you can draw a straight-ish line and a box, you have all the drawing skills necessary.
In this engaging workshop, you will learn how to create a basic sketch of an interface using some simple sketching techniques and UX principles as well as practice thinking-on-your-feet that will help you comfortably do this with a group.
I have used this technique to help teams focus the conversation, visualize the requirements they were requesting, quickly experiment with new ideas, and provide detailed input that I can use to design the outcome. Often, the sketch (or a photo of it) acts as the deliverable for simple problems, eliminating the need for more formal wireframes. This technique is accessible to everyone. You don’t need any special software and anyone on the team can use it. Pick up the pen and get on track again.
Not finding the session you were looking for? Want to delve deeper into a session you went to? Have an edgy or groundbreaking topic to share? Got some questions you want to discuss?
Then you want to come to Open Jam, where folks gather to introduce thoughts and take away ideas while building off of one another's creativity.
Anyone may convene an Open Jam session. They are short sessions that run throughout the day, from early in the morning, like Lean Coffee, and sometimes late into the evening! All you need to lead a session is passion and commitment.
We encourage interactive sessions providing opportunities to explore ideas and techniques. Sessions don't need to be formal, in fact, it's more fun if they are not!
So come to the Open Jam daily huddle at 8:30AM in the Jack Daniels space to choose a time slot for your session, then announce it to fellow conference participants so they can join! Feel free to tweet or promote your session using the conference hashtag #agile2013.
Follow @Open_Jam on Twitter for updates to what’s happening at the Open Jam track. Explore more, join Open Jam!
Trust among team members is imperative for the success of a software development project. Little is known about how distributed teams in Agile software development could build trust between team members separated across different geographical sites, time zones and cultures. Through a Grounded Theory study that involved 55 participants from 38 different software companies in the USA, India and Australia, we investigate the key emergent concerns of distributed teams in Agile software development. We found that members of a distributed team need to build trust with one another in order to become a successful Agile team. In this paper, we present techniques for building trust in Agile software development with distributed teams.
Every day, across a wide variety of software and IT organizations, people are being oppressed. At this point, the oppression has become so systemic, so ingrained, and so accepted as "business as usual" or "the culture around here" that it is effectively invisible. In the software industry we casually talk about "death marches" and how people that give up their vacations, weekends, and special events at their kid's schools are "real team players." We routinely set ridiculous deadlines that nobody believes in to "motivate" people into "giving it their all." And for what? Is a little extra bonus money worth the broken relationships, lost time with your children, high stress, guilt, unhappiness, and impact on health?
Unfortunately, one of the reasons that Agile adoptions fail is that implementing the principles and values of the Agile Manifesto requires breaking the deeply ingrained habits of oppression. It is time to do more than just offer the solution of Agile development, it is time bring the subject to light and provide ways to counteract oppressive behavior.
Who is to blame? Is it a certain personality type or role? No. The root cause is not a person, it is the practices and organizational structures of traditional development itself. It is the system, not the people. Truly addressing the problem means changing the practices and organizational structures to support a healthy work environment. But the path to change starts with awareness and coping mechanisms.
In this session, participants will take a journey of self-discovery, realizing how they unknowingly practice, enable, and condone oppressive behaviors that they wouldn't allow in other contexts. After having their eyes opened, they will then interactively learn and practice ways to peacefully and constructively counteract oppressive behaviors. As those practicing oppressive behavior experience new and more effective ways to handle the typical pressures of software development, they will also have less need to practice their old behaviors.
'To accept passively an unjust system is to cooperate with that system; thereby the oppressed become as evil as the oppressor.'
'Often the oppressor goes along unaware of the evil involved in his oppression so long as the oppressed accepts it.'
--Martin Luther King Jr.
'Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.'
--The Agile Manifesto
Atlassian has a 10 year history of creating innovative software products. We struggled to include UX within our Agile and Lean teams. After making a lot of mistakes, we came up with the Experience Driven Development Playbook. It allows all our autonomous teams to include experience design effectively and remain strongly user centered and fast.
The Experience Driven Development Playbook, that Jurgen Spangl will introduce in his talk, is a radical set of strategies to play with your team. At the core of the Playbook is the Experience Canvas. Inspired by the business model canvas, the Experience Canvas is quite different to any other documentation we currently have on projects. It is not a spec, and it is not a roadmap or anything in between. It is more like insurance: it helps us stay honest. The canvas is driven by the whole team, not just the designers or project managers and it constrains the boundaries rather than the outcome. It's not a document, it's a tool like a barometer.
We will cover the playbook in the introduction and tell you all about how we can to make one in the first place. We have very autonomous teams, packed full of very smart people who we trust to do the right thing. Each team works in a way that makes sense to them, we don't dictate a process that everyone must follow. The playbook came from wanting to ensure that all the work we do in various teams hit a particular quality level in terms of design, is user centered, solves the right problem, etc...We took our inspiration from sports team playbooks that contain plays that the team uses to play together and win. The experience canvas is one of those plays, and probably one of the most important ones. It is the first play in the book.
We will share with everyone how we introduced it to our organisation, how it works, where we're trying to improve it and how it has affected the way we work. If you are in a product team, this workshop is for you, whether you have tried to integrate UX successfully or unsuccessfully or if you are in a
In regulated domains such as finance and health care, failure to comply with regulation can lead to financial, civil and criminal penalties. While systems vary from organization to organization, the same regulations apply for all systems. As a result, efficiencies could be gained if the commonalities between systems could be captured in public, shared, test suites for regulations. We propose the use of Behavior-Driven-Development (BDD) technology to create these test suites. With BDD, desired system behavior with respect to regulatory requirements can be captured as constrained natural language ‘scenarios’. The scenarios can then be automated through system-specific test drivers. The goal of this research is to enable organizations to compare their systems to regulation in a repeatable and traceable way through the use of BDD. To evaluate our approach, we developed seven scenarios based on the HITECH Act Meaningful Use (MU) regulations for healthcare. We then created system-specific code for three open-source electronic health record systems. We found that it was possible to create scenarios and system-specific code supporting scenario execution on three systems, that iTrust can be shown to be non-compliant, that emergency access procedures aren’t defined clearly enough by the regulation to determine compliance or non-compliance.
Agile methods provide an organization or a team with the flexibility to adopt a selected subset of principles and practices based on their culture, their values, and the types of systems that they develop. More specifically, every organization or team implements a customized agile method, tailored to better accommodate its needs. However, the extent to which a customized method supports the organizational objectives, i.e. the ‘goodness’ of that method, should be demonstrable. Existing agile assessment approaches focus on comparative analyses, or are limited in scope and application. In this research, we present a systematic, comprehensive approach to assessing the ‘goodness’ of agile methods. We examine an agile method based on (1) its adequacy, (2) the capability of the organization to support the adopted principles and practices specified by the method, and (3) the method’s effectiveness. We employ the Objectives, Principles and Strategies (OPS) Framework to guide our assessment process. The Framework identifies (a) objectives of the agile philosophy, (b) principles that support the objectives and (c) strategies that implement the principles. It also defines (d) linkages that relate objectives to principles, and principles to strategies, and finally, (e) indicators for assessing the extent to which an organization supports the implementation and effectiveness of those strategies. The propagation of indicator values along the linkages provides a multi-level assessment view of the agile method. In this paper, we discuss our assessment approach and substantiation results.
These aren’t the same old concepts repackaged. Understanding and communicating requirements in an Agile environment is a very different way of thinking and working.
In this talk, Jeff will explain where the idea of the agile story came from, and how best to write and use them. You’ll learn how stories help you manage the flow of discussion and work from big ideas all the way through to delivery. You’ll learn how to break big ideas down into organized backlogs using story mapping. You’ll learn how stories fit into a discovery process that you’ll use to better understand the challenges of your customers and users, imagine solutions, and continuously learn if you’re building things they truly value.
Talks during this session:
How would you like to experience Kanban for yourself? Try playing the game! In this session we will play the latest version of the popular getKanban Board Game, facilitated by the guy who made it! Rather than hearing theory, you will actually see how a Kanban system works. You will feel the tension as you make trade-offs between utilization and cost-of-delay. You'll see how classes of service work, and what they're good for. You'll collect metrics and construct your own Cumulative Flow Diagram, Control Chart, and Lead Time Distribution Chart. As a result you will come away with a deep, intuitive understanding of Kanban, and best of all, you'll have a great time!
Unit and acceptance testing are central to agile software development, but is that all there is to agile testing? We build on previous work to provide a systematic mapping of agile testing publications at major agile conferences. The analysis presented in this paper allows us to answer research questions like: what is agile testing used for; what types of studies on agile testing have been published; what problems do people have when performing agile testing; and what benefits do these publications offer? We additionally explore topics such as: who are the major authors in this field; in which countries do these authors work; what tools are mentioned; and is the field driven by academics, practitioners, or collaborations? This paper presents our analysis of these topics in order to better structure future work in the field of agile testing and to provide a better understanding of what this field actually entails.
Agile development have a distinct culture that at first glance seems to conflict with Interaction Design. Therefore, integrating these two areas becomes a challenging task. There is little guidance about integrating them. Very limited empirical evidence exists on agile development and interaction design being combined in practice. In order to better understand how these approaches are combined in practice, a multiple-case study of agile teams working with interaction designers was performed. In the paper, we present a set of ten lessons learned from these studies.
Empowering the team requires a very different approach to leadership. An empowered team has the authority and responsibility to make decisions, rather than needing to approval or instructions from a manager. The team itself self-organizes around a leader instead of reporting to a manager. This session will describe a number of leadership styles and how these apply to the various roles people play on an agile team.
When people are talking to you, are you really listening, or are you starting to think about what you’re going to say next? Even if you hear their words, are you sure that you understand their intended meaning? In this exercise-driven workshop we learn to employ Active Listening techniques to improve interpersonal communication, with particular attention to how active listening techniques can help an agile coach succeed.
Talks During This Session
Workshops are effective in learning the human and social factors of software engineering [1]. However, their effectiveness in learning agile development in particular has not yet been determined, despite the fact that numerous agile development workshops have been held over the years. In this paper, we analyze the effectiveness of agile development workshops through an experiment, and show that the workshops are indeed effective at learning agile development. Self-study is another commonly used method to learn something new. Therefore, we compare the effectiveness of workshops with that of self-study to better illustrate the effectiveness of agile development workshops. In our experiment, we examine 7 workshop subjects and 8 self-study subjects, and compare their scores on the Agile mind check, which is a method used to measure their degree of mastery of agile development. As a result, we demonstrate the effectiveness of agile development workshops, especially those that simulate actual experiences. We also show that workshops are more effective than self-study.
The popularization of agile development as well as the recent prevalence of virtualization and cloud computing has revolutionized the software delivery process- making it faster and affordable for businesses to release their software continuously. Hence, the need for a reliable and predictable delivery process for software applications. The aim of this PhD research work is to develop a System Dynamics (SD) model to achieve a repetitive, risk-free and effortless Continuous Delivery process to reduce the perils of delayed delivery, delivery cost overrun and poor quality delivered software.
Traditional approaches to quality and risk management involve quality gates, change control boards, feature freeze and code freeze milestones, and independent QA or Test groups. These approaches stabilize quality at by sacrificing agility. Yet buggy fragile code is even more dangerous for Agile teams where so much is changing so often. Quality and risk management are critically important for agility. This leads to the inevitable question: if the traditional approaches to quality and risk management don't work in an Agile context, what does?
Practices vary across organizations, but all successful teams emphasize the same underlying principles of fast feedback, high visibility, collaboration, and alignment. This talk examines various approaches Agile teams have taken to increase quality, mitigate risk, and ultimately ensure they are delivering the highest possible value for their stakeholders. Along the way you'll hear real world success stories and cautionary tales.
Five years after scrum was introduced to Red Gate development teams, we’re still seeing value in continued investment in our agile & lean efforts. In fact, we’re now adopting these practices at the board level.
In this engaging session, Simon Galbraith, CEO of Red Gate Software, will share his agile & lean journey so far, describing the pains, the leaps of faith, the successes and the failures of Red Gate's adoption of agile practices, as well as the direction in which he's taking his team and where they're heading next.
Don’t worry - he’s not here to sell or market. This is about sharing the amazing experience of creating and sustaining an agile culture from start-up to mature organization.
If there’s sufficient interest, he’ll also offer an unique opportunity to engage with participants on the challenges and benefits of agile which he faces as CEO of a multinational organization.
(This part was written by Simon Cromarty, our Head of Project Management, after discussing it extensively with Simon)
To become a mainstream methodology, Agile had to overcome many potential obstacles. The first was geography…One of today’s most daunting obstacles is compliance, often bringing heavyweight documentation, required procedures that are very waterfall-ish, complex approval work flows, and complicated approval processes begins Compliance Is A Hurdle, Not A Barrier, To Agile a Forrester Research paper published in July 2011.
This presentation will walk attendees through the problem of why organizations trying to manage a software development life cycle or PMO in a heavily regulated industry are fraught with challenges (e.g. externally mandated documentation levels, limiting the requirements and scope of the Product Owner, morale of employees). The presenters will discuss the fact that many of the external compliance standards (FASB, MAS, FSOC) are vague, and worse yet not written with the software development team in mind. In fact one of the risks is the interpretation of policy or external compliance standard remains on the business or with an executive (through personal / fiduciary guarantees). For example, authors of US Federal legislation (e.g. Dodd Frank Act) do not specifically consider software development when writing laws and are often ignorant to the downstream effects of said legislation for a development team based in Russia or India. When asked for clarifications the FSOC does not know enough about software development to provide clear and concise answers and the amount of documentation in the said legislation can be (a) in the thousands of pages and (b) within living documents.
In addition, organizations are feeling pressures of their employee base to go Agile / Scrum / Lean. As the way in which we chose to work – our process - is a very personal or team based choice undoubtedly more software developers regardless of regulatory levels will move from Chaotic, Structured and Waterfall environments to Iterative and Agile, following the same pattern as non-regulated industry trends. In f
A classic way to choose a supplier is through a bidding process where tenders from competing companies are evaluated in relation to the customer’s requirements. If the customer wants to hire an agile software developing team instead of buying a software product then a new approach for comparing tenders is required. In this paper we present the design of such a new approach, a so-called Scrum Code Camp, which was used to evaluate the ability of agile teams in two different bidding processes with seven competing suppliers. A design science research approach is used to analyze properties of the two instances of the Scrum Code Camp and identify abstract domain requirements and -components of a Scrum Code Camp with the aim of presenting something very useful to others performing competitive bidding processes.
Agile Trends and Future Directions - Come join the leading industry analysts as they discuss the latest trends and emerging best practices around Agile software development. Learn how the most successful software organizations are utilizing Agile to drive business performance. Find out how the latest innovations in Agile practices continue to mature as development organizations deploy Agile further across the enterprise.
Not finding the session you were looking for? Want to delve deeper into a session you went to? Have an edgy or groundbreaking topic to share? Got some questions you want to discuss?
Then you want to come to Open Jam, where folks gather to introduce thoughts and take away ideas while building off of one another's creativity.
Anyone may convene an Open Jam session. They are short sessions that run throughout the day, from early in the morning, like Lean Coffee, and sometimes late into the evening! All you need to lead a session is passion and commitment.
We encourage interactive sessions providing opportunities to explore ideas and techniques. Sessions don't need to be formal, in fact, it's more fun if they are not!
So come to the Open Jam daily huddle at 8:30AM in the Jack Daniels space to choose a time slot for your session, then announce it to fellow conference participants so they can join! Feel free to tweet or promote your session using the conference hashtag #agile2013.
Follow @Open_Jam on Twitter for updates to what’s happening at the Open Jam track. Explore more, join Open Jam!
Large-scale agile adoptions often fall at one of two hurdles: 1. The organization selects a specific agile method or framework which it then tailors to produce the ultimate, one-size fits all company specific agile method. One that typically entails enforcing a level of prescription and governance at odds with agility and the diversity of work found in most software development organizations. 2. Although successful locally the early agile adopters fall out of governance and never link themselves into the broader organizational units, programmes, or portfolios that sponsor and fund them.
These and many other hurdles can be overcome if you are agile with your methods and processes, and adopt a practice independent, result-focussed approach to governance, compliance and process assurance.
In this hands-on workshop, with case studies drawn from many large-scale agile adoptions including KPN and Munich Re, attendees will learn how to empower teams to own and evolve their methods, understand where they are, monitor progress and health, share their practices and experiences, and define result based governance and compliance practices
This session uses the emerging SEMAT / OMG Essence standard, kernel and state cards to get hands on with results-based check points, check lists and health checks.
How do Agile and Lean work together?
What is Lean, anyhow? Lean Governance? A Lean Startup?
What does it mean to be a Lean leader? How can business and IT work better together?
Come ask questions; let’s learn together!
The first value of the Agile Manifesto relies on a huge assumption – that we know how to interact effectively. Real world experience shows us that interaction can be tricky. Misunderstanding is common and that leads to wasted time, effort and resources.
This session will introduce you to five Communication Katas – practices you can learn and master to improve communication and working relationships. These conscious practices will prepare you for effective conversations that promote shared understanding. Small adjustments can lead to big improvements in the way teams work. And that contributes to better outcomes.
Face-to-face communication is the most important tool we will ever use. In this session, you’ll upgrade that tool as you explore and practise practical skills that increase clarity, diminish anxiety and reduce misunderstanding. Used consciously and consistently, Communication Katas help us in our individual capacity as team members, leaders and role models. They also help us develop people. When practised by a whole team, they influence organizational culture.
Join us in crafting conscious conversations that lead to results.
A team's agility is severely limited when developers have to wait 4, 6, even 24 hours to learn whether their latest change plays nicely with the rest of the code base. And untangling bugs introduced by other changes made in the meantime can take hours, which arrests team velocity.
If that doesn't sound like your idea of fun, what might be more enjoyable is learning a few ways to tighten the "feedback loop". If your code is going to fail, let's make sure it fails FAST! From plugins you can add to your build server, to dependent build hierarchies, to multi-threaded testing, there are many ways to grease the gears in your continuous integration system that are (spolier alert!) well within the reach of most teams. We'll explore tricks of the trade with real-world examples from real-world teams who use them.
This talk is tool- and language-neutral (with a certain bias toward plain-spoken English).
In the first decade of Agility, the primary focus was on "how" to write an Agile Contract. Progress has been made, but the limits to our capabilities is now around the system level effects of the contracts we put into place. Contracts that too often work against the customer's interests, whilst appearing to serve them
Come discuss and explore the bigger picture and the greater possibilities afforded by re-addressing the fundamental assumptions behind contract negotiation and customer supplier relations.
Because of Agile and better engineering techniques we have pretty much solved the problem of “delivering” software. Unfortunately, it’s not enough. Now we need to turn our focus to delivering “the right” software – software that makes an impact to the customer.
The answer to building the right software begins with a better understanding of the business opportunity and goals. Best of all, we can do this using a collection of familiar concepts, combined in a powerful new way, bringing a shared and measurable vision to agile product management. This approach is called “Impact Mapping.”
This workshop introduces “Impact Mapping” by demonstrating a collaborative approach to solving the challenge of building the right thing. Breaking into small teams, we will build a sample Impact Map, learn to identify and verify the assumptions you've made, and find new approaches to solving the business problem. We will also discuss using this to measure the output of our effort. Attending participants will receive a handout with a worked example and sample questions and techniques that help lead to a successful mapping session.
Don’t miss this opportunity to learn about and practice the techniques to uncover assumptions and motivations about your current project – and ensure your next project makes the right impact on customers and bottom line. Let's help our customers better refine and communicate their goals. Impact Mapping is at the heart of the customer voice because it literally gives voice to their needs. We will see you at IMPACT MAPPING!
Talks During This Session
While nearly everyone would agree that continuous innovation is essential to a sustainable business, many organizations are reluctant to invest in new ideas because of the risk and cost associated with development. What's needed is a way to quickly and clearly communicate new ideas so that you and your team can achieve clarity before coding.
We have developed the Ideation Framework, a rapid prototyping and validation process that will take an idea from discussion to a validated concept. This workshop will consist of a series of exercises that will guide participants through the discovery of a problem, visualization of a solution and validation of the idea.
The result of this process is a clear, shared vision of the solution that has been validated by your customer. Through your learning, you may also begin to realize that you need to pivot your vision and attempt the process on a new solution. Your development team will gain a better understanding of the idea and can better estimate the feasibility and cost of building the application.
Addison-Wesley published the 3rd Edition of Peopleware: Productive Projects and Teams in June 2013. Tim Lister and Tom DeMarco wrote the 1st Edition back in 1987. 2013 is Tim’s 40th year in the business.
In his talk Tim will describe his work as a colleague, as an apprentice, as a mentor, and as a mediator.
He will describe how team dynamics have changed over the years, and how they bring new challenges to tight collaboration.
Not finding the session you were looking for? Want to delve deeper into a session you went to? Have an edgy or groundbreaking topic to share? Got some questions you want to discuss?
Then you want to come to Open Jam, where folks gather to introduce thoughts and take away ideas while building off of one another's creativity.
Anyone may convene an Open Jam session. They are short sessions that run throughout the day, from early in the morning, like Lean Coffee, and sometimes late into the evening! All you need to lead a session is passion and commitment.
We encourage interactive sessions providing opportunities to explore ideas and techniques. Sessions don't need to be formal, in fact, it's more fun if they are not!
So come to the Open Jam daily huddle at 8:30AM in the Jack Daniels space to choose a time slot for your session, then announce it to fellow conference participants so they can join! Feel free to tweet or promote your session using the conference hashtag #agile2013.
Follow @Open_Jam on Twitter for updates to what’s happening at the Open Jam track. Explore more, join Open Jam!
Whether you are a professional trainer or trying to bring agility to your organization or team, you no doubt have encountered the difficulty in conveying agile values and principles. Learning practices and techniques is easy in comparison; You learn by doing. But how do you teach a philosophy or mindset? How do you 'do' a value?
Through trial and error, through hundreds of classes, through training thousands of agile practitioners, Gary and Don have put together a set of best practices (and not-so-best practices) for delivering powerful agile learning experiences. Participants in this session will walk away with a toolkit they can put to use the next day. The toolkit will include scenario simulations, learning games, discussion generators, reenforcement exercises, student patterns, common pitfalls, and other activities to help you get out of the way and let the learning happen.
Proponents of Agile software methods often emphasize higher productivity and shorter time to market as two major benefits. For new code bases that are not over-burdened with technical debt, it is indeed fairly straightforward nowadays to attain both benefits. The story is very different, however, when teams embrace Agile methods in the face of significant level of technical debt. The debt often outweighs methodical progress made through adopting Agile.
To effectively service debt, one needs to ensure that technical debt stories in the Agile backlog would not become ‘second class citizens.’ To that end, we propose treating technical debt as a strategic investment theme. To our way of thinking, technical debt is no different from customary budget allocations to growing market segments, tactical sales opportunities, cost reduction initiatives and the like.
The key to success in implementing technical debt reduction under a strategic investment theme ‘umbrella’ is rigorous integration of technical debt reduction techniques in the Agile method. This kind of rigor requires intentionality at two levels:
1. Forward looking backlog management that fully takes into account the long-term consequences of technical debt.
2. Ruthless operational discipline that is ready to ‘stop the line’ whenever technical debt levels get significantly out of line.
Like it or not, sooner or later you will have to service your technical debt. The techniques proposed in this presentation will enable you to implement a disciplined manner of paying back your debt.
I believe in the power of software as a tool for social change. But apps won’t change the world. People will.
In this session, you'll hear a global software delivery story about how we used agile principles and practices to build Amnesty International an app in India and conduct user research in Kenya. My report is a multi-stakeholder story about crafting strategies based on human empathy and understanding. I'll be sharing how techniques like customer journey mapping, user-test driven development and continuous design helped us investigate an ill-defined problem and posit the simplest solution. I’ll be focusing on the human factors techniques we used to understand human rights activists’ needs, and elaborate how this agile approach is valuable when thinking about creating tools that need to scale. Everyone can gain insight from the unique challenges that the non-profit, NGO, and social enterprise space faces. Attendees will learn how these project's insights can be applied to any sort of product development, and how anyone can use these sort of design insights in a project lifecycle.
We'll then focus on outcomes over outputs in an interactive workshop at the intersection of user experience and business strategy. My aim is to equip participants with practical takeaways to tackle their projects differently. We will talk about a wicked problem using a design thinking approach, and see how it integrates with agile software development methodologies.
This is an opportunity to move your good idea forward and have some fun with agile. Think of it like Lean Startup Machine for social design - in 55 minutes or less. The focus is to see how we can find a viable idea through gamestorming and similar activities, then how we'd funnel that into generative user research for next-step validation and lo-fi prototyping.
Participants will learn challenges faced when trying to kickstart an innovation strategy globally, and how to adapt a process from discovery to development that allows you to analyse a problem and fit the answer to the context.
A simple, effective technique I learned from hydrological engineers on a software project in Africa can dramatically ease your work of prioritizing stories and make it easier to get funding for your projects. This technique, called Multi-Criteria Analysis (MCA), is being used today to help over 30 stakeholders in the 9 riparian countries of the Nile region make cooperative decisions about the use of the water of the Nile. It is equally effective in our corporate environments.
In this session, I talk about different criteria we should consider when prioritizing user stories, including corporate goals, the vision for the direction of the product, and the needs of the customer. These criteria are often in competition; Multi-Criteria Analysis is a technique for resolving conflicts of interest in such a way that all stakeholders know that their voice is heard and their needs understood. MCA replaces a gut-level feeling for what the priorities should be with a scientific process for making decisions. It also ensures the needs of all the stakeholders are heard. Finally, I will discuss how to use MCA to: choose one solution from a list of possible solutions, prioritize a product backlog, and make a strong project proposal. The presentation material is woven throughout a facilitated workshop where we learn MCA by doing it.
In the facilitated workshop we will all be stakeholders reaching agreement on the priorities for a set of user stories. The user stories will be provided; our task will be to use MCA to reach agreement on the priorities of the stories. This hands-on experience allows us to implement the knowledge gained from the presentation. You will leave the session with an effective tool for making cooperative decisions in your company.
In this fun and energetic session, we will learn the basics of Test Driven Design/Development (TDD) through the use of LEGO. We will create failing tests, make them pass and then refactor. We won't be writing software, we will be using LEGO bricks. By working with our hands, these technical concepts that can be tricky to wrap your head around will be simplified.
Even today, to the detriment of agile success, most organizational cultures remain delivery date-driven—resulting in delivery teams that are not focused on creating value for the customer. So how can we redirect stakeholders, the business, and the project team to concentrate on delivering the greatest value rather than simply meeting dates? Pollyanna Pixton describes the tools she has used in collaboration sessions to help all stakeholders and team members begin the process of adopting customer-centric agile methods. These tools include laying out an end-to-end customer journey, forming reusable decision filters to help prioritize backlogs, converting features into actionable user stories, and developing a solid process for making group decisions and communicating those decisions. Pollyanna shares questions that product owners and managers can use to define the problem while making sure they don't solve the problem. After all, that is the responsibility of the delivery team.
The goal of this process is focused on bringing meaningful thoughts and creating one shared valuable vision. However, the additional value is providing a concrete beginning of moving the culture away from date driven to value driven.
The Tools
Proper Business Analysis is key to building a high performing Agile team that delivers valuable products that truly meet customer needs. Supporting Analysts will give you an insider's view of a real-world BA's transformation from an Agile skeptic to an Agile Coach . You'll be lead you through what BAs are likely thinking when they first learn about Agile and be provided with insights & strategies for building a team of analysts that are not only Agile champions, but also a driving force behind hyper-productive Agile teams.
**Supporting Analysts is a lecture-style session that will cover 5 key sections:**
*1) How Business Analysts typically derive their self worth*
- What builds a BAs self-identify
- What are the values of a typical BA culture
- How BAs perceive they fit into an organization
*2) What BAs often think when they first hear about Agile*
- Initial gut reactions from the Agile Manifesto
- Emotional resistance to how Scrum is often presented
*3) Questions and concerns a BA may never ask a Coach, ScrumMaster, or Manager*
- Fears about job security and the ability to add value
- Lack of buy-in around the process and ability to do quality work
- Differences between mature & immature analysts
*4) Topics that resonate with analysts to help them overcome resistance*
- Strategies for addressing the role of a Business Analysts
- Tactics for overcoming concerns around Business Analysis processes
*5) Key aspects of the Agile framework that play to a Business Analysts strengths*
- Important soft-skills
- Critical analytical skills
**About the Speaker:**
As a Business Analyst by trade, Leslie J. Morse has lived this. She worked as an analyst at a Fortune 50 retailer and was ultimately managing a team of 24 other very competent BAs when leadership decided to convert a 275+ eCommerce team from Waterfall to Agile. Mentally she rebelled, she didn't understand and over-engineered the role of a Business Analyst within the Agile framework, an
Using Measurement as **levers** rather than for **feedback**, is sin #1. What's the difference? **Levers** are employed to **change someone else's behavior**. **Feedback** is employed to **improve your own performance**. The distinction is subtle but critical.
One of the most basic tenants of Agile is to trust the insight of the people closest to the work. But, here's the dilemma... as Agile scales into the enterprise, organizations are demanding measurement. I have seen many presentations on measurement and they often start with a quote like this one from Lord Kelvin, [When] you know something about [something]; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind. A measurement regime based upon this tenant is doomed to drive you to the dark side. Rather, **the introduction of measurement to the Agile domain requires that it complement and even amplify the qualitative insight of those closest to the work, NOT replace or counter it.**
The above is just one example. This talk will walk you through the seven deadly sins to look out for when implementing an agile measurement regime, but it's not all fire and brimstone. We will leave you with a list of heavenly virtues or good practices to follow when implementing your measurement regime and we will present examples of companies that we have worked with and whose metrics regimes exhibit these virtues. This information should give you the means to bend your own execs towards risk evaluation rather than absolutes; toward measurement as an insight amplification and feedback mechanism rather than a club to beat people up; as something that your teams will seek out rather than something that they will dread.
Could the kinds of questions we ask ourselves and others help us become better collaborators, coaches, and impact our very quality of life? Can simply asking better questions improve everything we do? This highly interactive session questions our questioning and reveals valuable techniques for accessing hidden abilities within ourselves and others. You'll be guided through a series of interactive exercises to discover how to use questions that empower and motivate us to access our resourcefulness, re-frame limiting beliefs, and strengthen rapport. You’ll practice using the Precision Model to help you instantly identify five ways we commonly distort our understanding of a situation and use five challenge questions to gain clarity and improve communication. Applying this simple skill will help you achieve new insight into any problem or situation you encounter. You’ll also do an exercise to help you discover better questions that can lead to answers you may not have thought of otherwise, and you’ll identify a burning question you can ask yourself to motivate and drive you towards greater fulfillment. By the end of this workshop you’ll have practiced several techniques for using questions to marshal problem-solving resources and collaborate more effectively.
When we reward people for becoming increasingly specialized, when we reward projects only for delivering on time and budget, then we make it difficult to impossible to implement some of the core Agile practices (co-location, dedication, responding to change, focus on business value). Introducing good software engineering practices to support Agile development, such as modular development, architectural practices, coding and programming standards, and Continuous Integration, can also be surprisingly difficult to implement because of specialization, a desire to not lay off people, confusion about how to promote and reward people, and even problems with accounting.
Different companies will have different answers as to how far they want to go along the Agile adoption curve. At the same time, we have to recognize that most major corporations will continue to do some work using Waterfall, and so the changes we suggest to support Agile cannot break Waterfall. What are some of the challenges of making the changes to better support Agile? If your company does A, and decides to change to B to better support Agile, what are some ideas for how you get from A to B and what are the potential impacts on the organization? Also, can you stop part way to B and still get benefit, or do you really have to go all the way.
This presentation will equip you with the knowledge you need to talk with your managers about whether to adopt Agile practices and how far you want to go in your Agile adoption.
The old models are broken. We see it everywhere - in three decades of declining employee engagement, in organizations that are struggling to adapt, and in a broader sense that businesses and governments alike could be doing better. That’s why cutting-edge organizations throughout the world are tossing off the outdated, mechanistic 21st century approach and embracing something new. Built upon five decades of social science, this new approach uses autonomy, mastery, and purpose as the pathway to high performance. As you will discover, challenging the existing orthodoxies isn’t just exhilarating. Today it’s the only way to survive.
Dan Pink’s book DRIVE is nearly ubiquitous in the agile community, yet until recently there were no concrete HOW-TO’s available for teams and organizations. In this 75 workshop, I’ll present an overview of the basic principles of motivation, backed by science, and illustrated through real life examples. Then we'll cover the 3 keys to motivation and engagement; and we’ll workshop some real-life HOW-TO scenarios for making this happen in the real world.
Everybody will leave with a play-book of ideas to take back to their organizations.
The Voice of the Customer is heralded in the Agile community yet we still seem to focus on increasing our velocity and creating the most elegant bullet proof code. If you are simply building the wrong product 'righter', then you risk gold-plating a product nobody wants to use. Instead we should focus on the Customer and user 'Outcomes'. What they need to achieve, be it buying a book on Amazon to improving the way we run our business processes. The Outcome Delivery movement is emerging as a community focused on helping Customers achieve value. This session is one piece in the large jigsaw of being able to help our customers articulate what they really need, instead of telling us what they want. If you can help your customers articulate clearly what outcomes they desire, and make this tangible with quantifying the results (so we know when we reach the customer 'success' threashold) and qualifying progressively that the outputs we build are moving us towards the target outcomes, then we can create a common platform to communicate. To help build the right outcomes, for the right people, at the right time.
We provide an objective framework to help you target Outcomes over Outputs and understand how being able to constantly adapt to changing target conditions and being able to create a way to measure value, will help you more than all of the 'Product Backlog' sorting techniques on the market today.
Over the past decade, agile and lean methods have brought enormous benefits to teams and organizations. These improvements have primarily focused on helping build things faster, with higher quality and improved collaboration. What hasn’t been a focus is ensuring teams are building the right things. As a result, a feature farming culture has emerged that focuses all their energy on managing backlogs and measuring velocity with little clue as to whether the improvements are achieving their intended business goals or solving a core problem. Many times the real goals and outcomes aren't even defined clearly and shared with the team.
This needs to change. Lean and agile teams including their leaders should start quantifying what value is, aligning their solutions to delivering value and iteratively measuring their progress towards these desired outcomes. Using this approach helps greatly clarify the opportunity for focus, prioritize the backlog of potential solutions for maximum impact and directly link stories with desired customer outcomes. This helps teams focus on delivering the right things from the first Sprint and leaders focus their limited resources on solutions with the biggest bang for the buck.
Ryan Shriver and Gabrielle Benefield have spent the last decade working with teams and organizations transitioning to agile. Their focus is to 'stand on the shoulders of giant's'; bringing the ideas from people like Tom Gilb and the Poppendiecks and the leading UX design thinkers in a new and simplified fashion that make these techniques pragmatic and accessible. Over the last two years they've collaborated to create a simple framework to help people understand what value is, how to measure it, and how to track the value delivered. Simple visuals, simple metrics, simple processes. The result is a practical approach to helping people continually build the right thing that compliments existing methods including Scrum, Kanban and Lean Startup.
This is a hands-on workshop where attendees will be introduced to the concepts through working a case study. We will provide our simple models to fill in and give guidance and feedback on the real world uses of this approach.
One of the most rewarding change opportunities for organization to create awesome workplaces exists by being innovative at the management level. Forget step-by-step explanations of management practices (you can’t copy culture!); the key to address the management level - i.e. to foster innovations at this level - is by inspirations. In order to get an awesome workplace, you have to see awesome workplaces. There are plenty of ways to inspire people, but this opportunity is often wasted during the introduction of Scrum and Kanban methods, or never reflected upon afterwards.
In this session, I will show you several aspects of awesome workplaces. A constantly growing container for inspiring management are the Agile Management Innovations (AMI). AMIs are practices for management which lead to democracy, fairness, decentralisation, dialogue, and lot of other positive effects. These effects lead to awesome workplaces, where people are truly motivated. The idea behind inspiration is to foster creativity and innovation through a changed environment. Management practices can't be just applied; 50% of managent practices depend upon the organisation's culture. That's why we call them AMInnovations.
If you experiment with AMIs, you'll get from status quo to awesome (that is of course only when you're status quo is not already awesomeness).
I’ll introduce the concept of AMI as well as plenty of real world examples. The goal is to inspire you twofold: I will inspire you in this session to experiment with AMIs, and AMIs will inspire the people within your organisation to achieve a better workplace.
"This meeting is a waste of my time." When was the last time you had that thought? Was it because the conversation wasn't focused, or people couldn't agree, or maybe they were in violent agreement, but couldn't see it? How easily do you think you can get this meeting back on track? In this session, you will learn a skill that you can apply on the spot that will help you focus the conversation and drive to consensus. Everything you need is probably already in the room.
This technique is specifically for conversations around the features, functions, and behaviors of your product. Most people are visual thinkers, so give them something visual to focus on. You can do that by walking up to the whiteboard and drawing out what people are talking about. By visually capturing the conversation in a public way, you will help all participants understand each other and come to consensus faster. "But I can't draw," you say. Neither can I, and I’ve been successfully using this technique for over 15 years. If you can draw a straight-ish line and a box, you have all the drawing skills necessary.
In this engaging workshop, you will learn how to create a basic sketch of an interface using some simple sketching techniques and UX principles as well as practice thinking-on-your-feet that will help you comfortably do this with a group.
I have used this technique to help teams focus the conversation, visualize the requirements they were requesting, quickly experiment with new ideas, and provide detailed input that I can use to design the outcome. Often, the sketch (or a photo of it) acts as the deliverable for simple problems, eliminating the need for more formal wireframes. This technique is accessible to everyone. You don’t need any special software and anyone on the team can use it. Pick up the pen and get on track again.
