Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/5' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

SPaMCAST 412 ‚Äď XP Explained a Discussion with Steven Adams

SPaMCAST Logo

http://www.spamcast.net

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

The Software Process and Measurement Cast 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.
Steve lives in the San Francisco Bay Area (a.k.a, Silicon Valley) where he has a successful career in software development.  Steve has worked for Hewlett Packard, Access Systems Inc,, Trilliant Inc., and Sony Mobile Communications; plus has consulted at Cisco Systems.  Steve has a computer science degree from California State University at Chico, learned software project management at Hewlett-Packard and, in 2009, started his Agile journey with Sony Ericsson.  Steve enjoys listening to technical podcasts, and SpamCast was one of the first and is a favorite!  Steve is also an avid bicyclist (road) and is on track to log over 3,500 miles in 2016.

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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 412 - XP Explained a Discussion with Steven Adams

Software Process and Measurement Cast - Sun, 09/25/2016 - 22:00

The Software Process and Measurement Cast 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.


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

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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 412 - XP Explained a Discussion with Steven Adams

Software Process and Measurement Cast - Sun, 09/25/2016 - 22:00

The Software Process and Measurement Cast 412 features our discussion of XP Explained, Second Edition with Steven Adams.  It was a great talk that helped me understand why the book has (and continues to have) such a large impact on how I view Agile and software development.


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

Blog: https://sadams510.wordpress.com/
Twitter: @stevena510

Re-Read Saturday News

We begin the read/re-read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  The Five Dysfunctions of a Team is a business novel that uses a story to get important ideas across to the reader in a less threatening manner.  This week we address the introduction and some of the backstory. All of this provides the background for us to recognize the impact of poor teamwork!   

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

Next SPaMCAST

The Software Process and Measurement Cast 413 will feature our essay on Scaling Agile and Management Styles.  This essay builds on our recent discussion of servant leadership.  We will also have columns from Steve Tendon talking about another chapter in his great book Hyper Productive Knowledge Work Performance, The Tame Flow Approach and a visit to the QA Corner with Jeremy Berriault.

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

Five Dysfunctions of a Team, Patrick Lencioni:  Re-Read Week 1

The Five Dysfunctions of a Team Cover

The “Book” during unboxing!

Today we begin the read of  The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing) as part of our Re-Read Saturday feature. This book uses a business novel approach to make his points. As I noted as we completed the re-read of XP Explained, Steve Adams suggested this book. This is a first read for me.  Please buy a copy and read along.  When we are done I will invite anyone that has contributed to the discussion to appear on the Software Process and Measurement Cast for a wrap-up discussion.

The book includes an introduction, two major sections, and 4 additional chapters. The two sections are titled:

  1.    The Fable.  The fable has five parts noted in the table of contents; however, it is made up of a large number of subsections.
  2.    The Model with three parts.

I suspect that we will read the book over 12 -13 weeks, each week representing a review of roughly 20 – 30 pages (depending on breaks in the book and the need to discuss the Lencioni‚Äôs ideas). Now without further ado…

Introduction

In the introduction, Lencioni begins by throwing down the gauntlet that teamwork is the ultimate competitive advantage.  In his mind, it is such an advantage because it is rare.  If I hold up the evidence I see in my career as the norm Lencioni hits the mark; real teamwork is not easy and often conflicts with what many of the perceived tenants of the dog-eat-dog hierarchical work environment.

Lencioni goes on to suggest that teams¬†because they’re made up of people, are dysfunctional by nature. Teams often reflect all of the dysfunctions of the people in and around the team. ¬†That said, the basic premise of the book is ‚Äúthat building a strong team is both possible and remarkably simple.‚ÄĚ ¬†However, at the same time is hard to create and care for a strong team. ¬†Strong teams require that we overcome behavioral tendencies that disrupt the ability of people to work together.

Lencioni concludes the introduction with a great ‚Äėwhy should I read this book‚Äô hook: the idea that we are interested in teams because the real power of teamwork is that you achieve more than individuals could do alone.

Section 1: The Fable

Quick Notes: The Fable section is composed of 45 subsections.  Each section ranges from one page to 90 pages.  For example, the first section is called Luck and is a one pager.  The first few sections are an exposition to build upon later in the book.

Luck introduces basic plot premise of the Fable, which Lencioni uses to illustrate the five dysfunctions of a team. DecisionTech is in trouble (if you did not know what a struggling firm looked like in 2002, by 2016 I am sure you have seen one or more them). The Board of Directors, lead by the Chairman, has decided to bring in an outsider, Kathryn Peterson, as the new CEO.  The Chairman of the Board is her primary supporter. 

Part one: Underachievement 

This section continues the exposition and provides sections that include background on the main players in the overall morality play. (Section titles are in bold)

Backstory ‚Äď DecisionTech began as well funded startup with a hand-picked executive team, nicknamed ‚Äúthe staff‚ÄĚ by the rest of the firm. The executive team was much akin to an all-star team. ¬†The firm started off with a great attitude. ¬†The beginning mentally painted the picture of the infamous emotional cycle of change many endeavors seem to face. ¬†By the two-year anniversary, the initial CEO and co-founder, Jeff Shanley was asked to step down but not to leave (warning bells, anyone?). The management team had developed into a toxic morass with people holding on the potential payout of going public. No one was unhappy that Jeff was moved aside.

