Sunday, August 1, 2010

Jeff Sutherland's Pearls


Last week I attend an Agile RTP meetup hosted at the offices of Relevance Software . I heard Jeff Sutherland speak about the "Five Problems solved for PatientKeeper". If you are into Agile then for me to repeat what he said would be redundant, and if you are new to Agile then you probably need some basic education before jumping into his talk.

However, I captured the following pithy quotations from Jeff:


1. "World domination always gets people excited". When the PatientKeeper management team was forming the company, they needed a vision of what PatientKeeper would be when grown-up. Jeff speculated that Bill Gates had a vision of owning the PC desktop. Sooo... the PatientKeeper team decided to own the mobile devices used by clinical professionals. They wanted to create a framework that would be considered the gold standard for third party medical application developers.

2. "If it is impossible show me the impediment list". Attributed to the CEO who took over PatientKeeper in 2003 and wanted the code deployed to hospitals after each Sprint. When told that the installation time was a bottleneck to this tempo, he formed the "Live by Five" program, which brought in PatientKeeper expert services to work with the hospital IT staff to make sure the installation took place by 5:00 the day of install.

3. "If Lean is all about removing waste, then SCRUM is all about removing impediments". Jeff likes to teach Lean Manufacturing to executives trying to adopt agile development because he believes that they can relate to the examples from the world of manufacturing.

4. "Is the Tango a methodology? Neither is agile". Someone in the audience asked Jeff to compare the light-weight "method" of agile with a bureaucratically heavy approach like CMMI. Using the analogy to the Tango, Jeff said that like that dance, the Agilista does not plan so much but responds to the circumstances of the project.

Wednesday, July 21, 2010

a mobile device dilemma Part II


Since last December when I shared the small family crisis caused by the way the cellular industry has conspired to keep me off of Android a couple things have changed:

  • AT&T has begun to offer some good Android phones. I would seriously consider the Captivate for my use.
  • Rumors of Verizon taking on the iPhone persist. If that happened I could move the family over and my wife and daughter could stay on the iPhone while I could pick and choose from a wide variety of Android devices.


However, my decision continues to be complicated by the fluid nature of the service provider landscape. Now it is the emergence of higher bandwidth networks. For most of what I do on the mobile device a solid 3G connection gets the job done. But if I could get 2-10x the bandwidth via HSPA+ or LTE then should I wait until the right Provider/Device/Price comes along on one of those networks?
Because of the financial impact of disengaging my family from 3 two year contracts on AT&T my easiest option would be to stay with them and face a simpler choice:

  1. Wait until this September when I am eligible for an upgrade discount and jump on the Captivate and use 3G
  2. Wait until AT&T roles out HSPA+ in early 2011 and hope there is a nice Android device able to take advantage of that network.
  3. Wait until AT&T roles out LTE in 2011-12 and hope there is a nice Android device (by then it will have a 2GHz processor and an mega-mega pixel camera) able to take advantage of that network.

Obviously these three choices represent the constant agony of the early adopter... whatever is in my hand is obsolete and the nice new shiny gadget is always over the horizon. BUT that feeling is tempered by my frugal side so that I tend to upgrade about every two years. I am tending towards option 2 with some caveats:

  • Since AT&T has not announced any concrete steps or devices towards HSPA+ (unlike T-mobile) I am afraid early 2011 could easily become late 2011.
  • With AT&T moving off of an unlimited data plan, will HSPA+ carry a double premium? First a higher $/byte charge then 3G, and second, my natural tendency to play with the technology and do video conferencing on the device until my first monthly bill comes in (Ouch!).


Decisions Decisions.
What would you do?

Wednesday, March 3, 2010

Agile Team Dynamics



Last night at the Agile RTP meeting we had Don Gray speak to us on Agile Team Dynamics.



The meeting was broken down to 5 teams with each team having approximately 10 people. One person was designated as the Product Owner. Each team was given a bag of supplies and an instruction sheet for the Product Owner to give requirements to the team. My team got a bag of colored paper, tape, and pipe cleaners.

