Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich.

Roy vandeWater: I’m Roy vandeWater.

Drew LeSueur: I’m Drew LeSueur.

Getting Started With Agile

Clayton: Today, joining us, we’ve got Peg Haustetter. Peg, you wrote an article about, basically the gist of it was getting started with Agile. That’s a real popular topic with people who are interested in Agile, or listen to the podcast, and things like that that we come across a lot. What was the motivation of writing that article?

Peg Haustetter: The company I work for is Systems Evolution. There are a few project managers that were going to clients that had not really been exposed to Agile, and [inaudible 00:46] to do, how to get started.

We developed a team, and in that team, we started putting together some slides that they could present at their customer. One thing led to another, and we decided to write an article that we published in our [indecipherable 01:05] . That article took all those slides, and all of those conference calls and meetings that we had, to try to get a little Agile primer to all of our members, and we came up with the article.

Clayton: I noticed that you mentioned things like sprints and iterations. The stuff that you’re describing is like Scrum, although you leave some parts out. I was curious if that’s something that maybe Scrum is in your background, or if that’s maybe your preferred methodology that you like to use for projects, or if that was even intentional?

Peg: I am a Certified Scrum Master, so those are the types of projects that I have run. We intentionally left it out because we didn’t want to really sell a flavor or a certain methodology [indecipherable 01:58] article, so that people could relate to what they’re currently doing.

Or to realize that not every company is doing something that’s purely Scrum, or purely any kind of methodology that a lot of them are mixing [indecipherable 02:17] some of their worth all on trying to do it all at the same time.

Hurdles Going From Waterfall to Scrum

Clayton: Is there anything that…You mentioned the waterfall, transitioning from waterfall or using that as a benchmark. In your experiences there, are most companies that you find that are trying to transition into Agile, are they doing waterfall now or do they not even have a process?

What are those hurdles, the biggest problems that you find that people face when they are trying to make that transition?

Peg: I do find that the clients that I have been at, they’re larger companies, and so they generally do follow the waterfall. I think the biggest hurdle is trying to get the business team [indecipherable 03:05] involved. They are all about defining the project, and agreeing to the requirements, and then throwing it over the wall, and “Call me when it’s done.” [laughs]

To try to keep them engaged and daily [inaudible 03:22] challenging for the [indecipherable 03:25] to get them in a room to do demo, or let them play around with whatever we’re delivering that sprint. That’s a huge hurdle, if I can get two or three of them in the room.

I think that in the end, the team that you’re working with [indecipherable 03:42] happy with the process once they’ve realized how it’s working, but to get them initially engaged is a challenge.

Clayton: I had overheard the conversation from a product manager and the product owner of a Scrum team the other day. The gist of the conversation was, “I really like this whole Agile thing and it’s great, but we really need to balance being Agile with getting things done.”

Peg: [laughs]

Clayton: I thought that was interesting. I was curious if you’ve heard anything like that, or what you’d say to that person?

Peg: [inaudible 04:19] is that maybe they’re not [indecipherable 04:22] their sprints correctly, because the whole idea is that you are getting things done, and you’re getting them done quicker, you’re getting them done so you have eyes on them, catching any issues, [indecipherable 04:34] put in the wrong place, the wrong color, some little small thing.

People are seeing it right now, if they see that the data’s coming out the wrong way in the field, they see it, you can react quickly and correct it, and then move [indecipherable 04:53] hang around with somebody that’s doing Agile. Go to a class, try something!

Hybrid Approaches

Clayton: You mentioned in the article that people like taking a hybrid approach, or maybe combining two things together. There is some talk in the Agile community of a “Scrum bond,” or something, trying to combine Scrum and Kanban together.

Have you ever seen anything like that be successful? Or are you more getting that as a way to introduce the organization to Agile, they might need to do more of a hybrid of their traditional technique, plus some more Agile concepts?

Peg: The things that I have experienced [indecipherable 05:42] methodology, a lot of it is because their compliance departments won’t allow…They don’t really understand the documentation. They still require tons of documentation, tons of certain types of testing, depending on what the product is, and then what sector that you’re working in.

I was working in the medical [indecipherable 06:11] sector. Obviously there’s a lot of regulations, a lot of paperwork, a lot of checklists. You still have to do a lot of those types of documentation while your development team is developing in the Agile methodology, but you still have to support all of the traditional [indecipherable 06:35] .

In some of those cases, in my case specifically, the PM had to produce more documentation than my team, probably wrote in code in some of those projects. I think it depends on the organization, and its will to let go of some of that.