Kathryn – The other executives of DecisionTech had significant problems with Kathryn‚Äôs lack of experience in high tech and the culture of the firms she had been with. That said everyone recognized that the Chairman of the Board was known to have good instincts. ¬†He personally assured the rest of the Board that she would succeed. In reality, DecisionTech was at the edge of the cliff and just changing people without address the real issues was not going to solve the problem. The last sentence in this section: “she (Kathryn) had an amazing gift for building teams” foreshadows the main theme of the book.

Grumblings – In the first few weeks of Kathryn’s term as president, she did or at least was perceived to do nothing other than schedule a series of off-site executive meetings. ¬†People complained about being asked to be away from the office and not being able to control the agenda.

Observations ‚Äď The title of this section is critical and goes a long way to explaining Kathryn‚Äôs behavior that set off grumblings. ¬†Observing DescionTech for two weeks provided Kathryn with an understanding of just how dysfunctional her executive team was and how big a challenge it would be to sort things despite her vast experience.

The next section establishes the background of the individuals (this is not a team, yet) on the executive team. ¬†These first few sections provide a basis for the raison d’√™tre of the book. ¬†Lencioni has painted a picture of a start-up that began with great expectations and an all-star cast of players to staff the executive level. There is no indication that the executive team worked well or played well together. ¬†The lack of teamwork had brought the firm to the brink of failure.

Buy a copy of  The Five Dysfunctions of a Team and read along.  Using the link will help support the blog, podcast and most importantly the author of  The Five Dysfunctions of a Team.

 


Categories: Process Management

Risk Tolerance

This is a risk I'm willing to take.

This is a risk I’m willing to take.

A risk is the potential or exposure to danger, harm or loss. The concept of risk is understandable to everyone involved in delivering work, at least a basic level. We understand that ‚Äústuff‚ÄĚ can happen when we least expect it to happen, in a project or in our individual lives. ¬†The question is whether any specific risk or the accumulation of risks is worth taking action to avoid. ¬†Which risks are perceived to be so daunting that they need to be actively avoided is based on personal and organizational perspectives and biases. ¬†The technical term for this behavior is risk tolerance. ¬†In response to Internal and External Risk, Matt Williams commented:

‚ÄúAn important step that I think often gets overlooked is the act of defining a risk tolerance.”

While many teams (or organizations) may have an intuitive sense of their risk tolerance, I think it‚Äôs helpful to have an explicit, conscious discussion about risk tolerance.‚ÄĚ

We can define risk tolerance in simple terms as how much value are we willing to lose if a risk materializes.  The impact of a risk materializing and becoming an issue can range from rework, a reduction in returns, shifting positive perceptions or a compliance failure. A reflection of risk tolerance, in the financial markets, is the difference between the rates of return for a financial instrument (e.g. stocks, bonds, and others) and another financial instrument (such as a treasury bond). In finance the higher the risk the higher the return is required to balance.

If risk tolerance is important for the governance of software development and maintenance projects we need a mechanism to define tolerable and intolerable risks before we decide how to ROAM risks. ¬†Assessing risk tolerance is an evaluation of the willingness to take on risks and how much “exposure” from threats from outside the company are acceptable.

In a further comment Mr. Williams went on:

“I think risk tolerance is very context-specific.

It depends in part on the organization ‚Äď its size, culture, mission, etc. ‚Äď in part on the project and its specific nature, and in part on the nature of the risk itself.‚ÄĚ

Every person and organization has a different level of risk tolerance.  We can visualize risk tolerance in a chart as a curve. Risk tolerance is a balance between probability the probability a risk occurs and the impact that will be realized if it does occur.  In most software development and maintenance efforts defining the risk/tolerance curve is an implicit rather than explicit act.  The issue is that a team’s or organization’s level of  risk tolerance will cause different behaviors.  Risk avoiders, teams or organizations that fear the impact of risks, will tend to do more research or analysis before committing to a direction.  Risk takers tend to try approaches and then pivot if needed.

Risk tolerance affects how everyone in an organization behaves. ¬†Rarely, however, does everyone in an organization have the same tolerance towards risk. ¬†Defining or at least developing an understanding of a team‚Äôs risk tolerance isn‚Äôt merely an academic discussion. ¬†Differences in risk tolerance can generate tensions and risks of its own, therefore at the very least teams need in the words of Mr. Williams, ‚Äúhave an explicit, conscious discussion.‚ÄĚ

Current Risk Arc:

Internal and External Risks

Incorporating the Idea of External Risk into Agile Efforts

Risk Tolerance (Current)

Measuring Risk Tolerance

******

 


Categories: Process Management

Distributed Stand Up Meetings

Shadow

