When Agile Steps on Its Own Tail: an observation from tranches

Every profession is associated with certain objectives and attributes, which allow to distinguish it from another one. The same understanding exist or should exist in IT. When we run a project in an Agile Scrum methodology, we usually recognise three roles: Project/Product Owner, Scrum Master and a Team. It is simple, but the devil is usually sits in details. OK, the only not-detailed-yet element of the Scrum project is the Team. Let’s analyse it.

People cannot be stopped in creativity and it is good. It becomes not so good when creativity losses the meaning of what it has created. What we know about the Scrum Team “by the book”? It is just a team of people doing IT development. How professionals fit in the team? Well, all team members are assumed to be professional though with more or less experience. So far, so good, but let's look at a daily reality.

Case 1. The Scrum Team includes: 2 senior Developers (SD), 3 junior Developers(UD) and one Business Analyst (BA). The team is planning a Sprint and the SD propose 2 days for particular task to realise, the UD ask for 3 to 4 days and the BA asks for 7 days anticipating problems with conflicting interests of the stakeholders. A common voting ends up with 3 days. Question: why BA has to work 2 times faster than others only because there are more Developers who do not know stakeholders well enough? Question: can the BA's work be done with quality if stakeholders still have conflicting interests?

Case 2. The Scrum team includes: 1 senior Developer (SD), 3 junior Developers(UD), one Business Analyst (BA) and 1 Technology Architect (TA). The team works on a big programme together with several other Teams. The overall assumption is that when Teams deliver their works over several Sprints each, the programme’s task will be resolved. In one of the Sprints, the TA identifies a problem, which could be resolved only across several Teams; if it would not be resolved, it can stop the Team work after the next Sprint (I hope you have guessed already that in this case the Teams and Sprints have certain internal dependency above the tasks of each Team). The TA reports the problem to the management and starts resolve it, which requires much longer time than the current and next Sprints can allow. The Scrum Master furious – the process is broken! (I mean the Sprint process and related time allocated to it up-front). What the TA has to do - go with the Team and hit known wall (and stop), or try to resolve unforeseen problem and save the Team? According to Peter Drucker, "Management is doing things right; leadership is doing the right things”. OK, but do professionals work for the sake of process or the process has to be tuned around professionals?

Beside obvious problems mentioned above, there are two more ones. The professional objectives of the Architectural work are in the resolving on-going problems regardless resources required, especially if they prevent us from solving the main task; the objectives of the Scrum Master work is in following the process regardless of circumstance because the assumption is that the Team is capable to resolve all on-going problems (or, on a contrary, the Team comprises no professionals and the only hope to deliver the outcome is to follow the prescribed process).

We can make a few potential conclusions already: a) A Scrum Team cannot solve all problems coming its way; b) A Scrum Team may be mistakenly used for inadequate task; c) A complex tasks, requiring significant architectural work up-front, cannot be solved using Agile methodology unless the architectural cross-Team solutions [aka a framework] are decided and constructed before the Scrum Teams step forward.

Well, there is always a risk of using a ‘wrong tool for the task’. Nonetheless, how can we protect Agile methodology from wrong using? What ‘controls’ or prerequisites should we have to still use this method in big programmes?

In both aforementioned cases, the problems raised because the operational framework defined by Scrum has a couple of small cracks. The first one: the Scrum Team does not recognise the different professional objectives and all members have the same rights in the making all decisions. The second one: the Scrum Team misinterprets "cross-functional" expertise of its members as cross-professional. In small/short projects with a few Sprints, like for modifying a Web Page layout, these cracks are negligible; in the big multi-task projects with several Sprints needed for each task, these cracks can destroy the entire work.

Yes, a Scrum Team can ignore titles of its members, but no team or work can ignore competitiveness. You can compose a perfect team of fire-fighters comprising veterans and junior fighters, but they still would not know how to open the flood-gate on a river to get necessary water source while all of them can deal with water. In the mixed Scrum Team, it should ‘manage’ the professional decisions of minority specialists having no clue about what they deal with, which leads to the idea that different professional members of the Agile Team have to have "more equal" rights to drive the behaviour of the team regardless pre-defined Scrum process.

The only conclusions or rules I can make from this real world observation is that:

1.The Scrum Team has to be professionally homogeneous though with different experience to be the most effective

2. For complex tasks, there should be heterogeneous Scrum Teams in the project cooperating with each other to deliver the results in the most effective way

3. Before the Scrum project starts, the management has to decide what it wants to maximise - effectiveness (result) or efficiency (process). Delegation of this task to in the teams is like asking for a magic and risks ineffective and inefficient work environment.

P.S. Another option from the tranches. We assume that we can preserve some Agile rules and free to change others - such assumption is incorrect and is usually punished by either a failure of the work or by a violation of classic Agile riles. Recent experience of one of friends of mine has demonstrated another use of Sprints though in violation of classic Scrum again. The latter is assumed that the outcome of a Spring is a result valuable for the stakeholders whose requirement the Scrum team wants to meet. Again. if the Scrum team contains specialist of different professions with different professional objectives, the team malfunctions by nature mismatch of these objectives. When managers or Scrum orthodox masters declare that people should get in agreement, this is the first and very big wrong step - people are not in due to agree with each other because this is not a precondition of their employment, their possibly different cultures and, as I mentioned before, their professional objectives. Such request can be satisfied by either a dominant of one profession over others (resulting in the obfuscated results) or by hiring a wizard.

The recommendations the fried of mine gave me are:

1. The rule of 'each Sprint has to deliver a result useful to the stakeholder' should be relaxed
2. If a Sprint team has N specialists, there have to be at least N different Sprints for the same task
3. If there are M tasks, the total number of Sprints should be, at least, MxN.

Example: we have a Scrum team comprising 2 Business Analysts, 3 Developers, a Scrum Master and a Product Owner. There are 3 non-primitive tasks identified up-front. For each task, the Product Owner defines one Sprint focusing on the needs of Business Analysts and one Sprint focusing on the needs of Developers. Thus, only the even Sprints can possibly produce an outcome useful for the stakeholders while the odd Sprints serve the Agile process itself, i.e. define what the next Sprint should deal with. The time periods between Sprints should depend on the complexity of related tasks and the sum of these periods should define the overall delivery time. Until we continue doing the opposite in our practice, our results remain poor regardless of any Agile use.

Good luck you in making the Agile process centered with professionals and not the other way around.