No tags yet.
One thing I’ve noticed about Agile/Scrum Teams is how, well, “team-like” they are. Surely there’s something we can learn here. When people talk about Agile/Scrum they focus on the frequent sprints and the daily stand-ups but I think there is something more important and it’s subtler than just the mechanics of the repetitive agile cycle.
There are two bad behaviors that I often see in non-Agile teams that I believe inhibit optimal teamwork. These are a ticketing approach to tasking and the “nothing to see here” approach.
A TICKETING APPROACH TO TASKING
Back in the 1980s and 1990s Total Quality Management (TQM) was popular. In this model, teams defined SLAs with their internal or external customers and attempted to manage to those agreements. So for example, a team of Business Analysts may have an SLA that “all feature clarifications from engineering will be answered in no more than 24 hours.” It seemed like a good idea – set expectations about how teams would respond to each other, measure compliance, and gradually tighten the SLAs as the teams became more practiced. The result, people argued, would be predictability and gradual continuous improvement.
But a side effect of this task monitoring is that every item is treated in the way that a Help Desk treats a ticket – the task owner is under pressure to complete the task in the quickest way rather than the best way. I call it the “ticketing approach to tasking” as each individual defines the work assigned in the smallest scope possible so that he or she could complete it quickly and get it off his/her list. The assignee rarely looks at the big picture but is focused on simply what he or she needs to do to claim the task was “done.”
The next escalation of this behavior is when the task output is rejected. People from different functional teams argue over whether or not the task is complete and which team needs to work the item next. It’s so obvious that this is a waste of time and yet we’ve all seen it happen.
NOTHING TO SEE HERE
Another undesirable behavior occurs when a team member is running behind but declares that it doesn’t matter because “I’ll still finish before John, and my work can’t be utilized before John’s is complete.” Now I understand that having a non-critical path item run late isn’t necessarily all that bad, but often the person running late has other tasks scheduled, maybe on other projects, which will suffer a knock-on delay. Also, issues on non-critical-path tasks are often not analyzed carefully, resulting in mistakes being repeated in subsequent projects.
AGILE IS DIFFERENT
We have found that as we introduce Agile/Scrum, these undesirable behaviors diminish.
As team members start to feel more aligned with their cross-functional agile team and less a part of their old functional discipline team, they start to think big-picture. There’s no point in “closing the ticket” with the least amount of work if that doesn’t move the team towards its goal. Everyone on the Agile/Scrum team feels the pressure of the sprint because it’s short and the deadline is never far away. In this environment arguing over a ticket is more obviously a total waste of time and people don’t do it.
When an individual is running late, the team responds to help. The help may be tangential – writing test scripts to help an engineer test as he codes for example - but the overall team goal is held highest and this fosters the best possible behaviors.
Why does this happen? I think two reasons:
I believe that people are, in general, good-natured. If every individual can see the goal, it’s easier to pull together. In the early stages of a long, non-Agile project the goal is often too distant to pressure the team members. As a result people worry about their own needs/deliverables more than the team needs/deliverables. Again, this happens because the team need/deliverable isn’t as visible and not because people are bad.
As I wrote in Retrospectives are not Optional, I think the frequent retrospectives in Agile reinforce good behavior and weeds out bad behavior very quickly. It brings people together into the team unit much faster than on a non-Agile project.
So if you’re not agile, what can you do?
There is so much we can learn and adopt from the Agile methodology without necessarily adopting everything. Going “pure agile” is a huge paradigm shift and you need support from the highest reaches of your company to make it successful. You can, however, make improvements without going all-in. Try these:
Run frequent retrospectives on a fixed period basis (every two or three weeks). Have team members review what they did and what they learned. Have them talk about what went well and what they won’t repeat next time. This sharing will pull your team together and your team members will become more introspective.
Set short-term informal goals within your program and challenge the team, as a whole, to meet them. Instead of a two-month “code the API” task, break this down into smaller items (e.g., authentication, sunny day flow, exception conditions) and have a tester work with or just behind the developer to give frequent feedback.
Have the testers do preliminary testing with the developers and don’t count bugs found there in the master defect list. Then when defects are found later in the designated QA environment it is a joint development/test failure and not a “run up the bug list” smirkathon(TM) by the tester.
Automate as many tests as possible. It always sounds like a chore but if you automate tests early you can run them very frequently. When you do this the testers are essentially helping the developers rather than picking holes in their work. This really helps fix the old-school development/test divide.
If you automate your tests, you hardly need have a bug list at all! The code is ready to ship when the automated tests run cleanly. So the only time you need to write up a defect is when you decide to not fix something, disable that test, and ensure the rest pass. This also helps eliminate friction between team members.
If you adopt one or two of these approaches I think you will see your cross-functional teams become more cohesive in the space of a few months.
