Just in case you haven’t noticed the explosion of devices and consumer based applications is beginning to challenge IT departments.  Do you allow your employees to use their own devices?  What about applications?  How do you deploy and manage security?  These are all questions that just about every IT shop in the world is having to answer.  It doesn’t matter if you’re a multi billion dollar conglomerate or supporting the local church.  The consumerization of IT is here, and I predict here to stay. 

The question of managing this phenomenon is not if you should allow it.  That battle has already been fought.  Devices and applications are being used because they are convenient or introduce efficiencies.  You cannot stop this wave.  Imagine being the head of a pager company and you just saw your first cell phone in action.  You need to start making cell phones, not scoff at the idea that cell phones will never catch on!  The real question is how do you take advantage of this movement.

Make no mistake, this is a paradigm changer and you need to think of ways to take advantage of this.  So what in the world am I talking about?  I remember when I first started working in the 90’s.  You hardly ever saw a laptop.  They were reserved for the ‘high-ups’.  They were cool and a status symbol.  Fast forward 10 years and now all you see is laptops.  They are now the standard of a productive work culture allowing people to work from anywhere, and unfortunately for this guy, at anytime of the day or night.  Laptops stopped being a status symbol and the hallmark of productivity.   They changed the paradigm. 

Today we have devices and applications that take full advantage of sleek form factors and the cloud.  Paradigm changer?  No doubt.  I, myself, own 3 laptops and two iPads.  I have the ability to work from anywhere and at anytime.  Couple that with some slick collaboration apps like Lync, Skype, Facetime and a host of other cloud based collaboration utilities there is no need for me to go into the office.  So why do we continue to build applications, corporate infrastructures and offices like it’s the 1990’s?  Do I really need a cube, an office or a desk phone?  No, what I need is a power strip. 

So what is the next model?  The next laptop transformation?  First, I think IT needs to look at how we allocate IT assets.  Why buy me a laptop?  I have three.  And they are far superior to the one you will probably provide me.  Why not give me a stipend so I can purchase my own equipment?  Why not give me a stipend for being an employee?  Chances are if you are like me you even dislike the office supplies!  I’ll buy my own pens and paper! 

Imagine how that would change the way you not only build out an office, but your approach to building business solutions!  Your external customers and internal customers become one in the same. All rely on the ability to use your product anytime and anywhere.

I’m probably one of the biggest fans of Agile.  Not because it’s one of the hottest things going on right now in the development community.  I’m big on Agile because I’ve seen what it can do for teams and organizations first hand.  Transformational would be an understatement.  Unfortunately there are plenty of shops out there not realizing the benefits that agile can bring.  They are practicing a faux pas version of it.  Let’s just call it ‘iterative’.  If you think you might be doing this type of Agile than this post is not for you.  This post is about the next level of Agile.

Those of us that have seen true Agile in practice will tell you that at the end of the day you’ll be left wanting more.  Clearly this practice can be applied to a larger audience.  Clearly every company should use Agile for everything!  Agile is more than the considerable uptick in productivity, quality and customer satisfaction!  To borrow from the extreme sports community:  Go big or go home!  I think I echo most of my colleagues when I say this.

I have news for us Agile advocates.  The business side of the house has been looking at Agile based methodologies much longer than we have.  I’ve known this for sometime, but I recently came across an article in Forbes where the author, Dan Woods, speaks about the marriage of Lean Manufacturing and Agile Development.  Agile is not Lean and Lean is not Agile.  Their approach to iterative improvement, removal of barriers and fail early- fail often approach is a best of breed. 

Woods makes an interesting statement at the end of his article:

In practice, Agile seems to be changing for the better by adopting Lean thinking in a large way. Rally says that its customers get to market 50% faster and are 25% more productive when they employ a hybrid of Lean and Agile development methods. Given the way that Agile fits in to the Lean framework, it wouldn't surprise me if before too long Agile is considered a branch of Lean practice tailored for the software industry.

I’ve written many times about the importance of business and technology coming together to create the best value.  This is by far the most common ground I’ve seen.  I agree with Wood, I look forward to the child of these two methodologies.

I’m going to tell you a story about how I almost failed as a manager.  I say almost because it was only because of Bob Smith that I recovered and really understood the error of my ways.    Bob is a factious character because the innocent should be protected.  However, the situation is real and the lesson is a good one that I would like to pass on. 