We were told to construct something that was:
  • Artistic
  • Tall
  • Sturdy

We were given 20 minutes for the exercise. The picture shows what we created.
Then Don asked each of use to take some post-its and write down what we had contributed to the exercise.

I think my set was:
  • Contributed vision of "Eiffel Tower"
  • Started rolling paper into tubes
  • Worked in team of two specialists Roller + Taper to create legs
  • Asked other team to give us balloons
Then Don told us about the Kantor Four Player Model.

During the exercise, each of the team members was contributing in one or more of the four interactions. Don asked us to classify each of our contributions. I had thought most of mine fell into the "move" category. In fact, among all the participants, the vast majority of actions were classified as either move or follow. A few Bystand and almost no Oppose.

Don mentioned that in an Agile team setup the Scrum Master should be a bystander, allowing a self managing team to do most of the Mover type activities. I made the observation that a classic problem with many agile teams is that the Scrum Master (often being an old project manager) can not help but try to take over and "move" the sprint along. Don agreed and gave some war stories from his own experience on how this can be a problem.

Other comments from the audience pointed out that the team dynamics in our 20 minute exercise did not realistically compare with a real project having team members familiar with each other and with the political / cultural context of the company surrounding them.

My main take away for the night was that in any healthy development teams these four players can each contribute something of value and that all team members should accept the presence of these roles in the team dynamics.

Wednesday, February 17, 2010

Meeting Fred Brooks


Last night I met Fred Brooks.
I was moderating a panel discussion of our local chapter of the IEEE Computer Society. It was about "Practical Software Development".
Afterwards, an older gentleman walked up to sign our registration sheet and apologized for joining late. I glanced down and the name was "Fred Brooks".
I had this flashback to 1977 when I was a young software developer. Two years out of school with a shiny new Masters in Computer Science. I was just starting to call myself a Software Engineer and I was in this meeting with about ten older, wiser, non-programming, engineers who did not understand why my software was on the critical path and why I had just announced a slip in schedule. The Project Manager ( a terrifyingly gruff Sargent type as I remember) suggested that we add a couple of other programmers to the team to help get me out of the ditch. I can remember holding up my copy of The Mythical Man Month and saying "I think that adding more people to a late project will only make it latter. Let me tell you why".
This was one of those pivotal moments in my career. The ideas in that book helped me earn the respect of the Electrical Engineers, Mechanical Engineers, Industrial Engineers, etc who surrounded me but did not understand my profession. Along with books like "Software Engineering Economics", and "Structured Analysis and System Specification", the "Mythical Man Month", became the core of my Software Engineering.

So, thanks Dr. Brooks.

Saturday, January 16, 2010

a Sojourn in the Clouds

I have been learning IBM's Mashup Center, demoing to clients, and weaving it into my Web2.0 briefing as an emerging technology. I am able to do this in the Lotus Greenhouse as a free service from IBM. Recently IBM released version 2.0 of the product and after a product webinar I was ready to try the new/improved product. Alas, the greenhouse only had version 1 (that has just been remedied). Anxious to get going I fired notes off to people in IBM asking when I would get the new shiny version. I then stumbled on the fact that IBM had v2.0 available on Amazon's EC2 and if one was only using it for developer investigation (compared to a mashup for multiple users) then the product was FREE.
IBM provided a getting started video and pdf so off I went. I would listen to the video for a bit and then try to repeat the steps. There are a lot of things to do up in Amazon Web Services to get started and several freeware programs one needs to download in order to get things to work. I got stuck several times and finally resorted to reading the pdf line by line and carefully doing EXACTLY what was written. I never got my Ultra VNC to work but was able to use my Firefox browser to link directly to the Mashup Center Instance running on EC2.
For the configuration I had requested (Linux with 4GB storage) I was paying Amazon about $1.75 for each 24 hour period. I left it on for a few days while I developed and demoed for a client and was then able to terminate my instance.
If I did not have access to Lotus Greenhouse, and I was someone wanting to play around with a program like Mashup Center then using a infrastructure cloud is a good way to do it. And how do I like IBM's Mashup Center? Let me build up some more examples and then I will post a blog with my experiences.

