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 with the purpose of explaining “Why features teams are not enough!” to form a good agile team. This event – Agile Breakfast is organized by Sybit. We were thinking what to share with the community so we decided to talk about this common challenge that many organisations face nowadays.
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 behaviour. 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 within each different agile team.
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 organisation. 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, the setup of each agile team was not delivering the expected result; 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 is an Agile Team that could basically consist of any feature teams and additional individuals that are needed to fulfil 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 agile 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 organisation.
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.