The Seven Deadly Sins of Enterprise Agile Adoption

Interview with Sanjiv Augustine and Arlen Bankston

by David Bulkin

Arlen Bankstrom and Sanjiv Augustine

Sanjiv Augustine is President of LitheSpeed and Arlen Bankston is Executive Vice President of LitheSpeed. Both have been in the Agile industry for a decade, helping individuals, teams and organizations implement and benefit from Lean and Agile methods.

This interview first appeared on InfoQ and is brought to you by InfoQ and IEEE Computer Society.

David Bulkin: Hi, this is David Bulkin for InfoQ along with Arlen Bankston and Sanjiv Augustine of LitheSpeed. Gentlemen, thank you for taking time out of the conference and for joining us today. Our topic is the Seven Deadly Sins of Enterprise Agile Adoption. Before we get into the topic, I was wondering if both of you can give me a little bit about your background. We will start with Arlen.

Arlen Bankston: Certainly. So, basically I'm with this company called LitheSpeed an Agile coaching, consulting operation. I've been in the Agile industry for about 12 years now doing Scrum and Extreme Programming, Feature Driven Development and Kanban. My background originally was in user experience design so I had a lot of experience lately doing trainings, Scrum trainings alike and coaching various teams and companies through enterprise Agile adoptions.

Sanjiv Augustine: I appreciate it David and it's good to be here. So, my name is Sanjiv Augustine and I am also with Arlen at LitheSpeed and I've been in the industry for over 20 years and also with the Agile space for over 10 years. It's amazing that it's kind of historic to be here at the Agile Conference attending this landmark 10th anniversary conference.

I originally started out at the Agile space as a Project Manager and I remember the early days when, on my first XP Team, we didn't quite understand what to do with this whole notion of project management; and then, of course, we progressed since then. You know, talking about project management, program management, and of course, now we're talking about the 'Seven deadly sins of Enterprise Agile Adoption'. So, it's all rolled in there.

Bulkin: With that, we're going to go sin by sin, define what sin is and talk about how we can address it and the immediate impact of the sins so we can prevent them from happening. So, Arlen, you want to start off providing the list?

Bankston: Certainly, so we found there are seven common empty patterns, if you will, that tend to be a bit problematic when you're trying to scale Agile to an enterprise level starting with an inappropriate scaling strategy. So, we're trying to either roll it out big bang or roll it out incrementally and pilots and gradually growing which is right and where do they work? That's the first.

We've accrued certain types of behavior over the last couple of decades with the waterfall processes and those are more firmly entrenched than what's visible. And it's interesting that in a crisis, we'll always tend to fall back on what we know best. So a lot of times our organization will say, 'Well, we want to move Agile.' Everybody gets excited and then the first crisis comes and Agile is thrown out of the window.

The second is a lack of organizational change management. So, introducing Agile as a change initiative and this is essentially has to be counted as such.

The third is a lack of demand management at the portfolio level followed by a lack of engineering discipline at the team level, Extreme Programming practices and that sort of thing.

Then there's the idea of doing a siloed or tiered rollout where it's an IT only proposition and does not really take into account the whole organizational. A lack of tool sophistication to support the needs at an enterprise level; and finally, the idea of outdated human resources policies where your performance management systems don't really match up to the realities of Agile teams.

Bulkin: I think we'll start with the first one - inappropriate scaling and if I am in a large company, what type of scaling approach you would we be looking at using, what would be the most appropriate?

Bankston: In our experience and in most of the adoptions we've led, it has been basically starting small and growing over time. So, in terms of choosing teams perhaps we're excited about trying Agile methods on ones that would volunteered gladly rather than being forced into the role and we would use them as a pilot team. They would test it out and then they would - grow it over time using those initial people to seed other teams, to grow in the master coaching strategy and so on.

Bulkin: So, potentially, the sin with the large company will be trying to do it top down, if I understand it correctly.

Bankston: The Big bang approach - this is really difficult to duplicate with these big companies. What do you think Sanjiv?

