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.

Agile Teams and Management Styles

Baseball Game

Teams and situations require different management styles.

Every team may leverage several styles of management to deliver value most efficiently. In agile teams, some styles are used more often than others. The default management style for Agile teams tends to be participative, but management style is affected by team size, context, and role.

Team Size: ¬†The number of people on a team affects possible management styles. ¬†The larger the team, the less participative the team can be due to the sheer number of connections and conversations required. ¬†I have participated on ‚Äúteams‚ÄĚ of 30 or 40 people earlier in my career (I use the term ‚Äúteam‚ÄĚ with reservation). With large teams like that, the possible number of interconnections between individuals is limited, where the formula (n(n-1))/2 defines the possible number of combinations. ¬†A 35 person team requires 595 connections, most of which would have to exercise to generate the consensus needed to execute participative management. Frankly, that is impractical. Agile teams are fairly complicated even though there are aren‚Äôt an infinite number of moving parts. ¬†Scrum teams are typically 5 to 9 people including a Scrum master and product owner, while XP teams tend to be in the 4 – 12 person range. ¬†A team of 12 would have 66 possible connections. ¬†Teams with larger numbers of connections tend to favor directive approaches ranging from the somewhat participative negotiative style to delegative management, or the command and control favorite, the authoritarian style.

Role: Role power is a concept that rarely gets discussed in most Agile conversations, however, different roles often represent a differential in power. For example, the product owner will tend to have more organizational power than a typical tester or coder.  Teams often premise interactions and decision-making on members checking their titles at the door.  Checking titles at the door is code for assuming equality of power at the team level. However, that equality is rare.  Product owners, tech leads and even the scrum master’s opinions tend to have more weight than someone that is one amongst equals.   These types of power imbalances tend to foster the use of negotiative or delegative management styles.

Context: Context is the most important rationale for using different management styles.  Most adherents of Agile would be quick to extol the virtues of collaborative management.  Collaborative management is very supportive of self-organization and self-management, however, there are occasions when collaborative management styles do not make sense.  In times of great stress, more direct authoritative styles are typically more appropriate (when there is a fire in the airline cabin, decisions must be made). How the team adjusts behaviorally, integrates the new decision or direction change and then settles back to its preferred style says a lot about the maturity of the team. A mature team typically recognizes the need for the management style diversion or urges the team member back toward the team norm (through peer pressure or discussion). At other times, Agile teams use delegative approaches to allow a member (or subgroup) to make decisions within their specialty areas.  For example, I recently observed a team that tapped two members to review and purchase print modules for an application.  The team agreed upon a broad set of criteria, then charged the subgroup to operate within that framework.  Whether addressing decision-making in emergencies or areas of technical expertise, context-dependent changes in style are typically short term. Afterwards, the team reverts almost immediately to their preferred style as soon as the need for an alternative style passes.

Teams always have preferred management styles but, as with potato chips, an Agile team can’t just use a single style. Getting work done is complicated. Teams reflect a chaotic environment of roles, team size and situation.

 

Management / Leadership Thread


Categories: Process Management

Dockerised Jenkins 2 on Google Cloud Platform

Xebia Blog - Tue, 08/30/2016 - 13:03
Any company doing serious software development needs a platform. The platform allows the company to build and test software and support running all applications. I have had a lot of experience with a platform based on AWS, Docker, and CoreOS using Fleet for orchestration. But being as curious as I am, I wanted to look

Help Me Create a Better Way to Prioritise Features

Xebia Blog - Tue, 08/30/2016 - 09:37
Do you remember the legendary PID? the Project Initiation Document. The famous big binder that we used to create in the beginning of a project to satisfy governance and then bury in a drawer so we could get started. Then agile came and we broke things down. We learned story maps, customer journeys, vision statements,

Attitude versus Knowledge in Software Development

From the Editor of Methods & Tools - Tue, 08/30/2016 - 08:52
In her article for the Summer 2016 issue of Methods & Tools, “Hiring for Agility,” Nadia Smith suggested considering an interesting difference between the need to recruit for “Agile”, defined as the knowledge and experience of Agile practices, and to recruit for “agility”, defined as attitude, values and behavior. Without focusing on Agile, this approach […]

SPAMCAST 409 ‚ÄúDelay‚ÄĚ

Friends, I have had an issue with my computer.  When I returned for grocery shopping the machine had stopped functioning.  There is a remote possibility that I will post this evening but the odds are that we will be back next week.


Categories: Process Management

Extreme Programming Explained, Second Edition: Re-Read Week 11 (Chapters 20 ‚Äď 21)

XP Explained Cover