Distributed Agile teams require a different level of care and feeding than a co-located team in order to ensure that they are as effective as possible. This is even truer for a team that is working through their forming-storming-norming process. Core to making Agile-as-framework work effectively are the concepts of team and communication. Daily stand-up meetings are one the most important communication tools used in Scrum or other Agile/Lean frameworks. Techniques that are effective for making daily stand-ups work for distributed teams include:

  • Deal with the time zone issue. There are two primary options to deal with time zones. The first is to keep the team members within three or four time zones of each other. Given typical sourcing options, this tends to be difficult. A second option is to rotate the time for the stand-up meeting from sprint to sprint so that everyone loses a similar amount of sleep (share the pain option). One¬†usable¬†solution that can be tried when distributed teams can‚Äôt overlap is to have one team member (rotate) staying late or coming in early to overlap work times.
  • Identify and attack blockers between stand-ups. Typically, on distributed teams, all parties will not work at the same time. Team members should be counseled to communicate blockers to the team as soon as they are discovered so that something discovered late in the day in one time zone does not affect the team in a different time zone that might ¬†be just¬†starting to work. One group I worked with had stand-ups twice each day (at the beginning of the day and at the end of the day) to ensure continuous communication.
  • Push status outside the stand-up. A solution suggested by Matt Hauser is to have the team answer the classic three questions (What did you do yesterday? What will you do today? Is there anything blocking your progress?) on a WIKI for everyone on the team to read before the stand-up meeting. This helps focus the meeting on planning or dealing with issues.
  • Vary the question set being asked. The process of varying the question set keeps the team focused on communication rather than giving a memorized speech. For example ask:
    1. Is anyone stuck?
    2. Does anyone need help?
    3. What did not get completed yesterday?
    4. Is there anything everyone should know?

This technique can be used for non-distributed teams as well as distributed teams.

  • Make sure the meeting stays ‚Äúcrisp.‚ÄĚ Stand-up meetings by definition are short and to the point. The team needs to ensure that the meeting stays as disciplined as possible. All team members should show up on time and be prepared to discuss their role in the project. Discussion includes the willingness to ask for help and to provide help to team members.
  • Ensure that everyone is standing. This is code for making sure that everyone is paying attention and staying focused. Standing is just one technique for helping team members stay focused. Other tips include banning cell phones and side conversations.
  • Use a physical status wall. While the term ‚Äúdistributed‚ÄĚ screams tool usage, using a physical wall helps to focus the team. The simplicity of a physical wall takes the complexity of tool usage off the table so the focus can be on communication. Use of a physical wall in a distributed environment will mean using video to capture¬†tasks moving on the wall (after the fact a picture can be provided to the team). If video is not available, use a tool to which¬†EVERYONE has access. Keep tools as simple as possible.
  • Don‚Äôt stop doing stand-ups. Stand-up meetings are a critical communication and planning event, not doing stand-ups for a distributed team is an indicator that the organization should go back to project manager/plan-based methods.

Like any other distributed team meeting, having good telecommunication/video tools is not only important, it is a prerequisite. If team members can’t hear each other, they CAN’T communicate.

Stand-ups are nearly ubiquitous in Agile. I would do stand-ups even if I were not doing Agile. However, despite their simplicity, the added complexity of distributed teams can cause problems. The whole team is responsible for making the stand-up meetings work. While the Scrum master may take the lead in insuring the logistics are right or to facilitate the session when needed, everyone needs to play a role.


Categories: Process Management

Acceptance Tests & Agile Teams Coaching in Methods & Tools Fall 2016 issue

From the Editor of Methods & Tools - Tue, 09/20/2016 - 13:13
Methods & Tools ‚Äď the free e-magazine for software developers, testers and project managers ‚Äď has published its Fall 2016 issue that discusses alternatives to acceptance tests, Agile transformation, software project estimation, Agile coaching and the following free software tools: DbFit, generjee, Mox. Methods & Tools Fall 2016 issue content: * Alternatives to Acceptance Tests […]

The Five Belts Of The Product Owner

Xebia Blog - Tue, 09/20/2016 - 08:35
One of the cool things that Europeans added to Judo is the belt system. Japanese are patient by nature, they either do or don't. In fact they distinguish only the black belt, you either have it or are progressing towards it. We need a bit more guidance to know we are on the right way,

SPaMCAST 411 ‚Äď Servant Leadership, Systems Thinking, Craftsmanship, Requirements

SPaMCAST Logo

http://www.spamcast.net

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

The Software Process and Measurement Cast 411 includes four columns!  The first is our thoughts on servant leadership. A servant leader facilitates collaboration not only by creating a learning environment but also by helping the team to establish a vision and goals.  Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. Many of the links between servant leadership and Agile are because servant leadership enables several of the principles in the Agile Manifesto, but servant leadership doesn’t work in every scenario. This essay will explore the origins of servant leadership, its ties with Agile and when to apply a servant leadership approach.

Jon Quigley anchors the cast with the second installment in a three-part arc on requirements in his ¬†‚ÄúThe Alpha-Omega of Product Development‚ÄĚ column. This week Jon discusses managing requirements.

Gene Hughson brings his Form Follows Function blog to the Software Process and Measurement Cast. ¬†In this visit, Gene discusses his recent blog entry titled, ‚ÄúOrganizations as Systems ‚Äď ‚ÄúUneasy Lies the Head that Wears the Crown‚ÄĚ. ¬†Gene points out that software development organizations live in a complex world where single factor explanations are dangerous.

