Agile Project Management Tune-up

The last MassTLC meeting in July on “Taking your Agile Development to the Next Level – Best Practices and Methodologies” triggered all kind of thoughts; for example:image

  • lingo is different by the substance is the same
  • finally software engineering get’s to adopt practices that have been applied in other practices
  • the real problem of resource overloading has not been solved!

Coming from the world of the Mythical Man-Month and The Soul of a New Machine but also practicing for more than two-decades project management following the warnings of the Critical Chain  and the Goal with the theory of Constraints (by Goldratt and others) led me to write this blog. The basic idea is the triangle of trade-offs (to the right).

The goal of the Product Development Organization is simple: Deliver the highest business value in the shortest time. Notice that business value has replaced the best quality or excellent product or most customer desirable (ala Good to Great). Notice also that the shortest time has replaced the lowest cost or other variations.

The challenge: But how we do so in a repeatable fashion (i.e. applying development processes) without discouraging new initiatives and innovation in the organization? Before we answer this question, let’s summarize the state-of-the art in processes.

Summary of Agile Processes

There is plenty of literature in this matter; if you have not seen the spectacular work by Mike Cohn at Mountain Goat Software, you owe to review his open presentations. This is only a repeat of the high level bullets from Mike:

  • Agile Processes
    • Scrum
    • Extreme Programming (XP)
    • Kaban
    • Lean

  • Semi-Agile Processes
    • Feature-Driven Dev (FDD)
    • Unified Process
    • OpenUP

  • Scrum
    • Roles
      • Product Owner (what/order)
      • Scrum Master (process coach)
      • Teams 7-9
      • Fixed duration sprints (2-4w)
    • Ceremonies
      • Sprint Planning
      • Sprint review
      • Sprint retrospective
      • Daily Scrum
    • Artifacts
      • Product Backlog
      • Sprint backlog
      • Burn-down charts

But how do the above processes scale to projects above 10 developers, non-collocated? How do we deal with the Flat World challenge: use Scrum of Scrums; use the Scrum of Scrums or Scrums; create Communities of Practices, etc. Again, these topics are well described in the literature and I would omit for brevity.

Trade-offs

For projects beyond “just software”, i.e. projects involving hardware development, systems engineering, embedded coding, user interfaces, device drivers, application software, all of them to be fully synchronized and with predictable deliveries, the senior manager is faced with the following tradeoffs:

 

Optimize

Compromise

image

TIME TO MARKET (When): Fastest possible way

Set of features (What): Only the absolutely needed
Departmental efficiencies (How Much): External help (consultants)

image

EFFICIENCIES (How Much): Most cost effective way

Delivery time (When)
Sequence of features will change (What)

image

PREDICTABILITY (What+When)

  • Clear forecast of “what” (i.e features) and
  • “when” (i.e. release date) will be delivered

Delivery time and features will vary

  • but will be known at least 30-60 days in advance
  • active customer management and feature trade-off.

image

INNOVATION & BREAK-THROUGHS

  • Something never thought or done before
  • Long term business and IP benefit

Time-to-market (When)
Sequence of features (What)

And because “our Public Company bosses” really care about Predictability and Fastest Time To Market (ignoring for this quarter the Efficiencies), we should think about the Conditions for Predictability. Here are my thoughts on this matter.

Less Predictable

Managed

Very Predictable

Team co-location

Distributed

Can be distributed for medium TTM

Required for fastest TTM
Good to have for medium TTM

Dedicated Team Members (one project at a time)

Not required

Only 20% interruptions

Required 100% dedication

Integration of Eng Team with Prod Mgmt Team

Separate orgs:  dynamically changing specs and priorities

Separate orgs:
medium TTM if what and when can be compromised.

Separate orgs: the what is fixed

Integrated orgs: highest efficiency and scalability

Technical Aspects

No past experience or know how

Have the expertise

Have done similar before

Metrics

No process and no business can run with some level of quantitative metrics of performance. This is especially relevant to high-performance teams. Here is an example of oversimplified metrics:

  • Fixed TTM projects. Example: released within 2-weeks from forecasted date; assumes stable+dedicated resources and fixed features
  • Fixed Features projects. Example: released within 4-6 weeks from forecasted date; assumes stable resources and manageable features
  • Global project optimization. Example: 80% of the Projects will be completed within 80% of the forecasted dates; forecasted date will depend on Proj. Mgmt Type

Know thy Management Style

Finally let’s also recognize that each one of us as managers has a different style; no matter what processes we follow or not, no matter how much we try to promote innovation, what really matters is your personal simagetyle. How you listen, how you understand the status of the deliverables, how to convey urgency, how you promote self-organization and new initiatives is your style. The most concise set of management styles are the X, Y, Z ones:

  • X = shut-up and dig
  • Y = you are smart and I can help you
  • Z = part of the family, keep everyone involved

But the WSJ has the view I really like: “Leadership is less about your needs, and more about the needs of the people and the organization you are leading. Leadership styles are not something to be tried on like so many suits, to see which fits. Rather, they should be adapted to the particular demands of the situation, the particular requirements of the people involved and the particular challenges facing the organization”, WSJ April 2009

I have found helpful to describe my style using the WSJ attributes with a spider chart –  just as an example.

I would love to hear your views!

Development processes: one size does not fit all

