Midwest IT Survival

Has Google found an authentication solution that works?

Recently, Google announced that they will be adding another authentication factor to their login process for their online services.  They indicate they will start with Google Apps and then expand into other services.  Their blog post indicates the initial focus is on commercial users of Google cloud products.  Google also states it will be offering this enhanced security to individual users but doesn’t go so far as to indicate exactly which or any roadmap of when services will be enabled.

I’m very interested to follow how Google has chosen to technically implement this additional authentication factor solution.  It looks like they are leveraging an out-of-band distributed one-time password to make up the additional factor.  Although I have yet to see the end user experience firsthand, the blog post above and image below would indicate one would have to register a cell phone number capable of receiving SMS text messages or a phone number that can receive an automated voice call.

It appears to be part of Google’s approach that once registered for their new authentication solution, when logging in on an “untrusted” computer, after the user successfully enters their password, they would be challenged for a one-time password sent as a text message to their cell phone or an automated voice call to their previously identified phone number.  Upon successfully entering that one-time password within the timeframe Google determines it is valid, the user would then be granted access to their Google application.

How Does Google “Trust” a Computer?

The concept of identifying a specific computer as “trusted” was introduced back in around 2004/05 by companies like PassMark subsequently acquired by RSA subsequently acquired by EMC.  The PassMark technical approach was to programmatic-ally capture data (HTTP “header fields”) that all web browsers and clients provide to web servers in order for the web server to determine the best way to return content back to that web browser or client.  Information such as the client’s IP address, operating system version, browser version, with additional details via browser plug-ins such as Adobe’s Flash provides even more client specific information.  The data that PassMark selected was propriety, but given the fixed number of data elements passed from client to web server, one could speculate on a finite number of possible variables to include.

The data elements were combined into an encrypted string stored as a browser disk based “cookie” that upon return to the web site, the web server would be presented with that previously encrypted cookie and verified to be the “same trusted computer”.  If the decrypted cookie data didn’t match enough of the data presented by the browser making the current request, the computer could be considered “untrusted”.

Note:  There a significantly more steps to make this a more secure process.  I’ve only provided an extremely simplistic example for conceptual understanding.

Attackers Focus on “Trusted” Computer?

Unfortunately, no security solution is completely foolproof.  As more details surface about how Google technically implements their solution, one possible weak link will be the “trusted computer” solution.  If a fraudster can get the “cookie” or find a means to make their computer “trusted”, then the whole additional authentication factor could be bypassed.

I’ll be very interested to observe the security discussion on this as it inevitably unfolds as Google shares more details.

Everyone participates in iteration planning meetings

Today is the third and final day of the Agile Boot Camp being hosted by ASPE SDLC Training. I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery. I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy. In order to appreciate this article, I suggest you read my thoughts and experiences from the first and second days.

First, the excellent Davisbase, LLC instructor finally revealed his contact information. I confirmed with him it was ok to share so here goes:

Rod Ashton

rod@davisbase.org

801-918-4092

I can’t stress enough that Rod’s real world experience in corporate IT project rescue and his on premise company Agile consulting experience were extremely valuable to making this course very pragmatic. Rod would physically step from the center of the room (Agile practice, process and theory) to his immediate left (real world) frequently to segue from theory to practical real world experience based guidance. This made the course triple in value for me. Lastly, at the end of the day today on the course feedback sheet, the best I could come up with on “needs improvement” was having white-boards for team exercises.

The third day is where everything really came together. Thus, without much lead in, here are my bullet point notes from the day:

• When asking why, consider 5 level of “why’s” to get to the bottom of the real need
• For developers that are stuck or struggling to break down a blob of work into tasks, lead them through their internal thought process of developing the blob with “what are you doing to do first? What are your going to do next? Next? Next? …”
• For product folks having trouble articulating what they really are asking for, try “if you could wave a magic wand, what would you want?” to break the potential log jam of real world constraints and competing priorities to get them to spill.
• Make all changes in small increments in order to “tweak” the output in order to achieve cadence.
• Always, rule of thumb = “simplicity”
• Considering the above two bullets, start with 2 week duration iterations in order to get feedback sooner and see results of incremental changes sooner.
• Agile plus continuous integration maybe the next hot thing in efficient and effective software development.
• To start to build team commitment, PM or Agile Coach or Scrum Master lock eyes with team members to get personal commitment on initial story execution until team auto-commits by default.
• No brainer, but how many organizations are realistic on capacity? 6 hours a day max on average of real employee productivity.
• Everyone, everyone, everyone involved in an iteration participates in iteration planning.