Kim Pries, the Software Sensi, brings a great discussion of the concept of craftsmanship in software development to the Cast.  Craftsmanship and quality are related, but craftsmanship is a more intimate and personal attribute.

 

Re-Read Saturday News

This week we complete our re-read of Kent Beck‚Äôs XP Explained, Second Edition with final thoughts on a book that has shaped a generation’s thinking on Agile, while at the same time being eminently practical.

Next week we begin our read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  This will be a new book for me, therefore an initial read, not a re-read!  Click the link (The Five Dysfunctions of a Team), buy a copy, and next week we will begin to read the book together.

Next SPaMCAST

The Software Process and Measurement Cast 412, if you thought we were done with XP Explained, Second Edition, you would be wrong.  One of the SPaMCAST’s long term listeners, Steven Adams and I recently sat down to discuss our thoughts on the book.  It was a great conversation that we look forward to sharing with you!

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 411 - Servant Leadership, Systems Thinking, Craftsmanship, Requirements

Software Process and Measurement Cast - Mon, 09/19/2016 - 02:19

The Software Process and Measurement Cast 411 includes four columns!  The first is our thoughts on servant leadership. A servant leader facilitates collaboration not only by creating a learning environment but also by helping the team to establish a vision and goals.  Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. Many of the links between servant leadership and Agile are because servant leadership enables several of the principles in the Agile Manifesto, but servant leadership doesn’t work in every scenario. This essay will explore the origins of servant leadership, its ties with Agile and when to apply a servant leadership approach.

Jon Quigley anchors the cast with the second installment in a three-part arc on requirements in his ¬†‚ÄúThe Alpha-Omega of Product Development‚ÄĚ column. This week Jon discusses managing requirements.

Gene Hughson brings his Form Follows Function blog to the Software Process and Measurement Cast. ¬†In this visit, Gene discusses his recent blog entry titled, ‚ÄúOrganizations as Systems ‚Äď ‚ÄúUneasy Lies the Head that Wears the Crown‚ÄĚ. ¬†Gene points out that software development organizations live in a complex world where single factor explanations are dangerous.

Kim Pries, the Software Sensi, brings a great discussion of the concept of craftsmanship in software development to the Cast.  Craftsmanship and quality are related, but craftsmanship is a more intimate and personal attribute.

Re-Read Saturday News

This week we complete our re-read of Kent Beck’s XP Explained, Second Edition with final thoughts on a book that has shaped a generation's thinking on Agile, while at the same time being eminently practical.

Next week we begin our read of The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  This will be a new book for me, therefore an initial read, not a re-read!  Click the link (The Five Dysfunctions of a Team), buy a copy, and next week we will begin to read the book together.

 Next SPaMCAST

The Software Process and Measurement Cast 412, if you thought we were done with XP Explained, Second Edition, you would be wrong.  One of the SPaMCAST’s long term listeners, Steven Adams and I recently sat down to discuss our thoughts on the book.  It was a great conversation that we look forward to sharing with you!

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

Extreme Programming Explained, Second Edition: Re-Read Week 14 (Final Thoughts)

XP Explained Cover

Today we conclude our re-read of Extreme Programing Explained, Second Edition (2005) with a few final through and five of my major conclusions from reading this book a second time.  Next week we begin our read of The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one, please use the link to support the blog and podcast).  

XP was my first real exposure to the guts of Agile. ¬†XP Explained (the First Edition) was a formative part of my Agile education. I didn’t expect the re-read to have as much of an impact; however, reflecting on the on what I have gleaned from reading the Second Edition, I was wrong. ¬†Five of the more significant reflections of our re-read are listed below.

  1.       XP is an expression of a strong set of values and principles.  Values and principles provide a rationale for the practices that are the nuts and bolts of a methodology. Organizations first adopt the values and principles of XP and then tailor practices based on their needs and context.  As long as they meet the values and principles of XP, organizations are extreme.  
  2.       The primary and secondary practices of XP fit together like a jigsaw puzzle.  Each piece reinforces and supports the other.  While they may be adopted incrementally, until all practices are in place other non-extreme practices will be needed.  
  3.       The one person you are really in charge of is yourself.  When adopting XP, begin by changing how you work and then use the evidence of value to persuade others to change. This idea is useful when changing any organization. You need to be able to walk the walk before you ask others to follow you.  I do not remember this theme from the first time I read the book; however, over the last fourteen weeks, this idea has become more important to how I think about how I approach any change Рorganizational or more personal.
  4. ¬†¬†¬†¬†¬†¬†There is no one way to approach XP. Beck shows his experience with being out in front of change (based on his history of thought leadership in Smalltalk and Object Orient Programming) by recognizing that concept purity is rarely a winning strategy when trying to have a broad impact. ¬†The goal of any change is what is of primary importance, rather than following the exact perfect path described in the “book”.
  5.       One final note is that the Second Edition of XP Explained is fundamentally a different book than XP Explained, First Edition.  This was not so much a re-read as a new read for me.  The Second Edition added a level of depth that can only come through feedback based on the continued evolution of XP use.  My reaction to how different the two editions were might not be same as not judging a book by its cover, but I now realize that it is not always a good idea to judge a book by its edition number.  

