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

The Software Process and Measurement Cast 437 features a discussion of our recent re-read of  The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing) with Steven Adams.  Steve has participated on nearly all of the re-reads, providing his unique wisdom.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development. Steve also has some advice on how to get the most out of the re-read feature.

Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development.  Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems.  Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson.  Steve enjoys listening to technical podcasts, and SPaMCAST was one of the first and is a favorite!  Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.

Blog: https://sadams510.wordpress.com/

Twitter: @stevena510

Re-Read Saturday News

This week we begin our read of Holacracy with a few logistics and a review of the introduction.  We have a short entry this week that will give you time to buy a copy today and read along!  If you have not listened to my interview with Jeff Dalton on Software Process and Measurement Cast 433, I would suggest a quick listen. Jeff has practical experience with using the concepts of holacracy in his company and as a tool in his consultancy.  

Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson was published by Henry Holt and Company in 2015.  The book is comprised of a forward, 10 chapters in three parts, notes, acknowledgments, and an index.  My plan is to read and review one chapter per week.  We will move on to a new book in approximately 12 weeks.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads. (more…)

Scaling!

Leading the way!

Participative management styles are often used by Agile teams.  Participative management styles are perceived to be more flexible. Flexibility allows teams to immediately react to the feedback they receive as they work rather than wait until it is too late to react. Flexibility is a core principle of Agile; however, scaling Agile requires trading some of the flexibility of participative management styles for more control.  More control is needed due to the increased size of both team and work and the increased level of risk large pieces of work typically represent.    (more…)

A pile of empty pizza boxes!

WIP limits are needed to stop waiting in queues.

Recently a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together. In a previous entry we began describing how kanban or Scrumban could be leveraged to help teams identify issues with how they work and then to fix them.  We conclude with the last two steps in a simple approach to leveraging kanban or Scrumban: (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…)

OLYMPUS DIGITAL CAMERAWhat’s the difference between an Agile coach and a scrum master? A quick internet search returns a variety of competing opinions (and a lot of ads for training classes).  This is not an arbitrary question – these terms have a great deal of power to set expectations for behavior. While some of the components of the roles are similar, the two roles are different in at least one major way –  scope.

Both Agile coaches and scrum masters help teams.  Both roles are tasked with helping Agile teams use Agile values and practices to deliver value to the organization.  Agile coaches and scrum masters use similar techniques to guide, facilitate, and coach teams so that they learn and use Agile techniques, confront delivery problems as they occur, and work together as a well-oiled unit.  If we stopped here the two roles would be the same. However, the scope of the two roles is different.

Agile coaches typically pursue the implementation of an organizational vision of Agile, or are tasked with delivering external knowledge and expertise to a team.  In both cases the coach is external and is not a member any specific project team. In order to effect change from the outside the project, the coach needs a broader exposure to Agile roles than a typical scrum master.  A coach should have played all of roles on an Agile team multiple times. They have the gravitas to influence without direct authority and from outside the team. They interact with a team or teams, and then let the team synthesize and internalize the advice. The Agile coach is typically the voice of Agile at an organizational level.  This generally requires broader exposure and experience with Agile techniques, which is why many organizations use external consultants to play this role. The need for an Agile coach is generally transitory, specifically they are needed when external injections of knowledge or energy is necessary to help ensure the application of Agile continues to evolve.

On the other hand, the scrum master is the team’s tactical coach (scrum defines the team as the scrum master, product owner and the development team). He/she facilitates the team’s use of Agile techniques and helps to protect the team from the outside world. Scrum masters are the voice of the process at the team level.  Scrum masters are a critical member of every Agile team. The team’s need for a scrum master is not transitory because they evolve together as a team.

The role of an Agile coach and that of scrum master have similarities, but also significant differences.

Are you listening?

Are you listening?

Listening is important for anyone involved in developing, enhancing and maintaining software. Teams that don’t listen well have difficulty identifying and refining needs and coordinating their work. With the demonstrated criticality of listening, organizations and teams should work  hard to facilitate improved listening.  Every development methodology and framework advanced has made great effort to improve communication, of which listening is a key component. However, significant obstacles to effective listening remain. For example: (more…)

Greater scale, more problems?

Greater scale, more problems?

In 2016, scaling Agile is a contentious topic.  Frameworks and techniques for scaling are often lambasted as semi-Agile or perhaps even backdoor waterfall techniques. Occasionally you still hear that if a piece of work is too big for one team to complete in a reasonable period of time, it should be broken down or just not done. Rather than throw the baby out with the bathwater, many organizations have taken a more pragmatic approach and adopted techniques to scale Agile. These techniques reflect the differences between a single-team Agile project and a scaled project.  Careful observation can trace most of these perceptions back to a single difference. (more…)