Managers and Developers Growing Apart with Gil Zilberfeld

Episode 76

August 29, 2012

18:00

TBD

tbd

The Agile Weekly Crew and Gil Zilberfeld discuss manager/developer communication, management practices, quality assurance and common manager mistakes.

Episode Notes

Clayton Lengel-Zigich and Gil Zilberfeld discuss:

Managers and Developers communicating together

Development practices have changed faster than Management practices

How QA integrates with a Scrum Team

Mistakes that most managers make

Transcript

Clayton Lengel‑Zigich:  Welcome to another edition of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich. Joining me today, we’ve got Gil Zilberfeld. Gil, can you tell us a little bit about yourself?

Gil Zilberfeld:  Thank you for having me, first. I’ve been in software for something like almost 20 years now. Currently, I am the Product Manager at Typemock, which is a company that creates tools for unit testing. I’ve been experiencing working in the Agile field for almost seven years, now. Working in a Typemock team, as well, working in Agile and modified Scrum, a lot of experience there, as well.

Clayton:  OK, great. You had mentioned that one thing that was interesting to you lately, was the topic of management. I’m guessing management in Agile environment or Agile organization? You specifically mentioned how managers and developers are growing apart. Can you explain that a little bit?

Gil:  Yes. You know that managers and developers have for decades been growing apart. There was no trust between the two groups. When the managers asked developers how long it will take to finish the project, whatever the developers told them, they multiplied by three, immediately.

From the developers’ side, managers were always keep exchanging everything and harassing them. Let’s say the developer did the screen and then the product manager’s passing by, looking over his shoulder, saying, “That’s not yellow enough,” and “You need to change that.” So there’s a lot of mistrust.

Agile was supposed to be the great coming together of things…

Clayton:  Fix all those problems.

Gil:  Yes. Some of it really does it, if it’s done correctly.

But the way I see it, in the last few years we see Scrum taking over as the winning Agile method. I’m not saying there’s a problem with it, but there’s a little bit of a problem. [laughs] And that is, it left developers behind, because Scrum declared that regardless of the Scrum practices which are communication practices the developers should select whatever practices they can do in order to support working software.

This was very acceptable from managers because they understood communication practices this is why Scrum actually won because it was easy to sell to managers. But once they accepted Scrum they didn’t do the next step and let developers pick the right practices for them to make sure that they can produce software.

For example, I was at a conference a year ago, something like that, and some mini conference something like two months ago. Two separate companies ‑‑ very large companies ‑‑ that one of them decided to go with Scrum as its methodology, the other one decided to go Lean. And both of them, at both times, did not even include developers as part of the process.

Again the developers feel that they are left behind and I think we can see the backlash in the way that developers are forming now craftsmanship groups, right?

Clayton:  Right, yeah. Taking some of the technical excellence practices, or maybe, I see a lot of teams that have adopted Scrum. Usually because it was sold to management and management made them do it, but then sometimes they’ll adopt some XP kind of practices, maybe continuous integration or pair programming, something like that. They try to augment it a bit.

Gil:  Yeah and this will actually make Agile work because second statement in their Agile manifesto talks about working software. But if companies don’t do that, they just buy into Scrum and they leave the developers outside they won’t get working software. And that’s because in a few years, unfortunately [laughs] people will start blaming Agile for being snake oil because…

Clayton:  Scrum, I think they make it clear, if you really read into it that they say you can augment the process with certain things, but there’s so many companies that you’re getting at, that will adopt Scrum and that’s all they do. So, you’re advocating for the developer. If they don’t include the development team, or the people that are doing the work, so to speak, and they don’t have some way to improve their practices then you’re going to end up with non‑working software it sounds like.

Gil:  Exactly, and these are the software companies. Almost every company today is a software company because software is such a core part of the business.

The problem is that, we’ll see in a while, people are just being angry, not only at the people who sold them Scrum, but the developers because Scrum was originated by the developers. I hope this will not happen because basically there is a solution for that.

The solution is that companies will understand that Agile is not just Scrum. You need to do all the things you can do in order to develop correctly and get software that works and high‑quality software.

Unfortunately, what happened in a very few years is something, basically, if we wanted to succeed, we should have gone another route because processes like this take awhile to get absorbed into big companies.

Clayton:  If I ask you, if I’m a manager and I’m listening to the podcast and I’ve got a Scrum team, by direct reports, I’m a functional manager and I’m realizing as you’re saying all this stuff that the developers aren’t really included and they don’t have any particular practices on their own and they just follow the Scrum rules.

They do the ceremonies and all that stuff and I’m convinced that I need to help them to do more or maybe help them with the technical practices, what’s a good first step? What could I do to help get my team started on the right track?

Gil:  The first thing is to start listening to them because the mistrust we have is because both sides don’t listen to the other side. Specifically, for developers to give them some confidence in the other side and that’s just to remember what happened last time when we tried to implement a new practice.

Management needs to take the first step and give enough room to the developers to decide what’s good for them. In terms of practices, XP practices are great, code reviews, pair programming, any testing, everything there is great, but we need to, first, as managers, to make the team, the developer team, feel they’re empowered enough.

I don’t like the “empowered” word really, but they are empowered enough to pick practices ‑‑ not for short‑term ‑‑ long‑term, and to keep practicing and make themselves better. Without it, the developers will just think that the managers have the new flavor of the week working for it.

They will wait for the winter changes to come about. They won’t really go into stuff. They know it’s going to last.

Clayton:  I know you’ve got a lot of history and experience with testing, unit testing specifically, CV kind of stuff, but in terms of maybe the bigger picture, a lot of sprint teams or Scrum teams, they will have a QA person, maybe have an embedded QA, sprint tester, whatever they call it. How does that person fit into that structure?

Most Scrum teams that I’ve worked with that have developers and QAs as separate roles, they do these mini‑Waterfall things where the developers do all the work and, then, the QA people do their work. I’m just curious what your take is on that. How do you think those two roles can be cross‑functional?

How can the testers, someone that has more of a QA background, how do they fit into the Scrum team that’s maybe doing TDD that has a very good testing culture on the development side, but maybe not so much on the QA side?

Gil:  It’s funny because I was something 10 years ago, the product manager in another company. Without knowing about Agile and roles within the Agile team, I attached testers to develop, in an organisation that there was separation before that.

I did that because it made sense. The [inaudible 10:03] as developers were doing a unit testing, but it was automated. We were doing some kind of manual unit testing. Of course, manual testing by the testers, but putting them together actually they did talk a lot of things.

First, they started talking to each other instead of just blaming each other for “you found my bug” or something like that. They actually sat together, testers and the developers, on the developer’s machine.

So instead of waiting for integration, which obviously was painful without automation, instead of that, as the developers developed the screens and some logic behind it, testers sat with them. They saw what they’re developing, and they could redirect them if there was a need.

Now beforehand, before we did that, there was some notion that there shouldn’t be any discussion between the testers and the developers because the testers will get polluted by knowing how the software is really built. Looking back, it sounds very stupid to me [laughs] .

Clayton:  I’ve heard that objection before. I’ve heard that one before.

Gil:  I know. Let them work together.

Today, the boundaries between the developers are blurring because testers that fit into an Agile team learn, have some skills in automation, some kind of programming. It doesn’t have to be at the level of the programmer like a C# developer. He’s doing all the tests in C#. Depending on the tools that he’s using, he can do something like Cucumber or any BDD tool or some kind of big automation tools as well.

But the communication between the two sides is the most important