I captured some helpful tips on how to establish a new team’s initial velocity:

• Plan to do the hardest stuff first
  • Tolerance for mistakes from management, nay saying peers and others are higher initially and less so as time marches on.
• Time box one hour for estimating to encourage quick decisions and less conversational off topic drift.

All in all, it was a lot of material crammed into three days. Rod did a great job keeping the class moving and keeping attendees awake and engaged. Plus, as I said before, his real world experiences merged with the Agile principles and process really made the course outstanding.

Now, my challenge is bring all this knowledge into practical execution with multiple agile and non-agile development teams plus non-agile infrastructure and all the classic corporate IT structures.

Can you really multitask?

Today is the second of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.  In order to appreciate this article, I suggest you read my thoughts and experiences from the first day.

With the basics of the history and the initial ground rules out of the way, now the class can dig into the meat of Agile.  The instructor started the second day with an interesting exercise. We were asked to do three things, each time boxed to two minutes:

On a piece of 8.5 x 11 regular white paper, do the following (2 minutes each):

• Write as many numbers as you can, 1, 2, 3, 4+
• Write as many letters of the alphabet as you can.  When you reach Z, start again with A
• Write as many letters and numbers as you can: A1, B2, C3, D4+

At the end of each 2 minute writing exercise, he captured the top number of entries from the class.  What was interesting and the point of the exercise: no one did particularly well on the letters and numbers exercise.  Even the clever people that tried various techniques to write faster failed to write as many entries as either numbers or letters only.

The point = people can’t multi-task as effectively as they think they can.

Or as I’ve come to appreciate this topic:

Context switching has a price.  That price can be around a 20% loss of productivity as a whole when someone is assigned an additional concurrent task to complete.

Many, many articles support my statement above. One classic is Joel Splosky’s “Human Task Switches Considered Harmful”

Early in the day, someone asked the instructor to share his opinion on if a team commits 100% to start being Agile, how long should it take to go from starting with high frustration to running smooth with little to no frustration.  Mind you, this is just his experience seeing companies and teams take on Agile, but in his opinion:

New Agile Team, 100% dedicated resources = 12 weeks or approximately 6 iterations

New Agile Team working with a vendor = 24 weeks or approximately 12 iterations

New Agile Team + vendor + contractor(s) = 36 weeks or 18 iterations

In more Agile terms, the project team requires the durations above in order to have more of a constant/predictive velocity and established cadence.

It was striking to see how the external elements of vendors and contractors double and triple the time it takes for a team to achieve a predictive Agile rhythm.

As we learned about good story creation and planning poker and relative estimating, I jotted down some Agile success themes that struck me throughout the day:

• Product Roadmap creation forces collaboration amongst all stakeholders.
• Serious Agile success is achieved when the business starts asking how to use Agile for their business work to be as productive as IT.
• Stories are from the user perspective, who, what and why … if you can’t define the “who”, then stop all work/discussion on that story.
• Agile requires a culture that encourages everyone to ask questions of everything
• Stories can come from anyone on the team … developer has an interesting idea about a product feature?  Write up a story for the backlog.

One of the more challenging topics to get ones waterfall head around was the planning poker or story estimating.  I wasn’t alone, a number of technical folks were asking questions around how it is possible to say this work takes “8 units” without completing that phase with “ of hours/days/weeks”.  Most classic corporate IT budgeting and projects need estimates of actual X features completed by Y.  Agile works under more of a “line of credit” concept stating: given Y amount of time and Z resources, X features will most likely get done assuming some velocity with cadence achieved.  I’ve tried to capture this challenge in more detail in this previous post on “Agile versus Classic IT Budgeting”.  For many classic corporate IT shops, this is a huge cultural challenge to overcome.

I am looking forward to getting back together tomorrow for the final day of talking about how to slot in stories based on priority and work units against the roadmap as well as release planning.

Demo Early, Demo Often?

Today is the first of a three day Agile Boot Camp being hosted by ASPE SDLC Training.  I’m excited to spend three days focusing on how to leverage the Agile methodology for software project delivery.  I’ve read a number of books and articles and blogs over the years, but this is the first formal Agile training I’ve been able to enjoy.

