Gary Allison's Leadership Blog

Its been many years since I have truly been blown away by a new technology, but it happened today. Google’s GWT is a game changing technology. Open sourced by Google, GWT enables UI development in Java then compiling the application to compressed, optimized javascript to generate Web 2.0 native browser applications. The advantages over JavaScript are nothing less than staggering. Use your favorite Java IDE, with full support of the Java productivity advantages (code completion, type checking, class exploration, etc), and then debug it using your powerful Java debugger.

But wait there’s more: GWT includes a browser
Continue Reading »

Tomorrow is the last day of the AJAX World conference here in NYC. Aside from running into my old friend Fuaat, it has been a remarkable few days. It is very exciting to see the rapid progress of the client-side browser toolkits in the form of the AJAX frameworks coming to fruition. Ironic though at the same time that these technologies seem like throw backs to the earliest days of developing on Windows – little documentation, no IDE, and very basic debugging. In short, there’s no doubt where its headed, but the developers will be tearing their hair out to get there.

 Its exciting to see the promise of AJAX on mobile devices and how these applications hold the promise of being able to have common code across platforms and devices. Clearly, applications must be developed for an audience – and mobile audiences often want something different. Still, I can’t help but to think, even my very capable WM5 device with IE lacks an appreciable support for Javascript. There seems to be no real relief in the near term to give us ubiquitous mobile development. J2ME still comes the closest today. I’ve been spending considerable time thinking about the mobile space lately. It seems clear that the number of devices coupled with the evolution of data services and lack of the “killer app” provides a greenfield of opportunity.

Found this entry on Guy’s Blog and wanted to cite this here. You have to love what you do. Without passion, great success is hard to come by. An entrepreneur will have tough times if he or she isn’t passionate about what they’re doing. People who love what they’re doing don’t give up. It’s never even a consideration. It’s a pretty simple formula.

Talking about requirements makes people’s eyes glaze over, so lets ask a more poignant question. What market are we trying to win? This focuses our vision in a much more effective way. The first deadly sin of software projects lies in not asking this question. Requirements management is a fundamental necessity in software development. Changing requirements causes obvious schedule impacts but has more subtle impacts in quality of the product and maintainability of the architecture. But, lets face it, few systems worth building have all their requirements known up front. There is always some element of discovery as the business matures, as early customers give feedback, as new deals are brought to the table.

The deadly mistake that can make your software project, and even the company, fail is a lack of focus on precisely how this product will win in the market. To answer this question, this presumes we can answer these questions of precisely which market are we in, who are our competitors, what are the major technology movements in the market, how will the product be marketed and sold, how should it be priced, and who will buy it. Even if you are the “technology” guy in charge of the software project, you need to know the answers to these questions because it affects in important ways the requirements of the system.   Most companies start out with a pretty firm grip on how they plan to win in the market. What trips them up time and again is not realizing the answers are changing. The deadly sin here is that if the answers to any one of the questions above change over time, they can dramatically affect your requirements and ultimately lead to the failure of your software project (and the company).  These changes can take place very quickly and very subtly in a small project. For example, selling a product into a new channel or to a new type of customer can quickly mushroom into a set of new requirements that can crush your existing commitments. To mitigate this, it is essential that the product management team and development leaders be integrated into the sales processes to gain visibility into these opportunities so they can anticipate new requirements as early as possible. This can be difficult as everyone is excited about the new customer or opportunity, and many times it becomes a “peeling the onion” exercise. At first, it seems that the new customer only needs a small change to the product, and then another, and then another. These changes are driven because they are fundamentally a different customer than has ever purchased before. Recognizing this difference is crucial.   

Another good example I’ve encountered many times is the difference between reseller and direct customers. Resellers are extremely valuable sales channels, but have very different requirements in products and billing than do direct customers. It is important to recognize and understand these differences up front. A reseller may want to embed your product in theirs or rebrand your service / web site. They often want to hide the visible aspects of your product because they want to present only their brand to the customer. These features must be factored in up front as they are very expensive to retrofit.

Finally, the new customer may not necessarily drive changes into your core product, but rather may require you to drive changes into your core processes. For example, a telco customer may have very long cycles between applying updates and may require different service levels that your other customers. Each of these have a cost component associated. The longer upgrade cycles may mean you have to keep alive older branches of source code alive for emergency patching, along with test environments that support that branch. These kinds of patches can be very expensive both to you and the customer. Also, you may have to go through longer or additional test cycles for the releases that go to these customers in an effort to avoid these costs.

In conclusion, asking “What market are we trying to win” means understanding the answer to the question and measuring each sales success against that answer. If the sale represents a fundamental change to this answer, then take the steps to deliberately plan for the product and process changes necessary to deliver on the opportunity.

