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

SPaMCAST 448 ‚Äď Uncertainty in Software Development, TameFlow, Leading QA

SPaMCAST Logo

http://www.spamcast.net

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

SPaMCAST 448 features our essay on uncertainty. Al Pittampalli said, ‚Äúuncertainty and complexity produce anxiety we wish to escape.‚ÄĚ Dealing with uncertainty is part of nearly everything we do our goal should be to address uncertainty head on.

The second column features Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 18.  

Our third column is the return of Jeremy Berriault and his QA Corner. Jeremy discusses leading in  QA.  Jeremy  blogs at https://jberria.wordpress.com/

Re-Read Saturday News

Chapter 10 concludes our re-read of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson which was published by Henry Holt and Company in 2015. ¬†This week’s chapter is titled, The Experience of Holacracy. In this chapter, Robertson wraps up most of the loose ends. Next week we will conclude this re-read with some final comments and thoughts.

 

Catch up on the all of the Holacracy entries:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9 Adopting Holacracy

Week 10: Moving Toward Holacracy

Week 11: Experience of Holacracy

In two weeks we will begin the next book in our Re-read series,  The Science of Successful Organizational Change. (I ordered my copy have you?). Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.   I am looking forward to sitting on the other side of the table during the next re-read! Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you even got a single new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 449  will feature our interview with Jasveer Singh.  We discussed his new book, Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication.  Jasveer, proposes a new sizing methodology for estimation and other measurement processes.

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 448 - Uncertainty in Software Development, TameFlow, Leading QA

Software Process and Measurement Cast - Sun, 06/25/2017 - 22:00

SPaMCAST 448 features our essay on uncertainty. Al Pittampalli said, ‚Äúuncertainty and complexity produce anxiety we wish to escape.‚ÄĚ Dealing with uncertainty is part of nearly everything we do our goal should be to address uncertainty head on.

The second column features Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 18.  

Our third column is the return of Jeremy Berriault and his QA Corner. Jeremy discusses leading in  QA.  Jeremy  blogs at https://jberria.wordpress.com/

Re-Read Saturday News

Chapter 10 concludes our re-read of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson which was published by Henry Holt and Company in 2015.  This week's chapter is titled, The Experience of Holacracy. In this chapter, Robertson wraps up most of the loose ends. Next week we will conclude this re-read with some final comments and thoughts.

 

Catch up on the all of the Holacracy entries:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9 Adopting Holacracy

Week 10: Moving Toward Holacracy

Week 11: Experience of Holacracy

In two weeks we will begin the next book in our Re-read series,  The Science of Successful Organizational Change. (I ordered my copy have you?). Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.   I am looking forward to sitting on the other side of the table during the next re-read! Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you even got a single new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 449  will feature our interview with Jasveer Singh.  We discussed his new book, Functional Software Size Measurement Methodology with Effort Estimation and Performance Indication.  Jasveer, proposes a new sizing methodology for estimation and other measurement processes.

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

Holacracy: Re-read Week 11, Chapter 10: The Experience of Holacracy

Book Cover

Holacracy

In approximately two weeks we will begin the next book is, The Science of Successful Organizational Change. Remember to use the link to buy a copy to support the podcast and blog. The reread will be led by Steven Adams. I am looking forward to sitting on the other side of the table during the next re-read!

Chapter 10 completes Holacracy.  This week’s chapter is titled, The Experience of Holacracy.  This chapter sums up the changes that are generated when an organization adopts Holacracy.  Adopting Holacracy requires learning different ways to control and manage; perhaps it would be better to say lead a company.  While every organization has different issues as they adopt Holacracy, Robertson has observed a few fairly common themes.

Toppling the Hero

Heroic management does not fit the Holacracy model.  The distribution and democratization of decision making create an environment in which the hero is out of step with the organization.  Heroic forms of management concentrate decision making in one spot: the heroic CEO which forms a single point of failure.  Travis Kalanick, the CEO of Uber is an example of the type of problem that occurs when decision making is concentrated in one heroic figure. The organization is limited to the decision making throughput of the hero.

The idea of reducing the dependence on a hero has been a topic of discussion in organizational circles as long as I can remember.  While the reliance on heroics has been reduced, embracing Holacracy still requires a culture shift.  That culture shift requires heroic leaders to give up the power that provides them comfort (and probably and endorphin hit when they ride to the rescue).  At the same time roles that have avoided making decisions find fewer places to hide.  In either case, embracing Holacracy requires abandoning what is currently comfortable to find a new equilibrium in which authority and leadership are redistributed.

Operating as the Victim