This week the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) tackles Chapters 20 and 21.  Chapter 20 is a discussion of applying XP.  The short version is that there is no one perfect way to apply XP, which dovetails nicely with Chapter 21 which addresses the concept of purity and certification.  IF there is no one perfect way to apply XP, there can’t be a litmus test for XP purity.

Chapter 20: Applying XP

Software development is rife with waste and inefficiencies even though practitioners have been struggling for years to wring the waste out the process.  Part of the issue is that people by their general nature are chaotic, therefore don’t always work in the most efficient manner. Other parts of the problem are that developing software is complex and what ends up running in production is often a result of learning and innovation.  Said more simply, software development is not a result of an assembly line process. There are many paths to developing code based on context, people, and the business problem being solved, hence the potential for inefficiencies.

Many organizations make the mistake of mandating the adoption of a methodology such as XP without addressing the pre-existing problems in the organization that lead to inefficiency and waste.  Organizations that have not dealt with the problems that make embracing the philosophies and principles that underpin XP viable are then shocked when individuals and teams revert to earlier practices they perceive as safer or more comfortable. Beck suggests that strong sponsorship is helpful to avoid reverting away from XP at the organization level.  At a lower level, for addressing the inertia created by pre-existing problems that are slow to change Beck again suggests the idea of leading by example, adopting XP yourself and providing tangible outcomes (and stories) are a powerful tool for change. 

The concept of continuous improvement connotes a smooth progression towards an ultimate goal. Any experienced practitioner or observer of organizational change will understand that idea of a smooth progression toward the future is a simplification.  Rather, progress is more of series of jumps as improvements are made, tempered by feedback and then integrated into the organization.  Change can be facilitated by coaching.  Coaches can bring knowledge-based on a wider base of experience to the team. Coaches are also a means to change the composition of the team which can inject the energy need to motivate change.

The final word on applying XP is if your organization’s values and principles are at odds with XP, don‚Äôt apply XP to the organization until you wrestle with the pre-existing culture.

Chapter 21: Purity

How can you tell if a team or organization is¬†practicing XP? ¬†There is no binary purity test. ¬†For example, just practicing pair programming does not mean you are practicing XP, just as being a distributed team meana you can‚Äôt practice XP. The values, principles, and practices that comprise the definition of XP in Extreme Programing Explained, Second Edition provide potential users of XP with guidance. Beck says, ‚ÄúSaying your team is extreme sets other people’s expectations for your style of communication, your development practices, and the speed and quality of your results.‚ÄĚ Whether you use extreme, Agile or are an RUP practitioner, what you call yourself sets expectations based on the values and principles embedded in the methodology. ¬†In the end, purity is a matter of living up to the expectations of values and principles you espouse.

The discussion of purity in Chapter 21 evoked a rant on certification. ¬†Beck stated, ‚ÄúIf a certifying authority isn’t willing to stand behind IT certification, it’s just printing certificates and collecting money.‚ÄĚ The suggestion is that like board certifications in medicine¬†unless the certification board is willing to police usage, the certification lacks value. ¬†As a member of the board of an association that tests and certifies practitioners, Beck‚Äôs comments are food for thought.

Based on the premise that XP can be implemented and practiced in many different ways, if the way you are practicing XP upholds the values and principles of XP you are “doing” XP. ¬†In other words there can be no litmus test and certification based on XP purity.

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

Remember  we are going to read The Five Dysfunctions of a Team by Jossey-Bass 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

Leadership and Management Are Not The Same Thing!

Follow me this way!

Follow me this way!

Most any substantive of discussion of Agile sooner or later turns to leadership.  As teams embrace the principles in the Agile Manifesto that foster self-organization and self-management, they often require a shift away from classic management techniques.  In some cases, as teams begin exploring Agile the idea of management becomes an anathema, while in other cases, the concepts of leadership and management are conflated. Leadership and management are not the same thing and in most organizations, both are required.

A manager is a person responsible for controlling, administering and/or directing all or part of an organization.  Alternatively, a leader is a person that provides motivation and vision that compels others to work with the leader to achieve the goals.

Comparing leaders and managers provides even more distinctions.  

Attribute Leader Manager Power Informal, Earned Formal, Hierarchical People Followers, Voluntary Subordinates, Authority Decision Making Facilitates Makes Vision Tactical Strategic Risk Posture Avoid Taker Culture Endorses Shapes

The list of attributes could go on; however, we can boil down the difference between a manager and leader to the distinction to three critical characteristics: earned power, vision, and followers. Most, if not all, of the rest of the attributes build on that base.  While the difference between a leader and manager is knife edge sharp, who plays each role is far murkier.

