Listen Now

Subscribe on iTunes

The Software Process and Measurement our essay on Mind Mapping. I view Mind Mapping as a great technique to stimulate creative thinking and organize ideas. Mind Mapping is one of my favorite tools.  Note:  this essay has a lot of visual examples, while there they are explained in the reading of the essay, I have also included them in a separate document for reference. 

If you want to reference the figures/examples in the essay download this PDF.  Mind Mapping Figures

We also feature Steve Tendon’s column discussing the TameFlow methodology and Chapter 4 of his great book, Hyper-Productive Knowledge Work Performance.  Steve and I discussed the impact of management’s profound understanding of knowledge work and that understandings impact on the delivery of value.

Anchoring the cast will be Gene Hughson, returning with an entry from his Form Follows Function blog.  This week Gene discusses the ideas in his entry, “Who Needs Architects?”

Call to Action!

For the remainder of August and September let’s try something a little different.  Forget about iTunes reviews and tell a friend or a coworker about the Software Process and Measurement Cast. Let’s use word of mouth will help grow the audience for the podcast.  After all the SPaMCAST provides you with value, why keep it yourself?!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “Calling The Shot”!  Check out the new installment at Software Process and Measurement Blog.

Upcoming Events

Software Quality and Test Management
September 13 – 18, 2015
San Diego, California
http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams.  Let me know if you are attending! If you are still deciding on attending let me know because I have a discount code.

Agile Development Conference East
November 8-13, 2015
Orlando, Florida
http://adceast.techwell.com/

I will be speaking on November 12th on the topic of Agile Risk. Let me know if you are going and we will have a SPaMCAST Meetup.

Next SPaMCAST

The next Software Process and Measurement feature our interview with Julia Wester.  Julia is an Improvement Coach at LeanKit and writes the Every Kanban Blog.  Julia and I had wide ranging conversation that included both process improvement and the role of management in Agile. Julia’s opinion is that management can play a constructive role in helping Agile teams deliver the most value.

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

The Mythical Man-Month

The Mythical Man-Month

In the seventh essay of The Mythical Man-Month, Fred P. Brooks begins to tackle the concept of estimating. While there are many estimating techniques, Brooks’ approach is a history/data-based approach, which we would understand as today as parametric estimation. Parametric estimation is generally a technique that generates a prediction of the effort needed to deliver a project based on historical data of productivity, staffing and quality. Estimating is not a straightforward extrapolation of has happened in the past to what will happen in the future, and mistaking it as such is fraught with potential issues. Brooks identified two potentially significant estimating errors that can occur when you use the past to predict the future without interpretation.

Often the only data available is the information about one part of the project’s life cycle. The first issue Brooks identified was that you cannot estimate the entire job or project by just estimating the coding and inferring the rest. There are many variables that might affect the relationship between development and testing. For example, some changes can impact more of the code than others, requiring more or less regression testing. The link between the effort required to deliver different types of work is not linear. The ability to estimate based on history requires a knowledge of project specific practices and attributes including competency, complexity and technical constraints.

Not all projects are the same. The second issue Brooks identified was that one type of project is not applicable for predicting another. Brooks used the differences between small projects and programming systems products to illustrate his point. Each type of work requires different activities, not just scaled up versions of the same tasks. Similarly, consider the differences in the tasks and activities required for building a smart phone app compared to building a large data warehouse application. Simply put, they are radically different. Brooks drove the point home using the analogy of extrapolating the record time for 100-yard dash (9.07 seconds according to Wikipedia) to the time to run a mile. The linear extrapolation would mean that a mile could be run in 2.40 (ish) minutes (a mile is 1760 yards) the current record is 3.43.13.

