Agile2015 has ended

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

Experience Report [clear filter]
Monday, August 3


How fudge candies catalysed feedback and engagement? Case study of successful experiment. (Krzysztof Czajka)
Limited Capacity seats available

This is a story about building appreciation and feedforward culture in the organization.
I am going to talk about a bottom-up experiment based on Jurgen Appelo's Merit Money, conduced in the biggest e-commerce company in Poland - Allegro Group. It is a story about learning throughout an Agile experiment to get the most out of it. Primarily the experiment was intended to challenge the existing bonus system based on forced ranking. It turned into appreciation and feedback system with some sweets involved. We will start from what needs this experiment was intended to address and see what were the obstacles in the beginning. Then see why and how it developed and what were the final outcomes of it. Then an interesting insight on how the participants liked it. Then an attempt to analyse the entire experiment and why we were sure it will be a success way before it was launched company-wide. At the end participants will see what the experiment finally turned into and how it is working in the company at the moment.
Do you feel your team could be more engaged in their work? Get inspired by this simple game, in which there are several instant feedback loops, fun, gambling and sweet prizes.
Oh, I forgot... and you'll find an answer on why we call it Fudge Candies.
Learning Outcomes:
  • Agile people: What you should consider when introducing similar kudos-like system? How to say thank you “like a real man”?
  • Managers: How to build engaged teams based on frequent internal feedback? What you should avoid?
  • Agile Coaches/SMs: Will see a feedback system example, which help build energized teams and incorporate frequent feedback from product owners.

avatar for Krzysztof Czajka

Krzysztof Czajka

Scrum Master, Allegro Group
Advocate of lean process in organizations. Fascinated by human behaviour in thinking organizations.

Monday August 3, 2015 14:45 - 15:15
Potomac 4
Tuesday, August 4


Strategies for adopting Test Driven Development in operations (Ranjib Dey)
Limited Capacity seats available

Operations has traditionally been the most interrupt driven part of any IT organization. But as cloud adoption kicks in, DevOps and infrastructure as a code brings in paradigm shift in IT operations, importance of code quality and other mainstream software development practices becoming integral part of IT operations. In this presentation I would share my experience on how we have successfully introduced agile methodologies in our operation team. How we have ensured our core business requirements (like high availability, scalability) were bolstered by introducing software development practices like test driven design, sprint planning, story based iterative development etc. I'll also talk about how unplanned activities like outage, newly discovered software vulnerability affect these workflows, and what can be done at the team organization level to minimize these effects. What safety nets need to be built to bolster teams confidence (and happiness :-) ), while we grow rapidly both in people side as well as in infrastructure side.

Key Learning:
  • When introducing new practices, start small.
  • Form a small but quality software part that reflect the usage of TDD techniques and let your peers, junior explore it, realize the benefit of it, before making it a convention.
  • Reduce adoption cost. Experience practitioner should pick up the high risk items first
  • Adopt and mix agile methodologies with the current practices incrementally, as and when the team feels comfortable with rather than enforcing a strict documented procedure (like ITIL).
  • Its almost always that something will fail, we cant avoid failure, but we can reduce the risk by shipping changes incrementally.
Learning Outcomes:
  • - how to adopt automated testing practices in operations team
  • - how to model and deliver strategic objectives in interrupt driven teams (like operations)
  • - how to ensure continuous learning in ever changing technological/tools landscape
  • - how to use better collaboration and communication techniques to ramp up new hires, junior candidates

avatar for Ranjib Dey

Ranjib Dey

Operations Engineer, PagerDuty
is a system administrator at PagerDuty, a hosted alert dispatch service.Along with rest of the operations team, Ranjib tries to design, deploy and maintainsystems that can withstand major outages. Before joining PagerDuty, Ranjib worked at Google, ThoughtWorks etc.In past Ranjib built... Read More →

Tuesday August 4, 2015 09:00 - 09:30
Potomac 4


Talk Ain't Easy - Round-the-World Agile Without *ANY* Talk (Gerard Meszaros)
Limited Capacity seats available

