Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Process Management

Holacracy:Re-read Week 4, Chapter 3. Organizational Structure

Book Cover

Holacracy

Remember to buy a copy of Holacracy published by Henry Holt and Company in 2015. Chapter 3, titled Organizational Structure describes the structural components of a holacracy. Chapter 3 provides the building blocks that allow distributed authority (Chapter 2) to function effectively.

Chapter 3: Organizational Structure

Chapter 2 provided the tools for distributing authority and the need for the organization to be able to quickly and continuously evolve how that authority is distributed. However, distributing authority in a dynamic environment without addressing how an organization is structured will cause chaos. The organization structure needs to be conducive to the processes needed to distribute authority. The classic pyramid structure organization is typically out of date, irrelevant and difficult to change.

Most organizations have three potential organizational structures. The one expressed by the org chart, the informal structure and the structure that best suits the organization’s purpose. The later is generally aspirational. The gap between what is and what could create friction within the organization that reduces the organization’s ability to achieve its purpose. The governance meetings are designed to help transform the organization from the “what is” into the “could be” structure. In holacracy the formal structure is always evolving based on the tension between what is it and what could/should be.

Roles are the basic building blocks of an organization. This is in comparison to classic organizations in which the job (or block on the org chart) is the basic building block. In a holacracy, authority is distributed to a role, not a person. Complex or large roles can be broken down into sub-roles. In a holacray the roles are grouped and organized based on the purpose rather than the people being grouped and organized. Focusing on the roles leave the people free to self-organize. Needed roles can be played by the individual that has capacity, rather than the having to waiting on a specific person is available.

Robertson suggests that a critical question that should be asked is not who you are accountable to, but rather “what are people at counting on you for.” Asking this question forces an examination of whether there is clarity around responsibilities and roles. Differences in expectations generate frustration and friction caused by the need to sort out the expectation. In holacracy the governance process acts as a mechanism to adjudicate role and responsibility differences. One of the critical points in the chapters is that in holacracy, the structure helps to differentiate between the people working in the organization and the functions or will they fulfill.
In holacracy, tasks are assigned to a role, not a person. This distinction separates the person and the role. However, roles and people generally confused. This true in the business and nonbusiness scenarios. When asked, I often respond that I am a consultant rather than the roles I play. Robertson uses examples from nonbusiness scenarios to make the point that people often perform multiple roles. For example, I have several roles including father, grandfather, spouse, writer, consultant and household elf.

A holacray constitution defines a role as consisting of three specific elements:
· Purpose provides the reason a role is needed.
· A domain defines the sphere for which the role has authority.
· Accountabilities are the ongoing activities that the role has the authority and is expected to perform.

The governance process in the constitution provides a process for adjusting all three elements.

Classic organization charts are typically represented as a pyramid. Holacracy is represented as a set of circles. The organization is represented as a super circle, called an anchor circle. Depending on size and complexity, the anchor circle is populated by sub-circles and roles (also represented as circles). Each circle is a holon (defined as something that is simultaneously a whole and a part). In holacracy, each circle is both autonomous and part of the larger organization. As organizations grow, circles breakdown. For example, a design firm my wife owned began as a single group of designers (one circle) and grew into a company which included designers, programming, and administration. Three circles. Further, the designers broke down into two: print and digital designers.

Circles without a mechanism for data to be shared across the boundaries become silos. Holacracy uses three types of links to facilitate the flow of information and purpose across the boundaries of circles.
Lead link. The lead link is appointed by the super circle (the circle the sub-circle is within) to represent the super-circle’s needs and purpose. The lead link brings information to the sub-circle, routing new information to the correct roles. The lead link is not a manager in the classic sense but rather routes information to roles in the circle. The lead link does not have the power to fire, hire or determine compensation, but can remove a role from a person.
Representative link. The representative link is elected by the members of the sub-circle and represents the sub-circle’s issues to super circle.
The lead and representative links provide a bi-directional path to connecting the circles and to provide alignment and feedback.
Crosslinks. This type of link represents a specialized form of link between sub-circles. In the company, I work for an example of a cross-link would be the role of solution engineer that links delivery and sales.

Holocracy identifies several roles that are elected by the people within a circle. These include facilitator, secretary, and representative. The lead link role is assigned. Elected positions generally are held for a year and participate in the meetings that shape the use of holacracy (governance meetings and tactical meetings – which are defined in later chapters).

Transformation Notes: Separating roles and people is a huge step for both people and organizations. The process of separating roles and individuals begins with defining roles. The book suggests that all three attributes (purpose, domain, and accountabilities) do not need to be defined all at once, but rather can evolve. This is a judgment call. The more resistance that is expected during a transformation the more definition of the attributes and governance process will be needed to defuse passive aggressive behavior.