A leader provides the vision and motivation needed to push the boundaries, change direction and challenge the status quo ante. Managers, on the other hand, deliver the administration needed for an organization to run; for example, creating and managing budgets, hiring and firing personnel, signing contracts, and other equally important tasks. ¬†Without someone to ‚Äúhandle‚ÄĚ these tasks, no amount of leadership will keep an organization going in the¬†long run. What makes a manager in the knowledge economy different is the need to empower subordinates to plan the day-to-day detail and leaders to leader all the while providing the environment for the magic to happen.

In the knowledge economy, value is dependent on the information available and the ability of people workers who are no longer undifferentiated cogs in the machine.  In this new world, management and leadership are not easily separated. Knowledge workers look to their managers and leaders to provide a vision and a purpose. In order to deliver organizational value, managers must provide the organization that facilitates the development of skills and talent while simultaneously inspiring results. In today’s business environment the role of manager and leader are dependent on each other.  Both roles are required in any partnership, team or multinational organization. There is no reason why a leader and manager can’t be the same person playing different roles based on context, but both roles need to be played.

Management / Leadership Thread

  • Five Different Management Styles
  • Leadership versus Management (Current)
  • Management Styles in Agile Teams
  • Management Styles in Scaled Agile
  • Servant Leaders, Revisited

 


Categories: Process Management

Software Development Conferences Forecast August 2016

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

Five Different Management Styles

Attention Dogs

Delegative management?

During a keynote speech at a conference I recently attended I listened to a Phillip Lew challenge the orthodoxy of Agile’s over-reliance on group decision making (participative management) styles. ¬†Agile teams are typically built a presumption that group decision making is all that is needed to deliver value to the customer. Group decision making is often compared to classic command and control forms (autocratic) of management. In many cases, autocratic management is portrayed as the antithesis of Agile which casts the discussion in terms of good and evil. ¬†Casting the discussion of management styles in terms of good and evil is probably an overstatement and just believing that are there only two management styles is a miss-statement. Let’s deal with the miss-statement first. There are at least five common management styles. Before we can wrestle with whether Agile only works if a pure participative management is used we need to agree on a few definitions.

Autocratic management, also known as directive or command and control, is based on leader assigning work to subordinates and then overseeing the completion of the work. Taylorism, discussed in the re-read of XP Explained, is a form of autocratic management.

Delegative management is a relatively hands-off approach in which a manager hands off a piece of work to the team or lower level manager and lets them deal with it. The hand-off of work includes the responsibility for accomplishing the work. This form of management can be thought of as fire-and-forget.  Assignments, once made, are left to be performed with a minimum of supervision.

Negotiative management features interactions to reach a common agreement. Negotiative management can be practiced between individuals or groups.  Decisions are often based on the power differentials between the participants and their negotiating abilities.

Participative management encourages all people involved in the work to contribute to organizing work and developing solutions. This management style works best when it leverages the diversity of knowledge and experience of the participants. Decisions under this style of management is typically marked by group consensus. This is the most prominent management style seen at the team level in Agile, which highlights self-organizing and self-managing groups.

Consultative management is a hybrid form of management that combines participative and autocratic forms of management.  The leader involves participants as an input, but ultimately the leader then makes the final decision.  When I was in the corporate world this was a typical management approach because preserves a clear chain of responsibility.  

None of these management styles is prima facie good or bad.  They are contextually useful.  For example, in the middle of a traffic accident, a driver will not have time to evoke participative management, but rather will need to make and implement decisions autocratically.  Each management type has strengths, weaknesses and can be applied effectively in specific contexts.

 

Next:

  • Leadership versus Management
  • Management Styles in Agile Teams
  • Management Styles in Scaled Agile
  • Servant Leaders, Revisted

Categories: Process Management

What Are Story Points?

Mike Cohn's Blog - Tue, 08/23/2016 - 15:00

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is estimated as 3 story points.

Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1 million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.

What Goes Into a Story Point?

Because story points represent the effort to develop a story, a team’s estimate must include everything that can affect the effort. That could include:

  • The amount of work to do
  • The complexity of the work
  • Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how each impacts the effort estimate given by story points.

The Amount of Work to Do

Certainly, if there is more to do of something, the estimate of effort should be larger. Consider the case of developing two web pages. The first page has only one field and a label asking to enter a name. The second page has 100 fields to also simply be filled with a bit of text.

The second page is no more complex. There are no interactions among the fields and each is nothing more than a bit of text. There’s no additional risk on the second page. The only difference between these two pages is that there is more to do on the second page.

The second page should be given more story points. It probably doesn’t get 100 times more points even though there are 100 times as many fields. There are, after all, economies of scale and maybe making the second page is only 2 or 3 or 10 times as much effort as the first page.

Risk and Uncertainty

The amount of risk and uncertainty in a product backlog item should affect the story point estimate given to the item.

