MenisMas' Blog

There are a lot of books, articles, videos and tweets about Leadership where you can find lot of information and advices to improve your skills as a leader, but I have just found few of references to the people who makes a leader a much better leader, leader’s teams.

I have to say when I started professionally I expected my boss to give me all instructions to follow and all the details I need to complete my work, but I didn’t realise my boss and the rest of the team expected me to ask the right questions and add a value to the work done by the team.

With the years one of the biggest lessons I’ve learnt: collaboration and cooperation between leaders and teams make a better and faster success. It is not only about a great leader leading sheeps, it works but giving as a result an average success, it is about the balance of a great leader leading a great team, then the success will be brilliant.

A team following and accepting all instructions and details given by their leaders is an easy work for the leader and does not allow an environment for a continuous improvement. Otherwise, a team which is able to challenge their leaders and help to build an environment where collaboration is the key will help to grow both leaders and teams.

Let's say we are part of an Agile team, running sprints to develop a software product where developers, testers, product owners and scrum masters are collaborating to deliver new features or functionalities in each sprint. One the classic discussions are around testing within sprint or testing after the sprint, but let's have a quick look to both approaches.

Testing within the sprint could mean that developers write Unit Tests and Code as first thing in the sprint and deliver the new code to QA Team some days before the sprint ends to let run testing plan and see if new code is bugs free.

In the other hand, testing after Sprint ends could mean developers are focused in write the new functions and features while running the sprint and the code is released to QA Team once sprint ends, letting developers to run a new sprint.

My thought came to my mind when running running sprints following the first approach (testing within sprint) developers were always delivering new features to QA Team with a very tight time to run the testing plan. We made the decision to run testing plan at the beginning of the next sprint, which means developers would prepare a new release ready to test when Sprint ends and move to the next Sprint. This helped to let the Developers understand the release ready to test should be under proper testing (developer testing) as they are the owners of the work delivered, letting QA Team to be focused on ensuring the software works as the Product Owner defined.

With QA is not testing we say Developers proceed with the testing of the new code written, following TDD they test their code runs properly and put in the output the expectations for the given inputs. With this Development Testing in place, he QA Team will run testing plan rounds being focused in the functionalities, ensuring the quality of the product meet expectations.

Of course this is not a must, each team should find their path at any moment and look always to the results to see if they should tune their current process, an specific approach could work for a particular moment developing a particular product with particular team members, a change in the equation could produce a change in the approach followed, just keep looking yourself to keep moving to the great success.