Team Coaching Notes: Help teams use words that separate individuals from the role they are playing. A side benefit of separating roles and people is that it becomes easier to discuss how a role was performed when you are not seen to be critiquing a person.

Remember to buy a copy of Holacracy (use the link in the show notes to help support and defray the costs of the Software Process and Measurement Cast blog and podcast).

Previous Entries in the re-read:

Week 1:  Logistics and Introduction
Week 2: Evolving Organization
Week 3: Distribution Authority

A Call To Action
I need your help. I have observed that most podcasts and speakers at conferences over-represent people from Europe and North America. I would like to work on changing that exposure. I would like to develop a feature featuring alternate software development voices beginning with Africa and Southeast Asia. If this feature works we will extend it to other areas. If you can introduce me to practitioners that would be willing to share their observations (short interviews) I would be appreciative!  Feel free to leave a note or send an email at spamcastinfo@gmail.com


Categories: Process Management

Capability Teams are Not a Silver Bullet

 

The terms ‘long-lived team’, ‘stable team’ or to a lesser extent ‘capability’ can evoke an almost magical reaction. The problem with a magical reaction is that it switches off our ability to think about the consequences of the attributes and assumptions that need to be true for these types of the team to function effectively.  When any concept takes on a magical aura, conflict and disaster follow.  Long-lived teams sometimes don’t always make sense in every situation.

Human Safety or High-Security Scenarios Influenced by Confirmation Bias.  Airline crews are a perfect example.  Rotating crew members helps teams to avoid confirmation bias.  The high productivity and trust of a capability team are replaced by detailed embedded processes and checklists. The cockpit checklist is used to establish a common process, the lack of familiarity makes sure that the pilot and co-pilot do not get overly comfortable in each other’s pattern of behavior and fall prey to confirmation bias.  The checklist is augmented by a strict observation of hierarchy. I recently visited a military base and during my stay, I got to speak with the guards at the gate multiple times (why I had time to talk at the gate is another story entirely). In the airline industry, long-lived teams have been linked to accidents. Gate duty was continually rotated so that no one became overly comfortable and strays from the process.  TSA officers follow a very similar pattern at major airports. In each of these cases, efficiency and interpersonal trust are traded for ensuring the process is followed and that nothing falls through the cracks.  Most software development scenarios favor the most efficient and effective delivery process because human life and security are not at risk when writing and testing the software.

Highly Variable Work. If either the type of work or flow of work is highly variable, a fixed capability team makes little sense.  One of the requirements for a capability team to be effective is a backlog of work to draw from otherwise the team will either sit or be highly inefficient (potentially ineffective also).  I recently spoke with a firm that occasionally required software development.  Rather than forming their own capability team, it made more sense to outsource the work to a firm with a capability team.

Cultures That Believe In Highly Matrixed Approach. Organizations that believe (magical thinking) that organizing hierarchies based on functional roles and then forming teams to tackle specific projects will only have long-lived capability teams by accident.  There are only three ways for capability teams to form and prosper in these environments.  The first is purely by accident, in this situation prospering also has to occur by accident.  Don’t count on this strategy.  The second is for a portion of the organization to seal itself off from the other part of the organization and embrace a new management approach.  This approach is similar to icebergs calving from a glacier; it happens but how long the new entity lives is an open question. This is a useful approach for trying out capability teams. The final and only long-term approach is to change the management culture within the organization; unfortunately, this is the hardest route (risk and reward are often related). In the end, until the management culture is refocused, creating capability teams staffed from matrix managers will generate friction and management frustration when managers try to lean in and task individuals.

Capability teams generally represent the holy grail for effectiveness and efficiency in Agile and Lean organizations. However whether we use the term capability team or long-lived team, no one should fall prey to magical thinking.  Magical thinking can cause mistakes.  Alex Yakima in the Software Process and Measurement Cast 439 strongly advocates that organization experiment with concepts first, review hard data on the impact of a change and them thinks carefully about a change.  This approach is the opposite of magical thinking. While my observation is that capability teams will usually come out on top; usually is not the same thing as always.

 


Categories: Process Management

Software Development Conferences Forecast April 2017

From the Editor of Methods & Tools - Thu, 04/27/2017 - 07:47
Here is a list of software development related conferences and events on Agile project management ( Scrum, Lean, Kanban), software testing and software quality, software architecture, programming (Java, .NET, JavaScript, Ruby, Python, PHP), DevOps and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods […]

New OnDemand Course - 10x Software Development, 2nd Edition

10x Software Development - Steve McConnell - Wed, 04/26/2017 - 11:54