If a team is asked to estimate a product backlog item and the stakeholder asking for it is unclear about what will be needed, that uncertainty should be reflected in the estimate.

If implementing a feature involves changing a particular piece of old, brittle code that has no automated tests in place, that risk should be reflected in the estimate.

Complexity

Complexity should also be considered when providing a story point estimate. Think back to the earlier example of developing a web page with 100 trivial text fields with no interactions between them.

Now think about another web page also with 100 fields. But some are date fields with calendar widgets that pop up. Some are formatted text fields like phone numbers or Social Security numbers. Other fields do checksum validations as with credit card numbers.

This screen also requires interactions between fields. If the user enters a Visa card, a three-digit CVV field is shown. But if the user enters an American Express card, a four-digit CVV field is shown.

Even though there are still 100 fields on this screen, these fields are harder to implement. They’re more complex. They’ll take more time. There’s more chance the developer makes a mistake and has to back up and correct it.

This additional complexity should be reflected in the estimate provided.

Consider All Factors: Amount of Work, Risk and Uncertainty, and Complexity

It may seem impossible to combine three factors into one number and provide that as an estimate. It’s possible, though, because effort is the unifying factor. Estimators consider how much effort will be required to do the amount of work described by a product backlog item.

Estimators then consider how much effort to include for dealing with the risk and uncertainty inherent in the product backlog item. Usually this is done by considering the risk of a problem occurring and the impact if the risk does occur. So, for example, more will be included in the estimate for a time-consuming risk that is likely to occur than for a minor and unlikely risk.

Estimators also consider the complexity of the work to be done. Work that is complex will require more thinking, may require more trial-and-error experimentation, perhaps more back-and-forth with a customer, may take longer to validate and may need more time to correct mistakes.

All three factors must be combined.

Consider Everything in the Definition of Done

A story point estimate must include everything involved in getting a product backlog item all the way to done. If a team’s definition of done includes creating automated tests to validate the story (and that would be a good idea), the effort to create those tests should be included in the story point estimate.

Story points can be a hard concept to grasp. But the effort to fully understand that points represent effort as impacted by the amount of work, the complexity of the work and any risk or uncertainty in the work will be worth it.

SPaMCAST 408 ‚Äď Kupe Kupersmith, Business Analysis and Agile

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 408 features our interview with Kupe Kupersmith. Kupe and I discussed the role of the business analyst in today’s dynamic environment.  It is critical to defining and facilitating the delivery of value. Weighty topics, but we also had a bit of fun.

‚ÄúKupe‚ÄĚ Kupersmith, President, B2T Training, possesses over 18 years of experience in software systems development. He has served as the lead Business Analyst and Project Manager on projects in the energy, television and sports management and marketing industries. Additionally, he serves as a mentor for business analysis professionals. Kupe is the co-author of Business Analysis for Dummies, a Certified Business Analysis Professional (CBAP¬ģ) and a former IIBA¬ģ Board Member.

Kupe is a requested speaker and has presented at many conferences around the world. Being a trained improvisational comedian, Kupe is sure to make you laugh while you’re learning. For a feel for Kupe’s view on business analysis topics check out his blog on BA Times. Kupe is a connector and has a goal in life to meet everyone!

Contact Information

https://www.linkedin.com/in/kupetheba

https://www.b2ttraining.com/

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 18 and 19.   Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next, we are going to read The Five Dysfunctions of a Team 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

In the next Software Process and Measurement Cast, we will feature essay on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

We will also have columns from Jeremy Berriault‚Äôs QA Corner and Jon M. Quigley‚Äô column, ‚ÄúThe Alpha-Omega of Product Development.‚ÄĚ

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 408 - Kupe Kupersmith, Business Analysis and Agile

Software Process and Measurement Cast - Sun, 08/21/2016 - 22:00

The Software Process and Measurement Cast 408 features our interview with Kupe Kupersmith. Kupe and I discussed the role of the business analyst in today’s dynamic environment.  It is critical to defining and facilitating the delivery of value. Weighty topics, but we also had a bit of fun.

‚ÄúKupe‚ÄĚ Kupersmith, President, B2T Training, possesses over 18 years of experience in software systems development. He has served as the lead Business Analyst and Project Manager on projects in the energy, television and sports management and marketing industries. Additionally, he serves as a mentor for business analysis professionals. Kupe is the co-author of Business Analysis for Dummies, a Certified Business Analysis Professional (CBAP¬ģ) and a former IIBA¬ģ Board Member.

Kupe is a requested speaker and has presented at many conferences around the world. Being a trained improvisational comedian, Kupe is sure to make you laugh while you’re learning. For a feel for Kupe’s view on business analysis topics check out his blog on BA Times. Kupe is a connector and has a goal in life to meet everyone!

