At the recent Agile Australia Conference James Shore gave a keynote talk and a workshop on Agile fluency. He spoke to InfoQ about his work on agile fluency, teaching and building tools for test driven development in javascript.
InfoQ: James, welcome. Thank you for taking the time to talk to us today. Would you mind introducing yourself very briefly to our audience?
James: Thank you for having me. I am James Shore. I have been working in the Agile community leading Agile projects since 1999. I started out with Feature Driven Development in 1999, I migrated to eXtreme Programming in 2000 and I saw great success with it, I loved it. At that time nobody was doing eXtreme Programming and I loved it so much that I was not really willing to do anything else after that. So, I found that I had to teach people how to do it and so I became a project lead and consultant on how to bring Agile into organizations and I have been doing that sort of thing ever since. I also have a book called “The Art of Agile Development” which came out in 2007 and these days I also have a screencast called “Let’s code Java Script” at letscodejavascript.com.
InfoQ: Great. You are at the Agile Australia Conference and yesterday you gave a great workshop in which you took us through your Agile Fluency Model. Would you like to tell us a little bit more about it?
James: Yes. Diana Larsen and I created the Agile fluency model back in 2011. We were looking at the state of the way that teams practiced Agile and the vast differences in the ways teams practiced Agile. Also, at that time – and maybe it still happens today – people were saying “This is Agile. That is not Agile” and we wanted to take a more inclusive look at the situation. We were also very intrigued by William Larsen’s language hunting project, which was about rescuing endangered natural languages, like the Chinuk Wawa, the trade language of the Native Americans of the Pacific Northwest. The neat thing about language hunting was that it put a lot of emphasis on fluency and other neat ideas as well and we thought that this idea of fluency made a lot of sense when we talked about Agile. So, we looked at all the different ways teams practiced Agile and how teams learned Agile over time and we saw a clear progression from a basic focus on value, of doing stories and talking about things in terms of business value to being able to deliver reliably on the market cadence and bringing in some of the technical practices from XP. And then, from there, some teams even get to the point of taking ownership of their markets, bringing business expertise into the team, having true responsibility for delivering value in terms of deciding what the product originally was, not just doing what they were told. We see a few examples of people going even further than that, to a higher level of fluent proficiency, where teams are acting as pure decision makers in the organization rather than having a top-down charter.
So, the fluency model was a change to distil this out and we took it to a lot of different people, a lot of respected colleagues, practitioners, executives and said “Does this make sense to you?” After some feedback and some modification, the response we got was “Yes. This actually reflects how teams learn and not only that – I can use this to see what we want to look at next”. Martin Fowler ended up publishing our white paper on his web site.
InfoQ: So how do teams know how fluent they are?
James: Well, it is really a matter of proficiencies. There are many different proficiencies, many different skills that you need in Agile.
What we have done is that we have sort of broken them down into these four bus stops and I think the important thing about being a fluency model is that it is not a maturity model. You do not look at it and say “There are four stars and if we are not four stars, we are crap”, CMM is an example of a maturity model - If you weren’t at CMM Level 5, you weren’t doing anything worthwhile.
With the fluency model, it is not really the case. What you have is four different stops on a journey and any one of those stops can be right for any team, depending on what they need and what their organization needs. Figuring out exactly what fluency your team has, takes some experience. We have distilled down four core metrics – they are not sufficient conditions, but if you do not have these capabilities, then you are probably not fluent.
So, for a one star teams, the teams that are focused on value which means talking in terms of business value. So, if you have a team and they are not talking in terms of business value, they are not showing progress in terms of business value, they are not giving their business partners the chance to change direction, change the order of stories, for example, if you are using stories. If you are not doing that, then you are probably not fluent at the one star level. If you worry you might be, there might be other things you need to do as well.
Similarly, for two stars – the core metric is delivering on the market cadence. If you cannot deliver to the market, whenever the market is ready, even if you do not have everything they want, then you are not yet fluent there.
For three-star – if you are not working in terms of business outcomes and sharing business metrics like return on investment or net profit/employee or net promoter score, if you are not thinking in sharing those types of ideas, you are almost certainly not yet fluent at three stars. But, again, just doing that, does not necessarily mean that you have the expertise required to be three stars. Three-star is about really understanding the market and being able to do the most valuable thing for that market.
InfoQ: And four star? You said you have not seen many organizations there yet. What would that look like?
James: Well, I think if you look at some of the cutting-edge self-organizing companies, you see the glimmers of what four star might look like. But four-star is partly there because we want to emphasize this is not a maturity model. A four star organization is going to consist of teams which are going to be setting the direction of the organization, not the CEO, not the CTO, but rather it is going to get merged from the collective wisdoms of the teams. They are going to work with each other to understand what the organizational strategy is and what the organization strategy should be. How does that work? Well, that is very bleeding edge. We do not know yet. I do know that for most companies that is not even the right target. But, you can look at companies like Zappos which are trying things like this, Semco which is not a software company, but they are famous for doing self-organization there in Brazil, Valve – they are a software company and I do not know if they are trying to do the Agile, we certainly haven’t talked to them about this, but they do a lot of things that might be starting to move towards proficiency at the four-star level.
InfoQ: As an Agile coach, what do I do with this?
James: Well, we are just now starting to produce a tool that can be used for coaches to understand where their teams are at and how they want to work with the teams to improve fluency, but even more importantly, understand what fluency is right for their organization and how to talk to leaders and executives about the investments needed to get to the right level of fluency.
One thing that we have learned that has been a surprise to me, that I did not realize when I first starting working on this is that fluency has more to do with organizational culture and investment than it does with specific team skills and it is certainly not about individual skills. Of course those skills do matter, but when you look at the broader organization and where teams are at, it is about what the organization is doing. For example, to have a two-star, one that delivers on the market cadence, you need to learn a lot of technical skills and that does take effort from the team. But an organization has to give room for a team to learn, as you are learning these things, as you are paying down technical debt, as you are introducing things like DevOps, first you have to bring these technical skills into the team and second – the organization has to be patient and willing to accept lower productivity.
So, this set of tools that we are creating- we are calling it the Agile Fluency Diagnostic – it is really a facilitated exercise for working with a team to understand where they are at and also to have information you can bring back to executives and talk about. This is what we are seeing. Understand that fluency is about what is happening in the organization and here is what you might want to look at and change in the organization to provide room for the teams to grow.
InfoQ: So, insight into the organization and tools to understand. Thank you. Switching gears a little bit, please tell us about some of the technical things that you are doing. You mentioned test-driven development for Java Script and CSS.
James: Yes. My background is as a programmer and I try to keep my hand in on the technical stuff ever since I started. I have a screen cast called “Let’s code Java Script”. It is about doing test-driven development of Java Script and Java Script is sort of famously challenging from an Agile and professional engineering practices perspective. So, the reason why I started this screen cast was to try to understand, to look into that and try to help people understand and to create ways of really doing good development. So, for example, there is a tool called Karma that you can use to run your test across browsers. So, I’ve got my system set up to that one. I run my build, it will run the test against eight browsers simultaneously and tell me, for example: IE8 – no surprise – has broken, everything else is still working.
Recently I have started an open-source project called Quixote. It is about being able to test –drive CSS so that you can make statements about “my logo is inside my Navbar, my content area is the same width as my Navbar minus the width of my sidebar” People have looked at test-driving user interfaces – it is a challenge that has brought me to this point. You see UI bugs all the time – it shows up. It works on Chrome, but it does not work on Firefox because somebody did not bother to look on Firefox. This makes an environment where it is very difficult to make changes to your CSS for fear of breaking something somewhere in your site. So, being able to test-drive that and do it in a unit-testing way that talks about the visual outcomes, rather than just taking a screenshot as some tools do, which is very brittle, or just talking about what you’ve typed into your CSS which is just redundant. Now, what we are looking at doing is programmatically describing how your page should look so that you can run those tests in a unit testing style that is very fast and can run across browsers.
InfoQ: An this is an open-source, freely-available plug-in?
James: Yes. It is a library. It is on GitHub. If you search “Quixote CSS”, you will find it, but my GitHub is github.com/jamesshore and it is on there. It is a library that you use inside of your existing tests. So, if you are Java Script and you know test-driven development, you might use Mocha or Jasmine, you might combine that with Karma to do cross-browser testing. Quixote would be a tool that you would use inside those tests to bring your page in and make assertions about how things relate to each other on the page.
InfoQ: You mentioned Java Script. You also have a free “How to” series.
James: That is right. I just launched a new channel on the site. The series “Let’s code Java Script” has been going on for three year. It is a subscription-based series on all sorts of professional Java Script and web development. One of the channels that I have just now launched is the “How to” series. This is for beginners, for people who are just coming out of college or have maybe a code school, that have learned how to program, but haven’t yet had the experience of working in a professional environment. So, they may be aware of version control and builds and continuous iteration and so on, but have not seen how that all really fits together. So, I put up this “How to” series for those people and I have launched it a couple of weeks ago and it is going to be free for the next several months as it gets going.
InfoQ: James, thank you very much for taking the time to talk to us today.
James: Shane, it has been a pleasure. Thank you for having me.
About the Interviewee
James Shore is a thought leader in the Agile software development community. He combines deep technical expertise with whole-system thinking to help development teams worldwide achieve high throughput, market focus, productivity, and quality. His work helps teams generate opportunities, reduce risk, and respond quickly and effectively to changing market conditions. James teaches, writes, and consults on Agile development processes. He's a featured speaker at conferences around the world. He led his first Agile team in 1999 and conducted his first Agile team transformation in 2000. He is a recipient of the Agile Alliance's 2005 Gordon Pask Award for Contributions to Agile Practice and is co-author of The Art of Agile Development (O'Reilly, 2007). In 2012, InfoQ named him "[one of the] most influential people in Agile." Today, he focuses on helping people who are willing to make dramatic changes in order to achieve great results.