My Latest Toy - AT&T Tilt

I finally found a sufficient convergence device to entice me to make the leap and integrate my PDA, GPS, camera, and phone. The AT&T Tilt 9825 (htc Kaiser) is an incredible device that embodies all of these in a similar (smaller) form factor of my aging Palm M130 PDA. It's far smaller than my aging Kodak DC camera (1.2mp) with a 3mp auto-focus and 10x digital zoom sensor. It has a bult-in GPS receiver and with Window Mobile 6 it runs MapTech mobile to give me all my marine and land navigational maps and features of a GPS device. The 2.8" display is clear and sufficient size to interact with applications. It has a touch-screen keypad for use of a phone or you can slide and tilt out the keypad with large buttons. When you do, the screen rotates and you can use it in your hands with thumbs or set it on a surface and use multiple fingers. The phone sounds great as a handheld, works with my bluetooth headset, and has a speakerphone (although the speakerphone in my old Nextel Motorola still sounded better in the middle of a conference room table).

I can use this as an mp3 player and can get streaming video that works quite well. Although I'm paying $40 per month for broadband instead of the $15 media access, the convenience is great. It support 802.11b/g WiFi and world-ready broadband. It synchronizes with Outlook contacts as my prior phone, but has a richer integration. I get email on this device from my earthlink account (leaving the email on the server), and then suck down the email on my notebook. I am able to IM in my MSN, AIM, or Yahoo accounts with ease, although I wish I had Trillian mobile to aggregate them.

It has a push-to-talk feature that I miss from my Nextel phone, but until I have other members of my family or friends with that feature it is shelf-ware for me for now.

My biggest fear I had was windows crashing in a call. Friends of mine have had this happen to them on the Treo and other devices. I bought this on October 5th (first day released in the US) and I am happy to say that this has not happened to me (yet).

New England Agile Bazaar October Meeting

I attended the Agile Bazaar meeting this month at Tufts University. This was a panel discussion format moderated by Ron Morsicato with an open format including a series of questions crafted by Ron that were geared towards adoption of agile practices. The panelists:

• Don Roby, Cyrus Innovation. A developer of highly usable solutions with a proven blend of Agile programming techniques, user-centered design, and deep insight derived from the firm's financial services experience.
• Brad Kain, Quoin, Inc. A builder of sophisticated applications for media, publishing, retail, finance, life sciences, and other industries.
• Giora Morein, BigVisible Solutions. A premiere provider of Agile enablement, training and software solutions.

There seemed to be consensus that agile practices are most popular in both small startup companies (especially in SaaS) and large financial services companies (like Fidelity Investments). The reason small startups are adopting embracing these practices is to address the rapid pace and reduction of technical debt. It is easier for these organizations to adopt agile because they can start fresh with this approach and don't have the cultural overhead to limit the pace of change. The larger financial services organizations are adopting agile to address the management of many small projects as opposed to most service and product teams. There was a discussion about hybrid methologies and the experience the panelists have had in the field. Most organizations to not practice a specific methology but a collection of practices, and then give the collection a name specific to their organization.

• Scrum or similar methods that describe the way in which projects are managed at the detail level, with a product owner.
• Some subset of XP development practices, especially TDD (test driven development) - a lot of resistence to peer programming - very few are using the notion of an on-site customer.
• Managing the business with CMMI or similar infrastucture framework is common with larger organizations, incuding phases and gates. There is evidence that CMMI is compatible with agile project management practices and certainly with XP coding practices.

Organizations looking to make the change to an agile lifecycle have common things they don't want to let go of. For example, building narrow funtionality (through all tiers) and delivering often, logging and tracking all defects found after a coding phase, constant communication within a team, and the dreaded exposure of peer programming. Architects of web services need to have a vision for the tiers needed for the service, but unlike a waterfall approach where you can complete a majority of a tier before moving on the the next, only to portion of each tier relevent to a specific feature in scope for the iteration is developed. The challenge of the change agent is to let them use familiar tools in a different way that moves them to changing the practices. For example, working with QE at the time of development and treating most defects loosely as part of the development exercise, and only escaping (after closing a story) defects can be logged and tracked as before.

