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&page=2' 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.

Re-Read Saturday: Extreme Programming Explained: Embrace Change Second Edition Week 1

XP Explained

This week we begin the re-read of Kent Beck’s Extreme Programing Explained, Second Edition (2005). I remember the first time I read Extreme Programing Explained (First Edition), it was flying back and forth between Cleveland and Los Angeles.  It took two flights and then a lot of time to consider. XP Explained provides not only an explanation of Extreme Program, but also a philosophy for XP and Agile.  The 189 pages are organized into two sections and 25 relatively short chapters and are crammed with information and ideas. I used a whole highlighter on the book during my first read (the pages are now florescent yellow.  The book was written by Kent Beck, one of my heroes even before Agile.  The Second Edition now has Cynthia Andres joining Mr. Beck.

Extreme Programming Explained: Embrace Change, Second Edition begins with two forwards and a preface.  I freely admit that my natural tendency is to plow through reading forewords and prefaces.  In this case, it was interesting to compare the difference between the forewords from the first and second editions, both written by Erich Gamma.   The main point is that the second edition is a full rewrite.  Gamma says that Beck applied the XP paradigm of “stay aware, adapt, change.”

Extreme Programming reflects a philosophy of adapting and changing based on the environment that the developer is operating in.  In the Preface, Beck rephrased the message that he used to open the first edition.  The message Beck opens the book with is that:

  1. No matter the circumstances you can always improve.
  2. You can always start improving with yourself.
  3. You can always start improving today. 

The message of XP Explained is one of hope, discipline, deliberate practice, and improvement.

Chapter 1 – What is XP?

Chapter 1 is the context from which the rest of the book builds.  During my original read, I remember breezing through this chapter to get to the “beef.” However, over the years, I have returned to this chapter to reground my understanding of Beck’s vision.  In the second edition, Beck builds on his initial definition: “XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements.” In the second edition, Beck provides a list of attributes to augment the original definition. 

  • XP is lightweight
  • XP is a methodology
  • XP can work with teams of any size
  • XP adapts to vague or rapidly changing requirements.

The obvious difference is the recognition that XP can be used with teams of any size. As interesting is the implicit recognition in the last attribute that XP is can be applied even when requirements are well understood.  The newer definition recognizes that XP is both a style and philosophy of software development that can be applied to any scenario. The overarching philosophy provides a container to hold a set of complementary principles that support a set of techniques.  

Beck suggests philosophically that in XP you don’t prepare for failure, rather you play all out to win.  XP is a philosophy and methodology that is based on a mentality of sufficiency. Rather than focusing on the constraints, a project lives within, XP focuses on delivering software and continuous improving regardless of constraints. All efforts and projects have constraints, spending too much time worrying about constraints is a distraction from the goal of the work.  

XP addresses many of the risks in the software development process, such as:

  1. Schedule slippage by leveraging short release cycles.
  2. Avoidance of not delivering anything due to project cancellation by the use of small releases that make business sense.  
  3. Chances that the system goes “sour” by leveraging continuous automated testing.
  4. High defect rates by having both programmers and customers write tests.
  5. Business needs are misunderstood by including business-oriented people as first class members of the team.
  6. Business needs change before delivery is addressed through the shortened release cycle.
  7. False feature rich releases are avoided by planning that includes the business and an insistence on working on the highest priority items first.
  8. Staff turnover is reduced by allowing programmers to take the responsibility of estimating their own work and then to perform to those estimates. The frustration of being asked (or told) to do the impossible is reduced improving the working environment.

When I was flying to Los Angeles reading Extreme Programming Explained the first time, I was a little bit too impatient and breezed through Chapter 1.  However, it is important because it provides the contextual underpinning for XP.  Understanding the definition and philosophy of XP  provides a foundation for beginning to explore XP in more depth next week.

Programming Notes:  Next week we will begin Section One: Exploring XP.  Currently, I am planning to re-read two chapters per week even though they are relatively short. Please get a copy of Extreme Programing  Explained, Second Edition (this link will support the blog and podcast), read along and comment!   

 


Categories: Process Management

Filtering objects to Optionals

Xebia Blog - Fri, 06/17/2016 - 16:36
A while ago I stumbled upon a Blog post by Natascha the Robot about Configuring a Constant Using Shorthand Argument Names in Swift. Which by itself is a great post, but I was most inspired by the Then library mentioned at the end of her post. Seeing how such a small amount of code could change the way we configure

Staff Liquidity Is All About The People

Baseball player swinging at a pitch

Sometimes having a DH makes sense!

We began discussing the concept of staff liquidity during the re-read of Commitment. Liquidity is a financial concept describing the ease of converting assets into cash. Stocks traded on a major exchange are liquid while stocks in private company traded between friends are far less liquid. Translating the financial concept to software development and maintenance teams, liquidity is a measure of the ease of turning effort into functionality. Staff liquidity is valuable three significant reasons:

Staff liquidity reduces risk. In Waltzing with Bears, Tom DeMarco, and Tim Lister defined five categories of risk.

  • Intrinsic Schedule Flaws
  • Specification Breakdowns
  • Scope Creep
  • Personnel Loss
  • Productivity Variance

Staff liquidity helps the team move people to bottlenecks caused by capacity problems, which reduces three of those risks (schedule flaws, personnel loss, and productivity variance).  For example, a team with a testing capacity problem will tend to fail to deliver or end up delivering partially tested code. When a bottleneck is identified, resources with some testing experience from within the team can be used to increase testing capacity. This is why everyone on a team can’t be purely a specialist (I-shaped person).

Staff liquidity increases productivity. The ability to get work done so that the business or a customer can provide feedback has been shown to  increase both quality and productivity over time. Don Reinertsen in The Principles of Product Development Flow (who was interviewed on SPaMCAST 92) stated at the outset of Chapter 8, “A little rudder early is better than a lot of rudder late.” The faster a team gets feedback, the smaller the impact of any potential change or defect. Staff liquidity prevents teams from getting stuck, delaying the completion of work and getting to a point where feedback can be gathered in production.

Staffing liquidity increases trust. Trust is a multifaceted term; however, one ingredient in trust is doing what you said you would and being able to prove it. Being able to adjust capacity in order to rally to problems or to remove bottlenecks increases a team’s ability to deliver. Additionally, the reduction of systemic risk lowers that amount of tension present in any work environment which increases trust between customers, management, and the team.

As noted in our read of Commitment, staff liquidity is good for everyone. But unless you have the luxury of having constructed a team with T, M and Pi-shaped people, how can you assess staff liquidity? Assessing the capabilities of the team can be as simple as canvassing the team during a retrospective. Ask team members which roles they could handle in a pinch and then ask the remaining team members to provide feedback. This approach requires a significant amount of trust among team members or the feedback will be perfunctory. A second easy mechanism is to actually watch what happens when a team runs into a bottleneck. Just waiting to see what will happen is a bit scary. This is the approach many inexperienced scrum masters and coaches use under the mistaken assumption that urgency will spur people to move outside their comfort zone. Combining the two techniques is actually far more useful. Asking about the breadth and getting team members to public commit to having more than a single specialty plants a seed which urgency can be used to push people into action (a type of anchor bias). Once the team understands each other’s capabilities, have team members with the most options pull their work last and keep a buffer of capacity free to help others.

Staff liquidity is not rocket science; however, it does require that teams and team members spend time understanding their capabilities. Time for introspection on capabilities and capacity must happen before starting an Agile effort and should be revisited during any effort. Real life will provide feedback and experience helps people to grow and change increasing options and staff liquidity.


Categories: Process Management

Productive Agile Teams:  I, T, E and M Shaped People

Pi(e)-shaped person?

Pi(e)-shaped person?

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

  • Dash-shaped people are generalists.  They have a breadth of experience, but little depth.  My mother used to describe these type of people as “a mile wide and inch deep.” In baseball, a generalist would be a utility player; highly valued because they fill in many positions, but not a starter.
  • I-shaped people are specialists. Specialists have a single specialty or focus.  My mother often called this type of person “an inch wide and mile deep.”  Considering the concept of staff liquidity from Commitment, an I-shaped person is the most limited of the letters.  For example, a person that is DBA that specializes only in NoSQL databases will be less valuable if the team needs help with business analysis.
  • T-shaped people represent the classic agile team member.  T-shape people have a specialty, and in addition, they have a wider breadth of experience with other skills.  T-shape people have a focus but can fill in when bottlenecks are recognized.    
  • M-shaped people have multiple specialties.  From the point of view of flexibility, a person with more than one specialty can be applied more flexibly than someone with single specialty. Each additional specialty shifts our mental picture from a letter to a comb.
  • Pi-shaped people combine breadth with multiple specialties (combining T and M-shaped people).
  • E-shaped people are people that combine experience, expertise, exploration, and execution. However, a lot of emphases is placed on the last E: execution. E-shaped people translate ideas into reality.  I would suggest that Leonardo da Vinci was an E-shaped person.

Understanding where the individuals on a team fall in the alphabet soup is a powerful input for applying the concept of staff liquidity.  A team applying staff liquidity will always allocate the people with the least options (the fewest things they can do or most specialized) to work first.  These are generally the I-shaped people. Those with more options fill in the gaps in capability after the first wave of allocation and are available to react when things happen. The allocation process provides the team with the most flexibility. Even in high-performing teams, not everyone is an M, T, Pi, or E-Shaped person. In my experience, teams are a mix of generalists, specialists, and multi-talented superstars. Everyone on the team needs to recognize the mixture of talents and capabilities in order to manage the work and remove bottlenecks as the development process moves forward.


Categories: Process Management

Productive Agile Teams:  I, T, E and M Shaped People

Pi(e)-shaped person?

Pi(e)-shaped person?

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

  • Dash-shaped people are generalists.  They have a breadth of experience, but little depth.  My mother used to describe these type of people as “a mile wide and inch deep.” In baseball, a generalist would be a utility player; highly valued because they fill in many positions, but not a starter.
  • I-shaped people are specialists. Specialists have a single specialty or focus.  My mother often called this type of person “an inch wide and mile deep.”  Considering the concept of staff liquidity from Commitment, an I-shaped person is the most limited of the letters.  For example, a person that is DBA that specializes only in NoSQL databases will be less valuable if the team needs help with business analysis.
  • T-shaped people represent the classic agile team member.  T-shape people have a specialty, and in addition, they have a wider breadth of experience with other skills.  T-shape people have a focus but can fill in when bottlenecks are recognized.    
  • M-shaped people have multiple specialties.  From the point of view of flexibility, a person with more than one specialty can be applied more flexibly than someone with single specialty. Each additional specialty shifts our mental picture from a letter to a comb.
  • Pi-shaped people combine breadth with multiple specialties (combining T and M-shaped people).
  • E-shaped people are people that combine experience, expertise, exploration, and execution. However, a lot of emphases is placed on the last E: execution. E-shaped people translate ideas into reality.  I would suggest that Leonardo da Vinci was an E-shaped person.

Understanding where the individuals on a team fall in the alphabet soup is a powerful input for applying the concept of staff liquidity.  A team applying staff liquidity will always allocate the people with the least options (the fewest things they can do or most specialized) to work first.  These are generally the I-shaped people. Those with more options fill in the gaps in capability after the first wave of allocation and are available to react when things happen. The allocation process provides the team with the most flexibility. Even in high-performing teams, not everyone is an M, T, Pi, or E-Shaped person. In my experience, teams are a mix of generalists, specialists, and multi-talented superstars. Everyone on the team needs to recognize the mixture of talents and capabilities in order to manage the work and remove bottlenecks as the development process moves forward.


Categories: Process Management

Software Development Linkopedia June 2016

From the Editor of Methods & Tools - Mon, 06/13/2016 - 14:35
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 software bugs, rewriting code, project routines, improving retrospectives, acceptance testing problems, #noprojects, DevOps and Agile (or not) software architecture. Blog: Software has bugs. This is normal. Blog: When to Rewrite […]

SPaMCAST 398 – Kevin Kruse, 15 Secrets Successful People Know About Time Management

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 398 features our interview with bestselling author Kevin Kruse.  We discussed his new book, 15 Secrets Successful People Know About Time Management.  The ideas Kevin presents on managing time and more accurately managing focus are extremely useful and in some cases just a bit controversial. Surprising findings include:

  •         Most high achievers do NOT use to-do lists.
  •         The Harvard experiment that showed how 3 questions saved 8 hours a week.
  •         Procrastination is cured by “time traveling” to defeat your future self.
  •         Most high achievers practice a consistent morning ritual.
  •         How high achievers manage their email

If you haven’t bought a copy of 15 Secrets Successful People Know About Time Management, I would recommend that you start your personal program to improve your productivity by using the link in the show notes and buying a copy!

Kevin Kruse is an Inc 500 serial entrepreneur, New York Times bestselling author, and Forbes columnist. Kruse has been named a Top 100 Business Thought Leader by Trust Across America. Over the last 20 years, Kevin has started or co-founded several multi-million dollar companies which have won awards for both fast growth (Inc 500) as well as employee engagement (#4 Best Place to Work in PA). As a keynote speaker and performance coach, Kevin has worked with Fortune 500 CEOs, startup founders, US Marine Corps officers and non-profit leaders.

Contact Information:

twitter.com/Kruse

facebook.com/KruseAuthor

instagram.com/kevin__kruse

www.15TimeSecrets.com

www.KevinKruse.com

info@kevinkruse.com

Re-Read Saturday News

We concluded the read of Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary. This week’s installment will addresses the epilogue (everybody lives happily ever after) and summarizes some of the key concepts that I have already found useful.  Next week we will begin re-reading  Kent Beck’s xP Explained, Second Edition. I originally read the first edition several years ago on flights traveling between clients.  The book provides an important explanation for xP and the even today confronts us with the realization that Agile is more than just Scrum. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next SPaMCAST

The next Software Process and Measurement Cast will feature our essay on using storytelling to jumpstart Agile efforts. Telling stories is a natural human activity from time immemorial that can be used to create a succinct and informative story to describe a business need or the future of an organization.  The essay provides an approach for using storytelling and suggests that sometimes the journey an organization must take to achieve a goal needs facilitation.

We will also have columns from the Software Sensi, Kim Pries and an entry from Gene Hughson’s 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 398 – Kevin Kruse, 15 Secrets Successful People Know About Time Management

Software Process and Measurement Cast - Sun, 06/12/2016 - 22:00

The Software Process and Measurement Cast 398 features our interview with bestselling author Kevin Kruse.  We discussed his new book, 15 Secrets Successful People Know About Time Management.  The ideas Kevin presents on managing time and more accurately managing focus are extremely useful and in some cases just a bit controversial. Surprising findings include:

  •         Most high achievers do NOT use to-do lists.
  •         The Harvard experiment that showed how 3 questions saved 8 hours a week.
  •         Procrastination is cured by “time traveling” to defeat your future self.
  •         Most high achievers practice a consistent morning ritual.
  •         How high achievers manage their email

If you haven’t bought a copy of 15 Secrets Successful People Know About Time Management, I would recommend that you start your personal program to improve your productivity by using the link in the show notes and buying a copy!

Kevin Kruse is an Inc 500 serial entrepreneur, New York Times bestselling author, and Forbes columnist. Kruse has been named a Top 100 Business Thought Leader by Trust Across America. Over the last 20 years Kevin has started or co-founded several multi-million dollar companies which have won awards for both fast growth (Inc 500) as well as employee engagement (#4 Best Place to Work in PA). As a keynote speaker and performance coach, Kevin has worked with Fortune 500 CEOs, startup founders, US Marine Corps officers and non-profit leaders.

 

Contact Information:

twitter.com/Kruse

facebook.com/KruseAuthor

instagram.com/kevin__kruse

www.15TimeSecrets.com

www.KevinKruse.com

info@kevinkruse.com

 

Re-Read Saturday News

We concluded the read of Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary. This week’s installment will addresses the epilogue (everybody lives happily ever after) and summarizes some of the key concepts that I have already found useful.  Next week we will begin re-reading  Kent Beck’s xP Explained, Second Edition. I originally read the first edition several years ago on flights traveling between clients.  The book provides an important explanation for xP and the even today confronts us with the realization that Agile is more than just Scrum. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

 

Next SPaMCAST

In the next Software Process and Measurement Cast will feature our essay on using storytelling to jumpstart Agile efforts. Telling stories is a natural human activity from time immemorial that can be used to create a succinct and informative story to describe a business need or the future of an organization.  The essay provides an approach for using storytelling and suggests that sometimes the journey an organization must take to achieve a goal needs facilitation.

We will also have columns from the Software Sensi, Kim Pries and an entry from Gene Hughson’s 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

Re-Read Saturday: Commitment – Novel about Managing Project Risk, Part 7

Picture of the book cover

Commitment

Today we conclude our read of Commitment – Novel about Managing Project Risk with a few highlights.   

The novel Commitment presents Rose’s evolution from an adjunct of a traditional project manager into an Agile leader. Rose is ripped out of her safe place and presented with an adventure she is reticent to take.  The project she is thrust into leading is failing and Rose can either take the fall or change. Real options and Agile techniques are introduced as a path forward for both Rose and the team. In the novel, Agile concepts such as self-organization are at odds with how things are done.  When a change is introduced that clashes with how we do things, it generates cognitive dissonance. Coaching and mentoring are methods for sorting out the problems caused when dissonance disrupts and organization.

One the hardest changes Rose has to address during the novel is that the job is not really done until the work is delivered to the customer. And as we find out later in the story, the job is not done until the customer uses what has been delivered. Many software projects fall prey to this problem because developers and testers are incentivized to complete their portion of the work so they can begin the next project. In many cases as soon as work is thrown over the wall it disappears from short-term memory. Throwing work over the wall breaks or delays the feedback cycle which makes rework more costly.  In the novel we see this problem occur twice, once between development and testing and later between the whole team and the customer who was afraid to implement the code every two weeks. Completing work and generating feedback are critical to making decisions

The novel’s explanation of staff liquidity was excellent. The process of staff liquidity begins by allocating the people with the least options (the fewest things they can do or most specialized) to work.  In self-managing teams, this requires that team members have a good deal of team and self-knowledge (see Johari’s Window). Those with more options fill in the gaps in capability after the first wave of allocation and are available to react when things happen. Allocating personnel with the most options last provides the team with the most flexibility. It should be noted that just because someone has a large amount of experience, that might not translate to options. Expertise and experience in one capability (for example, a senior person that can only test) has very few options, and therefore, have to be allocated early. Steven Adams connotes staff liquidity to T-shaped people. T-shaped people have a depth of expertise in one or few areas but have shallower expertise outside his or her specialty.  A T-shaped person enjoys learning and will have a good handle on their learning lead time. A team of T-shaped people and the use of staff liquidity increases the number of options a team has to deal with problems and changes as they are recognized.

In the epilogue of Commitment – Novel about Managing Project Risk everyone lives happily ever after.  At the end of the novel, I am left both with a better handle on a number of Agile and  lean techniques and perhaps more importantly with the need to see the options possible so that we can discern the difference between making a commitment and when we actually have choices. In the end, options allow us to maximize the value we deliver as we navigate the world full of changing context.

Thanks to Steven Adams who recommended Commitment.  Steven re-read the book and provided great comments week in and week out (Steven’s blog). His comments filled in gaps and drew my eye to ideas that I had not put together.  

Next week we begin the re-read of be Kent Beck’s xP Explained, Second Edition.

Previous Installments:

Part 1 (Chapters 1 and 2)

Part 2 (Chapter 3)

Part 3 (Chapter 4)

Part 4 (Chapter 5)

Part 5(Chapter 6)

Part 6 (Chapter 7)

 


Categories: Process Management

Starting An Agile Effort: People

Broken Chinese Statues

A good team will not go to pieces!

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

Team dynamics are an expression of how the team interacts with each other and those outside the team. A recent installment of Google’s “The Water Cooler” blog reported on a study done by Google on what makes a team effective at Google.  They found five critical factors:

  1. Psychological safety. Risks can be taken without causing insecurity or embarrassment.
  2. Dependability. Team members can count on each other (people say what they will do and do what they say).
  3. Structure and Clarity. The goals, roles, and execution plans are clear (and shared).
  4. The Meaning of Work. The work is important to the team members.
  5. The Impact of Work. The team believes that their work matters.

What team members believe and how they interact turned out to be the most important factors that lead to effective teams in the Google universe.  Interestingly, a New York Times article (Sunday, May 29th, 2016, Sunday Review Section p1, 4-5) written by Alain de Botton, titled “Why You Will Marry the Wrong Person” makes a similar argument about couples.  In the article, he stated:

The person who is best suited to us is not the person who shares our every taste (he or she doesn’t exist), but the person who can negotiate differences in taste intelligently — the person who is good at disagreement.

The same focus on dynamics reinforces Google’s findings that the right dynamics unlock a team’s potential.  Note:  This another VERY strong argument not to mess with the structure of teams that work well, if at all possible. 

Capabilities are abilities individuals have or can acquire to solve problems presented to the team. Capabilities include the knowledge of the business problem, application, and technical skills in applying tools, languages, and frameworks. One capability often not readily considered is knowledge of the lead time (Knowledge Options) to learn a new skill or techniques that might be needed to address a problem.  Knowledge options are where you know just enough about a subject to know how to apply the subject and how long it will take to get up to speed on the topic when needed. Understanding both current skills and the collection of a team’s knowledge options dramatically increases the breadth of technical and business problems any specific team can address.

Individual Agile teams are typically constrained to five to nine bodies. More than nine tends to cause communication problems, and in teams of less than five, it is difficult for the team to have the capabilities needed to address most sizable software problems. Large Agile efforts typically require multiple teams (scaling Agile). Business need and budget help to determine how many people (and therefore teams) will be needed. 

Part of starting an Agile effort is determining who will be involved, what their capabilities are or can be and finally a rough count of the teams that will be needed.  Even if the goal of the effort does not change, the path towards that goal will evolve, which means that many of the factors originally forecast (including scope, budget, people, and capabilities needed to deliver) will also evolve.  However, without some forecast of the people or teams needed it is difficult to get any effort started Agile.


Categories: Process Management

Starting An Agile Effort

Looking at the map to starting an Agile effort?

Looking at the map to starting an Agile effort?

What is needed to start an Agile project?  There are a number of requirements for beginning an Agile effort.  Those requirements typically include a big picture understanding of the business need, a budget, resources, and a team.   Somewhere in that mess, someone needs to understand if there are any unchangeable constraints. A high-level view of the five categories of requirements for starting an Agile effort are: 

  1. Business Need – All efforts need to begin with a goal firmly in mind.   While the absolute detail of how to achieve that goal may be discovered along the way, it is unconscionable to begin without firmly understanding the goal. Understanding the goal of the effort is the single most important requirement for starting any effort. Storytelling is a tool to develop and share the effort’s goal.
  2. Budget – In almost every organization, spending money, effort or time (the calendar kind) on an effort means that something else does not get funded. Very few efforts are granted the luxury of unlimited funds (money or effort). All efforts require a budget.  Budgeting begins at the portfolio level where decisions on which piece of work need to be addressed, then flows downward to programs or release trains where it divided up into finite pots of money.  The trickle down of the budget typically ends a team’s doorstep with a note saying that they have this much “money” to address a business need. The term money is used loosely as the effort is often used as a currency in many organizations.  If the business need or goal is the most important, then having a budget is a close second.
  3. Resources – In corporate environments resources generally include hardware, software, network resources and physical plant (a place to work).  People are not resources. In the late 90’s I participated in large bank merger projects.  In one of the projects the resources that had to be planned for were renting a floor in building (and lots of desks, chairs, phones, and stuff) and funding a route on an airline for the length of the project.
  4. People – People, often organized in teams, get the work accomplished.  Individual Agile teams should be cross-functional, self-organized and self-managed. A good team is a mixture of behaviors, capabilities and the right number of bodies. People are the third most important requirement for beginning an Agile effort.
  5. Constraints – Understanding the hard constraints for any effort has to operate within is important.  Some efforts are in response to legal mandates (income tax changes for example) or have to fit within specific hardware footprints (embedded code for example).  Constraints often are the impetuous for innovative solutions if they are known and anticipated. Note: constraints, like risks, can evolve, therefore they need to be revisited as an effort progresses.  

There is a hierarchy of requirements.  An effort needs a goal. A goal is needed to acquire a budget. A budget is needed to acquire a team and resources. Constraints are a wildcard that can shape the all of the other requirements.  Understanding and ensuring that the effort’s requirements are addressed is what is necessary for starting an Agile effort. 

The next few blog entries will explore each category in greater detail.


Categories: Process Management

Quote of the Month June 2016

From the Editor of Methods & Tools - Mon, 06/06/2016 - 12:56
The only software which doesn’t change is dead software. Stopping software from changing is a fast way to kill it. Treating software development as a temporary endeavour kills it. Regarding software as temporary also means the teams which create it get regarded as temporary. Such teams get disbanded at “the end”. The developers scatter to […]

Cumulative Flow Diagrams – Figures for SPaMCAST 397

Software Process and Measurement Cast - Sun, 06/05/2016 - 22:10

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams.  The following file includes all of the figures referenced in the cumulative flow diagrams  essay which is part of SPaMCAST 397.

Categories: Process Management

Cumulative Flow Diagrams – Figures for SPaMCAST 397

Software Process and Measurement Cast - Sun, 06/05/2016 - 22:10

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams.  The following file includes all of the figures referenced in the cumulative flow diagrams  essay which is part of SPaMCAST 397.

Categories: Process Management

SPaMCAST 397 – Cumulative Flow Diagrams, QA Sign, Project Strategy

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 397 features our essay on cumulative flow diagrams.  A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Cumulative flow diagrams are extremely versatile tools for managing work.

Download the figures that support this essay.

Our second column is a visit to the QA Corner. Jeremy Berriault weighs in on the thorny question of who signs off or approves the results of testing for projects. We discuss some strange behaviors that occur when responsibility and authority for the results of testing are ambiguous.

We also have the debut column from Jon M. Quigley. Jon inaugurates his column with a discussion of whether project risk, scope, and strategy are related.  The short answer is yes, and the longer answer suggests what happens when all of the options are not considered.  Jon is a principle at Value Transformation, LLC (www.valuetransform.com) along with being a teacher, coach, serial author and past guest on SPaMCAST 346.

Re-Read Saturday News

We continue the read of Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary.  Buy your copy today and read along (use the link to support the podcast). This week’s installment will address Chapter 7, which using the monomyth structure represents both atonement and the return home, the completion of the cycle.  Next week we will conclude with a few final thoughts.  The next book in the Re-read Saturday Series will be Kent Beck’s xP Explained, Second Edition. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next SPaMCAST

The next Software Process and Measurement Cast features our interview of with bestselling author Kevin Kruse.  We discussed his new book, 15 Secrets Successful People Know About Time Management.  The ideas on managing time and more accurately managing focus are extremely useful and in some cases just a bit controversial.  Listen to the interview, then buy a copy of his book and become more productive!

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 397 – Cumulative Flow Diagrams, QA Sign Off, Project Strategy

Software Process and Measurement Cast - Sun, 06/05/2016 - 22:00

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams. A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Cumulative flow diagrams are extremely versatile tools for managing work.

Figures for this essay are included as a separate entry in the feed.

Our second column is a visit to the QA Corner. Jeremy Berriault weighs in on the thorny question of who signs off or approves the results of testing for projects. We discuss some strange behaviors that occur when responsibility and authority for the results of testing are ambiguous.

We also have the debut column from Jon M. Quigley. Jon inaugurates his column with a discussion of whether project risk, scope and strategy are related. The short answer is yes, and the longer answer suggests what happens when all of the options are not considered. Jon is a principle at Value Transformation, LLC (www.valuetransform.com) along with being a teacher, coach, serial author and past guest on SPaMCAST 346.

Re-Read Saturday News
We continue the read of Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary. Buy your copy today and read along (use the link to support the podcast). This week’s installment will address Chapter 7, which using the monomyth structure represents both atonement and the return home, the completion of the cycle. Next week we will conclude with a few final thoughts. The next book in the Re-read Saturday Series will be Kent Beck’s xP Explained, Second Edition. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.


Next SPaMCAST
The next Software Process and Measurement Cast features our interview of with bestselling author Kevin Kruse. We discussed his new book, 15 Secrets Successful People Know About Time Management. The ideas on managing time and more accurately managing focus are extremely useful and in some cases just a bit controversial. Listen to the interview, then buy a copy of his book and become more productive!

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 397 – Cumulative Flow Diagrams, QA Sign Off, Project Strategy

Software Process and Measurement Cast - Sun, 06/05/2016 - 22:00

The Software Process and Measurement Cast 397 features our essay on cumulative flow diagrams. A CFD can help everyone from team members to program managers to gain insight into issues, cycle time and likely completion dates. Cumulative flow diagrams are extremely versatile tools for managing work.

Figures for this essay are included as a separate entry in the feed.

Our second column is a visit to the QA Corner. Jeremy Berriault weighs in on the thorny question of who signs off or approves the results of testing for projects. We discuss some strange behaviors that occur when responsibility and authority for the results of testing are ambiguous.

We also have the debut column from Jon M. Quigley. Jon inaugurates his column with a discussion of whether project risk, scope and strategy are related. The short answer is yes, and the longer answer suggests what happens when all of the options are not considered. Jon is a principle at Value Transformation, LLC (www.valuetransform.com) along with being a teacher, coach, serial author and past guest on SPaMCAST 346.

Re-Read Saturday News
We continue the read of Commitment – Novel About Managing Project Risk by Maassen, Matts, and Geary. Buy your copy today and read along (use the link to support the podcast). This week’s installment will address Chapter 7, which using the monomyth structure represents both atonement and the return home, the completion of the cycle. Next week we will conclude with a few final thoughts. The next book in the Re-read Saturday Series will be Kent Beck’s xP Explained, Second Edition. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.


Next SPaMCAST
The next Software Process and Measurement Cast features our interview of with bestselling author Kevin Kruse. We discussed his new book, 15 Secrets Successful People Know About Time Management. The ideas on managing time and more accurately managing focus are extremely useful and in some cases just a bit controversial. Listen to the interview, then buy a copy of his book and become more productive!

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

Re-Read Saturday: Commitment – Novel about Managing Project Risk, Part 6

Picture of the book cover

This week’s installment of Commitment – Novel about Managing Project Risk by Olav Maassen, Chris Matts and Chris Geary (2nd edition, 2016) will address Chapter 7, which using the monomyth structure represents both atonement and the return home, the completion of the cycle.  Next week we will conclude with a few final thoughts.  The next book in the Re-read Saturday Series will be Kent Beck’s xP Explained, Second Edition.   

Chapter 7 begins when Duncan tracks Rose and her sister down to tell her that she may not have a job. The client pulled funding because it was too risky. Rose decides to tackle the problem head on and ropes her sister and Duncan into seeing if they can get things sorted out. All of this is occurring despite the fact that they were getting positive feedback on a weekly basis (later we find out that the client has not been implementing the new code rather waiting for a big bang, which IS risky).

When the trio gets to work, Rose gathers the team and does some scenario planning.  Scenario planning is a form of the real options approach proposed in Commitment. The team identifies four potential four scenarios for their situation. The first is that the work goes forward as normal. The second is the possibility that the company can salvage some of the work completed and use it for another client.  The third is that some of the people go to work with the “idiots” on the fourth floor (Duncan’s project).  The fourth scenario is scrapping everything and everyone is fired. Rose asks the team to split up into smaller teams of 2 to 3 to flesh out the scenarios so that everyone will know how to act if that scenario becomes a commitment. On a personal level, this type of scenario planning is deeply ingrained in my psyche. 

As with other points in the novel, after the introduction of a concept, a call out is used to provide exposition.  The call out is Lilly’s blogs entry on increasing your psychic odds using scenario planning.  The blog entry points out that scenario planning is another expression of real options. The scenario planning helps to reduce the angst of uncertainty without making a commitment (discussed in Chapter 6). The blog entry provides an example documented in Peter Senge’s book, The Fifth Discipline. The process generated communication and collaboration across siloed group and department lines, which did not happen normally. Scenario planning as a tool for risk management has positive benefits because people think through how they will act and react if the scenario occurs.  Scenario planning in Senge’s book occurred at an organizational level; however scenario planning is applicable at any scale.

The transition back to the action in the story begins with as Rose meets with the client and begins the meeting by explaining the impact of the ‘cancel the project’ scenario on the client.  Rose walks through a chart showing the two of the client’s competitors that have been updating their software monthly are taking market share from Rose’s client.   Rose’s client has not updated their software in over a year, even though they were getting weekly updates. Rose suggests that if the trend continues the client will have no market share. The meeting shows the risk issue as the client’s fear that if a change goes wrong they will lose market share even faster.  Rose points out that the weekly incremental change reduces risk and that because the change is incremental even if something goes wrong it will be “rolled back” quickly minimizing the impact.  The meeting ends with the client going off to reconsider (taking Rose’s phone number so they can go to the source to ask the questions). 

Skipping over the date with Duncan that includes a bad movie, piano playing, and dark apartment windows, we get to the decision.  The phone rings and everyone holds their collective breath waiting for Rose to answer.  The project is back on and after a brief non-celebration, they press forward to complete the project.

We next cut to the project retrospective and celebration.  Interrupting the end of project celebration, a group of suits enters and announces the sacking of Rose from the project at the request of the client.  The sacking from the project clears the way for her promotion to vice president. The scene provides a bit of melodrama for capping the chapter.

We will finish Commitment – Novel about Managing Project Risk next week with final thoughts and a word or two on the Epilogue.

Previous Installments:

Part 1 (Chapters 1 and 2)

Part 2 (Chapter 3)

Part 3 (Charter 4) 

Part 4 (Chapter 5)

Part 5(Chapter 6)


Categories: Process Management

Facilitating A Storytelling Session

Ruins of Willkarakay

Telling stories is a natural human activity from time immemorial.  Creating a succinct and informative story to describe a business need or the future of an organization is challenging.  Stories are not bulleted presentation slides, although those tools can be used.  Rather stories at this level are longer narratives, or at the very least they are like the paintings in Lascaux Caves which evoke a longer narrative. Narrative storytelling is not a tool typically found or appreciated in status meetings, the process of building a narrative that describes a business need or the journey an organization must take to achieve a goal often needs facilitation.  Three facilitation tools are commonly used to help a team or an individual to build a story in a business environment. They are:

Context setting – A few of my friends write as at least part of their livelihood.  I am not sure I have ever heard one these professional writers say they begin a book or article without an idea of what they want to write about or where they want their protagonist’s journey to end. All writers need to begin with some context to direct the writing process.  A facilitator needs to do the pre-work to discover and understand the goal and the context surrounding of the storytelling session.   I suggest meeting with the session’s sponsor and a few of the participants in order to flesh out the context.  Consider these interview questions as a tool to get the stakeholder talking and to keep him or her talking:

  • Tell me about your vision of —— (insert stated rationale for the session)?

If this new:

  • Why is this change or functionality important to you? To the organization? To your customer?
  • What is your darkest fear if this change does not occur (or new functionality is not implemented)?
  • What is the greatest risk to accomplishing this change?

While many of these questions can create anchor bias (binding a team to a specific idea) the facilitator still needs to ask the questions to a subset of the team beforehand so the facilitator can prepare to help the entire team.  The pre-session serves multiple purposes:

  1. Creating the goal of the storytelling session.
  2. Gathering input for seed questions or scenarios to jumpstart the story session.
  3. Identifying pre-reading or research the storytelling team might need. 

Seed questions – Seed questions provide a structure that guides the session toward the desired goal without putting words in the team’s mouths.  The facilitator uses seed questions when the team seems to be becoming blocked or starting to wander off track. The facilitator should look for these situations and try to intercede before the team reaches gridlock.   All seed questions require situational context to be effective.  If a team is envisioning next year’s organizational structure, asking whether the local sports team will win isn’t relevant and could easily take the session off course.  Typical seed questions often focus on the classics of who, what, why, where and how much.  Seed questions might include phrases like:

  • What does  . . .  look like?
  • When you meet the goal . . .   
  • Who is impacted when  . . .
  • What problems do you anticipate getting to . . .
  • Could you say more about . . .
  • How would leadership need to change . . .

‘How’ questions are better at getting the team to discuss a process or journey. Create a set of seed questions based on the goal and research before the storytelling session. However, use what is happening in the session to customize the seed questions.

Listening – The facilitator needs to understand the goal so that that they can help the team keep the right pace and to stay on track. Active listening techniques such as repeating back, showing interest and asking to hear more about a point are useful to establish listening credibility with the team. Listening is critical to developing a level of rapport that will help establish the facilitator’s authority which he or she needs to re-direct the conversation. 

While storytelling may be in our DNA, but we often need a little help crafting a story in safe environment.  Storytelling while sitting around table in a typical corporate conference room often needs a bit more help, which is where the facilitator needs to step in.  When a facilitator steps in they need to have pre-planning and structure on their side.   


Categories: Process Management

Behind the Scenes: A Minimal Viable Setup for Creating Video Scribe

Xebia Blog - Thu, 06/02/2016 - 16:28
I'm getting a lot of questions about my previous blog post. Fortunately also about the content, but mostly about how I created the video. So in this episode we will look at the MVP (Minimal Viable Product) version of a video scribe and the lessons learned. This way you can make a better video scribe based on