The parent-child relationship (see blog) represents the standard management-worker operating model.  This relationship is often so ingrained that shifting the relationship requires significant energy and can cause consequences.  The redistribution of authority that is central to Holacracy changes the relationship between all of the roles within an organization.  Holacracy makes it more difficult to spend time grumbling about a problem when you have the authority to change the process.

One of the signs of change discussed by Robertson is when people begin to feel discomfort about not seeking consensus, begin apologizing for making certain decisions, or for rocking the organizational boat.  The discomfort is a sign that the parent-child relationship is evolving to something more akin to parent-adult relationship which is healthy for making decisions.

Moving Beyond a Personal Paradigm

Holacracy separates the idea of roles from individuals.  The separation of person and role along the distribution of authority moves a team or organization away from the need to rely on an individual, but rather to rely on the role.

The Evolution of the Organization

This section reminds us that Holacracy helps an organization shift from a static representation to an evolving, dynamic structure in which governance and decision making is distributed.

Next week some final thoughts.

Remember to buy a copy of Holacracy (use the link 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

Week 4: Organization Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9: Adopting Holacracy

Week 10: When You Are Not Ready

 


Categories: Process Management

Product Roadmap:  A Roadmap for Every Answer

Left and Right

 

Product Roadmap:  A Roadmap for Every Answer

Product roadmaps are a tool used to visually present a business strategy. Roadmaps serve multiple goals. The goals of roadmap development generally are varied, including not only the ultimate roadmap itself but also the journey to develop the roadmap.  Typical goals include:

  • Describing the vision and strategy visually. ¬†According to Pearson Prentice Hall, 65% of people are visual learners. ¬†A roadmap provides a powerful tool to connect with an audience.
  • Provide a guiding document for executing the strategy. A strategy is often visionary, the roadmap provides a path for action that moves past motivating words into tangible actions.
  • Get internal stakeholders in alignment. My four-year-old grandson‚Äôs favorite word is why. ¬†Frankly, it is contagious. ¬†A roadmap allows members of an organization to determine whether what they are working on fits into the big picture. ¬†The roadmap helps to answer ‚Äúwhy.‚ÄĚ
  • Facilitating the discussion of options and scenario planning. ¬†The journey to an initial roadmap and the process for maintaining the roadmap (a roadmap is not a destination) provides a process and an environment to discuss and evaluate how an organization is going to pursue its strategies to reach its goals.
  • Communication vehicle to external stakeholders, including customers. This is a classic use of roadmaps. Tuned for marketing, roadmaps are often invaluable for generating feedback as well locking in customers.

The myriad of goals that roadmaps can address implies that there are a number of different types of roadmaps.  Three different types of roadmaps are typical.

  1. Product/Business roadmaps are the classic version that provides the visualization of features and services required to deliver on a set of goal(s) and strategy.  The primary audiences for a product/business roadmap include executives (at a high level) and middle management (at a more granular level).
  2. Marketing roadmaps are typically an external communication vehicle predominately used for firms to communicate with customers outside the firm.  Note: I have seen teams serving internal customer bases develop marketing roadmaps.  The primary audiences for a marketing roadmap include sales, marketing, and customers.      
  3. IT roadmaps generally represent the planned evolution of one or more of the architectures stewarded by IT.  Architectures exist (whether documented or not) for information, systems, technology to name a few.  All of the IT architectures function within the business architecture and should enable the business’s strategy and goal.  IT roadmaps tend to follow the same audience pattern as product/business roadmaps with the exception that the level of detail sometimes is driven down to the sprint level (bad choice).  Remember that roadmaps are not plans!

The granularity of any roadmap is driven by what the tool is being used to communicate and, to some extent, hubris.  High-level product/business roadmaps tend to include high-level strategic initiatives the specifics of which fade the farther in the future the roadmap peers into the future.  Specificity in the future is a form of hubris.  Granularity can spin down into releases by period, specific features and in some cases maintenance and bug fixes (enter hubris again).

Roadmaps can serve many masters and answer many questions however there is not a one size fits all solution.

We will next tackle a suggested hierarchy of roadmaps in a typical corporate setting

 


Categories: Process Management

Avoiding deeply nested component trees

Xebia Blog - Thu, 06/22/2017 - 09:52

By passing child components down instead of data you can avoid passing data down through many levels of components. It also makes your components more reusable. Even multibrand components become much easier to build. Overall it is a pattern which improves your frontend code a lot! The Problem When building frontends you will pass data […]

The post Avoiding deeply nested component trees appeared first on Xebia Blog.

Programming Across Paradigms

From the Editor of Methods & Tools - Wed, 06/21/2017 - 18:46
What’s in a programming paradigm? How did the major paradigms come to be, and why? Once we’ve sworn our love to one paradigm, does a program written under any other still smell as sweet? Can functional programmers learn anything from the object-oriented paradigm, or vice versa? In this talk, we’ll try to understand what we […]

Product Roadmaps: Basics and Context

A Roadmap Provides Direction

Product roadmaps are a tool used to visually present an approach to translating a business strategy into the real world. The visualization of the impact of a strategy on a product allows all relevant constituencies to grasp how a product and its enablers are intended to evolve.  

In order to create and use product roadmaps, there are several key concepts and components that need to be agreed upon.  

The first concept that needs to be agreed upon is the definition of a product. Mike Cohn, of Mountain Goat Software, defines a product as ‚Äúa product is something (physical or not) that is created through a process and that provides benefits to a market.‚ÄĚ This definition gets rid of the distinction between tangible products and services to focus the idea value delivery. ¬†The most critical part of the definition is that the product must provide a benefit to a market. ¬†Much of internal IT‚Äôs work is either as part of the larger business-driven product or as an enabler. For example, learning management is a product delivered by human resources (HR) to the individuals within an organization. The system (e.g. PeopleSoft or Workday) and the network enable the product. The business strategy will define the future of the product which will in turn influence the enablers. ¬†

Some organizations make a major distinction between services and products.  The distinction is often made because services are intangible (can’t generate an inventory) while a product is tangible.  Making a distinction between a product and service may well impact how a strategy is delivered but is less useful when defining a  product roadmap or when determining whether a product owner should exist.  From a roadmap perspective, treating product and services the same is the simplest and best approach.

Many organizations create software-centric (or at least involved products) others use software to enable the delivery of value. ¬†Software-centric software functions will be identified on the product roadmap. For example, an ATM product roadmap might include purely software driven multi-lingual or voice activation functions. When the organization’s products are less software-centric the roadmap requires some form of linkage between the product and the technology which may be on two separate roadmaps. ¬†The potential for two very different paths is most obvious when leveraging commercial packages (COTS) or software as a service (SaaS). ¬†¬†In both cases, the software is serving multiple masters which may not match the business roadmap. Deciding on which part of the organization need to be covered by the roadmap is critical and can drive the need for a multilevel approach.

What ends up on a product roadmap depends on what you define as a product.  Internal IT organizations have a tendency to equate platforms to products and internal personnel as customers. This can lead to developing separate technology and business roadmaps.  While the best solution is to take a business first approach when separate roadmaps are generated, the organization will require a process to sync the two levels of roadmaps.


Categories: Process Management

Commenting Policy and How to Get Answers to Your Questions

Mike Cohn's Blog - Tue, 06/20/2017 - 17:00

Here is a short reminder about the Commenting Policy for this site. You can read the full policy here or via the link in the footer on every page.

A lot of the value of this blog comes from the discussion in the comments, and so it is important that all comments be related to the original post. While I appreciate anyone who takes the time to leave a comment, if a comment is not related to the original post, I won't reply and may delete the comment.

Do not hijack a post to an entirely different question. Please see if your question has been addressed by other posts. If not, you can submit it at http://www.mountaingoatsoftware.com/ask.

I try to address the questions and topics suggested there through this blog and my weekly tips emails.

I'm sorry, but I cannot reply by email to questions that are highly specific to your team. If your question or topic is one that I think is of general interest to others here, I will do my best to address it in a blog or weekly tip.

Quote of the Month June 2017

From the Editor of Methods & Tools - Tue, 06/20/2017 - 08:44
Avoid using defect tracking systems during the iteration. Fix bugs discovered in the work underway for the iteration immediately. If it takes a lot of work, create a task in the Spring backlog. However, there is usually no need to log this bug in the defect tracking system. Logging it would only create another work […]

SPaMCAST 447 ‚Äď Product Owners and The Business Analyst with Angela Wick

SPaMCAST Logo

http://www.spamcast.net

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

 

SPaMCAST 447 features our interview with Angela Wick on the role of the Product Owner and Business Analyst in Agile efforts. These two roles are critically important for delivering value in an Agile environment. Angela provides a fresh take on the Product Owner role and the Product Owner’s relationship to other roles Agile teams.

Angela is the founder of BA-Squared, LLC, a training and consulting practice.  She is passionate about modernizing requirements practices and helping organizations collaborate on a Product Vision aligned to strategy and guiding them to a meaningful backlog and iterations that keep the customer and organizational value top of mind.

She trains, coaches and teaches organizations on Product Ownership and Agile BA!

Email: Angela@BA-Squared.Com

Web: http://www.ba-squared.com

LinkedIn: https://www.linkedin.com/in/angelawickcbap

Twitter: https://twitter.com/WickAng


This is not first time the SPaMCAST has featured essays and conversations on the role of product owners ( for exampleSPaMCAST 430 and SPaMCAST 325).

 

Re-Read Saturday News

Chapter 9 continues the third section of Holacracy, Evolution Installed: Living Holacracy. ¬†¬†Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson was published by Henry Holt and Company in 2015. ¬†This week’s chapter is titled If You’re Not Ready To Adopt: Moving Toward Holacracy. ¬†In this chapter Robertson softens his if-you-can’t-do-it-all-don’t-do-anything approach. ¬†

This chapter begins with a story of Robertson being asked how they can move forward in a limited manner.  The person had just intently listened to a talk on Holacracy. The person explained that they could see the value, but did not have to power to change the organization or even their department.  Robertson’s knee jerk response was that you could not use parts; however, the response felt wrong.  So he reached out the larger community of practitioners to gather their field observations for how they handled scenarios in which everything could not be implemented.  Whether the story is apocryphal or not matters less than that this chapter softens the all-or-nothing stance stated earlier in the book.  

 

Catch up on the all of the Holacracy entries:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9 Adopting Holacracy

Week 10: Moving Toward Holacracy

 

In approximately three weeks we will begin the next book in our Re-read series,  The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.   I am looking forward to sitting on the other side of the table during the next re-read! Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

 

Next SPaMCAST

SPaMCAST 448 will feature our essay on uncertainty. Al Pittampalli said, ‚Äúuncertainty and complexity produce anxiety we wish to escape‚ÄĚ. Dealing with uncertainty is part of nearly everything we do. ¬†

The second column will feature Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 18.  

Our third column will be from Jeremy Berriaul.t. Jeremy discusses leading in  QA.  Jeremy  blogs at https://jberria.wordpress.com/  

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 447 - Product Owners and The Business Analyst with Angela Wick

Software Process and Measurement Cast - Sun, 06/18/2017 - 22:00

SPaMCAST 447 features our interview with Angela Wick on the role of the Product Owner and Business Analyst in Agile efforts. These two roles are critically important for delivering value in an Agile environment. Angela provides a fresh take on the Product Owner role and the Product Owner's relationship to other roles Agile teams.

Angela is the founder of BA-Squared, LLC, a training and consulting practice.  She is passionate about modernizing requirements practices and helping organizations collaborate on a Product Vision aligned to strategy and guiding them to a meaningful backlog and iterations that keep the customer and organizational value top of mind.

She trains, coaches and teaches organizations on Product Ownership and Agile BA!

Email: Angela@BA-Squared.Com

Web: http://www.ba-squared.com

LinkedIn: https://www.linkedin.com/in/angelawickcbap

Twitter: https://twitter.com/WickAng


This is not the first time the SPaMCAST has featured essays and conversations on the role of product owners ( for exampleSPaMCAST 430 and SPaMCAST 325).

 

Re-Read Saturday News

Chapter 9 continues the third section of Holacracy, Evolution Installed: Living Holacracy.   Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson was published by Henry Holt and Company in 2015.  This week's chapter is titled If You're Not Ready To Adopt: Moving Toward Holacracy.  In this chapter Robertson softens his if-you-can't-do-it-all-don't-do-anything approach.  

This chapter begins with a story of Robertson being asked how they can move forward in a limited manner.  The person had just intently listened to a talk on Holacracy. The person explained that they could see the value, but did not have to power to change the organization or even their department.  Robertson’s knee jerk response was that you could not use parts; however, the response felt wrong.  So he reached out the larger community of practitioners to gather their field observations for how they handled scenarios in which everything could not be implemented.  Whether the story is apocryphal or not matters less than that this chapter softens the all-or-nothing stance stated earlier in the book.  

 

Catch up on the all of the Holacracy entries:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9 Adopting Holacracy

Week 10: Moving Toward Holacracy

 

In approximately three weeks we will begin the next book in our Re-read series,  The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.   I am looking forward to sitting on the other side of the table during the next re-read! Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.

 

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

 

Next SPaMCAST

SPaMCAST 448 will feature our essay on uncertainty. Al Pittampalli said, ‚Äúuncertainty and complexity produce anxiety we wish to escape‚ÄĚ. Dealing with uncertainty is part of nearly everything we do. ¬†

The second column will feature Steve Tendon talking about Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 18.  

Our third column will be from Jeremy Berriaul.t. Jeremy discusses leading in  QA.  Jeremy  blogs at https://jberria.wordpress.com/  

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

Holacracy: Re-read Week 10, Chapter 9: If You’re Not Ready To Adopt: Moving Toward Holacracy

Book Cover

Holacracy

 

In approximately three weeks we will begin the next book is The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.   I am looking forward to sitting on the other side of the table during the next re-read!

Chapter 9 continues the third section of¬†Holacracy, Evolution Installed: Living Holacracy.¬† This week’s chapter is titled If You’re Not Ready To Adopt: Moving Toward Holacracy. ¬†In this chapter Robertson softens his if-you-can’t-do-it-all,-don’t-do-anything approach. ¬†

This chapter begins with a story of Robertson being asked by very someone that had just intently listened to a talk on Holacracy. The person intently explained that they could see the value but did not have to power to change an organization or even their department. ¬†Robertson’s knee jerk response was that you could not use parts; however, the response felt wrong. ¬†So he reached out the larger community of practitioners to gather their field observations for how they handled scenarios in which everything could not be implemented. ¬†Whether the story is apocryphal or not matters less than that this chapter softens the all or nothing stance stated earlier in the book.

Robertson suggests four ways that parts of Holacracy can be leveraged.  The are:

  1. Start using the language of Holacracy. Language is both a reflection of culture and a tool to generate culture. ¬†For example, shifting from using words like ‘problems’ and ‘solutions’ to ‘tensions’ and ‘processing’ shifts the blame-game dialog to a dialog of continual improvement. ¬†Other examples include using providing proposal instead or just identifying problems. ¬†A final example is to stop talking about people and focus discussions on roles. The idea is that if you change the words used in the organization the culture will follow.
  2. Rewrite your role descriptions.  Writing or rewriting role descriptions changes the focus to the set of activities needed to deliver value rather than mushy job descriptions.  Once written roles then evolve to address changes in the environment more easily than modifying job description with often is mired in bureaucratic rules. 
  3. Work on your organization not just in it.  Own the part of the business you can and engage in governance (a Holacracy word) to make changes that will help people work together to deliver value. Change the part of the organization that is within your span of control.  Foster an entrepreneurial mindset and evangelize that mindset to colleagues in an effort to evolve the organization.  
  4. Streamline your meetings. The meeting structure for tactical meetings, with its focus on building a dynamic agenda, training issues and processing one issue at a time, have value outside of Holacracy.  Robertson also suggests that the check in and closing rounds are useful focusing mechanisms in all meetings.  Another meeting technique that I have borrowed is the integrated decision-making process (described on page 72).  I have found the process useful for meetings that have to get through a number of emotionally charged decisions in an efficient manner (such as a project review board).

Chapter 9 answers, for a second time, the question of whether you can do parts of Holacracy by saying you can’t do Holacracy without going all in, but you can borrow parts and perhaps start the change.

Remember to buy a copy of Holacracy (use the link 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

Week 4: Organization Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9:Adopting Holacracy

 


Categories: Process Management

Adaptability Requires Comfort With Uncertainty

Making decisions is exhausting. It involves perception and analysis, and most of all: taking responsibility.
Mental load and the worry cache, Seth Godin, June 15, 2017

In most organizations, software development and maintenance is not a solitary activity.  Even a relatively simple enhancement require the involvement of multiple roles to identify, translate and implement an idea.  Teams are the tool used to effectively gather and coordinate all the needed roles in one place. While it is easy to perceive the team as a monolithic unit, every individual on a team is a decision-making machine.  Each person will have a different tolerance for uncertainty and ambiguity which will affect how they make decisions.

In 1983, Geert Hofstede published a paper titled National Cultures in Four Dimensions.  The paper introduced the idea of the Uncertainty Avoidance Index (UAI) to explain behavioral differences between nations. The theories espoused by Dr. Hofstede illustrate that different cultures react to uncertainty differently. Organizations and the teams inside those organizations also have different tolerances for uncertainty.  While the factors that influence how avoidant of uncertainty any organization or team are probably far more complex than national cultures, what is important is that we understand that some organizations and teams will avoid uncertainty more vociferously than others. In software development, how work is done is often a reflection of differing approaches and needs to reduce the anxiety generated by uncertainty.

Software development organizations that are highly avoidant of uncertainty exhibit many of the following attributes:

  1. Structure and rules focus. Development processes are spelled out at a high level of granularity and are often augmented by informal norms and rules.  Changing the process is formally evaluated and approved.
  2. Roles and individuals are conflated.  An individual plays a specific role and is expected to have a high degree of expertise in the role which makes them required participants for decisions that impact the role.
  3. Consensus decision making is used to increase the knowledge base for any specific decision while distributing responsibility.  Consensus decision making often increases the required energy to generate a specific decision. 
  4. Life is hectic.  Significant amounts of energy are required to continuously monitor the flow of work and the decisions being made that could possibly affect the work being performed. Excuse me while I check email and Slack on my iPhone during a meeting.  

Organizations and teams whose work and products impact health or safety often all into this category. The people that work in this environment must be comfortable with this form of structure. Organizations that have less tolerance for uncertainty will gravitate toward frameworks and methods that provide them a level of structure that reduces uncertainty.  DSDM, SAFe and other more structured approaches are often used in organizations in which uncertainty generates anxiety.

The reaction any team or organization has to uncertainty will be different, which is why there is no one perfect framework or method for delivering value. Highly structured approaches will appeal to some organizations while less structured approaches will appeal to others.  While these are just two poles on a continuum, my observations is that most organizations tend to live closer to one end than the center. That makes using the wrong approach in an organization tantamount two teams playing football together with one using the rules from the National Football League and the other playing by the rules of the Canadian Football League.  The result would be lots of tension.

 


Categories: Process Management

Software Development Linkopedia June 2017

From the Editor of Methods & Tools - Wed, 06/14/2017 - 13:52
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 product owner, project deadlines, working in teams, unit testing, better retrospectives, surviving as a QA, legacy code transformation, microservices, Scrum challenges and automated testing. Web site: Product Owner Assessment Text: […]

Reducing Uncertainty

Sign for Sheltering In Place

Sheltering Reduces Uncertainty

‚ÄúUncertainty and complexity produce anxiety we wish to escape‚ÄĚ. ‚Äď Al Pittampalli from How to Hold Meetings That Actually End With Decisions (Webinar June 8, 2017)

Much of the process of translating a user story or requirement into something that can be used is as much about managing and removing uncertainty as it is about technical transformation. Agile and legacy development (used in the broadest sense) are littered with techniques to help the team learn and to gather feedback. The techniques can be sorted into three categories:

  1. Forced Constraints (when reasonable) are useful in generating focus.  Common techniques in this category include time boxing (such as a sprint in Scrum or program increment in SAFe), breaking work into smaller components (story grooming) and defining a minimum viable product.  In each case, a constraint is introduced that forces a team to evaluate the set of solutions which often leads to a reduction in complexity and uncertainty.
  2. Experiments are set of techniques that allow teams to evaluate specific solutions on a small scale and use the outcomes to determine whether the solution is feasible. ¬†In Agile and lean circles this is often evangelized with the slogan of ‚Äúfail fast‚ÄĚ. A/B testing is a form of experiment that is often used to test business to customer (B2C) interactions. ¬†For example, A/B testing is commonly used to determine which headline will attract more attention on news sites. The results of the experiment allow the news site to deliver more value for their stakeholders (advertisers). ¬†Another form of experimentation that has been used, since time immemorial, is prototyping. Prototyping is a mechanism to test a concept before a team or organization makes a larger commitment of resources. The use of experiments reduces uncertainty.
  3. Feedback an incredibly powerful tool for reducing uncertainty when actively generated and evaluated.  Techniques such as peer reviews, pair-programing, demonstrations, daily Scrum meetings, and testing are tools specifically designed to actively generate feedback. Passive techniques Рsuch as asking for comments at the end of a blog entry Рtypically generate feedback more erratically than planned and active techniques, and are therefore less useful for reducing uncertainty.  Feedback generates information, which reduces what we don’t know (or exposes what is unknown) and therefore reduces uncertainty.

Many software development techniques are combinations of these strategies.  The ubiquitous sprint in Scrum is a forced constraint as teams are forced to get work done so they can receive feedback and then use that feedback to re-plan their course of action.

Uncertainty causes anxiety.  The Atlantic article, How Uncertainty Fuels Anxiety, states that everyone has a different level of tolerance to uncertainty (intolerance uncertainty scale).  Software development and maintenance often have a lot of uncertainty.  Nearly every day we are confronted with questions about issues and solutions.  Do we know how to solve a problem?  Do we have the skills to execute a solution?  Do we even know what the problem we are trying to solve is?  There are numerous techniques for reducing uncertainty which should be built into how work is performed.  How many are used for any piece of work is a function of an organization’s and team’s tolerance for uncertainty.


Categories: Process Management

Four Things to Do Before the Scrum Master Goes on Vacation

Mike Cohn's Blog - Tue, 06/13/2017 - 17:00

Ahhh, summer. Warm weather. Beaches. Barbecues. And vacations.

Vacations are great, but what happens when a team's Scrum Master goes on vacation? Should someone fill in? Should the team refactor code and fix bugs rather than try to work in a sprint while the Scrum Master is away?

To a large extent, answers depend on how long the Scrum Master will be on vacation. The one (and only) nice thing about the short vacations prevalent in the United States is that it's fairly easy for a team to get by without their Scrum Master for a week. It's much more challenging when a Scrum Master takes a more European month-long holiday.

Regardless of whether the Scrum Master will be gone for a week or a month, there are four things good Scrum Masters will do to ensure their teams continue to be successful without them.

Find a Replacement

First, the vacationing Scrum Master should consider looking for a temporary replacement. If the team is experienced with Scrum and with each other, the team could be fine without a Scrum Master if the Scrum Master’s absence is going to be short. I define short as up to a week for any team and up to two weeks for a team doing four-week sprints.

All other teams should try to have a replacement Scrum Master. The replacement could be a Scrum Master from a different team who helps out. It could be someone on the team who is curious about the role and who perhaps wants to try it out in a low-key manner.

A Scrum Master’s vacation can also be a good time to rotate the role among team members who are interested in or skilled at the role. The role might rotate daily or weekly depending on the length of the absence.

Clarify Expectations with the Team

In addition to securing a replacement Scrum Master, if one will be needed, a second thing a Scrum Master should do before departing on vacation is to clarify expectations with the team.

One important expectation is that the team will continue (as much as is practical) to use Scrum. A common fallacy is that some of the Scrum meetings exist for the Scrum Master. Teams that believe the daily scrum is a status update to the Scrum Master will be quick to abandon that “unnecessary” meeting when the Scrum Master is on vacation.

If it hasn’t been done long before, departing Scrum Masters need to correct any misperceptions that Scrum’s meetings or artifacts existing solely for a Scrum Master’s own benefit.

The Scrum Master should also set the expectation that not every impediment the team faces will be removed as quickly as normal. Even if a replacement Scrum Master is in place, the replacement may not have the time, skills, or connections to remove impediments as quickly as the vacationing Scrum Master.

Consider Changing the Sprint Length

A third consideration is changing the team’s sprint length. I rarely recommend changing a team’s sprint length, unless the team is making what they consider a permanent change.

For example, don't insert a three-week sprint into your normal pattern of two-week sprints without a really good reason for doing so. Sometimes Christmas or other similarly impactful holidays can be a good reason. If most of your team is going to be gone at the end of one sprint (and start of the next) because of a major holiday, it's worth at least considering making a sprint a week longer (or shorter).

Similarly, if the Scrum Master is going to be on vacation when a team would normally conduct its review, retrospective and next planning meeting, it might be worth delaying the end of the sprint by a week--in other words, add a week to this, and only this, sprint..

I would recommend a sprint-length change only for teams that are very new to Scrum and need their permanent Scrum Master there to facilitate the end-of-sprint/beginning-of-sprint events. A team with sufficient Scrum experience should be quite adept at those meetings and should be fine without its regular Scrum Master.

Consider Providing Emergency Contact Information

Finally, the vacationing Scrum Master should consider leaving emergency contact information with the team.

I'm a big proponent of being able to completely disconnect from work while on vacation. (Of course, I rarely follow my own advice.) However, there's a difference between being disconnected and being completely unavailable.

Because of their role as impediment solvers, Scrum Masters often have their fingers in many things. Because of this, someone on the team may occasionally need to get in touch with the Scrum Master.

This should happen very infrequently, but needs can occasionally arise. For example, last year I needed to contact a vacationing Scrum Master to get her login information for a tool she'd subscribed to for the team and was the only administrator on. We exchanged three text messages but it helped avoid a really painful workaround the team would have had to do for 3 weeks.

Another time, I reached out to a vacationing Scrum Master who had forgotten to leave notes on the seating arrangements for the new building the team was moving into. This Scrum Master had facilitated a slightly heated series of discussions with team members over how they would use their new space. I wanted to honor those earlier discussions by doing what had been agreed upon. I also wanted to avoid putting the team through the arguments again.

I don't want a Scrum Master thinking about work while on vacation, but providing emergency contact info to one person on the team or to another ScrumMaster can be helpful as long as the privilege isn't abused. It really should be for emergencies only.

A Team Can Perform Well While the Scrum Master Is Away

A great Scrum Master is a vital component of a successful, high-performing Scrum team. But a team can continue to perform well while the Scrum Master is on vacation as long as some thought is given in advance to finding a replacement Scrum Master, clarifying expectations about what should happen while the Scrum Master is away, changing the sprint length, and providing emergency contact information.

What Do You Think?

What’s your experience with a Scrum Master going on vacation? Are there things you’ve done or seen that help a team continue to do well while the Scrum Master is away?

Property-based testing in Java with JUnit-Quickcheck - Part 2: Generators

Xebia Blog - Mon, 06/12/2017 - 09:45

In Part 1 of this tutorial we¬†created a Property-based test (PBT) from a normal JUnit test with basic types. Now let us extend the domain object PostalParcel with a list of Products. All examples are written with Java 8 and can be downloaded from my gitlab repository. Write an unit¬†test for the function deliveryCosts with […]

The post Property-based testing in Java with JUnit-Quickcheck - Part 2: Generators appeared first on Xebia Blog.

Property-based testing in Java with JUnit-Quickcheck - Part 1: The basics

Xebia Blog - Mon, 06/12/2017 - 06:48

To be able to show you what Property-based testing (PBT) is, let's start by grasping the concept of a property in programming languages.¬†Since this is a Java tutorial, I will start with¬†Oracle and their¬†definition of a property in their¬†glossary: Characteristics of an object that users can set, such as the color of a window. Property […]

The post Property-based testing in Java with JUnit-Quickcheck - Part 1: The basics appeared first on Xebia Blog.

SPaMCAST 446 ‚Äď Questions, Go-To People, Servant Leadership

SPaMCAST Logo

http://www.spamcast.net

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

SPaMCAST 446 will feature our essay on questions.  Questions are a coach and facilitator’s secret power! But, with great power comes great responsibility.  

Our second column is from Gene Hughson.  Gene and I discussed his essay Go-to People Considered Harmful originally published on his blog Form Follows Function (www.genehughson.wordpress.com).  The concept may sound counterintuitive, but it is not.

The third column is from Kim Pries, the Software Sensei.  In this installment, Kim dives into the topic of servant leadership.

Re-Read Saturday News

This week we tackle Chapter 8 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 8 is a bit of a bits and bobs chapter but begins to draw in a lot of loose threads.  

This week we also announce the next book in the re-read series.  The envelope please. . . . The next book is The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.  Steve has been an active participant in many of our previous re-reads and has appeared twice on the Software Process and Measurement Cast to discuss earlier re-reads.  I will provide supplemental comments and highlights.  I am looking forward to sitting on the other side of the table during the next re-read!

Catch up on the all of the Holacracy entries:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9 Adopting Holacracy

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

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 447 will feature our interview with Angela Wick on the role of the product owner and business analyst in Agile efforts.The two roles are important and interrelated. This is not first-time the SPaMCAST has featured essays and conversations on the role of product owners ( for example SPaMCAST 430 and SPaMCAST 325).  Angela provides a fresh take on the role!

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 446 - Questions, Go-To People, Servant Leadership

Software Process and Measurement Cast - Sun, 06/11/2017 - 22:00

SPaMCAST 446 will feature our essay on questions.  Questions are a coach and facilitator’s secret power! But, with great power comes great responsibility.  

Our second column is from Gene Hughson.  Gene and I discussed his essay Go-to People Considered Harmful originally published on his blog Form Follows Function (www.genehughson.wordpress.com).  The concept may sound counterintuitive, but it is not.

The third column is from Kim Pries, the Software Sensei.  In this installment, Kim dives into the topic of servant leadership.

Re-Read Saturday News

This week we tackle Chapter 8 of Holacracy: The New Management System for a Rapidly Changing World by Brian J. Robertson published by Henry Holt and Company in 2015.  Chapter 8 is a bit of a bits and bobs chapter but begins to draw in a lot of loose threads.  

This week we also announce the next book in the re-read series.  The envelope please. . . . The next book is The Science of Successful Organizational Change. Remember to use the link to buy a copy in order to support the podcast and blog. The reread will be led by Steven Adams.  Steve has been an active participant in many of our previous re-reads and has appeared twice on the Software Process and Measurement Cast to discuss earlier re-reads.  I will provide supplemental comments and highlights.  I am looking forward to sitting on the other side of the table during the next re-read!

Catch up on the all of the Holacracy entries:

Week 1:  Logistics and Introduction

Week 2: Evolving Organization

Week 3: Distribution Authority

Week 4: Organizational Structure

Week 5: Governance

Week 6: Operations

Week 7: Facilitating Governance

Week 8: Strategy and Dynamic Control

Week 9 Adopting Holacracy

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

A Call To Action

If you got a new idea this week while listening to the podcast, please give the SPaMCAST a short, honest review in iTunes, Stitcher or wherever you are listening.  If you leave a review please send a copy to spamcastinfo@gmail.com.  Reviews help guide people to the cast!

Next SPaMCAST

SPaMCAST 447 will feature our interview with Angela Wick on the role of the product owner and business analyst in Agile efforts.The two roles are important and interrelated. This is not first-time the SPaMCAST has featured essays and conversations on the role of product owners ( for example SPaMCAST 430 and SPaMCAST 325).  Angela provides a fresh take on the role!

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