The first day covers the history and an introduction to Agile.  It also covers the forming of Agile teams, creating the product vision, focusing on the customer and the product road map.  The instructor was a little slow to get going, but once he got past the high level introductions and the brief history of Agile, things started to move quicker and get more interesting.  The class is full of people from all industries and job roles.  There are people from manufacturing, health care, insurance, government, consulting and financial services.  There are developers, managers, business analysts and project managers.  The class is mostly people without much if any Agile experience, so the pace of the course is perfect for the majority of the attendees.  Given my personal research and light weight implementation of a hybrid of Agile principles in past professional lives, I could see the course moving through material and concepts much quicker.

The instructor had us split into three and four person teams to do some exercises that support the content of the course.  Each team is given some very loosely defined requirements such as make paper airplanes that can achieve a certain goal or organize a pile of colored paperclips.  Once the exercises are completed, the instructor reveals the Agile specific principles involved in the particular activity.  This teaching technique is a creative way to get introduced to the theory before actually being told that theory from a strictly academic sense.  In the examples of the paper airplanes, team members self-organized into airplane designers, developers and testers based on the ad hoc team members basic personal/professional strengths.  I was amazed my high school mentally distracting interest in creative paper airplane construction coupled with the CWRU Strosacker quest to make paper airplanes glide gently over the crowd to softly bump into the main screen to the gleeful cheers of the students in the audience that came in handy today.

After today’s session, in chatting with the instructor, I learned he is a 25+ year veteran of globetrotting in order to rescue projects that are in trouble for time and/or budget reasons for American Express and other multi-national firms.  His hands on real world corporate and consulting experience gave additional credibility to the course material.  Some of his helpful, but maybe not strictly textbook knowledge shared included:

• Demo early, demo often = don’t wait till the end of the Scrum sprint to demo the product increment.  Get feedback ASAP in order to handle possible course correction.
• Team best practices =  Open and Honest Feedback = Direct, Specific and Non-punishing
• Plans are useless, planning is indispensable.
• Documentation is required, but only to the lowest level necessary.  “Do what it takes to barely get by”

I am looking forward to getting back together tomorrow to talk about creating and maintaining a product backlog, prioritizing that backlog and estimating work plus release planning.

Is everyone at the same level of competency?

As I was trolling through my RSS feeds of blogs I try and keep current on and I ran across another thought provoking post by Todd (@backfromred) entitled “The Failure in Gating Process”. I wrote a brief comment to share with Todd and his readers. In the comment I stated that I both agreed and disagreed with Todd’s premise. This blog article expands on that conflict.

Todd’s premise is that having PMO enforced project gates:

• Interrupt project progress momentum
• Allow management and sponsorship stakeholders an excuse to zone till “quality gate #4 next month” before paying attention to the project
• Efficiencies lost to stop, starting and context switching

It is difficult to argue that gating process or projects does have a “cost” associated with the stoppage.

Todd’s solution is better stakeholder engagement.

Again, I can’t disagree with his solution in theory. Where is disagree is in the practical implementation of “better stakeholder engagement” in the real world. First, project teams need strong, competent and knowledgeable participation from these disciplines:

• Project and Executive Sponsorship and Prioritization
• Project and Program Management
• Enterprise and Application Architectural Alignment
• Requirements Gathering, Documenting and Tracking
• Business/Systems Analysis
• Vendor Management (if 3^rd party providers involved in solution delivery)
• Technical Development/Integration Leadership/Delivery
• Testing (from unit through final business acceptance)

Simply having resources “engaged” from these disciplines does equal success if the engaged resources lack competency in their discipline and/or knowledge in their discipline to bring into the project fold.

How practical is it to have strong, competent and knowledgeable resources on every IT project in your portfolio?

I argue it is rare and even if all those resources exist in the same organization, they are assigned to the highest priority and visible project(s) alone. This leaves mid to low priority projects with a less than optimal resource mix.

How do you get timely visibility into when a less than optimal resource mix staffed project team is trending off the optimal trajectory?

You need a project gating system applied to specific projects to strategically pause, evaluate and course correct those specific projects.

I chose the previous statement’s phrasing carefully and specifically to avoid claiming that having a default project gating system as a “silver bullet”1 is the answer. Again, I’m not arguing against Todd’s claim that better stakeholder engagement is needed for successful IT projects. I’m saying the practical application in the real world still requires a project quality gating system due to the inability to have strong, competent and knowledgeable resource.

I have some thoughts on attributes of a more efficient project quality gating system, but I think I’ll need another article to collect and share these thoughts bouncing around in my head.

1. Top notch blog publisher Peter Kretzman on his blog “CTO/CIO Perspectives” has an excellent article on IT “silver bullets” and how to get early indications of projects in jeopardy.