Nelson v3.1

My Favourite Top Ten List of 2011

After spending the last week or so reading 2011 top ten lists, I’ve decided to link to my favourite one. The Top Ten Reasons why Large Companies Fail to Keep Their Best Talent, written by Eric Jackson for Forbes.

The top 10 list runner up is: Toronto.com’s Top Ten Movies of 2011.

Guest Post – Self Organizing Agile Teams: The Fine Line Between Freedom and Chaos

I recently wrote a guest post for www.toolsjournal.com. Check it out:

Self Organizing Agile Teams: The Fine Line Between Freedom and Chaos

As always please feel free to leave me your comments here or on the toolsjournal.com site as well. i love feedback.

Agile Mindset Is Not A Silver Bullet

I recently did a guest post for www.toolsjournal.com. Check it out:

Agile Mindset Is Not A Silver Bullet

As always please feel free to leave me your comments here or on the toolsjournal.com site.

Apps in your Browser … Is it the beginning of the end for the Idea of the App Store?

I just read an interesting article on CNN Money about Mobile Web Apps being developed on Browsers, see Mobile Web apps escape Apple’s iron grip. And it got me thinking about the future of the online app economy. In a few years will anyone download apps to their phone or will they just access it through their browser? Will all of  these app stores continue to grow or even exists? And will the power shift even more towards the developer or will it fall back to the heavy hitters?

The App Store business model is a sound one (Apple, Amazon, Android) all take a cut of the developers revenue for providing the distribution channel, and more recently Apple announced recently that it wants to take a cut of any type of content or subscription sale made through it’s apps. As you could imagine this doesn’t sit well with most developers and from a business revenue stand point if you’re already giving up 30% and then paying taxes and operating fees your app revenue disappears quickly. So developers have started to build apps that are OS agnostic and can run through any of the widely accepted web browsers.

Thanks to HTML 5 we may all be accessing our apps through browsers very soon.

The Only Constant in Life is Change

A Change Management Post by Nelson Bodnarchuk

You know the saying “the only things for certain in life are death and taxes”? Well I like to put more of a positive spin on things and say “The only constant in life is change”. Doesn’t matter what you do for a living, or what aspect of life you’re thinking of when reading this, father time doesn’t stop for any one and change is his right hand man.

The only thing you can really do is take some advice from Bruce Lee: “Be water my friend”.

So what’s the purpose of this post? I just started a new website FitBod.ca, a fitness focused website to help people build lean bodies, and enjoy a higher standard of living. I created FitBod.ca to help cut through all of the misinformation around getting in shape and making progress towards one’s fitness goals. It’s quite a bit different from my past ventures in Business and Consulting, and that’s what makes it so damn exciting. I was also looking for an excuse to post something that included the wisdom of Bruce Lee…making this post a win-win for me.

Have a good one.

Idea’s Around Agile Development

“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?

Success: A Road Map … It’s Not What You Think, or Maybe it is.

Disclaimer: None of these are my ideas and the full document can be found here: Quick MBA, I just wanted to capture a summary of these for future use. It’s based on the #1 bestseller, The 7 Habits of Highly Effective People, by Stephen R. Covey. My summary is actually a summary of a summary, I goal is to distill this information to it’s core. Call it laziness, call it efficiency… call it karma Ray.

The Seven Habits move us through the following stages:

1. Dependence: the paradigm under which we are born, relying upon others to take care of us.
2. Independence: the paradigm under which we can make our own decisions and take care of ourselves.
3. Interdependence: the paradigm under which we cooperate to achieve something that cannot be achieved independently.

The 7 Habits of Highly Effective People are:

Habit 1:  Be Proactive

Change starts from within, and highly effective people make the decision to improve their lives through the things that they can influence rather than by simply reacting to external forces.

Habit 2:  Begin with the End in Mind

Develop a principle-centered personal mission statement. Extend the mission statement into long-term goals based on personal principles.

Spend time doing what fits into your personal mission, observing the proper balance between production and building production capacity. Identify the key roles that you take on in life, and make time for each of them.

Seek agreements and relationships that are mutually beneficial. In cases where a “win/win” deal cannot be achieved, accept the fact that agreeing to make “no deal” may be the best alternative. In developing an organizational culture, be sure to reward win/win behavior among employees and avoid inadvertently rewarding win/lose behavior.

Habit 5:  Seek First to Understand, Then to Be Understood