In our examination of reasons why software projects fail, we start with a few basic assumptions. These seven deadly sins of software development assume that many of the fundamentals are in place: the team is staffed with trained experienced developers, you have a modern source code control system, build processes, test methodologies and automation, bug tracking system, project management systems, etc. In essence, we are assuming at least a CMM Level 2 team – without at least this level of process maturity, there are many other opportunities for the project to fail. This series of short articles focuses on the set of issues that sneak up on experienced software developers and development managers. They are seemingly common issues, but can surface in subtle and surprising ways while teams are heads down implementing a project. We’ll examine some examples along the way as well. Although we may have to change a few names, they will be real examples drawn from experience.

Its been a very busy forth quarter rounding out 2006. Business travel has taken me to South America twice, we’ve been working on closing a number of deals, and December saw the largest number of products all go GA ever in a month at Simdesk. All these are great reasons for not keeping up with the blog, but its time to get back to it.In 2007, I’m planning to write a series of articles on Software Development revolving around common sense knowledge every leader of a project should know. Though I place them in the realm of common sense, I’ve also seen them sink projects over and over again for those that are unaware (or just too busy to notice). Every series like this needs a catchy title, but I’m afraid we’re out of luck. We’re going to call this one “The 7 Deadly Sins of Software Projects”. If you’re in the business, I’ll wager you’ve either seen a few of these or maybe even been guilty yourself. Its easy to do because they can sneak up on you. Stay tuned.

The move to distributed teams is clear and overdue, whether its due to telecommuting, geographically dispersed offices, or just staying in touch on the road. So, perhaps it would be useful for this entry if we focus on tools and techniques needed to really make distributed teams productive. First things first, to make this work you first have to have the right supporting processes and supportive management. The purpose of this blog though is to focus on the technology needed to make this work. 

SKYPE Skype is the best thing since sliced bread – in fact, it slices, it dices, it chops, it hops, it smashes watermelons. The key benefit (and limitation) to Skype is its peer to peer communications architecture. This means, that unlike other services, the quality of the video, conference, etc, doesnt degrade because a server somewhere is busy. Ive used Skype to call all over the world and across town, it just works. Heres the skinny: Calls: Calls directly to other skype users over the PC are free, anywhere in the world. Calls to phone numbers are referred to as “SkypeOut”. These cost a few cents a minute internationally, and are free in the US through the end of the year (2006). I bought my first Skype account in Tokyo 2 years ago for 10 euros and still havent depleted it. Youll want a comfortable headset to use while talking – Logitech Orbit is tops. Lets you pan, has automatic face tracking, great low light sensitivity, and it looks cool. For portability, the Logitech Notebook Pro is hard to beat. It has the important built in mic, clips to your notebook LCD, great resolution and low light sensitivity, and a nice travel case is included. Note that video seems to be Windows only right now.

Video conferencing: With Skype, forget it. Skype only supports video in a point-to-point call presently. Youll need to use something more capable (more expensive) like webex.  Conference calling: Skype supports conference calls of up to 5 people. So, it is fairly low end, but many times 5 is enough. There is a new Skype Polycom speakerphone for Skype that plugs into your USB port. Ive ordered on and cant wait for it to get here. Polycom has an impeccable reputation for speakerphones, so I have high expectations. And, like everything else about Skype, it is cool.  Chat: Skype has built in IM. You can IM while being on a call.  Desktop sharing: Some very bright Japanese fellow has built a plugin for Skype that uses the video capabilities of Skype to let other users see your desktop. This is immensely useful in meetings where you need to review a document, build a plan, share a presentation, etc. The resolution is great – much better than what Ive seen with other approaches, probably because it is peer-to-peer. Once you install Skype, you can click here to get the plugin. (Windows only).  Note: since video is only point-to-point, so is desktop sharing. That is, you cant at this time have a conference call and share your desktop. There are other approaches like Unyte, but I havent yet heard positive things about them. However, the technology is maturing fast and it will no doubt improve.  Skypecasts: this is more of a broadcast service for Skype users. Since anyone can join in and hear, youd need to use this feature of Skype as appropriate.
Hope this is of help!

Ok, so your want to startup or install self-directed teams.(see a previous post on change). As with any change, this is a big challenge and there is no guarantee that it will be accepted completely by the team. Some will be uncomfortable with accepting accountability, a strong Scrum master will be needed, and some just don’t like having to fit within a structured process. In our adoption of Scrum, a few things have helped us gain acceptance:

