Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Improving delivery capability with Scrum - 2012

Motivation to move from a waterfall to an agile development cycle and to compare your agile method transition to high velocity improvement framework. Most agile methods focus on team level work flow management where as HVO principles work for all.

Rolf Häsänen

on 19 April 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Improving delivery capability with Scrum - 2012

Usual change driver Increase delivery capability 1. Many different methods exist Scrum Agile XP FDD CMM Cleanroom Crystal Zero Defects RUP TDD Lean Six Sigma Spiral Transitioning from phased gate
Agile software delivery 2. Choosing a method Fact based Comparing methods The trendy method I like this one Recommended by
a consultant tailor method for
your organisation Easy Hard 3. Learning the method Good news - research shows that companies sticking to better methods show clear improvements Bad news - you actually need to stick to your method learn & experiment. Effort is not the same dependent on what method you choose. Understanding your
transition experience High Velocity Organisation
foundation framework has two aspects to it. Organisation and development dynamics Scrum pros and cons 1. Each organisation has its own
characteristics which means improvements
need some measure of innovation and adaption! "Innovation is learneable, teachable & disciplined set of skills" Foundation Elements 1 law - 3 ideas - 4 principles Optimize the whole system
not the parts The system is human based
not tools, project or program
based. Organization structure is for
learning & administration
not power & control Leverage is in the number and
frequency of changes, not in
any particular change. Understand the Customer. People link the system Continuous improvement,
Everybody, Everyday Go see the problem!
(fact based problemsolving) Simple but not Easy Organisational preparedness Scrum needs more people with higher competence
compared with plan driven approaches. What is the impact on your organization? Goal of Scrum is to have self organising teams with a lot of latitude in decision making and problem solving. Is this acceptable in your organisation? Focusing on fast delivery through the whole value chain means shifting from optimizing resource utilization to optimizing value flow. Managment discussions need to shift focus - are you aware of this? Agile methods do not commit to whole scope.
Will it be understood that in order to
deliver highest value for specific release, scope needs to be flexible. Are you prepared for this discussion with stakeholders? Organization need to focus on scheduling release trains and feeding the development teams with
requirements. Does organization have mechanisms
in place to prioritize and clarify business needs with needed cycle time? Scrum cannot be implemented it needs to be learned, expectations must be managed. Are you
prepared to stay the course? Scrum roles require more multiskilled people that take ownership of the resulting functionality. How will this impact current roles and responsibilities? Development dynamics You must focus on quality to drive down cost and time.
-People need to focus, no multitasking
-Test automation is crucial
-Testing is not enough, build competence,
do pairprogramming, evaluate technical
debt. Transparancy is important.
-Visual management of the whole value chain.
-Visual management for teams. You need to build up a help chain for rapid dealing with issues all the way up in the organisation. Business stakeholders need to participate closely both before, during and at the end. Are they prepared to do this? Scrum teams contain all needed skills to finish work. Analysts, developers and testers. 4 times shingo winner, Crosby winner Scrum adresses several issues about development dynamics. Plenty of learning materials exist
about Scrum High focus on improvment Improvement of capacity
and quality is ensured in
long term. There is a lot of assumptions & beliefs about scrum. Refactoring is cheaper than big design up front Scrum does not use documentation For large scale development it is easy to discard needed supportive tools and
processes when transitioning to scrum. Scrum exposes organisational
shortcomings = improvment
possibility. TQM ToC Release trains are not adressed by scrum 2. Continuous Improvement methodology, principles, and mindset are global and reusable Don Kieffer, Senior Lecturer MIT Then you get to select a method,
"hyper performance" is "guaranteed" True enough
if you Innovate
and continually improve The rage in 80ies; passé in 90ies.
But companies that stuck with TQM have today
outperformed their compatitors! All improvment methods build
on old knowledge. Freshly packaged
and with a new acronym or name.

Statistical Process Control became
Six Sigma
Quality circles became High-Performance
work teams. The ability to identify and learn about new improvement methods no longer presents a significant barrier.
Instead it is the implementation of innovation that is the BIG challenge. You cannot buy a world class TQM program or a turnkey Six Sigma program nor a Agile process.
It must be DEVELOPED from WITHIN! This is called the
IMPROVEMENT PARADOX Learning a new way of working and improving things also means that some things must be stabile
and non changing. What happens in your organization when a new project manager comes in? 1. Learn & Stabilize 2. Improve & Innovate Keep your stakeholders close and informed
-perform demonstrations
-set up demo environments Handle complexity by dividing work into small chunks that can be developed, tested in and delivered in a sprint Engineer stability in and chaos out. Learn and discover the constraints of your processes and your organisation. Stabilise the key processes so that the wheel is not invented over and over again User stories and epics Normal scrum practices of splitting epics to user stories does not support large complex functionality where
context is important to
understand the whole. Management focus Balance refactoring with up-front design Definition of Done Definition of Done needs to support the principle of finalizing a work item. Management needs to
ensure that processes between organisational
units support the overall
goal and principles.

Responsibility is to see the
whole system and ensure that local optimization does not harm the overall system This requires re-learning
among management and
project members alike. Specifying design to capture existing knowledge and building tests to reveal problems Swarming and solving problems to build new knowledge Sharing new knowledge
throughout the organisation “For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. ” – Richard P. Feynman Handle complexity Minimize variety Main focus in Scrum is to break down
work items into User Stories than can
be completed in one sprint. Standardize Transparant Change ad-hoc and chaotic work to
repeatable procedures and processes. Visual management on all levels. Scrum
has a good starting point for this but
for complex environments other
industries have come further with
concepts like Oobeya. Scrum acknowledges that decreasing complexity provides a more controlled way of working. Some support exists. Rolf E. Häsänen
www.valueatwork.se By whomever is pushing the method The foundation Challenges Scrum details Steven J. Spears,
Senior lecturer MIT VP Operational Excellence Harley Davidson Actionable Transformation sequence 1. 2. Good engineering practices are equally important
as the scrum framework
Full transcript