Next week on the Software Process and Measurement Cast, Steven Adams and I will discuss his impressions from re-read of XP Explained, Second Edition.  I believe you will enjoy the conversation.

Bottom Line:  XP Explained, Second Edition still provides readers with an extremely important message to those interested in improving both the value of the software they deliver and from the work they perform.

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 ‚Äď 3

Week 3, Chapters 4 ‚Äď 5

Week 4, Chapters 6 ‚Äď 7 ¬†

Week 5, Chapters 8 ‚Äď 9

Week 6, Chapters 10 ‚Äď 11

Week 7, Chapters 12 ‚Äď 13

Week 8, Chapters 14 ‚Äď 15

Week 9, Chapters 16 ‚Äď 17

Week 10, Chapters 18 ‚Äď 19

Week 11, Chapters 20 ‚Äď 21

Week 12, Chapters 22 ‚Äď 23

Week 13, Chapters 24 ‚Äď 25

Remember we are going to read The Five Dysfunctions of a Team by Patrick Lencioni next. Click the link (The Five Dysfunctions of a Team), buy a copy and begin reading!

 


Categories: Process Management

Incorporating the Idea of External Risk into Agile Efforts

A spider web has several external risks.

A spider web has several external risks.



Making sure external risks are addressed in an Agile effort, or any effort for that matter begins with making sure that at least a basic risk management approach is in place. If a basic risk management approach is in place we can integrate the concept of external risks.  Everyone involved should understand the basics of the risk management process being leveraged on the effort.  All risk management processes need to identify who is responsible and how the process fits into the value delivery flow.  Specifically, incorporating the idea of external risks into the process is typically more urgent as the scale and duration of the effort increases if for no other reason than longer efforts are exposed to the trials and tribulations of the outside world longer than small efforts.  The size of the effort affects two main variables used to scale  Agile risk management.  The larger the effort the greater the need for the people involved with the effort to define who is responsible for risk management and how much process is needed to keep things organized.   The size of the effort, while a continuum, will be represented by small efforts (one team and a few iterations or sprints) and large efforts (over 75 participants with at least 6 iterations or sprints) for illustration.  

Responsibility. A responsibility defines who will ensure that risks are managed in an effort.

  • In small efforts using Scrum or Extreme Programming (XP), the risk is collaboratively managed by the whole team. ¬†Scrum and XP build team-level risk management directly into how work is done; allowing the responsibility for risks to be a bit more nebulous than in large or riskier projects. ¬†At a team level, the process of self-organization is often enough to facilitate the process. When self-organization is not enough to generate a collective responsibility for risk management the introspective feedback generated in iteration or sprint retrospectives should provide the impetus to get things back on track. The Scrum master should help to identify and focus the team collectively managing risk. Collective risk management can be effective for identifying external risk by leveraging the diversity of the team when coupled with a process that prompts the team to look outward.
  • Larger efforts require more formality in identifying who is responsible for championing the risk management process. ¬†For example, in SAFe, the release train¬†engineer (RTE) is responsible for making sure the program increment planning process (which includes the identification and ROAM‚Äôing of risks) occurs and is completed. ¬†The release train engineer also acts as the focal point to ensure that the backlog, including ROAM‚Äôed risks, is groomed and prioritized. ¬†¬†The size/scale of the effort requires someone to champion risk management or it could easily be uncoordinated. The RTE acts as a connector between all of the teams through the Scrum-of-Scrums (SoS). ¬†Through the SoS and a big picture view of the effort, the RTE can be instrumental for identifying and managing¬†external risks.

Process.  The process defines how risk management practices are built into the flow of how value is delivered.  

  • Small Agile efforts build risk management into the process (lean process) easily by adopting Scrum or XP. ¬†However, most small efforts tend to ignore external risks. Therefore, the process needs to build in some form of awareness building for¬†external risks. ¬†For example, small efforts often only need a checklist of common external risks (common being relative to the type of work being done) that can be referenced as a memory jogger when building and grooming their backlog and/or during iteration planning. ¬†For small efforts, the time horizon is short enough that aggressive risk management approaches are not needed. ¬†The goal in small efforts is to ensure that a conversation about both internal and external risks are happening on a consistent basis.
  • Large efforts require a more explicit process to identify and manage external risks. ¬†One very powerful method is a future telling session (we will examine this technique in detail in the near future) in which participants develop a vision of the overall effort and the journey toward that effort. ¬†During the session, the facilitator of the session challenges the storytellers to identify what might endanger or derail their effort (risks). ¬†The risks then can be ROAM‚Äôed (if using SAFe). ¬†Tools and techniques to shift the focus from just internal risks to both internal and external risks are needed because the potential for outside forces to impact the effort are significantly higher.

In small efforts using Scrum or XP a risk management is built in.  Injecting the idea of external risks requires a less overt hand.  Techniques like checklists can be used as a memory prompt. Many (not all) of these efforts are over and done before anything significant can get in the way.  Larger efforts are not that lucky.  Someone needs to champion risk management and external risks need to be explicitly discussed and the horizon needs to be constantly scanned!  