Training We are fortunate to have a certified Scrum Master on board who has trained the whole team. A full day of training was invested in every member of the team. Additional training is needed for Scrum Masters because their execution needs to be effortless for the process to flow.Executive Buy-in and Support All levels of management must support the process. The integrity of Sprint content must be held in tact for the process to work. During the sprint, business needs sometimes require us to trade Sprint tasks for backlog items, but the integrity is maintained if the team signs up to the change.Strong Leads that are Willing to take on Scrum Master role this process of self directed team still requires someone on the team to drive the process. In my experience, a strong and effective lead developer is one of the most rare and valuable commodities in the Software Engineering world.In short, the only mistake we have made with Scrum is not more quickly adopting the process everywhere in the team. At the end of the day, team success is the greatest motivator for this or any other change.

About 18 months ago, we adopted a self-directed process called Scrum in part of our development team – the part that focuses on end user applications.  Most of the team was a little apprehensive, but they are solid folks and they put it in action. 

 

Recently, we made the move to transition the whole team to Scrum, something I should have done long ago.  Initially, I believed that complex pieces of server-side software had longer life cycles, longer testing cycles, and therefore perhaps the Scrum process wasn’t a good fit.  I was wrong.  What we could have seen are the same benefits on the server-side that we’ve seen on the client.  So, now we are rolling it out team-wide.  So what are some of those benefits?

 

The most important benefit is the placing of ownership where it needs to be – at the team level and ultimately at the individual level.  Whether they are taking a turn at Scrum Master, or just part of the team, each person owns reporting on their progress, the whole team owns the sprint backlog delivery, and has the power to say no to things not in the Sprint.

 

Team planning and ownership of the deliverable by the team – each Sprint (we use a month), the team signs up to a number of developer days, test days, and Tech writing days available.  We estimate the line items in the backlog and allocate the available days.  Its all team driven, and as such, the team owns the plan for the Sprint delivery.  In addition, the team demonstrates the deliverable from last Sprint – a powerful way for them to show accomplishments.

 

Peer-to-peer accountability – another significant benefit.  With Scrum, there is no place to hide from missed deliverables, poor quality, and lack of skill.  Any team member can take any item of the backlog and work on any piece of the system. As such, Scrum breaks down artificial barriers.  And, with daily scrum meetings on what was accomplished and planned for each day, it is pretty easy to tell if someone isn’t pulling their weight.

 

Forcing the business to define priorities – Scrum forces a booked plan, reconciled to business priorities at the beginning of each Sprint, monthly for us.  It provides a systematic way to pull in all the business inputs (sales, marketing, support, et al) into the planning process – and enforces that this is there only chance to get input into the development cycle until next Sprint. (Not really of course, but it does force the conversation.)

 next Blog…. Success Criteria for Adoption of Scrum

The Second Law of Software Dynamics:  shipping software is a commitment, not an event.

Customers generally expect once they have adopted your software or service that you are going to continue to develop it, service it, respond to their requests for tweaks, and keep up with competitive forces.  In short, they made a commitment (time, dollars, training, or perhaps a key part of their business) to you, and they are expecting the same.

Yes, this applies to Web 2.0, SAS, and whatever the new paradigm of the day is. It is all just software in different cloth. It may be delivered in a different way, or have a new business model attached, but the commitment remains the same.

(What is the First Law?  Given any non-trivial system, as long as you test software, you continue to find bugs. I need to blog on when is enough, enough someday soon)

Do you watch Dirty Jobs on Discovery Channel? I have to admit, I think I’m hooked on this show. It might be the deadpan delivery of Mike Rowe, or could it be somewhat deeper? As a leader in software development, sometimes you can feel like the star in the PigWrangler episode (and no developers are not pigs). Bear with me as I take metaphorical license… Sometimes you have an uncooperative environment, and after the product goes to market, well, theres just a lot of poo to clean up. And, boy is there poo! Well, you’d just have to see the episode.

 In fact, the poo theme seems to run through many of the Dirty Jobs episodes. At the end of the day, in the midst of all the poo, there is a successful business. Art imitates life again.  In software development, there is more than a fair share of poo – changing requirements,customer promises of features that don’t exist, missed sales targets, layoffs, inept people at all levels (yes executive management too), pass-the-buckers, slackers, hackers, you name it. Face it – on any given day, we are all capable of poo. Still, out of all this comes innovation and products that people use every day. For many of us, this makes the job worthwhile, even when it’s a Dirty Job.

Lately, I’ve been interviewing to fill an open management position. Clearly these are positions of the utmost importance in that a great hire will push the team farther and higher, while a bad hire can be disastrous.