One of my first experiences managing development teams was an incredible opportunity. I was young, enthusiastic and motivated.  I inherited a team of folks with great capabilities but a relaxed attitude towards owning issues.  I’m positive we were not the first shop to experience this!  During the first few weeks of taking over this team I hired Bob as a replacement for a team member who left just before I took over.  Bob was my first hire.  Bob is an incredible technician.  He knows code, architecture and the urgency of our craft.    

I think I’m preaching to the choir when I say that inevitably there will be an issue in IT.  I, as a young manager, experienced this within two weeks of Bob coming on board.  I remember it clearly.  The guy Bob replaced left a code base and an architecture platform that, well, let’s just say was suboptimal.  I called everyone into a room and said this is the ‘hottest’ issue.  Let’s dedicate all our resources to getting this solved.  I got a lot of blank stares.  Bob however, was the guy on the beat.  Within five minutes he knew what to do, how to solve it and what needed to happen.  I was in love.

We were a young shop and there were about two more ‘major’ issues that came up within the next six weeks.  Each time I leaned on Bob.  He was my go-to guy to fix the issues that the team couldn’t address, with his help we  satisfied the customers and pleased the execs.  Then came the dreaded lunch!  Bob and I went out to lunch and he let me know that he was thinking about leaving the company.  Imagine my face at this point.  Bob was my get it done guy.  However, it was exactly why Bob wanted to go.

Bob had other ambitions.  None of them having to do with fire fighting others misfortunes.  Bob was a team player, but in his words (Bob doesn’t speak the best English so this is the best translation)  he said “I’m always willing help out, but you need to help others know how to win”.  Prolific need I say more!

What I learned from Bob is that teams need to learn how to fail as much as they need to learn how to succeed.  Winning feels good, I think that anyone that’s been a part of a winning team can sense what a winning team ‘feels’ like.  You just know.  Failure is the same.  You just know when something doesn’t feel right.  Winning and losing is intrinsic in our psyche. 

Failure is painful but inevitable in our business, just as much as success is.  The problem is that most people, as a team, don’t know what it’s like to manage through ‘failures’. It’s not natural.   We naturally separate into individuals when we sense failure.  The whole ‘It’s someone else's problem’ is a common reaction.  Arguably it’s a healthy reaction designed to help us cope.  However, in our business, the business of providing technology, it’s a toxic attitude because we can only solve problems as a team. 

Bob taught me that when a crisis occurs hold the team accountable.  The easy way out is always rely on Bob to fix the situation. Bob is not the long-term fix.  The team needs to know what pulling yourself from failure ‘feels’ like just as much as they understand what success ‘feels’ like.  Just like people know what ‘winning’ and ‘failure’ feels like, your team needs to understand what pulling success from the jaws of defeat feels like so they can repeat the behavior each time something goes wrong.  It's like muscle memory!

Agile is an incredible methodology for running IT projects.  However, at times you are asked to come up with a swag as to how much money and resources it will take to complete a project.  Modeling the complexities of resource requirements, time and expense can be difficult.  I recently put together a spreadsheet to assist in this activity.  I had every intention of moving this to an online application, but do to time constraints I have not had the time.  So I’ve decided to release this tool in, gasp!, Excel.  Please feel free to use as is, but if you beat me to creating an online tool at least put a link back to my blog!

First, a quick explanation of how the tool works:

Only edit the light blue fields

1.  
   1.  
      1. Story Points Total – Total story points the team estimated for the entire project
      2. Time Frame (Months) – Sometimes the business expects that a project needs to be completed in a timeframe.  This cell allows you to calculate that.  The warning here is that you need to be realistic.  9 pregnant women can’t have a baby in a month.  If you don’t understand that statement than you need to cease and assist the use of this tool immediately!  Advice:  Just be realistic.
      3. Blended Resource Rate – The blended rate of all available or projected resources.
      4. Contingency – This is a swag.  Enter a % of ‘play money’ to each side.
      5. Story points conversion – Agile purists hate this.  But in some situations you have to convert a story point into an hour estimation.  This field allows you to estimate time to quote.  More importantly it allows you to model scenarios.
      6. Headcount – The Dev line item is automatically calculated.   Remember, you are trying to back into the number of developers you’ll need and the amount of money you will need to complete the project.  Developers are the big unknown.  Other resources are fixed or can be calculated as a ratio (i.e. One QA professional per 3 Dev’s).   Again, this also allows you to model resources needed to manage the number of dev’s you are calculating.   Add your PM’s, Scrum Masters, QA people here.
      7. Capital Hardware – It costs money to run this new stuff.  Add your costs here.
