Welcome to the Pacific West Partners blog! This is a great place for us to share our experience in a fun, dynamic way. Feel free to browse through our archives, or select a category for more specific interests. We look forward to your feedback, whether it be from clients, fellow agile practitioners or other interested parties!

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,


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,, 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

Technical Debt: Pay it now, or pay it later!

The concept of software complexity and deferred refactoring as debt was originally coined by Ward Cunningham in an experience report for OOPSLA ‘92. It has since become an industry wide concept and is a commonly referenced and applied when practicing scrum and agile.
Technical debt is deferred work not directly related to new user story features, but necessary for the overall quality of the system. Examples of technical debt include delaying upgrades to necessary tools and frameworks, delaying the refactoring of overly complex or crude system components, etc. etc.

The problem with technical debt is that it will reduce the velocity of the team, and the quality of the software produced on a greater basis the longer it is ignored and / or deferred (just like only making the minimum payment on a credit card debt).
So now that we have an understanding about technical dept, and the problems caused by it, we can discuss an approach to solving this age old application development and maintenance issue.

Since Scrum teams are supposed to operate in a transparent manner, and the product owner is a full partner with the scrum team, the details of the technical debt that exists and is accruing in a product needs to be visible to and understood by the product owner.
Key technical debt items need to exist in the product backlog. Additionally, the ongoing impact to product quality and scrum team velocity by continuing to defer their resolution needs to be clear to the product owner so that the product owner may rightly prioritize these items in the product backlog.

Additionally some team adopt the notion that in each iteration or predefined number of iterations, a technical debt tax of some number of story points will be included during the sprint planning process. This assures that the most important technical debt items will be addressed when they exist in the backlog, and hopefully the “technical debt balance” will never get to the point where it takes too big of a bite out of a particular iteration or set of iterations.

Also, once the concepts of identifying technical debt and continuing to pay it down on a regular basis are in place, the scrum team becomes very sensitive to these issues, and very cleaver and effective in how it deals with them.

Therefore consistent and thoughtful application of these best practices associated with the management of technical debt will result in better software quality, improved team velocity, a happier and better informed product owner and a less stressed out scrum team! All in all, not a bad deal really.

As always, Paul

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.


End of Iteration Demos: In Scrum the measure of progress is working software!

Modern Project Management defines project progress in many interesting, complex, sometimes useful and sometimes erroneous ways.  From earned value to estimate to complete there is no shortage of thoughts on this always pertinent project management topic.  One of the many simple and effective aspects of the Scrum process is that the key measure of project progress is measured by working software.  This may seem as basic as to almost be taken for granted.  Nevertheless it is remarkable what clear focus can produce, and what a lack of clear focus also produces.

Therefore sprint progress is continuously evaluated thru ongoing software demos by the scrum team.  This simple and transparent activity eliminates surprises, facilitates user story acceptance and provides immediate feedback from the product owner and SME’s to the scrum team.

There are many practices associated with ongoing sprint demos, but the following best practices have been successful in the past and are worth considering:

  • Periodic and / or weekly demos:  Having a re-occurring and predictable demo schedule helps the whole team focus on what is being produced each period, as well has helps the product owners keep up with what is being produced and helps them and the team with the acceptance process.
  • Demo scripts and dry runs: For each sprint scenario, the team develops a step by step script (like a script in a play) then will help define all aspects of the final iteration scripted demo. These scripts will include test the details of the test scenarios, each step in the processing and checking in the demo, who will execute the demo, etc. etc. In preparation for the final demo, the team will perform “dry runs” or rehearsals, just like practicing for the opening night of the play.  These dry runs are performed as many times as required, until they are completed end to end without any errors or issues.
  • Demo Day: Finally the big day has arrived and the excitement that the whole team feels the day of the demo is palatable.  In fact the “opening night” analogy is a good one!
  • Celebrating a successful Demo:  After a successful demo, the team is in a mood to celebrate, and celebrate they should!  Whether it is a pizza lunch, a group hug, dinner offsite or what ever, nothing helps the team building and bonding process like celebrating a team success together as a team. This is very cool and should not be overlooked or minimized!