Contact Information

https://www.linkedin.com/in/kupetheba

https://www.b2ttraining.com/

 

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 18 and 19.   Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. Visit the Software Process and Measurement Blog (www.tcagley.wordpress.com) to catch up on past installments of Re-Read Saturday.

Next, we are going to read The Five Dysfunctions of a Team 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

In the next Software Process and Measurement Cast, we will feature essay on whether a team is really one or two teams.  While the essay is a result of answering a friend’s question, the ideas in the essay can be applied when you are building any sort of team.

We will also have columns from Jeremy Berriault‚Äôs QA Corner and Jon M. Quigley‚Äô column, ‚ÄúThe Alpha-Omega of Product Development.‚ÄĚ

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 9 (Chapters 18 ‚Äď 19)

XP Explained Cover

This week we continue with the re-read of Kent Beck and Cynthia Andres’s Extreme Programing Explained, Second Edition (2005) with two more chapters in Section Two.  Chapters 18 and 19 provide a view into two very different management philosophies that shaped software development in general and have had a major impact on XP.  Chapter 18 discusses Taylorism and scientific management; a management knows best view of the world. Chapter 19 talks about the Toyota Production System, which puts significant power back in the hands of the practitioner to deliver a quality product.

Chapter 18: Taylorism and Software

Somewhere in the dark ages when I was a senior in high school, I worked for Firestone Tire and Rubber. During my stint as a tire sorter and mold cleaner the time and motion people terrorized me and almost everyone at the plant. ¬†They lurked behind the machines with clipboards and stopwatches to ensure all workers were following ‚Äėthe right way‚Äô to do work. Cut to approximately four years later when I was a senior at Louisiana State University, I took several courses in industrial engineering. ¬†Between both sets of experiences, I learned a lot about industrial engineering, scientific management, and Taylorism. Some of what I learned made sense for highly structured manufacturing plants, but very little makes sense for organizations writing and delivering software (although many people still try to apply these concepts).

Frederick Taylor led the efficiency movement of the 1890’s, culminating in his book The Principles of Scientific Management (1911). Scientific management suggests that there is ‚Äėone best way‚Äô that can be identified and measured to do any piece of work (hence the stopwatches). Scientific management continues to be used by many organizations from manufacturing to hospitals (at least according to my sister-in-law who is a nurse). It is hard to resist something named scientific management, even though scientific management tends to clash with the less regimented concepts found in the Agile and lean frameworks used in knowledge work.

Side Note: Beck points out the brilliance in naming “scientific management,” who would be in favor of the opposite, “unscientific management”? (The book notes that when picking descriptive names, it helps to pick a name whose opposite is unappealing, for example, the Patriot Act.)

Why the clash? ¬†Scientific management was born in a manufacturing environment not software development environment. Taylor was focused on getting the most out workers that he felt had to lead and controlled closely. ¬†In Taylor’s world, making steel or assembling cars were repeatable and predictable processes and the workers were cogs in the machine. Time and motion studies, which are a common tool in scientific management, run into problems based on several simplifying assumptions when applied to many types of work, including software development. ¬†Beck points out three critical assumptions made by Taylor.

  1.   Things usually go according to plan as work moves through a repeatable process.
  2.   Improving individual steps leads optimization of the overall process.
  3.   People are mostly interchangeable and need to be told what to do.

Take a few minutes while you consider the simplifying assumptions as they are applied to writing, testing and delivering functionality, and then stop laughing.

While very few enlightened CIOs would admit to being adherents of Taylor, many would describe their “shop” as a software factory and actively leverage at least some of the tenets of scientific management. ¬†The practice of social engineering developed by Taylor and his followers is built into the role specialization model of IT that is nearly ubiquitous. One form of social engineering practiced on the factory floor even today is the separation of workers from planners, which translates into software development as separating estimators and project managers from developers and testers in today’s IT organization. The planners and estimators decide how and how long the workers will take to deliver and a piece of work. Developers are considered the 21st-century cogs in the machine that work at the pace specified by the planners and estimators. ¬†Every software development framework decries this practice and yet it still exists. ¬†Similarly, Beck points out that creating a separate quality department is another form of social engineering. ¬†The separation of the quality function ensures the workers are working to the correct quality by checking at specific points in the process flow. ¬†In every case, separating activities generates bottlenecks and constraints, and potentially makes each group the enemy of each other. Once upon a time I heard a group of developers mention that they had completed development, but the testers caused the project to be late. ¬†This is a reflection of Taylorism and social engineering.

Chapter 19: Toyota

The Toyota Production System (TPS) is an alternative to Taylorism.  Much has been written about TPS, including several books by Tom and Mary Poppendiech that pioneered applying TPS to software development and maintenance. In TPS, each worker is responsible for the whole production line rather than a single function. One of the goals of each step in the process is to make the quality of the production line high enough that downstream quality assurance is not needed.

