Agile Process Improvement


IMG_4827

You have to measure to improve!

The nine most commonly cited reasons for an agile transformation range from coldly tangible to ethereal.  As we have noted, each of the reasons can berestated as a question(s) that can be answered quantitatively.  How the question(s) is stated provides clarity to the organization’s goal.  This is no different than the way acceptance criteria and test cases define the nuances and provide clarity to user stories.  Today, I’m presenting an example of how data can be used as a feedback loop to highlight misinterpretation of intent and provide an impetus for behavior change. (more…)

The Science of Successful Organizational Change

The Science of Successful Organizational Change

This week Steven completes the re-read of Paul Gibbons’ book The Science of Successful Organizational Change. If you are involved in change (and everyone is) this book is a must read and a must re-read.  Next week we will feature a review of the graphic novel version of The Goal.  Steven’s final thoughts—

Final thoughts about Paul Gibbons “The Science of Successful Organizational Change”

A Great Reference

I found the quote on the cover to hold true.  “Place it on the bookshelf next to the Halo Effect, Switch, and The Fifth Discipline – in easy reach for rereading.”  Rolf Häsänen

You can use this book to get started with your own new initiatives.

Change Management (so much of the book covers this), but if you want to formulate a strategy to counter the resistance to change, turn to page 226 and re-read table 8.1 – A Holistic Model of Resistance to Change – to classify why people are resisting the change.

A word about Habitual change resistance – remember “Mind the Gap” – the gap between people wanting to change versus the difficulty in actually making the change (e.g., diets!) (more…)

No Mowing Sign

The Environment is Complex

Having been involved in the world of buying, building, maintaining, and testing software for many years, one of the longest running conversations between everyone involved with delivering value is the impact of complexity on cost, effort, quality and even on the ultimate solution to business problems.  The concept of complexity and the impact of complexity is unfortunately – complex.   The importance of developing an understanding of complexity is complicated by a lack of a crisp definition and a confusion of the topic with the concept of complicated.  The difference between complicated and complex is not a mere nuance; the distinction will affect the options we perceive are available to solve any specific problem.

(more…)

Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

SPaMCAST 457 features our essay on cognitive biases and their impact on decision making.  If you doubt the impact of biases on decision making, read chapter five of The Science of Successful Organizational Change (current Re-read Saturday Book) and listen to this week’s podcast!

Our second column this week is from Jon M Quigley (The Alpha and Omega of Product Development), Jon continues his theme of learning organizations with penetrating insight on how a learning organization evolves.

Kim Pries (The Software Sensei) anchors the cast this week with a strong argument that if you want to improve the software you are delivering begin by hiring the right people!

We also have a promo for 2017 Agile Leadership Summit:

Mark your calendar for an entirely new class of business conference. More “business theater” than a conference, the 2017 Agile Leadership Summit (September 22nd in Washington, DC) is sponsored by AgileCxO (agilecxo.org). It features an integrated mix of six vignettes on Agile leadership, two fantastic industry keynotes, and onstage jazz musicians who are demonstrating agility, iteration, and excellence throughout. Learn more at http://agilecxo.org.

Re-Read Saturday News

This week Steven dives into Chapter 6 of Paul Gibbons’ book The Science of Successful Organizational Change.   There are a lot of techniques that I see used on a daily basis that are based on pop psychology. Confronting the true believers is often a lot like jousting at windmills. Remember to use the link in the essay to buy a copy of the book to support the author, the podcast, and the blog!   

This week and previous installments: (more…)

Line Segment Shutdown

Line Segment Shutdown

When making any significant change to a team or organization, deciding whether to take a big bang or incremental approach is important.  Both of these approaches–and hybrids in between–can work.  Big bang and incremental approaches mark the two ends of a continuum of how organizations make a change.  The decision is almost never straightforward and organizations often struggle with how they should approach change.  The decision process begins by defining big bang and incremental implementation approaches in between the two ends so they can be compared. (more…)

How can this team really work together?

How can this team really work together?

I recently got a question from a long-time reader and listener.  I have removed the name to ensure confidentiality.

Context:

  • The person who asked the question is an experienced Agile leader.
  • The team is not all technically-equal full-stack developers, some developers work on UI stories and others work on backend stories.
  • The team has 8-10 people.

The Problem:

  • During story grooming/sizing, the entire team does not participate equally to offer up their points. UI developers participate on UI stories and are reluctant to chime in on backend work, and vice-versa.

The Question:

  • Scrum seeks to involve the entire team.  How can I get everyone involved (or should I)? 

(more…)

 

Space between has to big enough and no bigger.

Space between has to big enough and no bigger.

Cadence represents a predictable rhythm. The predictability of cadence is crucial for Agile teams to build trust. Trust is built between the team and the organization and  amongst the team members themselves by meeting commitments over and over and over. The power of cadence is important to the team’s well being, therefore the choice of cadence is often debated in new teams. Many young teams make the mistake of choosing a slower (longer) cadence for many reasons. The most often cited reasons I have found are:

  1. The team has not adopted or adapted their development process to the concept of delivering working functionality in a single sprint. When a team leverages a waterfall or remnants of a waterfall method, work passes from phase to phase at sprint boundaries. For example, it passes from coding to testing. Longer time boxes feel appropriate to the team so they can get analysis, design, coding, testing and implementation done before the next sprint. The problem is that they are trying to “agilefy” a non-Agile process, which rarely works well.
  2. New Agile teams tend to lack confidence in their capabilities. Capabilities that teams need to sort out include both learning the techniques of Agile and abilities of the team members. Teams convince themselves that a longer sprint will provide a bit of padding that will accommodate the learning process. The problem with adding padding is twofold. The first is that time tend to fill the available time (Parkinson’s Law) and secondly lengthening the sprint delays retrospectives. Retrospectives provide a team the platform needed to identify issues and make changes which leads to improved capabilities.
  3. Large stories that can’t be completed in a single sprint are often noted as reason to adopt longer duration sprints and slower cadence. This is generally a reflection of improper backlog grooming. More mature Agile teams typically adopt a rule of thumb help guide the breakdown of stories. Examples include maximum size limits (e.g. 8 story points, 7 quick function points) or duration limits (a story must be able to be completed in 3 days).
  4. Planning sessions take too long, eating into development time of the sprint. Similar to the large stories, overly long planning sessions are typically a reflection of either poor backlog grooming or trying to plan and commit to more than can be done within the sprint time box. Teams often change the length of a sprint rather than doing better grooming or taking less work. Often even when the sprint duration is expanded the problem of overly long planning sessions returns as more stories are taken and worsens as the team gets bored with planning.

Teams often think that they can solve process problems by lengthening the duration of their sprints, which slows their cadence. Typically a better solution is to make sure they are practicing Agile techniques rather than trying to “agilefy” a waterfall method or doing a better job grooming stories. A faster cadence is generally better if for no other reason than the team will get to review their approach faster by doing retrospectives!

Next Page »