Way too often is Kanban portrayed as an agile, flow based development process close to the classical waterfall competing with Scrum. Kanban is supposed to unite all the advantages that waterfall processes offer (like clearly defined responsibilities, working in specialization, and all of that really efficiently!) with the agility of Scrum. You’re successful, however, without planning, estimation, nobody hast o leave their comfort zone. Awesome, isn’t it!? But that isn’t really Kanban. It’s just FAKE – False, accumulated Kanban expectations. Kanban is, contrary to a lot of expectations, a evolutionary change management method. A central aspect of this method is the establishment of a work-in-progress limited pull system. Through this system, demand is approached to the real system capacity. Limiting the work-in-progress and the other five core practises create a pressure for change. The four principles support changing the system evolutionary and collaboratively. The basics of Kanban – principles and practises – will be presented and discussed during this talk. It is directly especially at an audience with no or little knowledge of Kanban as a change management method. Kanban can be implemented deeply or, the majority of implementations I see, in a shallow way. Therefore, members of the audience who are already using visualization as a first practice should be able to take away fresh impulses.
f you are struggling to forecast project delivery dates and cost, or you want to eliminate the story estimation process because you feel it is waste, or you need to build the business case for hiring more staff, then this session is relevant to you. All estimates have uncertainty, and understanding how multiple uncertain factors compound is the first step to improving project and team predictability. A major benefit of Lean is the low weight capture of cycle time metrics. This session looks at how to use historical cycle time data to answer questions of forecasting and staff skill balancing. This session compares the benefits of using cycle time for analysis over current planning techniques such as velocity, burn-down charts, and cumulative flow diagrams. This session takes you on a journey of what to do after capturing cycle time data or what to do if you have no history to rely upon. Reducing reliance on developer estimation (popularized by the twitter hashtag of #NoEstimates movement) is good general advice, having the tools to plan and manage teams and projects is still important to maintain support at the executive level. This session details the approaches to getting the numbers you need to have whilst minimizing un-necesary overhead and estimating ONLY this factors that matter most.
We all seem to love the term 'continuous improvement' - which is an honourable intention. But in reality 'continuous improvement' can be hell on earth - e.g. to always be 'not good enough'. In fact, some corporations, managers and teams have been known to use this phrase as an excuse for behaving badly. So, how can an honourable intention like continuous improvement create a negative impact, ie. apathy? If so - how do we avoid it? What are other ways of handling this need to consistently overcome challenges in an ever-changing industry? And does 'continuous improvement' have a limit or is it an endless source of success? Using case study examples this talk reflects on what continuous improvement really feels like on the ground and explores how we might want to approach 'getting better' by looking at and drawing from other industries, research, ideas and real-life experiences.
Let’s talk for a short while about how we build our teams. Best technical talent that we can find. Good engineering practices. Craftsmanship. Aren’t we full of that stuff? Oh yes, we are. And that’s exactly the problem. Building software is a team sport. So the question is: what does make a team effective? Once the question is answered we may want to rethink the way we build our teams.