How do you maximize team productivity? Decades of research have found at least a ten-fold—“10x”—difference in productivity and quality between the best teams and the worst. The studies have collectively involved hundreds of professional programmers across a spectrum of programming activities. Specific differences range from about 5:1 to about 25:1, and in my judgment, that collectively supports the 10x claim. Moreover, the research finding is consistent with my experience, in which I have personally observed 10x differences (or more) between different programmers.

Fully updated from beginning to end, our 10x Software Development, Second Edition online course describes the Eight Key Principles of 10x software development—how the most effective teams approach their work. The principles are: 

  • Avoid minus-x software development
  • Set direction
  • Attack uncertainty
  • Tailor the solution to the problem
  • Seek ground truth
  • Make decisions with data
  • Minimize unintentional rework
  • Grow capability

You’ll gain a deep understanding of these principles in this course, and you’ll learn specific tactics for turning your team into a 10x team.

New for the second edition are multiple activities to deepen your learning experience, including case studies, exercises, and quizzes; a reassessment and refreshing of every lesson in the course via full in-studio production (no “voice over PowerPoint”); and the addition of tactic-specific resources to help you take your learning beyond our course. There’s literally nothing about this course that we haven’t improved!

Because 10x software development requires all roles to be strong, this course is appropriate for Managers, Technical Leads, Quality Leads, Test Leads, Developers, Testers, and other software project stakeholders. In other words, this is a good course for software development teams as well as individual practitioners.

After you complete this course, you will be able to: 

  • Apply tactics to address the classic mistakes your team is making
  • Identify the development fundamentals you need to grow
  • Make decisions that will stick

After your team completes this course, it will be able to:

  • Confirm that you are all aligned on the project’s objectives
  • Match your development lifecycle to your work rather than the other way around
  • Apply risk management appropriately
  • Plan the right kind of early defect detection
  • Review and enhance your feedback loops

If you’re not already a member of Construx OnDemand, start a free trial today and take your first steps toward 10x excellence!

For a description of the body of research proving the existence of the 10x phenomenon, see my earlier blog post “Origins of 10X – How Valid is the Underlying Research?”

Four Factors to Address When Implementing Capability Teams

14955864_10154768928297276_8000508545464981060_n

There are those who believe that implementing a capability team is as easy as identifying a group of people, putting them together, and then doing a few team building exercises. Instant team! In the most simple terms possible – they are wrong.  There are four complicating factors that have to be addressed.

The first is identifying the capabilities required to deliver consistent value.   One approach is to perform a value chain analysis. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. The value chain concept is generally applied to whole organizations but can be applied to an individual business unit or a specific business function.  Once the path is mapped the roles required to transform the raw material will be identified.

The second factor implied in this factor is a consistent need.  Capability teams, while not permanent (even granite is not permanent) are long-lived teams.  The backlog or flow of work needs to be substantial enough to keep the team busy delivering output that is more valuable than the cost of the team.

Third, once the value flow and the roles have been identified, the people needed to perform those roles need to be reorganized into a capability team.  All members of the team need to “report” to a single leader or manager.  The capability team is a team member’s most important business team.  This typically requires breaking up hierarchies based on specialties.  For example, in a recent organization implementing capability teams, the product owner, and BAs resided in the business, programmers, and testers in development (although separate teams) and release management personnel in operations (which view themselves as separate from development).  The capability team required personnel from each of these specialties.  The team when formed reported to a business operations unit. The change required many managers to agree to give up resources and disrupt teams however they recognized that techniques life matrix management would reduce the value delivered to the overall organization, which in the end was more important than internecine squabbles.   

Breaking up the specialty-driven hierarchy is easily the hardest and most continuous of the changes need to adopt capability teams both from middle and senior managers and practitioners.  Middle and senior managers see their power base being eroded. Solving this problem requires strong sponsorship, consistency of purpose and an overriding belief in the purpose of the larger organization. In a recent LeadX podcast, Kevin Kruse interviewed Dan Pontefract (author and Chief Envisioner of TELUS Transformation Office) who suggested the best performers had a role-based mindset.  A role-based mindset allowed people and organizations to pursue their purpose more effectively.  The concept of capability teams and role based mindsets are linked. When you focus on organizing by role artificial hierarchies based on specialties stop making sense because they impede an organization purpose. At a practitioner level, one complaint is that the specialists do not get the intellectual support they would ostensibly get when organized by functional specialties.  Organizations that adopt capability teams often adopt communities of practice or programs like hackathons as a way to ensure intellectual support for specialties.  

A fourth factor that needs to be addressed is backlog management. A capability team requires a backlog to draw work from (otherwise they do not need to be a long-lived team).  Backlog management requires processes for how work gets on the backlog, how that work is prioritized, how that prioritization changes and when an item should be removed.  These are just a sample of the processes needed to keep a backlog groomed.  Backlog management is even more complicated when multiple functional areas are being serviced by the capability team or by more than one capability team. For example, when multiple functional areas are being supported by one or more capability teams, a product owner council is often a required to balance the need to multiples product owners.

