Skills for Scrum Agile Teams

You can't seriously suggest there are readers of infoq who learnt anything by reading this article.

@Rhys K

for sure this article could suggest to you a way to improve: how to provide feedback in a constructive way.
under the column "Behavioral skills" indeed you find Collaboration and Conflict Management. The same for Developers, QA and SM.
if you need more help, I can suggest an ever green, the perfection game

You wrote: "The team needs to ... be committed ...". What you mean by commitment here?

1. Commitment - is to do one's best in a sprint?
This may not be sufficient to complete the sprint successfully, because of some wrong assumptions during the planning, some unexpected problems like side effects of code changes from other teams.

2. Or commitment - is to really complete all the planned user stories, no matter what it costs? Even if it means overtime?

If you mean the 1st one, then it just means to be honest to the colleagues, to the employer, to the customers who will use your product. From the company management perspective, this is what every employee is expected to do and is paid for. No matter if you work by scrum or not. In this case only the one's best efforts are guarantied. There is no guarantee, that the plan will be completed till the sprint end.
If there's no guarantee, then what's the difference from the non-scrum projects?
If there's no guarantee, then such a "commitment" is worth nothing, "commitment" becomes just a buzz-word. Nothing more.

If you mean the 2nd one, then "commitment" means guarantied result. It is a real difference from many classical projects. It's kind of a small "fixed price" contract. But for the team it means some risks, mainly the risk to work overtime. To mitigate the risks:
- the team can explicitly reserve some time and commit to do less than one would expect
- the team can prefer quick and bad solutions for some user stories, if other stories took more time than planned. Reworking/refactoring this means additional efforts in future, which is not planned in the project budget.

So, with fixed week hours there is no real "commitment".
Either there is no guarantee that the work will be 100% completed till the end of the sprint.
Or the work will be 100% completed, but it will cost some reserved (and may be not used) time and/or worse quality, and thus make the work more expensive.
Neither is good.

So, real "commitment" is not compatible with the fixed working week, which most employees have. Thus:
- "commitment" in scrum is just a buzz-word
- scrum is not compatible with the fixed working week

first, the 5 engineering aspects (unit testing, automated builds, etc) are absolutely the right thing to do, and still a hard sell in many organizations

promoters of 'agile' methods should focus on these practices and de-emphasize the 'behavioral' aspects

in the real world, that is, 90% of business environments where software is developed, the impediment to the behavioral recommendations is the same source of all software problems: management

the average manager's understanding of scrum or xp or any 'agile' method is limited to one thing: short deadlines

that's all managers care about; all they know how to do is look at a calendar

everything else will be subgrogated to the calendar

most agile methods have some element of adjusting based on feedback, but in the business environment it's still every man for himself, and nobody gets rewarded for telling the truth


so any process or method where developers are encourage to be honest will fail

i wish it were otherwise but that's the reality

May be not for you! I come from a world of IT services, where teams claims following agile may not follow 20% of what is said above.

Good question. It is important that we be clear on how we use words.

When I teach, this is what commitment means:
"We commit to achieve these stories, or to communicate with you (the SM, the PO) ASAP when we discover things that threaten our ability to achieve them."

This combines the reality that software development is usually a research activity (we have never done exactly this thing before) with the fact that a promise has been made, upon which others have made their own commitments.

Experience shows me that it is important that teams actually make promises to their POs and then talk about having achieved them or not. This is what motivates learning and process innovation. Making promises and never talking about your success rate communicates "we don't really care", which erodes true communication and collaboration. The team that delivers 60% of what they commit, iteration after iteration, is not doing Scrum - they are not learning and improving.

Software development as a business activity requires accountability: in Scrum we make scope variable but highly value predictability of estimates. These two balance each other out and can create teams that learn to estimate well and deliver reliably on their promises.

Or not ... no process or method can compensate for people with bad attitude.

Speaking as a coach: What if we focused on the behaviour of those managers who set unrealistic expectations? Could that help?

Deborah, which ones do you mean - inhouse or those on the customer-side ;-).

Most important to me is that those "inhouse" managers have the responsibility to create environments that development teams need to be efficient. They don't have to understand what all the Scrum details are. But, they have to understand that there's a relation between efficiency and the quality of the environment they offer. The article above mentions parts of it (hardware, software, soft-skills, processes, ...).

My experience shows me that you can persuade those managers a bit easier to change from their old behavior to a more team-friendly one if they are in trouble with, for example, the team, with customers or with the upper management, or if they loose money or have an escalation management on a daily basis. But, maybe this is already the point of no return for the team (frustration, mentally resigning, resignation).

I still wonder if it would be better for the team members to leave the company immediately. What kind of upper management do we have in such situations that allows those managers to waste time, money, or motivation. You can't expect that the upper management will help here. On the other hand you will never have a team structure that allows to solve this through a 100% boycott or a revolution.

Once you learn that SCRUM is an acronym for SCRewed Up Methodology, it all becomes clears.

AGILE is such a worst thing that it focus only on the project and forgets totally on individuals. Individual would become a machine doing the same work again and again and forgets his personal development and totally forgets the family.

Funny, to me agile is all about individuals. And forgetting family? Sustainable pace is an important aspect of being agile.

Commitment in a SCRUM and Agile framework is all about commitment to quality. At the start of the sprint, SCRUM team plans the user stories to be worked on. On a daily basis we re-estimate on how much more time we need to work to deliver quality working software. In some cases, we realize in the middle of the sprint that not all we initially planned can be delivered, so we scope them out and focus on the more prioritized user stories.

We do not commit quantity in SCRUM but we commit on quality.

We do not commit on a fixed number of backlogs, but we can commit based on previous sprints on the number of story points we can deliver.

I agree, attitude is a BIG factor if you want commitment regardless of methodology used.

On the contrary, when we practice AGILE, one consideration is to ensure that our software engineers and Q.A. will have personal time. We respect deadlines but our customers needs to be oriented that we don't deliver fixed number of features, but we can deliver working piece of software. Gone are the days that we work ourselves to death just to meet the deadline. Stakeholders need to realize and learn to compromise quality vs quantity.

Good article.

I think "There are several things which cause an agile project to be different from projects based upon more traditional approaches, including..." is in same in every project whether or not the project used AGILE. This is a basis of a project. not only AGILE.