You have successfully coached a team or two, but seem to have lost momentum in spreading agile beyond your local division. The organization’s culture seems to be pitted against you. What efforts can you take to overcome this barrier? Do you know how to assess your current organizational culture? How about manage the changes to it? According to State of Agile Survey, for two years running, the ability to change organizational ...more »
Ideas & Submissions
Lessons learned from teaching and working with distributed agile teams.
Over the last three years I have worked with teams in 9 different countries, with every possible combination of distributed structure.
This talk examines what works and what doesn't work for distributed teams and presents some practical guidelines on ways to set distributed teams up for success.
In my work with teams and organisations around the world I have come across a number of anti-patterns in Agile implementations.
This talk will identify the common patterns, likely root causes and ways to prevent/overcome them.
The prioritized product backlog is core to being agile. A well prioritized backlog allows us to satisfy the customer through early and continuous delivery of valuable software. Lean and Kanban may call it something else, but there too, prioritized work is key. At the same time, prioritizing work is an extremely difficult activity. Internal customers, non-functional requirements, investigations, proof of concepts, and ...more »
Abstract: A friction often exists between User Centered Desgin (UCD) and Agile Software Development. On the one hand we all want to design a product that considers well the needs of the people who use it. On the other we want to deliver quickly through iteration and agile methodologies. It's not very obvious how these two ideas can be integrated... but they can. This session will cover how User Centered Design and Agile ...more »
In under four years, Mylyn’s task-focused interface has gone from a university whiteboard to a tool with over a million monthly downloads. Not long ago, the notion of a tool that re-aligns the IDE around Agile collaboration and hides more of the program than it shows seemed radical. But as the task-focused interface continues its adoption, the next big step in the evolution of developer tools is becoming clear. In order ...more »
The yelling is over, the features are prioritized, the experiments are designed. Now it's time to implement. How do you transition from idea to MVP (or beta) without (1) having to throw everything away when your user base explodes or (2) getting stuck in design and architecture hell? I'll take you through an experience-based, platform-agnostic approach to creating lightweight architecture and design that is equally useful ...more »
Continuous Delivery is the current pinnacle of agile development, but what lies ahead? Grounded in my own background and current work with continuous delivery, I will explore a number of ongoing and future concepts that could change how agile development and release works to achieve even higher levels of stability. Here are brief descriptions of some of the concepts I will be exploring: - Infrastructure as code- adding ...more »
Doing > Talking. This exercise will introduce concepts of Push vs. Pull, Kanban (bottlenecks, cycle time, work-in-process limits, idle/slack time, flow), Continuous Improvement (Kaizen), and Waste
After wrestling with multiple approaches in work flow, branch per feature has emerged again in new light. Having the right tooling and skill set makes a difference to quality and the ability to deliver fast. Being able to deploy at any time is a business advantage. Rolling back only a single feature without resorting to toggles is a way to mitigate risk that superfluous code introduces. This talk will go into the how-to ...more »
Who is responsible for QA on an Agile team? The answer is “Everybody”. And yet this is rarely the case. Often the Testers write their test cases and automation in isolation and execute them after development is finished. Developers write their code without talking to the testers except to understand how to reproduce the latest discovered defect. Product Owners elaborate requirements in isolation and then hand them off ...more »
The notion of Technical Debt (TD) in software development was introduced in 1992 by W. Cunningham, and since then refined and expanded, notably by S. McConnell in his taxonomy, Martin Fowler with his 4 quadrants, J. Highsmith and I. Gat etc. As a convenient metaphor to expose many ills of software development, technical debt has received lately a lot of attention from the agile community. As a result of its success as ...more »