Offshore, nearshore, and collocated teams were discussed. There is contention with many companies as they seek to reduce overhead by utilizing outsourced development services. Most of the companies in India, Eastern Europe, and Canada move people from project to project often, keeping their signature engineers on strategically high profile projects, especially to win new business. They tend to resist agile project managment approaches and have cultural challenges with sharing perceived bad news. Giora talked about a survey he conducted for a company with teams locally, India, and Canada, which had a series of projects together. This survey included both quatitative and qualitative questions about their experiences. 83% said the most successful projects included personnel spending time in the other locations, suggesting that face time really makes a difference in the success of a project. These respondents also said that they preferred to be in the same time zone. However, Giora mentioned that one of the most successful projects included members of the team in India spending time in the local project teams and having development in both time zones had the effect of 18 hour days. There was no evidence of increased productivity though. There was also talk about setting up your own team in India if you want to use agile practices. We did not seem to come to any conclusions on making what makes an outsourced project work with agile.

http://agilebazaar.org
http://groups.yahoo.com/group/AgileBazaar

Agile Peak Performance in Early Startups

As a long distance track running in high school and college, and later as a Navy Deep Sea Diver (special forces), I've experienced how keeping an aggressive stride goes beyond tiring and gets you into an momentum I call "automatic mode." This is when you achieve peak performance and you can go far beyond what the mind will limit you to otherwise. The military calls this "mind over matter" and is a real phenomenon. My Mother-In-Law trained for the Olympics in swimming and calls this point of going beyond exhaustion "the wall". The key to getting into this state is to establish a strong stride and keep repeating that stride tirelessly, despite changes in surroundings. What I found in the Navy, and as I worked as a life guard on an ocean beach one summer, the stride can include how you deal with changes in your environment, changing the pace and still keep the stride. We would run in knee deep water, soft sand, hard sand, marsh grass, etc. As we moved between these conditions we would change the pace but keep the stride.

I've only experienced peak performance results a few times in software development projects, but it can be achieved. The approach is to train the team for the inevitability that we may have to turn sharply in strategy and tactics. This enables the team to operate in new directions relatively quickly without breaking stride. If you don't build the team with this inevitability in mind and train for it, the team is easily rattled and breaks stride with every change, unable to achieve peak performance and can result in productivity erosion.

Agile software development lifecycles profess that projects are broken down into time-boxed iterations with prioritized work items, and software is delivered in demonstratable or releasable condition at the end of each iteration. The iteration is the stride of the team. The team does not like to break it's stride. So, account for the 'agility' of dealing with sharp changes in project direction. Change the work (pace) but preserve the current iteration cycle (stride). By putting in place best practices for planning and communicating this change as part of a subsequent iteration, the team can embrace the sharp changes as part of the process and not a disruption.

Achieving peak performance in an early startup requires a process that is focused on iterations within a project lifecycle that embraces responses to user feedback, changes in the marketplace, business strategy, technological discoveries, and other environmental conditions that make sense to respond to quickly. While planning these changes take into account the costs to the project and the team. There are research spikes (specific time allocated to research a topic enough to plan work), architectural impact, adjusting expectations in project commitments, changes in task priorities, and human factors. It is important to acknowledge these impacts and plan accordingly.

Scrappy Executive

I was recently described by a Venture Capital Partner as "scrappy" and that I can add more value to an early start-up than a later stage startup. I was puzzled by what he meant by that and asked a CEO from one of his portfolio companies who knew this VC Partner well over the last 25 years. This CEO said "scrappy is an attribute that means you do what's needed to get the job done, not focused on managing your title, a street fighter."

I guess this sounds like me. I always thought of me as a the steady guy who keeps his cool under pressure and instills best practice processes to steer the ship through all weather. But this analysis of my past 15 years of management in high technology industries illustrates a different view through a different colored lens. I've always been adaptive to changing needs in an organization and on many occasions stepped in or asked someone to step in to fill gaps that exist, even if they transcend the defined title or role.

I spent the last year and a half making the transition from a waterfall software development lifecycle to an agile one. There are a several tenants of an agile lifecycle that make this work, yet in an early startup sometimes you have to break in the process to adapt to a sudden need of the organization. I understand the value of not disrupting the stride of the Engineering organization too often or you wear out your crew. However, if you only work in rigid processes without the flexibility to adapt quickly you may not win enough battles to keep in the war and reach your goals.

Interesting reading about the Scrappy Executive... http://www.founderblog.com/2007/01/so-you-need-to-develop-product.html

http://www.happyabout.info/wiki/Scrappy