Lean and Agile Product Development
These are the confirmed speakers on the Lean and Agile Product Development track.
Jabe Bloom: Alternate Visualization
One of the Kanban Method’s most interesting principles: “Visualize the Workflow” is generally interpreted as creating and maintaining a Kanban Board. I propose, as my presentation, an experience report detailing our implementation of an alternate workflow visualization system for a customer support department. I will discuss visualization patterns and context in high flow systems and compare them against traditional software development visualization (Kanban boards). I would also present my company’s “Support Floor” visualization. In doing so, I hope to encourage a discussion on other contexts and processes that would benefit from alternate visualizations.
About: Jabe Bloom is an avid Systems Thinker. He plays with ideas, usually in the form of creative software, though often in the form of convincing others to create software. He should be making more photographs, but finds lame excuses not to. Jabe is currently CTO at The Library Corporation. He has more than 15 years experience leading and coaching software development and support teams, during which time he has been involved in all aspects of product development and business management.
Torbjörn Gyllebring: Kanban is not your process (let me tell you why)
Intended audience: Kanban practitioners or beginners transitioning & searching for a meaningful way to explain and articulate what they’re doing without retorting to “We used to do Scrum but now we do Kanban”
Goal: Lay a solid foundation & positioning Kanban in it’s right place relative to other methodologies and tools.
Outline: The explosive growth of the Kanban community and the buzz surrounding it has given raise to a steady stream of questions regarding its relation to other approaches and tools. Many with agile backgrounds expect to find a highly opinionated & pre-packaged methodology akin to Scrum, XP or the Crystal family. The profusion of “Scrum vs Kanban” themed blogs and discussions perpetuates such beliefs often missing some of the fundamental flaws in the comparison. It is inherently an apples to oranges type of comparison that can be illustrated with the following core properties:
- Kanban is not your process – it’s part of your process & a meta process for improvement and guided evolution. Once a process (even an ad-hoc seat of the pants one) has been established applying Kanban to that process will help guide the further evolution and tailoring to your context.
- You can’t start with Kanban – you need a process to apply it to. If you’re starting from a clean slate many good well understood & tried processes exist The Crystal family, XP & Scrum for agile folks, RUP, PROPS and others for those that must. Kanban really doesn’t care.
- Kanban doesn’t care if you have lunch – the relative merit of roles & procedures does not make them part of Kanban. Kanban doesn’t prescribe roles or organizational design but guides your discovery in context
- How Kanban guides evolutionary change leading to revolutionary results
Each of these points will be illustrated by a ~10minute slice with the aim to establish the main point and a short discussion on how that relates to other well known processes and why and when comparison makes more or less sense.
About: Torbjörn has spent the last 15years trying to make software work. The search has taken him from assembly coding to management, his coder mind busily searching for patterns and structure in ideas old and new. His heart pushing onwards to discover not only better ways to ‘deliver value’ but to do so in ways that realizes the full potential of everyone involved. He’s currently the European Development Manager at Cint.
Staffan Persson: Empowering product development through distribution of decision making
People involvement is the fundament of Lean. And it’s also the fundament of innovate product development. Applying Lean thinking should be the perfect way to drive value in product development. Scania has for over 20 years applied Lean throughout the organization. Some of it adopted, mainly from Toyota, other originating from our own history and traditions. Staffan talks on how Lean thinking is applied at Scania, and how to enable distributed decision making in a product development organization. Using examples from product development at Scania to discuss how to apply these ideas in a more general product development context.
About: Staffan is currently Head of Applications for Production and Diagnostic Follow Up within Scania R&D in Sweden. Previous experience includes being the system architect for the overall functional architecture of in vehicle electronics and software, with a lot focus on how to drive and sustain a good product architecture and overall product properties within a Lean development environment. Staffan is drawing from years of experience as a former consultant within software development in major industrial organizations.
Ken Power: Product Ownership Challenges in Large Organizations
Product Ownership is a multi-faceted responsibility that demands a broad set of perspectives combined with deep product and domain knowledge. Effective product ownership requires both an internal and an external perspective. The challenges are amplified for large complex organizations developing large complex products and systems. In different organizations, engineering, product management, user experience and other functional groups can all lay claim to the role with some legitimacy.This talk will describe the challenges of understanding product ownership in large organizations, and of filling the product owner role effectively. We present different models for filling the product owner role, including single product owner, proxy product owner, and product owner teams.
We will describe cases where these models have worked well, and also cases where they have not worked. Understanding barriers and challenges to effective product ownership is helpful, and we will talk about some pitfalls to avoid and some hard-won lessons learned. We will also discuss some case studies of effective product ownership and describe some of the principles that have contributed to their success.
About: Ken is an internal Agile-Lean Coach/Consultant and co-founder of the Agile Office at Cisco Systems’ Unified Communications Business Unit. He works with global product teams and the organization’s leadership, navigating a path through their agile and lean journey.
Frode L. Odegard: Becoming a Lean Leader: What Can and Will Go Wrong
The Lean Journey is not an easy one. Leaders who embark on a quest to turn their companies into “Learning Organizations” face a number of obstacles, many of which seem unavoidable. Since its founding in 2004, the Lean Software Institute has accumulated a long list of challenges IT/software executives face when introducing Lean.
These challenges include harmful leadership behaviors, perceived conflicts between Lean and the business model, silo boundaries, unhelpful bonus schemes, intellectual dishonesty, internal misalignment, poor business literacy among employees, insufficient leadership involvement, leaders doing too much, under/overestimating the organization’s change capacity, and poor knowledge management. Success also brings its own risks, such as employees holding leaders to a higher standard and then leaving the organization when leaders fail to raise their game. In this talk we will discuss what leaders can do to detect and meet these challenges, and how they can transform themselves in the process.
About: Frode has more than twenty years of experience as an entrepreneur and trusted advisor to high-tech executives. Organizations he has helped include Sony Electronics Inc., Lockheed Martin, Honeywell Aerospace, and Plantronics. Frode is currently writing a book on Lean transformations for software executives.
Before founding the Lean Software Institute in 2004, Frode was the CEO and founder of Odegard Labs, Inc., a for-profit software engineering research lab and consulting firm. Prior to founding Odegard Labs in 1991, Frode was the CEO and founder of Modula-2 CASE Systems A/S, a Norwegian company building next-generation tools for embedded software developers. In 2010, Frode also founded a global incubator for new startups, Odegard adVentures. His interests outside work include history, philosophy, psychology, theoretical computer science, travel, linguistics, and strength training. You can follow Frode on Twitter @odegard
Marcus Hammarberg: Theory of Constraints and Specification by Example
Since the first time I heard about Specification by example (or BDD if you like) I have had this nagging feeling that it fits like a glove with Lean thinking and the theories surrounding those ideas, but I haven’t been able to figure out how or why. Now I have had some time to think hard about that and I think I found a connection. The connection I saw was how theory of constraints can be applied with the use of Specification by example to the system development process itself. This session aims to show how the use of Specification by example can help you to find and manage bottlenecks in your development process.
About: Marcus has worked as consultant with system development since 1998. During this time he has mostly been working within the Microsoft-area and almost always been in the team lead role. This has led him in to try to investigate and learn new technologies that help team-based system development run smother and produce more qualitative software. Marcus enjoys working agile (with Scrum and Kanban) and using techniques such as Specification by example/BDD, TDD and CI to achieve these goals.
Håkan Forss: Standard work in software development
A cornerstone for continuous improvement in Lean is standard work. Standard work is a description of how a process should operate. Without standard work it is much harder to know if process changes are improvements or not. Implementing standard work in a manufacturing process with repetitive task sounds reasonable but how do you implement standard work in something as variable as software development where there is basically no repletion of tasks? In this Lightning Talk you will be shown an example of how standard work was used in a software technology migration project. The intended audience is managers, team leaders and coaches working with process improvements.
About: Håkan Forss works for Avega Group in Stockholm as a Lean/Agile Coach. Håkan Forss has more than 15 years of experience in the IT industry and his main focus today are Lean/Agile coaching, system architecture and development. He has a great passion for applying Lean and Agile values and tools to continuously improving your people, processes and business.
Håkan Forss also works on Kanban OSS project http://visualwip.codeplex.com
Pim Witlox: Managing Agile Development
Agile is one of the hottest topics in Software Development since the introduction of Rational Unified Process. It is a unification of a set of development techniques that provide the best possible Return on Investment. Agile employs techniques from Lean and JIT (Just in Time) to provide the fastest marketable products. The main question this research tries to answer is; what is needed to create an efficient management environment to support an Agile Development Process? The results found during this research can be found in the first part of this paper; there are some major requirements for successful implementation of this type of development process, summarized; the organization wanting to implement Agile should already be a Lean organization. A sub question that was raised during the research of this topic was; when should a company not try to implement Agile? When an organization cannot adhere to the requirements stated in Table 1, it is going to be very difficult to start an Agile Process or to keep it running smoothly. Also the practical applicability of an Agile Software Development Process was researched and an internal study of part of the Philips organization was performed to link the theory to application.
Topic specific information was researched by means of case study analysis, literature review and by means of interview. The other methods used for research were statistical analysis, data mining and market observations. This paper explains what Agile is, why it is a hot topic and how an organization can implement it. By means of case study analysis and literature review describes the strengths and weaknesses of this kind of development process. It also gives reference to an organization (Philips S.E.S.) already implementing Agile successfully and a way of changing to such an organization.
About: Pim Witlox is a 30 years old Dutch software developer who lives and works in Delft. MSc in information systems and have actively worked in the IT industry since 2000. Currently work at Deltares; a leading independent Dutch knowledge institute for delta technology.
Mike Burrows: Beyond the development system
What do Lean, Kanban, Systems Thinking, Complexity Thinking and Beyond Budgeting have to say about external influences on the software development process? Would they encourage us to approach the development system differently? Through a parallel case study experiment we hope to draw some essential lessons from each school of thought.
About: Mike has led development teams and larger IT functions for much of his career, working in aerospace, software tools, finance and energy, recently as Executive Director at UBS Investment Bank and then IT Director at the energy risk management consultancy Encore International where he led one of the first Kanban implementations in Central Europe.
Gabor Gunyho: Stop the Line + Stop Feature Development, ways to improve quality and speed in a large-scale project
Stop The Line (STL) is a practice done by agile teams and organizations in order to assure a high quality level in their software. This practice comes from the Lean manufacturing world. Toyota, in its Toyota Production System (TPS), defined the stop the line events whenever an error was found in the production system. The whole production line was stopped so that the defect could be fixed immediately, thus preventing it from flowing downstream on the line where detection and fixing would be more difficult and costly. This is followed then by systematic root cause analysis to prevent the problem from re-occurring.
In Lean Software Development or Agile Software Development in general, this is translated to stopping the building of new functionality if an error is found in the system by continuous integration (CI) -and thus, test automation (TA)- but also by manual testing. Therefore, the focus is put on fixing the bug immediately. The definition of “line” for the software development industry is, usually, more complex and sophisticated than in manufacturing and, thus, a more fine-grained approach to stopping certain parts of the system is used.
This paper shows how F-Secure handles the STL cases and study the relationship between the usage of a targeted STL practice with an addition of a threshold to trigger a stop on the feature development. Basically, a STL event is raised for bugs which break any of the automated tests or critical bugs which affect a specific part of the system (subsystems or software lines). Consequently, the development of any new feature for that specific line stops and the focus goes to finding and fixing those bugs that caused the failure.
Additionally, if defects are not breaking the automatic tests or are not critical enough (but still important enough so they cannot be trashed), they are not immediately handled but added to the defect list. In this scenario, a threshold on the number of defects is set to raise a Stop Feature Development (SFD) event -stopping completely any new feature development- if the number of defects per team or the number of bugs globally reaches a certain limit. On the team-level SFD events the development of any new feature in that team stops until the bug count for that team goes, comfortably, below the team limit. For global SFD (project wise) events, the whole project is handled correspondingly, with the overall bug count reduced under the project limit.
This study also compiles a set of statistics on how these practices changed the quality of the software over time. The project under study is a multi-site set up (Finland, Malaysia and Poland) formed by 10-12 teams (about 100 persons in total) over 18 months. The metrics analysed are, among others, number and duration of STL events over time, ageing of the defects, root causes of selected events, number and size of the commits, variation of the number of defects over time, etc. The statistics clearly indicates that the situation has changed significantly after the introduction of these practices. After some adjusting and learning period, the overall quality of the software increased and the time to develop new features decreased. This report shows how F-Secure got these results by using these two practices, among others, in a quantitative manner.
About: Gabor Gunyho currently works as a Lean Change Agent at F-Secure Corporation. Among his specialities are: Agile SW development, scaling Scrum to large teams, Lean product development, corporate level product development process frameworks, systems thinking, complexity theories.