Augustine: Absolutely. I think the sin is not recognizing which strategy applies. So certainly as already mentioned, for most companies I'm talking about having a large sort of incremental rollout. We start small, we have some pilot projects, able to expand the pilot and then you move to enterprise rollout with appropriate inflection points and growing as you go along.

Now, sometimes that approach is actually not desirable and if you're working, for example, with a smaller company, it might behoove you to start to apply all of the practices at once. So, to put some parameters around this, some of the larger adoptions that we've seen have been in the hundreds of projects. So, we're talking maybe starting about 150 projects rolling up to about 400 projects, I don't mean small or medium enhancement projects. These are large enterprise adoptions and it's definitely better to move incrementally in an enterprise that size probably 5,000 to 6,000 maybe up to 10,000 people or so.

However, if you are a small company and you are 200 people and you got ten projects and you have control, maybe C Level buy in, then it might behoove you to just do it in one fell swoop and that's go and make the appropriate preparation. Make sure the organization is ready with training and capability development as such and go forward with the adoption and just like at one shot.

Bankston: And I think that the reason for that is that we've often seen there's a problem with sustainment over time with enterprise adoptions. They start out successful but then over time, they lose the energy and they lose the gravity and often, this has to do with some of the other sins we mentioned of running into other silos, that are as pleased with the Agile methods and the changes they have to make to support them.

So in those cases, the reason that's easier for smaller companies to do the pulling off the band aid approach is because everybody then has to get on the bus and ride it. So, they don't have an option to slide back in both methods of operation. And it becomes rather easier, everybody has to align to get this common goal and just making it work.

Bulkin: So we've just covered deadly sin number one, we let's go on to number two: lack of organizational change management strategy, who wants to take that?

Augustine: I'll pick that one. So, the organizational change management, first of all, we have to understand that sustainment, long term sustainment of an Agile adoption requires both bottom-up adoption as well as top-down empowerment. So, what we're talking about is we have buy-in from not only the rank-and-file within the organization but also buy-in from executive management and when I say buy-in, it's not just pat people on the back and give them Starbucks cards for doing well but we're talking about, you know, a coherent and disciplined strategy and plan and execution for organizational change management.

So what do we mean? Just like instituting any change in behavior- whether you know, some people use the example of if you're a left-hander, you start writing with your right hand or, starting to write with your right hand or perhaps, if you're already used to driving on one side of the road in one country, you drive on the other side of the road in another country, it means that we have to change a number of things not just our software development processes but perhaps our HR systems, our portfolio management systems, our program management system and all of that is going to drive longer term organizational change and more specifically, a change in human behavior.

We've accrued certain types of behavior over the last couple of decades with the waterfall processes and those are more firmly entrenched than what's visible. And it's interesting that in a crisis, we'll always tend to fall back on what we know best. So a lot of times our organization will say, "Well, we want to move Agile." Everybody gets excited and then the first crisis comes and Agile is thrown out of the window.

Bulkin: So what organizational change management, for instance, will training be a major component?

Augustine: Absolutely. So I think one of the things to recognize this in the field of organizational development, they're going to talk about training, they're going to talk about communications; they're going to talk about planning overall and I'll let Arlen talk to some of these but we just need to understand that introducing Agile or any Agile method is an organizational change strategy and Arlen perhaps can chip in with some of the elements over there.

Bankston: Absolutely right. I think, you know, as you know the changing human behavior - a lot of research and anecdotal evidence that cultural change is really one of the key problems that you have to deal with and this is culture - it's really about how people relate to one another in many cases. So, when in change management, if you're talking about things like, for instance, changing the roles of middle management then this can be quite substantial an effort and it's not gonna happen overnight and also, it's not always done the same way.

So, a lot of training and a lot of these preparatory events help us to identify where people are excited about taking on new roles, where they like to change and learn new things, which people are going to be hindrances possibility to adoption because they're scared of changing or simply happy where they are; or for whatever other reason. So, that initial session of being able to go in and talk to people, do some ready assessments, and so on allows you essentially plan these things consciously rather than having them just catch up with you arbitrarily.