Implementing a capability team is not as simple as waving a magic wand.  However, the factors that have to be addressed should be addressed in any type of organization.  Often the impetus to address these factors is the need to become more effective and value driven which leads us back to capability teams. Although a bit circular, the payoff promised from adopting capability teams primes the pump for change and keeps it moving!

 


Categories: Process Management

Does the Scrum Master Role Ever Go Away?

Mike Cohn's Blog - Tue, 04/25/2017 - 17:00

Scrum Masters coach, mentor, guide, and enable their teams to develop great products. For a new team in an organization that is also new to Scrum, this can be a challenging and time-consuming job.

At first, a Scrum Master may spend time educating the team about the Scrum framework itself. The Scrum Master may have to convince the team that, yes, something potentially shippable can be developed in less than three months. The Scrum Master may mentor the team on new practices, such as test-driven development or continuous integration. And the Scrum Master of a new team will spend time helping the new product owner learn how to do that job.

It can take a lot of work to do this. But, it does get easier.

The Scrum Master Role Gets Easier Over Time

Over time, the team improves. And the skills team members acquire from their first steps with agile help them learn, evaluate and adopt new practices.

It is perhaps comparable to learning a new language. At first we learn through memorization. Later, when we know enough to begin conversing in the new language, we can also learn through context: One word in a sentence is new to you, but the other words provide enough context that you can discern the meaning of the new word.

After seeing some early benefits of Scrum, teams don’t need as much convincing to try new agile practices. And, over time, the Scrum Master gradually removes organization impediments to agility. Perhaps an early battle was with the facilities group to move people so that the agile team could sit together. But once fought and won, that battle does not need to be fought again.

This argues strongly that the job of the Scrum Master does get easier over time. In general, it will take less time to be a good Scrum Master a year into a team’s agile journey than it did at the start.

Why the Job Gets Easier

The Scrum Master role gets easier in part because team members begin to take on parts of the job.

After a while, team members need less coaching. They learn how to facilitate some of their own meetings. Team members work more closely and directly with the product owner, so the Scrum Master is no longer needed to resolve communication roadblocks and resolve issues. There are fewer organizational impediments to agility. Those that remain can be particularly difficult to resolve, but there are fewer of them.

And so, the Scrum Master job starts to take less time as the team and organization become better at Scrum.

But Does The Role Ever Go Away Entirely?

But does the effort required to be a ScrumMaster ever go all the way to zero?

Not in my experience.

Even the best Scrum team continues to benefit from the coaching, guiding and mentoring provided by a good Scrum Master. With that being said, some high-performing teams might find they do not need a ScrumMaster full time anymore. They might, for example, opt to have a technical team member also function as the Scrum Master.

But my experience is that even the best teams benefit from having a Scrum Master.

What’s Your Experience?

What have you found to be true about the Scrum Master role over time? Do you agree it takes less time as the Scrum Master and team become more experienced? Have you worked on a team that had so fully absorbed the role of Scrum Master themselves that they did not benefit from a designated, even part-time Scrum Master?

Quote of the Month April 2017

From the Editor of Methods & Tools - Tue, 04/25/2017 - 08:49
The ScrumMaster is one of the most undervalued roles in Scrum and Agile. Most teams that are just starting out don’t see the value of having a full-time ScrumMaster, and they try to combine this position with that of a developer or tester so that the ScrumMaster is “working.” It’s one of the most common […]

SPaMCAST 439 – Alex Yakyma, It’s Time to Think

SPaMCAST Logo

http://www.spamcast.net

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

The Software Process and Measurement Cast 439 features Alex Yakyma.  Our discussion focused on the industry’s broken mindset that prevents it from being Lean and Agile.  A powerful and a possibly controversial interview.

Alex’s Bio

Alex Yakyma brings unique, extensive, and field-based experience to the topic of implementing Lean and Agile at scale. Throughout his career, he has served as an engineering and program manager in multi-cultural, highly-distributed environments. As a methodologist, trainer and consultant, he has led numerous rollouts of Lean and Agile at scale, involving teams in North America, Europe and Asia, and has trained over a thousand coaches and change agents whose key role is to help their organizations achieve higher productivity and quality through the adoption of scalable, agile methods.

