3 Reasons Why a Cross Functional Team is Hard to Find?

Another article from Faisal Mahmood which discusses about Cross Functional Teams. It's sometimes hard to understand the real meaning behind the term "Cross Functional". So this article is a very good discussion to understand that term.

" A cross functional Team is crucial to get items to Done. However, not many Agile Teams become a cross functional Team. Some of the most important reasons they struggle to become a cross functional Team are
  1. Waterfall setup of the organization
  2. Lack of required skills
  3. “Hard roles” on the Team
1. Waterfall Setup of the Organisation

This is typically caused by the way projects are financed and resourced. Finance and resourcing units in many organizations work traditionally, although these organizations have adopted Agile. The way project Teams are set up hinder Teams from becoming a cross functional Team.

In these cases, the project financing teams do not understand or appeciate Agile. They require detailed project scope, resourcing, cost and schedule information. They have set up their processes based on traditional waterfall model. They struggle to understand the Agile notion of an emerging requirement, namely, the Product Backlog, emergent architecture, Sprint, and self-organizing Teams.

Project Teams are forced to produce detailed requirements, to predict resourcing needs, and to predict schedules based on fixed scope."

You can find the details of other reasons here.

7 Reasons Why Your Team Does not Get to Done

A new article from our author Faisal Mahmood about the Scrum Development Teams. He discusses why teams do not achieve to get the things done. Teams run sprints and sprints. At the end they cannot deliver any shippable product. Faisal mentions seven reasons of it.

" Seven reasons lead to Teams not getting to Done
  1. Team is not cross functional
  2. Unclear or absent Definition of Done
  3. Technical debt
  4. Overworked Team
  5. Late integration
  6. Change of scope during Sprints
  7. Ineffective planning
1. Team is not cross functional
Non cross functional Teams tend to struggle with getting Done by the end of their Sprints. They simply lack skills to turn the selected items to Done increments of functionality. They might lack business analysis, design, development, testing, database design or any other such skills. Team members might be unwilling to learn anything other their own well defined roles.

In many cases Teams end up with a mini waterfall within their Sprints where initially the business analysts do the analysis and clarify the requirements, then the designers design, the developers develop and if there is time left at the end the testers test the system. In case they find issues at the end, and they usually do, those remain unfixed and are pushed to following Sprints. All this undone work is pushed to the following Sprints. They just struggle to get to Done.

All the undone work leads to long, painful and expensive “stabilization phase” at the end."

You can find the details of other 6 reasons here.

3 Reasons Why Scrum Masters Struggle to Become Servant Leaders

Another article from Faisal Mahmood about Scrum Master role. He discusses three reasons of the hard parts of becoming a servant leader. "Servant Leader" term is my favourite about Scrum Master role and I think that every Scrum Master must have this attitude.
"It seems it is rather hard for some of the Scrum Masters to stick to their servent leader role. This is one of the most common pitfalls. The lure of being a manager is too strong. Knowingly, or unknowingly people keep falling into this trap. They behave more like project managers than ScrumMasters.
Several symptoms indicate that the ScrumMaster is struggling to let the team self organize and thus acting more as a manager, than a ScrumMaster. Three keys ones are
  1. ScrumMaster assigns tasks
  2. ScrumMaster acts as go between the Team and the Product Owner
  3. ScrumMaster makes decisions on behalf of the team
We’ll use Sally, as an example ScrumMaster to explain this anttipattern."

You can find the rest of the article here.

3 Common Scrum Master Mistakes - Part II

This is the second part of the article 3 Common Scrum Master Mistakes - Part I from our author Faisal Mahmood. In this article he discusses the consequences of these mistakes, typical causes and a few ideas that can help you to avoid making these mistakes. We think that this is one of the best articles that we've read before about Scrum Master role.

"The Team becomes reliant on a single person making decisions on its behalf. It kills self-organization. The quality of the decision making takes a sound beating. The Team has to live with the decision made by one person instead of leveraging collective intelligence of all the Team members.

These decisions might work fine, at times, because of the individual experience of the Scrum Master. However, over the long term a single person struggles with making quality decisions on his or her own, compared with the Team conducting a healthy discussion and utilizing its collective experience and intelligence in making such decisions..."

You can find the rest of the article here.

Tech Leads will Rule the World?

Here is the next contribution of Assembla. As you can remember from their webinar, they have a different approach to Agile Methodologies. In this article, they discuss the necessity of Technical Lead role in an Agile Team who works in a distributed environment. They have the argument of that Agile Teams cannot afford management roles in the organisation. It's a very interesting discussion but as ScrumTurkey we still believe in some management roles like Scrum Master in Agile Teams. What do you think? Here is the article:

"At a Google office the other day, I heard someone say “Tech Leads make all the decisions at Google.” They also make the decisions here at Assembla. If you do distributed software development, they should be making the decisions at your company
A Technical Lead or Tech Lead is a software engineer who also leads a team. The Tech Lead picks the important tasks, answers questions, solves problems, assembles a release, helps new team members – and does development.
We think that distributed teams require Tech Leads. These teams communicate with code and other deliverables. They need to work with a developer who can read the code...."

3 Common Scrum Master Mistakes - Part I

Another article from our author Faisal Mahmood, he discusses common Scrum Master Mistakes. He mentions three common ones and he says that "That person is acting more as a manager than as a Scrum Master". This is the Part I of the article, we will share the others in the following days.

"It is difficult for some Scrum Masters to stick to their servant leader role. Because of lack of support and limited experience, they fall back on what they know best – traditional management. Knowingly, or unknowingly, Scrum Masters keep falling into this trap. They start to behave more as project managers than as Scrum Masters.
Several symptoms indicate that the Scrum Master is struggling to let the Team self-organize. That person is acting more as a manager than as a Scrum Master. Three keys symptoms are
  • the Scrum Master assigns tasks
  • the Scrum Master makes decisions for the Team
  • the Scrum Master acts as a go-between for the Team and the Product Owner..."
You can find the rest of the article here. Enjoy your reading.