Christine Nolan has been doing an excellent job organizing the Software Cluster of MassTLC. Today’s meeting took place in the VMware facilities in Cambridge and moderated by Brad Meiseles, Director of R&D at VMware.
Brad made a couple of excellent references and quotes such as:

  • Begin with the end in mind” – From Steve Covey’s book of the 7 habits of highly effective people as Habit #2
  • The major problems of our work are not so much technological as sociological in nature” – Peopleware quote.
  • To build a successful organization and team, you must get the right people on the bus” – Jim Collins, from Good to Great.
  • Developers prefer to user agile methods; managers prefer to use heavy methods” – Anonymous
  • Micromanagement is evil; measuring lines of code is useless, because less truly is more” Mikael Jansson
  • Developer’s productivity is really a qualitative assessment, not a quantitative measurement

(If you Google on each of the above subjects, you can spend a wonderful afternoon with the ideas and opinions of many experts!)

Following Brad’s stimulus, the group engaged to a wonderful discussion about

  • Factors that drive software developer’s productivity
  • How to measure and quantify productivity

And of course, the topic of the work environment is always in the forefront: cubicles and open space vs. closed offices; to socialize and interact or to leave developers alone; everyone to get involved with everything or specialize; use of IM and email; working from home or going to the company; frequent meetings or not; distributed teams or everyone in one place.

My conclusion on this topic: developers to have a visible indicator that they do not want to be disturbed – either wear headphones or have a red-light on your desk

But, is social interaction and “group work” necessary for software developers?  Another lengthy discussion followed. A couple of hours later, I found myself researching this subject; and I run to the following quotation from a codinghorror blog:clip_image002

… Personally I have worked in teams and alone and prefer to work alone for the following reasons:
1. Full ownership of design decisions.
2. No communication overhead with other team members.
3. Responsible for the project schedule. 
4. Can set my own high standards, and do not have to encourage others to live up to these.
5. No "babysitting" of less experienced developers (sorry, but I’ve been there and it does take time and energy).
6. Can use a project to explore a new technology, without having to justify the decision to other team members or project managers.
7. Can communicate directly with customers without having to work through any middlemen (for example project managers or dedicated analysts acting as a conduit of communication between you and the customer).
8. Don’t have to deal with other developer’s legacy code, as all of the code is mine my familiarity levels are higher.
9. Get to choose what language and database to use for new projects, assuming that the customer does not care so long as they get their web application.
10. No time required for regular team and progress meetings with managers!
I could probably come up with more, but you get the point. The only reason I miss working in a team is for the peer review of my work, but for any projects were you are able to open source the code and release it publicly, the "hive mind" (to use your term) of the open source community will review the code for you, and will quite happily and vocally point out areas where you can improve…

Boy, John is a very lonely individual…

My Take Aways

clip_image002[4]

  • Engineering efficiency might not be the priority of the Business Objectives – quite often, optimizing time-to-market leads to lower engineering efficiency.
  • Software development productivity metrics are more qualitative vs. quantitative – a “qualitative metric” what an oxymoron!
  • Agile processes might be appropriate for one type of business but not for another; this totally depends on customer expectations: if they cannot “absorb” a new release every 4 weeks, doing 2-4 week sprints does not make sense. For certain type of products or businesses, traditional approaches (including waterfall) might be more appropriate.
  • Software Quality is a relative term: if the impact of making a mistake is low, qualification and stability can be compromised in favor of the time-to-release; and the reverse: if a software error can cause a major customer problem, you better qualify the product well.

Thoughts? 

High-performance teams: a lifetime experience

This subject has been the theme of many books and recent meetings. Most recently I attended the Mass Technology Leadership Summit on Rapid Development and Deployment; this meeting was one of the MassTLC Software as a Service & Cloud Software Cluster. Details about the promising world of SaaS, PaaS and IaaS can be found in David Skok’s presentation – as a keynote speaker he walked through the explosion of mobile applications and correlated it with the PaaS model. His presentation can be found in this link.

image

But beyond the analysts reports and VC community do and don’ts, the part that I enjoyed most was the panel discussion on High-Performance Teams by:

  • Julia Austin (VMWare)
  • Peter Wiley-Cordone (GSN)
  • Eric Malafeew (Harmonix)
  • Sanjay Vakil, (TripAdvisor)
  • Greg Kunkel (Next Jump)

Their discussion motivated me to write the twelve bullets below summarizing my 20+ year experience on this matter:

  1. High performance teams require clear business objectives, goals and priorities
    • do not assign tasks per person
    • understand the dependencies
    • provide visibility of impact to the revenue
  2. Innovation cannot be dictated; you can only develop an environment that encourages innovation
    • must invest to create such environment
    • requires perpetual effort
  3. To attract talent,
    • do not interview for a project, interview for smart and flexible developers
    • test for cultural fit – this assume that you already have decided on the culture you would like to have in your company!
    • value higher individuals with passion and humility
    • ask for specific examples of teams they liked and why
    • ask for heroic work they did vs. group achievements
    • check references or other colleagues by asking the question what memorable thing have they done.
  4. Smart people like to work with other smart people; the productivity of an exceptional designer is 30:1 to the “average” – and you only pay them just a factor of two more than the average!
  5. To increase cohesiveness, seed teams with members that excel at creating a community. Identify the nucleus of these communities by:
    • finding the poles of the informal networks
    • identifying the magnets of discussion in  water fountains, ping-pong tables or coffee corners
    • finding who invites colleagues for a beer after work or a golf tournament or a game
  6. Give the most challenging problems to the best engineers
    • it is OK to give a maintenance or support project to an excellent engineer, but upon successful completion you must give him a very challenging goal – aka ping-pong theory from the Soul of the New Machine.
  7. Distinguish between Architects and Prototypers – you need both!
  8. Require openness, no black boxes, total transparency; motivating developers to do peer reviews. having incumbents "mentor" new employees. the whole team participate in code reviews after the daily "standups”.
  9. Celebrate successes and learn from failures
    • successes to be justified by external (customer) feedback or revenue impact
    • maintenance or support tasks must also be recognized because of the inherent value internally or externally
    • because the failures of startups are more than the successes
      • extract value from the failure
      • focus on lessons learned
  10. Technical managers are hard to hire or grow internally
    • do not force great engineers into management as professional evolution
    • do not cap managers from technical involvement
    • recognize individual contributors in parallel with the managers
      • equivalence of salary and perks
      • pay attention to titles and org charts
  11. To motivate teams to do less glamorous projects let developers fix it the way they way want it, earn the opportunity to do more interesting projects, or bask in users’ appreciation of a problem fixed and a job well done.
  12. High performance team cannot be distributed at the beginning – in general, remote developers work on tasks not on team goals.