A lot of Agile adoptions focus at the team level initially; so, we need to begin to expand our purview there.

Augustine: Can I just add something over there. I think what we initially need is to communicate very clearly where people are going to find their place in the new world order. So, we're talking about changing the order of the world around them and people need that, who moved my cheese, 'where do I fit in'? and am going to have a place to add value, more simply put, will I have a job?

Bulkin: And let me ask you the next question on sin. In the organization you've been with, do you think they have enough communications in general or maybe more?

Bankston: It's always a challenge. I guess the most common pattern is really that people have viewed Agile so long as an IT thing and really the other groups are as pivotal if not more in the long term, they're really making the adoption work. You have to look at this in a more kind of a lean end to end value stream perspective here that everybody's got a part to play and you got to get them all engaged. What do you think?

Augustine: I think it's also a matter of timing. So, if you look at most Agile adoptions as we discussed earlier, we start up all excited and there's a lot of communication and we can communicate some of our quick wins and such, and then things generally, I would say, maybe not all; but I think tend to taper off. And what's important is that the change management is sustained, right? And sometimes Agile adoption can take multi years, can take, you know, two years, five years sometimes even longer than that.

To answer your question more specifically you said: "has there been enough communications?" Well, if you look at John Kotter, he's the sort of world-renowned guru on organizational change, he says, "Romp up your communications by ten times." So, 10x. So think back about the organizational change initiatives, think about the communications, and I would be hard put to find maybe more than a couple of them that we started communicating at ten times more what we usually have.

Bulkin: To move on to our next topic, I guess - lack of engineering discipline. This will be trying for instance, to implement Scrum and not doing engineering practice which XP made so popular.

Augustine: We skipped lack of demand management.

Bulkin: Sorry about that, so lack of demand management that's the next one.

Bankston: Sure, sure. And so I'll pick up on that one. What we're talking about here really is that a lot of Agile methods things like Scrum -they make a few assumptions really. They assume that you got dedicated teams; they assume that you have the ability for people to focus on more or less a single project or initiative at a time and be able to do all these things and yet, in most organizations, people, when you walk in, they're quite frequently working, many projects at a time - you got altogether too many projects and fundamentally very little prioritization of any true sort going on at the organizational level.

So with all these projects, it really makes it very difficult to get dedicated teams to allow people to focus on this. It slows down the flow of value. So all of those things add up to essentially a lack of demand management, right? They're not matching the capacity, the development organization, the real capacity to do things on their term with the demands of business or their customers are making.

Bulkin: This maybe simply - all these projects are approved starting January 1st; so, the assumption of the business part is - all projects start on January 1st?

Bankston: Right, we often say, "You will optimize for finishes not starts," right? And everybody wants to say, "Yes, we'll begin." But then the projects take longer.

Augustine: I think as companies over the last 20 or 30 years were really good at starting projects and we need to change that discipline to become really good at finishing projects. So we know that our portfolios are essentially like our crowded highways, like you go to any major city and you see all these crowded highways and that's what our portfolios look like. And from lean or queuing theory, we know that that it dramatically reduces the through put of any individual car which means from point A to point B, you're going to take slower, the more traffic there is on the highway.

So we need to understand that at the portfolio level, there is work to be done - there is tremendous amount of work to be done so that we can truly leverage the investment in our Agile teams.

So, we've been around for 10 years and there are many, many companies that are doing amazing work at the team level. So, you're walking to a company that's done Agile, let's say, four or five years and they're still struggling and you will talk to the people on the ground and you look at the teams, and they have Scrum rolled out; they have the discipline of Agile process; they might even have the engineering discipline but their still struggling and then you start to look at the portfolio and it says they're being hit from all sides with an unregulated demand.

