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!

Feed aggregator

Whitepaper on Getting QA and Developers To Work Together and Upcoming Webinar

Making the Complex Simple - John Sonmez - Tue, 07/15/2014 - 16:43

Just wanted to do a short post to talk about a whitepaper I wrote for one of the companies that has been a big supporter of this blog, Zephyr, and also invite you to check out a webinar I’ll be doing next week on “How trying to learn too much may actually be hurting you–and […]

The post Whitepaper on Getting QA and Developers To Work Together and Upcoming Webinar appeared first on Simple Programmer.

Categories: Programming

The Power of Misattributed and Misquoted Quotes

Herding Cats - Glen Alleman - Tue, 07/15/2014 - 15:30

Warning this is an Opinion Piece.

In a conversation this week the quote Insanity is doing everything the same way and expecting a different outcome. Or some variant of that. Attributed to Einstein. As if attributing it to Einstein makes it somehow more credible, than attributing it to Dagwood Bumstead.

Well it turns out it is not a quote from dear olde Albert. It is also mis-attributed to Ben Franklin, Confucius, and a Chinese proverb.

The first printed record of this quote is in the 1981 Narcotics Anonymous approval version of their handbook. No other printed record is found. 

Why is this Seemingly Trival Point Important

We toss around platitudes, quotes, and similar phrases in the weak and useless attempt to establish credibility of an idea by referencing some other work. Like quoting a 34 year old software report from NATO, when only mainframes and FORTRAN 77 were used, to show the software crisis and try to convince people it's the same today. Or use un-vetted, un-reviewed, charts and graphs from an opinion piece in popular techncial magazine as the basis of statistical analysis of self-selected data

Is it world shaking news? No. Is the balanced of the universe disrupted? Hardly. 

But is shows a lack of mental discipline that leaks into the next level of thought process. It's always the little things that count, get those right and the big things follow. That is a quote from somewhere. But it also shows laziness of thought, use of platitudes in place of the hard work to solve nearly intractable problems, and all around disdain for working on those hard problems. It's a sign of our modern world - look for the fun stuff, the easy stuff, and the stuff we don't really want to be held accountable for if it goes wrong

I will use the Edwin Land quote though, that is properly attributed to him

Don't undertake a project unless it is manifestly important and nearly impossible. 

That doesn't sound like much fun, let's work on small, simple, and easy projects and tell everyone how those successful processes we developed can be scaled to the manifestly important and nearly impossible ones.

Related articles Resources for Moving Beyond the "Estimating Fallacy" How to Deal With Complexity In Software Projects? 50 Common Misquotations, but no Howard Thurman Fake quotes flood social media 31 Famous Quotations You've Been Getting Wrong 6 Famous Misquotes & Where They Came From (Mis)quoting Neil Armstrong
Categories: Project Management

Simplify Prioritization into “Now” and “Not Now”

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In this post I write about how to do this within the context of establishing a longer-term vision for a product.

Simplify Prioritization into “Now” and “Not Now”

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In next month’s newsletter, I’ll write about how to do this within the context of establishing a longer-term vision for a product.

Simplify Prioritization into “Now” and “Not Now”

Mike Cohn's Blog - Tue, 07/15/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I think I’d like to buy a big-screen plasma television. And maybe after that, a new amplifier for my home theater.

I’ve also noticed that our home dishwasher doesn’t dry as well as it used to. For some reason, this doesn’t bother my wife, Laura, but it annoys me. So I’d like to replace the dishwasher.

The clothes washer is doing fine, but the dryer isn’t working too well. I think we’ve had it 14 years, and I sometimes have to run the drying cycle three times before clothes are fully dried. So, I’ll probably want to buy a clothes dryer, too. I’ve also lately become irritated by the toaster. It’s great and works well, but bread doesn’t fit. I have to angle the bread, with part sticking out of the toaster – so, I get partially toasted bread. Or, I flip the bread midway and then get the middle of the bread overly toasted. So, add a new toaster to the list.

After all that, a new car might be nice.

What is this list? Well, my personal Things to Buy Backlog, of course. It’s a prioritized sequenced list of things I plan to buy. To facilitate long-term planning it includes everything I plan to buy for the next 12 months:

  1. Groceries
  2. Tickets to movies that haven’t been released yet
  3. A magazine that I’ll buy in Newark airport next October because I’ll find a cover story intriguing
  4. A new pair of shoes
  5. Big-screen plasma TV
  6. Home theater amplifier
  7. Dishwasher
  8. Clothes dryer
  9. Toaster
  10. Car

Don’t you have a list like this, with that level of detail? Of course not. Neither do I. We don’t make lists like this because such a list is unnecessary. In everyday life, we don’t map out the equivalent of a product backlog.

Instead, we make our purchase decisions in a much simpler fashion: “Now” or “not now.” Do I want that big television now, or not now? And this amount of prioritization is good enough.

In many cases, it is also good enough for our product development projects.

Sure, you’ll always need to know what you’re going to build this sprint. But what you build next sprint will likely depend on what the team delivers this sprint, and on how customers respond to it.