Current Risk Thread:
External and Internal Risks
Incorporating the Idea of External Risk into Agile Efforts (Current)
Risk Tolerance
Future Telling as a Risk Management Tool


Categories: Process Management

Running Robot Framework's Remote Server as Java agent

Xebia Blog - Wed, 09/14/2016 - 07:48
Robot Framework is a great automated testing tool that uses a keyword-driven approach. When you want to run Robot Framework tests within the context of a running system-under-test you can load Robot Framework's RemoteServer as a java agent. This is not something that comes out of the box so we will explain how to do

Internal and External Risks

Evacuation Plan

Having a plan mitigates risk.

Risk management is crucial to the success of all software development, enhancement and maintenance projects.  Risk management at its basest level is avoiding problems that can be avoided and recognizing those that can’t be avoided. In order to recognize and avoid problems, every project must take the steps that need to be taken to consciously look outward and forward. The act of risk management requires both introspection and extrospection.  Extrospection, a rarely used word in the everyday conversation, is even rarer in many Agile approaches. One important way to assess risk is to consider whether there are internal or external risks.

Internal risks are from within the organization and arise during normal operation.  Internal risks are often forecastable, and therefore can be avoided or mitigated.  Internal risks are typically generated by one (or some combination) of human, technical or physical factors.  Many Agile practices naturally address internal risk. Practices like short planning cycles, retrospectives, flexible backlogs, and small teams are geared to addressing the delivering short-term value by addressing the risks that that team perceives to be controllable.

External risks come from outside the organization or project and outside of the team‚Äôs control. ¬†External risks tend to only be forecastable in retrospect, and therefore efforts need to be focused on recognition and reaction. ¬†Many external risks stem from legislative, environmental and political changes. The impact of a major earthquake on an organization’s supply is an external risk. ¬†

Recently, Steven Adams published an article on his blog titled, Seven Risks in Software Development.  In his article, Steven the following seven risks:

  1.    Risk of delivering little or no value to the customer or organization.
  2.    Risk of missing the delivery schedule because of poor predictions.
  3.    Risk of unplanned work disrupting the work process and schedule.
  4.    Risk of poor quality in the delivery.
  5.    Risk of work item becoming an outlier … way off!
  6.    Risk of the team not working well together.
  7.    Risk of end-users not using or liking the product.

Steven’s list is a powerful tool for facilitating a discussion of risks that are controllable at a team level.  Steven’s are all internal risks. A lean approach practiced by many teams to identify and manage internal risks (mostly) includes:

  1. Identify knowable risks.
  2. Build mitigation for common risks into the definition of done.
  3. Generate stories for less common risks and add them to the project backlog.
  4. Review risks when grooming stories.
  5. Carve out time during planning to identify emerging risks.

Agile techniques at a team level are designed to capture and manage internal risks. No one believes in not managing risk because not managing risk puts the value a team delivers at risk or at the very least puts their weekend when a risk becomes an issue and had to be dealt with.  Agile techniques tend to give teams a short-term inside the boundary perspective that is very delivery.  External risks often lurk outside the short-term focus, which means our techniques need to be tailored to address both internal and external risks.  

Next: Incorporating External Risks into an Agile Risk Approach


Categories: Process Management

Software Development Linkopedia September 2016

From the Editor of Methods & Tools - Tue, 09/13/2016 - 15:11
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 being a better developer, software architecture, tech leadership, shrinking the product backlog, customer journey maps, using sprint data, distributed testing, domain driven design, continuous delivery and testing microservices. Blog: Finding […]

The 3 Pillars of Successful Products or Why Project Ara was Cancelled

Xebia Blog - Mon, 09/12/2016 - 14:37
Google managed to surprise both the market as well as the fans by cancelling the Project Ara modular phone. But from a Product Owner point of view it was no surprise. Ara phones lack a fundamental pilar that makes a product successful. Context: Ara what? In 2013 Google announced to build the Ara phone. A

SPaMCAST 410 ‚Äď Jessica Long, Storytelling in Agile

SPaMCAST Logo

http://www.spamcast.net

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

In Software Process and Measurement Cast 410, we feature our interview with Jessica Long.  Jessica and I discussed storytelling. I find that storytelling is a useful tool to help individuals, teams, and organizations.  Projects can use stories to generate user stories and as a tool in retrospectives.  Stories are also a tool in generating a vision of the future in organizational transformations.  Those are just a few of the multitude of uses for storytelling in changing how value is delivered!

Jessica and I will both be presenting on using stories at the Agile Philly, Agile Tour 2016 on October 10th.  If you are in the Philadelphia area please register and attend!

Jessica’s bio:
Jess Long is an Agile Coach, a writer, a speaker and a mother with a passion for driving meaningful stories across multiple iterations in all facets of life. Transforming Corporate America and living to tell about it is no small feat. She keeps some level of sanity by finding humor in otherwise absurd situations.

Twitter: https://twitter.com/scrumandginger
Blog: https://scrumandginger.com/
LinkedIn: https://www.linkedin.com/in/jessica-long-pmi-acp-csp-cspo-87626614

