Should Business Operations Adopt Agile?

by Steve Ciske 24. August 2010 21:25

 

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

Tags:

We Need More Evangelists

by Steve Ciske 7. July 2010 20:51


evangelistboy I am going out on a limb here.  Technologist are not traditionally people persons.  Please insert your own Office Space quote [here].  Technology is a profession I love.  Make no mistake.  But, we have our issues.  The issues have nothing about capability or effectiveness.  We are very good at that providing solutions to problems.  Our problem is self promotion!

When thinking of traditional Technical Evangelists I believe most people picture someone that promotes a platform or a proprietary service such as the ones Microsoft and SUN have employed.  Currently, I believe that Steve Jobs is the best known evangelist given Apple’s recent product home runs.  However, I do believe there is an opportunity for smaller shops, or even your own company, to employ the same strategies to maximize technology value to customers.

I think at face value this makes sense, but just for fun let’s examine some everyday scenarios that support an evangelist position:

  • The pace of innovation is increasing.  You need to be agile in your evaluation of new technologies and how your business can leverage them to deliver a step change competitive advantage.
  • Your leadership team probably interacts less with technology less than your IT team does.  You need to continually bring new opportunities to the forefront at every chance.  Perhaps an evangelist should even be present during board meetings?  Can you imagine; IT being a strategic business partner???  I kid of course.  It’s what we should be!!!
  • Your customers are becoming more tech savvy.  There are no more secrets in Technology.  They have access to the same vendors and solutions that everyone else does.  You need to put someone in front of them that can inspire them.  Leave the sales transaction up to the sales team, build interest and excitement for the product up to the evangelist.
  • Building a product and selling it is just 30% of a launch (my take on it).  You need someone to continually look for ways to promote the product on a micro-interaction level.  Be it whitepapers, speaking at local groups or even through blogging and social network sites.
  • Customers need to be ‘connected’ to the product to build loyalty and honest feedback.  Nothing makes your IT product more replaceable than a customer feeling like they have no feedback loop or someone they can identify with.  Did you notice the recent Microsoft commercials about ‘Windows being my idea’?

So how do you position the need for a product evangelist?  Moreover, how do you convince the ‘brass’ that one is needed?  My current employer does not formally recognize the role, however I believe that each leader in the IT organization informally plays the role.  I think a large part of that is due to the fact that our IT department is viewed as a strategic partner in business decisions and efforts.  For many organizations that’s a tough road to pave.  I’m admittedly lucky.

Those of you seeking to build a case for implementing an evangelist culture I would work to tie the five points above with specific plans or actions to address them.  Building legitimacy is key.  Challenge your current status quo by continuously providing competitive analysis and how you can overcome those challenges by bringing forth new technological advancements.  It’s a small step and the culture will not change overnight.  However, it’s a step in the right direction.  Remember, overnight success usually takes 3-7 years.  Even for Google!

I would be happy to read and repost any stories on how you successfully implemented an evangelist role or culture.  I think this is an important component of IT’s growth and I’m happy to share.

Two Strategies That Can Save Your Career

by Steve Ciske 10. May 2010 20:10


I’ve been busy attending some conferences lately where I’ve had the chance to speak with IT pros across several industries.  What I found most interesting is that even amongst this diverse group there seems to be some common themes of interest and focus.  Sure, we spoke about cloud computing and virtualization, but at a higher level there were two underlying drivers to their strategies.

  • There are no longer any secrets in Technology.
  • Know the true value of IT.

There are no longer any secrets in Technology

This statement sounds odd at first.  However, when you really think about it there are none.  Your competitors have access to the same vendors and technology that you do.   How they effectively put them together might be a secret, but at the end of the day the access is the same. 

So what can you do to compete?  Speed.  How fast can you deliver to the market?  To put the pace of technology in prospective please play the video below:


The video is a few years old, but you get the trend.  Speed is of the essence.  So what do you need to do to be in a position to out ‘speed’ your competition?  Simplify your processes and your architecture.  These are perhaps two of the most taxing aspects of software development.  If you are not concentrating on streamlining these you’re probably not going to out flank the next ‘startup’ looking to capture your customer base.

Know the true value of IT

This one probably hits home to most IT folks who work in corporations.  You need to constantly justify your existence because someone will inevitably ask; What value does IT provide?  I think as a profession we commonly whip out ROI calculations on the projects we’ve completed or SLA’s that demonstrate our ability to meet some number that the business could ultimately care less about (show them that you have a 4 hour window when email goes out and see the reaction).  I hate to break it to you.  Meeting SLA’s and calculating ROI’s is not IT’s value prop.

IT’s value to the business is as an exponential transformational force that underpins all business activities.   It sounds a bit ‘Star Wars’, but let me prove it to you.

If you’re one of the fortunate souls that regularly has to calculate ROI’s for proposed projects you need to ask yourself the following question.  Three years from now will they come back and check to see if the ROI is realized?  If so who gets fired if it’s not?  I venture to guess that the answer for 99% of people is no, and no one.  Need more? Have you ever calculated that a new piece of software will automate X number of headcount?  When have you ever seen that headcount reduced or reassigned after delivery?  No, they just get to do more of the same thing, just more efficiently!

What you need to be looking at is how can you dramatically transform a market or a business process to give your company a competitive edge!  It sounds dramatic, but it’s really very simple. For example:  Why make the ‘order’ entry simpler so people can do more of it?  Why not focus on automation so you can reduce headcount and improve accuracy? 