That means you might want to forgo prioritizing any further ahead unless you are in an environment that requires it, such as contract development.

Prioritizing features in a “now/not now” manner streamlines your planning process, allows learning to be incorporated into the planning process, and better matches how we prioritize outside the workplace.

Many projects will find this a very valuable shift.

In this post I write about how to do this within the context of establishing a longer-term vision for a product.

Don’t Begin UAT Until…

Software Requirements Blog - Seilevel.com - Tue, 07/15/2014 - 12:20
As projects run long and budgets get tight, the first thing that gets squeezed is testing. Even with the best of intentions, the planning, design, and development phases often go longer than expected. In order to meet that precious target rollout date, testing can get rushed. However, it is really important that testing is done […]
Categories: Requirements

Daily Stand-Up Meetings: The Most Ubiquitous Agile Practice

Preparing for a Daily Stand Up

Preparing for a Daily Stand-Up

The daily stand-up meeting easiest Agile practice to adopt and the easiest to get wrong.  In order to get it right, we need to understand the basic process and the most common variants. These include interacting with task lists/boards and distributed team members. The basic process is blindingly simple.

  1. The team gathers on a daily basis.
  2. Each team member answers three basic questions:
    1. What tasks did I complete since the last meeting;
    2. What tasks do I intend to complete before the next meeting and
    3. What are the issues blocking my progress.
  3. The meeting ends team members’ return to work OR discuss other items.

This is the barest bones version of stand-up meeting.  The meeting is typically attended by the whole team, which includes the scrum master/coach, the product owner and all other team members.  Arguably while the product owner is not a required participant based on the published Scrum guidelines, their central role makes them an important contributor to the meeting when questions about direction come up. I advise team members to discuss whether the product owner will participate (highly recommended) when they develop the Agile team charter and add participation to the team norms.

The most common process addition is the inclusion of a task list/board, either as a physical list often found on the wall of a team room or virtually through the use of a software tool. The team will use the board to guide the discussion.  The tasks they talk about should be on the wall or in the tool.  A rule that is sometimes adopted is that team members do not work on items not on the wall (or tool). The task list focuses the team and provides visual feedback as tasks change status.

You will need to add the following steps to the process when using a list or board:

  1. Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  2. Update the board or tool in as close to real time as possible.

Lists and boards can get out of sync with reality.  Out of sync tools deliver bad information and can lead to work failing through the cracks.  When tools or task list are used they must be kept up to-date. Each team member must keep his or her tasks up-to-date.  This is not the scrum master/coaches role; they not project administrators.

Distributed teams, teams where one or more team members are in a different location, present several challenges, including time zones, accents, organization affiliation and sometimes language. In general, the stand-up meeting should be basically the same, regardless of the participant’s location. What typically does change are the tools needed to make the meeting effective. Videoconference or good teleconference equipment is an absolute must, as is access to the task list (a virtual tool is useful).

You will need to add the following steps to the process when the team is distributed:

  1. Ensure that everyone on the team can see and hear each other.  This typically means securing or scheduling video or teleconferencing facilities.
  2. Ensure that all participants can see and interact with the list during the stand-up and throughout the day.
  3. Update the board or tool in as close to real time as possible.

The stand-up meeting is a simple meeting that Agile teams hold on a daily basis to plan and synchronize activities.  Adding lists and tools can make the meeting more effective by focusing team effort, BUT adding lists and tools means that the team needs to keep them up to date and use them!  If we add complications such as distributing the team, virtual tools become a necessity. I have had to ask more than one team what value they were getting from a stand-up if part of the team couldn’t hear and participate.


Categories: Process Management

Measuring Coverage at Google

Google Testing Blog - Mon, 07/14/2014 - 20:45
By Marko Ivanković, Google Zürich

Introduction
Code coverage is a very interesting metric, covered by a large body of research that reaches somewhat contradictory results. Some people think it is an extremely useful metric and that a certain percentage of coverage should be enforced on all code. Some think it is a useful tool to identify areas that need more testing but don’t necessarily trust that covered code is truly well tested. Others yet think that measuring coverage is actively harmful because it provides a false sense of security.

Our team’s mission was to collect coverage related data then develop and champion code coverage practices across Google. We designed an opt-in system where engineers could enable two different types of coverage measurements for their projects: daily and per-commit. With daily coverage, we run all tests for their project, where as with per-commit coverage we run only the tests affected by the commit. The two measurements are independent and many projects opted into both.

While we did experiment with branch, function and statement coverage, we ended up focusing mostly on statement coverage because of its relative simplicity and ease of visualization.

How we measured
Our job was made significantly easier by the wonderful Google build system whose parallelism and flexibility allowed us to simply scale our measurements to Google scale. The build system had integrated various language-specific open source coverage measurement tools like Gcov (C++), Emma / JaCoCo (Java) and Coverage.py (Python), and we provided a central system where teams could sign up for coverage measurement.

For daily whole project coverage measurements, each team was provided with a simple cronjob that would run all tests across the project’s codebase. The results of these runs were available to the teams in a centralized dashboard that displays charts showing coverage over time and allows daily / weekly / quarterly / yearly aggregations and per-language slicing. On this dashboard teams can also compare their project (or projects) with any other project, or Google as a whole.