The regulations that drive why we do things [indecipherable 07:02] piece of software. I think it’s learning, and I think it’s learning all the way around. It’s not just for the companies, but if they’re regulated, it’s for the regulators. They have to understand. They need to look back and read all those documents again, and see if there is a more streamlined approach.

Starting Agile At Team Level

Clayton: Do you have any opinions on starting Agile at the team level, and then growing it from the team level up to the organization level? Or do you feel that starting at the organization level and trying to get the higher‑ups thinking in more Agile mindset is better? Do you have any opinion on that, or maybe you’re still trying those things?

Peg: I’ve had more [indecipherable 07:57] both the opposite ways. The medical device company I worked at, we were doing it at an organizational level. It came from the top down, and we happened to be the first project, but they were pushing it across the organization.

I think it was six [indecipherable 08:20] everybody was on‑board. There was lots of training. People went to all of the training, the displays, they went to [indecipherable 08:36] reviews and things like that, so they got engaged.

Currently I’m at a client that, first they were trying it more on a project‑by‑project basis, doing an evaluation to see if that project fit into that mold. That was a slow burn. Just a few people would try to do it. Now, they [indecipherable 09:05] organization.

I think that’s more successful, because when the management is on‑board with it, then everybody gets the right communications and training so that they can move forward with it.

The Role Of Organizational Culture

Clayton: One thing that we’ve found is that the organizational culture seems to play a very big role.

I was curious if you’ve also noticed that, or if you have any techniques or ways that you’ve tried to guide the organization culturally? Maybe they’re used to this waterfall, or more of hierarchical management style, and that transition to Agile can be upsetting from a cultural perspective. Is that something that you’ve noticed?

Peg: It is something that I’ve noticed, and it is baby steps. You just have to really spend a lot of time guiding, and getting them used to so much interaction. The first couple of projects that I’ve done in Agile, the business, it was just really hard to pull them along.

IT was all for it, we were gung‑ho [indecipherable 10:19] all the meetings, and didn’t want to be involved. It is a big cultural change. You have to just keep guiding them, and showing them all the advantages of being more participatory.

Each Role Has a Different View

Clayton: The article seems to talk from a…Maybe it’s geared towards a project manager, or someone who has a holistic, or has a higher‑level view of the organization of the project.

If me and a couple of other developers are on a software team, and we’ve been reading a lot about it, and we want to be an empowered, self‑organizing team, is there any different advice you’d have for someone that maybe is at that level of the organization?

Peg: [laughs] Yeah, there is. If I was writing this article, or talking with the development team, I would have taken a totally different approach. They already know the pitfalls, [laughs] they know that it would be better to have a team that plays on your strengths, and really jumps in and helps each other out, so that you’re not so stuck, spend hours [indecipherable 11:38] .

This methodology really does get everybody’s creative juices flowing, and I think developers thrive in this [indecipherable 11:57] . Somebody that you don’t really know how much they’re producing, or how quickly they can produce until they are standing up every day, and telling you everything you’re doing, and it’s contagious.

If I was writing this [indecipherable 12:14] mentally different approach.

Start With Someone With Expertise

Clayton: If there’s one big takeaway that you’d like people to get from the article, the piece of advice that everyone wishes that they knew before they started, what’s the one big takeaway?

Peg: I would recommend that, especially your first few Agile projects, that you would bring someone in‑house that has some experience, that can help your, if you have a PMO, depending on the size of the organization, but that can really give some guidance to the department, or the organization of the department that is [indecipherable 12:55] managed other projects.

Somebody that, if it’s a consultant, bring them in. Somebody with this real‑world experience, that’s already experienced some of the bruises along the way, so that you can have a more successful [indecipherable 03:14] and a more successful experience.

Clayton: We’re getting close to the end of time here. Is there anything you’ve been interested in lately? A book, or a blog, or any conferences or books that you’d like to promote, and let the audience know about?

Peg: I always took my training from Mike Cohn and reading Mountain Goat Software website, his blog. There are lots of books that he recommends, and I do find that all the books that Mike Cohn recommends do really help you in estimation or writing user stories. There’s quite a few tools that he has on his site, so I would recommend people [indecipherable 14:03] probably go to Mountain Goat Software.

Clayton: Peg, we thank you for your time today.

Peg: You’re welcome.

Clayton: As always, we invite the audience to check out the Agile Weekly Facebook fan page, where you can talk about this episode and other episodes as well. I think that’s about it, so thanks again, Peg.

Peg: Thank you.

YBS: Latest From Twitter; Staying Positive