I’ve put together some question (but not all in case you’re next) I’ve used, and hope they are of help to you.What does a manger do? This will generate lots of conversation. Looking beyond the technical to an understanding of the business environment willingness to get up close with a customer and truly understand their need ability to ask the hard questions, whether with marketing/sales, or with software engineers. Above all someone who embodies characteristics of servant leadership. How do you distinguish between top performers and above average performers? What are some examples of how you have rewarded these top performers? Looking for bonuses, creative recognition, and monetary recognition that clearly separates the top performers.What has been your highest performing team? What made them that way? Looking for people who give credit rather than take credit.What has been the most difficult situation you’ve encountered in mgmt? What would you do different about it if you relived it today? Amazing what you can learn here. If they can’t think of one, they are not being honest or don’t have any real world experience!Have you ever needed to manage an employee out of the business for performance reasons? Describe this process.What gets you excited?What would your goals be for the first week on the job? (I know it is such a stock question, but its still a good one).What agile development processes have you used? Where were they successful and where were there problems?What qualities do you look for when you hire? (what I’d like to hear is: willingness to go the extra mile (commitment), examples of driving issues/opportunities all the way through closure, even outside of normal channels (ownership), demonstrated ability to innovate, someone that works well within a team and demonstrates a fair amount of personal leadership.So, how long have you had that wart? (just seeing if you are paying attention)

It just amazes me the creative and inventive ways people use to avoid goal setting.    Believe me, I’ve seen it all.  When it comes right down to it, most people would just rather not be held accountable.  And, to some degree, this is understandable.  Life is full of the unexpected – and software is a great example.  There are new technologies, new toolkits, new platforms, and just plain new stuff all the time!  Who can say in any degree of certainty, how long something will take.  If you are truly certain, then you’re probably not working on anything very interesting.

But, beware of the one who continually avoids commitment.  Enough said.

About measurement. … A goal is only worthwhile if you measure, reward, and learn from it.  If you are setting goals using a process like SCRUM, goal measurement is fairly clear.  I love this process because it provides daily feedback and peer-to-peer accountability of the type not possible to deliver hierarchically from management.  It just means so much more coming from your comrades in arms. At the organizational level, I’m a huge proponent of setting high level vision goals at a functional level each quarter of things that need to get done, and then validating these with each team.  Once each team develops the detailed goals supporting the vision goals, we can validate they’re achievable, refine them, and make them more specific. This reminds me, sometime I really need to blog on what it is like to develop software for Japanese customers.  I wonder… can my career survive that much honesty…. 

Do you see a lot of conflicts at work, people working at cross purposes, even though at their heart, they have a common desire for success??? In my view, many times this is due to organizations not having a common vision, common sets of priorities, and measurable objectives. Or, perhaps they think they have this common vision, but until they go through the exercise of writing it down, they don’t realize?how far apart they are.

 

Each quarter, it’s just required we agree on a set of objectives for the team that can serve as a guidepost through the quarter. These are not set as a absolute iron-clad whipping post list, but rather as a set of important deliverables which the team commits to achieve. For software,a quarterly set of deliverables is a list of external commitments that must be supported by project plans and processes that deliver during the quarter.

 

Goal and objective setting is a somewhat tedious process that I’ve yet to see someone actually enjoy. Its just not fun, but anytime we skip this step in the course of “just having too much on the plate”, we inevitibly pay the a much higher price.

 

More on Goal measurement next Blog.

 

Now, back to that goal setting for next quarter….

A bit over a week ago, I had the privilege of attending this congress in Austin.  Security was very tight – APD on horseback, Harley, and on foot. It was an exciting event from Austin – attendees from over 84 countries meeting to discuss topic from economic development to trends in muni wi-fi.

 

It was however Paul Otellinis’ keynote that reached me perhaps the most.  He gave clear evidence that the digital divide is real and that it correlates with income level.  Over 1 billion people on earth make less than $1K per year.  4.7B make between 1K and 25K.  The remaining 800K make > $25K a year.  Accessibility to PC technology is pervasive at the top of this pyramid, and non existent at the bottom.  (Likely the authors of freakonmics could tear this apart).

 

Point is there are a few companies like intel that are investing Billions of dollars in working to bridge this divide.  It is a key mission of the team at Simdesk as well.  These initiatives aim at bringing access to technology, and therefore access to information and education to billions of people around the planet.  Through education comes opportunity and economic development.  This is certainly an exciting effort to be a part of.

 The larger question on my mind: could this really grow over time to bridge the strife between people all over the world?  Could the connectivity that the next generation of the internet will bring serve to bring us to a point of being one global civilization in 100 years?  I think back to Dan Simmons’ Hyperion, an amazing work of fiction in 1989 foretold the internet in a way that few can foresee even today – an existence where anyone can “jack in” wirelessly and access information on any topic.  With the advent now of muni wi-fi and wimax projects, the writings now are almost prophetic.