After the meeting, as I was walking with Brough in the Kendal Square T-station, I was bubbling the thoughts above; then he noted: but didn’t we apply the above when we were building the NMS team?

Are you an engineer who like the above? Call me to hire you at once!

Are you a manager who embraces the above? Call me to grub a coffee to chat!

A 75-week Journey

The journey of a Senior Technology Executive for 75 weeks is over! If you are about to take the same journey or you are in the midst of it, continue reading. It contains several lessons learned, what to do (and not to do) and other useful hints based on this recent experience.

Lessons learned

  • Your BEST experience of your life
    • Strengthens your character; challenges your values
    • You will learn a lot – you will also learn what NOT to do to others
    • Comparable to the experience of a death in the family or a divorce
  • First thing that matters is what THEY want
    • It does not matter what YOU want
  • Understand yourself – what really matters?image
    • People? (read people you meet)
    • Money? (look into PE portfolio companies)
    • Stability? (look into government sector or big companies)
    • Adventure? (look into early stage companies)
  • Its all about “fitness”
    • fit to the culture (work environment, energy, openness, interests, management style, etc)
    • fit to their needs (projects, expansion, budget, etc)
  • How far are you willing to compromise
    • what is the point(s) you will not compromise?
  • Follow a multi-prong approach
    • Be Found
      • Quality executive recruiters (at least 15)
      • On-line presence
    • Do Hunt
      • Networking – get to know people who can introduce you (>2 days/week)
      • Job boards: Linkedin, Ladders, Beyond (no more than 5 hrs/week)

What to do

  • Get a career coach; get help!
    • Educational
    • Structure
    • Morale
  • Split your time to 3 activities (I spent 20 hours/week for each one):
    • Networking (1-1 meetings, events, conferences, etc)
    • Marketing (your next steps, blogging, Linkedin, user groups)
    • Filler Work and Skills development (consulting, volunteering, seminars, etc)

image

  • Streamline your marketing material
    • Resume
      • Got to have one!  It should be very well crafted
    • Networking profile
      • Goal: get connected with decision makers or drivers
    • Introductory letter to recruiters
      • Goal: get their attention
    • Introductory letter (email) for networking
      • Goal: get a face-to-face meeting
  • Organize your files. Recommendation:
    • CONTACTS – I used Google Contacts. Enter everyone you meet
    • CAMPAIGN – list of companies you contacted and all correspondence, research material, etc
    • EXPENSES – keep track of your financial affairs and deductible expenses, including scanned receipts and mileage. Watch your expenses vs. budget weekly
    • DIARY – what did you do today? Who you met? Your next “To Do” list
    • DUA Records – worksheets, MSP, correspondence

How to behave and what to expect

  • 95% of your outreach efforts will not get a reply
    • But the 5% you will get are worth-it
  • Select your support circle
    • Any professional who can listen to you and you can talk to
    • You need 3-4 good ones
    • Meet (and vent) weekly or bi-weekly
  • Be relentless
    • Be ready to wait as much as 60 days before a valuable connection is made
  • Be confident
    • You are a competent senior executive
    • You are “an example to others” – not a follower
    • Your unemployment is not a disease
  • Have a singular goal
    • Find the next occupation you can add value

Additional Hints

  • Do not customize your resume
    • recruiters want this, but it is not a good idea
    • everyone has a different idea of what a good resume is!
    • get trustworthy professional help
  • Always include a cover letter
    • Tune it to the published position
    • Attach it also to your resume
  • Do your homework image
    • before every meeting (interview or not)
    • about people (and their connections), company, industry etc
    • find common touch points
  • Listen to your trusted coaches and friends
    • just listen what they say – then judge and apply
  • Digital presence matters. Importance:
    • Linkedin
    • discussion groups your participate
    • your Blog
    • your Web Site
  • Changing industry is hard
    • recruiters are looking for experts with history in the same industry
    • companies do not consider candidates outside of their industry!
  • VC and PEs
    • if you are highly recommended, 1:10 might be friendly
    • hopeless unless they have worked with you before

Companies Types

  • early stage start-ups, i.e. no funding or bootstrapped
    • lots of fun, excellent learning experience, 1:10 will make it
    • work for free as a filler of your resume
  • post-funded start-ups
    • looking primarily for individual contributors
    • good choice if you like the industry
  • pre-crossing the chasm, good business plan, product exists
    • go for them!
  • chasm crossed
    • all about scalability
    • moving fast, need as much help as they can get
  • mature but small
    • 80% of needs are “management of change”
    • minimal innovation
  • mature and big
    • hopeless

Example: Statistics

  • 3,200 blind introductory letters to CEOs nationwide
    • 2 interviews
    • Effectiveness: F
  • 12 executive recruiters; monthly contact with 2
    • 1:3 of them is very good; boutique recruiters are the best
    • Effectiveness: B+
  • 60 “blind” Linkedin introductions (hunting)
    • Got very good networking meetings
    • Make compelling introduction with InMail
    • Effectiveness: B
  • 45 companies – research and meetings
    • Wonderful experiences in multiple industries
    • Effectiveness: B-
  • 4-meetings per week (x75 weeks)
    • Individuals or small groups
    • Giving and Taking
    • Effectiveness: B-
  • 250 on-line applications (passive)
    • Got an excellent idea of the needs of each industry
    • 3 interviews
    • Effectiveness: C