The three columns related to cost and number of resources models out the amount of dedicated resources.  Dedication is an estimate.  Your resources will go to meetings, use the bathroom, etc.  One thing I will guarantee you, they will not be productive 100% of the time.  I’ve found that the team is productive between 80 and 70% of the time allocated.  Use these columns to provide a range.

Download the file here

This is one of the best SCRUM overviews I've seen in some time.  Just thought I would share.

Video originally posted by: Axosoft.com

I regularly get asked by people just entering or interested in the Technology field what my best advise to a budding technologist would be.  I hate that question.  There is so much to know and so many experiences to share.  How do you boil that down to one elevator pitch?  Someone queue the music: I’ve given a ton of horrible advice.

I’m pretty sure that to most of those outside of our industry pride of ownership is a good thing.  Society encourages people to buy houses, start businesses, etc. All thinking that this will lift the community because people have a ‘pride in ownership’.  In other words, because they own something they will continue to invest in it to make their property better. 

However, I believe, that pride of ownership in our industry is toxic.  I have noticed over the years that pride of ownership in technology leads to two things, terrible product delivery and stunted innovation.  Product delivery constantly fails because your developers are taking liberty with the code.  They are going to try to pay back some technical debt because they think or *know* that if they just had another ‘crack’ at that function or class they could improve it.  Stunted Innovation occurs for much the same reason.  Why look at other technologies?  Your team or yourself is completely engaged in the current paradigm.  If you change you kill your baby.

There is no doubt that the technology team plays an integral part in creating value for the organization.  As I’ve blogged before this is what IT’s value proposition is.  However, as a technologist, you need to realize that the product you created is the product of Technology, Marking, Sales and Customers coming together. Also known as business value.  The technology doesn’t belong to you.  It belongs to the organization. This is the difference between great companies and great failures.

Sounds harsh?  I mean your or your team created the product? But it didn’t.  The product was a successful implementation of the businesses needs.   To put it simply, You were the doctor in the delivery room.  There were a cast of others that had the same level of commitment and smarts to help give birth to the product.  I think I can speak for most of us when I say just be thankful that we walk out with clean shoes!

If, as an organization, you think that you have a pride of ownership issue please feel free to contact me. Once you are free it’s the most liberating and enabling existence of IT. I’m happy to evangelize. 

I’m not sure if you’ve heard about the recent TSA controversy regarding John Tyner and his recent visit to the San Diego airport.   For those living under a rock John Tyner refused an intimate pat down after refusing to go through the ‘Naked Machine’ (There’s another name for it that I refuse to print here).  You can spend all night reading up on this, but I need to Segway back into how this applies to software development.  So here it is: People understand procedures and rules are for the greater good, but when it stops providing value or begins to violate reason than you are doing more harm than good.

This is where the TSA and IT Governance have something in common.  John Tyner set off a national outcry regarding the use of some of these techniques designed to keep us safe.  There is no doubt that ‘Naked Machines’ and intrusive pat downs will keep the flying public safer than not having them.  But at what price?  Personal privacy, longer lines, inconvenience, etc..  At some point someone was going to have an issue and set off a fire storm.  The end result, in my opinion, will be an extensive review about the effectiveness of these searches and political pandering that will end up reducing the ability of the TSA to keep airline passengers safe.  One sure thing is that the TSA will suffer a reduction in public trust and ultimate legitimacy as a public safety entity.  Move over IRS and The Post Office, there is now someone more hated.

Unfortunately I’ve seen these same types of events (although everyone was clothed) happen in our industry. IT Governance and PMO organizations have a tendency to think that adding more process or rules is a good thing.  After all,  they initially improved processes in the past.  However, there is a tipping point where the implementation of more rules ultimately ends to less impact.  Ultimately becoming detrimental to the very SDLC process you seek to improve.  Then, everyone starts to question the effectiveness of the PMO or IT Governance.  Essentially leading to IT Organizations have their own John Tyner moment!  The result is the same.  Good intentions end up having the opposite effect of which they were intended.

My advice to IT Governance and PMO organizations is to constantly reevaluate all your polices.  A mature development organization should, in most cases, have less policies and procedures in place than one just starting out.  You need to constantly evaluate your maturity level as an organization and make adjustments.  Prejudice should be placed on removing roadblocks, not creating them.   Don’t turn your development staff into a bunch of John Tyner’s.

I’m not typically a person that takes issue with someone or some else’s post on my blog.  I’m of the opinion that blogs are there to put forth your ideas.  However, I happened across two posts today, one that references the other. One I disagree with and another I agree with and have more to add.  The one I disagree with is not out of spite, but I think it perpetuates some false assertions that, can and do, hinder the progress of something both the author and I strongly hold true.  The articles I reviewed were Introducing New Technology in Agile by Paritosh Ranjan and 5 Reasons NOT to choose a Technology by Ellyssa Kroski.

