The way I got here started up through the software development area, as like everybody else I did my time as a coder, has some master degrees in computer science, studied theoretical physics for a while, worked in the oil business for some time, building systems to keep some semi-submersible oil-rigs level so they don't flip over, with the first computer systems out there. Worked in Switzerland at ABB building control systems for electrical power plants and eventually stayed there, went back again and built the electronic stock exchange for the Swiss banks had failed twice before I got there and it is now running.
2. When was that? Were you using Agile then?
1996. Yes I was using Agile, but we didn't call it Agile because we didn't have a name.
Yes I am, that's one of the things I will talk about while I am here, it's how you create an environment where Agile emerges. Because it emerged.
It actually started with a one day session, at a local college in Utah, and I was involved in that organizing committee and in the break sessions here with Jim Highsmith and Alistair Cockburn as the main speakers we had. And then the first conference we had was six years ago, there were about three hundred people, and now it has grown to over fifteen hundred.
5. It is really impressive to see the room full yesterday at the keynote.
Yes, it's fun to see so much excitement and from all over the world. It is fascinating, you get on the elevator and you hear all these languages, and see all the badges, it's really fun.
The APLN is an organization to bring project leaders together, so the idea is to figure out a way to support them and give them a network of people they can call for supporting projects. Because what we find in projects is about everybody knows they are not predictable, and lots of interesting things happen, some good some bad, and so we wanted to provide a way for people to find information from experience. So we formed this network and people can sign up, we have local chapters, we have about fifty six of them I think now, and counting, and we had eight more chapters started in June. So it is very fascinating, we hold leadership summits, this year we held one in Dallas, in Seattle, we will hold one more in Atlanta, in September and one in Orlando that's on the Agile development practices. And they are now targeting different people so we are looking at different levels of leadership. For the one in Atlanta will work on real project leaders and the one in Orlando will work on more senior leaders, so looking at the executive view.
7. Excellent. How big are the conferences that you run?
They run anywhere from a hundred people to a hundred fifty people, we keep it small, it's all day, some of them have several tracks, some of them have two tracks some of them have five tracks, different ideas, different speakers come, it's an interesting model, speakers don't get paid, but we pay their expenses, so you have to be committed to the cause to participate, but we get excellent people to come and talk. It is fascinating.
Well I can speak for myself, I think management is about managing tasks and organizing tasks and making sure that those tasks get done in an orderly manner. Leadership is more about holding the vision and keeping the focus of the team, and the teams decide what needs to happen and what they need to do and when they are going to do it. And so they make the decisions. So leaders are helping them get the work done by helping them focus and asking questions, and making sure they have the tools they need to succeed but they don't manage tasks.
We don't. That's been the controversy in the organization is because some people wanted a competency based exam or competency based certification and the board has said "No, we are not going to do that. We don't have our members wanting that". So what we are working on now, we have a committee of about sixty or seventy people that talk about this and discuss it in one of the Yahoo groups and the idea is that they want to look at experience based recognition, that's what we are going to call it instead of certification. So you write an experience report and you have it peer reviewed by three people at least and then you are considered recognized and then the project can be a success or a failure. And it can still be a successful project.
10. That's interesting. Failed project still can be a success, can you tell me about that?
The advantage we have in Agile is that we find out whether we have enough business value to got to market so we are looking at the thirty six features that are useful and always used and we don't build the sixty four percent features that end up not being used at all or rarely used. So leaders can find out whether they got enough business value built, to go to market, but they can also find out if they are ever going to have enough business value to go to market and they find out early instead of finding out at the end of the project. So they can discover that and they can say "We're done. We are going to stop this project; we are not going to go any further". So instead of building a twelve million dollar project and then finding out it won't work, they can invest a small amount of money like maybe two million and discover that it is not going to happen. The market conditions may change, it may cost too much to build what you didn't expect, so you can stop and it's a great advantage but then it is still a successful Agile project.
11. So a project was started and failed to the benefit of the organization.What are you doing now?
I work at writing a book with my three partners for Addison Wesley, should be out early next year, the first draft is done. That's a big accomplishment. We did that, called "Stand back and deliver" about leadership tools, for leaders to help teams but not to lead the vision, hold the vision, how to hold the vision for people, and have them see it, have them see the strategy and project and complexities and uncertainties and how to collaborate, and how to look at business value, so we have been doing that. I speak a lot at a lot of conferences, which I love to do. I love doing tutorials, I love workshops I love giving classes so I do that about once a month. And I work with clients, we go into companies and help them discover inside their own companies how to be more productive and how to go to the next level.
12. You are also leading a session here at Agile 2008 on creating a culture of trust, aren't you?
Yes it's been a very popular class, Better Software asked me to write an article for their magazine and I wrote the article and then I did the presentations, and people are fascinated by this which I always think "common sense", everybody knows how to do this. But not quite, I guess, people keep showing up and they want to talk about it.
Well, people are beginning to understand that within a culture of trust leaders can stand back and if you don't stand back then you are hampering and restricting the productivity and the creativity and the innovation of the teams. So if you want them to work highly productive, have highly productive teams, you have to trust them. And they have to be able to trust each other. And you can't make people trust each other but you can as a leader create a culture that would foster trust then encourage it to happen and they get as safe as possible.
14. What are some of the elements of that environment that fosters a culture of trust?
Safety is always a big one. Being able to count on what people say, when people say "I will do this" you know they will do it. And that is very important. It has to eliminate fear, you have to eliminate as much as debilitating fear as possible so sometimes I find in organizations that some leaders are indiscriminate about how they manage conflict in the teams or they manage the behavior, if you want to call it managing behavior however you may look at that but they may see people and think they are not productive and they will reprimand them and it will be indiscriminant and that creates fear and it takes a while to work with a team, usually takes about a day before they will finally start talking about the fear and what it is, you have to build up the trust in the seminar, until they finally tell you and it is always instant like it is a switch, as soon as they say it, it happens and one organization I worked in somebody had abused the Internet, so everybody was not allowed to work on the Internet.
And they asked me about it and they thought I was fearful and they thought I was distrusting and they were really unhappy. And I said "Anybody that would do something like that is an idiot" and they go "Oh you agree with us?" and I said "Well, yes, that's distrustful". And they got an email yesterday from the executive of the company saying "We've turned the Internet back on". So they are getting it, what their message is and what the activities of leaders are and what message they are sending about trust so people are learning that if you don't have trust in the people they are working for you they know it, and they are not going to be highly productive.
They are not going to work for you. If you want highly productive teams, it's not just that you give them interesting work, you also have to let them make the decisions, you have to let them choose how to build their pieces and you have to trust them to deliver because you can't micro manage them. As soon as you start micro managing people their productivity starts to drop. And I have been in companies where I have seen productivity as low as 20%. And they are not happy people.
You teach leaders to ask questions and not tell. When someone comes to you and say "What do you want me to do? Or Is this the right answer? Or is there a problem here?" you say "What do you think? How do you want to solve that problem? What do you want to do about that?" They will come and say to me: "How do you want me to build this Pollyana?" and I say "How do you want to build it?" We hired you for your expertise and your talent, the way you solve problems, so solve problems.
16. How quickly does that turn around?
Sometimes the fastest I have seen it turn around is about three weeks which is for a full organization. It was the city library in Salt Lake City Utah and it is huge, it is a big library. And there were about twenty five people on the leadership team and it turned around in three weeks and I went "Wow that was fast". So it can happen but you have to have leaders that would hold the line because people test it and see if you are really going to do that.
And once you give in and rescue them as we say, and fix it for them, you're done, they are going to expect you do it all the time. And sometimes leaders say to me "Well if I don't fix it for them or I don't tell them what to do, what am I going to do?" And you see vice presidents telling you this and I am going "You are a Vice President of a billion dollar company, I think you should be looking outward at what's coming in the market place and how you can get ahead of it", and they go "Oh, ok". I am amazed, there is so much that business is forward thinking and forward looking that organizations need leaders to do, because they know the vision, they hold the vision of the company, and they need to be expanding their market, they need to be expanding the way they sell the way they reach their markets and I can't believe it they are spending their time looking at accounting papers and say "You have an error there" I am going "Give me a break".
17. We have all seen that kind of micro management though.
Of course 80% of the leaders are still command and control. The work that I am doing now is very interesting because people are asking me, senior leader level, VP level, of really big companies want to know how to transition their leaders from command and control to more participatory or leading collaboratively or leading in an Agile manner. And that is the work I am working on now, so stand by for some more articles they are going to be fascinating because this one really big company wants to try it and see if we can get it to work, they are willing to step out there and do it.
The vision is a combination of the purpose of the project, and the deliverables, the results, what results do we want, and trying to achieve the maximum business value of that. So, what a leaders does is builds the filters and say the purpose of this project is going to differentiate us on the market place, or we just have to reach parity like everybody else so that's the purpose.
And so you have to hold that and you have to be outwardly-looking so if that the market changes, and all of the sudden your differentiating project becomes a parity project, you have to be able to remind the team, focus the team on that and say "Our competition has beaten us to the market and therefore we are on a parity mode and so we would better focus on reaching what everybody else has and get it out there today quicker, how do we want to do that? How can we do that? What do you need to do?" So they focus by asking questions and everything else has to pass the filter and "Is this going to maximize our business value, is it going to reach the customer needs? Is it parity or is it differentiating for everything?" So they … the filters and they ask the questions for people to say.
Well I do it collaboratively. So when you go to make the prioritization on your feature list, marketing is in the room. Your customers are in the room, you talk about the business value or the value to your customers the value to marketing, and the value to the organization, that's internal.
20. And software development is in the room.
And software development is in the room. Especially the testers I believe that the testers are the gatekeepers of the features because if you don't have a test case, the code doesn't get built, doesn't get added to the build. So, any code that comes in there is no test case for it in my mind should be deleted. It was one of the very first things that I did at the stock exchange, and I don't know why it happened, but I said we had one week iterations and three months release cycles, one week iterations of market ready code that's very interesting. And I would say to them if I find any features coming out of your week that is not on your list, you are off the team, you are gone. I said I'll give you all the time you want I didn't ever sit down with people and say "Can you give me a better estimate?"
We had eight people doing the planning team so eight people would work on backlog, fixing the backlog and reordering the backlog all the time, and putting them in one week iterations for a hundred and twenty people. So I always said that to them and one team started doing it and I said: "What are you thinking here? What's happening?" and they said "Well the VP is coming down here and he is going to own the maintenance of the system and we are writing the maintenance features and he keeps telling us what we have to do". I said "Ok, I'll take care of that". And they said "You can tell us anything you want and we will deliver it, but has to go in the backlog first, stay off the floor".
Yes collaborative groups or if you can't you use story cards and you put the business value on the story card and the purpose. So people in the whole organization have to understand what it means to be differentiating in the market place or just reach parity and that's where you run into trouble, if you are building an accounting system that for your internal organization it only has to be parity as your competitors. So you shouldn't be adding extra features. And that is hard, because that is where developers go off the plan. And we end up with features nobody wants to use or one person wants but developers think: "Oh they got to have this, they will love this, this would be cool, we'll just throw it in here". Pretty soon you'll have a bunch of thrown in code that nobody wants to use and the real code they need is late. So people forget that Agile is about discipline.
Yes, planning happens all the time because everything changes and Agile is to embrace change why do we think we are going to embrace changes in requirements? We are going to embrace changes in the market place we are going to embrace changes with people on the team, they are going to come and go, we are going to embrace changes in risks that may affect us, we are going to embrace changes of options, how we build options to protect our risks going forward, so it's the same way with business value, we end up at the very beginning deciding what business value is and then we forget it till the end. Well that's not what I am talking about anymore.
You have to build the business value model based on purpose and consideration and costs and benefits. And you build the model and then at the end of every iteration you look at the inputs again and see if anything has changed. Time to market may change, you may have a window that opens up later for some reason, it may run that it opens up sooner. Because you've heard from the competition. It always been a worry mind when marketing goes out and touches the real world and they come back and say "Oh we have to make this change, because the competition has it now".
Then how does that information get from that edge to the edge down here of our developers? And that is through that collaboration process and reassessing the business value. So at the end of the iteration you are looking at the business value of what you got with a new model not the old one and then you go through the backlog and do it again with the new model and reprioritize them so you are constantly embracing the changes on how you determine business value as it goes along.
Well, I think that the advice is not just for project leaders but I will talk about that. It's about project leaders, middle management leaders and executives including it. It's like the book that we are writing called "Stand back and deliver". You have to let your teams to become creative and innovative. You have to let them do their work and choose their work and decide how to do it. So you essentially have to stop micro managing. So you don't get to tell people what to do anymore. You help them stay focused by asking questions.
When someone comes into my office and said "Pollyanna, how do I design this? How do you want me to design this?" That's my favorite question: "How do you want me to design this?" I look at them and say: "How do you want to design it?" You know, this was a task or a piece of software that you are passionate about because you chose it this is the one you wanted to do. You are very passionate about it and you have experience and knowledge in that area, so how do you want to build it? I had one guy come back three days in a row, every morning at my desk "How do you want me to build this Pollyanna?
I want you to use your expertise and your knowledge and the way you think and solve this problem." And next day, how do you want me to build this? I want you to do it.
And the hardest part for leaders is that they finally stop coming to your desk, you have to trust them to deliver. You can't check in on them and say "Are you ok? Do you need any help?" They don't need any help or they'd be at your desk saying "I need some help". And when they do coming ask for help, you have to help them look to the team and not to you. Why leaders think that they know everything right now is just beyond me.
25. So, what does this mode of leadership using questions look like at an executive level?
The same thing. They stand there, they work together collaboratively to talk about what their vision is and what their goals and objectives are to manifest that vision. So, people have high level goals, we have to make so much money in this area. So those executives go off with their team and they sit down with their leaders and they do the same thing and they ask questions. So the executive goes to their leadership team and say "How do you want to do this? How do you think we are going to get there? What project should we do? What's going to be the value out of those pieces? How's that going to help us reach out goals and objectives?" That's all they ask.
26. How do they feel about switching to that mode?
Some of them are very uncomfortable, but everyone is becoming very aware that without that mode that Agile does not work as well as it should. And a lot of leaders have talked to me about it. In summits they show up and they talk and they say "You know, our first thing we had to learn was the new way of leadership. We had to build this stand back, we had to stay out of the way". The real issue is that leaders need to help. They think they need to help people. So, the old days they could see the red flags and they could step up in and help. What now has to happen is we have to look at the red flags and ask questions to help them focus.
But we don't know what the red flags are. Because they have changed and that makes everybody uncomfortable. So leaders are going back to their old style the style that they are comfortable with and the one they know, which is command and control usually, first to middle managers, that's what they are holding on to, and their success and the project's success, is very essential to them in their career progress. They are very concerned about being able to make the team a success, but they have to learn it by standing back and asking them questions helps them solve the problems is what I say the opposite of control is discovery. So if you want people to find the best solutions, you want them to find them quickly, you have to let them know that you trust them and you know that they will find it.
27. We'll look forward to seeing your book next year by way of helping us do that. Thanks very much.
You're welcome. Thanks for asking me.