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 thing because, like the developers and managers have their own divide, developers and testers have that too. Once communication channels are open, the goals are aligning and will get a much better product.

Clayton:  To go back to the manager‑developer, those two groups, what’s the biggest mistake or something that you think a lot of managers are probably doing today, maybe a manager in Agile team, that if they were to change something about their behavior or something that they did that would make the biggest impact, that would make their team more productive or everyone happier or whatever?

Gil:  There are a lot of examples, but I’ll just say that they need to change their language. For example, saying to the developer, “But you estimated it will take two weeks.” Just listening to this sentence just generates an image in the developer’s eyes that is looking into a pointy‑haired manager, and you know that estimations are taken as promises or commitments.

Estimation for example or things like “not enough time to do testing,” these are sentences from the domain of the developer which sounds differently for people with different background. They start, again, seeing the managers as their enemy instead of someone who could help the team reach their goals.

Managers needed to learn ‑‑ that’s the same for developers ‑‑ they need to learn the language of the other side. Developers for, I don’t know, a hundred years…We’ve been developing since the ’40s. I’m coming from a development background. That’s why I always say “I” and “we.” We created our own, built our own little language. What we do is we work some black magic and something appears at the end.

Management has been there for hundreds of years. Management hasn’t changed much. This new thing of software development, it is new, so the domain is different. We always like to talk about domains and language of domains.

Managers need to understand what developers are talking about and what they care about because when the developers talks about quality…Switching back to the developer side, a developer really cares about his craftsmanship so the quality of the code, and the design needs to be very good.

The problem is how that it sounds to the manager. The developers need to think in the domain language of the managers as well. So instead of saying, “I need a good design.” He could say, “I have a design that allows us to change the code quickly” because that what is a good design for.

The two sides need to learn the language of the other side and start talking in that language. We have a whole lexicon of things that we can try to change the sentences or at least try to understand what the other side means when he talks about using these terms.

Clayton:  Interesting. I think we’re actually out of time, but I wanted to ask if the listeners wanted to find out more about you or Typemock, where would they go? Also, if there’s anything that you found interesting lately that you would like our listeners to know about.

Gil:  First of all, a lot of Agile stuff on my blog, on my site at Gilzilberfeld.com. Go to Typemock and download the tools for unit testing. We have tools for mocking for .NET and C++.

The thing that I’m actually looking at recently is system thinking. I’m trying to get into this new topic and learn more about it because I understand that when I look at those, there’s a lot of same terms like the thing that I brought up with languages or the sentence. There’s a lot more thing we can learn about going into thinking about this kind of systems and the interfaces between them.

Clayton:  Great. As always, we invite the listeners to check us out on Facebook at Agileweekly.com. You can join the conversation on the Facebook page. You can chat about this episode or any of the previous ones. I just wanted to say thanks Gil for joining us today. We appreciate it.

Gil:  Thank you.

[music]

Announcer:  If there’s something you’d like to hear in the future episode, head over to Integrumtech.com/podcast where you can suggest a topic or a guest.

Looking for an easy way to stay up‑to‑date with the latest news, techniques, and events in the Agile community? Sign up today at Agileweekly.com. It’s the best agile content delivered weekly for free.

The Agile Weekly podcast is brought to you by Integrum Technologies and recorded at Gangplank Studios in Chandler, Arizona. For old episodes, check out Integrumtech.com or subscribe on iTunes.