Project Management, Technology, Life.
RSS icon Email icon Home icon
  • Idea’s Around Agile Development

    Posted on February 10th, 2011 Nelson Bodnarchuk No comments

    “In the confrontation between the stream and the rock, the stream always wins, not through strength, but through flexibility.” – Buddha

    We’ve been bouncing around ideas recently regarding our processes and how to deal with contract negotiations while still remaining agile, not sounding ambiguous in our language with the client and still protecting ourselves from future technology changes in an un-standardized market. Here’s a great read that I found online regarding agile development titled “Agile Processes by Robert C. Martin”. The document offers potential solutions for Mercatus to leverage in the future.

    The points I really found useful in each section were as follows:

    • Individuals and interactions over processes and tools.
      • People 1st.
      • Let the team configure the development environment based on need.
      • A good team isn’t necessarily the one with the players that have the most skills but the one with the players who gel well and work together.
    • Working software over comprehensive documentation.
      • No documentation is bad, too much documentation is worse as the documents take a lot of time to produce and then even more time to keep in sync with the pace of the project and usually turn into sources of misdirection.
      • Create and maintain a short rationale & structure document that the team produces then keeps in sync from month to month. When a new member joins the team they work closely together to transfer knowledge in an interactive manner.
      • Produce no document unless its need is immediate and significant.
    • Customer collaboration over contract negotiation.
      • Software cannot be ordered like a commodity this leads to poor quality and project failure.
      • Successful projects involve customer feedback on a regular and frequent basis, rather than depending upon a contract or a SOW. Reference Contract Example Below.
    • Responding to change over following a plan.
      • When we build plans, we need to make sure that our plans are flexible and ready to adapt to changes in the business and technology.
      • A better planning strategy is to make detailed plans for the next few weeks, very rough plans for the next few months, and extremely crude plans beyond that.

    Contract Example:

    The author negotiated a contract for a large, multi-year, half-million-line, project. The development contract was paid out a relatively low monthly rate with large payouts when they delivered certain large blocks of functionality. Those blocks were not specified in detail by the contract. Rather the contract stated that the payout would be made for a block when the block passed the customer’s acceptance test. The details of those acceptance tests were not specified in the contract. During the course of the project the team worked very closely with the customer and released the software almost every Friday. By Monday or Tuesday of the following week the customer would have a list of changes for the team to make to the software. The team would prioritize those changes together, and schedule them into subsequent weeks. The customer worked so closely with the team that acceptance tests were never an issue. The customer knew when a block of functionality satisfied his needs because he watched it evolve from week to week.

    The requirements for this project were in a constant state of flux. Major changes were not uncommon. There were whole blocks of functionality that were removed, and others that were inserted. And yet the contract, and the project, survived and succeeded. The key to this success was the intense collaboration with the customer; and a contract that governed that collaboration rather than trying to specify the details of scope and schedule for a fixed cost.

    “If you learn only methods, you’ll be tied to your methods, but if you learn principles you can devise your own methods.” – Ralph Waldo Emerson

    The Principles to developing great software:

    • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
    • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.
    • Business people and developers must work together daily throughout the project.
    • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • Working software is the primary measure of progress.
    • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • Continuous attention to technical excellence and good design enhances agility.
    • Simplicity, the art of maximizing the amount of work not done, is essential.
    • The best architectures, requirements, and designs emerge from self-organizing teams.
    • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    What are your thoughts around agile development?

  • RFID Pros & Cons, Just How Secure is it?

    Posted on February 3rd, 2011 Nelson Bodnarchuk No comments

    Radio Frequency Identification, or RFID, technology communicates data via radio waves between an electronic tag located on an object and a reader device. RFID’s sole purpose is identification and tracking. It may sound like a new technology, however it’s been around for almost 70 years when the British were looking for a more reliable way to identify enemy aircraft. Check out the RFID time-line at Emory University. There’s also a ton of information on none other than Wikipedia.

    The obvious pros for this technology are bulk tag reading in an almost parallel fashion. Imagine you’re running a manufacturing plant with thousands of pieces of equipment, and your maintenance team can easily get real time information on all the equipment that they need to do predictive, preventative & corrective maintenance to that day. The other applications that RFID is being implemented are more consumer based, such as:

    • Car Sharing Services, like ZipCar and AutoShare.
    • Electronic Told Roads, like HWY 407 in Southern Ontario and various other cites around the world.
    • Public Transit, think Persto on the Metrolinx GO.
    • Asset management similar to the example above.
    • Product Tracking, like Casio Chips or IT Equipment, even clothes and electronics.
    • Credit/Debit Card touch payments, like ESSO Speed Pass and Master Card PayPass.
    • Drivers Licenses, like the EDL in Ontario.
    • You new Pass Port.
    • Future mobile Phones will have an RFID tag with payment info essentially making the mobile phone your future wallet.

    RFID technology is more wide spread than you probably thought, at least I found it surprising at how wide spread it’s usage is. So with all this information being read electronically, and the sensitive nature of some of the data stored on the tags, what security measures can be taken to ensure your data stays safe. The fact of the matter is if you’re using your credit card to pay for items purchased simply by holding it close to a reader, wouldn’t that create a bit of a security hole? Or more of a security Grand Canyon? This brings a whole new meaning to pick pocketing doesn’t it. You’re walking in a crowded area, and some one bumps into yo, says sorry and you think nothing of it. Then on your next credit card statement you notice that your card has fraudulent charges or worse is maxed out. The credit card companies themselves have admitted to knowing about the issue and working on ways to prevent it, but what can they do on the front-end to prevent fraud versus being reactive and calling you after a suspicious transaction has already been made. The fact of the matter is that they can’t, as well there was a story from CBC detailing how identity thieves could obtain your Billing address by intercepting your mail and with out even opening the envelope they obtain your billing address and read the sensitive data on the card or passport prior to you even getting it. Some tags can be read from several meters away and beyond the line of sight of the reader, as well.

    That’s the bad news, the good news is that RFID Technology isn’t mandatory across the board in the payment industry yet and consumers can purchase aluminum sleeves, or wrap their cards in foil, to protect their secure info when not using the card. The foil creates a Faraday Cage around the RFID tag, to scramble signals to the reader. Near Field Communication (NFC) also shortens the distance that readers need to be from the tags, combine this with some type of pin and activation code and you may have a solution to the security gap. The key is to remember that no system is hacker proof and that with the proper knowledge one can protect their information to a reasonable level of risk. RFID & NFC are just the next iteration of the card swipe in a lot of ways.