Resources

It will be an omission if I do not acknowledge my friends, colleagues and coaches who supported me substantively and emotionally: Brough Turner, David Asher, Bob Schechter, Maria Cirino, Greg Dracon, Steve Gladstone, Chuck Linton, Takis Metaxas, Elaine Doll, Dan Romaine, Anthony Barsamian, Russ Campanello, Imran Qidwai, Joanne Mavroides, Gerry Chaplin, Dan Romaine, Dave Wellich, Joellyn Wittenstein Schwerdlin, Colin Moor, Bob Elliott, Joe Freitas, Steve Miles, John Nicol, Jeff Krampf, Dan Daly, my wife Helen Tsiganou, Bob Steingart, Seth Frielich and all my other friends from SENG-NE. Each one of them spent quality time with me and help me in every step of this journey.

Give me a call or email to me if I can be of any assistance; and… keep your head-up!

The Battery Crossover Point

I have been monitoring the battery evolution for the past 25 years including primary (disposable) and secondary (re-chargeable) batteries. At Sea Data we were using primary alkaline and lithium stacks of 100’s of ampere hours; and when we had to drive GOES transmitters we were using NiCd booster batteries which were charged very carefully from the primary batteries. A similar design is currently used by URI for their Inverted Echo Sounder (IES) instrument to avoid the passivation effect of primary lithiums; it involves two Coulomb charge gauges under microprocessor control, consuming under 25uA of operating current.

A specific point of interest has been the price cross-over point of the Lead Acid batteries versus the Lithium Ions. Lead Acid batteries are used in cars, alarm systems, telco backup systems – they are very rugged, easy to use, inexpensive but also very heavy and include environmentally hazardous materials. The Lithium Ion batteries are used in laptops, PDAs, mobile phones and recently in electric cars; they are lightweight, do not include hazardous materials but they are mechanically and electrically delicate.

If you watch the evolution of the lead acid technologies over the past 25 years, nothing has changed much; in contrast, LiIon technologies have evolved at least by a factor of 20 in terms of cost per kWh.

In a recent article from Electronic Design (June 1, 2012) titled “Here Comes Electric Propulsion”, I noticed the following chart indicative of the technological growth of the Li-Ion batteries

Chart of battery improvements (Courtesy of Panasonic). Energy density DOUBLES every 10 years, i.e. 8% increase every year

An excerpt from Ultralife Corp also highlights that Li-Ions have additional advantages:

image

But with respect to cost, we have the following points:image

  • The best deal I could get for a 35AH Lead-Acid battery (which we use at netBlazr for our home brewed UPS systems) is $67 (weight is 27lbs!). 35AH at 12V is equivalent to 0.420 kWH; therefore, lead-acid batteries cost about $160/kWH as of mid 2012
  • As reported by Bloomberg New Energy Finance, the cost of Li-Ion batteries in 2011 was about $800/kWH, and in Q1 of 2012 decreased to $689/kWH (14% decrease); it is also expected that use of the Si-Alloy anode material will improve the densities by another 18% without significant increase of the cost.  It is also reported by Envia that the cost of the battery pack will be reduced to $125/kWh.

Compiling the Discharge Tolerance and the cost estimates  two estimates, we can assert that

  • the cross-over point for new designs is NOW
  • ignoring the Discharge Tolerance, the cost of Li-Ions batteries will be roughly twice than the Lead Acid batteries  by the end of 2012 and parity in 2014; by that time, Li-Ions will be 2-4 times BETTER than Lead-Acids in every aspect!

One final point: the evolution of electronics relating to power management (gauges, conditioning, chargers, protection etc)  of Li-Ions has been explosive – just take a look at Linear’s Technologies, Maxim’s and Texas Instrument Data Books!

Conclusion: stop using Lead Acid/AGMs for new designs — flip to Li-Ions immediately

Internet of Things: A forever passion

I decided to write this blog to share lifetime experiences in the space of electronics and “the cloud”. But first, let me apologize about bragging myself; this blog contains too many sentences including “I”; nevertheless, it’s helpful to look backwards and see how the art of electronics led to the home automation and finally to the cloud services.  So, here we go.

In the 80’s at Sea Data, I had the opportunity to be mentored by two leaders in the electronics space, Winfield Hill and Paul Horowitz, the authors of the book The Art of Electronics – the best reference book for engineers in the field. The majority of the examples in the book are real circuits and designs we experimented and implemented at the company. Key projects included,

  • underwater pressure/salinity/temperature processing for in situ wave energy analysis,
  • environmental monitoring systems (deployed in the Savannah river nuclear plant by Dupont)
  • high capacity recorders for sonar applications

In fact, the reason I joined this start-up was my graduate expertise on non-uniform sampling, i.e. how to optimize systems with minimal amount of energy in terms of computing operations per Joule. The common thread of all work at Sea Data was

  • stand-alone and low power devices
  • state of the art electronic designs
  • 10’s of thousands of lines of code for the early microcontrollers
  • transmission of processed data via wireless links to the shore

To elaborate to the last point, our systems was collecting environmental data under the ice in Alaska, performing extensive signal processing (using an 8085 processor running FORTRAN), and after days of collection and processing coming to the surface and dumping the results to a SATNAV link to Washington DC servers. The buoy was drifting and data-collection, processing and data-dumping was continuing for many months; the energy source was a sophisticated system consisting of lithium primary batteries, rechargeable ni-cads and solar panels. I consider this to be the first Internet of Things rudimental implementation – Internet for commercial use really did not exist at those days and the “Things” were just our buoys!