Thursday, December 3, 2009

a mobile device dilemma

The exclusive deals that device manufacturers are making with service providers will ultimately cause a family crisis for me.
Today my family of three is using an AT&T unlimited family plan. On that plan we have three devices:
Blackberry Bold - me
iPhone 3GS - wife
iPhone - daughter

I picked the Blackberry last year when my old one died. It was not my ideal choice. I really wanted to jump on the Android bandwagon. I am an avid Google user and wanted to have a state-of-the-art experience of integration. Alas, I did not do so at the time because:
1. AT&T did not have an Android device (I suspect they may never have one).
2. The T-mobile HTC G1 was not a game changing device

However, at that time my wife/daughter were using dumber devices mainly with voice/texting capabilities and I probably could have migrated the family over to T-mobile.

BUT since I got my Blackberry (which has OK Google apps), my wife/daughter became iFans. At this point, I would have to pry the iPhone from my wife's cold dead hand.

So you see my dilemma. At some point there will be this wonderful, amazing device (like an HTC HD2 running Android 3.x) on a service provider like Verizon and I will either have to ignore it, convince my family to abandon their iPhones, or split the family unit into separate accounts ($$$).

I had hopes that Google's push for an open network would have worked out. Being able to purchase any device and activate on any network (radio compatibility assumed) would make this little family crisis in the making disappear.

Wednesday, December 2, 2009

What is the perfect Agile Tool? - It Depends.

Within the Agile/Scrum/XP community there is a love/hate relationship with tools that support the development process. I used to call these Computer Aided Software Engineering (CASE) tools but that term has fallen out of favor. CASE is more associated with the waterfall wold the the Agile Manefesto revolted against.  There is one camp of Agilistas that will only use 3x5 index cards posted on a board in a war room. And even when considering tooling, the complexity of the tool is a major discussion point.
Last night, I attended an agile tools shootout hosted by the aRTP group. We looked at the following tools:
Zen
Cucumber
PivotalTracker
Rally
ScrumWorks Pro
Microsoft Team System
IBM Rational Team Concert
Jira/Greenhopper

Actually, the demos were given in two separate rooms and I was only able to personally see the Zen, PivotalTracker, ScrumWorks Pro, and Rational demos. From the demos and what I could see from their web sites I would broadly seperate the Microsoft and IBM tools from the rest and put them into the more complex category. However, this is because with both of these tools the vendors are attempting to cover the full development cycle and making sure at detailed design and coding they have things covered. For example, Team Concert was demoed as an Eclipse plugin with source code control, build management, real time notifications, project management features all enabled
Other tools, such as Zen and PivotalTracker tended to be more like electronic 3x5 cards with electronic boards. They did offer the advantage over a manual system of being able to automatically calculate burn down and other statistics.
In the middle of the complexity spectrum were Rally and ScrumWorks Pro because they added more project management features and the ability to integrate with other tools.

So which would I pick? Like any good consultant the answer is "Depends".

It depends on the size and complexity of the organization using the tool.
It depends on the target architecture and technologies used (e.g. one tool I did not classify above is JIRA/Grasshopper which is specifically used for Ruby development)
It depends on the level of contol over tool content needed (e.g. several tools were SaaS with concerns over security)
It depends on the sophistication of the developers.
It depends on the level of formality required of the process (e.g. if federal certification of the software is required then more traceability and reporting will be needed)
It depends on the risk accommodation of the users (Want to go with a small flexible rapidly changing tool/company OR stick with a slowly moving but more stable large vendor)

I did enjoy the exposure to the tools and we will be holding another shootout in the future.