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.

E-mail | Post RSS Permalink | Comments(3)

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.

E-mail | Post RSS Permalink | Comments(1)

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!

E-mail | Post RSS Permalink | Comments(1)

I was reading through some updates on a few social networking sites.  When I came across a link posted by one of my friends, Josh Minton,  who posted an article by Aaron Levie, the CEO and co-founder of Box.net.  The article titled How the IT department co go from zeros to heroes.  The article jumps around a bit but the essence of the article is this.  The cloud represents an opportunity for users to use whatever technology they want because, when given the choice, they will utilize technology that will ultimately make them more productive.  IT just needs to get out of the way. 

I think it’s expected that Aaron Levie would make a claim that the cloud is 100% good and if you’re not moving that way you and your customers are missing out.  Don’t get me wrong.  I think the cloud is great and a real opportunity for companies to leverage great software that would either be too expensive, difficult to manage or don’ have the expertise to create themselves.

However, there are three key problems that I have with the way Levie justifies opening up the purchasing and management of software purchases to business unit owners.  The first is that resources, I’m referring to money here, is a finite resource.  Purchasing and managing software is a process and a skill that takes time to learn and master.  Your IT department should have enough experience in this area to make sure that you are getting the best value for your dollar.  Believe me, in the world of Enterprise software everything is negotiable and you need to have knowledge of all the levers you can pull to negotiate the best deal. 

Secondly, Levie cites some Forrester research that finds this type of purchasing is already prevalent:

"Especially in firms where IT is seen as plodding and cumbersome to work with, the new price points and preprovisioning of SaaS and cloud will foster renegade buying by the business."

If you find yourself in this position I would simply start by addressing why your IT organization is viewed by your business partners in this way.  Something is clearly broken and needs to be addressed.

The last issue that I have with this thinking is that IT is in a unique position to see how the enterprise operates end to end.  Many business units work in isolation.  Sales doesn’t always fully understand or appreciate what information the accounting department needs to do their job effectively.  My experience has been that everyone always looks for a software solution to fix any gaps that a good old communications plan can fix for free.  Allowing each department to independently choose a solution without consideration of the larger enterprise needs will do nothing but perpetuate the inevitable ‘brokenness’ and siloed cultures that you see in some organizations. 

E-mail | Post RSS Permalink | Comments(5)

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

E-mail | Post RSS Permalink | Comments(0)

Now that’s it’s late December I’m reading, and interested in, all of the top 10’s.  We have a phenomenal amount of technology and data points at our fingertips.   However, this is my top 10.  Nothing scientific.  Just thoughts as I think about the last year.  So here it goes:

Confession:

1. I really like my Windows 7 Phone.  I don’t get why other folks blew it off
2. I hate printers.  For crying out loud.  It’s 2010, can you not get paper to feed correctly or for that matter get the drivers to work?
3. I don’t hate Apple.  I hate Steve Jobs.  You with me Adobe?
4. When you are a software guy, there is no substitute for good infrastructure guys.
5. I get ‘the cloud’.  While you are trying to understand it, I’m trying to figure out how to make money off of it.
6. Lawyers don’t get open source.
7. I think Kinect and the iPad are the two most significant gadgets in 2010. 
8. A good technology team can add a few million to the value of your business.  A great one can exponentially add multiples.
9. All great teams get arrogant.  Your challenge is to manage the intensity of it.
10. Great technologist live everywhere.  Develop a team and a methodology that utilizes the best of the best.  The best are all around us.

Anything to add?

E-mail | Post RSS Permalink | Comments(1)

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. 

E-mail | Post RSS Permalink | Comments(0)

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.

E-mail | Post RSS Permalink | Comments(0)

I’m sitting here on a Friday night doing what all geeks do.  Reviewing blogs and of course catching up on Dzone.com!  I was checking out the top links section when I came across Jared Richardson’s recent post ‘You’re a Bad Manager, Embrace It’.  I have to admit I’m a little shocked at his article as a sort of bitter commentary on the state of IT management.  I’m the first one to tell you that the future of IT management concerns me as well but as someone who does manage development teams I would like to provide some insight.

First some things I truly believe as a manager:

Developers are professionals, treat them as such.  They didn’t get to where they are because they are incompetent.  If you hired right, they are better than you ever were as a developer.

The team is everything.  You fail as a team and you succeed as a team. 

Promote your teams, always.  Your job as a development manager is to maximize your teams opportunities.  This is distinctly not a team sport.  If you fail at this the blame is solely yours.

Protect the team.  Distractions like office politics, budget fights and general obstacles keep the team from doing what they do best:  be development professionals.   Your job is to clear the field so the team can perform to the best of their abilities.

The funny thing in reading Richardson’s post is that I can see where some of these frustrations come from.  However, I’ve worked with very few inept development managers.  Perhaps I’m just lucky but I think as someone who has spent some time in management I can see both sides of the coin.  Let’s start by examining some of his thoughts:

“When your team gives you an estimate for how long they think work will take, you always reduce it. By dropping 25 to 50 percent of the time, you like to think you're pushing your team to do their best. We all work better under a deadline, right?”

Estimates are just what they are.  Estimates. We all play this game everyday. Whether buying a car, getting work done on the house or even doing a personal financial budget.  Management wants something. We, as in the team, want the appropriate amount of time and money to do something the way we want it done.  Your job as a development manager is to translate for both sides.  Simply slashing time or taking an estimate at face value is wrong in either case.  If you have no negotiation skills than perhaps management is not for you. 

