If you understand this classic joke – you get the point
“Whitebox Expectations ” is about to spoil this great joke. Sorry, – but it’s for all the best reasons.
“Whitebox Expectations” is a holistic approach to generate the best input to the solution. We have packed the best from requirements engineering, testing, risks and configuration management, to ensure that the evolvement of expectations to the solution is optimised to serve all stakeholders involved .
We have done that, because interviews with 10.000+ development professionals has made it painfully clear to us, that the current way of communicating between all stakeholders has failed. Despite the fact that many good methods has been proposed.
We have seen:
– That different roles need different competences. Thats why ” Whitebox Expectations” is role based competence development
– A common framework for understanding is required! That’s why “Whitebox Expectations” is a holistic approach across classic disciplines with a strict defined terminology
– No one size fits all! That’s why “Whitebox Expectations” is driven by the benefit you will achieve and then enabling you to make the best choice of methods and practices
– Splitting up the responsibilities in requirements, risk and test destroys the “flow”! That’s why “Whitebox Expectations” support the “flow” (from e.g. a need is expressed and until it is validated that the solutions is supporting it)
– When information is spread around, it is not used! That’s why “Whitebox Expectations” introduce a corporate memory
– The Product Owner have to be superman! That’s why “Whitebox Expectations” is a corporate competence
Whitebox Expectations covers some disciplines, that – unfortunately – has been managed rather separate. This is explained here….
Why did the industry fail to manage all the stakeholders expectations?
While "Whitebox Expectations" claims to solve a problem that all have experienced, we better be shure why it wasnot solved before!
Short answer: Underestimated complexity!
Communicating needs and requirements are surprisingly difficult – even between the stakeholders.
Everyone feel that their perspective is obvious
No-one feels really understood
Root cause: Misunderstandings, small but many.
Add to this:
- There are many stakeholders
- They have very different background
- They have different motivations
- The key stakeholders are those that are the least “accessible“
- New Technology opportunities appears fast
- Sometimes faster than a project can react to them
- Tools to support the communication has been very poor
Suddenly it seems reasonably to believe that poor communication on a very complex matter is constantly leading to misunderstandings that jeopardize development projects.
Failed strategies: Individual training in isolated disciplines.
The last 3 decades we have seen a lot of effort going to test/risk/requirements training to individuals, but it has hardly improved the industry’s performance. The market for these individual trainings is declining for good reasons, – because it is a teams game. The sports analogy is appropriate. Even the best trained individuals cannot make up for a poor team performance and if they on top of it all are to narrow specialized, no one should expect a high performing team.
“Expectations” is covering the three steps to corporate competence
1: Training of all the basic competences required
2: Design of the company specific practice and design of tool support
3: The company specific training to individuals.
“Whitebox Expectations” is a holistic approach to requirements engineering, testing, risk management and configuration management, called Expectations Engineering. Holistic, because the synergy that occurs when they are performed as one, are so much bigger than when performed as individual disciplines.
Expectations engineering is how we should respect the complexity, handle it, avoid the misunderstandings. With teams that are trained expectations engineers you can ambitiously go for the business opportunities, and expect reliable results. Better products, faster.