A significant portion of this essay is a review of a number of studies that illustrated the relationship between work done and the estimate. Brooks used these studies to highlight different factors that could impact the ability to extrapolate what has happened in the past to an estimate of the future (note: I infer from the descriptions that these studies dealt with the issue of completeness and relevance. The surveys, listed by  the person that generated the data, and the conclusions we can draw from an understanding of the data included:

  1. Charles Portman’s Data – Slippages occurred primarily because only half the time available was productive. Unrelated jobs meetings, paperwork, downtime, vacations and other non-productive tasks used the remainder.
  2. Joel Aron’s Data – Productivity was negatively related to the number of interactions among programmers. As the number of interactions goes up, productivity goes down.
  3. John Harr’s Data- The variation between estimates and actuals tend to be affected by the size of workgroups, length of time and number of modules. Complexity of the program being worked on could also be a contributor.
  4. OS/360 Data- Confirmed the striking differences in productivity driven by the complexity and difficulty of the task.
  5. Corbatoó’s Data – Programming languages affect productivity. Higher-level languages are more productive. Said a little differently, writing a function in Ruby on Rails requires less time than writing the same function in macro assembler language.

I believe that the surveys and data discussed are less important that the statistical recognition that there are many factors that must be addressed when trying to predict the future. In the end, estimation requires relevant historical data regardless of method, but the data must be relevant. Relevance is short hand for accounting for the factors that affect the type work you are doing. In homogeneous environments, complexity and language may not be as big a determinant of productivity as the number of interactions driven by team size or the amount of non-productive time teams have to absorb. The problem with historical data is that gathering the data requires effort, time and/or money.  The need to expend resources to generate, collect or purchase historical data is often used as a bugaboo to resist collecting the data and as a tool to avoid using parametric or historical estimating techniques.

Recognize that the the term historical data should not scare you away.  Historical data can be as simple as a Scrum team collecting their velocity or productivity every sprint and using it to calculate an average for planning and estimating. Historical data can be as complex as a pallet of information including project effort, size, duration, team capabilities and project context.

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

Why did the Tower of Babel fall?

A hybrid

A hybrid

Being Agile is a lot easier than it was even a few years ago. However, there are still roadblocks; including lack of management buy in, not changing the whole development life cycle or and only vaguely considering technical Agile practices. The discussions I have had with colleagues, readers of blog and a professor at Penn State about roadblock have generated a lot passion over the relative value and usefulness of hybrids.

Classic software development techniques are a cascade beginning with requirements definition and ending with implementation. The work moves through that cascade in a manner similar to an auto assembly line. The product is not functional until it rolls off the end of the line. The model uses specialized labor doing specific tasks over and over. Henry Ford changed the automotive market with this technique.  However, applying this model to software development can cause all sorts of bad behaviors. Those bad behaviors are generally caused by a mismatch between linear work like manufacturing and work that is more dynamic and more oriented to research and development. One example of a bad behavior the abuse of stage gates. Often teams continue working even when the method indicates they must wait for a stage gate decision. The problem is that if they wait for a decision they will never complete on time. Managers are ALWAYS aware what is happening, but choose to not ask. It generally is not because anyone in the process is a bad player, but rather that the process is corrupt.

Agile is different. Agile stops the cascade by breaking work into smaller chunks. Those smaller pieces are then designed, developed, tested and delivered using short sprints (known as cadence) in order to generate immediate feedback. The “new” process takes the reason for running stage gate stop signs away.

Hybrid models attempt to harvest the best pieces from the classic and Agile frameworks to fit the current organizational culture or structure. The process of making the Agile (or classic methods for that matter) fit into an organization optimized for classic methods is where issues generally creep in. The compromises required often stray from the assumptions of built into the Agile values and principles.  Examples of the assumptions built into Agile include stable teams, self management and delivering functional software at the end of every sprint. It is easier to wander away from those values and principles than to tackle changing the organization’s culture or structure. One of the most common (and damaging) compromises can be seen in organizations that continue the practice of leveraging dynamically staffed teams (often called matrix organizations). Stable teams often require rearranging organizational boundaries and a closer assessment of capabilities.

Typical organizational problems that if not addressed will lead organizations to generate classic/Agile hybrids include:

  1. Silos: Boundaries between groups require higher levels of planning and coordination to ensure the right people are available at the right time even when there are delays. Historically, large development organizations have included the role of scheduler/expediter in their organization chart to deal with these types of issues.
  2. Overly Lean: Many development organizations have suffered through years of cost cutting and have far fewer people than needed to complete the work they have committed to accomplishing. Personnel actively work on several projects at once to give the appearance of progress across a wide range of enterprises. Switching between tasks is highly inefficient which reduces the overall value delivered, often leading to more cost cutting pressure.
  3. Lack of Focus: Leaders in development organizations often feel the need to accept and start all projects that are presented. Anthony Mersino calls this the “say yes to everything syndrome.” This typically occurs in organizations without strong portfolio management in place. Ultimately, this means that people and teams need to multitask, leading to inefficiency.
  4. Lack of Automation: While I have never met a development practice that couldn’t be done on a small scale using pencil and paper, automation makes scale possible. For example, consider running several thousand regression tests by hand. In order to run the tests you would either need a significant duration or lots of people. Lots of people generally means more teams, more team boundaries, more hierarchy and more overhead – leading to the possibility of just running less tests to meet a date or budget.

The values and principles that underpin Agile really matter. They guide behavior so that it is more focused on delivering value quickly. The four values in the Agile Manifesto are presented as couplets. For example, in the first value: “Individuals and interactions over processes and tools,” the items on left side are valued more than those on the right (even though those on the right still have value). Hybrid models often generate compromises that shift focus from the attributes on the left more toward the center and perhaps back to those attributes on the right. Hybrids are not evil or bad, but they are generally cop-outs if they wander away from basic Agile values and principles rather than addressing tough organizational issues.

Agree or disagree, your thoughts are important to guiding the conversation about what is and isn’t Agile.

Being Agile is more than just Scrum or not being waterfall.

Being Agile is more than just Scrum or not being waterfall.

If you were a developer from the 1980s or early 1990’s and traveled in time to attend most Agile conferences today, you would probably take away the idea that Agile was all about Scrum and kicking sand at project managers. Unfortunately MANY organizations have same stilted perception. The perception that Agile is just another form of project management is EXACTLY wrong. If an organization only embraces the parts of Agile that address team organization and project control they are not truly Agile. In order to deliver the most value from adopting and embracing Agile, organizations and teams must understand and adopt Agile technical practices. Just doing Scrum is not going to cut it if your goal is improving the quantity and quality of functional software you deliver.

Tools, processes and techniques that facilitate the development, testing and implementation of functional software are technical practices. A very abridged list of technical practices includes:

  • User Stories
  • Story Mapping
  • Test Driven Development (including variants such as Behavior Driven Development)
  • Architecture
  • Technical Standards (including Coding Standards)
  • Refactoring
  • Automated Testing
  • Pair Programming
  • Continuous Integration

Implementing a combination of Scrum with Extreme Programming (xP) is one of the most common methods of addressing both the technical and management/control aspects of delivering functional software. xP is an Agile software development methodology originally conceived by Kent Beck and others in late 1990’s. There are many other techniques, frameworks and methodologies that support the technical side of Agile. These techniques directly impact how effectively and efficiently solutions are designed, coded and tested. As importantly efficiency directly impacts the amount of value that is possible to deliver.

You Are Not Agile . . . If You Do Waterfall described some of the attributes of organizations that get stuck transitioning to Agile from a process point of view. Similarly, many organizations begin an Agile transition by adopting Scrum perhaps with a few techniques such as User Stories; however, they never quite get to addressing the technical components. The issues of the business analysts, developers and testers don’t get addressed.

Allan Kelly, in an interview on the Software Process and Measurement Cast 353, stated that if you are not “doing” the technical side of Agile, you were not Agile. This statement is probably somewhat of a harsh assessment and perhaps a bit hyperbolic, but only a bit. Developing, enhancing and maintaining software (or any product) requires more than short iterations, stand-ups, retrospectives and demonstrations. Far be it from me to say those techniques don’t help and even alone are certainly better than most waterfall practices, but they do not address the nuts and bolts of developing software.  In order to deliver the maximum value we have to change how we are developing designs, writing code and then proving that it works because that is the true heart and soul of software development.

In the long run Agile has to address management buy in, changing the whole development life cycle or and the technical practices, or you won’t get the whole value that Agile can deliver.

I would be interested in your thoughts!

 www.spamcast.net

                             www.spamcast.net

Listen Now

Subscribe on iTunes

The next Software Process and Measurement features our interview with Steve Turner.  Steve and I talked time management and email inbox tyranny! If you let your inbox and interruptions manage your day you will deliver less value than you should and feel far less in control than you could!

Steve’s Bio:

With a background in technology and nearly 30 years of business expertise, Steve has spent the last eight years sharing technology and time management tools, techniques and tips with thousands of professionals across the country.  His speaking, training and coaching has helped many organizations increase the productivity of their employees. Steve has significant experience working with independent sales and marketing agencies. His proven ability to leverage technology (including desktops, laptops and mobile devices) is of great value to anyone in need of greater sales and/or productivity results. TurnerTime℠ is time management tools, techniques and tips to effectively manage e-mails, tasks and projects.

Contact Information:
Email: steve@getturnertime.com
Web: www.GetTurnerTime.com

 

Call to Action!

For the remainder of August and September let’s try something a little different.  Forget about iTunes reviews and tell a friend or a coworker about the Software Process and Measurement Cast. Let’s use word of mouth will help grow the audience for the podcast.  After all the SPaMCAST provides you with value, why keep it yourself?!

Re-Read Saturday News

Remember that the Re-Read Saturday of The Mythical Man-Month is in full swing.  This week we tackle the essay titled “Why Did the Tower Babel Fall”!  Check out the new installment at Software Process and Measurement Blog.

 

Upcoming Events

Software Quality and Test Management
September 13 – 18, 2015
San Diego, California
http://qualitymanagementconference.com/

I will be speaking on the impact of cognitive biases on teams.  Let me know if you are attending! If you are still deciding on attending let me know because I have a discount code.

Agile Development Conference East
November 8-13, 2015
Orlando, Florida
http://adceast.techwell.com/

I will be speaking on November 12th on the topic of Agile Risk. Let me know if you are going and we will have a SPaMCAST Meetup.

Next SPaMCAST

The next Software Process and Measurement feature our essay on mind mapping.  To quote Tony Buzan, Mind Mapping is a technique for radiant thinking.  I view it as a technique to stimulate creative thinking and organize ideas. I think that is what Tony meant by radiant thinking. Mind Mapping is one of my favorite tools.

We will also feature Steve Tendon’s column discussing the TameFlow methodology and his great new book, Hyper-Productive Knowledge Work Performance.

Anchoring the cast will be Gene Hughson returning with an entry from his Form Follows Function blog.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here. Available in English and Chinese.

The Mythical Man-Month

The Mythical Man-Month

In the seventh essay of The Mythical Man-Month, Brooks returns to the topics of organization and communication using story of the Tower of Babel as a metaphor for many of the engineering fiascoes seen in software development. In the story of the Tower of Babel, when communication broke down, coordination failed and the project ground to a halt. As projects become larger and more complex, communication and organization always becomes more difficult and more critical.

The essay Why Did the Tower of Babel Fall? presents three mechanisms to facilitate communication.

  1. Informal Communication, which includes all of the telephone calls and conversations that occur in and among teams. Healthy teams and teams of teams talk, interact and share information and ideas.
  2. Meetings are more formal and include reviews, technical briefings, demonstrations, sprint planning and release planning events. Done well formal meetings, whether part of an Agile framework or not, can find problems and share information and knowledge.
  3. Project Workbooks are the repository of the evolving intellectual property that defines any significant endeavor.

Brooks goes into depth on the definition and structure of the project workbook. While the workbook that Brooks describes is a physical construct we should consider that the idea of workbook is less of a document then a structure for grouping information. All the project documents need to fit into the workbook and be part of the overall structure of project information so that it can be reused and inherited from. The ultimate goal of the workbook is ensure that everyone who needs information has access to the information and gets the information.

Workbook Mechanics: In order to meet the goal of ensuring of everyone access to the information they need, the workbook needs to be maintained and organized. For example, Brooks suggests ordering and numbering all project memorandums (we would call these emails now) so that people can look through the list and actually see if they need information. Brooks points out that as size of the effort, project or program goes up, the complexity of maintaining and indexing the project communications increases in a non-linear fashion. Today’s technical tools like wikis, SharePoint and hypertext markup make curating and sharing information easier than paper and microfiche (if microfiche is before your time, Google it). As a reminder, capturing and reusing IP is required in all types of work. As a coder, it is easy to fall prey to the idea that the code and a functional system is the only documentation required; however, this is false. For most large efforts, capturing decisions, designs, architectures and even the occasional user manual is an option that can be ignored only if you want to court a communication failure. Remember however that over-reliance on documentation is not the goal.

Brooks uses the formula (n2-n)/2, where n is the number of people working on an effort, to define the possible communication interfaces. As the number of people increase the number of interfaces increases very quickly. Organization is a tool to reduce the amount of interfaces. This is one of the reasons why small teams are more effective than large teams. Scaling Agile is often accomplished by assembling teams of small teams. We use the metaphor of trees or flowers are often to describe the visualizations of team of teams. Communications spreading from a central point can look like a tree or flower. Organizations leverage techniques like the specialization and division of labor to reduce the number of communication interfaces.

There is often push back on division of labor and specialization in Agile. This push back is often misplaced. Within a team the concept of T Shaped people, which eschews specialization, increases capabilities; however, teams often specialize thus becoming capability teams. Capability teams often tackle specific types of work more effectively and efficiently by reducing learning curves. Capability teams fit into Brooks’ ideas on organizing to reduce the communication overhead.

Brooks proposes that each grouping of work have six essential needs.

  1. A Mission,
  2. A Producer,
  3. A Technical Director or An Architect,
  4. A Schedule,
  5. A Division of Labor, and
  6. Interface Definitions Among the Parts.

Four of these essentials are easily understood; however, the roles of the producer and technical broke new ground and extended the ideas Brooks began in The Surgical Team. The role of the producer is to establish the team, establish the schedule and continually acquire the resources needed to deliver the project. The role of the producer includes many of the classic project and program management activities, but also much of the outside communication and coordination activities. When small effort with a single team the roles of the producer and technical director can be held by the same person. As efforts become larger and more complex the roles are generally held by separate people. The role of the producer in the Scaled Agile Framework (SAFe) is handled by the Release Train Engineer. The technical director focuses on the design and the technical components (inside focus). In SAFe this role is held by the System Architect.

Brooks leverages the metaphor of the Tower of Babel to focus on the need for communication and coordination. Projects, team and organizations need to take steps to ensure communication happens effectively. Techniques like meetings and project workbooks are merely tools to make sure information is available and organized. Once we have information organization provides a framework to ensure information is communicated effectively. Without communication any significant engineering effort will end up just like the Tower of Babel.

Are there other mechanisms for organization, communication and coordination that have worked for you? Please share and lets discuss!

Previous installments of the Re-read of The Mythical Man-Month

Introductions and The Tar Pit

The Mythical Man-Month (The Essay)

The Surgical Team

Aristocracy, Democracy and System Design

The Second-System Effect

Passing the Word

The spiral method is just one example of a Agile hybrid.

The spiral method is just one example of a Agile hybrid.

Many organizations have self-titled themselves as Agile. Who wouldn’t want to be Agile? If you are not Agile, aren’t you by definition clumsy, slow or dull? Very few organizations would sign up for those descriptions; however, Agile in the world of software development, enhancements and maintenance means more than being able to move quickly and easily. Agile means that a team or organization has embraced a set of principles that shape behaviors and lead to the adoption of a set of techniques. When there is a disconnect between the Agile walk and the Agile talk, management is often a barrier when it comes to principles and practitioners are when it comes to techniques. Techniques are often deeply entrenched and require substantial change efforts. Many organizations state they are using a hybrid approach to Agile to transition from a more classic approach to some combination of Scrum, Kanban and Extreme Programming. This is considered a safe, conservative approach that allows an organization to change organically. The problem is that this tactic rarely works and often organizations get stuck. Failure to spend the time and effort on change management often leads to hybrids frameworks that are neither fish nor fowl.  Those neither fish nor fowl frameworks are rarely Agile. Attributes of stuck (or potentially stuck) organizations are:

The iterative waterfall. The classic iterative waterfall traces its roots to the Boehem Spiral Model. In the faux Agile version of iterative development, short, time-boxed iterations are used for each of the classic waterfall phase. A requirements sprint is followed by a design sprint, then a development sprint and you know the rest. Both the classic spiral model or the faux Agile version are generally significantly better than the classic waterfall model for generating feedback and delivering value faster; therefore, organizations stop moving toward Agile and reap the partial rewards.

Upfront requirements. In this hybrid approach to Agile, a team or organization will gather all of the requirements (sometimes called features) at the beginning of the project and then have them locked down before beginning “work.” Agile is based on a number of assumptions about requirements. Two key assumptions are that requirements are emergent, and that once known, requirements decay over time. Locking product backlogs flies in the face of both of these assumptions, which puts teams and organizations back into the age of building solutions that when delivered don’t meet the current business needs. This approach is typically caused when the Agile rollout is done using a staggered approach beginning with the developers and then later reaching out to the business analysts and business. the interface between groups who have embraced Agile and those that  have not often generates additional friction, often blamed on Agile making further change difficult.

Testing after development is “done.” One of the most pernicious Agile hybrids is testing the sprint after development is complete. I have heard this hybrid called “development+1 sprint.” In this scenario a team will generate a solution (functional code if this is a software problem), demo it to customers, and declare it to be done, and THEN throw it over the wall to testers. Testers will ALWAYS find defects, which requires them to throw the software back over the wall either to be worked on, disrupting the current development sprint, or to be put on the backlog to be addressed later. Agile principles espouse the delivery of shippable software (or at least potentially shippable) at the end of every sprint. Shippable means TESTED. Two slightly less pernicious variants of this problem are the use of hardening sprints or doing all of the testing at the end of the project. At least in those cases you are not pretending to be Agile.

How people work is the only cut and dry indicator of whether an organization is Agile or not. Sometimes how people work is reflection of a transition; however, without a great deal of evidence that the transition is moving along with alacrity, I assume they are or will soon be stuck. When a team or organization adopts Agile, pick a project and have everyone involved with that project adopt Agile at the same time, across the whole flow of work. If that means you have to coach one whole project or team at a time, so be it. Think of it as an approach that slices the onion, addressing each layer at the same time rather than peeling it layer by layer.

One final note: Getting stuck in most of these hybrids is probably better than the method(s) that was being used before. This essay should not be read as an indictment of people wrestling with adopting Agile, but rather as a prod to continue to move forward.

Follow

Get every new post delivered to your Inbox.

Join 4,590 other followers