And if only we understood that we need to funnel that demand, prioritize it and feed the prioritized projects to the Agile teams, they would deliver and then we can truly leverage the investments. So, I think a lot of problems now have shifted, you know, if you look at the past few years, we've shifted from projects to programs. We learned how to deliver Agile projects pretty well, we're still learning how to learn Agile programs and portfolios well.

Bankston: And just one more note on that of a comment tip that we give people is to think about bringing projects to teams rather than vice-versa. It lets you keep the teams together longer and all the benefits you get from gelling and becoming very productive, you get to keep those benefits and we're more than happy to review it every time.

Augustine: Right and to channel Mary Poppendieck it would be basically using the product model more than the project model.

Bankston: Yes exactly.

Bulkin: Our next one which I believe is lack of engineering discipline trying to do Scrum without engineering practices that were made popular from XP. Who can take that?

Augustine: I can start it off. So, you know, over the course of our experience, we've done most of the Agile methodologies. We started as an XP shop way back in the day and we had the good fortune of understanding what it took to truly dive deep into a project, romp up the discipline, set up a studio use pigment brains model of software craftsmanship and build it through high quality high performance software team.

I think what's been diluted over the last two years in our excitement to go Agile, in our excitement to rollout Agile methods, we think that standing up and having a daily stand up, having release planning and sprint planning is enough and it's great, you know, the first step towards organizational change is to introduce XP, (introduce Scrum) but a lot of times, we like to embed Scrum with XP. And when we do that, then we can achieve some truly amazing results. So, we not only get the flexibility and high performance from the team flexibility of Scrum but then also the engineering discipline from XP.

So, we take the essential XP practices, perhaps like continuous integration, TDD, refactoring and build them into our Agile teams and then truly build a model of software craftsmanship. I think that's something that's been lost over the past few years is starting; we're starting to see a resurgence of that. I blogged about it and I think they call it the XP2.0, so I'm happy to see XP 2.0. Arlen, won't you say something about that?

Bankston: Certainly, so I mean, just in reality, of course, a lot of the team level problems that occurred in the early days or to be able to get things really and truly done. Of course, we're trying to speed the flow of value in the end which includes things like testing. So, we're running some very low level problems like an inability to do things like very long manual regression testing and we like to move more towards automoated testing as a way of doing things and that can be quite a challenge frankly that the early history between Scrum and Extreme Programming led to something about divergence for variety of reasons between those for a while - Scrum being a very simple framework; similarly Kanban and other methods that have come online and share the same lack of prescription.

They say, "You don't have to do this," and we can use these methods in fact of things outside of software development entirely but if you're doing software development, then you need some of these practices.

Bulkin: So quite simply if I had, for instance, teams and lots of interdependencies and they don't have automated builds and continuous integration, there are teams which are great in individual productivity but they try to put it all together and it fails.

Augustine: Well what you'll end up with is our longer sprint cycles, longer iterations, because you're not able to do much because you still have the manual testing if you truly want to have testing within the sprint and then you have longer regression testing cycles and then you end up into this slippery slope of what you call hardening sprints and regression sprints and such.

So what we would love to see and we've seen with amazing results at the enterprise level, let's say, there's a large company that we work with that has 27 teams running in a development center and they deliver, believe it or not, a zero defect software - it's amazing. There's a cost that comes along with that but their business partners are willing to assume that cost and they've gone for, I think, six months across 27 teams with zero defect software. It's quite remarkable, very impressive.

Bulkin: So the next one: siloed or tiered implementations. So coming from bottom-top only, inside of IT only, we touched on this a couple of times already.

Bankston: There's a common anecdote out there you heard also that to really make this work in the long run, you need to have things bottom-up, top-down and middle-out. So, you really need to support all of these various efforts, all these perspectives on the initiatives essentially.

And these days, I would say, early on, we saw quite a lot of bottom-up adoptions. You got a lot of teams; you're very excited about this. Agile obviously came from developers initially for the most part. Now, they're seeing the opposite in many occasions. You're seeing executives come in, they read about it and the magazine on the plane and they come in and try to enforce it.