Alex is a founder of Org Mindset (http://orgmindset.com), a company whose mission is to help enterprises grow Lean-Agile mentality and build organizational habits in support of exploration and fast delivery of customer value.

Re-Read Saturday News

Chapter 2 of Holacracy tackles why the consolidation of authority is harmful to the ability to nimble, agile (small a), and productive organizations and secondly, why the distribution of authority supports an organization’s ability to scale.  The argument in Chapter 2 is a central tenant of Holacracy.

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

A Call To Action

I need your help. I have observed that most podcasts and speakers at conferences over-represent people from Europe and North America.  I would like to work on changing that exposure. I would like to develop a feature featuring alternate software development voices beginning with Africa and Southeast Asia. If this feature works we will extend it to other areas.   If you can introduce me to practitioners that would be willing to share their observations (short interviews) I would be appreciative!

Next SPaMCAST

The next Software Process and Measurement Cast will be a big show!  SPaMCAST 440 will feature our essay on two storytelling techniques: premortems and business obituaries.  We will also have columns from Jeremy Berriault, Jon Quigley, and Steve Tendon.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 


Categories: Process Management

SPaMCAST 439 - Alex Yakyma, It's Time to Think

Software Process and Measurement Cast - Sun, 04/23/2017 - 22:00

The Software Process and Measurement Cast 439 features Alex Yakyma.  Our discussion focused on the industry's broken mindset that prevents it from being Lean and Agile.  A powerful and a possibly controversial interview.

Alex’s Bio

Alex Yakyma brings unique, extensive, and field-based experience to the topic of implementing Lean and Agile at scale. Throughout his career, he has served as an engineering and program manager in multi-cultural, highly-distributed environments. As a methodologist, trainer and consultant, he has led numerous rollouts of Lean and Agile at scale, involving teams in North America, Europe and Asia, and has trained over a thousand coaches and change agents whose key role is to help their organizations achieve higher productivity and quality through the adoption of scalable, agile methods.

Alex is a founder of Org Mindset (http://orgmindset.com), a company whose mission is to help enterprises grow Lean-Agile mentality and build organizational habits in support of exploration and fast delivery of customer value.

Re-Read Saturday News

Chapter 2 of Holacracy tackles why the consolidation of authority is harmful to the ability to nimble, agile (small a), and productive organizations and secondly, why the distribution of authority supports an organization’s ability to scale.  The argument in Chapter 2 is a central tenant of Holacracy.

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

A Call To Action

I need your help. I have observed that most podcasts and speakers at conferences over-represent people from Europe and North America.  I would like to work on changing that exposure. I would like to develop a feature featuring alternate software development voices beginning with Africa and Southeast Asia. If this feature works we will extend it to other areas.   If you can introduce me to practitioners that would be willing to share their observations (short interviews) I would be appreciative!

Next SPaMCAST

The next Software Process and Measurement Cast will be a big show!  SPaMCAST 440 will feature our essay on two storytelling techniques premortems and business obituaries.  We will also have columns from Jeremy Berriault, Jon Quigley, and Steve Tendon.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

SPaMCAST 439 - Alex Yakyma, It's Time to Think

Software Process and Measurement Cast - Sun, 04/23/2017 - 22:00

The Software Process and Measurement Cast 439 features Alex Yakyma.  Our discussion focused on the industry's broken mindset that prevents it from being Lean and Agile.  A powerful and a possibly controversial interview.

Alex’s Bio

Alex Yakyma brings unique, extensive, and field-based experience to the topic of implementing Lean and Agile at scale. Throughout his career, he has served as an engineering and program manager in multi-cultural, highly-distributed environments. As a methodologist, trainer and consultant, he has led numerous rollouts of Lean and Agile at scale, involving teams in North America, Europe and Asia, and has trained over a thousand coaches and change agents whose key role is to help their organizations achieve higher productivity and quality through the adoption of scalable, agile methods.

Alex is a founder of Org Mindset (http://orgmindset.com), a company whose mission is to help enterprises grow Lean-Agile mentality and build organizational habits in support of exploration and fast delivery of customer value.

Re-Read Saturday News

Chapter 2 of Holacracy tackles why the consolidation of authority is harmful to the ability to nimble, agile (small a), and productive organizations and secondly, why the distribution of authority supports an organization’s ability to scale.  The argument in Chapter 2 is a central tenant of Holacracy.

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

A Call To Action

I need your help. I have observed that most podcasts and speakers at conferences over-represent people from Europe and North America.  I would like to work on changing that exposure. I would like to develop a feature featuring alternate software development voices beginning with Africa and Southeast Asia. If this feature works we will extend it to other areas.   If you can introduce me to practitioners that would be willing to share their observations (short interviews) I would be appreciative!

Next SPaMCAST

The next Software Process and Measurement Cast will be a big show!  SPaMCAST 440 will feature our essay on two storytelling techniques premortems and business obituaries.  We will also have columns from Jeremy Berriault, Jon Quigley, and Steve Tendon.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

 

Categories: Process Management

Eight Characteristics of Successful Software Projects

Xebia Blog - Sun, 04/23/2017 - 09:21

We do a lot of software projects at Xebia Software Development. We work most of the time at our client’s location, in their teams. Together we improve the quality of their software, their process, and engineering culture. As such, we’ve seen a lot of projects play out. Most of these efforts succeeded but some failed. […]

The post Eight Characteristics of Successful Software Projects appeared first on Xebia Blog.

Holacracy: Re-read Week 3, Chapter 2 Distributing Authority

Book Cover

Holacracy

This week, we tackle chapter 2 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 2 tackles why the consolidation of authority is harmful to the ability to nimble, agile (small a), and productive and secondly, why the distribution of authority supports an organization’s ability to scale.  The argument in Chapter 2 is a central tenant of Holacracy.

 

Chapter 2: Distributing Authority

Concentrating the decision making in any single spot isn’t agile (small a) or scalable.  Holacracy distributes decision-making as close to the where the work is done as possible.  Robertson uses two metaphors outside of the typical workaday world to illustrate these points early in Chapter 2.  The first analogy centers around a discussion of why cities as they grow become more productive and innovative, while organizations become less productive and innovative as they grow. The conclusion is that work needs to emulate some of the attributes of cities, in particular how people are given a set of laws but within those constraints don’t have to wait for bosses/bureaucracy to make decisions and get things done. The second analogy provides a hint on how to make complex systems work.  The human body is a distributed system.  The system has overall rules, but each part runs separately with minimal input within those boundaries.  No single top-down decision-making process can keep as complex a system as the human body running.  

The metaphors illustrate that organic systems avoid top-down decision-making processes in practice.  There is significant evidence that even when strict top-down processes exist on paper, the real process is far different.  This “un” or identified decision-making process has its own problems making it difficult to know who is accountable or will generate friction.  In other scenarios, consensus decision making is used as a substitute.  Consensus decision making requires everyone’s input and is often slow, inefficient and unscalable.   

Holacracy addresses the problems in the typical organizational design by distributing the power to make decisions to the process which is defined the written constitution introduced in Chapter 1 (we will tie roles to the process later).  Using the city metaphor, the constitution represents the law and ordinances (or if you want a sporting metaphor to consider the constitution as the rulebook). The constitution the primary tool that distributes authority to the process and trumps everyone else, including the CEO, and those that wrote the constitution.  Power is ceded to the constitution. The constitution breaks the inferred parent-child relationships hierarchies are built upon.  Breaking the parent-child relationship creates an environment in which a team can self-organize to address the work they are presented with.  Determining how to change the organization to foster self-organization has been the single issue haunting the Agile movement since the term was coined. By distributing the decision-making into the process, Holacray provides people in the organization with the power to respond to issues locally within their domain without having to get everyone else to buy in. Empowerment!

Static decision making structures, whether distributed or not, rarely work well for long.  There needs to be a governance structure to provide the basis from which we can learn and improve the process.  Governance is an overused term with many definitions. For this book governance is defined as both who makes decisions and the limits under which those decisions are made. Robertson refines that definition by making a distinction between governance and operations.  Governance is about how we work, while operations are about getting work done.  A governance structure provides a decision-making process that allows the organization to change how it will work and make decisions based on the needs of the actual work.  Governance that is concentrated at the top of the hierarchy requires one or a select few people to make all of the decisions.  I have a number of friends that run “small” businesses (including my spouse), to a person they all had to learn the lesson that they need spend less time working “in” the business so they can work “on” the business. When that lesson hits home they learn how to distribute decision making.

Putting the concepts in Chapter 2 together, governance and the rules generated to implement the governance model define how the organization is structured.  That structure has only one goal, to bring about the organization’s purpose.  Operations delivers on the purpose.

Transformation Thoughts:  Changing an organization to be more able to quickly react to change or to speed knowledge work, requires pushing decision making down. Distributing the decision-making authority often means changing the organization’s structure.  This can rarely be done piecemeal.  Implementing Agile techniques in an effort to increase the flow value or increase speed to market without addressing distributed decision-making reduces the transformation effectiveness.

Team Coaching Thought:  All teams have a decision-making structure. Deciding on a governance model for the team that allows decision making to be distributed is as important as it is in larger organizations.   

Remember to buy a copy of Holacracy (use the link in the show notes to help support and defray the costs of the Software Process and Measurement Cast blog and podcast).

Previous Entries in the re-read:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization


Categories: Process Management

Being an Agile Security Officer: user stories

Xebia Blog - Sat, 04/22/2017 - 14:28

This is the fourth part of my 'Being an Agile Security Officer series'. In this blog post I will go deeper into the details of how user stories are created and what role security stakeholders should play in that. The Epic Within Agile, work is usually defined in user stories. These are minimal and defined […]

The post Being an Agile Security Officer: user stories appeared first on Xebia Blog.

Cheating and building secure iOS games

Xebia Blog - Fri, 04/21/2017 - 07:53

You probably have one of the million games where you earn achievements and unlock specials on your iPad or iPhone. If you develop games, you've probably wondered about people cheating your games? In this blog we're going to show you how to try cheating out yourself and how to build secure iOS games.The actual question […]

The post Cheating and building secure iOS games appeared first on Xebia Blog.

Capability Teams – One Solution for Dynamic Teams

Not Exactly A Capability Team But Close!

One of the holy grails of Agile in software development and other business scenarios is how to organize so that stable teams are efficient, effective and safe. The great preponderance of organizations use some variant of an organizational model that groups people by specialty and then allocate them to project teams.  This creates a matrix in which any practitioner will be part of two or more teams, which, in turn, means they have two or more managers and serve two or more masters.  People, like desks, chairs, and laptops, flow to the area of need, disband, and then return to a waiting pool until needed again.  One of the basic assumptions is that within some limits people are fungible and can be exchanged with relative impunity.  This approach has problems.  Ariana Racz, Senior Quality Assurance Analyst, provided a great summary of what is wrong with the idea that people are fungible in her response to Get Rid of Dynamic Teams: The Teams.  Ariana stated, “A resource on paper is not a resource in application.” In most circumstances, dynamic/matrixed teams reduce the productivity of knowledge workers.

An operational solution to using a dynamic/matrixed approach (we will return to where dynamic teams make sense – later) to build and manage a team is to adopt the idea of a capability (also known as a functionality) team.  The version of capability teams I espouse was influenced by an article written by Karl Scotland (What is Capability, Karl also appeared on SPaMCAST 174 to discuss Kanban Thinking).

A capability team is the group of roles needed to address and deliver a set of technical or business outcomes.  For example, to script, record, edit, post and promote the weekly Software process and Measurement Cast podcast there are five primary roles.  These roles are played by a fixed team of three people. This team has been together on this project for approximately 11 years with only a few minor tweaks in membership.  Each person in this small team has a specialty but can perform or support the roles of other members.  The podcast capability team can take the podcast from idea to delivery.

There are several important attributes of a capability team:

  1.      The team needs to include people that can perform all of the roles need to deliver functionality from idea to production.  A SaaS application capability team would include the roles of architect, business analysis, configuration, coding, testing, security and release management.  Many roles might be played by a single person or several people might play a single role depending on the work being addressed by the group.
  2.      The team reports to a single manager. The capability team represents the most important work team each member belongs to.
  3.      Membership in the team changes slowly based on the evolving context of the business (barring externalities such as people leaving the team).  Every team will change over time, however, in capability teams, change happens through evolution.  When teams need new knowledge the team members find a way to acquire that knowledge and increase the capability of the team.
  4.      A backlog of related valuable work is available for the team to draw work from.  This generally requires an organization to take a product view rather than a project view of work.  A product view recognizes that there is a need for enhancements, changes, and support continuously across the entire lifecycle of a product.  This flow does not easily conform to arbitrary start and end dates that are part of the definition of projects.
  5.      Capability teams dissolve or are repurposed when they are no longer needed.  No team is forever. When the value of the backlog of work they are serving is less than the cost of the team, they need to dissolve or find something else to do.

Capability teams are not a new invention. Capability teams are the norm in some industries.  My brother Nick builds custom homes in Baton Rouge, Louisiana.  Nick employees several capability teams.  For example, he has two crews that roof houses.  Each crew has people to perform all of the roles needed to successfully roof the houses Nick designs and builds. Team members rarely change and Nick says that it is impressive to watch them work as they seem to be able to anticipate the needs of other team members.  As impressive is the safety record of long-lived teams. Capability teams represent an approach to address one of the holy grails of increased efficiency and effectiveness promised by Agile: long-lived stable teams.

Next: Implementing: Capability Teams


Categories: Process Management

Engineering the Software Engineer

From the Editor of Methods & Tools - Wed, 04/19/2017 - 14:54
What are the characteristics of a good software engineer? It’s a topic many people would argue endlessly about. This is not surprising given we are effectively living in the era of software alchemy. Some of the best programmers draw on a strong scientific and engineering background. They combine this with craft like coding skills in […]

Software Development Linkopedia April 2017

From the Editor of Methods & Tools - Wed, 04/19/2017 - 08:04
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about team complexity, developer burnout, blaming, tester skills, code coverage, integration testing, front end architectures and agile antipatterns. Text: Team of Teams & Complexity: An Approach for breaking down Silos Text: […]

Get Rid Of Dynamic Teams: The Premise

Five Dysfunctions of a Team

Five Dysfunctions of a Team

The use of teams to deliver business value are at the core of most business models.  In matrix organizations teams are generally viewed as mutable, being formed and reformed from specialty labor pools to meet specific contexts. Teams can be customized to address emerging needs or critical problems and then fade away gracefully.  Examples of these kinds of teams include red teams or tiger teams.  This approach is viewed as maximizing organizational flexibility in a crisis.  The crisis generates the energy needed to focus the team on a specific problem.  However, as a general approach, dynamic teams have several problems because of how the organizations are structured and how people interact and become teams.

The Five Dysfunctions of a Team by Patrick Lencioni identified two principles that directly highlight issues with dynamic teams.

  1.       Team members are not easily replaceable parts.
  2.      You can only have primary loyalty to one team.

Each person on a team is a set of behaviors, capabilities, opinions, and biases.  For a team to be effective, the team members need to figure out how to fits all those different components together.  This requires a combination of self-knowledge and knowledge of your colleagues on the team.  When teams are established, members begin the process of learning each other’s biases and capabilities. This is often called team building. For a practical perspective, this knowledge is important for team effectively know how to allocate work and to identify warning signs when problems arise.  Almost all team change models, such as the Tuckman model (storming, norming, and performing), recognize that teams become more effective when they build this type of knowledge. Continually disrupting teams stops teams from becoming more effective.

The second principle that Lencioni raises that directly impacts dynamic teams is loyalty.  In a dynamic team, each team member needs to answer which team do they have primary loyalty towards.  Team members will trust team members from their primary team more than others (boundary biases) and will try not expose attributes of that team that could be perceived negatively.  When the needs of their primary team conflict with the need of their other team, one team will suffer.  It is not hard to guess which will get the short end of the stick.  The effectiveness of the team on the short end will suffer for two reasons.  The first is obvious, their work will either not get done or require others to step in to complete.  Second, team members that are not directly committed to the team will always be suspect. Their peers will always be looking over their shoulder waiting for them to drop the ball.

Even more basic are the cognitive biases which drive human behaviors.  Cognitive biases are patterns of behavior that reflect a deviation in judgment that occurs in particular situations. Teams that are always learning the nature and behavior of team members often fall victim to social and attribution biases.  These types of biases reflect errors we make when evaluating the rational for both our own behavior as well as the behavior of others. Team members that misinterpret behavior of other team members make mistakes.  Mistakes reduce team effectiveness and deliver defects which reduce the team’s perceived value setting off a negative spiral.

Dynamic teams driven by matrix management are an anchor that reduces the effectiveness of teams. Creating static teams that can meet organizational needs efficiently and effective is not as simple as declaring that all teams are fixed.  

Next:  Teams need to be constructed to match capabilities to the flow of work.  

 


Categories: Process Management

SPaMCAST 438 - Size for Testers, Organizations as Systems, Problem Solving

Software Process and Measurement Cast - Mon, 04/17/2017 - 01:23

The Software Process and Measurement Cast 438 features our essay on leveraging sizing in testing. Size can be a useful tool for budgeting and planning both at the portfolio level and the team level.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Organizations as Systems and Innovation. One of the highlights of the conversation is whether emergence is a primary factor driving change in a complex system.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses why blindly accepting canned solutions does not negate the need for active troubleshooting of for problems in software development.

Re-Read Saturday News

This week, we tackle chapter 1 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 1 is titled, Evolving Organization.  Holacracy is an approach to address shortcomings that have appeared as organizations evolve. Holacracy is not a silver bullet, but rather provides a stable platform for identifying and addressing problems efficiently.

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

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Alex Yakyma.  Our discussion focused on the industry's broken mindset that prevents it from being Lean and Agile.  A powerful and possibly controversial interview.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

Categories: Process Management

SPaMCAST 438 – Size for Testers, Organizations as Systems, Problem Solving

SPaMCAST Logo

http://www.spamcast.net

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

The Software Process and Measurement Cast 438 features our essay on leveraging sizing in testing. Size can be a useful tool for budgeting and planning both at the portfolio level and the team level.

Gene Hughson brings his Form Follows Function Blog to the cast this week to discuss his recent blog entry titled, Organizations as Systems and Innovation. One of the highlights of the conversation is whether emergence is a primary factor driving change in a complex system.

Our third column is from the Software Sensei, Kim Pries.  Kim discusses why blindly accepting canned solutions does not negate the need for active troubleshooting of for problems in software development.

Re-Read Saturday News

This week, we tackle chapter 1 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015. Chapter 1 is titled, Evolving Organization.  Holacracy is an approach to address shortcomings that have appeared as organizations evolve. Holacracy is not a silver bullet, but rather provides a stable platform for identifying and addressing problems efficiently.

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

Next SPaMCAST

The next Software Process and Measurement Cast will feature our interview with Alex Yakyma.  Our discussion focused on the industry’s broken mindset that prevents it from being Lean and Agile.  A powerful and possibly controversial interview.

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, for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management