Re-Read Saturday News

This week we reach the penultimate week in our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 24 and 25. Chapter 24 discusses the value and power in communities. Chapter 25 is Beck’s conclusion and reflection on the book: XP is about people!

Next week we’ll wrap this re-read up and get ready to read The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass). ¬†This will be a new book for me, therefore an initial read, not a re-read! ¬†Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks we will begin to read the book together.

Next SPaMCAST

The Software Process and Measurement Cast 411 will be a big show featuring our thoughts on servant leadership. In SPaMCAST 411 we will have a visit from the Kim Pries, the Software Sensei. We will have more from Steve Tendon on the 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).  And anchoring the cast will be Gene Hughson with an entry from his Form Follows Function Blog.  

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 410 - Jessica Long, Storytelling in Agile

Software Process and Measurement Cast - Sun, 09/11/2016 - 22:00

In Software Process and Measurement Cast 410, we feature our interview with Jessica Long.  Jessica and I discussed storytelling. I find that storytelling is a useful tool to help individuals, teams, and organizations.  Projects can use stories to generate user stories and as a tool in retrospectives.  Stories are also a tool in generating a vision of the future in organizational transformations.  Those are just a few of the multitude of uses for storytelling in changing how value is delivered!

Jessica and I will both be presenting on using stories at the Agile Philly, Agile Tour 2016 on October 10th.  If you are in the Philadelphia area please register and attend!

Jessica’s bio:
Jess Long is an Agile Coach, a writer, a speaker and a mother with a passion for driving meaningful stories across multiple iterations in all facets of life. Transforming Corporate America and living to tell about it is no small feat. She keeps some level of sanity by finding humor in otherwise absurd situations.

Twitter: https://twitter.com/scrumandginger
Blog: https://scrumandginger.com/
LinkedIn: https://www.linkedin.com/in/jessica-long-pmi-acp-csp-cspo-87626614

Re-Read Saturday News

This week we reach the penultimate week in our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 24 and 25. Chapter 24 discusses the value and power in communities. Chapter 25 is Beck’s conclusion and reflection on the book: XP is about people!

Next week we'll wrap this re-read up and get ready to to read The Five Dysfunctions of a Team by Patrick Lencioni (published by Jossey-Bass).  This will be a new book for me, therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks we will begin to read the book together.

Next SPaMCAST

The Software Process and Measurement Cast 411 will be a big show featuring our thoughts on servant leadership. In SPaMCAST 411 we will have a visit from the Kim Pries, the Software Sensei. We will have more from Steve Tendon on the 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).  And anchoring the cast will be Gene Hughson with an entry from his Form Follows Function Blog.  

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

Extreme Programming Explained, Second Edition: Re-Read Week 13 (Chapters 24 ‚Äď 25)

XP Explained Cover

We conclude the main portion of the re-read of Extreme Programing Explained, Second Edition (2005) with¬†Chapters 24¬†and 25. Next week will present¬†a few final thoughts before we shift gears and start reading The Five Dysfunctions of a Team (if you do not own a copy, it is time to order one ‚Äď use the link to support the blog and podcast). ¬†This week in XP Explained; Chapter 24 discusses the value of community as an asset to support the adoption and use of XP. Chapter 25 is Beck and Andres‚Äôs concluding notes on XP Explained.

Chapter 24: Community and XP

A supportive community is a huge asset for XP practitioners (this true for any profession or movement). Communities provide a mechanism for people interested in XP to connect, encourage each other and share ideas and experiences. The power of a community is generated by the interchange between people in a way that helps both the individuals and the group to achieve their goals. Finding and getting involved in a community can be as easy as getting involved or forming a community of practice within your organization or reaching out to one of the XP online communities.

Beck counsels that the role of a community member should be weighted towards the act of listening rather than talking. ¬†Listening is the combination of hearing and interpreting. ¬†Listening helps new members to learn how a community works before jumping in with both feet. ¬†Listening also helps members to understand who will be helpful and who just talks to hear their own voice. Listening is just as powerful tool for community members as it is for those involved in coaching and facilitating learning. If you embrace the ‘listen first, talk second’ rule then communities have value to any individual if he or she participates.

One final note, communities provide a mechanism for enforcing accountability between members.  Promises to people that you have close ties with are more difficult to break.  Mastermind groups are a common example of a community that builds in holding members responsible.

Chapter 25: Conclusion

Beck states that he created/documented XP to make life better for developers.  One main takeaway from the re-read is that there can be no improvement without first improving yourself (we will explore final thoughts more next week).  

Beck concludes that XP is more of statement about creating a balance of true values and integrity, and less about the practices and techniques that move you down the path of practicing XP. The books end with the quote:

“XP is a way of thinking about and acting on your ideals.‚ÄĚ

 

Previous installments of Extreme Programing Explained, Second Edition (2005) on Re-read Saturday:

Extreme Programming Explained: Embrace Change Second Edition Week 1, Preface and Chapter 1

Week 2, Chapters 2 ‚Äď 3

Week 3, Chapters 4 ‚Äď 5