You know, and either of the things in isolation isn't good enough. You really need to make the ends meet. So, there's that angle of it.

As far as the siloed rollout, of course, we're never talking about again, this is often a development initiative initially or as seen at that even when it comes top-down in fact, it's often seen that way when in fact, to really make it work, you have to tie the silos together, you have to get sales and marketing, release management group - you have to get them all involved so you have a nice smooth flow throughout the whole delivery of value.

Augustine: Yeah, it's amazing. There's a nice article, I forgot the date on it but in the New York Times and it talks about the merger of Delta and Northwest and they have this beautiful picture you can actually look at it's like a sticky chart, it warms the heart of any Agilist but it's essentially what fifteen hundred systems or so all laid out on stickies and it was during the MNA the merging acquisition process between Delta and Northwest that they laid out their different systems and they had a migration plan and then integration plan across fifteen hundred of [silos] if I remember the number correctly, on a sticky chart.

I'm assuming they also had some tool with that level of complexity and sophistication but you know, I think when we understand that we need to look at things both holistically and also particularly within a team, that's when we understand that we're not able to confine Agile rollout to a particular silo, you know, just IT or just business and we're not able to confine it to just any tier, just project managers, just teams. We need both the horizontal tiers and the vertical silos if you want this to be successful.

Bankston: And to your point about the board for the airlines some of the very successful projects which are the most interesting use similar very simple visual management system to do just this. I hope the silos see what they are doing and tie them together and get them on the same page.

Bulkin: Specifically on your own initiative, let's assume I got great success in IT and I've personally seen this and the business hasn't brought in. What are the ramifications of that, just delivering software which we are not ready to take to market and the customers are not ready for it, the sales force is not ready to sell it?

Bankston: You end up with sometimes with more of a push than a pull sort of. You've got development building all sort of things but they're not really terribly desired. You know, in the worst case, they're building lots of things just really aren't useful and that lack of engagement in business is absolutely the death nail fragile initiatives in the long run. You have to have them saying, "This is a good thing for us and not just an IT initiative.

Augustine: Yeah. There's a great session that I attended. I think it's by Jez Humble earlier in the conference and it is about Lean Startup and I think from over there he had one quote and he said: "If you don't understand who our customers are, we have no way to define quality. How can we define good quality if we don't understand the customers?"

So, if you have an IT only initiative, we run the risk of veering off course and doing things that will not ultimately add value to the business. And that's completely antithetical to the principles of Agile delivery and Agile management.

Bankston: I saw an interesting session as well. You mentioned Mary Poppendieck because she did one on design thinking and wonderful big points there and one that I pondered in myself for a long time is the idea that product to enroll not to be seen as we learn walk to unilaterally goes out there and defines the product as absent conversation with others and so on. And I think it's instructive to look at the history of the product to enroll. It used to be, for those who've heard this, this pigs-and-chicken showtime, but the product used to be a chicken; it used to be an chicken sort of atmosphere that was created in many cases where it's all about the team and not so much about the business customers because we'll just let the product to tell us what to do and that creates some quite unfortunate barriers between these two entities.

So, really these days using these Product Owners has becom a pig, it's becoming a more in healthier teams, really more of a partnership.

Augustine: Just one final thing and David, if you're there David Bland, I promised him to do a plug for the Lean Startup; and so despite the name, Lean Startup, Lean is an amazing model for the enterprise. And so, we can avoid a lot of these problems that we talk about like a lack of a scaling strategy, the tiered rollout, the siloed rollout - if you look at Lean as an umbrella for everything that we do in Agile; Lean process improvement, the Toyota production system has been out there for 50, 60, 70 years.

We have examples whether it's from Ford or Toyota or in Southwest Airlines, of examples of enterprises that have done this across at scale.

I think what's happening with the Lean Startup model is that we understand its customer development model and we understand that we should not be diverted from the business. The only way we can succeed is we have Agile, our engine of Agile development going but we also need an aligned engine of customer development on the business side and bring those two together pretty quickly.

