Archive for October, 2012

Why features teams are not enough!

Posted: October 29, 2012 in Agile, Process Improvement, Scrum, Software Development
0

Hi guys, this time I am co-writing this post together with Sven Schnee. Couple of weeks ago we were invited to speak at the local community. This event - Agile Breakfast is organized by Sybit. We were thinking what to share with the community so we decided to talk about a common challenge that many organizations face nowadays. The topic was “Why feature teams are not enough!”.

To be easier for you guys to follow we’ll tell the story of Herman - An Agile Coach.
Herman was hired as an Agile Coach in company Super Soft. He was an experienced Agile professional, in previous companies, where he worked, he was involved in several Agile transitions.
Herman took his first weeks to understand how the teams worked. After attending several demos he noticed a common behavior. The guys who were facilitating the demos always said “We are done, we do our job” but in reality they could not demonstrate anything because nothing worked. It was time for him to start doing some changes. He found several problems within the company. However one of the biggest issues was the strong presence of “Silos”; all the work of a specific component was done in a single department with few or no communication with the other departments. Once the department is done with his own development he hands it over to the next department. This goes on until all involved departments added their part to the product. Then in the end the integration usually happens with testing, bug-fixing and major problems popping up.
Super soft had several independent products that could be build/sold separated, so why not create teams that alone could release these products to the market? This was what Herman with “Feature Teams” created. He did assemble teams that alone could release a product without much help of other parts of the organization. This actually worked quite well for several months leaving Herman happy with his accomplishment.
Few months later the market conditions did change and Super Soft needed to launch a completely new product. Basically a bundle of several other independent products. Soon the initial problem that Herman had with different departments was hitting him again; this time on product level. Even though he had created feature teams that were able to ship a full product, in the scope of the new system, the feature team was not able to deliver anymore; skills like GUI design, CRM development, and some others, needed to build the system, were missing from the traditional feature team. Different product teams were developing their own products but nobody communicated with each other until the last moment when all integration problems popped up.
One evening when watching “Team-A” on TV he had a good idea. The creation of “Feature Squads”. A feature squad could basically consist of any feature teams and additional individuals that are needed to fulfill the mission. The mission in the new market conditions was to deliver full vertical features that included all the parts needed to bring the value to the customer. Despite his brilliant idea Herman still had to face problems. The new feature squads had their own little woes. Herman had to experience the pain of having a daily or planning meetings with more than 10 individuals. These meetings really took too long and the interaction between squad members suffered. He decided to break the teams, as a result he had a bigger number of teams but less individuals per team. The fact that these teams were not always collocated added a bit of complexity to the project, there were issues related to the communication and trust between members. It was a challenging path but at the end the product was released with success.
This was the story of Herman, the Agile Coach who helped Super Soft to become a better organization.
What we want to highlight is the fact that in both situations Herman had problems assembling teams. As result he did create cross functional teams, first breaking silos within departments, later within organizations.
We truly believe that companies should assemble teams in a cross functional way. The team alone is able to release the product without any extra involvement from other teams. Of course in reality there are always more dependencies but in theory this is how it should work.
This presentation can be found on my slideshare. And Sybit post about the presentation can be found here.
As always please give me your feedback,
Chers,
Luis

Why is it difficult to have a “Green Build”?

Posted: October 22, 2012 in Agile, Scrum, Software Development
8

Hi guys, in my last post: Why is it important to have a “Green Build” I did explain how important is to have a Green Build. In this post I will explain several reasons why it is so complicated to keep it green.

Before I start to enumerate several possible reasons I want to highlight the background of our system. We have a long way to go until we are truly agile. We have all the necessary skills within the Feature Squad to release a product but the organization is structured in different departments (System Build, Development, QA, etc.). This set up is responsible for the presence of silos. We are working toward an organization where silos will not exist but this is how organization works. On top of this the developer must wait several hours to get some feedback about what he did. He only knows if he broke something several hours later. Now with this information you will understand better the problems we are facing.

There are four different areas that I want to touch:

  • Code changes
  • Tests changes
  • Build System
  • Test System
Based on the previous topics I want to tell you a story of a project where I was involved. It was a complex; the technology was new and difficult and the teams were not all collocated. I mentioned before that the developers had to wait several hours to get the feedback to know if they had broken something. As a consequence the product was constantly broken. In this case the basic unit test coverage was not enough to prevent the developers from breaking functionality. These teams still have a long way to go to become truly Agile. One of the areas where we could see this was by looking at the frequency of their commits, some of the guys did not commit their changes for days in a row. Which resulted in a lot of time lost trying to merge their changes into the trunk. And above all this complexity they also had to deal with a complex version control system, allowing developers to make many mistakes while checking in.
The testing part was still acting like they were before, they were now part of the same team but they acted like they were still in the Silo’s. F.ex. new tests were still only written by the QA people, not by the developers who implemented the code. This meant that sometimes the test were failing for several days because the people writing the tests were not the ones that needed to fix the code. Another problem they faced was that when the functionality changed and the QA people were not notified that the tests would not be adapted and then fail for the wrong reason.
And finally we had some problems that showed up once in a while, but important enough to mention here. The build system did not belong to the development team, instead the build system belonged to a whole separate department. Which meant that when a problem related to the build occurred hey sometimes had to wait for several days before the build was green again.
Having the above mentioned problems meant that finding a root cause was extremely difficult.

I don’t have the perfect solution for all these problems, I have my beliefs and my opinions but I don’t know how to solve all issues in a short time. Since I do not want to finish this blog without any ideas I will give an example of another team we have where the results are extremely positive.

This small team has the ownership of everything. They own the build system, testing system, production system and whatever is needed for the work. They practice TDD, and there are no departments saying how they should work. They solve their own problems on daily basis, they do whatever is needed to make it “green”. They commit their code every couple of hours, they don’t go home if the code does not compile and all the test are green. I believe the biggest advantage of this team is the fact they know why a green build is so important. After failing so many times they understood why a green build is mandatory.

All organizations should aim for continuous improvement. However I truly believe the first step is to understand where we are and where we want to go. So if your organization has some problems, bigger or smaller, does not matter. I believe first you should realize which problems you have and define a plan where you want to go. Then just work with the rest of the organization to achieve those goals. Do not forget to empower your teams, they know what to do much better than you.

Please let me know what do you think.

Thanks,

Luis