Erik Simmons, Intel Corporation, Swiss Requirements Day 2011.
Erik used to be a software developer and moved towards requirements engineering. There are 3 trainers like Erik in Intel’s engineering classes. They trained 15’000 students despite the fact that the classes are not mandatory. Intel has learned that the ROI on better requirements is vital.
Read Erik Simmons› 7 lessons learned in requirements engineering improvement.
Intel first makes sure, that the methods and practices are correct. Only then the tools come in. It takes education, training but also a lot of practice in order to write good requirements. It takes a common language and a conceptual framework for describing and discussing system development.
Lesson 1. Skill in requirements engineering and passion for requirements engineering improvement are not enough
Changing an organisation is among the hardest things to do. Change agency must be treated as seriously as requirements engineering.
A Change Agent is someone who influences or facilitates change within a group. He serves as a catalyst for change and a lightning rod for innovation by
- Illustrating gaps and areas for improvement
- Shaping the environment to improve change effectiveness and
receptivity - Contributing subject matter expertise
- Guiding the group through the details and challenges of the
change process - Confronting facts and speaking the truth
The Organizational Change Process: Change occurs in a somewhat predictable order: Current culture, disconfirmation event, defining the future state, gap analysis, decision to change, ‹unfreezing the culture›, making changes, ‹refreezing the culture›, new culture.
The Role of Disconfirmation. In established cultures, change requires a powerful stimulus that disconfirms the current way of doing the numerous things companies do and are exposed to.
Intel at one point had to let go 30’000 people. They did it before the recession: ‹We have to change as long as we can›. They saw it coming…
In new vs. established competencies failure should be rewarded or no innovation will happen. In a low-learning-anxiety environment it must be OK to fail, but unacceptable not to try.
Transition Management: William Bridges wrote about the ’neutral zone› between ending the old and beginning the new: Moving an organization from comfort to promise is not easy work.
Lesson 2: Know how requirements engineering integrates into your development life cycles.
A life cycle is a framework that is home to many methodologies. Each methodology prescribes various activities. Each activity contains many practices that can be tailord to fit an environment. A practice may use any of several processes, with varying levels of rigor. But mind you, practices are not processes!
How much detail is enough? Upper management wants to go faster and be at the border of acceptable risk and investment.
BRUF (Big Requirements Up-Front) vs. Agile: Requirements are never complete…
Therefore it’s a good idea to use an evolutionary approach to requirements engineering:
- Start defining the scope of the system full breath, but minim depth
- Decide what not to write
- Decide when to write those requirements you will write
- Create the necessary details at the right time, always using business value and risk reduction as guides
- Revisit steps 2 and 3 often based on what you learn as you make progress and the requirements evolve
Why are there breakes on a car?
No, not to stop the car.
But, to make it safe to go really fast…
If requirements are there to slow down a project it won’t work. Requirements engineering is an offensive weapon against complexity, time to market, rework and waste.
Lesson 3: Engage directly with teams to solve their problems – your goals are secondary
How much change can the team absorb at once? There is only so much absorbative capacity.
Lesson 4: Use Evolutionary Delivery (Evo) to Drive Change
What are you going to do in the next 2 weeks to add value to your stakeholders?
EVO: Going forward with small steps allows for only small errors.
It also has a quicker ROI during the project as opposed to the big bang release.
Lesson 5: Treat Requirements Engineering as an Innovation
Requirements engineering ist the new big thing. It should support innovation:
The two models of organizational change according to Schein and Rogers go well together.
Lesson 6: Focus on Defect Prevention
Use Specification Quality Control SQC emphasizing on
- Cost and TTM reduction
- Defect prevention
- Resource efficiency
- Early learning
- Author confidentiality
- Quantified specification quality
Mistakes come in classes, whole orders of defects can be avoided.
Lesson 7: Take care in how you present your results
Money talks, but it’s not always possible to provide software’s ROI. Further important categories include
- Reaction and satisfaction
- Knowledge and skills transfer
- Application and implementation
- Business impact
- Financiel benefits & ROI
- Intangible benefits
The ROI on requirements engineering is large enough that its absolute
value is irrelevant.
«There is nothing more difficult to take in hand, more perilous to
conduct, or more uncertain in its success, than to take the lead in the
introduction of a new order of things.»
– Machiavelli
«After you’ve done a thing the same way for two years, look it over
carefully. After five years, look at it with suspicion. And after ten years,
throw it away and start all over.»
– Alfred Edward Perlman
«It is not necessary to change. Survival is not mandatory.»
– Deming
http://twitter.com/#!/WalterSchaerer/status/84003380091035648