Week 4, Chapters 6 ‚Äď 7 ¬†

Week 5, Chapters 8 ‚Äď 9

Week 6, Chapters 10 ‚Äď 11

Week 7, Chapters 12 ‚Äď 13

Week 8, Chapters 14 ‚Äď 15

Week 9, Chapters 16 ‚Äď 17

Week 10, Chapters 18 ‚Äď 19

Week 11, Chapters 20 ‚Äď 21

Week 12, Chapters 22 ‚Äď 23

Remember we are going to read The Five Dysfunctions of a Team by Patrick Lencioni next.  This will be a new book for me; therefore an initial read, not a re-read!  Steven Adams suggested the book and it has been on my list for a few years. Click the link (The Five Dysfunctions of a Team), buy a copy, and in a few weeks, we will begin to read the book together.


Categories: Process Management

Servant Leadership: Not All Puppies and Kittens

Picture of standard poodle

Leadership Is Not All Puppies!

Servant leadership is a powerful tool to unlock the ability of teams or groups to deliver value. As we have found, servant leadership unlocks several of the principles that underlie the Agile Manifesto.  Despite the linkage to Agile, applying servant leadership is not all puppies and kittens. There is no one perfect style of management or leadership, and servant leadership is only one of those styles. Different types of people and different contexts mean that servant leadership does not fit every organization’s need.  There are several criticisms of servant leadership that can illuminate who shouldn’t use servant management and in which contexts to avoid the style.  Below are some common criticisms of the style, along with my comments on those critiques:

Servant leadership can disrupt the chain of command within the organization. In business, managers are charged with serving owners first and customers second (society and employees are tertiary or worse ).  Managers that are not serving the owners and customers will lose their jobs. While leaders should engage, motivate, and support employees, this behavior does not rise to being their servant.

A servant leader who acts at odds with the direction of the organization or in conflict with the management structure undermines the authority of management and may negatively impact the value the organization delivers to its customers. ¬†In the end, the manager’s primary duty is not to satisfy employees; rather it is to satisfy the needs of the organization.

Servant leadership can lead to a mismatch of goals or a conflict of vision.  (Note: this criticism is related to the idea of a disruption in the chain of command.)  In order to be effective and efficient, activity within an organization needs to reflect the ultimate goal of the organization.  An organization is the reflection of both individual goals and organizational goals. Giving primary importance to the needs and aspirations of individuals may generate conflict with the overarching goals of the organization.  One of the major conflicts not resolved with servant leadership is related to individual-organization fit; in the end, the needs of the organization need to be prioritized.

Servant leaders draw followers to themselves based on the concept or idea they champion.  Many classic examples of servant leaders can be drawn from religious history.  Jesus was a servant leader.  If a servant leader exists at the head of an organization then there will be no conflict or mismatch of goals. However, if a servant leader arises that is in conflict with the organization’s goals, that leader should be co-opted or removed.

Developing an environment of servant leadership within an organization often takes time. I ask everyone that I interview on my podcast what they would change if they had a magic wand. To a person, each wishes that a magic wand existed. Servant leadership, as an organizational philosophy generally requires undoing decades or centuries of organizational culture, and therefore, takes a lot of time to implement. Organizational change needs to start at the top and then diffuse throughout the organization.

As Greger Wikstrand in SPaMCAST 370 stated, culture change is a long and arduous path because the change must overcome how people and organizations have developed and evolved over a long period of time.  Just because a change is hard or takes a long time does not mean it shouldn’t be approached Рjust don’t get frustrated when you can’t wave a magic wand.

Servant leadership is not appropriate for all organizations.  Some organizations require high levels of structure and organization to survive. Military organizations tend to require structure and organization that is able to transmit orders and information from the top to the trooper in the field.  Servant leadership’s focus on the individual conflicts with the need for structure.

One size does not fit all organizations. There are scenarios in which servant leadership may not align with the basic business structure. However, the scenarios where servant leadership can’t be used are relatively rare in most corporate environments.

Servant leadership is not a good style for companies that need to be turned around very fast. Servant leaders listen, consult and serve their followers, which slows the decision-making process down. An individual making a decision is often significantly faster than group decision-making (whether better or worse will be the subject of another essay). When a crisis occurs leaders must, at times, suspend consultative and negotiative processes and issue specific orders. Examples may include significant market shocks or situations where downsizing is necessary.

Servant leadership can generate a parent-child relationship which can generate a demotivated and disengaged workforce. Servant leaders can fall into a nurturing parent to child relationship which may be viewed as manipulative.  Additionally, if employees feel that the manager overlooks or corrects errors, employee accountability falls, resulting in poor performance.

Parent-Child relationships in the workplace, whether critical or nurturing, rarely generate high performance over the long run.  A better model is an adult-to-adult relationship which is more balanced.  All leaders should be educated so they can foster a adult-adult relationship.

Servant leadership is one leadership style.  It makes sense in some scenarios, typically those in which values, commitment, and engagement of everyone are requirements.  Software development and maintenance typically fit this situation. However, it is not the only appropriate style, and the culture and context of the organization influence the prevalent style in the organization.

Current Management Thread


Categories: Process Management