Face to Face Communication is one of the core values of Agile yet here we are building an SaaS product with a 5 person team in 5 time zones spread around the world using agile and we never talk to each other! Come see how we rescued a a small 5-year-old SaaS product that was suffering from an existential crisis by adopting agile practices and innovative communication techniques using free or low-cost SaaS tools .
The original developer had built a complex system that met the business needs but after 4+ years had lost interest in the product. As a result the flow of new functionality had slowed to a dribble and the business people in Australia and New Zealand were very frustrated! The technical architecture was quite complex as it used many frameworks but had no documentation and very few (and very complex) unit tests. There were half a dozen servers doing various things and the build and deployment processes were all manual. As a result, we were in severe danger of being unable to support the product. We had to find someone to take over support and enhancement of the application and we had a lot to learn. Being a very small company with everyone only involved a few hours per day, we couldn't afford the cost or risk of hiring a full time developer. We've had some ups and downs with outsourcing the development work to people in India and Romania but we have now restored the regular flow of value to our customers. This required evolving a highly distributed agile process with each person located on a different sub-continent. We embraced key agile practices including User Stories, ATDD, CI, Unit Testing, Database Refactoring and Automated Deployment (not quite CD, yet!) We build on cloud-based SaaS technologies whenever possible to maximize value and minimize build cost. And we learned how to work as a cloud-based team with good collaboration and communication using cloud-based tools without ever talking face-to-face.
Learning Outcomes:
  • * Adopting Agile doesn't have to be expensive.
  • * Distributed development challenges can be overcome using low-cost (or even free!) SaaS tools.
  • * There is an amazing variety of SaaS tools available to choose from (Good news: don't have to build; Bad news: Have to choose from many options)
  • * Avoid analysis paralysis; Just pick something "good enough" and start running with it
  • * Voice communcation is highly overrated - Poor communications links and accents can make it useless
  • * "Good-enough" communication is better than no communication; good chat tools are key;
  • * Supplement with Multimedia (quick screen shots, mock-ups, interactive prototypes, etc)
  • * People will adjust behaviour to optimize the situation; many of us make ourselves available in non-core hours to answer developer questions quickly
  • * Start with small improvement features that affect small parts of the code; learn as you go
  • * Plan on things to take longer than you expected and don't despair when they take even longer; everyone is learning lots and will get faster over time
  • * Be prepared to get the wrong people off the bus! (Our first attempt at outsourcing was a dismal failure; we had to rewrite all the developers code; we should have fired him a lot sooner.)
  • * Focus on quality, productivity will come later.


Gerard Meszaros

Solution Frameworks Inc.
Gerard Meszaros is an independent software development consultant and trainer with 30+ years experience in software and over a decade of experience in agile methods. He is an expert in test automation patterns, refactoring of software and tests, and design for testability and has... Read More →

Tuesday August 4, 2015 11:30 - 12:00
Potomac 4


The Agile Architect: Our Experience in Discovering A Successful Pattern (Chris Edwards, Sean Dunn)
Limited Capacity seats available

The role of "Architect" is sometimes frowned upon in the Agile community as a central command-and-control authority who bottlenecks decisions and limits team empowerment. Or at least, that is what we thought. Follow the real-life journey of our teams as we discovered how the role of an architect is compatible with Agile principles. We will explore our failures, and eventual discovery on how the role brings can bring an immense amount of value to the organization and the teams, especially on large, multi-team projects.
This talk relates our experiences in integrating an architect role with several teams at IHS Inc. Faced with the challenge of scaling several teams working on the same product, we quickly discovered the need to exchange technical information between the teams. How were we to maintain an appropriate level of technical consistency while remaining true to Agile principles? We explicitly wanted to avoid an authoritative architect role, but struggled to find an alternate model. After initial failures, we eventually learned the important relationship between leadership and architecture. Ultimately, we discovered a successful pattern for an architect role that preserves emergent design and team empowerment while maintaining minimally sufficient technical consistency.
Our organization is comprised of approximately 40 people on 6-7 teams developing 3 separate products. Between 3-5 teams are working simultaneously on the Harmony Enterprise project. The challenges of this project are the focus of the presentation.
Learning Outcomes:
  • Our initial approach of the architect was to be a “scout” that did investigations and provided a stream of information to the teams. We encountered several issues with this approach:
  • - Communication would breakdown. Info would be misunderstood or missed. This often became the "architect's fault" for not communicating enough information.
  • - Different teams had different design values, and thus there was friction between the teams who had different expectations of the designs coming out of other teams. We could not yet engage in meaningful, objective design discussions. Again, this became perceived by the teams as "the architect's fault".
  • - We learned quickly that we were "wrong" about our architectural approach. This was an agile victory because we discovered it early, but it was not well received by the teams who perceived someone else's mistake as causing them more work.
  • We value consitency in several areas (Coding standard, design values, architectural approach), but we failed to engage the teams in decision making process. Through one-on-one conversations with Scrum Masters, we developed a "Design scrum-of-scrums", in which the Architect facilitated a daily 30-minute meeting with representatives from each team ("Design Quarterbacks"). His goal is not necessarily to provide answers, but to guide the conversations so the teams are considering all the right things and reaching a decision that they can buy-into. Previously the Architect would be responsible for doing research and prototyping, but now acts as the role of Coach while the teams take on this responsibility.
  • Our experience with this approach as proved very positive.
  • - Relationships between teams has improved which has results in much more communication.
  • - Problems with designs are discovered much quicker, because the teams have more information
  • - A common mental model (“Conceptual Integrity”) exists across teams, which results in reduced rework.


Sean Dunn

Agile Coach, IHS Inc.
Sean has been passionate about Agile methodologies since 2008. He is experienced in the energy and defense industries and has successfully applied Agile methodologies in a variety of settings. With over 13 years of military experience, Sean is very interested in the relationships... Read More →
avatar for Chris Edwards

Chris Edwards

Principal Software Engineer, IHS Inc.
Chris Edwards, P.Eng. Chris is a software manager with IHS Inc. IHS is a global company with over 8000 employees that provides information and analytics to multiple industries,including energy, automotive, electronics, aerospace and chemicals. Chris has had a variety of roles including... Read More →

Tuesday August 4, 2015 14:00 - 14:30
Potomac 4


Facing Fake-To-Fake: Lessons Learned from Distributed Scrum (Vincent Tietz)
Limited Capacity seats available

Agile and distribution is not a contradiction. The agile principles seem to compensate the risks in distributed development scenarios. This is what the Saxonia Systems AG has learned from numerous distributed projects. With the introduction of agile methods, we seem work significantly better. But, why? This presentation analyzes the main risks in distributed setups and shows how agile principles have impact on the team collaboration and motivation. We show what we have learned from past projects and what we have done to support distributed teams. Finally, we provide an overview about the four pillars of distributed and agile software development: 1) the distributed project room, 2) the tools, 3) the adopted processes and roles, and 4) the motivated team. Finally, we show how these aspects result in our concept ETEO (“Ein Team – Ein Office” which is german and means “one team – one office”) which boosts distributed teams.
The distributed project room consists of a digital scrum board, a high definition video conferencing system which is always on and a general room setup for working and meeting periods. Today, collaboration tools for code review, video chat, screen sharing, synchronized boards and others, support many tasks within a distributed scrum team. Further, we identified additional skills for team members and especially the Scrum Master. As the title suggests, the face-to-face communication is limited which might be experienced as non-natural or "faked". Therefore, we introduced tools to improve awareness and expressiveness of each team member. Finally, the whole team needs to reflect their working culture and should be supported by specialized coaching tools. Continuously, the implementation of the agile principles need to be reviewed to keep the team efficient and motivated. Ignoring at least one of these facts, may lead to dangerous and unpredictable projects, wherein the team needs to invest much time to find out how to work distributed and efficient.
Learning Outcomes:
  • challenges and pitfalls when implementing distributed agile
  • setup of a distributed project room,
  • required tool classes and tool examples,
  • adopted processes and team roles and
  • tools to improve awareness and expressiveness for a truthful team communication