The first point that caught my eye on Ranjan’s article was the generalizations about Agile. 

Generally Agile projects are of very short durations. So, introducing new technologies in such a small time frame is always risky.

I will first start off by saying I can’t qualify what a long duration is.  My assumption is that a short duration is less than a year.  I would argue that Agile is exactly the methodology for introducing a new technology.  Agile, in principle, is setup to manage just that, risk. 

The second point Ranjan points out about Agile is that:

In Agile, the team size is pretty small, so if only one person keeps working on the new technology, then the team becomes dependent on him. While pair programming the knowledge about the new technology also distributes in the team and the team has a balanced truck number.

I don't mean to be awkward here but we are talking about two birds of the same flock.

And then there is this:

Most popular open source solutions are extremely well documented and a variety of free and commercial technical support options are available. Due to the nature of community development, documentation and instructions are often written from a variety of viewpoints - creating well-rounded information, instruction and tutorials. In addition, open source projects can't hide usage techniques, due to the free availability of the code. Free technical support is often available in the form of mailing list or newsgroup discussions; nevertheless some background research, knowledge or experience is often required.

Look, I’m a huge fan of FOSS.  And make no mistake I’m a huge M$ fanboy (Another rant for sure BTW).  However, Ranjan’s uses this reasoning to start the argument.

I really like Ellyssa Kroski post.  I wish more people thought like this.  What I would add to the post is defiantly check the availability of talent.  Regional specialties is a real concern.  For example I live in the Dallas – Ft. Worth area.  You will find more Microsoft professionals in Dallas than Ft. Worth.  In Ft. Worth you will find more java folks or specialty IT (Ft Worth is has more manufacturing and Dallas has more ‘corporate headquarters’).  A theory I’m still working on btw.  I would love to see someone produce a demand heat map by city.

I have an opening for a Data Warehouse/ Inmformatics manager and two openings for SSRS report developers.  Please contact me if interested.

No Recruiters please!!!

Agile, in terms of application development or, for that matter, any  IT based projects is the ‘new normal’.  If you’re in IT and have not moved to this methodology I would strongly encourage you take the plunge.  Agile, in itself, is a game changer.  I’m happy to debate anyone who challenges that position.  What about the rest of the business?  Is Six Sigma and Peter Drucker the most progressive thinking when running a business?

I spend a lot of time writing about how and why IT needs to be a more strategic partner in the day-to-day business operation.  It is in fact our value proposition.  So why not take the principals we have learned in Agile and introduce them to the day-to-day business practices?

Let’s take some time to translate the principals behind the Agile Manifesto on how it might apply to business operational principals:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Ops Translation:

“Our highest priority is to to deliver quality products and services expeditiously to satisfy both customer and shareholder expectations”

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Ops Translation:

“The Business climate is ever changing.  You must continually make adjustments to maximize every advantage.”

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Ops Translation:

“Always have a prejudice towards improving value constantly by adding Customer value often and incrementally.  ”

Business people and developers must work
together daily throughout the project.

Ops Translation:

“Your Business needs to operate as a cohesive unit to maximize shareholder and customer value, everyday.”

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Ops Translation:

“Manage to expectations.  Make sure you have the right people in the right positions to ensure success for shareholders and customers.”

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Ops Translation:

“The most efficient way to break down the barriers to success is getting the right people in the room that can remove the barriers to success.  Have those people meet daily.”

Working software is the primary measure of progress.

Ops Translation:

"Become a results oriented organization”

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Ops Translation:

“Continuous improvement should always be a core value and goal.  There should be no “fire drills” when aiming for operational excellence”

Continuous attention to technical excellence
and good design enhances agility.

Ops Translation:

Success is infectious.  Strive for it daily.  Develop a culture of innovation and the framework to support it.

Simplicity--the art of maximizing the amount
of work not done--is essential.

Ops Translation:

“Operational success is not achieved by moving mountains.  It’s achieved by measuring your ability to move a bucket of stone.”

The best architectures, requirements, and designs
emerge from self-organizing teams.

Ops Translation:

“Seek self organizing talent.  Encourage innovation from the bottom up.”

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Ops Translation:

“Build a culture of examining lessons learned.  Your key contributors will always apply this to the next opportunity for improvement.”

 
These thoughts are my first pass at defining how Agile principals might apply to day-to-day operations.  What is your take on how day-to-day operations might benefit from adopting Agile?