In my career I have been playing different roles, which allows me for looking at software development from different perspectives. First, I was an Eclipse support engineer working for IBM. This allowed me to learn about internals of Eclipse SDK and see how software development looks from a support line point of view. Later, I was a Scrum Master and a developer of image recognition technology in a startup company. This taught me how to form a team which works with Scrum and how to deal with rapidly changing requirements. After that, for couple months I was solely a Scrum Master working with several (often distributed) Scrum teams. This allowed me to validate in practice many agile concepts and learn a lot about traps and good practices concerning Scrum and agile in general. Currently, I'm a Java Technical Lead in Rule Financial where we develop Java-based systems for investment banks from all over the world. Here I code in Java and lead the agile team. After my regular working hours I was doing research in the area of software engineering, focused on requirements analysis, agile methodologies and software quality. This led to publishing some research papers, participation and speaking at many conferences and lately obtaining a PhD degree. In terms of conferences I had a chance to speak at Business Information Systems 2007, Javarsovia 2008, EmpiRE 2012 (International Workshop on Empirical Requirements Engineering) and some local meetings, including Poznań JUG. Moreover, I conducted a workshop at GeeCon 2010, taught Software Engineering at Poznan University of Technology and did several trainings in the area of requirements engineering.
1h - Slides+Speech
Rapid Feedback is one of the XP fundamental principles according to Kent Beck and other agile gurus. This is why we have short sprints, daily standups, backlog groomings and sprint retrospectives. Unfortunately, retrospectives are usually neglected as they are at the very end of every sprint, hence there is no time for it and they always look the same (so they are boring and don't provide value). However, sprint retrospectives are crucial for our agile teams and processes. Taking example from Marty McFly and Dr. Emmett "Doc" Brown we need to travel back in time in order to save our future! Marty and Doc had their DeLorean DMC-12, but what can we use to travel in time? You will find the answer in my talk. I'll share best practices of looking back at our sprints and processes in order to plan better future iterations. I'll show various activities which can be used in order to obtain valuable feedback and plan next actions. I'll talk about distinctive parts of retrospectives, I'll show real-life examples, also for distributed teams, and tell you what can kill and save every retrospective meeting. The talk will be based on my experience I gained working with agile teams. If possible we will even conduct a retrospective with the audience during the talk.
The talk is targeted at every member of an agile team and it doesn't require any specific knowledge.
The initial outline of the talk is following:
1. Introduction to agile principles with the emphasis on feedback.
2. Ingredients of every retrospective : setting the stage. gathering data, generating insights, decision making and closing
3. How to engage your team?
4. Activities and tools which will make your retrospectives more effective.
5. Dos and Don'ts
5. When we can be satisfied with our retrospectives?
6. Distributed retrospectives.