 Our next speaker for the day is Rebecca Parsons. Rebecca has been a great inspiration for me as well. She's been not just an inspiration but also a great mentor. She's tremendously helped us with this conference. And I've worked with Rebecca in my previous organization. So I thought it would be cool to have Rebecca come here and share some of her experience. Things that are not easy, things that are hard are actually important and sustainable. So I'll hand it over to Rebecca. Thank you. Thank you so much, Nuresh. My name is Rebecca Parsons. I'm the CTO of ThoughtWorks and also a member of the Agile Alliance Board of Directors. Now for something completely different, as they say. Following a talk like that is difficult. The lives of those women lead and what it tells us about how privileged we actually are to be able to do what we do. It's something that hopefully we can all keep in context. So the title of this is Agile is not the easy way out but it does work. And what I'm trying to talk about here is thinking about what it is that we do and what we choose to do. And some of these things actually are much more difficult than they might appear to be but we do it because it works. We do it because it's effective. And so that's what I really want to talk about here. But I want to start with a metaphor. And for those of you who know me you'll know I'm the world's least visual person but you're about to see something you almost never see in a talk from me which is pictures. But I call this the tale of two toy castles. When I was talking about this presentation and in particular trying to figure out how I was going to talk about Agile and technology or talk about helping women work they were out of the sex trade and get their self-esteem and their courage and their self-respect back. They said well you need something to kind of bridge between the two worlds. What is it this business does? Well they make bags and they make t-shirts and they said okay we've got to find a textile metaphor for you. Here we have a knitted castle and you can actually buy a kit to knit that castle on Amazon. I don't think you want to put this into your catalog I don't know there's that much of a market for it but you can get just about anything on Amazon. This is literally a castle that you sit down and knit with yarn. On the other side you have a castle made out of Lego blocks. Now I want you to keep this metaphor in your mind as we go through this talk and in particular what I want you to think about are three completely different aspects of how we do our jobs. The first is what is your team? How does your team look? How does your team work together? How is that team developed? And the second is the system. How does the system, the software system, the software asset that your team is building what does that look like? How does it evolve? How does it change? How do we assess the quality of that artifact? And the third then is the business itself. How able is the business to adapt? How is it responding? So I want you to keep this metaphor in your mind you've got the knitted castle and the Lego castle as we go through this talk and at the end I'll come back and talk about this again. So within the Agile community there's this wonderfully religious zealous debate and we all love religious debates like the language wars or the IDE wars, you know, Eclipse versus IntelliJ Java versus C-Sharp, all of those wars we love and within the Agile community the war that we seem to be battling at the moment is which matters, the principles or the practices? Are you Agile because of the way you think or are you Agile because of what you do? Can you be an Agile developer if you don't pair program? What I want to talk about is both the principles and the practices. From my perspective though, if we are going to look at Agile from the perspective of the broader organization we have to focus on the principles rather than on the practices. And we all have our favorite principles. Probably my favorite is the notion of feedback. When you look at how often the productive use of feedback and the response to feedback that we see in our systems. To me, that's an essential part of Agile. Yesterday there was actually a talk the empirical core of Agile which is all about applying control system theory to thinking about Agile software development. What is control system theory? It's talking all about feedback. But we have other critical principles like transparency, like reflection. So those things are very important when we think about Agile. But it's these principles that actually inform these practices that most people recognize as Agile. If you talk to people who are not within this community they will associate things like pair programming or continuous integration or scrums and sprints. Because they think about the practices. If you're not within the community the most visible thing that we do is not talking about the principles but it's actually living out the practices. And it's these principles that give rise to these practices which is at the core of the day-to-day life of people who are working in an Agile environment. Combining things together this results in an approach which I believe has four critical properties. The first is that it's disciplined. There is this common sense that we're all cowboys, we're all cavalier. We just go off and we don't care about standards and we don't care about quality and we don't care about the business and we don't care about money. We just want to do what we want to do. That couldn't be any further from the truth than it is. Agile is actually quite a disciplined process and I'm going to talk through several aspects of how Agile is disciplined. The second is Agile is sustainable. Anyone can do something for a brief period of time. Very often, or never that I can think of as software developers are we faced with a situation John was talking about where in one instant a 13-year-old's girl's life was changed forever. We don't have those problems. We get put into situations where, okay, I can probably work one 80-hour week or one 100-hour week or one 120-hour week but that's not sustainable. For Agile to matter in the long term, for Agile to matter across our industry, it can't be something that relies on heroic efforts and so what this process is is sustainable. This is my personal favorite. Agile is also grounded in reality. In the work that I do very often, when I think about the prime purpose of conversations that I have and activities that I undertake, it's to get people to accept the world as it is rather than accept the world as they want to see it. The amount of delusion that is often built into IT organizations is pretty astounding. We would really like the world to be a good place. I would love the world to be a place where John was out of a job. Unfortunately, I don't think that world is going to happen anytime soon but a lot of what we're trying to do in Agile is make sure that at least the software delivery processes that we are undertaking for our organizations are actually grounded in reality and when you put those three things together once you get something, it actually works. It doesn't work all the time. If we go back to the manifesto, there's still that people over process and regardless of how good your process is, if you want to have the right people doing it, it's not going to work. Nothing is guaranteed in this but I firmly believe that when we put these principles together with the practices and execute them in a proper way that we have the highest probability of being successful. So this isn't the easy way but hopefully we'll see why it works. So I want to take each of these three prime elements, the result and this effectiveness and talk about some of the principles and practices that underlie it. And I want to start with discipline and I hear two very different things when I try to talk about Agile to organizations that are still getting used to this concept and the first one is what I mentioned before that it's just this cavalier approach. You don't care about standards, you don't care about the long term, you don't care about anything, it's just so that the developers get to have fun. The other thing that I also hear is, and oh by the way, Agile doesn't work unless you have very small teams of highly skilled individuals. My organization has to hire average and hopefully above average people but I don't have the cream of the crop and I never will because I have to hire in the normal market, there's nothing that distinguishes me from anybody else so I have to hire average and Agile only works with highly skilled teams. And in fact I have some people who are incompetent or really below average and so I have to protect them. It's like how is any process going to protect your code base from a developer who doesn't know how to do his job? And this is one of those, do you really believe what you're telling me that somehow a waterfall process will protect you from someone who doesn't know how to do their job? So what we have instead is a process that does have very high expectations for the individuals on the team, not just the developers, the analysts, the project managers. There are high level of expectations that we have on the performance of individuals on the team. Let's start with some of the basic practices. When we look at Agile software development, pair programming is one of the things that lots of people talk about because it's so controversial. Why in the world would you have two people doing one person's job? And one of the important things that I like to emphasize with pair programming because it helps us look at the principles and how they might give rise to practices in other areas. Pair programming is all about the fact that we believe code review is good. Well if code review is good what happens if you turn the knob up to 11? What if you do code review all the time? And even though people focus on the fact that this is two people working on the same piece of code at the same time, the principle, the objective behind pair programming is all about constant code review. As code is being written it is being reviewed. It is being discussed. The individuals who are participating are thinking all the time about are we approaching this problem the right way and it's not one person and it's very easy regardless of your best intentions to get blinkers on. I'm just going to go this way and having someone off to the side saying hey wait a minute, if we take this route it will be much quicker. So that's what pair programming is all about. Testing is a key part of making agile work. Testing at all levels, unit testing, functional testing, acceptance testing, technical testing, all those aspects of testing. Again it's a very disciplined approach. You know immediately if you've broken something. Your team knows immediately if you've broken something. And continuous integration. To actually do continuous integration right does not mean oh it's Friday afternoon I better check in. Continuous integration underlines the continuous word. That means you're checking in on a regular basis. And why the reason you're doing that is it allows you to understand how what you're doing is being impacted with what everybody else is doing. Without that continuous integration you don't have that feedback. So this particular practice goes back to this principle of feedback. You want to know as soon as possible when you need to have a conversation with someone else about the code that you've just written. The unambiguous definition of done. I have never been able to figure out how it is people can with a straight face say last week this huge three month's task was 70% done and now it's 80% done. I can tell the difference between 10% and 90%. But are you really going to tell me that you can that precisely distinguish between 70% and 80% done? That doesn't make any sense. The discipline part is to say I'm going to put a hard line. It either passes all the tests or it doesn't. It's either done because it passes all the other tests or it's not. And the only way it makes any sense at all to start talking about 75% or 80% done is in the aggregate. If I've got a reasonable estimate of the relative size of things I can say I am 80% done because 80% of the stuff is 100% done. And I don't care if I might have things over here that are 90% done because I don't know what 90% done means. So it's either 100% done or zero and the only percentage done that makes any sense at all is in the aggregate. And once you get that on a beguished definition of done you've got much more clarity into where you really are. Continual refactoring. If we are being serious about our craft as software professionals when we see something that's broken we ought to fix it. And part of what enables this is having that comprehensive test suite that allows us to say this new thing that I'm doing is going to change this piece of code in this way and I want to make sure it's done right. And so I'm going to not take the easy way out and copy it and paste it over here and make my changes but I'm going to actually take the time to refactor this to properly introduce this new feature into the code base and to keep up the overall quality of the code and the critical part of making this thing sustainable. Because if you're constantly taking the short term of I'm just going to hack this thing in eventually you're going to have a house of cards that's going to collapse. Standups and retrospectives. This is a critical part of how we make these teams work. The standups are important because every single day the team is focused on what are the blockers that will prevent us from doing anything and what do we have to do to fix it. If you've got a feedback loop of a problem being raised and you have no way to fix it it's not a very useful feedback loop. If you can't take action on the existence of a piece of data you shouldn't be collecting it because there's no point. It's a wasted effort to collect data that you can do nothing about. So these standups exist for the purpose of removing the blockers and eventually the retrospectives are... I'm a software developer I know how many times I've said I'm sure it's going to work this time and you're just absolutely convinced that now you understand what the problem is and you're going to be able to say this fix is going to do it. I know I've got it nailed. Part of what being a member of an agile team is about is being able to put your hand up and admit I've been saying that for long enough I need help. And as software developers having to get up there and say I need help is not always the easiest thing to do. So we're asking people to take risks by saying I need help I have a problem. We're also asking the rest of the team to step up and provide that help in such a way that it doesn't demean people. So this is not an easy thing. Many people talk about developers as were the world's most anti-social creatures. I often tell people I got into computers because they were a whole lot easier to deal with than people. Kind of ironic the job I ended up in. Agile is actually a very social process. Software development can be a very solitary process but only in a very narrow scope of applications. Some individuals can do incredible things all by themselves but the kinds of problems we face require us to work in teams. And that means people have to have the courage to stand up and ask for help and others have to have the respect and trust to offer that help in a productive way. And finally, Cavalier attitudes really don't work very well in the long term in an Agile team. And people who really aren't pulling their weight can't survive. It's interesting when I talk to teams that are getting ready to start adopting Agile software development, you can almost see the look of fear in particular individuals' eyes because they know all of a sudden people are going to know there isn't any place to hide on an Agile team. If you're pairing with someone that person you're pairing with is going to know whether or not you're paying attention whether or not you're working hard, whether or not they're doing all the work and you're just coming along for the ride. And eventually that's going to show up in the team because no one's going to want to pair with them. And all of a sudden you have this situation where someone who really hasn't been doing their job there's a spotlight on them. But the reverse also happens. You have people who really want to learn and perhaps didn't have the right training or haven't had the right experiences or haven't had the right opportunities. In an environment where you have so much feedback on your code quality you have all of the style checks that get built into builds. Now you have the opportunity for people who really want to learn to actually get better. To pair with the people on the team that are more experienced than they are and to swallow their pride and ask for help. Why did you make this particular decision because that's not what I would have done to start to get better? If you really want to learn and improve an agile team is a great place to be because you are constantly receiving feedback on the quality of the work that you're doing. And in a respectful agile team that is a tremendous opportunity for someone who wants to learn and improve their craft. So these processes together form a very rigorous structure within which we work and this is what really drives the discipline aspect of what we do. But there's an important part of this as well which is that it is the team that is putting in and enforcing this discipline. I've had people ask me how is it you enforce the check-in build. So the verify that the build is going to work before people check in process. It's like no one has to enforce it because if you're the one that breaks the build and the siren goes off or the email goes to the entire team broken build you're not going to do that more than once. It might still happen but if you really didn't follow the process and it happened because you were lazy you're going to feel horrible facing all of the people who get to listen to this siren that's going off because the build is just broken. So these processes have a very disciplined structure and everyone who is working within this agile team is working in this discipline structure. So the next key part is sustainable. As I said if you've got a deadline that's two weeks away it's phenomenal what somebody can do if they're just focused on I've got two weeks and I've really got to do this and it's critical. But agile is a grown-up process now. And for us to be a grown-up methodology this has to be something that a team can continue to do for one year and two years and five years and in fact part of what we're seeing now and what I've sometimes heard referred to as the backlash against outsourcing is the fact that if you've got a development team sitting in California working with a development team in Bangalore that's a 12 or 12 and a half hour time zone difference you know 11 and a half or 12 and a half depending on where we're at and if you've got teams that for five years on the India side are having to get up early or stay late and on the California side are getting up and staying late that's not sustainable we have to start thinking about how is it that we're going to maintain this process in a steady state for one year and two years and five years and ten years even though the product is going to look completely different and hopefully we will be evolving our processes along the way we have to start thinking in those time frames even though we have a completely different time frame for deliveries the process itself has to be able to run and be sustained the first thing I want to talk about is really this distinction between iterative and agile I hear a lot of people use those terms interchangeably and it's not the iteration that's the key part of what we are trying to talk about when we say frequent deliveries that's the heartbeat that's built into our feedback cycle but that's only one aspect of it we have all of these other principles and practices and approaches and realities and unfortunately what I often see when people say well of course we're agile we're using iterative software development they're just doing mini waterfalls and what they're ending up doing is at the end of every month they've got a death march and every one of us who's been in this business for any length of time has been on a death march and if those happen every nine months or maybe even three months over the course of two years we just can't sort of expect that to be able to think that year and year out every month you're going to be in a death march at the end of the month that's not sustainable that's demoralizing and that's why we need to move away from this notion that it's just about the iteration because there are also ways that you can turn those iterations into something other than a death march every single end of iteration and part of this is the balancing between the short and the long term and the critical for us to think about whether or not it is worth it for us to compromise the long term health for a short term goal and sometimes that's the right thing to do I remember one project that I was working on it was when the UK was going through the transition to the chip and pin and on a certain date if your stores couldn't use the chip and pin software the credit card fraud liability went from the credit card companies to the retailers now think about what that means from a financial perspective making some compromises for the long term to make sure that you don't all of a sudden have to accept all the credit card fraud that might happen in your chain that's a pretty big financial deal for an organization because that's legitimately an unbounded liability so it makes sense at times to compromise your long term but you want to do that understanding the risks that you're running and the costs that you are incurring and there are times when it is worth saying no I'm going to take a short term hit because the long term costs are too large to bear and so part of what the agile processes give us and in particular in this case it's our iteration planning meetings where we're actually sitting down and saying we need to talk about these two competing objectives and we need to balance these priorities on the basis of the short and long term costs and the short and long term benefits and make sure that the business decision makers have all of the information that they need to understand the risks that they're running and the costs that they are incurring sometimes the short term should win sometimes the long term should win as a team we are very often split on what matters more the developers are often accused of well I need to make sure my code base is clean so that it's maintainable and some would say that it's our obsession with the perfect code base some will say that the business is always far too focused on short term results the stereotypes are true to some extent but I think all of us at various times think this short term goal is worth going for this long term goal is worth paying a short term price for we need to make sure that that balance is made on the right information scope control limiting waste I was having a conversation with an individual and he said you've been talking about eliminating waste for all of these processes but to me the biggest source of waste is all of the extra stuff the business throws in and one of the things I realize and one of the value one critical piece of value that we get out of these agile processes is the fact that we are constantly asking the business what is the next most important thing that you need think about the behavior that a waterfall model inspires in a business person today what you want in 18 months time and then I'm never going to ask you again and then I'll give you something in 18 months well that business person has no idea what their environment is going to look like in 18 months and so they're going to be very creative of all the possible things that they might need in 18 months because you're not going to ask them again if you can convince them tell me what you need now and I promise you I will deliver that in a month and I will ask you what you need next now they no longer have to do these wild imaginings of what the world might look like in 18 months time they can focus on what they really need and that's a tremendous form of scope control because all of a sudden you're not building software you don't need you're not building software you have to rip out because your customers hate and you are building the things at the time that you need them and so this whole mechanism of saying I'm going to let you business person come back to the well every month or every three months and tell me what your priorities are now you get rid of all of those wild and crazy ideas that probably would never be useful but you end up wasting valuable development resources to build and then you've got more code to maintain and we all know that the defect rate is directly proportional to the lines of code so you've got more defects and every time you bring on a new developer it's more things to understand it's more compute cycles to build there's an enormous amount of waste and all of this functionality that we build that nobody really wants one of my favorite parts of this whole agile process is what I call the agile contract and it really defines the relationship between the stakeholder and the development team because it's the stakeholders right under this contract to say this is what I want and this is my priority order and this is overall what I want to spend and if possible I would like something on Tuesday but it's the development team's right to say this is how much each of those individual things are going to cost so if you want the most I can give you by Tuesday here's where I draw the line and if you want something below the line then you have to take something out so as the development team I am not allowed to tell the stakeholders what his priority is but similarly that stakeholder is not allowed to tell me how much work I'm going to have to do to get something done he understands his priorities and what's driving them and that's his responsibility to make those decisions it's our responsibility to as accurately as possible tell him what are these things going to cost and then those decisions can be made and when I say stakeholder I'm not just talking about the standard business user stakeholder I'm also thinking about people like the enterprise architect who also has things that they might want to have done I'm talking about the operations department which have these requirements for support and monitoring and what do I do when the database crash all of those processes they're stakeholders too and they should be participating in this process and the agile contract gives us the basis for that because the development team is best suited to say this is what it's going to take but the business is best suited to say this is the priority in which I want to do it and oh by the way this is how much I'm willing to pay so this whole thing results in a situation where we don't need heroes anymore we certainly don't need heroes constantly and that's really the situation we were in before we needed heroes all the time and that is not sustainable so the team through this whole notion of team empowerment is the people who select the processes they're the people who establish this discipline structure within which they work but because the team is empowered to do that the team is bought into it and that's part of what makes it sustainable it is not sustainable for people to day in, day out, month in, month out work under a structure that they don't think is right that they don't understand and that is imposed from outside now imposed from outside might be legitimate to understand and accept and realize why it's there but part of what makes this sustainable is that the team itself is establishing the discipline and because they've established the discipline they understand the rationale for it and it is sustainable for them to work under that discipline for extended periods of time third one grounded in reality again this is one of my favorites because I do so often sit there and think do you really believe what you're telling me the first aspect of this is our use of yesterday's weather in planning if you have a team that did X amount of jelly beans whatever your estimation method is and in this week they did five jelly beans and nothing's really changed in the environment nothing's really changed in the domain nothing's really changed in the team there's absolutely no justification whatsoever next week we're going to magically do 10 jelly beans yes there are aspects of team dynamics that will improve over time but you can't really estimate when that gelling moment is going to happen some people will say velocity is whatever it is and that's true in the short term you can't say things are going to get better next time so we're going to be able to double our productivity but what you can do over a longer term is to say well are there things that are impacting our velocity well the fact that our build server crashes three times a day the fact that we forgot to plan for the fact that there was a public holiday maybe the requirements we're getting into a new area where people don't understand the domain well enough so maybe we need to do something about that you have the ability to change some of these things long term but just saying things will magically get better and so we can double our productivity next time is silly the notion of what yesterday's weather says things will only get better if you do something to change it and so we need to focus on are there things that we can make better so that next next iteration maybe we can get 10 jelly beans because the build server isn't crashing every day anymore clarity of actual progress a lot of this has more to do with the relationship between the team and the business than within the team itself because if the business starts to believe that the team is producing something and we get this through the regular showcases then you start to get the right kinds of relationships and the right kind of conversations about the tradeoffs that have to be made a business is going to be more likely to accept that you really actually can't do something if they feel like you have been doing things in the past so the showcases provide a little chip on the side of the development team to show progress and rather than this sort of made up number I am now 83.5% done on this story you've got something concrete because you've got things that people see and that gives you clarity into actual progress rather than imaginary progress another part of being grounded in reality is adaptive planning things like evolutionary architecture and emergent design is all about you plan for the time horizon where it's sensible that you think you have enough understanding of the environment and then you just sort of put markers along the way past that so that you can adjust yourself as things change evolutionary architecture one of the major tenets of this is you wait until the last responsible moment to make a decision because that's when you have the most information and there are times when you have to make that decision a day one and there are times that maybe you can wait three months to make that decision and in that three month period of time you have a whole lot more information these three items to me are all about taking guesswork out of being a software developer when we're trying to make design decisions too early we are guessing what is the path of the requirements evolution going to take what are the changes that the business is going to want in a year that's guesswork the more we can set up our system to allow us to respond to actual needs quickly rather than having to guess at perceived needs and then recover when we get it wrong again we're taking waste out of the system I don't know about anybody else but I'm really lousy at predictions and I wouldn't want my day to day job depending on me guessing right all of the time and yet that's what a lot of these upfront design decisions are all about is guessing about which way the world is really going and this is really about adaptive everything you know we need to look at requirements the business is looking at how is the business landscape changing all of those things are changing and we have to have a system that is able to adapt to that and this one is a really important part in terms of being grounded in reality there's an extreme view that I'm an agile that I'm just an order taker I do what the business tells me to do and personally I see that as an abdication of professional responsibility if somebody tells me to do something that makes no sense it's my professional responsibility to say why it makes no sense and to say that I really don't think you want to do this now maybe they have a reason I don't understand and that can prompt a conversation let's say I'm an order taker I do everything the business tells me to do is an abdication of responsibility and I think that's something that we as a profession need to start thinking about we are not just order takers we are not just robots that crank out code so much about what we talk about in Agile is bringing the person back into this we are not robotic code generators we are individuals we are software professionals who are looking at these things and it is our responsibility to do more than simply blindly take orders from the business so all of these principles and practices these structures put together put us in a position to embrace and take advantage of the opportunities that the business sees because we are still in some ways the enablers of a business and the business is operating in a business environment and there might be opportunities out there that the business wants to take advantage of and that's going to require us to be able to respond by changing and adapting the systems to serve that new need and there might be threats out there competitive threats, regulatory threats vendor threats in terms of end of life well maybe we better get rid of that piece of software that has been out of support for five years and they are really this time dead serious about end of life and unfortunately there are still a lot of systems running out there with unsupported software we need to be in a position to both respond to threats and take advantage of opportunities or more precisely to enable our organizations to do that so let's go back to our two toy castles the knitted castle to me represents kind of the waterfall idea of software development you can sit there and you can design this beautiful elegant structure lovingly craft this but once you've finished it it's set in stone think about how difficult it would be to add a gate to the back of that knitted castle you have to unravel everything because everything is so closely aligned now there are some situations where that's actually required because you need that close level of cooperation to get performance requirements and such but you don't want to do that as a default because if you have to change anything in that knitted castle you have to rip it all apart the Lego castle is not as elegant it's not as beautiful but if you want to add a tower on the side of it you pull that part out the whole rest of the castle stays intact and you stick in your tower is it as meticulous? no is it as beautiful? some people would say no me knitting it you'd probably still like the Lego castle far better than the other but the point is the Lego castle gives you options that simply do not exist in the knitted castle and the vast majority of the organizations we deal with live in a world that changes so frequently that we need to be living in a Lego castle not a knitted castle because we don't have the options to say I know what the world is going to look like for the next five years and I can construct this glorious edifice that is absolutely fit for purpose for the next five years maybe some of you are lucky to work in that situation but I haven't seen many organizations yet that have that luxury so we need to think about things more from the perspective of how do I construct my team and my software system and how do I influence my organization to construct Lego castles rather than knitted castles thank you very much for your time does anybody have any questions I think we've got time for a few we had one down here hi Rebecca I think you're right it was a hard act to follow but it was a good presentation thank you I think going back to basics is important I was really interested in the metaphor of the knit and Lego living in San Francisco I think the knit castle would have survived earthquakes better than the Lego castle and I'm wondering what you might think about the difference between component versus future teams and component versus future orientation and requirements management you're right in terms of this particular metaphor I actually think when you apply it to systems the systems that are that closely coupled together you often get more fragility in those contact points but I do think that looking at the way features coexist with each other and trying to think being very deliberate about what your granularity strategy is is part of how you get away from that so whether that means a component versus a feature strategy to me it's more understanding what are the interaction points between these things and therefore what's the logical grouping I want to put around something to isolate changes as much as possible and make my intersection point flexible enough so that when the earthquake hits it won't all fall apart thanks for your wonderful presentation so the normal question in the agile world is that recognition of the individuals but we understand that in agile world it's a teamwork the standard question is that how you will recognize the best resource when we are working in a combined team approach I'm having trouble hearing but I think what you said is given the fact that we're talking really more about teamwork how do we recognize individual contributions as well okay that's actually a difficult question because it gets into both how work gets allocated within the team and most teams know if you've got a team here who really understands the guts of communication protocols you're going to put that person on those stories because that's where his skills are now you want to make sure he's paired up with somebody else but teams very often self-adapt to that a very interesting question in all of this is what are the HR implications for agile and there are lots of things from the perspective of how an organization should respond to teams like this that are still very open questions I still believe you will have differential levels of contribution and there's nothing wrong with that because we are all individuals and so there's nothing wrong with the hotshot getting more money than the average contributor on a team but what you also have to make sure is that the hotshot isn't getting exploited all the time and the hotshot is taking seriously his responsibility to in fact help the others understand that place that is his specialty because the more of that specialist knowledge can be spread across the team the stronger the team is as a whole and that requires the hotshot actually to basically give up his competitive differentiator in some ways and that can be difficult for people to do one of the conversations I had recently with the developer included that agile is about empowerment and I don't want anybody looking over my shoulder and telling me what to do so this is kind of comes to early feedback and involvement of the stakeholders and those kind of things so that was he felt pretty strongly about it said no agile empowers me to do whatever I want and I can give my work back for review after it is done till then I should be on my own so your thoughts on that are counter to the notion of of the continuous feedback culture if you've got somebody sitting off in a corner doing things and I'll let you see it when I'm ready to let you see it that breaks that continuous feedback and I think one of the important things that we often run into is you know there's nothing sacrosanct about any of these practices if we understand what the principles that underlie them and part of what all of this review is about is not just about making sure it's not just about the code but it's also about the early warning mechanism if you're in a team of 20 or 30 or 40 people how do you know what you're doing over in this corner isn't running completely counter to what everybody else is doing over on the other side and so to talk about it as looking over someone's shoulder that's really the wrong attitude it's more that the final product is the collection of all of those individual activities and all of those individual activities have to work together and if I don't have visibility into what you're doing I can't do my part in a way that cooperates and so that's the way I would respond to that that's okay alright thank you Rebecca that was awesome okay and I'll be around