Vincent Tietz

Saxonia Systems AG

Tuesday August 4, 2015 15:45 - 16:15
Potomac 4
Wednesday, August 5


Rebooting Agile @ GE Transportation (Jesse Fewell, Julie Wenzel)
Limited Capacity seats available

What do you do when your Agile journey isn't going where you'd hoped? GE Transportation had been on a multi-year Agile journey, but recently challenged itself with hard questions: Are we getting what we want? What if we turned everything upside down? What if we leverage our maintenance burden to increase innovation? What if labor capitalization increased our transparency? What if going offshore actually increased our collaboration? Come hear the honest story of the largest builder of railroad equipment leverage impediments into improvements.
Learning Outcomes:
  • Understand why you might reboot an Agile program
  • Understand ideas for generating executive buy-in BEFORE making changes
  • Understand ideas for overcoming both known impediments and unexpected surprises

avatar for Jesse Fewell

Jesse Fewell

Agile Coach & Trainer, JesseFewell.com
Jesse Fewell is a writer, coach, and trainer in the world of management and innovation. From Boston to Bangalore, he's helped startups and conglomerates alike catapult to breakthrough results. His adventures are written down in "Can You Hear Me Now", his handbook for remote teams... Read More →

Julie Wenzel

IT Program Manager, General Electric Transportation
I am a recent graduation of GE's prestigious Information Technology Leadership Program (ITLP) where I successfully completed four six-month rotational assignments in data modeling with SAS solutions, supply chain, finance enterprise standards, and in global signaling. I am a result... Read More →

