Shane Hastie is a New Zealander; I live and work in New Zealand, travel a lot around Australia and New Zealand and around the rest of the world; I’m a member of the board of the Agile Alliance; I was elected last year for a two-year term; that’s been a really interesting and very fulfilling piece of work; as you say, I do the work with InfoQ; I’m the lead editor in the Process and Practices space and there it’s been really enjoyable getting to go and investigate my industry. In my day job, I teach and I coach, work with Agile teams literally all around the world and have become quite passionate about the cross-cultural aspects of working with teams: the global teams, cross-functional teams, cross-cultural teams are the norm today whether or not they’re co-located; New Zealand is a country that has many diverse cultures and bridging those gaps is part of the stuff that I’ve become passionate about.
Also, I volunteer with the International Institute for Business Analysis bridging the gaps again between the world of analysis and the Agile world; in the Agile space there’s been a little bit of resistance to it “We don’t need no stinking business analyst!” and the job role as a business analyst might not always be there on teams but somebody is doing analysis and a lot of people on the teams are doing analysis; so it’s looking at how we bring the skills of analysis into the Agile space as well so.
Michael: You actually gave a good summary of some of the questions I was going to ask you; so let’s start with the cross-cultural stuff: being a New Zealander, I really understand what you’re talking about; InfoQ is also very cross-cultural.
We are indeed - multiple countries, multiple backgrounds, it’s a great community to be part of.
It’s not necessarily the questions that are different but the background of the questions and in many cultures, it’s the ability literally to ask a question, so how do you question, how do you challenge; the subtle nuances in meanings that sit behind. In some cultures it’s considered impolite to say no so if you’re having a conversation perhaps between a manager and a developer and the manager says “Can you do this task?” the developer might be thinking internally “There is no chance in hell that I would ever be able to do this thing!” but they kind of say yes and the yes might not mean “I can do the task”, it means “I have heard you.” So where you’re crossing cultures from that perspective and in that particular case, we’re talking about high power distance differences as well, you have to be very aware of the nuances of what that response means within that culture.
3. So a cross-cultural team would have to be very aware of this?
Absolutely and to be really effective, they need to take the time to understand each other and that’s about building the trust and having the communications. One organization I’ve worked with does it wonderfully; they are a 250-person development shop with 19 different national cultures represented; once a month on a Friday afternoon, the whole shop, the whole place closes and they get together and each culture prepares a meal for the rest; so they take a turn. And sharing food is a wonderfully important part of being human and it builds; there’s all sorts of good things that come out of sharing food but they use the opportunity of preparing; so they prepare a meal from their culture and they serve it in the way it would be served and the people from that culture explain the meal. So if it’s the turn of the Indian people for instance, there will be a variety of different curries, there will be no beef and mainly vegetarian food and it will be served without knives and forks and you’ll use the bread to scoop up the food and they will explain everything about “This is what the meal means to us, this is how we eat, and this is how we would typically communicate” and just that little thing. And as I said, they take turns through the whole, through all of the cultures over and with 19 cultures it takes 19 months, it’s one Friday a month; and it builds that understanding and that’s the sort of thing that we need to be doing more of.
I’m working with all of the above ranging from very small organizations to large multinational companies with in one case four and a half thousand people moving through an Agile transition in 19 different locations; that’s probably the most diverse that I’ve worked with down to a really small Agile transition in a company in New Zealand that is an agricultural producer.
The International Institute for Business Analysis and this is the body looking to create a profession of analysis not analysts, analysis and that’s a very important distinction. The job title of business analyst in some organizations and in some environments is very valid, but in a lot of cross-functional teams, we see the disappearing of the roles, role based stuff but we still bring skillsets and that skillset of analysis is very important. The IIBA is currently defining the next level, next round of the business analysis body of knowledge, what are the good practices the good tools and techniques that are out there that can be used in myriads of different types of projects from business transformation, reengineering, process and process change through to technology implementations.
I’m a member of the team, of the core team building the version three of the BABOK (Business Analysis Body of Knowledge) but also a big part of the reason I’m engaged there is I’m bringing the Agile perspective to that and have led the team that has produced the Agile extension to the body of knowledge and that really has been about finding what are the commonly used good Agile practices that help in the analysis activities on projects.
6. What are some of those commonly used practices?
Well probably the most common one that we hear about is user stories and the effect of use of user stories, the work that Jeff Patton is doing on story mapping extending that out but also bringing in things like personas from the user experience space, bringing in the envisaging activities to make sure and it’s the sort hackneyed, make sure that we build the right product. I do feel quite strongly that at a technical level, we know how to build software systems today; most of the technical problems have been solved, yes there is some stuff but the risk in the software realm today is not so much about “Can we do this with the technology?” the risk is “Should we do this? Are we building the right thing?” Or there’s the off quote it’s Standish group statistic that says 64% of features in software products are never used; well that’s a huge amount of waste, let’s make sure we do build the right thing and that of course is what the Agile movement is very much about the just in time, just enough and let’s bring the business analysis community into that same mindset, that same way of thinking; so moving away from the big upfront design, understand everything but what’s the minimum and what is sufficient to make sure that we are going to solve the right problem.
Yes; it’s in many ways we’re getting quicker; even the two-week cadence of a Scrum team or of an Agile iteration might be too long and moving towards the continuous deployment; the move perhaps towards a more Kanban type approach where you’ve got the flow and the work in progress limits and just keeping work steadily going through. The other thing is really important in terms of keeping teams together for longer periods rather than continually reforming the loss of knowledge that happens when we break a team apart and yet our whole project’s culture and environment has been about putting a group of people together just long enough for them to become productive and then destroy it.
8. What advice would you give to that organization that is breaking teams up?
Stop; keep the teams together; the longer we can keep people working together as a group, they build that inherent trust, they build that many levels of communication and they form a team culture and that builds and flows and bring work to the team rather than bringing the team to work. And I’ve worked with a few organizations where we’ve managed to do that and the productivity differences are huge; the quality differences are huge; the satisfaction, the joy in work stuff and as a consequence of that, the customer delight and customer satisfaction; and really it’s that customer delight that drive profitability which gives us a reason to exist.
It really does depend on the organization; we’re tackling almost the two extremes; at one level you’ve got the organization who has perhaps come from a startup culture where the teams have been very technical and the management has in fact been the provider of the voice of the customer; at the other you’re dealing with perhaps the large corporate, the government department large financial institution who have a whole department whose job has been to protect the customer from having to talk to geeky, technical people because they don’t understand and can’t communicate and all of those horrible stereotypes; and with both of those organizations, it’s a matter of bridging and bringing to the middle an understanding that that skillset of the ability to either bring the right customer to the team or the XP world where the onsite customer is the perfect way of working, I totally agree.
The problem is when certainly in the corporate environment, you are typically dealing with at least 15 different customers and you’re not going to have 15 of them on your project; you’re not going to have the people dedicated to the team at that level so you need another role to help maybe go out and bring the right customer to the team at the right point and in some cases bring the knowledge from that customer to the team. Selling that is a different type of selling depending on those two extremes but you’re convincing and explaining that the value of the build the right product.
Michael: So as a consultant are you brought in to kind of mediate that?
Frequently I’ve worked with organizations who are trying to make the “We want go Agile and what does Agile mean in our context?” because there’s no single definition of Agile. There’s probably a few things that we can say “This is the shape of an Agile project; it will fix iterations” but even that is going away today, short feedback cycles and lots of feedback cycles and it’s helping create a culture where people can provide that feedback. And I come back to culture and culture is not just a transnational culture is across teams. I’ve been in the room where you have a marketing person and an accountant trying to have a conversation; they talk past each other; they’re using the same language, it is some derivation of English, but there is no communication. Somebody with analysis skills, somebody with that facilitation skills often sits in that conversation and bridges those gaps; the universal translator, the person who hears Klingon and speaks Romulan bridging the gaps.
10. Speaking of facilitating, do you conduct or help people conduct retrospectives?
Yes; that’s a large part of that helping build the feedback loops.
Boy, you’re putting me on the spot. If there’s one thing that I’ve learned that I would like to sort of convey out there, different is not bad, it is just different and bridge those differences; take the time to listen to each other and understand and when we actually drill down to underneath the differences, there’s more in common between us than what is different and when teams can get to that point of understanding, when different communities, different groups can get to that point of understanding, a lot of the trouble goes away.
Yes. On the board at the moment, I’m not an office holder but we’re a group of 12 passionate people who really do care about improving the world of work and improving, making the software environment, the software community more humanistic. I look after one program in particular that I really enjoy and I get a lot of personal satisfaction out of and that is the Agile Manifesto translation program. The Manifesto was written by 17 very forward thinking people way back in 2001 and in about 2006 or ’07 there was a program, which started under the Agile Alliance to translate this and our aspirational goal is to translate it into every written language in the world. It’s going to take a while; so far and just as the conference started, we published the 42nd language, now of course 42 is a very fortuitous number in the technical community being the answer for all of the world’s questions. So we have 42 languages that are up there on the Agile Manifesto website and there are another 24 in process.
And what I like about the way that that program runs, it’s not a matter of an individual who speaks a language coming along and saying I want to translate and they sit down and write it in Georgian or Hindi or whatever. The program has been structured so that people form a community around doing the translation and in some cultures, some countries those communities are already there; it’s tapping into the existing Agile community. But what’s been really fantastic to see is the number of the translations, the formation of the team who are going to actually tackle the translation into their local language has triggered the creation of a local Agile community. So you’ve had disparate individuals who are doing Agile using these techniques and now they want to contribute and it gives them the hook to create a community and from that we’ve seen in a number of countries where those communities have been gone on to greater and greater strengths and yes as I say, there’s 42 languages published and up on the website at the moment.
We certainly encourage them to do so and so what I see is within those translation teams, they tend to use the Agile practices, lots of feedback, good healthy discussions. An interesting one that we see in many languages is how do they translate the term Agile because in the English language it’s about that adaptive and quick to respond; not every language has a word that translates exactly like that and in some cases they’ve debated for and discussed for weeks and months about what would be the best local term and in a few cases they’ve’ actually stuck with Agile and chosen to do so. But just having those conversations again lots and lots of feedback, lots of iterations to come up with and also it’s never finished; there have been changes to translations years after the original one was done because somebody has come up with perhaps a slightly better meaning or way of expressing one of the principles or one of the values.