For per-commit measurement, we hook into the Google code review process (briefly explained in this article) and display the data visually to both the commit author and the reviewers. We display the data on two levels: color coded lines right next to the color coded diff and a total aggregate number for the entire commit.


Displayed above is a screenshot of the code review tool. The green line coloring is the standard diff coloring for added lines. The orange and lighter green coloring on the line numbers is the coverage information. We use light green for covered lines, orange for non-covered lines and white for non-instrumented lines.

It’s important to note that we surface the coverage information before the commit is submitted to the codebase, because this is the time when engineers are most likely to be interested in improving it.

Results
One of the main benefits of working at Google is the scale at which we operate. We have been running the coverage measurement system for some time now and we have collected data for more than 650 different projects, spanning 100,000+ commits. We have a significant amount of data for C++, Java, Python, Go and JavaScript code.

I am happy to say that we can share some preliminary results with you today:


The chart above is the histogram of average values of measured absolute coverage across Google. The median (50th percentile) code coverage is 78%, the 75th percentile 85% and 90th percentile 90%. We believe that these numbers represent a very healthy codebase.

We have also found it very interesting that there are significant differences between languages:

C++JavaGoJavaScriptPython56.6%61.2%63.0%76.9%84.2%

The table above shows the total coverage of all analyzed code for each language, averaged over the past quarter. We believe that the large difference is due to structural, paradigm and best practice differences between languages and the more precise ability to measure coverage in certain languages.

Note that these numbers should not be interpreted as guidelines for a particular language, the aggregation method used is too simple for that. Instead this finding is simply a data point for any future research that analyzes samples from a single programming language.

The feedback from our fellow engineers was overwhelmingly positive. The most loved feature was surfacing the coverage information during code review time. This early surfacing of coverage had a statistically significant impact: our initial analysis suggests that it increased coverage by 10% (averaged across all commits).

Future work
We are aware that there are a few problems with the dataset we collected. In particular, the individual tools we use to measure coverage are not perfect. Large integration tests, end to end tests and UI tests are difficult to instrument, so large parts of code exercised by such tests can be misreported as non-covered.

We are working on improving the tools, but also analyzing the impact of unit tests, integration tests and other types of tests individually.

In addition to languages, we will also investigate other factors that might influence coverage, such as platforms and frameworks, to allow all future research to account for their effect.

We will be publishing more of our findings in the future, so stay tuned.

And if this sounds like something you would like to work on, why not apply on our job site?

Categories: Testing & QA

Bitly: Lessons Learned Building a Distributed System that Handles 6 Billion Clicks a Month

Have you ever wondered how bitly makes money? A URL shortener can’t be that hard to write, right? Sean O'Connor, Lead Application Developer at bitly, answers the how can bitly possibly make money question immediately in a talk he gave on bitly at the Bacon conference.

Writing a URL shortner that works is easy, says Sean, writing one that scales and is highly available, is not so easy.

Bitly doesn’t make money with a Shortening as a Service service, bitly makes money on an analytics product that mashes URL click data with with data they crawl from the web to help customers understand what people are paying attention to on the web. 

Analytics products began as a backend service that crawled web server logs. Logs contained data from annotated links along with cookie data to indicate where on a page a link was clicked, who clicked it, what the link was, etc. But the links all went back to the domain of the web site. The idea of making links go to a different domain than your own so that a 3rd party can do the analytics is a scary proposition, but it’s also kind of genius.

While this talk is not on bitly’s architecture, it is a thoughtful exploration on the nature of distributed systems and how you can solve bigger than one box problems with them.

Perhaps my favorite lesson from his talk is this one (my gloss):

SOA + queues + async messaging is really powerful. This approach isolates components, lets work happen concurrently, lets boxes fail independently, while still having components be easy to reason about.

I also really like his explanation for why event style messages are better than command style messages. I’ve never heard it put that way before.

Sean talks from a place of authentic experience. If you are trying to make a jump from a single box mindset to a multibox way of thinking, this talk is well worth watching. 

So let’s see what Sean has to say about distributed systems...

Stats
Categories: Architecture

The 4 Levels of Freedom For Software Developers

Making the Complex Simple - John Sonmez - Mon, 07/14/2014 - 16:00

For quite some time now I’ve been putting together, in my mind, what I think are the four distinct levels that software developers can go through in trying to gain their “freedom.” For most of my software development career, when I worked for a company, as an employee, I had the dream of someday being […]

The post The 4 Levels of Freedom For Software Developers appeared first on Simple Programmer.

Categories: Programming

Work-Life Fusion, not Work-Life Balance

NOOP.NL - Jurgen Appelo - Mon, 07/14/2014 - 14:44
Work-Life Fusion

Sometimes people ask me, “What do you mean with work-life fusion? How is that different from work-life balance?”

Well…

Work-life balance means using Twitter for your work-life and Facebook for your private life. Instead, I have friends, family, and business contacts everywhere! My 13th happy anniverselfie on Facebook was liked by 86 people, half of them were friends and family, and the other half were business contacts. I call that work-life fusion.