In the TPS there is less social stratification and less need to perform independent checking. Less independent checking is needed becasue workers feel accountable for their work because it will immediately used by the next step process. In software development, a developer writes code and tests code that forms the basis for the future stories. A developer in an organization using the TPS can’t hide if they deliver poor quality and will be subject to peer pressure clean up their act and deliver good quality.

Beck caps the chapter with a reminder of the time value of money.  Making anything and then not using it immediately so that you generate feedback causes the informational value to evaporate. Quick feedback is one of the reasons why short iterations and quick feedback generates more value than classic waterfall.

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

A few quick notes. We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), 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

Two Teams or Not: Courage and Flexibility

You got to have courage!

You got to have courage!

I listen to Malcolm Gladwell‚Äôs wonderful Revisionist History podcast. In the last podcast of season one, he discussed ‚Äúthe satire paradox.‚ÄĚ The punchline of the most recent installment of the podcast is that change is not possible without courage. Flexibility requires courage. ¬†Change, when embracing something like Agile, requires the flexibility to give something up. ¬†Perhaps we might be asked to move outside of our comfort zone and work differently, or to work with people we haven‚Äôt worked with before. ¬†Asking testers and developers to work on the same team or to work as pairs or asking backend and UI subteams to work together require¬†flexibility. ¬†We can define flexibility to embrace Agile or any other significant modification to work based on four basic attributes:

  1. Ability to accept changing priorities РAgile projects are based on a backlog that encompasses the prioritized list of work for team(s).  This backlog will evolve based on knowledge and feedback. The evolution of the backlog includes changes to the items on the list and the priority of the items on the list. All team members, whether a developer, business analyst or tester, need to accept that what we planned on doing in the next sprint might not be what we originally thought.  
  2. Ability to accept changing roles and workload РSelf-directed and self-managed teams make decisions that affect who does what and when.  Each team member needs to accept that they might be asked (or need to volunteer) to do whatever is needed for the team to be successful.  Adopting concepts such as specializing generalists or T-shaped people are a direct reflection of the need for flexibility.
  3. Ability to adapt to changing environments – Business and technical architectures change over time. Architectures are a reflection of how someone (a team or an architect) perceives the environment at a specific moment in time. Implementing the adage that developers should ‚Äúrun towards feedback‚ÄĚ requires courage and flexibility.
  4. Ability to persist РAny process change requires doing something different, which is often scary or uncomfortable even if it is only briefly. If we give up immediately at the first sign of unease nothing would ever change, even if the data says that staying the course will be good.  For example, the first day at all six universities that I attended was full of stress (I remember once even having the dream that I could not find my classes). I was able to find the courage to persist and push through that unease in order to make the change and find a seat in the back of room in each class.

When I was asked whether two teams were really one team or whether they should find a way to work together, the answers have been premised on the assumption that they had the courage or the flexibility to change. The discussion of courage and flexibility is really less about Agile techniques, but rather a change management issue. A test of whether courage and flexibility are basic issues can be as simple as listening to team members comments. ¬†If you hear comments such as ‚Äúwe have always done it that way‚ÄĚ or ‚Äúwhy can’t we do it the way we used to?‚ÄĚ, then leaders and influencers need to assess whether a team or individual has the courage and flexibility to change. ¬†If they do not have the flexibility and courage needed, leaders and coaches need to help develop the environment where courage and flexibility can develop before any specific process framework or technique can be successful.

Changing how people work is difficult because most people only choose to change if they see a greater benefit/ pain avoidance than the pain of not making the change. Flexibility is a set of abilities help individuals and teams to make a choice and then establishing a commitment to that choice so that change happens.


Categories: Process Management

Software Development Linkopedia August 2016

From the Editor of Methods & Tools - Wed, 08/17/2016 - 15:25
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about team management, the (new) software crisis, saying no, software testing, user experience, data modeling, Scrum retrospectives, java microservices, Selenium tests and product backlog refinement. Blog: The Principles of Quantum Team […]

Two Teams or Not: First Do No Harm (Part 2)

A pile of empty pizza boxes!

WIP limits are needed to stop waiting in queues.

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

  1. ¬†¬†Establish beginning WIP limits for each task. Work in Process (WIP) limits indicate how many items any specific task should control at a time (being worked on or waiting in queue). An easy approach to determining an initial WIP limit for a task is to count the number of people whose primary responsibility is to perform that task (Joe is a primarily a coder ‚Äď count 1 coder) under the assumption that a person can only do one thing at time (good assumption), and then use the count of people as the WIP limit. Roles that are spread across multiple people are a tad messier, but start by summing the fraction of time each person that does the role typically spends in that function (round to the nearest whole person for the WIP limit). ¬†The initial WIP limit is merely a starting point and should be tuned as constraints and bottlenecks are observed (see the next step).