First seek to understand the other person, and only then try to be understood. Stephen Covey presents this habit as the most important principle of interpersonal relations. Effective listening is not simply echoing what the other person has said through the lens of one’s own experience. Rather, it is putting oneself in the perspective of the other person, listening emphatically for both feeling and meaning.

Habit 6:  Synergize

Through trustful communication, find ways to leverage individual differences to create a whole that is greater than the sum of the parts. Through mutual trust and understanding, one often can solve conflicts and find a better solution than would have been obtained through either person’s own solution.

Habit 7:  Sharpen the Saw

Take time out from production to build production capacity through personal renewal of the physical, mental, social/emotional, and spiritual dimensions. Maintain a balance among these dimensions.

The World is Going Mobile Whether you Like it or Not

Just like the headline reads, the world is going mobile, and we’re only at the beginning of it all. I recently read somewhere that 80% of mobile users check their social networking status before turning off the lights in the their bed at night, and it’s the first thing they do when they wake up. When you’re on public transit how many people do you see using a mobile device? In our quest to consume more information, mobile devices help to fill the gap between us and the information that we’re looking for, it doesn’t matter if it’s a movie, a train schedule or your Facebook feed.

Enter the mobile device with it xG or WiFi Connection.

As Apple, RIM and others continue to grow their App Stores, while more and more people start using their mobile as their primary internet connection, mobile devicesa re going to out pace PC’s in sales within the next 2-3 years. So what does that mean for anybody involved in software development? “Anybody” being basically everyone, if you use software and send feedback to the provider you’re part of the process. It means that there’s a massive need for more and better mobile software.

I know, I know, pretty obvious right? Maybe not, the Mobile Internet and Mobile Marketing channels have been described as being in the same state as the Internet was back in 1994. Lass than 25% of businesses are engaged in Mobile Marketing. The big question is “WHY”? Could it be the time or the money involved, or is it the collective lack of understanding of the potential that exists in directly marketing to a persons mobile?

In 10 years (2020) will we even have PC’s or will they have been replaced by their mobile counter parts and have a wireless connection to different I/O devices. I see my mobile as a way to learn more about what’s going on in my city, connect with my social circle and do business.

Take Polar Mobile, they’ve grown exponentially over the last year, and there are others joining the game everyday. I’ve worked on mobile development projects with price tags that are in the mid 6 digits range and it doesn’t look like things are slowing down anytime soon as mobile devices are estimated to outnumber people at least 2-1 in most places in the world today. Don’t believe me? Search “Mobile devices outnumber people“.

This may concern some people, after reading some of the headlines about where our collective priorities lie. But I’m not here to start a political debate about the number of people with mobile devices that don’t have access to toilets or clean water in the 3rd world or what day in the future the mobile devices will become sentient and try to eliminate or enslave the human race. I’m just amazed at how our need to connect on different levels and find a sense of belonging in the universe has translated into the birth of the mobile web. Anyway you look at it, we’re in the golden age of opportunity and mobile is the new wild west.

Real Software Engineering & The 5 Why’s

Here’s an interesting video that was sent my way recently discussing why software engineering, as it’s being taught in Universities, doesn’t work. By not working I mean, it doesn’t produce high quality software for a low cost and sometimes it doesn’t produce working software at all. Check out the video here:

I’m not one to use only one methodology, I like leveraging techniques that work and prefer whatever gets the best ROI for the problem identified, call it Agile, call it Spiral, call it Water Fall…call it Karma.

That said, I’m a big fan of Lean tools as they work in both the manufacturing and software industries where I’ve seen their benefits when implemented properly. If you’re looking for a place to start implementing these types of tools for little to no cost impact on your budget try holding a “5 whys” session with your client to fully understand what the root cause of their problem is. For those of you living in a more reactive environment you may have heard of Root Cause Failure Analysis (RCFA), this is essentially the 5 whys after something has seriously gone wrong. Try asking the 5 whys at the front end of the development process to fully define what the problem is before moving forward with developing a solution and I’m confident that you’ll see a positive step change in your development process. By clearly defining the problem and what it means to be complete your developers will have the understanding and a clearly defined goal to work towards. There is obviously much more that you can do to improve things within your development process, however people tend to adjust to small changes more efficiently compared to one big change. As Doc Brown would say “You’ve got to think four dimensionally”.

For more information on the 5 Whys and an example: Check out any of the following links:

http://blog.carbonfive.com/2010/01/agile/recipe-for-5-whys-with-an-agile-software-team

http://en.wikipedia.org/wiki/5_Whys