How do we work? A typical project lifecycle here at ReQtest

So how do we do it exactly? This is what a typical project lifecycle for the ReQtest team looks like.

We never write requirements several sprints ahead. We do this to eliminate waste and to support “just in time-commitment”.

When planning a sprint we pick requirements from the backlog and then (and only then) do we supplement and ‘flesh out these’ requirements. This is how we apply our “just in time-commitment”.

We use a Scrum board and quick, 5 minute morning meetings to discuss progress and the day’s plans, and if anything else needs to be said, we normally add it as a comment in ReQtest.

During development time we focus on design, writing code and providing feedback to the project owner. Other models would probably state that one “tests the system”, but we prefer to ‘see the whole‘ and ensure that the focus is on “providing feedback” so that the causes of any defects are found and eliminated.

After all, the work is about so much more than just about finding bugs. In our view, we should focus more on validating and ensuring that the features that we’ve developed provide value to the users. If we find out that a feature is not good enough, we remove it from the planned tasks, thus eliminating waste.

We do not write useless design specifications, and we have very few meetings. Too many meetings ruin the entire team’s productivity, so we don’t hold many formal meetings with entire departments or the whole company, unless we’re all having a drink on Friday afternoon that is. We consider most meetings as distractions and a slow method of internal communication, so to keep our waste down, we have the quick 5-minute meetings mentioned earlier.

We carry out thorough usability tests to make sure that the newly developed features are of high usability and value as well as to decrease waste.

Henrik keeping a watchful eye during usability tests with real and actual users of ReQtest.

We save time and money by implementing any design changes in the system after the usability tests have been conducted. That way any changes from the initial mock up cost us almost nothing.

During development we do not focus on writing unnecessary documentation and we don’t document using traditional voluminous system documentation. Instead we use automated testing, pair programming, and a few very important business rules as our system documentation. In comparison to other projects where most of us have worked, we document very little. When I talk about how little we document, I do get many questions, as it is still controversial to have so little documentation, but we have found that this approach works. We document what is necessary, but only what is necessary.

Under development we use a Kanban board. We have put restrictions on how many tasks may exist in the columns. The Kanban board makes it easier to prioritize if urgent tasks come from support or if there are problems in the production environment.

Each of our sprints is normally only two weeks long. This way we support the principle of frequent deliveries as well as the principle of timeboxing, which forces us to work on the most important deliverables. We know which deliverables are the most important from our requirements (which we formulate late) and which we also scale, for example, using the MoSCoW method.

In parallel with development, we carry out our testing. When the sprint finishes testing is done too.

Our team is hugely empowered. We always credit the team for successes. In other development models it is common to raise only the star developers. By working lean we have a self-organizing team comprised of people with complementary skills. From a management perspective the team does not need to be managed in a traditional way since the team manages themselves and very ably too.

Most importantly for ReQtest as a company, however, is the fact that we are not dependent on any one single person. Often when I talk to customers they say they have the problem I like to call “Mike’s system”; they are highly dependent on one single person, often a developer. If this person is not present, the customer has a problem. We are not dependent on specific developers, partly since we often program in pairs and everyone knows a lot about each other’s work, partly because we use test automation, pair programming and we regularly let developers test each other’s components. Of course our approach is combined with individual development. For example we have a developer with a passion for complex business logic and we have others with a passion for user-friendly interface. They do carry out a lot of pair work, however the organization also allows them to evolve their personal interests