Agility is the tool gilb vilnius 9 dec 2013
Download as PPTX, PDF•4 likes•1,761 views
The document discusses practical agile systems engineering tools and principles, emphasizing that agility should serve as a tool to achieve prioritized results rather than the primary focus. It highlights the importance of a disciplined approach to agile methodologies, stressing the need for stakeholder involvement, effective prioritization, and the integration of results-driven values. Additionally, it outlines common pitfalls in agile methods and offers strategies for successful implementation, including effective decomposition of projects into manageable steps.
![
Example of one of the Objectives:
Customer Service:
Type: Critical Top level Systems Objective
Gist: Improve customer perception of quality of
service provided.
Scale: Violations of Customer Agreement per
Month.
Meter: Log of Violations.
Past [Last Year] Unknown Number State of
PERSCOM Management Review
Record [NARDAC] 0 ? NARDAC Reports Last
Year
Fail : <must be better than Past, Unknown
number> CG
Goal [This Year, PERSINCOM] 0 “Go for the
Record” Group SWAG
www.Gilb.com
December 9, 2013
Sli
de
16](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-16-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
40](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-40-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
of developing a
design, estimating its
cost, and ensuring that
the design is costeffective
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
41](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-41-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
iteration process
trying to meet cost
targets by either
redesign or by
sacrificing 'planned
capability’
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
42](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-42-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
Design is an
iterative process
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
43](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-43-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
but they iterate through a series of
increments,
thus reducing the complexity of the
task,
and increasing the probability of
learning from experience
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
44](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-44-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
an estimate to
complete the remaining
increments is
computed.
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
45](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-45-320.jpg)
![
“Software Engineering began to emerge in FSD” (IBM Federal Systems
Division, from 1996 a part of Lockheed Martin Marietta) “some ten years ago [Ed.
about 1970] in a continuing evolution that is still underway:
Ten years ago general management expected the worst from software projects –
cost overruns, late deliveries, unreliable and incomplete software
Today [Ed. 1980!], management has
learned to expect ontime, within budget, deliveries of high-quality software. A
Navy helicopter ship system, called LAMPS, provides a recent example. LAMPS
software was a four-year project of over 200 person-years of effort, developing over
three million, and integrating over seven million words of program and data for eight
different processors distributed between a helicopter and a ship in 45 incremental
deliveries [Ed. Note 2%!]s. Every one of those deliveries was on time and under
budget
A more extended example can be found in the NASA space program,
- Where in the past ten years, FSD has managed some 7,000 person-years of
software development, developing and integrating over a hundred million bytes of
program and data for ground and space processors in over a dozen projects.
- There were few late or overrun deliveries in that decade, and none at all in the past
© Gilb.com 2011 09 December 2013
47
four years.”](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-47-320.jpg)
![
“Software Engineering began to emerge in FSD” (IBM Federal Systems
Division, from 1996 a part of Lockheed Martin Marietta) “some ten years ago [Ed.
about 1970] in a continuing evolution that is still underway:
Ten years ago general management expected the worst from software projects –
cost overruns, late deliveries, unreliable and incomplete software
Today [Ed. 1980!], management has learned to expect on-time, within
budget, deliveries of high-quality software. A Navy helicopter ship system, called
LAMPS, provides a recent example. LAMPS software was a four-year project of over
200 person-years of effort, developing over three million, and integrating over
seven million words of program and data for eight different processors distributed
between a helicopter and a ship in 45 incremental deliveries [Ed. Note 2%!]s. Every
one of those deliveries was on time and under budget
A more extended example can be found in the NASA space program,
- Where in the past ten years, FSD has managed some 7,000 person-years of
software development, developing and integrating over a hundred million bytes of
program and data for ground and space processors in over a dozen projects.
- There were few late or overrun deliveries in that decade, and none at all in the
past four years.”
in 45 incremental deliveries
were few late or overrun
deliveries in that decade,
and none at all in the
past four years
© Gilb.com 2011
09 December 2013
48](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-48-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the
design is cost-effective.' (p. 473)
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won
as each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No.
4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
49](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-49-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
of developing a design,
estimating its cost, and
ensuring that the design
is cost-effective
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
50](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-50-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
iteration process
trying to meet cost
targets by either
redesign or by
sacrificing 'planned
capability’
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
51](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-51-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
Design is an
iterative process
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
52](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-52-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
but they iterate through a series of
increments,
thus reducing the complexity of the
task,
and increasing the probability of
learning from experience
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
53](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-53-320.jpg)
![Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met.
'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management
farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an
integrated way to ensure that software technical management is consistent with cost management. The method
[illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design
is cost-effective.' (p. 473)
an estimate to
complete the
remaining increments
is computed.
He goes on to describe a design iteration process trying to meet cost targets by either redesign or by
sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the
'development of each increment can proceed concurrently with the program design of the others.'
'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474)
It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in
seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of
increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as
each increment develops, and as the true cost of the increment becomes a fact.
'When the development and test of an increment are complete, an estimate to complete the remaining increments is
computed.' (p. 474)
Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77
This text is cut from Gilb: The Principles of Software Engineering Management, 1988
Copyright Tom@Gilb.com 2013
9 December, 2013
54](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-54-320.jpg)
![Restore Speed:
Type: Software Quality Requirement. Version: 25 October 2007.
Part of: Rock Solid Robustness
Ambition: Should an error occur (or the user otherwise desire to do so), the
system shall be able to restore the system to a previously saved state in less
than 10 minutes. <-6.1.2 HFA.
Scale: Duration from Initiation of Restore to Complete and verified state of a
defined [Previous: Default = Immediately Previous]] saved state.
Initiation: defined as {Operator Initiation, System Initiation, ?}. Default = Any.
Goal [ Initial and all subsequent
released and Evo steps] 1 minute?
Fail [ Initial and all subsequent
released and Evo steps] 10 minutes.
<- 6.1.2 HFA
Catastrophe: 100 minutes.
www.gilb.com
December 9, 2013
68](https://image.slidesharecdn.com/agilityisthetoolgilbvilnius9dec2013-131209064220-phpapp01/85/Agility-is-the-tool-gilb-vilnius-9-dec-2013-68-320.jpg)
Agility is the tool gilb vilnius 9 dec 2013
- 1. ‘Agility is the TOOL, not the Master’ : Practical Agile Systems Engineering Tools including My Ten Key Agile Principles and several case studies Tom Gilb “ Build Stuff 13, 9.12.2013 Monday 1600-1700, Vilnius, Lithuania, #BuildStuffLT [email protected] @imtomgilb www.gilb.com These slides are on gilb.com downloads, and twittered at #BuildstuffLT The Talk was videoed. Paper: Value-Driven Development Principles and Values – Agility is the Tool, Not the Master July 2010 Issue 3, Agile Record 2010 (www.AgileRecord.com) http://www.gilb.com/tiki-download_file.php?fileId=431 And a folder with pdf pptx and paper https://www.dropbox.com/sh/npgauiu85fhtz3h/DrLcPi9vgy Simpler 1 December 9, 2013 http:// © Gilb.com tinyurl.com/AgileSGGilb Agility is the Tool
- 2. Defining ‘Agile’ • “Any set of tactics that enable a prioritised stream of useful results, in spite of a changing environment” – TsG 7 June 2013 • A focus on ‘Agile’, is the wrong level of focus. – Using agile tactics that ‘work’, is a good idea. • Focus on results, no matter what. • As a government minister, I was asked to give ideas to, put it “Value for Money” Monday, 09 December 2013 © Gilb.com 2
- 3. Stakeholders Learn Measure Values Value Management Process Deliver Solutions Develop Monday, 09 December 2013 Copyright: [email protected] Decompose © Gilb.com 3 3
- 4. Stakeholders Learn Measure Values Value Management Process Deliver Solutions Develop Monday, 09 December 2013 Copyright: [email protected] Decompose © Gilb.com 4 4
- 5. Agile World View “Agility” has many dimensions other than IT It ranges from leadership to technological agility The focus of this brief is program management agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting F Agile Strategic Planning Agile Capability Analysis E Agile Program Management Agile Project Management Agile Systems Development Agile Processes & Practices Agile Tools Agile Information Systems Monday, 09 December 2013 Agile Tech. © Gilb.com Source: David Rico 5 5
- 6. Agile Recap Agile methods DON’T mean deliver it now & fix it later Lightweight, yet disciplined approach to development Reduced cost, risk, & waste while improving quality What Use lightweight, yet disciplined processes and artifacts Low work-in-process Customer Involve customers early and often throughout development Early feedback Prioritize Identify highest-priority, value-adding business needs Focus resources Descope Descope complex programs by an order of magnitude Simplify problem Decompose Divide the remaining scope into smaller batches Manageable pieces Iterate Implement pieces one at a time over long periods of time Diffuse risk Leanness F F F F Result Flexibility F F F F How Architect and design the system one iteration at a time JIT waste-free design Swarm Implement each component in small cross-functional teams Knowledge transfer Collaborate Use frequent informal communications as often as possible Efficient data transfer Test Early Incrementally test each component as it is developed Early verification Test Often Perform system-level regression testing every few minutes Early validation Adapt Frequently identify optimal process and product solutions Improve performance E E E E E E E E Source: Rico, D. F. (2012). What’s really happening in agile methods: Its principles revisited? Retrieved June 6, 2012, from http://davidfrico.com/agile-principles.pdf David Rico Rico, D. F. (2012). The promises and pitfalls of agile methods. Retrieved February 6, 2013 from Monday, 09 December 2013 & agile intersect? Retrieved February 6, 2013, from http://davidfrico.com/agile-concept-model-3.pdf © Gilb.com Rico, D. F. (2012). How do lean 6 6
- 7. 14 PITFALLS OF AGILE METHODS ● Change – Use of top-down, big-bang organization change, adoption, and institutionalization. ● Culture – Agile concepts, practices, and terminology collide with well-entrenched traditional methods. ● Acquisition – Using traditional, fixed-price contracting for large agile delivery contracts and projects. ● Misuse – Scaling up to extremely complex large-scale projects instead of reducing scope and size. ● Organization – Unwillingness to integrate and dissolve testing/QA functional silos and departments. ● Training – Inadequate, insufficient, or non-existent agile training (and availability of agile coaches). ● Infrastructure – Inadequate management and development tools, technologies, and environment. ● Interfacing – Integration with portfolio, architecture, test, quality, security, and usability functions. ● Planning – Inconsistency, ambiguity, and non-standardization of release and iteration planning. ● Trust – Micromanagement, territorialism, and conflict between project managers and developers. ● Teamwork – Inadequate conflict management policies, guidelines, processes, and practices. ● Implementation – Inadequate testing to meet iteration time-box constraints vs. quality objectives. ● Quality - Inconsistent use of agile testing, usability, security, and other cost-effective quality practices. ● Experience - Inadequate skills and experience (or not using subject matter experts and coaches). • (Note. Firms may prematurely "revert" to inexorably slower and more expensive traditional methods or "leap" onto lean methods that may not adequately address common pitfalls of adopting agile methods.) • Source: David Rico http://davidfrico.com/agile-pros-cons.pdf 2012 Monday, 09 December 2013 © Gilb.com 7
- 8. + 8 System Owner Stakeholders Values Business Values System Functions Product Owner Build Test Maintain © Gilb.com Agility is the Tool Detailed Technical Design December 9, 2013
- 9. + Value Decision Tables Business Goals Profit Market Share Resources Training Costs -10% 50% 20% Stakeholder Val. Training Costs User Productivity Resources Intuitiveness -10% 10 % 2% Product Values Intuitiveness Performance Resources Performance 50 % 10% 5% GUI Style Rex -10% 50% 1% Prioritized List 1. Code Optimize 2. Solution 9 3. Solution 7 © Gilb.com Agility is the Tool Copyright: [email protected] User Productivity 40% 10% 10% Jeffsutherland Twitter: Very cool product backlog management by Tom and Kai Gilb http://ad.vu /2h4d Sat 28 March 2009 Code Optimize 40% 80 % 2% Scrum Develops We measure improvements Learn and Repeat December 9, 2013 9
- 10. + 10 Jeffsutherland Twitter: Very cool product backlog management by Tom and Kai Gilb http://ad.vu/2h4d Sat 28 March 2009 © Gilb.com Agility is the Tool Copyright: [email protected] 10 December 9, 2013
- 11. 1. Control projects by quantified critical-few results. 1 Page total ! (not stories, functions, features, use cases, objects, ..) 2. Make sure those results are business results, not technical Align your project with your financial sponsor‟s interests! 3. Give developers freedom, to find out how to deliver those results 4. Estimate the impacts of your designs, on your quantified goals 5. Select designs with the best impacts in relation to their costs, do them first. 6. Decompose the workflow, into weekly (or 2% of budget) time boxes 7. Change designs, based on quantified experience of implementation 8. Change requirements, based in quantified experience, new inputs 9. Involve the stakeholders, every week, in setting quantified goals 10. Involve the stakeholders, every week, in actually using increments Copyright 2004-13 Gilb, may be used citing source © Gilb.com Agility is the Tool December 9, 2013 11
- 12. Main Idea: Get early, and frequent, real, stakeholder net-value - delivered Deliv er Value ! © Gilb.com Agility is the Tool December 9, 2013 12
- 13. (not stories, functions, features, use cases, objects, ..) © Gilb.com Agility is the Tool December 9, 2013 13
- 14. Real Example of Lack of CLARITY Defined Scales of Measure: ◦ Demands 1. Central to The Corporations business strategy is to be the world‟s premier integrated <domain> service provider. thinking. ◦ Leads to requirements that are unambiguously clear ◦ Helps Team be Aligned with the Business 3. Dramatically scale back the time frequently needed after the last data is acquired to time align, depth correct, splice, merge, recompute and/or do whatever else is needed to generate the desired products comparative 2. Will provide a much more efficient user experience 4. Make the system much easier to understand and use than has been the case for previous system. 5. A primary goal is to provide a much more productive system development environment than was previously the case. 6. Will provide a richer set of functionality for supporting nextgeneration logging tools and applications. 7. Robustness is an essential system requirement (see rewrite in example below) 8. Major improvements in data quality over current practices This lack of clarity cost them $100,000, 000 © Gilb.com Agility is the Tool December 9, 2013 Sli de 14
- 15. www.Gilb.com Version December 9, 2013 Sli de 15
- 16. Example of one of the Objectives: Customer Service: Type: Critical Top level Systems Objective Gist: Improve customer perception of quality of service provided. Scale: Violations of Customer Agreement per Month. Meter: Log of Violations. Past [Last Year] Unknown Number State of PERSCOM Management Review Record [NARDAC] 0 ? NARDAC Reports Last Year Fail : <must be better than Past, Unknown number> CG Goal [This Year, PERSINCOM] 0 “Go for the Record” Group SWAG www.Gilb.com December 9, 2013 Sli de 16
- 17. Align your project with your financial sponsor’s interests! © Gilb.com Agility is the Tool December 9, 2013 17
- 18. the Fundamental Objectives (Profit, survival) Software Productivity: Lines of Code Generation Ability Lead-Time: Predictability. TTMP: Predictability of Time To Market: Product Attributes: Customer Satisfaction: Profitability: Productivity Slides incl Ericsson http://www.gilb.com/dl559 5
- 19. ◦ Support the Strategic Objectives Complaints: Feature Production: Rework Costs: Installation Ability: Service Costs: Training Costs: Specification Defectiveness: Specification Quality: Improvement ROI: Productivity Slides incl Ericsson http://www.gilb.com/dl559 "Let no man turn aside, ever so slightly, from the broad path of honour, on the plausible pretence that he is justified by the goodness of his end. All good ends can be worked out by good means." Charles Dickens 6
- 20. http://www.agilemodeling.com/essays/productOwner.htm © Gilb.com Agility is the Tool December 9, 2013 20
- 21. Background: this policy defines the expectations for a ‘Product Owner’ (PO) for serious, critical, large, and complex systems. 1. This implies that it is not enough to manage a simple stream (Backlog) of „user stories‟ fed to a programming team. 2. It is necessary to communicate with a systems engineering team, developing or maintaining the „Product‟. System implies management of all technological components, people, data, hardware, organization, training, motivat ion, and programs. Engineering: means systematic and quantified, „real‟ engineering processes, where proactive design is used to manage system performance (incl. all qualities) attributes and costs. New idea being drafted by TG for a Client Bank, 7.12.2013 © Gilb.com Agility is the Tool December 9, 2013 21
- 22. 1. COMPLETE REQUIREMENTS: The RE (Requirements Engineer) is responsible for absolutely all requirements specification that the system must be aware of, and be responsible for to all critical or relevant stakeholders. In particular, the RE is not narrowly responsible for requirements from users and customers alone. They are responsible for all other stakeholders, such as operations, maintenance, laws, regulations, resource providers, and more. 2. QUALITY REQUIREMENTS: The RE is responsible for the quality level, in relation to official standards, of all requirements they transmit to others. They are consequently responsible for making sure the quality of incoming raw requirements, needs, values, constraints etc. is good enough to process. No GIGO. If input is not good quality, they are responsible for making sure it is better quality, or at least clearly annotated where there is doubt, incompleteness, ambiguity and any other potential problems, they cannot resolve yet. 3. ARCHITECTURE: The Requirements Engineer is NOT responsible for any architecture or design process itself. This will be done by professional engineers and architects. They are however very much responsible for a complete and intelligible quality set of requirements, transmitted to the designers and architects. The are also responsible for transmitting quality-controlled architecture or design specifications to any relevant system builders. These are the designs which are input requirements to builders. Effectively they are „design constraints requirements‟. 4. PRIORITY INFORMATION: The Requirements Engineer is NOT responsible for prioritization of requirements. Prioritization is done dynamically at the project management (PM) level, based on prioritization signals in the requirements, and on current feedback and experience in the value delivery cycles (Sprints). The primary responsibility of the Requirements Engineer, is to systematically and thoroughly collect and disseminate all relevant priority signals, into the requirement specification; so that intelligent prioritization can be done at any relevant level, and at any time. New idea being drafted by TG for a Client Bank, 7.12.2013 © Gilb.com Agility is the Tool December 9, 2013 22
- 23. http://www.agilemodeling.com/essays/productOwner.htm © Gilb.com Agility is the Tool December 9, 2013 23
- 24. © Gilb.com Agility is the Tool December 9, 2013 24
- 25. If you cannot, then your knowledge is of a meagre and unsatisfactory kind (Lord Kelvin) © Gilb.com Agility is the Tool December 9, 2013 25
- 27. www.Gilb.com Version December 9, 2013 Sli de 27
- 28. © Gilb.com Agility is the Tool December 9, 2013 28
- 29. 29.5:1 © Gilb.com 9 December, 2013 Sli de 29
- 30. Decomposition of Projects: How to Design Small Incremental Steps INCOSE 2008 http://www.gilb.com/tikidownload_file.php?fileId=4 1 © Gilb.com Agility is the Tool December 9, 2013 30
- 31. ◦1% increase at least ◦1 stakeholder ◦1 quality or value ◦1-week delivery cycle ◦1 function focus ◦1 design used http://www.gilb.com/tiki-download_file.php?fileId=451 111111 Unity Method slides © Gilb.com 9 December, 2013 31
- 32. How to decompose systems into small evolutionary steps: some principles to apply: 1• Believe there is a way to do it, you just have not found it yet! 2• Identify obstacles, but don't use them as excuses: use your imagination to get rid of them! 3• Focus on some usefulness for the user or customer, however small. 4• Do not focus on the design ideas themselves, they are distracting, especially for small initial cycles. Sometimes you have to ignore them entirely in the short term! 5• Think; one customer, tomorrow, one interesting improvement. 6• Focus on the results (which you should have defined in your goals, moving toward target levels). 7• Don't be afraid to use temporary-scaffolding designs. Their cost must be seen in the light of the value of making some progress, and getting practical experience. 8• Don't be worried that your design is inelegant; it is results that count, not style. 9• Don't be afraid that the customer won't like it. If you are focusing on results they want, then by definition, they should like it. If you are not, then do! 10• Don't get so worried about "what might happen afterwards" that you can make no practical progress. 11• You cannot foresee everything. Don't even think about it! 12• If you focus on helping your customer in practice, now, where they really need it, you will be forgiven a lot of „sins‟! 13• You can understand things much better, by getting some practical experience (and removing some of your fears). 14• Do early cycles, on willing local mature parts of your user community. 15• When some cycles, like a purchase-order cycle, take a long time, initiate them early, and do other useful cycles while you wait. 16• If something seems to need to wait for „the big new system‟, ask if you cannot usefully do it with the „awful old system‟, so as to pilot it realistically, and perhaps alleviate some 'pain' in the old system. 17• If something seems too costly to buy, for limited initial use, see if you can negotiate some kind of „pay as you really use‟ contract. Most suppliers would like to do this to get your patronage, and to avoid competitors making the same deal. 18• If you can't think of some useful small cycles, then talk directly with the real „customer‟ or end user. They probably have dozens of suggestions. 19• Talk with end users in any case, they have insights you need. 20• Don't be afraid to use the old system and the old „culture‟ as a launching platform for the radical new system. There is a lot of merit in this, and many people overlook it. I have never seen an exception in 33 years of doing this with many varied cultures. Oh Ye of little faith! http://www.gilb.com/tikidownload_file.php?fileId=41 © Gilb.com 9 December, 2013 32
- 33. “We should bring the whole force of our minds ◦ to bear upon the most minute and simple details ◦ and to dwell upon them for a long time ◦ so that we become accustomed to perceive the truth clearly and distinctly.” Rene Descartes, Rules for the Direction of the Mind, 1628 © Gilb.com 9 December, 2013 33
- 34. That which remains quiet, is easy to handle. That which is not yet developed is easy to manage. That which is weak is easy to control. That which is still small is easy to direct. Deal with little troubles before they become big. Attend to little problems before they get out of hand. ◦ For the largest tree was once a sprout, the tallest tower started with the first brick, and the longest journey started with the first step. ◦ From Lao Tzu in Bahn, 1980 (also quoted in Gilb, Principles of Software Engineering Management page 96), Penguin book © Gilb.com 9 December, 2013 34
- 35. Design is the servant of the requirement. If it does not work „fire‟ it. © Gilb.com Agility is the Tool December 9, 2013 35
- 36. Lean Startup 9 December, http://www.slideshare.net/venturehacks/the-lean-startup-2 2013 36
- 38. http://rsbatechnology.co.uk/blog:8 Back in 2004, I was employed by a large investment bank in their FX e-commerce IT department as a business analyst. The wider IT organisation used a complex waterfall-based project methodology that required use of an intranet application to manage and report progress. However, it's main failings were that it almost totally missed the ability to track delivery of actual value improvements to a project's stakeholders, and the ability to react to changes in requirements and priority for the project's duration. The toolset generated lots of charts and stats that provided the illusion of risk control. but actually provided very little help to the analysts, developers and testers actually doing the work at the coal face. The proof is in the pudding; used Evo ◦ I have (albeit in disguise sometimes) on two large, high-risk projects in front-office investment banking businesses, and several smaller tasks. ◦ On the largest critical project, the original business functions & performance objective ◦ requirements document, which included no design, essentially remained unchanged over the 14 months the project took to deliver, but the detailed designs (of the GUI, business logic, performance characteristics) changed many many times, guided by lessons learnt and feedback gained by delivering a succession of early deliveries to real users. ◦ successfully went live over one weekend for 800 users worldwide was In the end, the new system responsible for 10s of USD billions of notional risk, , and seen as a big success by the sponsoring stakeholders. “ I attended a 3-day course with you and Kai whilst at Citigroup in 2006 © Gilb.com 9 December, 2013 38
- 39. Richard Smit “… but the detailed designs ◦ (of the GUI, business logic, performance characteristics) changed many many times, guided by lessons learnt and feedback gained by delivering a succession of early deliveries to real users” “ I attended a 3-day course with you and Kai whilst at Citigroup in 2006”, Ric © Gilb.com 9 December, 2013 39
- 40. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 40
- 41. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) of developing a design, estimating its cost, and ensuring that the design is costeffective He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 41
- 42. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability’ 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 42
- 43. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) Design is an iterative process He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 43
- 44. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 44
- 45. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) an estimate to complete the remaining increments is computed. He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 45
- 46. Reduce the level or delivery time, of lower-priority requirements, in order to deliver high priority requirements on time, within budget, or at Goal levels. © Gilb.com Agility is the Tool December 9, 2013 46
- 47. “Software Engineering began to emerge in FSD” (IBM Federal Systems Division, from 1996 a part of Lockheed Martin Marietta) “some ten years ago [Ed. about 1970] in a continuing evolution that is still underway: Ten years ago general management expected the worst from software projects – cost overruns, late deliveries, unreliable and incomplete software Today [Ed. 1980!], management has learned to expect ontime, within budget, deliveries of high-quality software. A Navy helicopter ship system, called LAMPS, provides a recent example. LAMPS software was a four-year project of over 200 person-years of effort, developing over three million, and integrating over seven million words of program and data for eight different processors distributed between a helicopter and a ship in 45 incremental deliveries [Ed. Note 2%!]s. Every one of those deliveries was on time and under budget A more extended example can be found in the NASA space program, - Where in the past ten years, FSD has managed some 7,000 person-years of software development, developing and integrating over a hundred million bytes of program and data for ground and space processors in over a dozen projects. - There were few late or overrun deliveries in that decade, and none at all in the past © Gilb.com 2011 09 December 2013 47 four years.”
- 48. “Software Engineering began to emerge in FSD” (IBM Federal Systems Division, from 1996 a part of Lockheed Martin Marietta) “some ten years ago [Ed. about 1970] in a continuing evolution that is still underway: Ten years ago general management expected the worst from software projects – cost overruns, late deliveries, unreliable and incomplete software Today [Ed. 1980!], management has learned to expect on-time, within budget, deliveries of high-quality software. A Navy helicopter ship system, called LAMPS, provides a recent example. LAMPS software was a four-year project of over 200 person-years of effort, developing over three million, and integrating over seven million words of program and data for eight different processors distributed between a helicopter and a ship in 45 incremental deliveries [Ed. Note 2%!]s. Every one of those deliveries was on time and under budget A more extended example can be found in the NASA space program, - Where in the past ten years, FSD has managed some 7,000 person-years of software development, developing and integrating over a hundred million bytes of program and data for ground and space processors in over a dozen projects. - There were few late or overrun deliveries in that decade, and none at all in the past four years.” in 45 incremental deliveries were few late or overrun deliveries in that decade, and none at all in the past four years © Gilb.com 2011 09 December 2013 48
- 49. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 49
- 50. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) of developing a design, estimating its cost, and ensuring that the design is cost-effective He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 50
- 51. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability’ 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 51
- 52. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) Design is an iterative process He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 52
- 53. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 53
- 54. Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) an estimate to complete the remaining increments is computed. He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77 This text is cut from Gilb: The Principles of Software Engineering Management, 1988 Copyright [email protected] 2013 9 December, 2013 54
- 55. It is much easier to determine requirements with a little hindsight! The eternal cycle of stakeholder priorities © Gilb.com Agility is the Tool December 9, 2013 55
- 56. Team 2 Team 3 Team 1 Team 4 Confirmit Product * Empowered Creativity: Term coined by Trond Johansen, Confirmit, 2003 © Tom @ Gilb.com 09 December 2013 56
- 57. 9 8 3 3 Monday, 09 December © [email protected] Top10 2013 Method 57
- 58. Only 5 highlights of the 25 impacts are listed here Release 8.5 © Tom @ Gilb.com
- 59. © Gilb.com Agility is the Tool December 9, 2013 59
- 60. © Tom @ Gilb.com 09 December 2013 60
- 61. 9 8 3 3 09 December 2013 © Tom @ Gilb.com 61
- 62. In these ”green” weeks, some of the deliverables will be less visible for the end users, but more visible for our QA department. We manage code quality through an Impact Estimation table. Speed Maintainability Nunit Tests PeerTests TestDirectorTests Robustness.Correctness Robustness.Boundary Conditions ResourceUsage.CPU Maintainability.DocCode SynchronizationStatus 2013 Method Monday, 09 December © [email protected] Top10 62
- 63. Current Level Competitive and Minimumeconomic Future Goal level Level © Tom @ Gilb.com 09 December 2013 63
- 64. © Tom @ Gilb.com 09 December 2013 64
- 66. • “Maintainability must be consciously designed into a system: • failure to design to a set of levels of maintainability • means the resulting maintainability is both bad and random. ” • © Tom Gilb (2008, INCOSE Paper) http://www.gilb.com/tikidownload_file.php?fileId=138 www.gilb.com December 9, 2013 66
- 67. 1. Problem Recognition Time. How can we reduce the time from bug actually occurs until it is recognized and reported? 2. Administrative Delay Time: How can we reduce the time from bug reported, until someone begins action on it? 3. Tool Collection Time. How can we reduce the time delay to collect correct, complete and updated information to analyze the bug: source code, changes, database access, reports, similar reports, test cases, test outputs. 4. Problem Analysis Time. Etc. for all the following phases defined, and implied, in the Scale scope above. 5. Correction Hypothesis Time 6. Quality Control Time 7. Change Time 8. Local Test Time 9. Field Pilot Test Time 10. Change Distribution Time 11. Customer Installation Time 12. Customer Damage Analysis Time 13. Customer Level Recovery Time 14. Customer QC of Recovery Time Source: Competitive Engineering Ch 5 & Ireson (ed.) Reliability Handbook, 1966 67 www.gilb.com December 9, 2013
- 68. Restore Speed: Type: Software Quality Requirement. Version: 25 October 2007. Part of: Rock Solid Robustness Ambition: Should an error occur (or the user otherwise desire to do so), the system shall be able to restore the system to a previously saved state in less than 10 minutes. <-6.1.2 HFA. Scale: Duration from Initiation of Restore to Complete and verified state of a defined [Previous: Default = Immediately Previous]] saved state. Initiation: defined as {Operator Initiation, System Initiation, ?}. Default = Any. Goal [ Initial and all subsequent released and Evo steps] 1 minute? Fail [ Initial and all subsequent released and Evo steps] 10 minutes. <- 6.1.2 HFA Catastrophe: 100 minutes. www.gilb.com December 9, 2013 68
- 69. 1. How many of you would prefer to keep doing conventional „softcrafter‟ refactoring; even if the results were not measurable 2. How many of you think you ought to try to engineer measurable software maintainability results into your systems ◦ Even if your boss is not smart enough to ask you, or support you doing it? © Tom @ Gilb.com 09 December 2013 69
- 70. © Tom @ Gilb.com 09 December 2013 70
- 71. My 10 Agile Values? Simplicity 1. Focus on real stakeholder values Communication 2. Communicate stakeholder values quantitatively 3. Estimate expected results and costs for weekly steps Feedback 4. Generate results, weekly, for stakeholders, in their environment 5. Measure all critical aspects of the improved results cycle. 6. Analyze deviation from your initial estimates Courage 7. Change plans to reflect weekly learning 8. Immediately implement valued stakeholder needs, next week Don‟t wait, don‟t study (analysis paralysis), don‟t make excuses. Just Do It! 9. Tell stakeholders exactly what you will deliver next week 10. Use any design, strategy, method, process that works quantitatively well - to get your results Be a systems engineer, not a just programmer (a „Softcrafter‟). Do not be limited by your craft background, in serving your paymasters “Values for Value” http://www.gilb.com/tiki-download_file.php?fileId=448 Agile Record 2010, www.agilerecord.com, October 2010, Issue 4 71 © Gilb.com Agility is the Tool Copyright 2004-8 Gilb, may be used citing source December 9, 2013
- 72. Ecstatic Stakeholder! 72 © Gilb.com Agility is the Tool December 9, 2013
- 73. That’s All Folks! Discussion? I am here all Conference and incl My Friday ‘Evo’ Seminar And love to talk with you! Remarks? Questions? Email me if you like For free digital copy of this book, and 4 of my Agile papers, and the Evo book Email me subject “Book” [email protected] If you want to agree a meeting, email me or text +47 92066705 This talk is NOW at Gilb.com/Downloads (Slides) 73 © Gilb.com 17 Feb 2010
- 74. Agile Credibility Agile „Grandfather‟ (Tom) Practicing „Agile‟ IT Projects since 1960 Preaching Agile since 1970‟s (CW UK) Acknowledged Pioneer by Agile Gurus and Research Beck, Sutherland, Highsmith, Cohn, Larman etc. Ask me for details on this! I am too shy to show it here! Agile Practice IT: for decades (Kai and Tom) Organisations: for Decades (Citigroup, Intel, HP, Boeing) Books: Principles of Software Engineering Management (1988) the book Beck and others refer to Competitive Engineering (2005) Evo: (Kai, evolving, 55 iterations) 74 © Gilb.com Monday, 09 December 2013
- 75. OK I am not that shy! (the most influential!) Agile References: "Tom Gilb invented Evo, arguably the first Agile process. He and his son Kai have been working with me in Norway to align what they are doing with Scrum. Kai has some excellent case studies where he has acted as Product Owner. He has done some of the most innovative things I have seen in the Scrum community." Jeff Sutherland, co-inventor of Scrum, 5Feb 2010 in Scrum Alliance Email. “Tom Gilb's Planguage referenced and praised at #scrumgathering by Jeff Sutherland. I highly agree" Mike Cohn, Tweet, Oct 19 2009 “I‟ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out." Mike Cohn http://blog.mountaingoatsoftware.com/?p=77 Comment of Kent Beck on Tom Gilb‟s book , “Principles of Software Engineering Management”: “ A strong case for evolutionary delivery – small releases, constant refactoring, intense dialog with the customer”. (Beck, page 173). In a mail to Tom, Kent wrote: “I'm glad you and I have some alignment of ideas. I stole enough of yours that I'd be disappointed if we didn't :-), Kent” (2003) Jim Highsmith (an Agile Manifesto signatory) commented : “Two individuals in particular pioneered the evolution of iterative development approached in the 1980‟s – Barry Boehm with his Spiral Model and Tom Gilb with his Evo model. I drew on Boehm‟s and Gilb‟s ideas for early inspiration in developing Adaptive Software Development. …. Gilb has long advocated this more explicit (quantitative) valuation in order to capture the early value and increaseTool (Cutter It Journal: The Journal of Information Technology © Gilb.com Agility is the ROI” December 9, 2013 75 Management, July 2004page 4, July 2004).
- 76. TWELVE TOUGH QUESTIONS 1. Why isn't the improvement quantified? 2. What is degree of the risk or uncertainty and why? 3. Are you sure? If not, why not? 4. Where did you get that from? How can I check it out? 5. How does your idea affect my goals, measurably? 6. Did we forget anything critical to survival? 76 © Gilb.com 7. How do you know it works that way? Did it before? 8. Have we got a complete solution? Are all objectives satisfied? 9. Are we planning to do the 'profitable things' first? 10. Who is responsible for failure or success? 11. How can we be sure the plan is working, during the project, early? 12. Is it ‘no cure, no pay’ in a contract? Why not? Monday, 09 December 2013 There is a detailed paper on these questions at Gilb.com http://www.gilb.com/tiki-download_file.php?fileId=24
Editor's Notes
- #2: Version Buildstuff Vilnius Dec 9 2013Might need trimming as I am doing the Case studies in separate talk next daySlides originated June 7-8 2010 DigerudIt took me on 8th from about 13-21 to finish these from my raw materialsAdded (Wright Citi case, and That’s all folks) slides 21 sept 2011 7 Nov 2013Main Talk vastly upgraded for Agile Warsaw (recorded talk) Oct 2013Added about 10 Green Week slides at end for Agile Singapore. 7 Nov 2013 Recorded
- #3: http://www.google.com/imgres?imgurl=http://keepingagile.files.wordpress.com/2012/06/genericagileconceptideogram.png&imgrefurl=http://keeping-agile.com/&h=1088&w=1426&sz=439&tbnid=wlLdDxB_sXa_VM:&tbnh=82&tbnw=108&zoom=1&usg=__XS_KE8RhixHHbCmLa3CJiUKdiHA=&docid=YErwU0C8H4LOJM&sa=X&ei=HSayUaX5CYbj4QTpqoC4Aw&ved=0CFEQ9QEwCg&dur=1002
- #4: Comment: this is the Evo version of an Agile Cycle. But it is a variation on the classic Deming/Shewhart Plan Do Study Act clycle from Statistical Process Control. TSg June 7 2013
- #5: Comment: Scrum or other Agile IT methods, are at best a part of the business solution. They must be managed carefully, and quantitatively so they give real busness results, not just dubious IT systems. TsG June 7 2013
- #6: Comment: Agile concepts apply to all management processes
- #7: Comment: Agile is divide and conquer, bug problems, so we keep contact with reality, our stakeholders, and real results. It is a Cartesian method. Analysis, Mastery, Synthesis.
- #10: developing a large web portal www.bring.no dk/se/nl/co.uk/com/eeat PostenNorgeJeffsutherland Twitter: Very cool product backlog management by Tom and Kai Gilb http://ad.vu/2h4dSat 28 March 2009
- #11: developing a large web portal www.bring.no dk/se/nl/co.uk/com/eeat PostenNorgePhoto Kai 2009 at OC4 Kolbotnw JeffPhoto Sutherland 2010 April from Digerud Cabin
- #14: http://www.hit.nl/images/content/BSCStrategyMap.png
- #15: http://www.chariho.k12.ri.us/curriculum/MIsmart/matter/matter.html
- #18: http://dashboardsbyexample.com/wp-content/uploads/2008/06/marketing-spend-business-results-model.png
- #21: Made tsg Vilnius 9 dec 2013
- #22: ‘Advanced Product Owner’ Policy: System ‘Requirements Engineer’ (RE).Background: this policy defines the expectations for a ‘Product Owner’ (PO) for serious, critical, large, and complex systems.This implies that it is not enough to manage a simple stream (Backlog) of ‘user stories’ fed to a programming team.It is necessary to communicate with a systems engineering team, developing or maintaining the ‘Product’.System implies management of all technological components, people, data, hardware, organization, training, motivation, and programs.Engineering: means systematic and quantified, ‘real’ engineering processes, where proactive design is used to manage system performance (incl. all qualities) attributes and costs. 1. COMPLETE REQUIREMENTS: The RE (Requirements Engineer) is responsible for absolutely all requirements specification that the system must be aware of, and be responsible for to all critical or relevant stakeholders.In particular, the RE is not narrowly responsible for requirements from users and customers alone. They are responsible for all other stakeholders, such as operations, maintenance, laws, regulations, resource providers, and more. 2. QUALITY REQUIREMENTS:The RE is responsible for the quality level, in relation to official standards, of all requirements they transmit to others. They are consequently responsible for making sure the quality of incoming raw requirements, needs, values, constraints etc. is good enough to process. No GIGO. If input is not good quality, they are responsible for making sure it is better quality, or at least clearly annotated where there is doubt, incompleteness, ambiguity and any other potential problems, they cannot resolve yet. 3. ARCHITECTURE:The Requirements Engineer is NOT responsible for any architecture or design process itself. This will be done by professional engineers and architects.They are however very much responsible for a complete and intelligible quality set of requirements, transmitted to the designers and architects.The are also responsible for transmitting quality-controlled architecture or design specifications to any relevant system builders. These are the designs which are input requirements to builders. Effectively they are ‘design constraints requirements’. 4. Priority Information:The Requirements Engineer is NOT responsible for prioritization of requirements. Prioritization is done dynamically at the project management (PM) level, based on prioritization signals in the requirements, and on current feedback and experience in the value delivery cycles (Sprints).The primary responsibility of the Requirements Engineer, is to systematically and thoroughly collect and disseminate all relevant priority signals, into the requirement specification; so that intelligent prioritization can be done at any relevant level, and at any time.
- #23: Dec 9 2013‘Advanced Product Owner’ Policy: System ‘Requirements Engineer’ (RE).Background: this policy defines the expectations for a ‘Product Owner’ (PO) for serious, critical, large, and complex systems.This implies that it is not enough to manage a simple stream (Backlog) of ‘user stories’ fed to a programming team.It is necessary to communicate with a systems engineering team, developing or maintaining the ‘Product’.System implies management of all technological components, people, data, hardware, organization, training, motivation, and programs.Engineering: means systematic and quantified, ‘real’ engineering processes, where proactive design is used to manage system performance (incl. all qualities) attributes and costs. 1. COMPLETE REQUIREMENTS: The RE (Requirements Engineer) is responsible for absolutely all requirements specification that the system must be aware of, and be responsible for to all critical or relevant stakeholders.In particular, the RE is not narrowly responsible for requirements from users and customers alone. They are responsible for all other stakeholders, such as operations, maintenance, laws, regulations, resource providers, and more. 2. QUALITY REQUIREMENTS:The RE is responsible for the quality level, in relation to official standards, of all requirements they transmit to others. They are consequently responsible for making sure the quality of incoming raw requirements, needs, values, constraints etc. is good enough to process. No GIGO. If input is not good quality, they are responsible for making sure it is better quality, or at least clearly annotated where there is doubt, incompleteness, ambiguity and any other potential problems, they cannot resolve yet. 3. ARCHITECTURE:The Requirements Engineer is NOT responsible for any architecture or design process itself. This will be done by professional engineers and architects.They are however very much responsible for a complete and intelligible quality set of requirements, transmitted to the designers and architects.The are also responsible for transmitting quality-controlled architecture or design specifications to any relevant system builders. These are the designs which are input requirements to builders. Effectively they are ‘design constraints requirements’. 4. Priority Information:The Requirements Engineer is NOT responsible for prioritization of requirements. Prioritization is done dynamically at the project management (PM) level, based on prioritization signals in the requirements, and on current feedback and experience in the value delivery cycles (Sprints).The primary responsibility of the Requirements Engineer, is to systematically and thoroughly collect and disseminate all relevant priority signals, into the requirement specification; so that intelligent prioritization can be done at any relevant level, and at any time.
- #24: Made tsg Vilnius 9 dec 2013
- #25: http://www.treehugger.com/zaha-hadad-car.jpg
- #26: http://www.ie.sogeti.com/PageFiles/877/Impact%20six%20themes%20%5B1%5D.gif
- #29: http://bellagio.typepad.com/main/images/vaccine_priority_groups.jpg
- #30: 29.5 to 1 fixed and 2 rectangles moved to right 12 3 2013 stockholmArrows and heqader edited Dec 9 2013 Vilnius TG
- #31: http://www.agileadvice.com/archives/IterationValueDelivery.png
- #32: Decomposition of Projects - How to design small incremental result steps, 2008 Paperhttp://www.gilb.com/tiki-download_file.php?fileId=41111111 Unity Method of Decomposition into weekly increments of value delivery. (10 min slides)http://www.gilb.com/tiki-download_file.php?fileId=451Draft 11 dec 2008 7MB see paper on it at [http://www.gilb.com/tiki-download_file.php?fileId=41]Note a raw set of slides not well sorted or refined but a beginning set for a 1 day course on decomposition, aimed perhaps at Scrum and Agile peoplehttp://www.gilb.com/tiki-download_file.php?fileId=350Decomposition of Projects: How to Design Small Incremental Steps INCOSE 2008http://www.gilb.com/tiki-download_file.php?fileId=41http://www.gilb.com/tiki-download_file.php?fileId=350Decomposition Slides Aug 2010http://www.gilb.com/tiki-download_file.php?fileId=451111111 Unity Method slides 10 minute TalkEvo PaperSlides
- #33: Decomposition of Projects: How to Design Small Incremental Steps INCOSE 2008http://www.gilb.com/tiki-download_file.php?fileId=41http://www.gilb.com/tiki-download_file.php?fileId=350Decomposition Slides Aug 2010
- #36: http://blogs.warwick.ac.uk/images/eludlow/2007/06/20/modepaleizen04_groot.jpghttp://blogs.warwick.ac.uk/images/eludlow/2007/06/20/modepaleizen04_groot.jpg
- #37: Source http://www.slideshare.net/venturehacks/the-lean-startup-2Slides bySteven Blank and Eric Ries. “The Lean Startup, Low Burn by Design , not Crisis”
- #38: From Kai Gilb Bring Case (gilb.com)www.gilb.com/tiki-download_file.php?fileId=277
- #39: Yes, Richard was trained in Requirements by you and Kai while he was at Citi.From: Tom Gilb [mailto:[email protected]] Sent: 26 February 2009 15:16To: Dick HollandHi Tom,I am honoured to be in contact with you again! I attended a 3-day course with you and Kai whilst at Citigroup in 2006 (I worked in the FX e-commerce front-office team at the time). You may be interested to know that I wrote a detailed business requirements spec (no design, just requirements) adopting many of your ideas shortly after the course including key quantified requirements. This spec ended up staying largely stable for a year as we did an evo – like development process, at the end of which we successfully went live with a brand-new FX order management system in a global big-bang release to 800 Citi users in 20 locations. I hope to continue to use and expand competitive engineering practises at my new home here at LZ, with Dick’s help!Many regards,Richard.Hi Tom,Thought you might like to know I have just completed a review of Competitive Engineering on my own company's blog:http://rsbatechnology.co.uk/blog:8As I tried to do when I worked with Dick at LatentZero, I continue to try and spread the word to a world of (initial) unbelievers! I actually have an interesting opportunity right now to demonstrate the benefits of early & often delivery of value to stakeholders in a couple of new projects. Look forward to meeting you and Kai again sometime ...Regards,Richard Smith.sept 10 2011
- #40: Yes, Richard was trained in Requirements by you and Kai while he was at Citi.From: Tom Gilb [mailto:[email protected]] Sent: 26 February 2009 15:16To: Dick HollandHi Tom,I am honoured to be in contact with you again! I attended a 3-day course with you and Kai whilst at Citigroup in 2006 (I worked in the FX e-commerce front-office team at the time). You may be interested to know that I wrote a detailed business requirements spec (no design, just requirements) adopting many of your ideas shortly after the course including key quantified requirements. This spec ended up staying largely stable for a year as we did an evo – like development process, at the end of which we successfully went live with a brand-new FX order management system in a global big-bang release to 800 Citi users in 20 locations. I hope to continue to use and expand competitive engineering practises at my new home here at LZ, with Dick’s help!Many regards,Richard.Hi Tom,Thought you might like to know I have just completed a review of Competitive Engineering on my own company's blog:http://rsbatechnology.co.uk/blog:8As I tried to do when I worked with Dick at LatentZero, I continue to try and spread the word to a world of (initial) unbelievers! I actually have an interesting opportunity right now to demonstrate the benefits of early & often delivery of value to stakeholders in a couple of new projects. Look forward to meeting you and Kai again sometime ...Regards,Richard Smith.sept 10 2011
- #41: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #42: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #43: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #44: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #45: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #46: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #47: http://projects.staffs.ac.uk/suniwe/images/rup-cycle.gif
- #48: A time or cost estimate, once it becomes a deadline or a budget respectively, is a ‘limited resource’. One of the smartest ways to deal with limited resources is intelligent prioritization (Gilb and Maier 2005). Instead of implementing all your designs in a ‘big bang’ manner, and hoping to meet all the requirements and resource (time and cost) estimates, we suggest you deliver the project valuea little bit at a time, and see how each of the designs actually works, and what they each actually cost. ‘A little bit at a time’ should be interpreted as delivering evolutionary steps of approximately 2% of the overall project timescales (say weekly, fortnightly or monthly cycles), and hopefully about 2% of the project financial budget.Planguage’s impact estimation (IE) method (Gilb 1988; Gilb 2005) is helpful in identifying the designs that give the estimated best stakeholder value for their costs. We implement designs incrementally so that we can get acceptable feedback on costs, and value delivery (in terms of meeting requirements). With a bit of luck, stakeholders then receive interesting value very early, and what works and what doesn’t is learned in practice. If a deadline is hit, or if the budget runs out (possibly because of a deadline being moved up earlier or a budget cut!), then at least there is still a complete live real system with delivered high-value. In such situations, the whole concept of the project-level estimates, the deadlines and the budgets is not so important any more.Nobody does it better! Harlan Mills told me that they had to solve the persistent problem of cost overruns, in relation to the contracted estimates, because the government was getting smarter, and using fixed-price contracts (as opposed to cost plus). If the project ran over, IBM lost its own profit. If IBM did not find a better way, they could just as well leave the business (Personal Communication).Notice the “45 deliveries” Mills cites. That means 2% delivery cycles. IBM was using intelligent feedback and learning. They actually had very sophisticated estimation technology based on a thorough collection of experiences (Walston and Felix 1977). But this did not give them the accuracy they needed to avoid losing money. Lets us say they had a 40% profit margin, and they could be wrong by 40% to 200% (The NASA range, see earlier Figure 3). They would still lose money on most contracts. So, they had to compensate for their estimation inaccuracy by incremental feedback, and necessary change, to come in ‘on time and under budget every time’. Mills’ colleague, Quinnan describes their process of intelligent dynamic prioritization in detail in (Mills 1980 in IBM SJ 4-1980).A thorough explanation of systems development processes helping achieve intelligent prioritization is found in (Gilb 2005). See also Figure 9. Nothing less will suffice for large and complex systems (that is, for project involving hundreds of staff, years of effort, and sometimes $100 million or more in cost). For smaller systems (small teams over a few months), several organizations have made good simple practical adaptations (Upadhyayula 2001 (Study of Evo at HP in 1990s); Johansen and Gilb 2005) of the essential ‘Evo’ development process ideas (Evo itself predating later ‘Agile’ methods)[Denning 2010, p.129] & [Gilb 2010c].The agile community has adopted small iterative cycles (Gilb 2010c), but they have failed to adopt the notion of measurement of value and quality – which is essential for larger projects, and some smaller ones. Without explicit absolute quality requirement and design impact metrics, the value prioritization is ambiguous and too subjective (Gilb 2010c; Gilb and Brodie 2010).
- #49: A time or cost estimate, once it becomes a deadline or a budget respectively, is a ‘limited resource’. One of the smartest ways to deal with limited resources is intelligent prioritization (Gilb and Maier 2005). Instead of implementing all your designs in a ‘big bang’ manner, and hoping to meet all the requirements and resource (time and cost) estimates, we suggest you deliver the project valuea little bit at a time, and see how each of the designs actually works, and what they each actually cost. ‘A little bit at a time’ should be interpreted as delivering evolutionary steps of approximately 2% of the overall project timescales (say weekly, fortnightly or monthly cycles), and hopefully about 2% of the project financial budget.Planguage’s impact estimation (IE) method (Gilb 1988; Gilb 2005) is helpful in identifying the designs that give the estimated best stakeholder value for their costs. We implement designs incrementally so that we can get acceptable feedback on costs, and value delivery (in terms of meeting requirements). With a bit of luck, stakeholders then receive interesting value very early, and what works and what doesn’t is learned in practice. If a deadline is hit, or if the budget runs out (possibly because of a deadline being moved up earlier or a budget cut!), then at least there is still a complete live real system with delivered high-value. In such situations, the whole concept of the project-level estimates, the deadlines and the budgets is not so important any more.Nobody does it better! Harlan Mills told me that they had to solve the persistent problem of cost overruns, in relation to the contracted estimates, because the government was getting smarter, and using fixed-price contracts (as opposed to cost plus). If the project ran over, IBM lost its own profit. If IBM did not find a better way, they could just as well leave the business (Personal Communication).Notice the “45 deliveries” Mills cites. That means 2% delivery cycles. IBM was using intelligent feedback and learning. They actually had very sophisticated estimation technology based on a thorough collection of experiences (Walston and Felix 1977). But this did not give them the accuracy they needed to avoid losing money. Lets us say they had a 40% profit margin, and they could be wrong by 40% to 200% (The NASA range, see earlier Figure 3). They would still lose money on most contracts. So, they had to compensate for their estimation inaccuracy by incremental feedback, and necessary change, to come in ‘on time and under budget every time’. Mills’ colleague, Quinnan describes their process of intelligent dynamic prioritization in detail in (Mills 1980 in IBM SJ 4-1980).A thorough explanation of systems development processes helping achieve intelligent prioritization is found in (Gilb 2005). See also Figure 9. Nothing less will suffice for large and complex systems (that is, for project involving hundreds of staff, years of effort, and sometimes $100 million or more in cost). For smaller systems (small teams over a few months), several organizations have made good simple practical adaptations (Upadhyayula 2001 (Study of Evo at HP in 1990s); Johansen and Gilb 2005) of the essential ‘Evo’ development process ideas (Evo itself predating later ‘Agile’ methods)[Denning 2010, p.129] & [Gilb 2010c].The agile community has adopted small iterative cycles (Gilb 2010c), but they have failed to adopt the notion of measurement of value and quality – which is essential for larger projects, and some smaller ones. Without explicit absolute quality requirement and design impact metrics, the value prioritization is ambiguous and too subjective (Gilb 2010c; Gilb and Brodie 2010).
- #50: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #51: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #52: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #53: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #54: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #55: Slide developed Oct 6 2013 tsg for London Software Architecture Conference Talk 9 Oct 2013 15.1.18 Quinnan Source: Robert E. Quinnan, 'Software Engineering Management Practices', IBM Systems Journal, Vol. 19, No. 4, 1980, pp. 466~77Robert E. Quinnan: The Management of Software Engineering. Part V: Software Engineering Management Practices.IBM Systems Journal 19(4): 466-477 (1980) Quinnan describes the process control loop used by IBM FSD to ensure that cost targets are met. 'Cost management. . . yields valid cost plans linked to technical performance. Our practice carries cost management farther by introducing design-to-cost guidance. Design, development, and managerial practices are applied in an integrated way to ensure that software technical management is consistent with cost management. The method [illustrated in this book by Figure 7.10] consists of developing a design, estimating its cost, and ensuring that the design is cost-effective.' (p. 473) He goes on to describe a design iteration process trying to meet cost targets by either redesign or by sacrificing 'planned capability.' When a satisfactory design at cost target is achieved for a single increment, the 'development of each increment can proceed concurrently with the program design of the others.' 'Design is an iterative process in which each design level is a refinement of the previous level.' (p. 474) It is clear from this that they avoid the big bang cost estimation approach. Not only do they iterate in seeking the appropriate balance between cost and design for a single increment, but they iterate through a series of increments, thus reducing the complexity of the task, and increasing the probability of learning from experience, won as each increment develops, and as the true cost of the increment becomes a fact. 'When the development and test of an increment are complete, an estimate to complete the remaining increments is computed.' (p. 474) This article is far richer than our few selected quotations can show, with regard to concepts of cost estimation and control.
- #56: http://www.performance-measurement.net/assets/neely/prism03.gifIt is much easier to determine requirements with a little hindsight!(I just invented this now as I was making the slide June 8 2010 Tom Gilb)
- #57: Originated March 12 2013 Stockholm tsg
- #60: http://www.lab49.com/files/company/IterativeProjectDelivery.png
- #64: Slide originated 3 Nov 2013 for Smidig 2013 Oslo TsG
- #65: Slide originated 3 Nov 2013 for Smidig 2013 Oslo TsG
- #66: Source Competitive Engineering book, Glossary, Requirement
- #67: Source of This principlesGilb ACCU Designing Maintainability Friday 1400 90 minutes.ppt (10.41 Mb)You can download this file using: http://www.gilb.com/tiki-download_file.php?fileId=171Maintainability Paperhttp://www.gilb.com/tiki-download_file.php?fileId=138Designing Maintainability in Software Engineering: a Quantified Approach. Tom GilbResult Planning Limited [email protected] © 2008 by Tom Gilb. Published and used by INCOSE with permission. Principles of Software Maintainability I would like to suggest a set of principles about software maintainability, in order to give this paper a framework: 1. The Conscious Design Principle: Maintainability must be consciously designed into a system: failure to design to a set of levels of maintainability means the resulting maintainability is both bad and random. 2. The Many-Splendored Thing Principle. Maintainability is a wide set of change quality types, under a wide variety of circumstances: so we must clearly define what we are trying to engineer. 3. The Multi-Level Requirement Principle. The levels of maintainability we decide to require are partly constraints, a necessary minimum of ability to avoid failure, and partly desirable target levels that are determined by what pays off to invest in. 4. The Payoff Level Principle. The levels of maintainability it pays off to invest in, depend on many factors – but certainly on the system lifetime expectancy, the criticality/illegality/cost of not being able to change correctly or change in time, and the cost and availability of necessary skilled professionals to carry out the changes. 5. The Priority Dynamics Principle. The maintainability requirements must compete for priority for limited resources with all other requirements. We cannot simply demand arbitrary desired levels of maintainability. http://www.learntarot.com/bigjpgs/maj01.jpgThe Magician is the archetype of the active, masculine principle - the ultimate achiever. He symbolizes the power to tap universal forces and use them for creative purposes. Note his stance in the picture. He acts as a lightening rod - one arm extended up into the Divine for inspiration, the other pointing toward Earth to ground this potent energy. [note] His abilities appear magical at times because his will helps him achieve what seem to be miracles.What makes the Magician so powerful? First, he is not afraid to act. He believes in himself and is willing to put that belief on the line. He also knows what he intends to do and why. He doesn't hesitate because he understands his situation exactly. The Magician can focus with single-minded determination. As long as he remembers the divine source of his power, the Magician remains the perfect conduit for miracles.In a reading, the Magician implies that the primal forces of creativity are yours if you can claim your power and act with awareness and concentration. This card is a signal to act and act now, provided you understand exactly what you want and are committed to getting it.http://learntarot.org/maj01.htmtaking actiondoing what needs to be donerealizing your potentialmaking what's possible realpracticing what you preachcarrying out plansproducing magical resultsusing your talentsactingconsciouslyknowing what you are doing and whyacknowledging your motivationsunderstanding your intentionsexamining the known situationconcentratinghaving singleness of purposebeing totally committedapplying the force of your willfeelingcenteredsetting aside distractionsfocusing on a goalexperiencingpowermaking a strong impacthavingvitalitycreatingmiraclesbecomingenergizedfeelingvigorousbeing creative
- #69: Example 1c: The ‘Ambition’ level statement is a high lev el, not too quantitatively rigorous, summary of the requirement level we want. It is a healthy agreed prelude to more-rigorous definition. We often use the statements made poorly by management, and cite them as the source or authority. We then process with Scale and Goal etc. to define in an engineering manner.
- #73: http://www.centerforvibrationalhealing.info/images/ecstatic-woman.jpg
- #75: Agile References:"Tom Gilb invented Evo, arguably the first Agile process. He and his son Kai have been working with me in Norway to align what they are doing with Scrum.Kai has some excellent case studies where he has acted as Product Owner. He has done some of the most innovative things I have seen in the Scrum community."Jeff Sutherland, co-inventor of Scrum, 5Feb 2010 in Scrum Alliance Email. “Tom Gilb'sPlanguage referenced and praised at #scrumgathering by Jeff Sutherland. I highly agree" Mike Cohn, Tweet, Oct 19 2009 “I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out." Mike Cohn http://blog.mountaingoatsoftware.com/?p=77 Comment of Kent Beck on Tom Gilb’s book , “Principles of Software Engineering Management”:“ A strong case for evolutionary delivery – small releases, constant refactoring, intense dialog with the customer”.(Beck, page 173). In a mail to Tom, Kent wrote:“I'm glad you and I have some alignment of ideas. I stole enough of yours that I'd be disappointed if we didn't :-), Kent” (2003)"But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice." Corey Ladas http://leansoftwareengineering.com/2007/12/20/tom-gilbs-evolutionary-delivery-a-great-improvement-over-its-successors/ Jim Highsmith (an Agile Manifesto signatory) commented: “Two individuals in particular pioneered the evolution of iterative development approached in the 1980’s – Barry Boehm with his Spiral Model and Tom Gilb with his Evo model. I drew on Boehm’s and Gilb’s ideas for early inspiration in developing Adaptive Software Development. …. Gilb has long advocated this more explicit (quantitative) valuation in order to capture the early value and increase ROI” (Cutter It Journal: The Journal of Information Technology Management, July 2004page 4, July 2004). Ward Cunningham wrote April 2005: “Tom -- Thanks for sharing your work. I hope you find value in ours. I'm also glad that the agile community is paying attention to your work. We know (now) that you were out there ahead of most of us. Best regards. – Ward”,http://c2.com Robert C. Martin (Agile Manifesto initial signatory, aka Uncle Bob): "Tom and I talked of many things, and I found myself learning a great deal from him. The item that sticks most prominently in my mind is the definition of progress.", "Tom has invented a planning formalism that he calls Planguage that captures this idea of customer need. I think I'm going to spend some serious time investigating this. " from http://www.butunclebob.com/ArticleS.UncleBob.TomGilbVisit'1985: perhaps the first explicitly named, incremental alternative to the “waterfall” approach is Tom Gilb’s Evolutionary Delivery Model, nicknamed “Evo” 'http://guide.agilealliance.org/timeline.htmlGilb T. (1985). "Evolutionary Delivery versus the "waterfall model" " ACM SIGSOFT, http://dl.acm.org/citation.cfm?id=1012490Mary Poppendieck, 2012In 1988, Tom Gilb wrote the book Principles of Software Engineering Management, which is now in its 20th printing. One of the earliest advocates of evolutionary development, he has recently reiterated the elements of good software engineering in an article in Agile Record[2], from which I quote liberallyhttp://poppendieck.blogspot.com/2010/12/product-owner-problem.htmlAgile History… Historical Roots of Agile Methods:Where did “Agile Thinking” Come from?Noura Abbas, Andrew M Gravell, Gary B WillsSchool of Electronics and Computer Science, University of SouthamptonSouthampton, SO17 1BJ, United Kingdom( Oct 10 2008)http://eprints.ecs.soton.ac.uk/16606/1/xp2008camera_ready.pdf"Agile ideas appeared in old development processes as well. In 1985, Tom Gilb wrote “Evolutionary Delivery versus the ‘Waterfall model’”. In this paper Gilb introduce the EVO method as an alternative of the waterfall which he considered as “unrealistic and dangerous to the primary objectives of any software project”. Gilb based EVO on three simple principles [17]: • Deliver something to the real end-user • Measure the added-value to the user in all critical dimensions • Adjust both design and objectives based on observed realities "
- #76: Agile References:"Tom Gilb invented Evo, arguably the first Agile process. He and his son Kai have been working with me in Norway to align what they are doing with Scrum.Kai has some excellent case studies where he has acted as Product Owner. He has done some of the most innovative things I have seen in the Scrum community."Jeff Sutherland, co-inventor of Scrum, 5Feb 2010 in Scrum Alliance Email. “Tom Gilb'sPlanguage referenced and praised at #scrumgathering by Jeff Sutherland. I highly agree" Mike Cohn, Tweet, Oct 19 2009 “I’ve always considered Tom to have been the original agilist. In 1989, he wrote about short iterations (each should be no more than 2% of the total project schedule). This was long before the rest of us had it figured out." Mike Cohn http://blog.mountaingoatsoftware.com/?p=77 Comment of Kent Beck on Tom Gilb’s book , “Principles of Software Engineering Management”:“ A strong case for evolutionary delivery – small releases, constant refactoring, intense dialog with the customer”.(Beck, page 173). In a mail to Tom, Kent wrote:“I'm glad you and I have some alignment of ideas. I stole enough of yours that I'd be disappointed if we didn't :-), Kent” (2003)"But if you really want to take a step up, you should read Tom Gilb. The ideas expressed in Principles of Software Engineering Management aren’t quite fully baked into the ADD-sized nuggets that today’s developers might be used to, but make no mistake, Gilb’s thinking on requirements definition, reliability, design generation, code inspection, and project metrics are beyond most current practice." Corey Ladas http://leansoftwareengineering.com/2007/12/20/tom-gilbs-evolutionary-delivery-a-great-improvement-over-its-successors/ Jim Highsmith (an Agile Manifesto signatory) commented: “Two individuals in particular pioneered the evolution of iterative development approached in the 1980’s – Barry Boehm with his Spiral Model and Tom Gilb with his Evo model. I drew on Boehm’s and Gilb’s ideas for early inspiration in developing Adaptive Software Development. …. Gilb has long advocated this more explicit (quantitative) valuation in order to capture the early value and increase ROI” (Cutter It Journal: The Journal of Information Technology Management, July 2004page 4, July 2004). Ward Cunningham wrote April 2005: “Tom -- Thanks for sharing your work. I hope you find value in ours. I'm also glad that the agile community is paying attention to your work. We know (now) that you were out there ahead of most of us. Best regards. – Ward”,http://c2.com Robert C. Martin (Agile Manifesto initial signatory, aka Uncle Bob): "Tom and I talked of many things, and I found myself learning a great deal from him. The item that sticks most prominently in my mind is the definition of progress.", "Tom has invented a planning formalism that he calls Planguage that captures this idea of customer need. I think I'm going to spend some serious time investigating this. " from http://www.butunclebob.com/ArticleS.UncleBob.TomGilbVisit'1985: perhaps the first explicitly named, incremental alternative to the “waterfall” approach is Tom Gilb’s Evolutionary Delivery Model, nicknamed “Evo” 'http://guide.agilealliance.org/timeline.htmlGilb T. (1985). "Evolutionary Delivery versus the "waterfall model" " ACM SIGSOFT, http://dl.acm.org/citation.cfm?id=1012490Mary Poppendieck, 2012In 1988, Tom Gilb wrote the book Principles of Software Engineering Management, which is now in its 20th printing. One of the earliest advocates of evolutionary development, he has recently reiterated the elements of good software engineering in an article in Agile Record[2], from which I quote liberallyhttp://poppendieck.blogspot.com/2010/12/product-owner-problem.htmlAgile History… Historical Roots of Agile Methods:Where did “Agile Thinking” Come from?Noura Abbas, Andrew M Gravell, Gary B WillsSchool of Electronics and Computer Science, University of SouthamptonSouthampton, SO17 1BJ, United Kingdom( Oct 10 2008)http://eprints.ecs.soton.ac.uk/16606/1/xp2008camera_ready.pdf"Agile ideas appeared in old development processes as well. In 1985, Tom Gilb wrote “Evolutionary Delivery versus the ‘Waterfall model’”. In this paper Gilb introduce the EVO method as an alternative of the waterfall which he considered as “unrealistic and dangerous to the primary objectives of any software project”. Gilb based EVO on three simple principles [17]: • Deliver something to the real end-user • Measure the added-value to the user in all critical dimensions • Adjust both design and objectives based on observed realities "