As the team is determining the WIP limits, think about whether there are tasks that only one person can perform that are necessary for a story to get to production. These steps are potential bottlenecks or constraints.  When developing the WIP limits identify alternates that can perform tasks (remember T-shaped people!).  If members of a silo can participate only in their own silo it will be difficult for them to help fellow team members outside their silo, which can be harmful to team morale.  This type of issue suggests a need for cross training (or pair-programming or mob programming) to begin knowledge transfer.  

  1. ¬†¬†Pull stories from the backlog and get to work! Pull highest priority stories into the first task or tasks (if you have multiple independent workflows you will have multiple entry points into the flow). ¬†When a story is complete it should be pulled into the next task, if that task has not reached its WIP limit. ¬†¬†If a task can’t be pulled into the next step, it will have to wait. ¬†When stories have to wait, there is a bottleneck and a learning opportunity for the team.

As soon as stories begin to queue up waiting to get to the next step in the flow, hold an ad-hoc retrospective.  Ask the team to determine why there is a bottleneck. One problem might be that the WIP limit of the previous task is too high.  Ask them how to solve the problem.  If they need help getting started ask if the queue of stories is due to a temporary problem (for example, Joe is out due to the flu) and then ask if there is more capacity to tide things over.  If the reason is not temporary (for example, only a single person can do a specific task, or stories are too large and tend to get stuck) ask the team to identify a solution that can be implemented and tested.  The goal is to have the team identify the solution rather than have the solution imposed on them from someone else (think buy-in).

Using kanban or Scrumban to identify and generate solutions to how teams work facilitates the development of good teams. Good Agile teams exhibit three attributes:

  • Bounded – Team members belong to the team and the relationships that they develop will be ‚Äústicky.‚ÄĚ
  • Cross-functional – Cross-functional teams spend less time negotiating hand-offs and tracking down who can or should do any piece of work, thereby reducing the potential for bottlenecks.
  • Self-organized and self-managed – Self-organized and self-managed teams don‚Äôt need to wait for permission to make the decisions needed to remove bottlenecks or process constraints.

Overlaying kanban or Scrumban on top of the team’s current process does not change anything. . . .to start with. But it does position the team to take action when they SEE a problem. ¬†Visualization of how work is flowing will show the team where bottlenecks occur. The scrum master or coach then needs to challenge the team to eliminate those bottlenecks, promoting the health of the team in the process.

 


Categories: Process Management

The Legend of the 5 Monkeys, the Doctor and the Rose

Xebia Blog - Mon, 08/15/2016 - 17:16
As Product Managers people look up to us to carry the vision, to make sure all the noses are aligned, the troops are rallied and that sort of stuff. But what is it that influences behavior? And what makes your team do what they do? The answer has more to do with you than with

SPaMCAST 407 ‚Äď Magazine with Cagley, Hughson, Pries, and Tendon

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 407 includes four separate columns.  We begin with a short essay refreshing the pros and cons of Test Driven Development. Test Driven Development promises a lot of benefits but all is not light, kittens and puppies. Still, TDD is well worth doing if you go into it with your eyes open.

Our second column features Kim Pries, the Software Sensei. ¬†Kim discusses what makes software ‚Äúgood.‚ÄĚ The Software Sensei puts the ‚Äúgood‚ÄĚ in quotes because it is actually a difficult word to define but Kim is willing to give the discussion a go!

In our third column, we return to Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 10 which is titled The Thinking Processes. Thinking processes are key to effectively using  Agile, lean and kanban processes.  

Gene Hughson anchors the cast with an entry from his Form Follows Function Blog. ¬†In this installment, we discuss the blog entry titled ‚ÄúLearning to Deal with the Inevitable.‚ÄĚ ¬†Gene and I discussed change which is inevitable and innovation which is not quite as inevitable.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 16 and 17.   Chapter 16 ends Section One with an interview with Brad Jensen.  Section Two addresses the philosophies of XP.  Chapter 17 tells the creation story of XP from Beck’s point of view.

We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), 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.

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. 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, we will feature our interview with Kupe Kupersmith. Kupe brings his refreshing take on the role of the business analyst in today’s dynamic environment.  This interview was informative, provocative and entertaining.     

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 407 - Magazine with Cagley, Hughson, Pries, and Tendon

Software Process and Measurement Cast - Sun, 08/14/2016 - 22:00