And these days, I would say, early on, we saw quite a lot of bottom-up adoptions. You got a lot of teams; you're very excited about this. Agile obviously came from developers initially for the most part. Now, they're seeing the opposite in many occasions. You're seeing executives come in, they read about it and the magazine on the plane and they come in and try to enforce it.

Bulkin: We'll talk about another one: lack of tool sophistication.

Bankston: When you look at a lot of Agile environments, there is in fact quite a lot of emphasis on using physical methods, using cards, using sticks, using index - things of these nature. Why? Well, because they are tangible; they're concrete - more people can interact them at once; they don't have a lot of cost associated with; they don't feel so serious.

As your teams can get on there, they can change things. It's cheap and it's easy. But of course, as you get the scale of this and with the increased proliferation of distributed teams which are geographically disperse, you, of course, see more the need for appropriate tools for the environment, we are business partners with Version 1 who are large tool vendors and they're one of the leaders in these breed of tools that are called Agile Lifecyle Management. So, quite a lot of those sort of things become necessary at scale one and many of them also facilitate certain things that the physical cards don't do.

So I think you've seen and what we generally promote is in fact, consideration of using both methods. There are certain things that the physical cards are appropriate such as planning sessions or anything where there's quite a lot of dynamism and fluidity. We are multiple participants acting in concert but they work better for that. They're up there and people can move around very quickly. But for things like tracking and recording and analyzing for distributed communication, you better take the right tool for the job.

Augustine: Auditing, governance - I think it becomes very clear that when you're working in a distributed environment, you can't just operate without the appropriate tools. And it's not just the Agile, the ALM or the Agile Life-cycle Management tools, there's also the Agile engineering tools, the continuous integration tools, and also the video conferencing tools. Even if we can write a big check to whichever vendor and get something like a telepresence or a telecon solution or you got to do cheap on Skype or one of these net meeting in a simple PC or laptop-based tool, it is easy available voice over IP has made it pretty transparent. You know you can be in a team across the globe or across the country or in another city and you can have close to real time collaboration as long as the timezone works out, you're going to have close to real time collaboration.

Now honestly, it's not as good. Nowhere as near as good as being there in person as an Agilista, as an Agilista, we always believe that the best mode of collaboration is in person, face-to-face; butthat's not, and we have to deal with the reality that a lot of times that a growing number of us are operating in the scenario of distributed development.

And so we have to recognize that it's not one or the other. As Arlen mentioned, the in person interaction that you get with working in a white board, working on a wall -both things are great; it's fantastic. And there's a value to that and we should be doing that. But we also need to consider that if we are in a distributed team situation, we absolutely need different tools whether it's Agile Lifecyle, Agile development, or communication tools. And then also for management reporting governance and all these kinds of things, we need tools to be able to do that.

So I don't think we can appropriately scale without having the lack of tools. We call it tool sophistication because sometimes we have basic tools but we don't know how to use them in sophisticated fashion.

Bankston: And I think that to that point, the danger that many Agilists fear is people getting too immersed in the tools or too concerned about their value when, in fact of course, a lot of the behavioral aspects of Agile are more important than the tools are. We ought not be scared of the tools. We see plenty of distributed teams really doing quite well. I think it's a generational thing perhaps too that people will be coming more and more comfortable with communicating in that fashion.

Augustine: Just one sort of word of caution over here. We should always understand that we should let the process drive the tool and not the tool drive the process. So, let's work with the process. Let's align it and then use the tool to support it. We're believers of both process and the right tools.

Bulkin: If my list is correct here, we our on our seventh deadly sins: outdated human resource management policies. So, the Human Resource department is rewarding for your individual performance. How does fit on an Agile team and in the Agile organization?

Augustine: This is a great segue.Arlen and I did a session yesterday on the joy of Agile work. And we started to realize that a number of years ago that when we needed to introduce Agile, people got really happy and we introduce Agile and first, it was our egos thinking, "Oh, we're great."

