Software that fits is the ethos of Skyscraper Software. This site explains the ideas behind the concept of creating software that fits.

One of the main goals of everything we do at Skyscraper Software is to delight our customers. By following the principles of lean software development we try to achieve this goal.
Our customers can be businesses or people. The goal is the same, the result must also be the same: software that fits. In the next sections below we explain our overall process of lean software development, impact mapping and behavior driven development (BDD), and how it helps us create software that fits.

lean software development


To describe lean software development on one page is almost impossible, so we've focussed on what we think are the most important features of lean software development.
If you want to know more about our other lean development ideas, or you want to discuss something just get in touch with us.


To be able to get delighted customers and excellent software products, you've got to understand the business and have a very good understanding of technology.
For a product to be developed successfully, during the development information has to flow. The quality of the information flow between the customer and the development team, and among the team members determines the success of the product development. And in the end if the customer is delighted.


At Skyscraper Software we always focus on people, not on systems. Be it employees, customers or suppliers, always respect people.
Excellent software products are developed by people with expert technical knowledge in many areas. Technical experts are first of all member of a team and second they are specialist in a certain area.


We always focus on maintaining and creating knowledge within our organization. Technical excellence is something we always strive for.
And also, developing a product is all about learning. So if we defer decisions, we can learn more. Which comes down to just-in-time commitment and decision-making.


Deliver fast is not about haste. It's about being able to respons to customer's needs, in a reliable manner and again and again.
To able to deliver fast, and at excellent quality, processes need to be continuously improved. In doing so, we must guarantee that quality is build into our products.

more on lean software development

get in touch

impact mapping


This section describes how we start our product development process, with impact mapping.


An impact map can best be defined as a mind map which visualises scope. And also very important the assumptions it is based on. It is a mind map which is created during a discussion which is centered around four questions: why? who? how? what?

  • The answer to the why question, defines the goal. Why are we doing this?
  • The who question answers for which actors we're doing this.
  • The how question is all about determining the impacts we're trying to create.
  • The final question, the what, is about the deliverables, features and other activities.


To start the impact mapping we usually organize a workshop, where we'll try and answer the four questions. This workshop can take half a day, or a couple of days to complete.
It is important that technical experts and business people are present at the workshop. This is the starting point of the whole product development, so it is esential that everything is clear for everybody involved in the development.
In this workshop we try to define the real goals and create the impact map, complete with among other things budget, measurements and priorities.


When we've identified the most important needs or features, we're going to get started on the development of the minimal viable product. Making sure the customer can use most important features the software product as fast as possible. This is where the build, measure, learn cycle starts, so that we can verify our assumptions early on and move forward from there.



Once we've got an impact map, and we get started developing software, we use BDD. Impact Mapping gives us the impacts or behavorial changes we want to achieve with the software. From this and the rest of the impact map we're able to write user stories that fit nicely with the BDD structuring of user stories in scenarios and the format of "given-when-then". In doing so, we get a very good understanding of the business case.
Once we've got the user stories written down, we can start writing tests and code for the user stories and its scenarios. Here we follow the principles of Test Driven Development.


To implement BDD scenarios we use Test Driven Development. TDD helps us be more productive and write the source code in small, high quality steps. Test cases are defined and unit tests are created and in the end code is produced. When all unit tests concerning a scenario are ok and implemented the scenario should work completely.

There is a lot more to BDD as explained above. Want to know more, just get in touch