Perhaps the most annoying, and perhaps dangerous, argument is the one that Richardson makes next (I’ve heard it at least a dozen times):

A typical developer, after you factor in benefits and the overall cost of employment, costs you from 150,000 to 200,000 dollars a year. If you have a ten person team, you can buy them extremely high end workstations for around $3,000 each. That's $30,000 a year to save two man years. Does that sound like a good investment?

I agree with this but there is a hard reality that every developer (and management hopeful) should know.  I would like to set a scene for everyone reading this.  You as a development manager go to the CIO or CFO and explain this great opportunity to increase productivity.  The CIO or CFO have read the latest article in CXX magazine about the benefits of offshoring.  They won’t even get to the saving of two man years.  They will just see the $150,000 to $200,000 cost. Personal experience tells me that you don’t want to spend the 100+ hours of power point presentations justifying the value of your locally based team.  Trust me on this.  There are better ways to get the equipment you need.  You just need the ability to translate the need without exposing the team to risk.

Now something about rewarding the team:

Speaking of rewards, like most bad managers you reward your developers individually. You provide bonuses and raises to the top performers, and less for the middle, and none for the "low performers". Then you stand back and wonder why they don't perform as a team. Why they refuse to help each other and compete with each other.

This gets back to the culture.  The team is everything.  Perhaps I should have made this # 1 on my list.  Great development teams self organize.   Developers know who are top performers and who are not.  This does not mean that you only reward the most experienced.  You reward the top performers at every level, entry level, mid’s and sr’s.  I have yet to manage a team where the top performers allow the ‘low performers’ to bring the team down.  They always pick up the ‘slack’.  Your job as a manger is to know who the top folks are and get their input.  No top performer wants to work with someone not pulling the team forward.  It’s a team effort.  Drop the weight of low performers and increase team moral by demonstrating that your more than willing to cater to the self organizing and self managing team’s wishes.  They are after all, the best suited professionals to make that determination.

I’m by no means saying that Jared Richardson’s article has no merit.  I’ve heard plenty of management horror stories.  Bad managers are out there.   I respect his attempt to shine some light on what it takes to build great teams and look forward to more of his posts!. 

E-mail | Post RSS Permalink | Comments(2)

I have a confession to make.  I love what I do for a living.  I’m one of those fortunate few who never really has to work a day in his life because I love what I do.  At times I feel guilty when people ask what I do for fun and I have to make something up  not related to IT.  The fact is that no matter what hobby I pick up all I can think about is what website or technology can I create to augment my enjoyment. 

A little background story on this post.  I was speaking to a few friends the other day about volunteering to teach a practical computing class in secondary school or even offering internships.  The feedback from the friends (all who were teachers) is that they really don’t offer that today. Apparently, at least in Texas, the barriers to entry is a bit overcoming.  It’s clearly an underdeveloped program.  We can do better and let me tell you why.

When I was in grade school my mom actually volunteered to teach a Basic class.  No kidding.  She taught the class to a bunch of 4th graders (if I remember right).  I was fascinated.  I grew up with a mother who was an AS400 programmer.  I distinctly remember during her college years playing with her ‘punch cards’.  Now that I have kids who type on my keyboard when I’m not present I have a new appreciation for KID (Kid Induced Defect).  It’s no wonder she has a full head of white hair (sorry mom).  We always had technology in the house, always.

No kid wants to follow in their parents footsteps, and I was no exception.  To top it off according to my math scores in High School I wasn’t cut out for the Technology field.  I just didn’t get it.  I went to college to be a teacher and then finally I wanted to be a lawyer.  I accomplished neither.  I came out with a degree in poly sci and international relations.  Clearly a great setup for working in a single flavor snow cone shop!  However, I never stopped ‘messing’ around with Technology.  It was something that I actually knew more about than most kids my age just because of my exposure to it.  If there is “classically trained” then I was clearly un-classic. 

I came out of college a few years before the dot com incident (that’s what I call it now).  A great time for someone like me to find my calling.  I was there to see the web grow up.  Not to mention I was one of the lucky few who knew how to make my 14.4 kbit/s modem work by adjusting the IRQ settings.

So what does all have to do with wanting to teach gum chomping students who are more interested in using the iPhone than knowing how to leverage it?  It’s all about exposure and making the conceptual relevant.  Technology is everywhere.  It’s also an exponential multiplier of productivity and profitability.  Clearly an advantage in the ‘real world’.  The pace of innovation is incredible.  Think about where we were in terms of storage and processing power 5 years ago?  The laptop I’m typing this on has exponentially more capability than my TV,  phone, DVD player, camera and alarm clock combined. 

I think we should be, at a bare minimum, exposing our students to the magic behind the curtain if you will.  An exposure to programming and it’s practical application will help more than it will ever hurt.  I teach an ‘Intro to SQL for Analyst’s’ class at the company I work for.  It’s often filled with financial analysts who are realizing that a spreadsheet is no longer sufficient for doing the types of analysis they need to do the job.  More importantly, their current exposure to technology tells them that there must be a better way to get the answers they are searching for and need. 

So, let’s arm our students with at least the foundation.  I guarantee at some point they will use the exposure to further their positions and knowledge.  The technology community is filled with bright, passionate and dedicated professionals.  Let us volunteer to teach our next generation of colleagues!

E-mail | Post RSS Permalink | Comments(6)