I know what your thinking.  That should go into the ROI calculation for sure.  And you are correct.  However that is often what I see go wrong.  Too many times business leaders ask to make something simpler or ‘shinier’.  Our value as IT professionals is helping them realize exponential transformations by pointing out opportunities that they might not even think of.  That is the true value of IT!

Calculating Development Capacity

by Steve Ciske 7. April 2010 00:05


273250_18086064 Anyone who writes code is always interested in the capacity (or load) that their system can handle.  For some, including this author, it’s a matter of pride and bragging rights.  However, there is a different type of capacity that is normally overlooked.  When was the last time you estimated your team capacity?

Your team capacity is as equally as important as system capacity.  Team capacity determines how much work you’re getting done and, at the end of the day, how much value you’re giving to your customers.  I think that most folks automatically assume that their team capacity is some magical number calculated based on the number of people that work on the team multiplied by a ‘hours per week’ number.  Although this isn’t entirely incorrect you might be short changing yourself.

So to start, let’s talk about what factors go into team capacity planning.  There’s the obvious, availability of the team.  You can’t factor forty hours a week if your team is also dedicated to other tasks.  What about complexity of the tasks?  There are methodologies out there that can help you plan for that.  What’s missing from the equation?  Simple, budget, talent and infrastructure.  Let’s take a brief dive shall we?

Budget

Most projects have budget constraints.  However, you need to weigh your available budget with time.  I think most people think that if you have 5 FTE’s (Full-time employees) working for six months on a project and it takes up the entire budget you’re probably doing better than most.  What if you have 2 FTE’s and 3 contractors that complete the work in 4 months but still fit within your budget?  What about 2 FTE’s and 3 contractors and it still takes six months?   Is it worth it?  Now you have freed up 3 additional FTE’s!  You now have just added to your team capacity.  You actually end up retaining intellectual property because of your FTE’s, but get the work completed by augmentation.  The pitfall is that typically a contractor will always cost you more.  So you need to figure out what the difference is between time and cost in order to take advantage. 

Infrastructure

Infrastructure is the key to making budget and talent work.  When I talk about infrastructure I’m talking about your team’s ability to ramp up an outside resource.  You need to ask questions like:  How long does it take to setup our environment?  How long does it take for them to understand our architecture?  What software will they need to complete the work?  I’ve seen a lot of talent and budget wasted on this over the years.  If you want to increase team capacity you should focus on the ramp up.  And not just for augmentation, but for your own team as well.  Either way a solid infrastructure adds to your team capacity.

Talent

Talent is probably the most important aspect when considering team capacity.  I’ve spoken about budget and infrastructure.  However, if you don’t have the talent to manage ‘additional capacity’ then you might as well have stopped at paragraph one.  If you follow budget and infrastructure than you need someone to help you manage the additional ‘capacity’.  This is where you need to invest in the team.  Based on my experience, a good senior level technical person can manage three to four staff augmentations (read contractors).  Again, the benefit is that you keep the intellectual knowledge in-house, but increase capacity at the same time.

Conclusion

So what is your true team capacity?  By factoring in talent, budget and infrastructure you can dramatically raise your team’s ability to meet your goals.

Anti-Anti Pollyanna

by Steve Ciske 5. April 2010 23:06


pollyanna_club I was having a discussion the other day about the fact that I often times come across as hopelessly optimistic at work.  Specifically the conversation centered around some recent work and project challenges my team was facing.  Members of my team felt that despite the outlook I always seem to have a misplaced positive attitude.  This lead to a great deal ribbing and a bunch of ‘the man’ jokes.  Make no mistake, I offer no apologies and feel that it’s an important trait of any leader no matter the occupation.  I think more should adopt the trait.

First, a little background on the title.  I was speaking to my wife about the exchange and explained my take on my perceived constant optimism.   After a long conversation she smiled and said you’re ‘anti-anti Pollyanna’.  For those of you that are not familiar with the novel (I had to look it up too) the book is about a girl named Pollyanna who plays what is known as ‘The Glad Game’.  Essentially she finds the good in everything.

So why am I the ‘anti-anti Pollyanna’?  The first is that I have 100% confidence in my team to tackle any challenge.  They are, in my world, the best at what they do.  They are some of the most competent technologists I know or have ever known.  It’s easy to have a positive outlook when you feel that your team can tackle just about any obstacle. 

Secondly, as a manager, the people that work for you hang on to every word you say.  This is not a self serving statement.  People buy cars, homes, and plan for the future based on how they feel about job stability.  Think about the recent interactions with your supervisor.  Has anything they said made you double think your current job satisfaction or worry if there will be a pay check next week?  I would be willing to bet you could think of half a dozen instances.

I think in terms of software development this is even more important.  As Technology managers we have a tendency to think more about brining the current project on time and under budget than the ones we manage.  People are the asset, not the project and not the software.  As managers we invest significant amounts of energy, time and money to the development of great teams.  Bad attitudes and bleak outlooks can significantly reduce your ROI on the talent pool you’re attempting to build. 

Managing people is an awesome responsibility that I think some folks take lightly.  Make no mistake, it’s what you are paid to do and just like everything else in your career you should strive to do it well. 

So am I a Pollyanna?  Yes.  But I’m even more Anti-Anti Pollyanna.