 Hi, I think we're live, so I'm going to get started. Hi, Jim, how are you? It's a pleasure to have you with us. It's been great to have interacted with you all these years, and now I actually have you on a webinar with us and have all the folks in India watch you. For folks who are watching, I think Jim Shorz does not need an introduction. I'll do a quick one. Jim Shorz is the author of the Art of Agile Development book. He also created the series of webinars or screencasts called Let's Go Test Pro and JavaScript. I think it was put up on Kickstarter, and it received an overwhelming response. So congrats, Jim, on that. Jim also has been working with Diana Larson to create the Agile fluency model, which explains how organizations or teams move from one type of Agile to another type. And that's kind of really our topic for the day. So thanks again, Jim, for joining us. And I'll hand it over to you to get started. Thank you for having me. It's a pleasure to be here. What I want to talk about today is Agile fluency. But specifically, what I want to talk about is something I've noticed that's a little disturbing. And that is that Agile isn't working. I was in Norway last year. Speaking to a room of about 100 people. And I asked the people in that room, how many of you are on teams that are described with the word Agile in some way? When people talk about your teams, they say you're on an Agile team. Everybody in the room raised their hand. And then I asked them, how many of you are satisfied with how Agile is working for your team? How many of you feel like you're actually getting what you expected out of Agile, what the benefits of Agile you thought you would get? And two people raised their hands. Two people. Actually, one person and then another person sort of thought about it and raised their hands. That's 2%. And this is something that I've been noticing in my own work is that there are just a lot of teams out there that are not getting the benefit from Agile that they expected. So that's what this talk is about. This talk is about, why aren't teams getting what they expect out of Agile and what can you do about it? Now, Diana and Larson and I were talking about this problem several years ago as well as discussing how we could potentially teach Agile to people. And in the process of doing that over the course of several years of work, we created something that we're calling the Agile fluency model. It's a description of how teams grow over time in their understanding of Agile. Now, before I show you this model, I need to disclaim, as Diana always says, all models are wrong. So the model I'm about to show you is not 100% correct. All models are wrong, and this model is not 100% correct either. But some models are useful. And in sharing this model with colleagues and consultants and coaches and team members and managers and executives, we've shared it with a lot of people at this point because we created it three, four years ago. And what we hear over and over from the people that we share it with is that it does accurately reflect what they're seeing in their own teams. And what happened is after we developed it and shopped it around and shared it with people, we shared it with several people asking for their feedback. And one of those people was Martin Fowler. And he liked it so much that he asked us if we could publish it. So you can actually find a white paper about this model on Martin Fowler's website. The easiest way to get there, though, is to go to agilefluency.com. And that will redirect you to the white paper. So that model is what I want to talk to you about today. The model talks about fluent proficiency. So it has several levels of proficiencies, different things that people can do or achieve with agile. But what we're interested in talking about the most with this is fluent proficiency. And fluent proficiency is when you are not just proficient in some aspect of agile or really anything, but we're talking about agile, but not just proficient, but that you have unconscious competence with that aspect of agile. In other words, if your boss comes stomping into the room at 3 p.m. on a Friday and says, why isn't this software done yet? What do you do? Do you run back to your cubicles and say, everybody stop testing a code, just program and tell it's done because the boss is stressed out? Well, that is a different type of fluency than if you say, OK boss, I understand this is important, but the reason that we are doing this is because this is the most effective way for us to get it done. That's a different kind of fluency. So fluent proficiency is what we're looking at here. Let me show the model to you. I'm going to pull this up. Nuresh, is that coming through OK? Yes, I can see it fine. Thank you. OK, great. So this is the model that we talk about in the paper. And it's sort of the summary of the model. It's not the whole model, but it's a good way of describing it. As I was saying, this is about fluent proficiency. So you'll see here that there's multiple stars, multiple levels of proficiency. What we're looking at is fluency at any of these levels. And the trick here, the important thing to realize here is that fluency at any of these levels is a good thing, any of them at all. One star would sort of roughly corresponds to Scrum. It's about doing sprints and user stories and stuff like that. When teams are fluent at that level of proficiency, they see some real benefits. And teams also see benefits at the two-star level, the three-star level, and the four-star level. So it's not about getting to four-star. Four-star isn't necessarily appropriate for every organization. What it's about is deciding which level is right for your team and then not promising more than you can deliver. I think I said at the beginning that people are getting different results from Agile than they expected. Part of that is that they're being promised one thing, and then they're actually delivering something else. They've been promising one level proficiency and delivering another. So let me take a moment and walk through this model and describe how it works. And I believe Noresh has the ability to take questions. So if questions occurred, you please send them in, and then we'll talk about it after I've gone through the model. This model starts out with the assumption of fluency in building code. Maybe it's not perfect. Maybe it's not always delivered. Maybe it's not bug-free. But the assumption is that you're working on a team that has a fluent proficiency in building code. And then at some point, there's something that happens that makes the team say, we want to do Agile. Maybe it comes from within the team. Maybe it comes from management. But whatever that foreign element is, the team starts to do Agile. When that happens, the first thing that they're able to do, regardless of how they decide to approach Agile, what we tend to see is the first level of fluent proficiency they get to is this first star. And that generally takes a team culture shift. What we're looking at, again, as I said before, was this fluency at this first star means that you can show progress from a business perspective that your stakeholders can redirect your team as necessary. And this typically involves, again, user stories and sprints and retrospectives working as a team. Getting to this takes a team culture shift. And teams that get to this level of fluency, they are doing things that are really useful to their organizations. A lot of teams that have started doing Scrum, which is basically Scrum done well, is teams that are fluent with Scrum are fluent at this first star. Teams that have that fluency see some real benefits. There's more transparency to their organization. People are generally happier with the work. They have more control over the work as well. Some teams look for something more. But before I talk about that, I wanna talk about something kind of interesting that I've seen in the world of software. And this is something that sort of has confused me in the beginning and now I've come to accept. And that is that I work with a lot of teams that have huge business success but have really lousy code. I think many of us have seen this. You go to a company and you see that they're really successful as a company and then you look at your software and you say, oh my, what is going on here? What is wrong with this code? And this bothered me because my background is as a programmer, I take pride in creating good code or trying to create good code. And it was a real conundrum. It was a real puzzle for me that all these companies could be so successful with having really crappy code. And what it led me to realize, like it or not, business success is independent of technical success but something else I've noticed. A lot of the companies I work for because I do a lot of consulting on agile things, on agile processes and helping teams become agile. A lot of those companies hire me after they've gotten to the point where they can't make any more progress on their software. They've had a big business success. Many of the companies I work with were startups and now are larger IPOed companies. So they're more still entrepreneurial but they're big enough and been successful enough that they've been around for a while. After about five, seven, maybe nine years with their product, they're finding something that is really uncomfortable for them and that is they're finding that they can't make any more progress on it. People are complaining about technical debt. The simplest seeming things take forever to deliver and their programmers come up to them and say, we can't work with this, we need a total rewrite. And so they decide to do a total rewrite but that is a terrible thing to do if you're a software company. If you decide to do a rewrite of your software, what that means is that the software you have now is the only software you're gonna have for the next several years where you stop everything and rewrite. Meanwhile, your competitors are catching up and exceeding you. Your customers are seeing nothing new coming along. A lot of these companies have maintenance support agreements where the customers are paying the money for regular updates and they're not delivering updates. Rewrites are a really bad idea as a company but the technical debt on their software is so bad they have no choice. So what I've learned is that although business success is what will make a company successful and technology has really very little to do with that, technology success or rather lack of technology success can be really devastating several years down the line when it causes you basically stop all your business to rewrite. Now there's a third component to this which is personal success. I'm not gonna talk about this a lot right now. Basically you need the people, your stakeholders and team members and everybody involved in the project to feel a sense of personal success. Otherwise they're not gonna give it their all and you can even see sabotaging behavior in the worst case. So all three of these things, business success, technology success and personal success, these are really what's necessary for long term success as a company. So in the short term good business makes the company and the long term bad technology will break the company and people glue the company together. So what does this have to do with agile fluency? Well, one star teams, these teams that are doing sprints and retrospectives and have the ability to change direction and see progress from a business perspective, they're not actually fluent at delivering value sustainably and that's where two star teams come in. Some teams, not all, over time grow to the point where they're fluent at this second star and teams that are fluent here, they have the ability to ship on market cadence, they capture value frequently, they reveal obstructions early. You can tell if your team is fluent at this level. If they're able to deliver on the market cadence and by deliver on the market cadence, what I mean is you ship software to market as often as your market wants to see it. For a web based company or software, that might mean you're shipping multiple times per day because people can't tell. Excuse me. For a more traditional company, it might be less often. I worked for a company that delivered software to the drug industry because that industry is regulated by the FDA. They couldn't take software more than once per year because it was too expensive to take revisions other than that. So their company's market cadence or their market's cadence was once per year. Yours will depend on the specifics of your market. But whatever your market cadence is, if you're delivering reliable, reasonably bug-free software on that cadence as frequently as the market wants it, then you may be fluent at this second star. And if you're not, then you're not yet fluent. Getting to this second star of fluency takes a shift in team skills. This is where we bring in a lot of the agile engineering practices. This is test-driven development and refactoring and evolutionary design and stuff like that. I wanna note here, we're showing this, we create this model as a path. That doesn't mean that you work on getting to fluency at one star and then you work on fluency at two star and then you work at fluency at three star. That's not how it works. And I'll go into this more in a little bit. But the idea of this model is twofold. First, we wanted to describe what we were seeing in the real world. And second, we wanted to show you how you could use this to influence your teams and to talk about how agile works with your company, with your managers, and with your teams. So what this model shows by showing a path from one star to two star to three star, we're not saying do one star and then do two star. Actually, what you should be doing is deciding what level you want a fluent proficiency you want and just going for that from the beginning. And then your team will develop fluency roughly in the way we're describing. First, they'll become fluent at the one star level, then they will become fluent at the two star level, then they will become fluent at the three star level if you're going that far. Speaking of three star, some teams, not all, aim for fluency at this third star, which we've called optimized value. You can tell teams that are fluent at this third star of proficiency because they're making really good product decisions. Optimized value, this third star of fluency is about making the best decisions possible, giving the resources available. That doesn't mean you're making perfect decisions all the time, it means that you're making the best decisions you can given the information you have and you're using your time and resources wisely to learn what those best decisions are. This level of fluency is much more rare than the first two. When I talked in front of live audiences and I asked them to raise their hand and tell me self rate themselves at which level of fluency they think their teams are at, about 40%, maybe half the rooms, people in the room will say that their teams are fluent at one star. Maybe 30% will say that they're fluent at two star and only about 5% say they're fluent at three star. And I think that's interesting because when people talk about what Agile can bring you, they're talking about three star Agile and I think that comes back to the question I posed at the beginning which is what's going on? Why are people unhappy with what they're getting out of Agile? Three star Agile is rare because it takes an organizational structure shift. It requires, what we're talking about here is expertise in making product decisions and what that needs is full time expertise on the team. And in the beginning I would say, well what you need is a product manager on the team full time. You need customer, onsite customers who are really responsible for this on the team and that's true but in many organizations that expertise is actually not available in the organization so you have to develop it within the team. That disrupts existing organizational hierarchy. That disrupts decision making structure. This makes three star Agile a lot harder to achieve not because it's technically difficult like refactoring and test-driven development but because it requires a certain level of trust from the organization. So that's part of it. You need people on the team who have real expertise in the problem domain, in the product that you're creating. But you also need something else. You need adaptive planning and that can be really hard for organizations. Let me describe this. Imagine that you are at the beginning of a project and you have this huge unknown future ahead of you. That's this gray triangle. For most people that huge unknown future is very profoundly discomforting. It is uncomfortable to look at that and say we don't know what's gonna happen. So they create a plan. They create a bright red line that says this is what we're gonna do and no matter what we are gonna do it. And then the work start happening and you see that all these opportunities open up but you're gonna follow that plan so you do. And the result is that you don't learn from new information as you go and you miss out on getting the most value possible out of your product. Now, depending on how much expertise you have involved you might get good value but you're still not gonna get the most value. You're always gonna learn new things as the work continues. So a team that's fluent at this third star of Agile Proficiency, they start out with this. They say we don't know what's gonna happen. We're going to adapt our plans as we go. And as we see opportunities arise we're gonna explore them. We're gonna try them out. Some of them will work out. Some of them we won't. We'll take some false starts, revise our plans as we go and that's how we're gonna get as close as we can to the maximum value. This can be really difficult for companies but that kind of adaptive planning, the kinds of things that you see in the lean startup movement for example and what you would see in Jim Highsmith's book about adaptive planning. That kind of adaptive planning is really important if you're gonna be fluent at this third star. There is one more star that we've put out there as sort of an aspirational goal. And none of the groups that we've talked to have said that they're yet fluent at this fourth star. I do know of some teams that are fluent at four star agile but they're very small and as those companies grow they actually tend to lose that fluency. At this fourth star what we have is an organization that optimized the entire system. Rather than just having a team optimizing the value of the product we have multiple teams who are collaborating and cooperating as peer decision makers to optimize the value they produce for the organization and to set the direction for the organization. This is very different than your traditional top-down structures. It requires an organizational culture shift and we've put it out there is because we think this is some place where agile may go in the future but it's probably not appropriate for most teams now. So that's the overall model. Again this reflects, this is based on what we were seeing in the real world of how teams grew in their understanding and their fluent proficiency with agile over time. You can use this to help your company understand what the possibilities are and that's what I wanna talk about next. In this model the one star team represents agile fundamentals. The two star team represents sustainability. A team that's just operating at the one star level will have to do a rewrite after several years. A team that's operating at this two star level can continue that indefinitely. The three star team represents agile's promise. This is the changing direction to meet the needs of the market that people always talk about when they talk about agile. And four star I think is agile's future. So let's go back to the question I asked at the beginning. Why aren't teams getting great results from agile? Well I actually think they are getting great results. A team that's fluent at one star is getting good results from that. They're getting the ability to be transparent to their business to change direction and they're often getting a sense of renewed control over their work. But they're being promised. When people talk about agile they say you're gonna get what we're calling three star agile. You're gonna be able to change direction according to the needs of the market. They're promising three star, they're delivering one star. And that difference is disappointing. So how can you help? How can you prevent this disappointment with agile in your own teams? How can you get the most value out of agile? Well I think this model is something that you could use. Here's how it works. First, the trick is really about, I said before that teams were promising one thing and delivering the other. So ultimately the trick here is to figure out what level of fluent proficiency your team needs and deliver that. Promise it and deliver that. And each level of fluency takes a certain amount of investment. So figure out what investment you can actually reasonably put forth and don't promise more than what you can achieve with that investment. And here's some tricks. Go ahead and take screenshots of this as you can because this isn't part of the agile fluency paper we have online. This is actually, other than this talk and a few other talks I've given that this information isn't in printed form anywhere. So to use this model to help create that understanding of what you can do with agile and to create a really good value from agile, start out by considering the benefits. Do you want greater visibility into your team's work or an ability to redirect? Do you want low defects in productivity, high value deliveries? Choose one of these benefits. And of course, when I put this in front of managers and executives, what I hear is, well, we want four star. But in addition to the benefits, you also have to consider what the investment is. One star takes an investment of team development and work process design. Two star takes that plus investment in developing your team's skills and being patient with lowered productivity while the team learns. Three star involves expending some social capital and incorporating business expertise in the team. And four star involves significant effort in establishing an organizational culture, which is probably not appropriate for most companies. So based on those benefits and that investment, choose your target. Here's what we find is most common. For a throwaway system, one star is sufficient, but usually not enough because it's not sustainable if you're planning on developing long term. If you're in a large or bureaucratic organization, two star may be the most you can do because the organizational structure shift required for three star is too much. If you're in a small or entrepreneurial organization that really wants the benefits of three stars and can handle the investment, then three star is a good fit. And four star, I would say, is really only appropriate for companies that are looking to have a culture of extreme innovation. And then practice. The first two stars are covered really well in the literature. One star, all the material you'll need for one star is in the Scrum or Kanbanu literature. Two star is really well covered in the XP in software craftsmanship literature. If you're going for three star, you'll need one star plus two star plus you'll have to start inventing some stuff. You can look at the Lean software movement, you can look at Lean startup, they'll have some ideas. And then for four star, you really have to invent. There's some companies that are doing stuff sort of at the four star level that you can look at. Valve, for example, Semco, GitHub at one point was at that level, although I don't know if they are now. And then keep practicing. As I said before, teams tend to grow in their fluent proficiency over time. We see that it takes a couple of months, two to six months, depending on how much help and how much focus they have to get fluent at one star level. Three to 24 months to be fluent at the two star and multiple years to be fluent at the three star. Not so much because it's difficult, but because it really takes that organizational structure shift. So that is a brief introduction to the fluency model. Again, I think that Agile has been disappointing for a lot of teams because they're promising one thing and delivering another. You can get great results from Agile. You just need to pick the appropriate level of fluency for your organization, understand the investment needed to get there, and then talk about it from that perspective. Please use this model in your own work. We have licensed it freely for people to use. And in the work I've done with managers and executives, they've really liked it. It really rings true to them, and they found it useful to think about how to invest in Agile. So please take this and use it. And with that, I'm going to turn this back over to Nuresh to do the Q and A. So thank you for listening. All right, thanks, Jim. This was very insightful. Love your Agile fluency model. I think I read about it a few years ago when it was published, I think in 2012, a couple of years ago. I really like how you've described moving basically from the fluency at building code, starting at focusing on that, then focusing on value next, getting to deliver the real value, adjusting it to market cadence, things like that. And then really focusing on optimizing value, which is more of making the right product decisions and having the whole culture where teams are focusing on what really matters, and then eventually moving to optimizing for systems, where again you kind of highlighted if you're building these kind of systems, maybe this level of proficiency is enough, and when you're kind of doing this kind of, or this is the kind of nature of your organization, then you might want to aim for this. I think that's very insightful, and I'm hoping that a lot of people will have good takeaways back from this at their work. So thank you for that, Jim. Thank you. All right, in terms of questions, I'm waiting for people to ask questions. I have a few questions as you were talking through, so I'm gonna get started. So I think when you started off, you hit the nail on the head by talking about that technical success is one thing, but business success is another thing. And I mean, at least in my opinion, the agile community, more specifically the extreme programming community had focused a lot on the technical success. And the whole idea was that if you're gonna have technical debt, then in a few years' time, your system will not be able to cope up with the needs of the market. And you trust upon that, right? The interesting thing for me is, and I hit this a few years ago when I started building my own products, is as a startup founder or as a entrepreneur, one of the things that you really struggle with is this whole dilemma of what is good enough? What is good enough in terms of the technical success? Because I think it's a range or it's a spectrum, and it's not, I have technical success or not, it's a whole spectrum, depending on the nature of the product and things like that. The big dilemma is that a lot of times you don't know if the business is gonna succeed and you wanna know how much you wanna invest in it, both in terms of technology and also in terms of people, right? I could hire really rock star programmers or rock star team members, but that's gonna cost and that's gonna take time because it's not gonna happen very easily. And I could be waiting on that while missing the market opportunity or I need to first validate whether the market opportunity even exists even if I have to write crappy code and put it out there to really validate certain things. So I guess it's not really a question, I'm more kind of getting into a dialogue where this is a dilemma that I always run into and what would be really your advice to someone in that state of where do they draw the line? How much technical success is good enough? I think that's a really interesting question and I actually think that sort of decision making is a hallmark of the three star team because what you're doing, a two star team is one that's capable of delivering software that is gonna be really solid long term. A three star team is able to take those sorts of decisions and trade it off against market realities and market opportunities. And so I wouldn't necessarily expect a fluent two star team to understand that and you mentioned XP and I think that's a good example. XP is the quintessential two star method. It is a fantastic way of creating sustainable software delivering reliably on the market cadence. But all it has to say about product is really just, you need to have somebody on the team that knows that stuff and that's pretty much as far as it goes. So, but let me get into some of the things you mentioned about the trade off of technical debt. There's debts as an instrument for people, especially savvy business people, you take on debt to have the ability to do more than you otherwise could. So can you take on technical debt in the same way? I think that's an interesting question. I've certainly observed from doing my JavaScript screencast, my Let's Code JavaScript screencast, that it takes, especially for those things that haven't been done before that we're trying to touch on in the screencast, it can take a lot of work to figure out how to test something for the first time. In the screencast, we're doing testing of touch events. So in the iOS, when you touch the screen and draw stuff, we're testing that. That wasn't easy, that took some time to figure out. So is it worth that kind of investment in your company when you're not even sure that this product you have is even a good idea? This is particularly true for startups or for new products. My, I think a really savvy team is going to conduct market experiments that don't require a lot of code. And actually the screencast is a good example of that. I conducted market experiments in terms of doing tweets and blog entries, asking people if they would be interested in a screencast and by doing the Kickstarter, none of which required me to actually build the Let's Code site. And it wasn't until after the Kickstarter was done and I was already delivering videos that I actually built a really professional looking site that could take people's money. So I think part of the trick is not to build software at all. The other thing though, as I've certainly seen this, long time ago, I worked on a product called card meeting. It was sort of a predecessor to Trello and these other card based planning boards. And the reason you don't know about card meeting, you know about these other two is because card meeting was a failure. I had some boundary difficulties. But one of the things we tried to do is we tried to just take on technical debt in order to get a product out the door. And we did, we got a product out the door for Agile 2006 or something like that. I don't remember exactly when it was, maybe it was 2008. And we said, here's a demo, you can use this. But then our technical debt was so bad, we just came to a complete halt, stalled out and because of founder problems, I had disagreements with my co-founder, that was it. And I would say technical debt was definitely a factor in that. So for me, from that experience, I won't take on technical debt for anything that's meant to live. I'll conduct experiments that I plan to throw away, but I'm not going to, but anything that I know is going to continue, if it's successful, is gonna continue to live, I'm not gonna take on technical debt for that because the cost is too high. Once a product's out the door, you're spending a lot of time on marketing and support and handling customers. You have even less time then than you did at the beginning. And you can't afford to pay down technical debt at that point. So I've been talking a lot, I'll let you get a word in edge-wise, but that's sort of my perspective on it. Technical debt is only okay if you're gonna throw away the product, it's too expensive otherwise. So once I had this discussion with Michael Feathers and we were talking about what if code disappeared every six months? What if that's how you build stuff and code automatically disappeared every six months? How would that change your behavior or perspective of how you would build software? And I thought that was very interesting because at that point I was working for a company where every six months or so, the technology stack that they use actually goes through a massive change. And if you're still stuck to the old technology stack, you're basically taking on a huge business hit in terms of the server infrastructure particularly. The amount of users you can support on one particular server or stuff like that. So for them, throwing away stuff every six months was just the natural way that they ran business and they were very successful doing that. So they just wrote shitloads of crappy code and then they pushed the button. It would run for a few months and then they would be looking at the next thing that they need to do in terms of, from a technology stack point of view. And they would actually parallelly start building something else and in six months time they would roll that out and put the new thing in. I went in there with the background where I believe that that was a really bad idea. You need to, I came from a lot of XP backgrounds. I was very hung up on some of those things. And it just didn't feel right. It just felt like these guys don't know what they're doing. But yet, they were extremely successful doing that. So I feel again these are really debatable topics and it's very contextual. Well I think that's really interesting that you bring that up because we were talking about the Agile Fluency Model, right? The whole point of the Agile Fluency Model is that any level of fluency is right. Choose the one that works for your organization. So for that organization, one-star fluency would have been a great fit because they didn't need sustainability. Now, I mean, you know that company. My experience has been that technical debt becomes more costly than no technical debt. Or I shouldn't say that. I should say test-driven development is more costly than no test-driven development for the first six to eight weeks. And then after that it's actually faster because you've got enough code that having the test to support you is more effective. So for if the cycle was six months and also given a lot of the cost of getting started with test-driven development is the learning that happens, not the actual the code that's written. I might have looked at doing test-driven development anyway but I think it's a really good example of a case where one-star Agile is the right, is potentially the right answer because you don't need that sustainability. And I think that's a great example. The interesting thing about them was they used to do a lot of what I came to know about as a set-based development. So they wanted to build a chat server and they basically spun three teams of three people and they would basically let three teams go off for a month and basically build a server infrastructure. And then there would be literally a competition between the teams to support the maximum number of users. Basically the ROI per user is what they were trying to optimize. And whoever showed the results would basically get the credit and that their code would basically, their product would go out of the door. This is where again some of the things that the lean startup tries to do in the sense of doing parallel experiments or trying to do some of the safe fail experiments where it's okay to fail and you set up that way purely from a learning perspective is important. So I think some of those things while at gel level one fluency was good enough or one star fluency was good enough for them, they were also doing some of the stuff that's kind of belonged in the four star fluency that you were talking about in an interesting way. Yeah that is a really interesting example. I'd like to hear more about that company sometime. It's pretty unusual to have that type of environment. And you know how I said every model is wrong? Well for a company that's actually throwing away its software every six months but still being really entrepreneurial that for them they could probably skip the two star stuff which I've never actually seen before and still be really successful. So that's a really interesting example. It's funny because the founder basically got me in to help them with two star fluency how you've described it, right? Set up a QA team, how teams do test-driven development, pair programming, basically focus on thin slices, get stuff every week out of the door, things like that. And while I was there I constantly struggled with is this even the right thing for them because what they're doing seems so much more better in some sense, they obviously can pick up some of these practices and it will benefit but they seem to have jumped the gun somehow and gone to the next level which is interesting and I'd never seen that. So I struggled for almost six months trying to debate in my head, you know, what I had learned as the best practice if you will actually basically discarding it and saying, well, what I've learned is not enough. I need to go back to the basics. All right, I think we have a few questions I need to make sure that we also cover those questions. So let's see, we have Lakshmi Kanth here asking a question saying somehow I felt two star and three star are part of Scrum framework but you said that in your experience Scrum really is at one star level. Can you please confirm my understanding? Yeah, absolutely. I didn't mean to say that Scrum was one star. The Scrum is a method. It's a set of guidance but Scrum itself, none of the methods I described are actually at any of those stars because the star levels are for teams that are fluent at a particular proficiency level. So you might say that a team is one star if they're able to provide a lot of visibility into their development and they can change direction and they're working as a team and reflecting and adapting and so forth. A team that can do that even under pressure is fluent at the one star level. If you wanna learn those sorts of things the Scrum materials have a lot for you on that. The Scrum materials don't have so much about test-driven development. Scrum really tries to be a broader method that doesn't talk about the specific technical practices. So starting from Scrum, you might be pointed to test-driven development or these other practices but you won't find as much of that in the Scrum literature as you will in the software craftsmanship movement or that you'll find in the XP movement. Similarly, there's not as much in the Scrum literature or the XP literature about how to do really good product management. Scrum says you need a product manager but doesn't really say a lot about what that person should do. XP says you need an on-site customer or customer team but again doesn't say a lot about what that person should do. The Lean startup movement though talks a lot about conducting experiments and the cycle that they have of trying an experiment, collecting data, revising your plans based on that data. Similarly, the Lean software stuff talks more about the product level and the overall system than the other literature does. So it's not so much that a Scrum team can't be fluent at two star and three star. It's that if you're learning, if you wanna be three star, then there are multiple sources of information that you're gonna wanna pull from. All right, thanks, Jim. I'll move quickly to the next question which is kind of almost correlated. Maybe just you can clarify quickly if the understanding of William, Will's panel is right. He's asking just because you're doing daily stand-ups, stories which adhere to invest principles, doing demos every two weeks and you're calling it Scrum, does it really mean you're at fluency level one, you're practicing fluency level one? I think that's a really interesting question. It comes back to what is fluency and that's the unconscious competence. And the easiest way to tell is if you're fluent at a particular level and we actually have some tests that we mentioned in the white paper that you can look at, some key indicators. But fluency is the way you work when you're under pressure. So although you might be doing sprints and stories and all that stuff, a normal work, when you're at your best, if an emergency comes along and everybody throws up their hands and runs back to their cubicle and starts working independently without doing any of that good teamwork stuff, then you're probably not yet fluent. And the key indicator for the one star is really about that ability to talk about what you're doing from a business perspective and to be able to redirect as the business needs. And I guess also the focus is on basically the team culture shifting to being more of a collaborative culture. So you could be doing daily stand-ups and you could be doing all the other jazz, but your team culture has not actually changed. People still are individually measured, people are still very, that heroism culture still exists. And that's another indicator in my opinion that you're not really at fluency level. Probably not, yeah. What we try to do with the model, and again, look at the white paper for the details on this, we try to make it pretty independent of which methods you are using. So it would be theoretically possible. So the key indicator for fluency at the first star is that ability to speak to the business in business terms. That's what distinguishes it from just fluency at coding is that now you're talking in business terms. So just hypothetically, a team that everybody works independently and is all siloed that was still able to speak in business terms and redirect as the business needed. You could say that they're fluent at that level, but I'll bet you they wouldn't be able to keep it up because as people change roles, it's just not sustainable. So Scrum, the Scrum materials are probably a better way of getting to fluency at that one star, but we don't actually care if you're using Scrum or if you're using something else as long as you're hitting that key indicator of working from a business perspective. The same goes for two star and three star as well. It's not so much that you're using XP or test-driven development at two star level. It's that you are consistently delivering bug-free software on the market cadence. And XP, Agile Engineering Practices are the best way I know of doing that, but if you've got another way of doing it, more power to you, that's fine too. Oh, thank you. In your paper, you also talk about deliberate practice. Can you touch upon a little bit on what is your take on deliberate? What is your definition of deliberate practice and what do you recommend teams? How do they do deliberate practice? Yeah, that's a good point. Thanks for bringing that up. I sort of glossed over this at the end of the presentation. What we see, and I think this is really important, you know, when you're using this model, take it to your managers or your executives, talk to them about what Agile can get you and what the benefits and investments are. And when your team, when your management and your team collectively decide what level of fluency that you're going for, say it's two star, three star, whatever it is, maybe it's one star, whatever that level is, practice everything needed to get there from the beginning. And it will take, and what you'll see is that you'll grow in fluency over time. So if you're aiming for three star, which is sort of what people promise with Agile, then you'll see fluency at one star before you see fluency at two star, before you see fluency at three star, in most cases. And that's just because the practices for two star are more challenging than the practices for one star. And the organizational changes that are required for three star are more disruptive than learning the practices for two star, so it will tend to grow. But do it all, all the time, and you'll see it grow. So the deliberate practice is decide where to go and then learn what you need to learn about what it takes to get there and then just practice it, practice it, practice all of it, all together. Cool, and I think when you talk about deliberate practice, it's about very specifically focusing on a particular thing at a time and really, really trying to master it. It's not just any practice, but it's very deliberate practice with specific kind of measurements around it in terms of what level you've hit or whether you've reached your desired level. I'm not suggesting like metrics, but something where it can indicate whether you hit the level of mastery or you need to focus more on this particular practice before you start focusing on other practices. That's actually, I wouldn't agree with that in this case. I think it's because with Agile, all these different practices reinforce each other in such different ways. I actually think it's more important to try to put them all in together than to do them one at a time. For example, it's really hard to do refactoring without test-driven development and pair programming makes that a lot easier as well. Similarly, it's hard to do stand-up meetings just to take a simple example if you don't have people in a team room because it's harder to get them together. That's a really simple case. So what I like to see teams do, and I actually talk about this in my book, The Art of Agile Development. What I like to see teams do is choose some book to follow. Mine's a fine choice if I do say so myself, but whatever book you choose, choose a book to follow and do it by the book. So that's where the deliberate practice comes in. There's things in Agile that people look at and say, I don't wanna do that. That's not a good idea. I'm gonna do everything except that. This pair programming thing, world's worst idea. I'm never gonna do that. Well, don't do that. If you decide to go for two star and you decide that Scrum and XP together are the way to get you there, then find a book that talks about those things or find a couple of books and do it all by the book for a little while, for quite a while, several months. And then after three months, then decide about what you're gonna take out or change and then do it for another three months. And then after six months, then you probably have enough experience to decide for yourself what the right things are. But don't just assume you know before you even try it. So that's my take on it. That's how I've always taught it and it's been very successful. I think we'll continue to disagree. I remember having this conversation with you in 2007 when we talked about, I was talking about basically using theory of constraints try and find the bottleneck and then use just-in-time practice to address that particular bottleneck and constantly be aware of what your bottleneck is and what just-in-time practice would suffice that. And I'm not sure if that's the only way to do it, but that model seems to work better for my style of working and I'm assuming your experience is with the model that you have worked with. But I think there are different models that exist. You know, a lot of people, I actually have an essay online, if you search for Kaizen and Kaikaku, you'll find, and I don't know if anybody's gonna be able to spell that. It's K-A-I-Z-E-N and K-A-I-K-A-K-U, Kaizen and Kaikaku. That's basically sort of a fundamental, two different fundamental ways of adopting agile that people talk about in the agile community. The do one thing and then find out what's not working and then do the next thing and then do the next thing. That's Kaizen, a continual improvement. Versus Kaikaku, which is a form of Kaizen, which is a Japanese term meaning change, which is a dramatic or sudden change. That's when a sensei comes in and restructures your lean manufacturing for. I do think Kaizen can work. I've seen it work. And I've seen Kaikaku work faster and with less pain because the human, and this is the disagreement I think we had, Nuresh, so I respect that you have seen it differently. What I have seen is that the human effect of constantly changing your environment is really draining and it's not really sustainable for a couple of years. Whereas the Kaikaku approach, big bang, really disruptive, really painful, takes a lot of emotional and political change. It's a little juice to do it, but you'll be done in six months. So that's the trade-off. I choose Kaikaku, but I also choose not to work with the companies that can't do that. So that's my choice. Right, cool. Let's take a couple of more questions. So we have Pramod here who's asking, is there a journey the teams go from one star to three star and how do you know when they have hit the ceiling in terms of their current level? Well, I think this actually ties into what we just were talking about. So for me, I would say if you're going for three star, do all the three star practices from the beginning. And what you'll see is you'll see them grow on fluency. And again, you can find some metrics in the white paper for how you'll know they've gotten there. But one star, they're gonna be reporting their progress from a business perspective rather than technical perspective. Two star, they're gonna be delivering bug-free software on a regular cadence and not struggling to get iterations done. Three star, you're gonna see them really focus on what the business metrics are and how they're meeting them. And doing that without having to get a lot of pushback from the rest of the organization. So again, I would start doing all those three star practices right away as much as you can and you'll see fluency grow rather than saying, are we at one star? Okay, now it's time to do two star. And then waiting to be fluent at two star before doing three star. Do it all and watch it grow. Do it destructively. I wouldn't say destructively. But I mean destructively, the Kaikaku model. Oh, right, right, yeah. And also this, you know, when I use this model, I use it to talk to management about what the investment should be. So if I talk to a company about doing and they say they wanna do three star, then I say, well, you know, you're looking at a serious investment. Not only are you talking about a team culture shift, you're also looking at things slowing down while the team learns, and you're also gonna need to make some investments in team's business expertise and giving the team permission to make those decisions. And getting to full three star fluency is gonna take several years. You're gonna see benefits within about three to six months, but getting to fluency is gonna take several years. Are you really willing to make that investment? That's a good conversation to have. And if the answer is no, we're not ready to make that investment right now, let's just do one star, or let's just do two star, then that's great. You can change your mind to go for three star later. But don't say we're going through three star if you're not. You know, choose the direction that's right for you now. You'll really decrease that disappointment that people have about being promised one thing from Agile, but getting something else. Absolutely, I think it's very important to have that conversation in terms of the investment that needs to be made, that expectation setting, because I'm afraid that a lot of Agile coaches out there don't really set that expectation. They seem to say, well, yeah, we will get you to three level proficiency or five level proficiency, but they don't really have an explicit dialogue about what it would take in terms of investment and what are the expectations that you need to have in the organization to get to that level. It's not gonna be, you know, we just slip in and we start working and then two days later we reach that level of fluency. There's a whole bunch of investment that needs to happen and it needs to be a conscious investment. It's not just gonna happen automatically, you know, and I think a lot of people fail to set that expectations up front, and which is where, again, it goes back to what you were saying earlier is the disappointment that you promised us all of this stuff, but we didn't know what we were signing up for. Absolutely, and Diane and I have both used this model with a lot of companies now, and it really works well. And again, this is, we've licensed this, it's copyrighted by us, but you guys can use it. We've got a full PDF, you know, high quality download that you can use and take with you and use it in your own slides and talking to your own management. It really works well talking to management. They, having this framework and understanding of investments and trade-offs, managers just eat it up, they love it. So yeah, have that conversation because it really does work well. And I wanna re-emphasize that there are four different levels of proficiency described within this model, but they're all good. Choose the right one. Don't just go for number four because it's got the, you know, because it's the highest on the list. Four is actually inappropriate for almost everybody, and three is inappropriate for a lot of people. So look at it carefully and think, you know, like Nuresh was talking about earlier with his group that was throwing away their software all the time, one star or one and three star without two, which is really weird. Those, that together was the right thing for them. So look at it from that perspective as you use it. Don't just automatically assume you need the highest numbers. I think they were doing it, you know, not really knowing what they were doing and your model kind of gives a framework for them to at least be aware what they're doing. So I think that's a very great contribution. Because people a lot of times end up doing something which is working, but not necessarily understanding why or knowing the underpinnings of it. So at least in some sense your model kind of helps people understand that what are these different levels? What is applicable when? And you might have skipped this, but that's okay because in your given context, this is not as important. Yeah, and I think that's why it works so well when we take it to managers because it gives them a sense of clarity as opposed to sort of this fuzzy what is agile, here's the agile manifesto. It gives them a lot more clarity about what they're gonna get and what they're expected to invest. You know, a savvy manager is gonna hear, oh, it's a two-day training course and we're gonna do all these amazing things. They're gonna look at that and say, yeah, right. So knowing that there's real investment involved actually is a bit safer for them because they know it's not just snake oil. Well, I think we're just running out of time. So I'll throw one last question at you. What is your take on certifications? You know my answer to this one, Nirash. You're just throwing a snake into the pit here, aren't you? So yeah, I think it is really useful for a company to know that the people they're hiring are good at what they do. Unfortunately, I don't think certifications give them that information, which is unfortunate. But it's really, really important when you're hiring somebody to know that they're competent and the best way that I know of to know if somebody's competent when you interview them is have them do work sample work. In other words, ask them to do the type of work that they're actually gonna do in your company and have somebody who's competent in that kind of work evaluate how they did it. So I don't think care programming is one way of doing it. But it's not the only way. Yeah, I don't think we've figured out what it takes to get the right person on team because it's certainly a lot more than a certificate they carry or what institute they went to or any of that stuff. I think a lot has to do with how they fit into the team and whether the aspirations are aligned. There's so much stuff that is, I think, a lot more important than the knowledge that they have. So I think the Agile Alliance had this article about the certification models out there probably can test the knowledge level but not really the skill level and there's actually a lot more than that to know if this is the right person on your team. Absolutely. And even if you're just looking at knowledge, a certificate isn't gonna give you nearly as much information as work sample. Having the person actually do the work that they're going to be doing because the work of your organization is subtly different than what they got from the certification. And certifications, even the ones that actually involve tests, which they don't all involve, as you well know, the tests are often knowledge-based, not judgment-based. So, and good software development is about exercising judgment. So if I were to interview somebody to work with me, and on my work, I'd be very interested in how they do refactoring and do continuous and reflective design. I have no idea how you test that but it's certainly something I can evaluate in person by showing them my actual work and asking them to critique it or the actual design and asking them to critique it. So work samples, that's the key. I would take that over certifications any day of the week. Cool. There's one quick question here and we'll wrap up. Where is the PDF that you've been talking about? Is that a URL? Is that on agilefluency.com? Yeah, if you go to agilefluency.com you will get redirected to the white paper which is on Martin Fowler's site. If you scroll down, you'll see the image I've been using in the slides. There should be a link to a PDF next to that image. All right, okay. All right, Jim, I think we have overshadowed time but it was wonderful catching up with you and thanks again for joining us. It's been a real pleasure meeting you again on Google Hangout. I think the first time I met you was in Philadelphia when we used to run the agilefully group and you were kind enough to come and do a talk for us back then. And I think you also did a tour in India where you spoke at different cities in India. So we are hoping that sometime in the near future we will be able to do a similar tour with you in India. I would love to do that and thank you for having me. It's been a real pleasure and a lot of fun catching up with you. So thanks again. Thanks, Jim. Have a good one. Bye-bye. Thanks everyone and we will see you next week at the conference.