Listen to the Software Process and Measurement Podcast

SPaMCAST 317 tackles a wide range of frequently asked questions, ranging from the possibility of an acceleration trap, the relevance of function points, whether teams have a peak loads and safe to fail experiments. Questions, answers and controversy!

We will also have the next installment of Kim Pries’s column, The Software Sensei! This week Kim discusses robust software.

The essay starts with “Agile Can Contribute to an Acceleration Trap”

I am often asked whether Agile techniques contribute to an acceleration trap in IT.  In an article in The Harvard Business Review, Bruch and Menges (April 2010) define an acceleration trap as the malaise that sets in as an organization fails prey to chronic overloading. It can be interpreted as laziness or recalcitrance, which then elicits even more pressure to perform, generating an even deeper malaise. The results of the pressure/malaise cycle are generally a poor working atmosphere and employee loss. Agile can contribute to an acceleration trap but only as a reflection of poor practices. Agile is often perceived to induce an acceleration trap in two manners: organizational change and delivery cadence.

Listen to the rest now

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change of on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

SPaMCAST 318 features our interview with Rob Cross.  Rob and I discussed his INFOQ article “How to Incorporate Data Analytics into Your Software Process.”  Rob provides ideas on how the theory of big data can be incorporated in to big action.

 

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST

Register Now

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

Accelerating when you a plotting a change in direction can be a problem.

Accelerating when you a plotting a change in direction can be a problem.

I am often asked whether Agile techniques contribute to an acceleration trap in IT.  In an article in The Harvard Business Review, Bruch and Menges (April 2010) define an acceleration trap as the malaise that sets in as an organization fails prey to chronic overloading. It can be interpreted as laziness or recalcitrance, which then elicits even more pressure to perform, generating an even deeper malaise. The results of the pressure/malaise cycle are generally a poor working atmosphere and employee loss. Agile is often perceived to induce an acceleration trap in two manners: organizational change and delivery cadence.

Implementing Agile requires substantial and sustained organizational change. It generally affects team structure, the work and process management and technical techniques impacting configuration management, testing and coding. Changes of these types are almost never deployed in a single big bang, but rather in waves with minor tweaks being made in-between changes based on feedback. All organizations have a different “carrying weight” when it comes to change, or the amount of change an organization can absorb before the resistance level overcomes the pressure to change. Many factors can influence the carrying weight an organization can internalize, and therefore avoid an acceleration trap.  These factors include organizational change management programs (selling the change), level of involvement, and the pressure to change.  The first two items on the list should be built into the change program. Organizational change management programs generally help make the case for change, layout the benefits of change and seek buy-in. Getting the people who are being asked to change involved in planning and implementing the change helps to combat feelings of victimization that can occur. The third category, the pressure to change, is generally a reflection of market performance. I have often observed that a good “near death experience” (organizationally speaking) significantly increases the ability of an organization to change. Change driven by desperation is not something anyone wants to live through and you are asking for trouble if you try to fake it.

The principles of the Agile Manifesto call for a sustainable pace of delivery. The pace should be set to be able to be maintained indefinitely. Organizations that use Agile to address projects with a fixed scope and set delivery dates will generally find early success as Agile accelerates early delivery of functionality.  This initial success is often followed by burn out as team cannot maintain the pace of delivery. A common pattern I have observed is that a team is able to increase its velocity for a few sprints until suddenly it encounters a sprint in which nothing seems to go correctly and average velocity is negatively impacted.  This saw tooth pattern can either be reflection of exhaustion or overstepping. Both are a sign of an acceleration trap.  A simple solution (or maybe an overly simplistic solution) is not to agree to fixed scope and fixed deadline projects. A less simple solution would include integrating the development of a minimum viable product (MVP) into all release plans for all relevant projects, so that unsustainable cadences can be avoided. The introduction of an MVP into the concept of a backlog and release plans will require educating both the Agile team including product owner and other IT stakeholders.

Agile can add to the possibility of an acceleration trap if change management is not addressed or the change to Agile is imposed on project teams. Further accepting unrealistic projects, Agile or not, can lead to all sorts of problems, including an acceleration trap. Neither of these categories of problems HAVE to create an acceleration trap, if action is taken early.  Failure to address the causes of the acceleration trap is more to blame than Agile.