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…)

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

SPaMCAST 452 features our essay on personal process improvement.  We are responsible for our own path in life. Stepping back and reviewing where we are today and where we want to be tomorrow is a form of a retrospective.  Just like any other retrospective, the goal is to change the trajectory of the path you are on.   

Kim Pries, the Software Sensei, discusses ethics in software. Ethics guide (or they don’t) practitioners of all types.  Many certification organizations include ethics statements but rarely have the teeth to enforce those ethics.  Kim asks whether this approach makes sense.

Anchoring the cast is Jon Quigley with his Alpha and Omega of Product Development column.  Jon is beginning a three column theme on the impact of people and learning on product development. One of the places you can find Jon is at Value Transformation LLC.

Re-Read Saturday News

Today we continue re-reading The Science of Successful Organizational Change led by Steven Adams.  THis week we dive into Chapter One titled Failed Change:  The Greatest Preventable Cost to Business?  The frightening part of this chapter is how intimately it resonates based on personal observation. Remember to buy your copy.   

Previous installments:

Week 1: Game Plan

Week 2: Introduction   

Week 3: Failed Change

(more…)

You got to have courage!

You got to have courage!

I listen to Malcolm Gladwell’s wonderful Revisionist History podcast. In the last podcast of season one, he discussed “the satire paradox.” The punchline of the most recent installment of the podcast is that change is not possible without courage. Flexibility requires courage.  Change, when embracing something like Agile, requires the flexibility to give something up.  Perhaps we might be asked to move outside of our comfort zone and work differently, or to work with people we haven’t worked with before.  Asking testers and developers to work on the same team or to work as pairs or asking backend and UI subteams to work together require flexibility.  We can define flexibility to embrace Agile or any other significant modification to work based on four basic attributes: (more…)

Pi(e)-shaped person?

Pi(e)-shaped person?

Many Agile discussions talk about team members as generalizing specialists.  Generalizing specialists are individuals that have a specialty; however, they also have broad levels of experience that can be applied.  Tim Brown of IDEO coined term ‘T-shaped people’ (or skills) to describe this combination of specialization and experience.  There are a number of other letter- or symbol-based metaphors, sort of an alphabet soup of metaphors, that describe the type of person you might find in a team. (more…)

Broken Chinese Statues

A good team will not go to pieces!

One of the most iconic television shows of the 1980s (83 – 87) was the A-Team. In the A-Team, the four team members combined their talents to right wrongs and conquer evil. In a precursor to Agile, the team was cross functional and in the context of the larger world, self-organizing. While the A-Team reflects Hollywood’s perception of a team, the lesson shouldn’t be lost that for most software development or maintenance efforts teams are necessary to get things done. If teams are a necessity, then it is important to understand the attributes of an effective team.  For any specific effort, the best team (or teams) is a function of team dynamics, capabilities and the right number of bodies. (more…)

photo

An Agile center of excellence (ACoE) provides support and energy to an Agile transformation within an organization. It supports through leadership, evangelization, best practices, research, support and/or training for agile and lean ideas. ACoE’s support can be categorized in three inter-related areas. These areas, the three “P’s,” are people, process and project.

People are the heart and soul of any development process. As we have noted, Agile has an enormous focus on people (remember the Agile value of valuing people over process). The ACoE provides support to people though bringing new ideas into the organization, by providing coaching, developing coaches and acting as change agents.

Agile is a set of processes, or sets of steps taken to achieve a specific end. A recipe is a process, as is a daily stand-up meeting or checking code in and out of configuration management tool. The ACoE supports Agile processes by capturing process, identifying and fostering the use of relevant metrics (collection and reporting are typically PMO functions – to be discussed in the near future), facilitating communities of practices and providing tools.

Projects are the currency of most IT organizations. At its simplest a project is an enterprise with a start and end that is organized to deliver a result. ACoEs support the performance of Agile teams at a project-level as coaches. Coaches are folks who deliver help to teams, stakeholders and other leaders within an organization so they learn how to be Agile. At the project-level, coaches help teams use and tweak processes to meet the team’s needs, provide training and support for tools and processes and help the team learn how to ask the hard questions about how the team is using Agile.

The primary goal of the ACoE is to provide practitioners with the tools, techniques and capabilities they need to be Agile. By helping teams perform, the ACoE also helps sell and maintain the Agile transformation. Both of these goals begin as an organization starts a transformation to Agile and continue to be important as teams evolve and continuously improve. The ACoE delivers value by addressing the three Ps. For example, through the role of coaching and by facilitating communities of practice, the ACoE helps to promote an environment where there is consistency of practice and where innovation can happen. While the combination of innovation and consistency might sound contradictory, coaches often act as an Agile Johnny Appleseed. ACoE coaches see how teams work, the changes that have made to the processes and why those changes were made. The ACoE can then help to spread ideas that prove to be valuable through coaching, referrals or discussion in communities of practice.

People are chaotic.

People are chaotic.

Have ever heard the saying, “software development would be easy if it weren’t for the people”? People are one of the factors that cause variability in the performance of projects and releases (other factors also include complexity, the size of the work, and process discipline.) There are three mechanisms built into most Agile frameworks to address an acceptance of the idea that people can be chaotic by nature and therefore dampen variability.

  1. Team size, constitution and consistency are attributes that most Agile frameworks have used to enhance productivity and effectiveness that also reduce the natural variability generated when people work together.
    1. The common Agile team size of 7 ± 2 is small enough that team members can establish and nurture personal relationships to ensure effective communication.
    2. Agile teams are typically cross-functional and include a Scrum master/coach and the product owner. The composition of the team fosters self-reliance and the ability to self-organize, again reducing variability.
    3. Long lived teams tend to establish strong bonds that foster good communication and behaviors such as swarming. Swarming is a behavior in which team members rally to a task that is in trouble so that team as a whole can meet its goal, which reduces overall variability in performance.
  2. Peer reviews of all types have been a standard tool to improve quality and consistency of work products for decades. Peer reviews are a mechanism to remove defects from code or other work product before they are integrated into larger work products. The problem is that having someone else look at something you created and criticize it is grating. Extreme programing took classic peer reviews a step further and put two people together at one keyboard, one typing and the other providing running commentary (a colloquial description of pair programing). Demonstrations are a variant of peer reviews. Removing defects earlier in the development process through observation and discussion reduces variability and therefore the risk of not delivering value.
  3. Daily stand ups and other rituals are the outward markers of Agile techniques. Iteration/sprint planning keeps teams focused on what they need to do in the short-term future and then re-plans when that time frame is over. Daily stand-ups provide a platform for the team to sync up on a daily basis to reduce the variance that can creep in when plans diverge. Demonstrations show project stakeholders how the team is solving their business problems and solicit feedback to keep the team on track. All of these rituals reduce potential variability that can be introduced by people acting alone rather than as a team with a common goal.

In information technology projects of all types, people transform ideas and concepts into business value. In software development and maintenance, the tools and techniques might vary but, at its core, software-centric projects are social enterprises. Get any group of people together to achieve a goal is a somewhat chaotic process. Agile techniques and frameworks have been structured to help individuals to increase alignment and to act together as a team to deliver business value.