Ciske's Blog

Agile with a Little Bit of Lean

Filed under AGILE , Governance , IT Governance , Management , Methodology , Operations , Opinion , SCRUM , Software Development , Technology

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.

Can You Go From Zero to Hero by using SaaS?

Filed under Business , Cloud , Governance , IT Governance , Management , Methodology , Operations , Opinion , PMO , SaaS

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. 

Estimating Project Costs and Resource Needs Using Agile

Filed under Governance , IT Governance , Management , Operations , Software , Software Development , Technology , Agile

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

SCRUM in Under 10 Minutes

Filed under AGILE , Governance , IT Governance , Methodology , SCRUM , Software Development

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

Pride of Ownership: This Baby Is Not Yours

Filed under Business , Education , Governance , Management , Opinion , Software , Software Development , Strategy , Technology

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. 

The TSA and IT Governance

Filed under Management , Operations , Opinion , Software Development , Strategy , PMO , IT Governance , Governance

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.