Wednesday August 5, 2015 11:30 - 12:00
Potomac 4


Lessons learned from testing a mission critical and complex system (Melanie Hopwood)
Limited Capacity seats available

In this Agile software development environment, are you working on legacy software that has an impact on our nation's security? Or are you asking yourself how can I do test driven development with such a huge legacy code base? Would it take you forever and a day to test everything in your system? We have felt these pains and have some suggestions on how to utilize user data, metrics and risk planning to resolve these hard questions.
Learning Outcomes:
  • Ideas on how to automate test scenarios that involve sensors
  • How to create test scenarios to ensure performance of an aging code base
  • How to maximize the value from exploratory testing of a complex system
  • How to best integrate live data into automated testing for complex scenarios
  • How to establish criteria to gain consensus of an appropriate level of testing on a complex system

avatar for Melanie Hopwood

Melanie Hopwood

QA Advocate, Asynchrony
3 years experience working with an experienced Agile team developing software for support of first responders

Wednesday August 5, 2015 14:00 - 14:30
Potomac 4


Organization and Business Agility: Managing the Portfolio Backlog in Large Organizations (Ken Power)
Limited Capacity seats available

Working in a multi-team, multi-program, multi-product environment brings several challenges. One of those is providing a smooth flow of work to teams, and incorporating their feedback, while staying responsive to the needs of the business in a changing environment. This Experience Report documents several years’ experience working in such environments. The focus of this Experience Report is specifically on managing the portfolio backlog, not the full scope of what could be considered under a portfolio management strategy and implementation. We have found that getting the portfolio backlog management strategy right is a key element in the success of the overall portfolio management approach.
It sounds like it should be straightforward: create a list of all the work the organization has to do, get the right people together, prioritize the work, make changes as needed. The reality proves to be far from obvious. The attempt to provide a portfolio backlog approach brings the organization’s agility into sharp focus. Those business units that make it work effectively find that having an approach for managing the portfolio of work contributes to overall organization responsiveness.
This Experience Report will share several lessons learned, and highlight some pitfalls to avoid, when designing your own portfolio backlog management approach.
Learning Outcomes:
  • Challenges and lessons drawn from several years of implementing portfolio backlog management approaches in multiple business units
  • Definitions that we use
  • Useful practices
  • Value of portfolio management
  • Relationship between managing the portfolio backlog, and the work done by teams
  • Relationship between product managers and product owners
  • Metrics
  • Visibility and transparency
  • Flow of work
  • Explicit investment in different area: features, capabilities, architecture and more
  • Rolling roadmaps, and how to communicate the portfolio to customers
  • The role of continuous planning
  • The portfolio backlog management meeting
  • The portfolio leadership team
  • Collaborating with customers and other stakeholders

avatar for Ken Power

Ken Power

Software Engineering Leader, https://kenpower.dev/
Ken Power has held multiple positions in large technology organizations. His current responsibilities include leading global, large-scale engineering organization transformations. He has been working with agile and lean methods since 1999. He holds patents in virtualization and network... Read More →

Wednesday August 5, 2015 14:45 - 15:15
Potomac 4


Lean Sales Up - Making value since the pre-sale stage (Jorge Silva)
Limited Capacity seats available

The process of pre-sales can be painful, long and expensive.
It’s the first negotiation stage. You have to convince the prospect that you are the best
option. And we have to adjust the customer’s always-high expectations. And therefore,
this leads to over estimation, lies about times and deadlines, and a lot of non-healthy
behaviors that get the relationship dirty at the beginning.

However, there is always a way to improve and to get a balance, where both the
customer and the provider feel confortable, satisfied and secure.
In this report experience, we will explore how to merge the delicate and costly sales
process with the agile/lean principles.
We will reflect about how to identify what really adds value to the proposal or contract.
Since this is an experience report, we will stand in real experiences and real examples,
which will go with every concept, idea and thought mention in this report. So this is no
theory on practice, but theory from practice.
The goal is to show how to start adding value from the ground-zero stage. The idea is to
generate value from the conception of the product/project. Eliminate waste as the lean
thinking predicates.
To meet our goal, we will share our experience in several sales processes, talking
mainly about these topics:
• How to manage time request
• How to generate trust through transparency
• How to give flexibility and empowerment to the customer
• How to revert the "fix feature oriented” thought to a more time box approach.
• How to educate the customer with some agile concepts and practices.
• How to become a partner with the customer, and stop being a provider
Learning Outcomes:
  • Audience could take lot of tips, tools and ideas sprung from real experiences. It most important, it will be able to start using it easily in their daily work.

