The next 2 steps on bbv’s Agile journey

This is the keynote I gave at the bbv TechDay 2011. bbv TechDay is a company internal conference held once a year to distribute knowledge gathered through the year amongst our software developers, testers, project leaders and so forth.

During the last couple of months, two main topics for improvement have emerged that will keep us busy during the next year. Discussions in our Scrum Master and Product Owner Roundtables have shown that all our Scrum teams identified very similar areas that need improvement: Improvements needed to deliver software with even higher quality and velocity.

But let’s take a look at what had happened in the last couple of years, first:

Our Agile journey began about 9 years ago. A few XP practices were introduced – like a daily stand-up meeting or unit testing. However, it was too early to be called Agile.

For me, Agile methodologies and practices really started in the year 2007, when some projects introduced Test Driven Development. Once the unit tests were in place, we noticed that we started to block us inside the team, when code was committed that was not working. Therefore we introduced Continuous Integration.

In 2008, we started using Scrum as our main development process. As a result, we had to keep our code as agile as our process. So we put much energy into Clean Code practices. Only with easy changeable code we still were able to deliver new or changed functionality at a continuously high pace.

Then, the journey got quicker and quicker: We learned how to deliver multiple projects with a single Scrum team and we introduced Kanban to master challenges that software maintenance puts on planning.

With all these new practices and methodologies we had to push Team Learning. Coding Dojos and Roundtables started throughout the teams.

Working on projects for several years taught us that keeping software working requires more than unit tests and manual testing. Therefore we started experimenting with Acceptance Test Driven Development. Today, several teams use so called Story Acceptance Tests on a daily basis or even write these tests in test-first style.

With more and more experience on Scrum we had the chance to take on larger projects and expand our knowledge about Release Planning and Scrum-of-Scrums.

 

So much about our Agile history. But …

… what will happen next?

I had a lot of discussions this year with several members of all bbv Scrum teams.

And I identified two main areas where most effort is currently put in.

The first is …

… Quality Assurance.

How can we deliver software with maximal quality in minimal time.

To achieve this, we have to minimize the duration of quality feedback cycles. We don’t have the time to wait until a release candidate is built and push it to the testers and wait for the tons of defects they will find, just to start the development-testing-cycle again, and again.

We work with Sprints. And we have to know that our software works at the end of the Sprint. If it does not work, we have failed. Of course, this is an ideal. But to achieve our goal of maximal quality in minimal time, we need to try as hard as we can to get as near as possible to this ideal.

There will always be additional testing on release candidates – for example due to not available third party systems or hardware. But the number of defects found by these tests need to be almost zero.

Let’s take a look at what has to be done to get a Sprint increment that fulfills our quality requirements:

We can distinguish between quality assurance activities that

• support the team to deliver what is needed with few defects
• critique the product to check whether it fulfills user, business and non-functional requirements
• are business facing, that means they check whether we build the right thing
• are technology facing, that means they check whether we build what we built in the right way

The slide shows the activities most prominent in our projects.

 

Now, let’s take a look at where the strengths of our developers are – of a typical good Java, C++ or .Net developer:

The main expertise of our developers is clearly the lower left quadrant: Test Driven Development, Clean Code and other Engineering Practices. The developers build also the Story Acceptance Tests and perform some of the non-functional tests, but it’s not their favorite.

When we take a look at the skill set of a typical good tester …

we see that his home is on the critique the product side. The strengths of our testers are checking whether the product fulfills what is required and whether the functionality is provided in a way that is useable.

 

In our Scrum teams there is another role that plays a major part in quality assurance: the Product Owner.

The Product Owner is responsible that the correct functionality is implemented. Therefore, the Product Owner plays an important role in Story Acceptance Testing and Exploratory Testing. However, the Product Owner alone will likely only scratch the surface.

 

Now, let’s put all together:

And what do we see?

We have a big hole on the critique the product side. Especially, we have a gap between the developers and testers.

If we want to fill this gap we need to define a new role:

This role connects all existing roles. The skill set includes all business facing testing in order to support the Product Owner in verifying whether the functionality wanted by the Product Owner was built. The main focus lies on Exploratory Testing.

The new role closes the gap between, testers and developers, too. The past has shown that the way our testers are used to work does not match the fast, incremental and iterative approach of our Scrum teams. Their strength is in testing release candidates. While this style of testing is demanded by a lot of our customers, it does not fit the claim of our Agile software development teams. Therefore, this new role takes the lead in testing to critique the product, but works closely with the developers so that there is no gap anymore. The feedback is immediate and steers development.

Let’s sum up: The new role is the expert in delivering software that fulfills users and customer needs and works well.

Although, this covers three out of four quadrants on the slide, I consider the duties of this new role and the duties of the developer role to be roughly equal in size and needed knowledge.

 

Finally …

… we still need a name for this new role.

Or as I prefer: let’s call everyone developer with focus either on features or quality.

Next year, we will have to find ways to grow these kind of team members.

 

Now, the second step on our Agile journey concerns …

… our Scrum Masters.

Although this was a discussion that went on since the very start of Scrum in our company, the new Scrum guide enforced the debate.

 

When I look at the job our Scrum Masters do today, then I see mostly this:

The Scrum Masters cleans up the mess of the team. He keeps the Scrum Board clean, updates the burn-down charts and more or less moderates the Scrum meetings. But mostly, that’s it. The daily work is dominated by normal developer stuff.

 

Just a quick reminder taken from the Scrum guide:

There are two main responsibilities for the Scrum Master:

• The Scrum Master carries Scrum outside the team.
• The Scrum Master seeks ways to get a more productive team, delivering higher quality.

The Scrum Master first has to push quality inside the Scrum Team. This includes engineering practices like TDD, ATDD, Clean Code, Continuous Integration, Coding Dojos, Learning Resharper shortcuts, and so on. This also means finding better ways to work together like Pair Programming, discussion and decision culture.

But it does not stop inside the Scrum Team. The Scrum Master has to go and see all people in the whole Project Team – all people involved in the project, including operations and support. Tell them why we work this way, convince them that this helps them, too.

If your project runs successfully, then go on and talk to other people at the customer’s site.

And finally, do your part inside bbv. Help other Scrum Masters or consult other teams. Only if we share our experiences, we can become better Scrum Masters in a reasonable amount of time.

Next year, we will therefore look at ways how to coach our Scrum Masters to get the skills needed for all this.

Developers with a quality focus and leading Scrum Masters are the two main points we need to tackle in the near future. Doing so, we can keep our leading role as Agile consultants within Switzerland and hopefully beyond.

It was a lot of fun – and hard work – so far; but I’m looking forward to continue our journey on the Agile path.

And remember: Agile is a direction, not a destination.