In the 90’s, as I engaged with the 2nd start-up-in-transition, Natural MicroSystems, I got involved with voice processing systems and communications. It took a decade before the company reached $1Bn of evaluation, >$150M or revenues and amongst the Best Companies to Work in MA.

Meanwhile, my passion in designing circuits and writing embedded code continued as a hobby beyond Natural MicroSystems product development. Relevant activities included:

  • Teaching at the Harvard Extension School experimental electronics (analog and digital) during the summers for 10 years
  • Starting my own design consulting company
  • Exploring new areas in home automation

The last activity became my playground: I had no pressure to make more money, no deliveries, infinite time to think and lots of experimentation to do. The goal was simple: be able to check and control every appliance and device in the house while I was travelling to Europe and the Far East. And because suburban Sherborn looses power at least 5 times a year, everything had to be battery backed-up.  To make the story short, I designed and deployed several prototype systems:

  1. X-10 based sprinkler control system (early 90’s)
  2. Designed a 4KW UPS system for the entire house
  3. RF 433MHz based water-valve water leak system
  4. Z-Wave water pump tracking system
  5. Web interface of all sensors via HomeSeer, .NET, and early PHP web servers
  6. Distributed temperature sensor system (combination of one-way RF 433, and zig-bee); reversed engineered off-the shelf sensors and developed the concentration point and web interfaces.
  7. First WAP based application to control all home sensors and actuators (early in 2000)
  8. Interface to cellphones via SMS for control and alarms
  9. Expansion of the house UPS with wireless connections to a gateway feeding the cloud web services.
  10. PC based gateway between serial devices/sensors and on-line services
  11. Design my own 2-phase power metering device
  12. Web based mobile applications to connect with home automation systems.
  13. Interface of power metering solutions (Envio, B&D) with cloud services (Google Power, Meniscus).

(It is worth to mention that my first X-10 plug-in card for CPM Z80 machines was made in 1982. The system included the necessary software written in assembly language to control lights and appliances; it also included an interpreter to create programmable scenes.)

Starting in 2002, NMS expanded its business to the OEMs of the Mobile Carriers. For the next several years, the industry of mobile voice communications and associated value-added services emerged very strongly. At the same time, the messaging space, especially SMS enjoyed the fastest growth.

Going forward to 2006, the first concept of M2M started emerging at the Mobile World Congress. Operators could see how voice and data plans will be saturating earth’s population in 5-10 years, and started exploring alternatives. Concurrently the WiFi standards had advanced, hardware became a commodity and deployment of Wireless Networks became ubiquitous and trivial. At the lower end, very inexpensive silicon for low energy wireless technologies such as Bluetooth, Zigbee, RFID and NFC was made available.

At this point it became apparent that everything could be interconnected in a cost effective manner; any device, stationary or mobile could be a part of a bigger network and service. So, I started participating in technical forums and industry events and experimenting with development kits in most of the wireless interconnecting software stacks.

In 2008 I realized that embedded devices and LAN/WAN wireless connectivity problems have been solved.  The new challenges now are different:

  • To simplicity all user interfaces of the interconnected devices
  • To provide cloud based services (processing, intelligence, analytics, logging, etc) which are useful and valuable

(useful = the user get a real benefit; it might be entertainment, convenience, simplicity of every-day-life things, etc
valuable = the user is willing to pay for it)

So, here we are: experience, passion, and an arsenal of technologies ready to be used.

What is the next big application domain which is worth pursuing?

Cowboy Agile Product Dev: 60 days to delivery

With this blog I would like to share the experience of designing and producing a mini-product line within 60 days. You might think that this is not a big deal for an organization consisting of good product managers and disciplined engineers; the difference here is that a single person (the “cowboy”) executed the entire project from A to Z, working on a part-time basis. But before I get into it, I would provide some background and context.

imageIn November 2011, I got involved with company called Alpha Innovations which manufactures anti-static materials for industrial use. More specifically, they make a patented string which includes a conductive thread and little  tiny spokes which attack electrons from charged surfaces. In addition, they produce ionizing rods made out of fiberglass and dressed with a similar conductive patented material. The products are sold under the brand name StopStatic. Bill Larkin, the founder of the company and the brains behind this commercial success, approached me to solve a unique problem: the strings and rods work amazing well, but his customers need t know that they do so! he needed some sort of visible and audible indicator showing that static electricity is discharged properly.

But what is really needed in actionable technical terms? what are the use cases? what are the cost constraints? All the right questions to translate Bill’s objectives to the reality of a product.

After visiting a local factory, Web Industries, I saw in my own eyes the real problem – boy, that’s an important problem to solve!

After a couple of weeks, I had created a rough requirements document; at the same time I started experimenting with various circuits (see this blog) and outlined 3-4 possible solutions, using logarithmic amplifiers to measure from nano-Amperes to milli-Amperes, tera-Ohm input circuits and all kinds of wild possibilities. By Christmas day, the first prototype took flesh and bones (described here) and went back to Web Industries to get their feedback – the factory manager was impressed so was Bill. Next steps: create half a dozen units to give to trusted customers for further testing and refinement.

The race begins

By the end of January we were ready to go; to make our life more interesting, we decided to participate to the International Plastics Showcase, April 2nd to 5th. So, we had a hard delivery in 60 days with whatever we could display at the show. But let’s start with the objectives first:

  • to test the market and verify the need of this product
  • to converge to the exact technical requirements – create several different versions of the product
  • meet the deadline of the show