Nothing breeds success like success and nothing builds credibility and trust with product owners and stakeholders like working software! It is so cool seeing the faces and reactions of product owners as they begin to consistently see working software produced demo after demo and sprint after sprint.  Before long these product owners become the biggest supporters of the scrum team and the scrum process. As they adjust to the rhythm of a sprint (sprint planning, daily stand ups, periodic demos, dry runs and then demo day), they become super productive and much more confident and satisfied with their own role and the results produced for their efforts!

Cheers and regards, PR

Self managed teams vs. command and control style project management

One of the most powerful, challenging and subtle principles of the Scrum process is the notion of self managed teams.   It does not take the experience of too many scrum projects, programs, organizations, etc. before it becomes clear that this change is nothing short of a true paradigm shift!
In larger organizations, the well developed command and control management structure and culture does not prepare new scrum teams with the awareness, skills and confidence to easily adapt to working on self managed teams.   On the contrary, many of the cultural mores go against the principles, skills and techniques required when adopting self managed teams.  One concept that is often problematic is the notion that the team (and therefore all of the Scrum team members) is responsible and accountable for the results of each Sprint.  In many organizations, accountability is more likely to be avoided or ambiguously shared then fully and clearly embraced.

Therefore once the basic scrum process, ceremonies, etc. has been learned by the team, then the more subtle capabilities required by Scrum such as self management begin to become more visible and noticeable.

Common sense dictates that if organizations and scrum teams want to enjoy the potential order of magnitude productivity improvements of the Scrum process they need to migrate from the command and control style project management (PM becomes a constraint to the productivity of the team) to the self management style where many team members can share in the planning, facilitation, follow through, etc. for the team.  In this case much more work can be planned and completed by the team when it is not single threaded through a traditional technical PM.

Fortunately, newly forming Scrum teams that have effective leadership and facilitation will be able to adapt to the principles of self management, shared leadership, etc.  Some simple techniques to help the team understand and develop these skill can include rotating daily stand up facilitation, requesting that various team members share in the defining and updating of work tasks, and  where every possible rotate roles within the team, etc.

In addition to removing the single threaded constraint an even more powerful benefit is that once the team begins to master the self management principles and behaviors, the scrum team can better align itself and ride the energy and inspiration of a number of team members instead of always requiring the PM to lead and drive in this regard. The end result of this transformation (yes, I mean transformation) is significant and much more sustainable over the long team (Less individual burn out).





Scrum on the inside, Waterfall on the outside!

Scrum on the inside, waterfall on the outside:

I am currently working as a “Scrum Guru” or Scrum Mentor to a very large national HMO.

They have embarked on a “Mega Program” to deploy new Pharmacy applications throughout the country and are attempting to retire a legacy set of applications that have been in use for over a decade. Additionally this project has been in the planning stages for many years, and is now a “must have” for the organization.

Due to past challenges with their in house waterfall software development processes, this group is now the second major program within the organization to attempt to work in an Agile & Scrum manner.

There are many, many things that could be blogged about this project, but one item that has grabbed my attention is that the program seems like Scrum on the inside and waterfall on the outside. Even with the adoption of Scrum within the program, there still are innumerable parts of the client organization that operate with waterfall processes, timeframes, expectations, etc.

As if the transition for this program to Agile and Scrum is not challenging enough, there are many external IT and non IT organizations that are “died in the wool” waterfall folks. Can this project be successful with this model? Yes, as it is still better than the alternative! (All waterfall, all the time) Will it be challenging and sometimes painful? Yes and of course yes. Is this enterprise unique in encountering this reality when it is courageous and smart enough to adopt the Scrum process? No, this is probably the rule rather than the exception for large enterprises that attempt to adopt Scrum.

Anyway, if you have any comments or suggestions for us, please don’t keep it to yourself!

Cheer, Paul

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