Most Lean/Agile team have had limited success in establishing a culture of Continuous Improvement. Retrospectives are done but in most cases they are done without a goal, a vision. Toyota Kata, as codified by Mike Rother, is an approach to put an culture of Continuous Improvement in a team/organization.

This full-day workshop focuses on applying Agile engineering practices to web development. We'll look at practices such as build automation, continuous integration, test-driven development, refactoring, and incremental design and see how to apply them to front-end web development. We'll cover topics such as cross-browser testing, JavaScript, and CSS.

Audience: This session assumes familiarity with Agile engineering practices such as test-driven development and refactoring. Experience with JavaScript, CSS, and other web technologies is recommended. Come prepared to code.

How fast can you go from an Idea to Reality?

From an idea to the time you validate your solution with real users - not friends and family, how long does it take?
In case you are yet to start, how long should you take?

Lean Startup is a buzz-word these days. And for a good reason too - it works! But, there may be times when you get hung-up trying to validate with methods like landing pages, MVPs, MVFs and Interviews. And before you know it, a month has passed by, trying to generate traffic to your landing pages, making sense of analytics and polishing your MVP. 

The Google Ventures' Design Sprint is a framework for solving real-world problems through research, ideation, prototyping and talking to real users, in 5 days or less.

How will Design Sprint help?

• Focus. First off, design sprint will put you on the clock. 3-5 days of complete immersion. 
• Build the right thing. Taking a Design Thinking approach inspired by IDEO, will help you look at the problem the way your customer would. Then user your teams creativity to solve it in unique ways. 
• See the Truth. When you'll put the prototype to test in the hands of a real user, your team will see first-hand what works and what doesn't. It's the next best thing to reading your customer's minds.
• With a couple of days still left in the week, you relax with a cup of Earl Grey tea and do some more thinking. Probably, get ready for the next sprint.

When we conducted design sprints with our customers, we had some unexpected realizations:

• We saw that the ownership and motivation in the team improved significantly.
  They were mindful about "why" they were working on the features they were working on.
• Our customers would say, "This has completely changed the way I think about building products." 
  Going from a solution driven approach to problem-first approach and keeping the products very lean.

This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.

A Slicing Heuristic is essentially:

An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.

The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle.

It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.

This talk will equip teams and organisations who are established on their Agile journey with a robust, clear and repeatable method for improving the quality and time-to-market of their software development efforts.