A pick at the units ready to go

All R2

From the left to right, the VisioStat VS-400, VS-100A, VS-100 and VS-200; each unit has it’s own special features but all of them share 95% of the same h/w and 100% of the same software. The actual system configuration is shown in the two pictures below. The left side setup is indicative of the string configuration and the right side picture of the ionizing wand. I have also System Junction R1created four short video clips to help Bill and his people to better understand the functionality of the units and prepare for the show. If you are interested to know more details about the use and functionality, you can follow the links below.

Introduction (http://bit.ly/H1Gffa)

Chapter 1: Indicators and Controls

Chapter 2: Adjusting the VisioStat Sensitivity

Chapter 3: Connecting the JunctionStat and WandStat

Chapter 4: Connecting and External Power Supply

 

 

 

Planning of tasks to be performedSystem Wand R2

At the beginning of the project, the following tasks were known to be executed:

  1. Create an initial set of requirements with preliminary objective specifications for each variation; do we need 2 product variations or 6 to test the market
  2. Converge to a h/w design which can accommodate the above variations
  3. Select the appropriate form-and-fit package
  4. Decide on visible controls and indicators
  5. Architect the software, i.e. functional aspects and user interface
  6. Select appropriate components – trade-offs between feed-through technology vs. surface mount
  7. Order all necessary parts at the right quantities for a pre-production run
  8. Capture schematics
  9. Do the board layout
  10. Assemble the PCBs
  11. Deal with all mechanical aspects of the enclosures
  12. Develop the code
  13. Design and implement the front panel inserts
  14. Integrate the units, i.e. mechanical, electronics, software
  15. Test completed units
  16. Create instruction videos and documentation
  17. Ship to the show!

Being a cowboy has an advantage: work fast with minimal time lost to communicate with other; but also a disadvantage: you are on you own, no second pair of eyes to review your work, no help you can count on. By no means you should think that I like to be a cowboy — I’d rather work in the context of a company and apply the same techniques for 100-times bigger projects!

Lessons learned: The techniqueVS-200 Internals R1

I have applied the same approach to multiple other projects in my past life – the difference here is the required velocity and the breath of disciplines needed, i.e. thinking about product requirements, user interfaces, industrial design, hardware details and software implementation at the same time. What really helped me was my very long commute to netBlazr of more than 2.5 hours per day: a ton of time to think and balance trade-offs while stuck in the Mass Pike. Here are a couple of techniques which I used, in a random order/priority:

  • Start with high risk areas: Attack the most difficult and higher risk aspects first; start with the highest risks items or least known; avoid spending time initially on anything you know how to do or have done in the past.
  • Consider Alternatives: think of options and alternatives for as many areas as possible; create trade-offs and compare the approaches. Converge quickly to an approach, even if not the best.
  • Be Defensive: Murphy’s law applies everywhere: if anything can go wrong, it will; this extends from all mechanical tolerances to details of the user interface, to the software impossible if-else case. Have always a backup plan for all aspects of the project and be ready to flip to it.
  • Parallelize  Massively: identify as many tasks to be worked in parallel at any point of time. Work like a CPU: run everything concurrently and block when you have an I/O (i.e. external) dependency. Maintain a mental dependency Pert chart of serial tasks and parallel super-tasks. Focus on the super-tasks while you are executing the serial tasks which have no dependencies.
  • Design-code-test iteratively: start with a block diagram, create the first pass of the code, use stubs for the details, test as quickly as possible. Apply the same for all system pieces; build the composite code frequently – say  every 4 hours of work (!) and test the complete system.
  • Be code perfectionist: there is zero tolerance for code mistakes or bugs in an embedded system; if the code crashes the hardware can be damaged and the operator can be hurt. Test and re-test everything and in combinations. If a particular design is risky and not perfect, throw it out and redesign it, re-code it, and re-test it

The above techniques were applicable to all aspects of this project, the mechanical, the electronics, the user interface and the embedded code. Consideration of Alternatives, being Defensive, Design and Test, etc are directly applicable throughout the project.

What went better than expected: Pick List

  • schematic capture, PCB layout, PCB deliveries (from China).
  • code stability and robustness – entirely in C but very object oriented.

What went worse than expected:

  • parts selection and part procurement – too many unexpected delays
  • fabrication of mechanical parts – drilling holes, front panel inserts, etc.

But at the end, everything was done on time and shipped to the show…

Feedback from China

After the show, Bill flew to China to talk with local manufacturers and get their feedback. I have a strong suspicion that the next step is all about wireless connection of all the static discharge sensors and a centralized console.  It is also very likely that some sort of storage record of statistics will be important. Now we are talking…

If you are a technical manager and you would like to chat more about the above, just contact me!  If you have any comments on the above techniques, I would love to hear your wisdom.

Modify Mikrotik RB-750UP to measure ANY voltage

After the power outage in Boston last month, Brough and I decided to provide battery backup to our new head-ends. A typical head-end includes several gigabit ports (3 x RB-1100 AH2’s or a bunch of RB-750’s), power injectors to the radios and a backhaul fiber connection. So far we have been using off-the-shelf UPSes (see the last unit in the blog Giving birth to a Rack with a View), but they do not last very long – just a couple of hours. The challenge is to power our head-ends for more than one day, preferably two days.

To do this, we have to fine tune our power budget. Using batteries, stepping them up to 120V (80% efficiency), then stepping them down to 24v for the radios using PoEs (78% efficiency), and using a WebSwitch wastes at least 50% of our available power. So, we quickly decided to run the entire system from batteries with the appropriate electronics. So far, we only have a block diagram of what we plan to do – the moment we converge to a good solution, I will write another blog for the WISPA community.

One of the challenges is monitoring the battery voltage remotely using an inexpensive way. There exist several commercial products measuring voltages which include their own server and interface with web browsers – unfortunately all solutions require extra hardware and many hundreds of dollars… Jim becomes very unhappy if we spend too much money for hardware.

So, here is the idea that struck me this morning Light bulb:

since the Mikrotik routers are able to measure their own power supply voltage and make it available via the Winbox (/system health print), there got to be a way to disconnect the resistor divider network from the power jack and make it available separately.

Minus a few details — such as, not having any schematics or PCB layout, no assembly drawings, NOTHING – just two RB-750UPs as arrived from the distributor. So, I got my hacking hat and started working…

Step 1: Prepare and Relax

imageMikrotik uses 0402 components (i.e. 0.2mm) and you really need a good microscope to do this!  The PCB features are 0.125mm apart – yes you are reading this right: a human hair is only 10 times thinner than the space between pins – the picture to the left shows this. image

To make measurements by toughing various components, I replaced my voltmeter probe with the thinnest needle I could found in the house – even that was still too big and I was running the risk to short adjacent pins.

Most importantly, you have to relax ; no phone ringing, no kids (or wife) in the lab, and a good chamomile teaMugdo not drink any coffee at least two hours prior to this!

 

Step 2: Orient to the unknown PCB

Starting with the Power Jack – tracing the (+) terminal was hopeless. Too may traces under components, too many vias. So, if the “left to right methodology” does not work, we need to make intelligent guesses:image

  • If the processor measures voltage, there got to use an A/D either internally or externally
  • Let’s start with the processor; after reading the Atheros chip specs, I could not find any A/Ds integrated – that’s a dead end
  • Next, start looking for familiar I2C or serial converters (from Maxim or Linear Tech or TI) – I know the three product lines very well, but no luck; dead-end again
  • But then, in the vicinity of the connector I noticed an AMTEL (Tiny 461A) processor – aha, Mikrotik uses a co-processor for all supervisory functions!
  • Now I need to find which pin of the processor is used to take voltage measurements. The data sheet was helpful – there were only 11 pins which support A/D measurements. But which one?

Step 3: Search and Hack

The technique to find the pin was straight forward:

  • pick a pin,
  • fix the input voltage to the router, say Vin, image
  • measure the pin voltage Vs,
  • change the input voltage Vin by 50%,
  • measure the pin voltage Vs again – if 50% higher, you might be closer.

It only took two tries and voila, I got it Thumbs up: pin 25, ADC1. As I changed the voltage from 9V to 18V, the ratio of Vin/Vs was constant. I also measured the Vcc of the ATMEL chip to 3.3V (as expected). In this case, if the ratio is 1:11 then the maximum reading should be about 36V.

image

Step 4: Find the resistor divider network

You would think that following the pin trace is easy; not that fast, especially since the natural sunlight in my lab has faded away. Keep looking with the microscope… The only “trick” you can use is

touch resistors at random Fingers crosseduntil you find the one with the same voltage as in pin 25!

After 20 min or so, I managed to find two resistors with the expected voltages. Time to snap another picture.

 

Step 5: Apply “the inverted bug” technique

imageThe task was to unsolder the upper resistor (R1) and fit a connector with one pin to the ground and the other pin to the lifted leg of the resistor. This had it own challenges – my top of the line Weller soldering station was not good enough to unsolder a 0402 resistor with my 1/16” tip; not enough heat to melt the common horizontal power bus. It’s time to use the “big gun”: the Metcal de-soldering tweezers, which I had borrowed from my buddy Frank Smith.

After a couple of attempts and plenty of solder flux, I managed to lift one leg of the resistor up in the air. Doing so, allowed me to measure the resistance; what a surprise: R1=10k and R2=1k – designers think alike! This gives a ratio of 11 – which matches with the computed ratio from the spreadsheet.

 

 

Step 6: Complete packaging and test itimage

In comparison, this is a piece of cake. Tools used:  Kapton (Polyimide) tape, drop of fast epoxy, and a file. It does not have to be pretty – it only needs to work.

Testing was done by connecting the Mikrotik to its power supply and using a lab supply to the external pins. Here is the Winbox screen:

image

Conclusion

Discovering the way to do this was interesting; luckily, I do not have to modify every router we deploy – just one at the head-end; I can do this again and again within 30min (minus the chamomile tea time). If you find this useful, do drop me a lineCall me.

Enjoy!

Nuclear chamber or what?

Just take a look at this picture and guess what you are looking at. Notice a pressure chamber with a bunch of electrodes at the top and massive plumbing on the right of the picture; also, lots of colorful wires…

Chamber1

Let me help you with one more picture – this is the other side of the same thing.

Chamber Other Side

Ok;  now you got it;  it’s (actually was) my Keurig coffee machine at home.

Here is the story of the week; on Friday, while at the office, I put my K-cup in the machine, hit the BREW button but unexpected things start happening: hot water started dripping from the overflow pipe to the reservoir and only a few drops of water made it into my cup. I played with the switch, the power plug, the reservoir, but no luck. Then I applied my technique which always works: hit the machine hard and slam the K-cup door; nothing; nothing worked.

Around 11:00 am, Brough comes to the office after visiting one more customer; he started reading his email but, after a while, he turns to me saying: George, something is wrong with the coffee machine…

But that was at the office on Friday.

During the weekend, at home, I was enjoying the doses of caffeine – my favorite brand is called Rev-UP and contains twice the caffeine of a Starbuck grante. You see, at home I have an identical Keurig machine as at the office. I had bought both of these coffee makers at the same time about 15 months ago from Amazon.

On Sunday, the unexpected happened – my home machine started misbehaving exactly the same way as one at the office! Is this strange or not – has the Chinese manufacturer timed the entire batch to blow-up at the same time? Apparently YES!

Given that I was bored cleaning my office, I decided to figure out what is going on; my thought was very simple: if I figure out how to fix the home machine, then I could also fix the office machine and save $360 of buying new machines.Chamber Valve

Disassembling this thing was a nightmare; after I removed the obvious 23 screws, the thing was still inaccessible. I could not really expose the internals because the plastic covers were surrounding the entire chamber, all pumps and plumbing.  So I decided to pry the plastics and break it apart. So I did.

To make the story short, the problem was an electrically activated valve – it was stuck one way. I did not have a clue how the plumbing worked, but by trial and error (and some logic) I ended up bypassing the valve. The picture on the right shows the valve disconnected, hanging on the side and the plumbing re-routed to the overflow reservoir.

I finally started brewing coffee again! 

But my satisfaction did not last very long… After 3-4 cups of hot water, one of the loose wires touched the wrong point, and of course the lights went off and the breaker popped open…

Next step: place an order to Amazon for Keurig B70 model; worst of all, I still do not know how to fix the thing at work.

Can anyone help me on this?

Giving birth to a Rack with a View

imageAfter months of negotiations, Jim managed to lease space at the 61st floor of the John Hancock’s tower to install netBlazr’s antennas. While Brough was enjoying sunny Florida, George was driving to You-do-it Electronics to buy the missing screws to make “the rack”; and finally she was born: Dec 30th, 2012 at the 14th floor of One Marina Park Drive in South Boston, weighting 220 pounds (with the batteries); mother George and father Brough are doing fine. His first picture to the right.

His brain is fully wired – his mother actually did a good job connecting all cells together. Of course, the routing connections are missing — neither her father Brough nor her uncle Jason spent any time get with the newborn. Her first EEG was good and lights were blinking.

image

It only took two hours to move her from the birth room and to her permanent home: the 61st floor of John Hancock’s Tower. And now the fun begins: put her at the top of a crib made up with four cinder blocks. In this picture, she is sitting comfortably in her own space:

image

Unfortunately, his father forgot the bits and screws for the antennas – so Jim played the role of the taxi driver. Meanwhile, mother was enjoying the baby and had an opportunity to take a couple of nice pictures. Her room did not have any curtains – so she had full view to the outside; what a view! can you image this? at the top of the tallest building in Boston!  indeed, a Rack with a View

image                  image

After Jim and Brough came back, the dirty work started – mounting the antennas; lots of them. George did start the first mount climbing at the top of the 10’ ladder (61st floor + 10’ of the ladder, not daring to limageook down!). Did not do very well – broke 4 screws and left the first mount with only 3 supports. Jim was learning from George’s mistakes and took over the hammer drill and whispered:  drill baby, drill; and while Jim was drilling, the father (Brough) was supporting him. Here is a picture of them:

Jim and George were trading places mounting one antenna at a time – 12 of them! amazing enough, the team had a plan that father (Brough) had created:image

By 4:46pm, all mounts were installed, except the two missing screws that George snapped off. All of us were exhausted, full of dirt, thirsty but happy: she was a happy baby in her new home. The team drove back to One Marina Park Drive after a nice breeze of –6 degrees walking to the parking lot – all very happy.

The baby is still waiting from Cogent to get a New Year gift – she wants to be connected to the Internet!

VisioStat: Measuring from nano-amps to kilo-volts

The Challengeimage

  • To measure the static charge of a 12”x12” Teflon sheet when it is rubbed by a piece of cloth
  • To measure the charge accumulated on a can of Coke when it is charged at 10kV
  • To discharge a roller of plastic (or paper) as it run in a production floor

The Answer

My new instrument called VisioStat; here are the highlights:

  • it can measure static charges from 40 nano-Coulombs to 6 micro-Coulombs
  • it can discharge continuously surfaces draining 20 nano-amperes to 120 micro-amperes
  • you can zapped it with 30kV without destroying it
  • it is calibrated!
  • it provides an visual indication (a flasher) of the amount of charge or discharge
  • it includes a beeper which buzzes proportionally to the charge or discharge
  • it is TOTALLY programmable in software
  • and battery operated

Does it work?

In the following YouTube clip, there is a demonstration of VisioStat measuring the field of an ionizer, i.e. a generator of 15kV.

Next video clip shows how charges are transferred from a Teflon sheet to VisioStat; this mode of operation is called “the Coulomb meter”.

And finally, setting VisioStat in “Discharge mode”, you can discharge any surface from static electricity and get an indication of how much charge was removed per unit of time. This mode of operation is applicable to discharging large rolls of plastic or paper in an industrial setting.

To make this instrument, you really need to know (or learn!) the physics behind static electricity; then you practice your analog electronics, digital electronics and lots of programming; and if you are curious, I did use a PIC to:

  • control the analog front end
  • drive the LED bar
  • provide a PWM modulation to the beeper
  • drive the flasher intelligently
  • reconfigure the instrument
  • perform auto-scaling
  • measure the battery voltage – in case the lithium batteries have drained below their threshold
  • self calibrate

And because I was trying to keep the production cost low, I only used the PIC16F818 which has only 18 pins, 2K of memory and only costs $2.50. Oh by the way, prototyping using the Vero wiring-pen and 34 AWG self fluxing polyurethane coated micro-wires and tiny conduits (aka wiring combs). This technique is not very popular in the USA but works — Vero Technologies is a UK company http://www.verotl.com/vero-wire. The pictures below show the guts of VisioStat.

image

The next step is to commit to a PCB layout for the volume production run.

If you would like to know more about VisioStat, just give me a ring.