The post Work-Life Fusion, not Work-Life Balance appeared first on NOOP.NL.

Categories: Project Management

The Failure of Open Loop Thinking

Herding Cats - Glen Alleman - Mon, 07/14/2014 - 14:12

Screen Shot 2014-07-13 at 9.18.12 PMWhen there are charts showing an Ideal line or a chart of samples of past performance - say software delivered - in the absence of a baseline for what the performance of the work effort or duration should have been, was planned to be, or even better could have, this is called Open Loop control.

The issue of forecasting the Should, Will, Must cost problem has been around for a long time. This work continues in DOD, NASA, Heavy Construction, BioPharma, and other high risk, software intensive domains.

When we see graphs where the baseline to which the delays or cost overages are compared and those baselines are labeled Ideal, (like the chart below), it's a prime example of How to LIe With Statistics, Darrell Huff, 1954. This can be over looked in an un-refereed opinion paper in a IEEE magazine, or a self-published presentation, but a bit of homework will reveal that charts like the one below are simply bad statistics.

Screen Shot 2014-07-13 at 9.26.15 PM

This chart is now being used as the basis of several #NoEstimates presentations, which further propagates the misunderstandings of how to do statistics properly.

Todd does have other papers that are useful Context Adaptive Agility is one example from his site. But this often used and misused chart is not an example of how to properly identify problems with estimates,

Here's some core issues:

  • If we want to determine something about a statistical process, we of course need to collect data about that process. This data is empirical - much misused term itself - to show what happened over time. A time series of samples.
  • To computer a trend, we can of course draw a line through population of data, like above.
  • Then we can compare this data with some reference data to determine the variances between the reference data and the data under measurement.

Here's where the process goes in the ditch - literally.

  • The reference data has no basis of reference. It's just labeled ideal. Meaning a number that was established with no basis of estimate. Just this is what was estimated, now let's compare actuals to it and if actuals matched the estimate' let's call it ideal.
  • Was that ideal credible? Was it properly constructed? What's the confidence level of that estimate? What's the allowable variance of that estimate that can still be considered OK (within the upper and lower limites of OK)? Questions and their answers are there. It's just a line.

We can use the ne plus ultra put-down of theoretical physicist Wolfgang Pauli's "This isn't right. It's not even wrong."  As well the projects were self-selected, and like the Standish Report, self-selected statistics can be found in the How to Lie book

It's time to look at these sort of conjectures in the proper light. They are Bad Statisics, and we can't draw any conclusion from any of the data, since the baseline to which the sampled values are compared Aren't right. They're not even wrong."  We have no way of knowing why the sampled data has a variance from the ideal the bogus ideal

  • Was the original estimate simple naĂŻve?
  • Was the project poorly managed?
  • Did the project change direction and the ideal estimate never updated?
  • Were the requirements, productivity, risks, funding stability, and all the other project variables held constant, while assessing the completion date? if not the fundamental principles of experiment desgin was violated. These principles are taught in every design of experiments class in every university on the planet. Statistics for Experimenters is still on my shelf. George Box as one of the authors, whose often misused and hugely misunderstood statement all models are wrong, some are useful.

So time to stop using these charts and start looking for the Root Causes for the estimating problem.

  • No reference classes
  • No past performance
  • No parametric models
  • No skills or experience constructing credible estimates
  • No experience with estimating tools, processes, databases (and there are many for both commerical and government software intensive programs).
  • Political pressure to come up with the right number
  • Misunderstanding of the purpose of estimating - provide information to make decisions.

A colleague (former NASA cost director) has three reasons for cost, schedule, and technical shortfalls

  1. They didn't know
  2. They couldn't know
  3. They didn't want to know

Only the 2nd is a credible reason for project shortfalls in performance.

Without a credible, calibrated, statistically sound baseline, the measurements and the decisions based on those measurements are Open Loop.

You're driving your car with no feedback other than knowing you ran off the road after you ran off the road, or you arrived at your destination after you arrived at your destination.

Just like this post Control Systems - Their Misuse and Abuse

 

Related articles How to "Lie" with Statistics How to Fib With Statistics Control Systems - Their Misuse and Abuse Seven Immutable Activities of Project Success
Categories: Project Management

Software Development is Like Play Writing

Herding Cats - Glen Alleman - Sun, 07/13/2014 - 23:23

WaitingForGodotI stole this idea of this blog from Stephen Wilson's post of a similar name. And like all good borrows I've added, subtracted, and made some changes, because everything is a remix.

I don't know Stephen, but his post is provacutative. I'm assigned to a client outside my normal Defense Department and NASA comfort zone. The client needs a Release Management System integrated with a Change Control Board. Both are the basis of our defense and space software world. This client is trying to use agile, but has little in the way of the discipline needed to actually make it work.

The SWDev is like play writing is a beautiful concept that can be applied to the choas of the new client and also connected back to our process driven space and defense, which by the way makes heavy use of agile, but without all the drama of the it's all about me developer community.

Let's start here:

