There was a fascinating Twitter conversation last week when I was busy writing other things. (I also find Twitter to be a difficult-for-me arena to have a conversation. I need more than 140 characters.)
The conversation started when Neil Killick tweeted this:
orgs need coaches not because “agile is unintuitive”, but because effective sw delivery is a team game requiring folks at their best.
I liked that and retweeted it. Mohinder Khosla asked (quite reasonably, in my opinion):
Do we have stats that this is real? Just saying
Mohinder, I am sure we do not have stats. We rarely do what I would categorize as real research in how software product development works. That’s because we continually learn and even if we start a new project with exactly the same people, we have learned to work together in previous projects. If we don’t keep teams together, we have to relearn how to work together. (See Hackman’s Leading Teams book for this and much more insight on teams.)
Agile challenges all of our previous assumptions about how software product development works.
- We think in product, not just project. See terms as releasing, product owner, and MVP.
- We think in flow efficiency, not resource efficiency.
- We integrate all of the work we might have done as phases into small stories that we release often.
- We invite change, we don’t try to control it
- and much more…
Agile is a mindset change and a cultural change. (See When is Agile Wrong for You?)
One of the big changes in agile is that we work as a team. We work as a team to move work across the board. We don’t hand off work from developers to testers. We don’t hand off work from architects to developers. We don’t hand off work from testers to operations.
Can each team do that now? Probably not the first time they try to use agile. This notion of the cross-functional team being the team in question challenges everything we, our managers, and our organizations “know” about product development.
Coaches can help teams and managers learn what it’s like to create the agile mindset and an agile culture. Do you need a coach? Maybe not. Here are some questions I have asked my clients when they asked whether a coach would be useful for them:
- Do you have a cross-functional team? Or, is it a team of developers, followed by a team of testers, etc.
- Can you create features as one cross-functional team, by yourselves? (You might not be doing this now, but can you? Or, do you need other people across the organization?)
- Does the team demonstrate on a regular basis? (My guideline: at least once every two weeks.)
- Does the team retrospect on a regular basis? (My guideline: at least once every two weeks.)
Notice that these questions are about team collaboration and delivery.
Agile creates transparency. We can see when a team is not “performing.” I put that in quotes because often the environment is what causes teams to not “perform.”
Some teams have trouble working as a team. Coaches can help. Other teams cannot answer yes to my four questions. If so, coaches can help the team and the managers. Can the organization help itself? Of course. Would it be easier with a coach? Probably.
You don’t need agile coaches to be successful. You can do it yourself. And, if you look at people and teams who fit your definition of success, they will often tell you they have coaches. (I do.)
Agile teams deliver working product on a regular, frequent cadence. They can use flow-based agile or iteration-based agile to do so. It doesn’t matter.
When teams deliver on a regular basis, they work as a collaborative team. That idea and practice might be quite new to everyone in the organization. Coaches might help.
The next post will be the role of managers in coaching in an agile environment.
| Reference: | Coaches, Managers, Collaboration and Agile, Part 1 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