The Software Process and Measurement Cast 407 includes four separate columns.  We begin with a short essay refreshing the pros and cons of Test Driven Development. Test Driven Development promises a lot of benefits but all is not light, kittens and puppies. Still, TDD is well worth doing if you go into it with your eyes open.

Our second column features Kim Pries, the Software Sensei. ¬†Kim discusses what makes software ‚Äúgood.‚ÄĚ The Software Sensei puts the ‚Äúgood‚ÄĚ in quotes because it is actually a difficult word to define but Kim is willing to give the discussion a go!

In our third column, we return to Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban published J Ross (buy a copy here). We tackle Chapter 10 which is titled The Thinking Processes. Thinking processes are key to effectively using  Agile, lean and kanban processes.  

Gene Hughson anchors the cast with an entry from his Form Follows Function Blog. ¬†In this installment, we discuss the blog entry titled ‚ÄúLearning to Deal with the Inevitable.‚ÄĚ ¬†Gene and I discussed change which is inevitable and innovation which is not quite as inevitable.

Re-Read Saturday News

This week we continue our re-read of Kent Beck’s XP Explained, Second Edition with a discussion of Chapters 16 and 17.   Chapter 16 ends Section One with an interview with Brad Jensen.  Section Two addresses the philosophies of XP.  Chapter 17 tells the creation story of XP from Beck’s point of view.

We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), 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.

Use the link to XP Explained in the show notes when you buy your copy to read along to support both the blog and podcast. 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, we will feature our interview with Kupe Kupersmith. Kupe brings his refreshing take on the role of the business analyst in today’s dynamic environment.  This interview was informative, provocative and entertaining.     

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 9 (Chapters 16 ‚Äď 17)

XP Explained Cover

This week we reach a bit of transition in Kent Beck and Cynthia Andres‚Äôs Extreme Programing Explained, Second Edition (2005). A short but contextually important entry. Chapter 16 ends Section One with an interview with Brad Jensen. ¬†Section Two addresses the philosophies of XP. ¬†Chapter 17 tell the creation story of XP from Beck’s point of view.

Chapter 16: Interview
The chapter is an interview with Brad Jensen of Saber Airline Solutions that details his organization’s story of implementing and using XP. ¬†The story provides guidance, cautions and a presentation of the benefits gained from using XP.

Jensen reported that Saber experienced a substantial reduction in defects.  The reduction in defects was substantial enough to outperform the CMMI Maturity Level 5 organizations that participated in the Bengaluru (Bangalore) SPIN.

Implementing XP was not easy. ¬†Implementing XP was a slow process of establishing buy-in eventually reaching 80 – 90% penetration. He indicated that at the end of the day they had the courage to fire people who wouldn’t pair program. In essence, those that eventually couldn’t or wouldn’t make the transition were jettisoned so the organization could reap the benefits of quality and productivity.

The interview ends with Jensen’s recommendation to use XP.

Section 2: Philosophy of XP

The section of the book discusses the philosophy of XP. ¬†Over the nine chapters in this section, Beck and Andres explored applying lessons from other to accelerate the application of XP and applying XP in the varied development environments found in the today’s world.

Chapter 17: Creation Story
If you reflect, often the difference between the ideas that catch on and those that don’t is less about effectiveness and more a function of their legends or stories. The story serves to anchor the ideas and to place them in context so they can more easily be consumed. ¬†Daniel Pink, in his book Made to Stick, described how ideas can become sticky. A story that connects with the person consuming the story’s perception of the world is a ¬†major step towards making the idea stick in their mind. ¬†The XP creation story described by Beck reflects a project reality that almost everyone in software development and maintenance has experienced. ¬†The fact that we can relate predisposes developers to listen and accept the ideas that are at the core of XP.

XP was “born” on the Chrysler payroll project. Beck was called in to evaluate and later to rescue a large project that had turned into a “train wreck.” The assessment was that if the project left to continue on the current path that delivery was a pipe dream. ¬†Beck was asked to rescue the project which provided a lavatory for using XP. ¬†In the book, Beck stated, “My goal laying out the project style was to take everything I knew to be valuable about software engineering and turn the dials to 10″ this was the outline of extreme programming.” Leveraging XP helps turns the project that had begun as a train wreck into a business success. ¬†The XP creation story presents us with a version of the hero’s journey beginning where the journey started, the trials along the way, the goal that was attained and the steps to move forward after the goal has been met.

The recitation of the creation story serves multiple purposes.  First, the story makes the point that XP can scale to be used on large projects successfully.  Additionally, the creation story and the interview in Chapter 16 explicitly identifies benefits are attainable using XP which is important in order to explain the value of XP.

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

A few quick notes. We are going to read The Five Dysfunctions of a Team by Jossey-Bass .  This will be a new book for me, therefore, an initial read (I have not read this book yet), 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