Enterprise Agile Transformation Reality Check: The limits of “cookie cutter” enterprise agile transformations

Accomplishing a lasting enterprise agile transformation requires more than some budget, superficial PMO support, some certified scrum masters and lukewarm executive sponsors.

Lasting agile transformations are an enterprise culture change, where all key leaders, stakeholders and organizations must be open to genuine introspection and collaborate in a flexible manner. If the organization is not prepared to leave their respective comfort zones and embrace agile values and principles, a different set of software development practices will likely produce minimal desired productivity, creativity and cross functional alignment results.

Agile transformation work is indeed a four letter word, and an effective and long lasting agile transformation requires genuine leadership, engagement, grit, openness and energy. When organizational leaders (business, product management and software development) and team members bring these assets to the table, amazing results, shifts and empowerment can occur!

Agile design and development principles meet enterprise IT infrastructure: The irresistible force meets the immovable object!

From enterprise data warehouses to OLAP cubes to Cassandra and mongo dB analytics platforms, we are not in Kansas anymore. Agile teams and practices are being pushed and prodded and pleaded and threatened by business units with unrealistic time to market needs, CIOs with enterprise class legacy system obsolescence and frustrated and overwhelmed architecture VPs – how do we apply agile principles and practices to these super-sized work efforts?

Do 2 week iterations apply to our work, or can we make them longer?  How much documentation is appropriate for this class of work?  How do we create vertically slices stories that can be implemented in iteration?  How do we test these technical or infrastructure stories?  How do you express infrastructure work as business user stories, and how should the narrative be written? How can we support iterative product development and still design our platforms and services for high availability, scalability, maintainability and reasonable TCO (total cost of ownership)?  The questions never stop, and these challenges are real and these folks need help; and they need it now!

Product management leaders and executives want to understand how agile methods integrate with traditional UCD, UX, Ideation and Discovery work.

QA leaders want to understand the agile approach to automated unit testing, manual and automated functional testing, integration testing, stress and load testing and user acceptance testing.  And how do all these levels of testing work together, what should be completed in a specific iteration, and who owns what anyway?

The life of an enterprise agile coach or agile program manager is never boring, and it is rarely simple.  In the coming weeks this blog will explore practical thoughts and solutions to address these “upper division” agile topics and challenges.

Cheers and Happy Monday,

Paul

2009: A few observations / lessons and good riddance (don’t get mad, get even)!

As 2009 winds down to a merciful close, I think maybe a few comments may be in order.  (Or at least not out of order?) With IT professional services bill rates as low as I have seen them since them since the early 1990’s, I will not be mourning the passing of this year, etc.  The ironic thing is that margin aside, there was some excellent work done in 2009, and I was indeed grateful for the opportunity to be working on some significant enterprise programs.

It is interesting to see that the biggest tech industry winners are the companies that have taken new technology (Apple, RIM, Salesforce.com, etc.) and helped push it from the early adopters to the mainstream.  How the iPhone has been able to enjoy such incremental success while the country is mired in the worst depression since 1929 is indeed curious!  Nevertheless I do think 2010 will be a very strong / bounce back year for the mainstream IT industry.  The fortune 1000 and many middle market companies have little choice but to continue to invest in upgraded infrastructure and new product development as these organizations cannot broaden their product offerings and improve worker productivity without such investments.  A fascinating reality of the world wide and North American economy in my opinion is that economic spending, recovery, etc. continues to be regional and industry specific in nature.  Those workers who are nimble enough to position / reposition themselves in the medical, green or tech industries in 2010 should have a very solid year (my pipeline of new opportunities is as strong as it has been since the spring of 2007).  Those in construction, automotive or even commodity service sector are likely in for another difficult year.

Another very promising trend from 2009 is the continued growth and penetration that Agile and Scrum methods and techniques are having in main stream fortune 1000 and key middle market organizations! Indeed more organizations than ever before are awaking to the potential benefits of Agile product development.  The corollary to this is that most of these organizations are moving steadily and slowly up the learning curve to become effective agile organizations!  There is still more improvement and maturity required before many of these organizations will truly accomplish much of what agile offers them.

The bottom line for IT service providers and skilled engineering labor is that deep and broad skills and experience are still in significant demand, and will be busier in 2010 then 2009. Rates have already begun to bounce back!  For those who are just entering the industry and trying to develop a solid foundation of Agile technical skills, the best strategy this year will be to focus on getting real world and useful agile experience and work.  Although the compensation for this group will still lag, it will pay off in the due time for those who can hang in there!

Cheers and best wishes for the year ahead!

Paul Reed

Scrum 201: Mastering agile development and continuous integration and testing processes.

As scrum teams develop and mature, it becomes very clear that some aspects of agile and scrum are much easier to learn and master then others.

Sprint Planning, the daily stand up, and writing and sizing user stories, etc. can be learned and well practiced by teams within a reasonable number off sprints.

Other concepts and skills required to effectively implement scrum have a longer learning curve and require substantial changes in development and testing approach, technique and what is considered possible or normal!

This issue cuts right to the heart of what is different between waterfall and agile, and even requires smarter, more creative developers and testers that are actually will and able to communicate the details of their approach, work and progress to their team members on a regular basis.

To further complicate things, many large enterprise computing platforms have become very complex with many loosely to not so loosely coupled tiers.  (OS, DB, App server, Web Server, BUS or Information Broker message routing, Security brokers, WSDL’s and other web services components, etc. etc.).  The number of tiers and the complexity associated with their end to end execution can overwhelm and intimidate many testers, and make it more difficult for them to understand how to approach functional testing before the entire solution is delivered in its entirety.

Success in these environments requires more sophisticated tools and test harness software for automated regression testing, web services testing, etc.

Patience, technical leadership and a real understanding by the team that we “succeed as a team, and fail as a team” is required before real progress can be made.   Testers, developers, designers and architects must work effectively together to devise effective “white box” tests that can chip away at the validation of the overall solution while some or many components are still under development and not yet delivered.    This stuff is the heavy lifting required by scrum team to significantly improve velocity once the low hanging fruit has been picked.  In future posts I will share some techniques I have appreciated to help teams accomplish these goals.

 

Welcome to Paul Reed’s Agile Software Development and Project Management methodology blog!

Hello, and welcome to Paul Reed’s Software Development and Project Management methodology blog! (What, there are not enough of these available already)

In the upcoming weeks and months, I will be offering commentary, insights and hopefully providing a little humor and stress relief associated with the world of Enterprise IT management (oxymoron?) and agile software application development methodology.

What is true is that after almost 30 years of continuous employment within our field, I have performed most of the job roles within IT and IT consulting, made all of the common mistakes that a person typically makes (and a few uncommon ones too!), and worked  with about 50 companies across north America, Europe and Asia!

At the best I will offer real world insights and analysis into complex issues and problems associated with agile project management and Scrum software development methodology.  At the least I can let you know a few great places to check out when you are working in Des Moines, London, Ft Lauderdale, Reno, Charleston, Hyderabad or Montreal.

Also, please feel free to let me know when I am in your opinion way off base,  full of it, or particularly insightful!

Thank you, cheers and warm regards,

Paul Reed, PMP, CSM, CSP