avatar for Jorge Silva

Jorge Silva

Co-Founder, 10Pines
I'm a software developer who has more than 10 years in the field. In the last 5 years Im leading a company that is strongly based on the agile principles. Lately we had participated in several bids, generating time for reflection and to improve our sales skills. In particular, bids... Read More →

Wednesday August 5, 2015 16:30 - 17:00
Potomac 4
Thursday, August 6


Hardened Agility: Deploying Agile at a Defense Contractor (Joe Gariano)
Limited Capacity seats available

Are government contracts too rigid for agile? Is agile too undisciplined for a large defense contractor?
I have faced many of the challenges of applying agile in the defense industry. In my career at General Dynamics, I've spent years using agile methods in the development of government encryption products, I've consulted with a variety of engineering teams wanting to increase their agility, and I've led an agile initiative within our internal IT department. In this experience report, I will identify some of the contractual and cultural obstacles to agile that we've encountered, and will summarize the process and tool framework that we've evolved to address those obstacles. Agile practitioners in the defense industry will learn how we solved some familiar problems. And those outside of defense may be surprised at the innovations borne out of this environment.
Learning Outcomes:
  • What some of the fundamental challenges are to applying agile in the defense industry (both contractually and culturally)
  • How certain formal processes and tools can be integrated into agile in a smart way to make it more compelling in the defense industry without sacrificing agile values
  • How certain defense industry practices might benefit agile outside of the defense industry

avatar for Joe Gariano

Joe Gariano

Project Manager, Agile Champion, General Dynamics Mission Systems

Thursday August 6, 2015 09:00 - 09:30
Potomac 4


From Scrum to Kanban - A Team's Journey (Aki Namioka)
Limited Capacity seats available

In the summer of 2014, my team made the decision to transition from Scrum to Kanban. After practicing Scrum for 2+ years, we found that as the nature of our business was changing, our practices weren't holding up. My company, Marchex, had decided to move my team away from working on our Free411 product, to a new Search related product. Directory Assistance was not a growing business, and it was clear that Mobile Search Advertising had huge growth potential.
In the world of new product development, we found our priorities and backlog were changing much more rapidly and our 2 week sprints plans were becoming problematic. In response, we started looking at Kanban as a paradigm that would help us accommodate a more fluid backlog. With guidance from another team that was successfully using Kanban, we embarked on our journey. We took a number of steps to help make the transition as smooth as possible, and by the end of the summer we had completed our transition to Kanban. I will discuss the factors that led us to make the transition, the steps we took to make the transition as smooth as possible, and a summary of best practices and lessons learned.
Learning Outcomes:
  • Factors that led to transition
  • Process of transitioning from Scrum to Kanban
  • Lessons learned, during transition from Scrum to Kanban

avatar for Aki Namioka

Aki Namioka

Sr. Program Manager, Marchex
After several years of practicing Waterfall + OOAD, I was introduced to XP in 2001 at the OOPSLA conference. I have been an Agile practitioner ever since. My Agile experience has taken me through XP, Scrum, and Kanban.

Thursday August 6, 2015 09:45 - 10:15
Potomac 4


Mob Programming – My first team (Jason Kerney)
Limited Capacity seats available

As I became a member of the first real team I have ever worked on, the lessons I learned were not the ones I expected. I was the newest member of the first fully functional Mob Programming group. I got to see how good practices led by kindness, consideration, and respect allowed us to produce bug free code and happy partners. I will talk about the tools and practices we employ to be a team focused on individuals, and then illustrate how that focus keeps us one of the most successful teams I have ever seen.
Learning Outcomes:
  • Gain insight into what Mob-Programming is
  • Discover tools that might help you explore a whole-team approach
  • Understand that there is no magic bullet
  • How Mob-Programming Differs from Pair Programming
  • How Mob-Programming affected me

avatar for Jason Kerney

Jason Kerney

Agile Technical Coach, Some Company
I am a programmer, coach, father, husband and friend. I care deeply about the industry of software development and the communities surrounding it. I love to play with programming languages, yet consider it the greatest accomplishment when we address the humanness that software ultimately... Read More →

Thursday August 6, 2015 11:30 - 12:00
Potomac 4