It was a puzzle, so we introduced Agile and first we thought, "Maybe there's a novelty of moving into same location working together in rank with your fellow team members that created that kind of excitement. But it tended to be sustained and what we discovered after looking into the work of MihalyCsikszentmihalyi flow and this idea that you can get into the zone when you're enjoying the work that you do. So, whether you're a musician or software developer or manager, when we're doing the things that we truly enjoy; when the work itself becomes its own reward, our happiness and the joy that we get from our work is significant.

We understood that the conditions created on an Agile project - clear goals, constant instant feedback, being able to work together elevate to us to a different level and we're able to get stuff done; we get instant review and feedback and therefore, instant gratification. And it also led us from there into this notion of the whole game theory that's been...with the innovation games and all that's been taking the world by storm over here, the Agile world please.

We started to realize the alignment. So what we've been doing in the last couple of years is understanding that the better way to do human resource management or portfolio performance management, you know the 360 degree feedback, the review is really a remnant of the past; it's a remnant not even of the engineering age; it's the remnant of the industrial Taylorist policy which we still follow. We try to bring people the norm of. "Are you meeting? Are you exceeding expectations?" We try to get them to conform to the bell curve and we don't truly understand what motivates people.

So the HR policies, I think, are generation behind, maybe two generations behind.

Bulkin: I was going to say the 360 review system is step better than traditional review systems. Even that is still rewarding you for your individual performance not the team's performance.

Bankston: We've seen some of our clients, we've seen them doing quite well. I think at the end of day, if you're going to get feedback on people there really is no fundamental alternative to do something like it 360 review, you know, you get a number of parties and then of course it's a matter of choosing the right parties and asking the right questions.

We've seen some serious anti-patterns of some of our clients where, I think, one in particular a very large client, they're across the world. Several people have come to me and noted they're management by objectives policies are quite deleterious to their adoption of Agile initiatives in having to succeed because these policies are always quite individually focused.

And so, you might have an MBO that says, "You need to go and get 'x' hours of training in this particular subject and what it does, is to pulls you away from your team or that you need to do these particular things for your department and really, all of these MBOs for this particular client, at least, they tend to be all about that one person and it's really quite disincents them from teamwork.

Bulkin: I know one test who told me we have an MBO their objectives is to find an 'x' number of defects and] obviously the tester was not very motivated at that point to help the team and prevent those defects from occurring. I think we're closing up in our interview time. So, I just want to wrap it up and give you a couple of moment, you want to summarize what we've talked about.

Augustine: Sure. I can go over the list of the seven deadly sins of enterprise Agile adoption that we're talking about.

The first one is inappropriate scaling strategy where we talked about matching the scaling strategy to the size of the adoption, small adoptions probably go the whole hug than larger adoptions, enterprise to a hundred of projects and so we definitely want to go within an incremental approach.

The lack of organizational change management, we want to have the appropriate change management strategy, treat Agile as an organizational change management.

The lack of demand management essentially understands the value of portfolio management and don't just focus on the team, understand that we need to funnel projects to this portfolio and bring the projects to the teams.

Number 4: lack of engineering discipline — so, it's great to go get running with Scrum or Kanban but let's make sure that we truly build software craftsmanship engineering discipline into our teams.

Number 5: siloed or tiered rollout. I believe that we're doing the individual silos only or just tiers or mixed combination of both — we don't want that. We want to treat the enterprise as an enterprise and look at these and use visual management tools at the enterprise level, so not just at the team level.

Number 6: lack of tool sophistication — essentially, unless you have the appropriate tools especially in a distributed team fashion; and,

Number 7: outdated HR policies.

InfoQ logo

This interview originally appeared on InfoQ.com (Information Queue), an independent online community focused on change and innovation in enterprise software development and targeted primarily at the technical architect, technical team lead (senior developer), and project manager. InfoQ serves the Java, .NET, Ruby, SOA, and Agile communities with daily news written by domain experts, articles, video interviews, video conference presentations, and mini-books.

Showing 5 - 5 of 5 results.
Items per Page 1
of 5