In both software and play writing, structure is almost entirely arbitrary. Because neither obey the laws of physics, the structure of software and plays comes from the act of composition. A good software engineer will know their composition from end to end. But another programmer can always come along and edit the work, inserting their own code as they see fit. It is received wisdom in programming that most bugs arise from imprudent changes made to old code.

It turns out of course neither of those statements is correct in the sense we may think. There is the act of composition, but that composition needs a framework in which to be developed. Otherwise we wouldn't know what we're watching or know what we're developing until it is over. And neither is actually how plays are written or software is written. It may be an act of composition, but it is not an act of spontaneous creation.

Let's start with play writing. It may be that the act of writing a play where the structure is entirely arbitrary is possible, but it's unlikely that would be a play you'd pay money to see. A Harold Pinter play may be unstructured Waiting for Gadot may be unstructured, but that's not really how plays are written. They follow a structured approach - there is a law of physics for play writing.

  • You need characters - a protagonist and the supporting cast
  • You need a setting - where are we and what's going on that supports the story
  • You need some sort of imbalance between the characters, the setting
  • You need some way to restore the imbalance or leaving it hanging
  • You need to engage your audience in some way that will resonant with the personal feelings

That's about the story of the play. To actually write a play, here's a well traveled path to success. These guidelines are for the outcome of the writing effort starting in the beginning.

  • A rough title is needed to anchor the play in the readers mind.
  • An action statement, describing what  the characters are going to do in the play, as a group, as individual. How are they going to change and who changes
  • The form of the play describing the organization of the characters, the situation, the environment. How does the play's action relate to the emotional qualities of the characters and most importantly to the audience.
  • The circumstances of the time and place of the action and other important conditions.
  • The subject as an informational platform.
  • The characters of course, describing what are the forces driving them and their relationships with each other, the circumstance, and the environment.
  • The conflict. It's boring watching a play that is boring. What are the obstacles that have to be overcome by the characters?
  • The meaning for the play. What is the point of view? What are the key thoughts for the play as a whole and the characters in the play?
  • The style of the dialogue, the composition and manner of this dialogue?
  • And finally a schedule for writing the play. When will it be done?

When we talk about writing software there is a similar story line

  • Who are the protagonist? - they're the end users of the software.
  • What is the setting? - there is a stated need for something new.
  • What is the imbalance? - something is not getting done and it needs to be improved.
  • How do we restore the balance? - by closing the gaps between the imbalance and the balance with a software solution.

The story line is the basis of Capabilities Based Planning. With the capabilities, the requirements can be elicited. From those requirements, decisions can be made for what order to deliver them to produce the best value for the business or the mission. 

This process is about decision making. And decision making uses information about the future. This future information comes many times from estimates about the future. 

 

 

 

Related articles Agile Requires Discipline, In Fact Successful Projects Require Discipline People, Process, or Tools
Categories: Project Management

SPaMCAST 298 – Brian Federici, Continuous Integration, A Practitioners

Listen to SPaMCAST 298

SPaMCAST 298 features our interview with Brian Federici.  Brian discussed continuous integration and nearly continuous delivery from a practitioner’s point of view. Continuous integration and delivery are at the heart of fast, better and higher customer satisfaction promised by Agile methods however, in many environments, continuous integration and nearly continuous delivery are still a merely interesting theory.  Brian discussed how these concepts affect how work is delivered.

Brian has been programming professionally since 2003, focusing primarily on C# and Web technologies.  He’s a big proponent of test-driven and behavior-driven development.  He has contributed to the NuGet open source project as well as created some of his own.  He is also an active member of Agile Philly, Philly .NET, Philly GameWorks, and Philly Application Lifecycle Management groups.  In his free time, he enjoys video games, drumming, tennis, and dodge ball. You can interact with Brian in many different ways!

Personal:
http://brian-federici.com
http://twitter.com/brianfederici
http://www.extra-life.org

Code:
https://bitbucket.org/mrcode
https://gist.github.com/benerdin

Groups:
http://www.agilephilly.com/
http://phillydotnet.org/
http://phillygameworks.org/
http://www.meetup.com/Philly-Application-Lifecycle-Management-User-Group/

 

Next week we will feature our essay on Systems Thinking.  Many process improvement programs falter when, despite best efforts because they don’t improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. Systems Thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather simply being influence by a single event.

 

Upcoming Events

Upcoming DCG Webinars:

