Re: [scrumdevelopment] RE: Distributed Definition
On Sep 26, 2013, at 5:55, Ron Jeffries <ronjeffries@...> wrote:
All,On Sep 26, 2013, at 4:39 AM, Tathagat Varma <tathagat.varma@...> wrote:
I think a definition of 'distributed' should factor-in those significant trends on how work gets done today and in what direction is it headed to?More to the point, why would a definition of "distributed" include any value judgment at all. Presumably a distributed team is -- something like --a team whose members habitually work in physically distinct locations from one another, and who rarely, if ever meet and work together in person.
- One of the things that those companies, and a lot of open source projects, have in common is that the workers are customers. If you are developing something that you yourself will use then you bring passion and perspective that can create value independently. You find like minded folks to do the same, and as long as you agree most of the time things will go rather smoothly.You will also find open source projects that are dysfunctional, because the players disagree passionately on the approach or even the ultimate goal. Many such projects fork successfully, but many others fizzle.However, most of the software in the world is business software. You can't count on people with the necessary technical skills being users or even being passionate about the goals. You need business people to represent the customer and advocate for their passion. You need those business people to be in the room to have a good chance of that being communicated effectively to the team.On Mon, Oct 7, 2013 at 12:16 PM, Yves Hanoulle <mailing@...> wrote:yes I agree on the idea that the team sometimes is not the botteneck, yet if you look in detail at the companies likegithub, automattic, leanpub, you will see that none of this is the case.aka there is no bottleneck elsewhere. They optimize the team in a way that works best for them.And yes they all meet F2F from time to time.yet mostly their communication works because they focus on trust.trust is a bigger communication channel then F2F.I'm no expert on open source, yet I started a few communities that mostly communicate e-mail based.And it works great. yes it's limited and yes I would not call them real teams, yet everything that needs be done (and waaaaaay more) gets done.trust and small independant work...
Phone 00 32 476 43 38 32
Who is agile http://www.leanpub.com/WhoIsagile
Who is agile in South-Africa http://leanpub.com/WhoisagileSouthAfrica
The Leadership Game https://leanpub.com/TheLeadershipGame/
Agile Conferences Calendar: bitly.com/AgileConferences
Agile Thursday Quiz: www.hanoulle.be/atq
Coaching Question Of the Day: www.Retroflection.org
Contact me: YvesHanoulle2013/10/7 Adam Sroka <adam.sroka@...>Exactly. Agile teams need valuable stories to work on and the ability to get those rapidly into the hands of customers to get feedback. If any of the up or down stream processes that make this possible are the bottleneck then highly optimizing the Agile team is waste. One of the reasons that many organizations are able to improve with distributed teams is that the team is not the bottleneck.On Fri, Sep 27, 2013 at 9:52 PM, Tim Wright <tim@...> wrote:You comment about optimising variables to optimise the system rang a bell for me. There's a fantastic manufacturing theory called the "Theory of Constraints" (The Goal by Eliyahu Goldratt describes it well). In that theory we don't bother doing local optimisations - as these often degrade the performance of the system as a whole. Instead we identify the key bottleneck in the system and do whatever we can to optimise the system to exploit that bottleneck. This means we might de-optimise other parts of the system to improve the performance of the bottleneck. It turns out that improving the performance of the bottleneck increases the performance of the system - and nothing else has any effect on system performance.In most projects I've been on, system development (and testing) is the bottleneck for the project and scrum does a fantastic job optimising that bottleneck. However, from an organisational perspective, I can conceive of an organisation where software development is not the bottleneck. In that case, it's feasible that de-optimising software development - perhaps by using distributed teams - could increase performance of the organisation as a whole - by using those resources on the organisation's bottleneck for, perhaps, sales (a common bottleneck for organisations).Just a thought.TimOn 28 September 2013 13:35, Adam Sroka <adam.sroka@...> wrote:Call it a "driver," "excuse," or whatever, the point is that there are legitimate reasons to choose to do something suboptimal to optimize some other variable. That doesn't make the choice any less suboptimal, but it might still be optimizing the whole given the constraints on the system.Part of my point, however, is that I have rarely seen this. Distributed seems to be the de facto choice and the arguments against it rarely come up until it is too late. Usually by the time I get called there are problems and one of them is figuring out what the hell those guys over there are doing that takes so damn long (and is usually wrong, and therefore has to be redone, etc.)There are exceptions, of course, but the best, most driven, distributed teams I have worked with were spending a huge amount of energy (and money) to feel like they weren't distributed. Expensive cameras, long hours in order to have team meetings across time zones, frequent travel to establish rapport, etc. That cost usually offsets the savings promised by being able to hire elsewhere.The alternative is to not spend that money and not have a real team. Lots of hand offs, document driven communications, frequent and unpredictable delays. If that's where you are then that's where you are, but it's not consistent with Agile/Scrum values and it's not as cost effective as the management theories predict it should be.On Fri, Sep 27, 2013 at 7:52 PM, <timswise@...> wrote:
Here's the output and context that I was going for... I hate when there's no follow-up.
I agreed with Adam's point of view before this presentation. The presentation itself had an aha moment for me. It was basically that if a business need (global labor pool, etc) outweighed the suboptimal team then you had a valid business driver that you can justify and communicate to your business. That's powerful. Before I would have said that the business excuses for the need was valid, now I would say the business driver for the need is valid.If you want to check out a write up here it is...
Warning it is my blog... at least I'm transparent in my shameless self promotion :) http://ow.ly/picrk
Thanks to all for the input. It is much appreciated.
---In email@example.com, <steve@...> wrote:
If you are developing a product for global consumption, then having parts of the team in different parts of the world is helpful from a cultural and language point of view; witness the Vauxhall Nova - didn't sell well in Spanish speaking countries because 'no va' means something like 'doesn't go'!!
However, to be successful you still need good communications; web cams, video-conferencing facilities, decent VOIP phones, good network bandwidth. Unless the organisation is willing to invest in good comms any advantages of having the team spread across the world will be markedly reduced.
---In firstname.lastname@example.org, <email@example.com> wrote:Hello Tathagat,Interesting... Thanks for the examples... another success is 37signals. I largely agree with what you say; however it seems that I've not communicated my point sufficiently directly: face to face and hence collocated is almost always a better option, if we can work out the logistics. You can still email/skype to the next desk, now we can also walk over and have a free and frank exchange of views (which btw, in some circles means a fistfight)It may not be practical always, and distribution maybe a necessary compromise. It may mean a happier compromise and one increasingly made since these days is not such a bad option.If we have to choose between location and talent, we don't have to blindly choose colocation; neither need we blindly choose talent, unless it is clearly much above average.OTOH since familiarity breeds contempt: being distributed could mean a better working relation! Bah, blasted humans, they are so difficult! so shall we spar w/o meeting in person!?!CheersSrinivas
Sent from my iPhone
On Sep 27, 2013, at 12:33 PM, Tathagat Varma <tathagat.varma@...> wrote:Srinivas - Let's look at these contemporary examples:http://automattic.com/map/ - how are the folks at Automattic (the WordPRess folks) distributed across the world. and the CEO Toni talks about it at http://toni.org/2010/03/08/5-reasons-why-your-company-should-be-distributed/. As he says, they are "In Automattic’s case, we currently have over 50 employees spread across12 US states and 10 countries." The have now grown to 180 and still growing distributed...http://gigaom.com/2012/03/26/tales-from-the-trenches-github/ - the reasons why Github went distributed. They didn't even have an office for the first two years - http://zachholman.com/posts/how-github-works-asynchronous/http://www.themarkphillips.com/2011/06/27/Building-and-Maintaining-Internal-Community-And-Culture.html - how the guys who make Riak do it. They say, their teams disributed juet like their databases...and the tribe of such location-agnostic startups keeps growing...The way MOOC has been disruptive innovation - now people don't need to go to college to get educated - and it has nothing to do with economics. It is the sheer content delivered in a smart manner that makes people use Khan Academy or other MOOCs. Could we have predicted this ten years back? Maybe not.Similarly, I am seeing that the next wave of work is all about work going to wherever the talent is - with or without the desirable price point. While scrum might be one way to address how to organize work, and might be particularly useful when the entire teams sits on a single floor, the very premise of what constitutes a collaborative 'team' is changing rapidly from what it was ten years back. So, will I want to stick to the definition of a team that was ten years back, or adapt my process and practices to what the terrain looks like here and now?I guess the questions is: what is more important to you: talent or location? I am sure the top talent that wishes to be 'recruited' at their home base knows the rules of the games enough to be collaborative lest be forced out of business. Whereas location just for the sake of it might give me a sense of entitlement about work?regards,TathagatOn Fri, Sep 27, 2013 at 11:04 AM, Srinivas <ceezone@...> wrote:Hello TV,In my view the important point you make is about, when dispersed individuals have to collaborate, therefore, are nudged to be more careful about their communication. Hence they can be very effective.In your own case, which you cite, I think collaborating using tools is the only practical option which isn't prohibitively expensive. However, 18 th century mathematicians also collaborated using letters and snail mail (max baud rate being dependent on carrier pigeons). They would have been more efficient with skype! But even more so with co-location. Therefore they had retreats; unfortunately underrated these days. That is possibly why we still have conferences, not just webinars.The scrum community attaches more meaning to a 'team' than the average layman does. In this context, co-location is seen as desirable; however distribution may be very difficult to avoid. It may be the only practical option.Wikipedia is an interesting success story of unknown distributed people collaborating. But are they really collaborating? Or are they simply aligned in bits and pieces and their work (mostly driven by genuine interest in topics) gets aggregated?When a political party sweeps the polls, are voters collaborating consciously? Maybe, these days via social media, but this also happened before in BI ( Before Internet) .More points to ponder, eh?CheersSrinivasSent from my iPhoneyApart from my dayjob, like many of you, I routinely work on volunteer groups that have no chance of ever meeting face to face. e.g., as track chair for one of the tracks for Agile India 2014, I work with 'distributed' teams of folks in multiple cities in India, US, Iran, Australia, etc. We have never had any in-person contact nor do I expect that will happen (at least not before the conference), and yet, through a combination of imperfect mediums of communication and collaboration - mail, phone, skype, common collaboration tool (i.e., the submission system), we are able to make steady progress towards our objective. Given the nature of work (volunteers who are not spending 100% bandwidth on it but rather 2% or 5% of their daily bandwidth sustained over a long period of time, Poisson arrival pattern of feedback from reviewers and authors, etc.), I don't think face to face would actually work. And I don't feel that the current arrangement is hurting us.So, I would argue the purpose for which we are defining the term 'distributed'. In fact, for some class of 'work', it might be not just be the only way available, it might even actually be the best way to collaborate - i.e., when you purposefully introduce a disruptive constraint in the system, you actually force all parties in the system to articulate their interfaces or contract much more 'sharpely' than what you would do otherwise, and that very act of sharpening the interfaces helps surface up a whole lot of impediments that we would have otherwise continued to be blissfully ignorant of! To me, a team size - any team size in a batch is a potential indicator of 'safety in numbers' - to that end people in distributed zones are not allowed to seek such safety and hence must collaborate with constraints. Think of it as kanban applied to team size. I think there is enough anecdotal data to back up my perspective. Take Wikipedia - how many of the volunteers have face cared about face to face collaboration? Or other open source projects? Or e-lancing? and yet, they work because people have found out how to use dislocation as a competitive advantage. Perhaps that creates much higher agility because when someone gets off the team, because the nature of work is so 'well-defined' and has already been done 'over the wire' that a backfill is able to hit the ground running pretty face. Now this might not be the way all of us here do work, but I am beginning to see this as a very fast, effective and efficient way to get the job done without worrying about the location.I have had experiences with non-native speakers of English who came across as poor communicators in a face to face setting, but with very good communication skills over email (perhaps thanks to some online translators?). So, would I care if those folks were sitting within a 5 meter radial of my cube?I think a definition of 'distributed' should factor-in those significant trends on how work gets done today and in what direction is it headed to?-TVregards,TathagatOn We--
Tim021 251 5593