Agile Autonomy and Commitment

A recent post Should Agile Teams have to Call Their Shots got me thinking.

Calling pool shots == Velocity prediction

Mike makes the statement that calling your pool shot each and every time you shoot the cue is akin to being able to predict the outcome of a sprint iteration. The analogy is interesting but I think a little imprecise. Professional pool players - at least the 8 ball players I have seen on T.V. - have the ability to shoot the cue, hit the ball they want and have the cue glide into the near exact position needed to make their next shot. Pro-pool players seem to do this without really thinking about it (at least that is the way it appears on the T.V.). Similarly scrum sprint teams have to execute work for a period of time and when that time box is up be ready to do the next needed thing. However the sprint team can do this without ever needing to know their velocity at all and they can repeat the cycle over and over without the knowledge of their velocity. Velocity is important in predicting how much a team can do - but is only useful in predicting 'what' a team can do by providing a bar to say that something is too big or too small to fit within an iteration cycle.

Trust

Calling your shot in terms of scrum sprint teams and their velocity measurement is really about creating a level of predictability for the team and the organization as well as generating a level of trust for delivery with the business partners. Unlike the pool example - there is an external group beyond the individual that has to be able to count on the team committing to and delivering on promises so that the organization as a whole can be setup to execute the next set of work without having to worry about items that did not get completed because a team missed the mark. In the pool example there is only a single person and only that persons call of the shots matter - it is hard to scale that example up to teams with multiple people all of whom have to understand the team commitment and the need to follow through. Equating the single person in pool to a single team also doesn't seem quite right for the reason I laid out above... a team doesn't need to call the shot in order to do work in iterations, but they do have to call the shot in order to generate trust that they can 'predictably' do iterations. It is the trust and predictability that allows planning beyond one iteration for the organization.

I think a better analogy would be something like the team being able to reliably hit a bulls-eye in darts. Hitting the bulls-eye in darts requires skill and practice. I believe it to be the practice part of dart throwing that was missing in the pool analogy presented. Teams will not have any knowledge of their velocity when they start out and it will be difficult if not impossible for them to "call their shot" until they have run through many iterations and actually gelled as a team. As they practice however - they will get more consistent and more accurate. However, in those first few sprints, despite not having a consistent velocity and provided that they commit to and complete work that the team agrees can be done, the team will be building the trust with the business and management that as they get more accurate in their velocity measurements the team can be counted on to complete agreed to work in a given iteration.  This is when the benefit of knowing your velocity can be seen. 

Mike was right that knowing the team velocity is important for planning and laying out releases and things - but I would argue that trust that the team will complete what they sign up to complete is far more important.

Steve Jobs Open Letter

In an open letter (also available directly from the apple website, here) to the world, posted on engadget, Steve Jobs attempts to layout his reasoning for why no flash and other "third party" libraries on the iPhone, iTouch, and iPad.

I am going to pick a little on point number six from his letter:

"Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform."

Yes Steve - this can be thought of as a laudable goal. The problem, you see, is choice. In some respects "...if you build it, they will come..." holds true when you talk about cool features and tools to make applications. However, making the choice to not allow ANY THIRD PARTY tooling (flash not withstanding) you are restricting all the other people that might not want to learn Objective-C in order to program for the platform. True - there are plenty of people willing to use your tools, as the number of applications currently available demonstrates, but if the number of applications 'COULD' be 10X as large if you allowed Java, C#, other languages into the space without compromising quality (which you shouldn't be able to control in the first place Steve) would you say that's a good trade off?

I am not sure I buy into the simplistic argument that Apple is using to draw this particular line in the sand.

...To make sure people can 'always' make use of the latest and greatest platform features...

Is it not the case that anyone that wants to do that should be able to make the CHOICE to utilize Objective-C as their platform for coding applications. However, if I am not always interested in the latest or greatest features, essentially I don't care about the cutting edge, I just want an application to work... why can't that type of thing be done in another language and without compromising the supposed quality/availability that you taut.

Sorry Steve, I am just not buying it - literally and figuratively.

The Great Debate

So - The new shiny thing is out for the iPhone, OS4, which contains a change in the Terms-of-Service that seems to have everyone talking. There are some great posts discussing the TOS changes from John Gruber over on Daring Fireball, here and here. There is also some additional commentary, including an email exchange with Steve Jobs, over on the TaoEffect - here with a follow up due to user comments here.

What I have been wondering reading all of the various commentary about the TOS change is this:

Other then form factor, what makes the iPhone platform so substantially different from a MacBook?

You could talk about computing power, the iPhone obviously has a lot less over all computing power then a MacBook. Yes, very true. So what - it still seems to run programs just fine.

You could talk about screen size, the iPhone screen is obviously a lot smaller then your typical MacBook @ 15 inches or so. Yet somehow the information from the programs on the iPhone still seems to make it to the user just fine.

You could talk about the lack of multitasking, however as I recall macs well into their golden age, before OSX came out, used to do cooperative multitasking (which arguably gave the appearance of multitasking without really doing it) - which with a few tweaks looks alot like the multitasking being introduced in iPhone OS4.

On the MacBook I can write applications in:
Ruby
Python
C
C++
Objective-C
Java
Perl
Erlang
JavaScript
And the list goes on.

On the iPhone I can write applications in:
C
C++
Objective-C
JavaScript (WEBKIT Only)

So the only substantial difference is the programming languages I can utilize to write for the platform? Ok, I admit that this is an oversimplification of the situation, but it does make for a good talking point.

So why is the iPhone so limited in regard to the languages one is allowed to use to write applications? I think the answer is simple, Apple is attempting to control every single aspect of how their software/hardware is used in the name of 'Good user experience'. Apple has, as a company, always tended to lean in the direction of 'control everything' - take their historical stance on mac clones as a for instance. However the control Apple is attempting to wield on the iPhone is much tighter then that of the computers that they also market. I can write in any language I choose on the MacBook - but I need Xcode, Objective-C and Apples blessing to write an iPhone app. The platforms are not different enough to warrant the 'language' restriction. Add to the concern that the last item on the above list, Apple's blessing, can be very difficult to come by if your application happens to compete with Apple's interpretation of 'good user experience' (i.e. if what you write using the tools they say, competes in anyway with the built in functionality).

It seems to me that Apple is not interested in the user experience - just their own bottom line... like any other market driven company. Apple's stance seems to be working, at least for now, based on their current stock price as of the time of this post. I do question however if the stance Apple has taken will work in the long term - people may start to take notice and do what I have done... vote with my dollars and not purchase the things that they produce. Essentially avoiding the 'Apple Tax'. Make no mistake, this is not an Apple bashing exercise - I believe that they do make a very unique user experience and a lot of coders could learn from the 'little' things and polish on development that they do so well. I just think that those things don't make up for a corporate stance that is attempting to squeeze everything that isn't C based on a Mac out of the iPhone development picture.