July 24 11:30 EDT – The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute(ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.

 

 


Categories: Process Management

SPaMCAST 298 – Brian Federici, Continuous Integration, A Practitioners View

Software Process and Measurement Cast - Sun, 07/13/2014 - 22:00

Listen to SPaMCAST 298

SPaMCAST 298 features our interview with Brian Federici.  Brian discussed continuous integration and nearly continuous delivery from a practitioner’s point of view. Continuous integration and delivery are at the heart of fast, better and higher customer satisfaction promised by Agile methods however, in many environments, continuous integration and nearly continuous delivery are still a merely interesting theory.  Brian discussed how these concepts affect how work is delivered.

Brian has been programming professionally since 2003, focusing primarily on C# and Web technologies.  He's a big proponent of test-driven and behavior-driven development.  He has contributed to the NuGet open source project as well as created some of his own.  He is also an active member of Agile Philly, Philly .NET, Philly GameWorks, and Philly Application Lifecycle Management groups.  In his free time, he enjoys video games, drumming, tennis, and dodge ball. You can interact with Brian in many different ways!  

Personal:
http://brian-federici.com
http://twitter.com/brianfederici
http://www.extra-life.org

Code:
https://bitbucket.org/mrcode
https://gist.github.com/benerdin

Groups:
http://www.agilephilly.com/
http://phillydotnet.org/
http://phillygameworks.org/
http://www.meetup.com/Philly-Application-Lifecycle-Management-User-Group/

 

Next week we will feature our essay on Systems Thinking.  Many process improvement programs falter when, despite best efforts because they don't improve the overall performance of IT. The impact of fixing individual processes can easily get lost in the weeds, the impact overtaken by the inertia of the overall systems. Systems Thinking is a way to view the world, including organizations, from a broad perspective that includes structures, patterns, and events, rather simply being influence by a single event. 

Upcoming Events

Upcoming DCG Webinars:

July 24 11:30 EDT – The Impact of Cognitive Bias On Teams
Check these out at www.davidconsultinggroup.com

I will be attending Agile 2014 in Orlando, July 28 through August 1, 2014.  It would be great to get together with SPaMCAST listeners, let me know if you are attending.

I will be presenting at the International Conference on Software Quality and Test Management in San Diego, CA on October 1.  I have a great discount code!!!! Contact me if you are interested!

I will be presenting at the North East Quality Council 60th Conference October 21st and 22nd in Springfield, MA.

More on all of these great events in the near future! I look forward to seeing all SPaMCAST readers and listeners that attend these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute(ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.

 

Categories: Process Management

Better than something or someone or just good

Gridshore - Sun, 07/13/2014 - 15:56

Recently I saw some tweets about the possibility to finally have a website to express your hate for Eclipse. Since I am a strong believer in another tool than eclipse and I really don’t want to work with eclipse, at first I thought this was funny. Than I was checking some news posts and found a post on apple insider where they show a Samsung advertorial that bashes the iPhone battery life. Again, funny if you like samsung or you think android is better than the iPhone. Maybe even funny if you still love the iPhone.

These tweets and sources of information made me think about marketing of products, opinions of people and sometimes company strategies. As a company, do you want to prove you are better than someone else, or do you want to prove that you are really good. Personally I do not really care if I am better than someone else, I only care if I am good or maybe even superb.

Does it really work to be better than … ? Was Argentina better than the Dutch just a week a go? If not, like so many say, did it help the Dutch? Better than is an interesting concept in soccer. If your soccer teams never wins the championship, you as a fan still think they are the best. I get the same with my local soccer team, every parent thinks his kid is better than the other kids. So better than is incredibly subjective. If you say you create better software, does it sell better? What is good software? If you are into software quality you probably have a few tools to calculate the quality of software. Are you a better programmer if the lines of code you write have shorter length? Are you a better software developer if you use another tool than eclipse? I don’t really care. Use eclipse if you want to, use something else if you can afford it.

I like to make fun of people that use eclipse just like I make fun of people using linux or windows. But in the end, I don’t really care. I know people using windows or linux, working on eclipse can make better software than I can. I do not want to work for a company that tries to sell projects only by stating that they are better than someone else. I want my company to tell customers about what we are good at.

So if you are in the hating or Better than business put a hate comment on this blog, if not have a good day.

The post Better than something or someone or just good appeared first on Gridshore.

Categories: Architecture, Programming

WorldCup 2014 Retrospective: The Magic about Mindset and Leadership

Xebia Blog - Sun, 07/13/2014 - 13:56

This weekend preparing this bjohan-cruijff-hollande-1974logpost, I ran into a brilliant quote from Johan Cruijff. At a conference a few years ago for the Dutch local government, he told a great story about a talented blind golfer, Ronald Boef he played golf with.  Despite his handicap, Ronald Boef played his best golf in difficult mental circumstances like playing balls over a big pond or consistent putting. The conclusion of Johan Cruijff: "Ronald doesn’t “see" the problems, he is only focussing on the next target. He thinks from a positive mindset".   I couldn’t agree more.  In my opinion, this is one of the fundamentals behind eXtreme Manufacturing (XM) and the reason why the Dutch team didn’t made it through the WorldCup finals.

Like many consultants, topsport is an inspiring source for me.  Almost every day I show or tell stories from great sport coaches like Marc Lammers or Johan Cruijjff.   Like every major sports event, also this WorldCup in Brasil contained some interesting lessons for me I wanted to share with you.

The Big Question: You can have the best individual team members but still not be able to perform.  Why?

 3rd Place Playoff - 2014 FIFA World Cup Brazil

Top Team Ingredient #1: Mindset

The defeat of Spain against the Netherlands, the glorious win of Germany over Brazil showed having fun, faith and determination pay off and a lack of these ingredients will bring you in a lot of trouble.   Until the penalty series of the semi-finals, the right side of this recipe also worked for the Dutch squad. Now, penalty series are for no one a fun exercise, which only leaves faith and determination.   Unlike the previous penalty series against Costa Rica, the Dutch team had no faith in their keeper as a penalty-killer which directly effected the teams determination. They became more hesitant and aware of what could happen when missing a penalty.  Yes, Ronald Boef probably would have taken the penalties better than the Dutch team did against Argentina.. ;-)

Top Team Ingredient #2: Leadership

Like Johan Cruijjf stated in the same video, the leader on the pitch should be 100% concentrated on every detail and also (in my words) be the natural leader of the team, coaching them in keeping the spirit up and giving them enough room “to grow".  Despite his great qualities as a football-player, as a captain Robin van Persie was obviously not the natural leader of the team. Arjan Robben was. The natural leadership of Arjan Robben in combination with his determination was an important reason why The Netherlands were able to regain their motivation and pull off a highly respected 3rd place in this WorldCup.

In my opinion, a high performing team should always have a natural leader.  The options:

  1. A formal leader with natural leadership qualities is the perfect combination.
  2. A formal leader without natural leadership qualities but able to delegate this to another team member is also okay.
  3. A formal leader without natural leadership qualities and ignoring don’t having this competence, is bad news for the team, the team’s environment but above all, for the formal leader himself.

For the new coach van the Dutch team, Guus Hiddink, it will be a challenge convincing Robin van Persie to step back as the 1st captain after nominating Arjan Robben.  Robin van Persie should keep one thing in mind here:  no one is doubting his qualities as a top world class striker.  As a natural leader however, he is not that world class.  Trying to be one is effecting his performance as a world class striker and that would in the end be a disappointment for his supporters but above all, for Robin van Persie himself.

What does this imply for Leadership within organizations?

Leadership, especially natural leadership, is crucial for having highly motivated and productive teams.  The team stays motivated and focussed on their goal.

How ever, a lot of employees are still instrumentally “nominated” to become a coach or manager without having any leadership skills.  In my opinion, natural leadership is something you can’t gain by nomination or just by learning it.  You can improve it, but there should be some basis of natural leadership.  Ignoring this can be even counter-productive: conflicts will arise, the spirit and productivity will go down.

The Agile Team Charter Is a Team Tool

In the age of empires, kings and queens granted charters to companies.

In the age of empires, kings and queens granted charters to companies.

Project managers and developers have long been at odds with each other over deliverables like the project charter. The project management view is that the information is needed, albeit by parties outside the project team, and the project teams see their effort being siphoned off.  Generally, the charter has been considered a control document, therefore the bastion of stakeholders and project managers.  Agile techniques and the institution of the Agile team charter has changed that, however all of the parties that consumed the information from the classic charter still have information needs. There are three audience for the information in the classic charter.  Agile while still generating and sharing information provides it via different channels.

Agile teams are the primary consumer of the Agile team charter. The charter is a tool to help the team identify the project goal in their own words and then to concentrate the team’s attention specifically on that goal. Attention is an asset that is never overabundant, but is critical for any team if they are going to deliver the stories to which they have committed.  Along with direction, the charter also serves as a tool to guide the team’s behavior. The team identifies norms that establish an environment that is conductive to performance.

In the past, charters have been developed or framed by stakeholders or sponsors. Because of their authorship, it often takes on the feeling of a contract that can constrain and bind. Agile projects, and by extension Agile team charters, are flexible and dynamic to enhance the team’s ability to respond to the users and product owner needs, as they are discovered.

In many circumstances what stakeholders are looking for in the charter is a communication channel, or at the very least, a place at the table to influence and guide the project. In the past they have either written the charter or have signed off on the contents in the charter. Agile projects respect and embrace this need by providing techniques that generate involvement. Inclusion of the product owner as a direct part of the team, and the participation by a wide range of stakeholders and users in demonstrations where the team seeks approval and feedback are examples of Agile team’s recognition of the business’ place at the table. Instead of asking stakeholders to specifically define what is going to be delivered in the charter up front, Agile uses inclusion to dynamically define the projects outcome.  This ensures that as need change so do the goals of the project.

The classic project charter provides executives with an understanding of the important projects within their organizations. The need for information about strategic projects, whether Agile or any other another method, is no different. Charters are often used in organizations to authorize or approve a project; when an executive signs off on the charter it signals the beginning of a project. Authorization and notification is taken care of with one signature.  The Agile team charter is not the right tool for authorization because the charter now guides the team rather than authorizing the team. Agile organizations separate the team charter from authorization and typically develop a simple authorization form that is separate from the charter.

In the age of empires, kings and queens granted charters to companies. These charters identified the organization’s rights and obligations. Typically the charter established the governance structure for the endeavor. Today, many project charters follow in the same proud tradition. However when practicing Agile, much of the structure of classic project charters is overhead or shifted to other, more interactive techniques.  In today’s environment rarely do we need to approach projects as if we were chartering the East India Trading Company. Agile team charters work hand-in-hand with other Agile techniques like including product owner as team members and demonstrations that seek input to share information with a wider community.

 


Categories: Process Management

Quote of the Day

Herding Cats - Glen Alleman - Fri, 07/11/2014 - 23:44

Gentlemen, we have run out of money; now we have to think - Winston Churchill

The role of estimating in project and product development is many fold...

  • For product, the cost of development must recouped   over the life cycle of the product. Knowing the sunk cost of the product provides decision making information to the business if the target margin will be achieved and on what day.
  • For projects, the cost of development is part of the ROI equation. ROI = (Value - Cost) / Cost
  • For day to day business operations cash flow is the actual cost of producing outcomes. Budget is not the same as cost. We have define a budget for our work, but some forecast of the cost of that work, gathered from current operations or past performance, let's us know if we have sufficient budget.
  • For products when marginal cost exceeds marginal profit, we're going go out of business if we don't do something about controlling the cost. But our cost forecast and revenue forecast are the steering points to provide feedback for making choices.
  • For projects, the marginal cost and the marginal benefits obey the same rules of microeconomics.

In both cases the future cost and future monetized value are probabilistic numbers.

  • This project or product will cost $257,000 or less with an 80% confidence
  • This project or product will complete on or before May 2015 with a 75% confidence

With both these numbers and their Probability Distribution Function, decisions can be made about options - choices that can be made to influence the probability of project or product success.

Without this information, the microeconomics of writing software for money is not possible and the foundation of business processes abandoned.

In order to make these estimates of cost, schedule, and the technical performance of the project or product, some  model is needed and the underlying uncertainty of the elements of the model. These uncertainties come in two forms

  • Reducible (epistemic uncertainty) - money can be spent to reduce this uncertainty. Testing, prototypes, incremental development. 
  • Irreducible (aleatory uncertainty) - this is the normal variance in the process or technical components. The Deming uncertainty. The only action to reduce this uncertainty is margin, Cost margin, schedule, and technical margin. The cost margin is then part of the total project or product budget and the schedule margin part of the total period of performance for the project or the planned release date for the product.

To suggest decisions can be made without knowing this future information violates the principles of microeconomics of business 

Related articles Both Aleatory and Epistemic Uncertainty Create Risk Uncertainty is the Source of Risk Elements of Project Success More Uncertainty and Risk
Categories: Project Management

Agile Charters: More Barnacles!

The bigger the ships, the more barnacles.

The bigger the ships, the more barnacles.

As we noted in Agile Charter Barnacles, the basic Agile team charter is brief and to the point. However there is a natural tendency to add components back from classic charters.  The charter is a tool for the team, therefore the team needs to find the components that add value to how they work.  When these components add value to the team(s) doing the work adding these sections makes sense.  A number of readers of the Software Process and Measurement blog have asked about whether adding specific charter sections make sense in an Agile project or whether there are other techniques to address their needs.

  1. Roles:  Classic charters typically include a section that describes the roles that team members will play on the project team.  Agile teams are self-organizing, and roles change to ensure that the team can deliver the work they commit.  In large Agile programs, identifying areas of focus for teams is often valuable to help direct communication. Projects that are using classic project management methods with a smattering of Agile techniques will need to document roles.  However, at the team level, documenting regimented roles does not make sense for most Agile projects.
  2. Resources: Resources represent the assets that a team can draw from to deliver value and function effectively.  Resources can range from physical space to knowledge capital.  In general I only recommend identifying and documenting resources when they are outside of the norm and could be easily overlooked.  For example, I was once asked if was important to identify and document that the project team was going to use a new team room.  Since the team would tend not to forget where they worked, I suggested that they probably did not need to document the room as a resource.  While the statement sounds cynical, the discussion then turned to a discussion about who the target audience for the charter was, the team or others outside of the team.  An Agile team charter is a team-level tool, not an external communication vehicle.
  3. Context: The context for the project can be helpful for the team(s) involved in developing and delivering a solution.  In a very real sense the product owner is physical instantiation of context.  In small projects, the access of the product owner will generally suffice as a means to share context. In larger projects or programs with broad or complicated business objectives, capturing context is important.  I generally recommend in cases where capturing the narrative context is important that a separate document (this is generally not flip chart territory) is generated and that the product owner spearheads its creation.
  4. Milestones and Delivery Cadence: The Agile release plan documents the strategy that the team intends to use for delivering the project.  Release plans will identify whether functionality will be delivered to production on continuous basis, at the end of every sprint or after a number of sprints as a release. Identify the strategy the team intends to follow in the charter if it outside of the normal pattern the team follows. The release plan itself should be documented and maintained separately from the Agile team charter.
  5. Assumptions:  Assumptions are defined as things that accepted as true or certain to happen without proof.  Teams should always reflect on what they accept or believe is true that is not supported by evidence.  Assumptions that are outside of the norm need to be treated as potential blockers, captured and pursued by scrum master/coach to verify or treated as risks (documented as user stories and included in the backlog).

To add components to the Agile team charter or not to add components to the Agile team charter, that is the question. Since the Agile team charter is a tool that helps focus and guide the project teams — then the answer is add a component only if it adds value to the team.


Categories: Process Management