Cliff: You came to JP Morgan Chase from Thoughtworks – a marquis agile services company and the home of Martin Fowler. What were your main takeaways from your time at Thoughtworks that you feel have impacted your work going forward?
Elena: Thoughtworks primarily makes money by writing and delivering custom software, so their approach to agile is a practical approach of what works to create the highest quality software in the best possible way. That I was able to experience software development in order to get software delivered instead of as a set of prescriptive steps makes a huge difference to me. I am only interested in the results: I am not interested in getting an agile badge at the end of the day. Software is less prescriptive and more about thinking.
Martin Fowler sets the tone. Thoughtworks is not prescriptive. They have the best recruiting process that I have ever seen.
“I am only interested in the results: I am not interested in getting an agile badge at the end of the day. Software is less prescriptive and more about thinking.”
Cliff: In your current venue – a large corporate organization with lots of compliance requirements – how has this impacted your views on prescriptive versus understanding the intent of agile processes?
Elena: Absolutely: because a large corporation where there are layers of command and control and regulatory bodies looking over your shoulder, people who are prescriptive about agile would just tell you, “Don’t go there because it is never going to work”. My attitude is, Let’s go where there is a problem to be solved, and lets apply techniques that we know will work to make things better. I have ended up with a technique in this environment that works way better than the waterfall alternative that we were using before.
Cliff: Do you feel it is important that coaches and others have agile certifications?
Elena: I think pretty highly of the PMI ACP credential. It is a standard curriculum. It does not make any claim that you are the master of anything. With the Scrum Master certification, even though you have had a course on how to be a Scrum Master, the fact that the word “master” is in the name implies a-lot more than should be implied by the fact that you have taken a two day course.
That said, the proof is always in the results that you get with the person. Cert speaks to the person’s interest in their seriousness in pursuing agile techniques as a professional. In a corporate environment as I am in, a certification can differentiate a person with equal skills who eschews all certification because that kind of radicalism would not work quite as well in this environment as it would, say, in a startup.
Cliff: You are quite versatile: not only do you have a deep background in agile, but you also had the role of business architect for the Corporate Investment Bank Operational Stability group at JP Morgan. Could you explain that versatility and how you found yourself able to move from one role to another and whether you found that versatility important for the kind of work that you do.
Elena: Like most people in technology, there is an odd fit between what I do and the job title that I happen to have. I was acting as a business architect, I am acting as a project manager right now, prior to that I was acting as a chief agilist/methodologist. I can do a-lot of different things and so I can hold a-lot of job titles and I think that is a good thing to do but I would not say that everybody must be a generalist to be a success. I think people must know what they love and are good at and find a place where that’s what people want and know that that’s where they should be.
Cliff: With senior positions one often sees that the person defines the job, rather than the other way around. Do you think that in an agile setting that versatility is an asset at all levels?
Elena: Yes: There is a whole conversation in the agile community around this. Remember that I am a senior person – I am over 50 and I am very practical – so, having seen a-lot of different things, what I think is important is to build a team that has the right mixture of skills across the team members, not necessarily with specific skills monopolized by specific people. On an agile team you end up with everyone pulling together and contributing what they can. On the one hand, I want to make sure that the whole team works well together and not someone arguing “that’s not my job”; on the other hand, in a large company or a large economy, you need to understand that there are a bunch of people out there who have made their profession to be a BA or to be a tester, so if you want to build the best possible team, and you insist on only hiring people who only put agile generalist as their job title, you are limiting the pool of people. On top of that, historically, there have been a-lot more women in analysis and testing, and what has transpired today, particularly in the Scrum community, is that everyone on a team is a “developer”: they mean in a generic sense, but what happens on the ground is that everyone who gets hired is a developer (programmer), and suddenly they don’t have the right skill sets, and then they hire some women who don’t get the developer title, and then suddenly everyone is not a developer anymore, and some are making a-lot more money than others are; so I feel that there is an entire gender apartheid that sneaks in – not because it is what anyone intended but because that is just how it works out. In the end I just want a group of professionals with the right skills mix but I am not picky about who does what.
“...you need to understand that there are a bunch of people out there who have made their profession to be a BA or to be a tester...”
Cliff: So you really have to think long and hard about the skill makeup of the team, rather than prescriptively going down the playbook so decide what kinds of team members you need.
Elena: As a shortcut, at Thoughtworks you were a dev, a quality analyst, or a business analyst. For these, there were skills sets. You could move around. When you staffed a team, you took people who self identified: four devs, one analyst, one tester. Not just a matter of ability, but a matter of preference as well.
Cliff: You are currently a VP of corporate compliance tech. Is that an unusual path, going from chief agilest to a compliance role? How do you reconcile the compliance viewpoint with the agile viewpoint?
Elena: Agile is the most disciplined way to develop software. At Thoughtworks and the way we do it here, it is very disciplined: you don’t start developing until you have figured out your environments and your team; you do all the hard stuff first, so that you can actually use agile for predictability, because everything that is unknown has been settled before you start making a commitment or an estimate. Because agile is so self reporting, you can do a burnup that shows when something will be done. A colleague who was an auditor for CMM and he said that a team that agrees to be coached in this type of agile is essentially a team that goes from CMM level 1 to 3 in probably three to six months. I can’t picture a better way to do software development if you want controls.
“...you don’t start developing until you have figured out your environments and your team; you do all the hard stuff first, so that you can actually use agile for predictability...”
Cliff: That goes way beyond Scrum: it really has to do with release planning.
Elena: Yes. Thoughtworks does “Scrum Plus” – they did it much longer than the term has existed. It is now a bandwagon that people are jumping onto. We use the Scrum process for managing but we wrap it in a protective layer of significant planning.
Cliff: A-lot of XP people joke that Scrum is just XP without all the technical practices that make it work.
Elena: I think that’s true. What I would describe myself as doing is Scrum, XP, and Lean wrapped in release planning processes.
Cliff: Why is release planning so important in an organization like yours? And what kinds of things do you feel need to happen in release planning?
Elena: It follows naturally from the concept of “last responsible moment”, so if you are in a small city you can hold off on a lot of major decisions, like whether you are using a database: you can use a file system until it becomes clear that you need a database. In a large corporation you have to have a pretty solid idea of whether you are using a database or not, and what your systems are going to be for development and testing and production because the time to acquire a new piece of equipment can be a year to 18 months. So a-lot of release planning entails acknowledging that there are logistical processes that move slowly.
“What I would describe myself as doing is Scrum, XP, and Lean wrapped in release planning processes.”
Cliff: One of the long lead time things that I have run up against is security related processes. Obviously you have Sarbanes Oxley. Do security related processes need especially long lead time?
Elena: We have really high quality tools for handling security testing that we can incorporate into every iteration so we don’t even have to do anything special to get them. So for me security is a thing that just needs to be a paragraph in my overall quality plan, and then I just need an architect and a development lead who can make sure that the people who are doing the development are able to understand how to use that software, so we can actually be doing security screening from the moment we start writing code. So it has never been on my critical path. I have a much bigger problem hiring a whole team, or getting a whole set of environments that enable simultaneous development, test, and UAT to go on, than I would ever have with security.
Cliff: Is there a security or governance group that has to do security review? And if so, how have you removed them from the critical path?
Elena: Well they have a process for addressing security from very early in the value stream, and agile is much better able to satisfy that process than any other approach.
Cliff: What does that process look like?
Elena: It covers every aspect, and there is a special focus on the security of customer information, so it is just a matter of proving that you are covered under all of the security dimensions. All of our infrastructure is built out by a group that follows this process. So we are concerned with the coding level, and we would not write insecure code, in fact we put better safeguards in our code than other people do.
“Well they have a process for addressing security from very early in the value stream, and agile is much better able to satisfy that process than any other approach.”
Cliff: So is it a matter of convincing them that you have a secure coding process, and that way you have removed them from the critical path?
Elena: Yes. They will review the actual code eventually but if we are doing actual security testing every two weeks or with every build, that’s way more surveillance than they could ever provide.
Cliff: You mentioned that various types of testing are a critical path item and you even posted something to that effect on the Transition2Agile website. You mentioned that using mocking tools such as Lisa were helpful in eliminating some of those critical paths. Is it still a critical path? What are the main challenges to setting up test environments?
Elena: Most of the challenges come with standing up the environments to be able to test from day one. It is the thing that you tackle before you make any promises. Once you have crossed that hurdle, then you find a team that is able to do repeated builds and repeated deploys to test, who are open to automation, so there is a whole bunch of new skills that need to be taken on board. But in general testers and especially user acceptance testers love agile because you are thinking about them from the get-go about their requirements.
Cliff: So they become part of the game. Are they treated as part of the team – as developers – or are they treated as a testing group within the team?
Elena: I don’t always have control over that. I feel that a team should be made up of individuals who are on a team and there are lots of different staffing models, and I try to get as close to that as I can, and I treat it as a risk to be mitigated if I can’t get that.
Cliff: What are your thoughts on transitioning to some of these things? Both at a team level and at an organization level? Should it be gradual? Or treated as an urgent thing?
Elena: I would never want to be motivating people in terms of being more or less agile. I would want to know what the business drivers are and then I would pick low hanging fruit to get the teams in the direction that they need to go from a business perspective. So I would prefer to change the conversation immediately from “Which agile techniques do you use”, to “What are your business problems?” and let’s solve those. I am an advocate of cafeteria agile, where you have a whole choice of techniques to use, and you understand what they do, and you apply them as appropriate to a given business situation. So I don’t have a blueprint of how to become agile: I would say, “What problems are you having?” and I say, “Here is how you would typically solve that – are you willing to try it?” and if so, you really need executive sponsorship for that because you are changing things and change requires a-lot of executive support. But I would measure business indicators, not things like how many daily standups you have had or are you using a backlog management tool or what-not. The things that make you look agile externally might not correlate to you doing something better for your business.
“I would never want to be motivating people in terms of being more or less agile. I would want to know what the business drivers are and then I would pick low hanging fruit to get the teams in the direction that they need to go from a business perspective.”
Cliff: That is kind of a management consulting viewpoint.
Cliff: It sounds like you are saying that there are discussions that need to happen with leadership to ask why they want to go agile, and that maybe agile alone is not sufficient: maybe you need some other ideas too.
Elena: Yes. And it depends on what you define as “agile”. Thoughtworks defines agile as “start with the right people”, so if you go into a company with guns blazing and say that to be agile you need to reevaluate your entire staff, that is not going to be that popular. But it could be that in the end to be successful that there might need to be some attention to that, but that might not be the thing to start with.
Cliff: One of the challenges there is that if there are functional silos, then it is hard to get good conversations about it. From your overall experience in many organizations, what are some strategies for advancing the collaboration across silos within the IT organization to reach consensus on actual goal and how agile might fit into that?
Elena: This is pragmatic: you cannot do grass roots agile in a large company – you just can’t. If you have silos in your IT organization, you have to have the person who is their boss decide that it is important for the conversation to occur. Executive sponsorship for an agile transformation, just like for anything you might want to get done in a big company, is make-or-break. If you have the unwavering support of an executive, you can try and fail a whole bunch of times, and they will stick with you and eventually you will find something that works. If you don’t have executive sponsorship you could come up with something perfect and beautiful and they will be like “No, I don’t like it”. There is no way for you to be successful without pairing with some at the very top of the organization that you want to change.
“This is pragmatic: you cannot do grass roots agile in a large company – you just can’t. If you have silos in your IT organization, you have to have the person who is their boss decide that it is important for the conversation to occur.
Cliff: The agile community is calling for things like culture change, but does not seem to have answers for that. Yet the org change community has been dealing with this for decades and has many answers for these situations. That is why we formed Transition2Agile: to bridge agile ideas with org change ideas.
Elena: Culture change is the hardest thing to start with.
Cliff: Yes, it is like saying, “Let’s start with the thing that is almost impossible”.
Elena: Yes, if that is a prerequisite then well – I rant about that on my blog now and then. If you culture is toxic, then what do you do? You either have a business problem to solve and you stay or you leave.
Cliff: The agile community has the assumption that if you leave everyone alone they will all self organize and work together.
Elena: And I say, “What people did you ever work with in real life?”
Cliff: My wife is a therapist and deals with people’s personality issues every day, and when I tell her about self organization she looks at me like I am from Mars.
Elena: Steve Deming has a very cool diagram that shows the difference between self organization and self governance. His point is that you can self organize but you need to have governance around a set of teams. You can’t self organize a set of teams. I think that is a crucial jump that agilists need to make.
Cliff: What do you feel is the right balance in terms of working with leadership, functional management, and teams?
Elena: It depends on who has the power, and who has the pain points.
Cliff: How do you divide your time between tactical team work and leadership discussions?
Elena: I am doing a tactical job right now and I am glad because it is “sharpening my saw”. It is giving me hands on experience with the issues. I am not off in an ivory tower preaching about theories. So the answer is how can you personally fit best into an organization to get the best results. My boss is really good at organizing at the program level.
Cliff: Does JP Morgan Chase do a-lot of software development inhouse?
Elena: It depends on how you define in-house. JP Morgan Chase has 270,000 employees.
We pretty much do every combination of vendor thing that you can do. If we develop our own non-functional standards for code quality, etc., such as using Sonar, then you actually can arrange with a vendor to give you code deliveries in two week increments and you can write automated tests that you run on what they deliver.
Cliff: Does that require having executable tests?
Elena: Yes, although you could do it manually but it would be better to have it automated.
Cliff: How important do you feel devops is for your agile processes?
Elena: I think that is where we have to go. Absolutely. It is not a goal that I have been able to achieve in this environment because even ops reporting goes through and entire executive chain than the developers. Optimally you are building in functional and non-functional tests as you go. You can use feature tagging. You can put things into production without turning it on. Everything is automated but still supervised. You have living code that is completely wrapped in protective automated tests. Then you don’t even need an operations group: you just have a development group. If people want to save a bunch of money they would move toward continuous delivery. But that is going to be a-lot more practical in green field than if you are working with an old system.
“I think that [DevOps] is where we have to go. Absolutely.”
The world changes so fast. You hear “We can’t do that here”, but at JP Morgan I have only worked on new code the entire time I have been here: greenfield software development occurs everywhere. All organizations do new code.
Cliff: Is there anything you would like to add that I did not cover that you feel is important for agile adoption in large complex organizations?
Elena: We need to be thinking more about the product management side. The most challenging thing is often finding out the business problem that needs to be solved. Product owners need to be able to say “No that’s not what I want” many times.
Cliff: So there are market driven needs that are hard to pin down up front.
Elena: IT often does 85% of the thinking. In practice, tech often sets a-lot of the business direction and takes guff as they do it.
Cliff: Thank you Elena!
Elena: Thank you!