How we use the Lean philosophy at ReQtest

We use Lean principles almost religiously, and although we are no Toyota, we find that there is no better way for us to maximize our productivity, communicate effectively and ship an excellent product in the most efficient of ways.

In fact, we’re all strong proponents of Lean principles, and we use a number of these principles all the time, every working day at ReQtest.

Eliminate waste

The worst form of waste in system development is almost certainly redundant, unnecessary features. Early on in my career, I was involved in implementing a sales support system for a client. The standard software contained a module to send bulk emails that was originally built for U.S. customers. The team spent a huge amount of project time understanding how the function worked and determining requirements for our client-specific implementation. After several rounds of revising requirements, implementing, reviewing, and fixing, the module was finally completed.

To my utter disbelief, we discovered that the client’s processes had no pressing need for bulk emailing as they were already using a cloud based bulk email sender, so the module was never deployed in production. Guess what our next project was? You guessed it; it was yanking out everything deemed unnecessary in the system, which included the blessed bulk email function.

In this case, the “bulk email” function is a crystal clear example of “waste”. It was of absolutely no value to the client, yet caused significant costs in terms of training, requirements definition, testing and correction. In hindsight, it was obvious to everyone that all that time should have been spent on something the client actually wanted instead.

Just in time commitment

We prefer to decide which requirements to include in the next sprint as late as possible, typically during sprint planning. Furthermore, requirements are not written and described in full until they are needed. According to the Lean principle of “Defer commitment,” we should make decisions which affect commitments as late as possible, which is why this approach is also called “Just In Time Commitment”.

By delaying the ‘freezing’ or ‘setting in stone’ of requirements until we have tested and evaluated different options, better decisions can be made, decisions based on the facts and experience which we have gathered, rather than decisions based solely on our imagination.

Deliver Fast

Another Lean concept that we use is that of “Deliver Fast”. We find that this approach not only forces us to think of how to plan our work more efficiently, it also cuts down on waste, both in terms of time wasted as well as wasted code and implementations.

Even if there is no pressing need to deliver to the client so rapidly, the frequent internal deliveries help us to spot anomalies such as the redundant email feature mentioned above, and additionally, we can keep an eye on how well our progress is shaping up when compared to the product roadmap.

Prototyping

In addition to the above, we also use a combination of prototypes and usability tests. According to the ‘Amplify Learning’ principle of Lean software development, “The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input”

We take this credo a step forward and use prototypes to quickly produce tangible and visual solutions which work well as a basis for dialogue with our clients, users and fellow team members. We also conduct usage tests, also known as “usability tests”, which we plan so as to give us validation from our end-users as early as possible. In combination, these two techniques give us valuable, early and low cost feedback using which we can vastly improve the quality of our requirements.

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.

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 one week 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.

When development is completed, 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.