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!

Project Management

Hanging Out

NOOP.NL - Jurgen Appelo - 13 hours 59 min ago
Hanging out...

This week I spent more time hangout out with people, which means less time is available for my blog. Sorry about that! (Also, I have a book to finish…)

The post Hanging Out appeared first on NOOP.NL.

Categories: Project Management

Better Management for Networked Organizations

NOOP.NL - Jurgen Appelo - 14 hours 1 min ago
Networked Organization

People are in need of different answers. They need answers to questions about how to implement better management with fewer managers. Creative networkers cannot rely on bosses to grow healthy organizations for them. They need to know how to manage things together.

I firmly believe that networked organizations own the future.

The post Better Management for Networked Organizations appeared first on NOOP.NL.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - 15 hours 52 min ago

Recipes exist to get ideas, not to be followed to the letter†

The recipe for a project is described by its Capabilities. The technical and operational requirements need to support those capabilities, but defining those up front and following them to the letter restricts the creativity of the project team, just like it restricts the creativity of the chef. 

† Epicurious web site comment on Vichyssoise recipe

Categories: Project Management

Concept of Operations First, then Capabilities, then Requirements

Herding Cats - Glen Alleman - Wed, 04/23/2014 - 13:49

The common practice of starting with requirements leads to the common complaint that  requirements change, we don't know what we want yet, our users aren't very good at defining requirements so we'll let them emerge. While these are common, they are usually a symptom of a missing piece of information.

We don't know what  capabilities  are needed and what is the Concept of Operations that those  capabilities will implement, the project as likely failed before it starts. If we do know the Capabilities and the Concept of Operations, we can then measure progress of our work effort, not in the passage or time, consumption of resources (including money), or the production of stories or  story points (which are unit-less and therefore pretty much meaningless to those paying the our work), but in   Measures of Effectiveness, Measures of Performance, and Technical Performance Measures..

Concept of Operations

Let's start with a formal defininton of the Concept of Operations

Screen Shot 2014-04-22 at 7.25.26 PM

What this tells us is that we need to start with what DONE looks like. DONE is not a set of features. DONE is not stories or story points. DONE is not modules, databases, bent metal. DONE is the ability, the capability to do something of value in echnage for the money we've spent.

The assessment of a capability is it's Measure of Effectiveness. These are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. We need to define these upfront. The Measures of Effectiveness:

  • Are stated in units meaningful to the buyer,
  • Focus on capabilities independent of any technical implementation,
  • Are connected to the mission success or fulfillment of the business case

They are not emergement. They are descriptions of success. When we treat them as emergent, our project is chasing a moving target and is headed to the ditch.

Next are Measures of Performance. They  characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. The Measures of Performance are:

  • Attributes that assure the system has the capability and capacity to perform,
  • Assessment of the system to assure it meets design requirements to satisfy the MoE.

Next comes the Technical Performance Measures. These are attributes  that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. The Technical Performance Measures:

  • Assess design progress,
  • Define compliance to performance requirements,
  • Identify technical risk,
  • Are limited to critical thresholds,
  • Include projected performance.

Notice we have not mentioned coding, development methods like Scrum or XP, teams, paired programming of anything to so with building code. With these items in place, all those activities have no reason for being, other than to consume money and pass time. None of those items having anything with moving the project toward DONE, other spend money and pass time. Oh, you'll get a pile of stories implemented. Are they the right stories? How would you know. You'll perform lots of Test Driven Design. Is is the right design. How would you know? 

Oh your customer is going to prioritize those stories and features. How are they going to know in the absence of knowing what DONE looks like.

Capabilities Based Planning

This has been presentde before, but now it has a reason - the Concept of Operations.

Capabilities based planning (v2) from Glen Alleman With the ConOps and CBP, we now have what we need to assess the development processes. 
  • What's the¬†value at risk?
  • What are the critical success factors for the project?
  • What information do we need to assess our progress to plan. We have a plan right. A strategy for showing up on or near the planned need date ar or near the planned cost.
  • What is going to prevent this project from being successful and what are we going to do about those things before they impact our success?
  • How are we going to measure¬†physical percent complete from our work effort?

We Know the Answer To That Rights?

  • Measures of Effectiveness
  • Measures of Performance
  • Technical Performance Measures


  • Passage of time
  • Consumption of money
  • Production of features
  • Absorption of hours of labor
Related articles Requirements Elicitation Calculating "Earned Value" 5 Questions That Need Answers for Project Success Elements of Project Success How Not To Develop What "Done" Look Like Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Capabilities Based Planning
Categories: Project Management

Software Development Linkopedia April 2014

From the Editor of Methods & Tools - Tue, 04/22/2014 - 15:58
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about professional software testing, managing agile requirements with features or job stories instead of user stories, integrating quality assurance and Scrum, security architecture, load testing, database normalization and UX design. Blog: Heuristics for recognizing professional testers Blog: Feature Boards Blog: Testing at Airbnb Blog: Replacing The User Story With The Job Story Article: Four Tips for Integrating Quality Assurance with Scrum Article: Security Architecture Approaches Article: Preparing for Load Testing Best ...

How Chaos Theory will influence management and management styles in the future

Software Development Today - Vasco Duarte - Tue, 04/22/2014 - 15:18

Managers all over the world are faced with a critical challenge to their role. They ideas about management and their management style is being challenged. And this is even more important because many managers have reached a position of in their career where they thought they could "take it easy". Nothing could be further from the truth.

Today the role of managers in all industries is shifting. And in no industry more than the knowledge industry.

In this video I explore why this is happening and where we may be able to look for solutions. I also present a concrete set of consequences that will affect you as a manager from the trends we are witnessing in the knowledge industry.

Do you want to know more?

Sign-up here to read a white paper I wrote about the sources of disruption for managers and management in general. In it I explore where the key threats to the current management roles are coming from.

Ready to explore what you as a manager can learn from The Science of Chaos?You came to the right place! :) Mystes in Finland organizes a workshop about Chaos Science applied to the challenges of managing small and large knowledge work organizations. You can visit their site to know more about the workshop and to sign up. Places are limited. In that workshop I will touch on the following topics:
  • Current theoretical base for managing projects
  • What is wrong with managing software projects today and why?
  • What can we learn from Chaos Theory and how to apply it in real life projects?
  • A model for a successful project using what we have learned from Chaos Theory
Do you have specific questions that intrigue you? Send them to us and we promise to address them during the workshop!

Process Improvement In A Complex World

Herding Cats - Glen Alleman - Tue, 04/22/2014 - 15:05

Much of the discussion around making improvements in processes fails to address the governance aspects of a business or organization. Instead it focuses on the personal aspects. Agile development of a software team, without the corporate impacts. The desire to stop doing something without an actual replacement, under the guise of we're exploring. Our the mention of the term intent of the commander without understanding that filling out that intent requires complete capabilities to act in in the absence of direct supervision.

My project management maturity was changed forever at Rocky Flats, under the management of senior leaders with experience and skill formed in the US Navy. The book Making the Impossible Possible is the story of that project and the learnings that can be applied in any high risk, complex, high reward domain.

Making the impossible possible from Glen Alleman The term Intent of the Commander is actualized in the concept of the Plan of the Day. Here's an actual plan of the day for shipboard life. This notion of plan of the day was applied late in the Rocky Flats program. Before that  we had Plan of the Week and then Plan of the Month. The approach is very simple. What do we plan to get done at the end of this period (day, week, month? Write that down, establish some measures of performance and effectiveness for those ourcomes. Measure them, take corrective actions if they don't match the expectations. Repeat until done. Plan of the Day
Categories: Project Management

Be Here Now

Mike Cohn's Blog - Tue, 04/22/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'm a child of the '60s, but only in the literal sense. I was born in 1962, so while I was alive during much of the excitement of that decade, I spent much of the decade playing "cowboys and Indians" and other non-politically correct games of the era. But I grew up in Southern California, and the vibe of the '60s lasted well into the '70s there. Further, I had a fair number of friends who had older brothers, some of whom I met only occasionally, but who were very much part of the hippie counterculture.

I remember one of these brothers-of-a-friend quite clearly. When I was 10 years old, he showed me a book called Be Here Now. Even then, I wanted to be a writer and this book really struck me as I paged through it. First, the book was square--books weren't supposed to be square unless they were picture books for babies. This book was for adults. At least I thought so. But it wasn't typeset like a normal book--it looked more like a poison pen letter; you know, like a ransom note with the text cut from newspaper headlines to make new words. There were drawings, but not drawings relegated to nice little boxes on the page. The drawings and the text were jumbled together.

It wasn't until I was 18 though that I actually read the book. I found a copy at my college library and read it. The New York Times called the book a "counterculture bible." And it was as common in the 1970s to see copies of that book around as it is today for programmers to have the Gang of Four patterns book.

I can't say the book's contents had any influence on me. It's a guide to Hinduism for Westerners who wish to become yogis. Not my thing. But the title of that book has always resonated with me: Be Here Now.

I think the ability to be here now is something too many of us are losing. We can't just be in the moment and in the place. Everyone has to be constantly on their cell phones, or checking email or Facebook on their laptops while supposedly making progress on something else. (I will admit to having paused once while writing this to investigate the bonk of a new email arriving. But I've so far withheld the temptation to look a second time.)

I witness the inability to be here now while training or doing consulting. I remember a particular client a couple of years ago where I was teaching a Certified ScrumMaster class. The boss had warned me that people there were busy so they'd have their laptops with them if needed. I spent much of the first day unable to make eye contact with a single person in the room. Not one person was truly in that room.

I really worry about this. I have daughters who are 14 and 18, and I often think about the work world they'll be entering. My wife and I have tried to instill in them the hippie mindset to be here now. Will others in their future companies share that? What will the short attention spans we are cultivating do to innovation? To productivity? To collaboration?

In the true spirit of the '60s, I'm going to leave this philosophical rather than trying to identify three steps agile teams can do to overcome short attention spans. I want to be no more practical than to ask each of you to be here now a bit more often, a bit longer, and a bit more intensely each day.

Connecting the Dots Between Principles and Practices of Project Success

Herding Cats - Glen Alleman - Tue, 04/22/2014 - 00:57

When we hear about all the methods of managing projects, the PMI Body of Knowledge, PRINCE2, home grown and commercial  solutions - always look at them in the light of these 5 Immutable Principles and the 5 Practices then implement the principles.

Principles and Practices of Performance-Based Project Management¬ģ from Glen Alleman
Categories: Project Management

Really, Can You Be Agile and Not Disciplined?

NOOP.NL - Jurgen Appelo - Mon, 04/21/2014 - 16:00
Agility versus Discipline

Last week, it happened again. On Facebook I posted a screenshot of the huge checklist that I use as a quality assurance gate for my book chapters. Some people commented that this looked quite disciplined.

Frankly speaking, I don’t see what’s so special about my discipline. If you want to be agile you have to be disciplined!

I don’t see how it can be any different.

The post Really, Can You Be Agile and Not Disciplined? appeared first on NOOP.NL.

Categories: Project Management

Design Your Agile Project, Part 4

If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.

That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.

In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.

Feedback is Necessary

Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”

This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.

Each team must know the principles:

  1. You need to see all the work in progress.
  2. You want to flow work through the entire team.
  3. You want to see working software, sooner, rather than later.

Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.

Now, let’s talk about what happens when you want to meld these teams into a program.

Each Team is the Heart of the Program

You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.

The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.

This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.

In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).

That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.

Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.

What If the Teams are New to Agile?

What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.

CynefinIf your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.

However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?

That is much more difficult.

Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.

You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.

Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.

When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.

They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.

What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?

Don’t panic! You work in ways to reduce your risk.

Stay tuned for Part 5.

Categories: Project Management

We Can Know the Business Value of What We Build?

Herding Cats - Glen Alleman - Sun, 04/20/2014 - 01:58

In a recent post titled #NoEstimates - Really? there was an interesting comment.

Clearly, the business value of any feature or project can not be known with much certainty in advance of it being implemented. Still, for the purpose of keeping the analysis simple for now, let’s table this issue for a bit.

This is not the case in a governance based organization or a Capabilities Based Planning organization, where the "valuation" of the resulting product, service, or purchased or built product is part of the planning process.

It's a "build to valuation"

Knowing - to some probabilistic level of confidence - what business value or mission fulfillment the project or product will produce is the core of any decision making process. Knowing the cost of the value is about making decisions, analysis of alterntaives, or assessing the trade space. 

With the "estimated" value and the "estimated" cost for that value, a decision can be made in what is called "analysis of alternatives" in our software intensive domain.

Only by having both estimates - value and  cost of acheiving  that value, their most likely numbers and the probabilistic range of those numbers (measured usually in dollars), can we make that "analysis of alternatives," or "trade space" needed to Govern both the business and the project and products that enable the business to meet its goals.


So there are popular myths around the estimating of cost and value discussion, and a few that are just flat out bogus:

  • We can't know the value of our outcomes, until they are done.
    • Start with a Balanced Scorecard strategy approach, where you define the¬†needed value of any work before starting, determine the estimated cost of achieving that value for the busines or mission and¬†do the math of ROI = (Value - Cost) / Cost.
  • No requirement can be confirmed to be correct until the software is complete and put to work.
    • Read any - my favorite The Requirements Engineering Handbook¬†- requirements management book to see if this makes any sense at all.
    • This assumes - the myth that is - that those developing the software really don't know what done looks like in any units of measure meanigful to the decision makers. Requirements definition is the role of Systems Engineering. So if the developers can't know, maybe they need to the Systems Engineers. Don't have Systems Engineers? Now that's a different problem.
    • All the Capabilities Based Planned and Requirements Management processes are based on assessing the value of those requirements¬†before the product or service arrives.
    • Assessing that value is part of all Systems Engineering process using Measures of Effectiveness and Measures of Performance.
    • During the project's execution, Technical Performance Measures and their supporting Quantifiable Backup Data are used to assue that what is being built is meeting the needs of the customer.
  • Making Estimates is a waste of time when we don;t know what the requirements are.
    • This is true.
    • But if you don't know what the requirements are, someone has to pay to find out. This someone is usually the customer. This is the basis of Agile, and it works.
      • But someone has to pay.¬†
    • Even in the realm where the requirements are vague, there is hopefully some ¬†notion of what¬†Capabilities are needed from the project or product.
    • What are you going to do with the results of the project or the product when it arrives?
    • How much are you willing to pay for those capabilities?
    • Don't have the answers to some level of confidence? - Just set fire to the money now and save all the effort.
  Related articles The "Real" Root Cause of IT Project Failure Resources for Moving Beyond the "Estimating Fallacy" 5 Questions That Need Answers for Project Success Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices
Categories: Project Management

Why Projects Fail, No Matter the Domain

Herding Cats - Glen Alleman - Fri, 04/18/2014 - 23:07

There are endless reasons for why projects fail. Some are correct, some are bogus, some are down right nonsense. Into this list I'd like at add my opinion, informed by hands on experience on software intensives programs in defense, energy, bio-pharma, commercial products, and enterprise IT.

It starts and ends, with the

Failure to know what DONE looks like in units of measure meaningful to the decision makers

The starting point for the description of DONE is the clear and concise statement of the Needed Capabilities for the resulting project that produce value for the stakeholders. These capabilities are stated in Measures of Effectiveness.

These capabilities state what the results from the project will do for the business or mission when they are available. The planned availability date is part of their capability. Only then come the requirements, then planning for the delivery of the technical and operational components that enable these requirements. Then several more enablers of projects success are needed.

All these activities, outcomes, processes, methods are encapsulated in the paradigm of Systems Engineering. The picture below are the notional elements of Systems Engineering. This picture is from the FAA Systems Engineering Handbook. This handbook is for the National Airspace System (NAS), a software intensive program to upgrade the exiting software, hardware, and processes. Other agencies and business have similar pictures.

SE Elements

  • Synthesis - Transforms requirements into physical solutions.
  • Functional Analyses - describes the functional characteristics that are used to derive the products or services of the system resulting from the project
  • Requirements Management - identifies and manages the requirements that describe the desires capabilities of the project
  • Interface Management - identifies and manages the interactions between components of the system or interactions with external systems
  • Integrated Technical Planning - Plans the projects efforts and products
  • Speciality Engineering - Analyzes the system, requirements, functions, solutions, and/or interfaces using specialized skills and tools. Assists in the derivation of requirements, synthesis of solutions, selection of alternatives, and validation and verification of requirements.
  • Integrity of Analyses - Ensures that the analyses provide the required level of fidelity and accuracy.
  • Lifecycle Engineering - Identifies and manages requirements for system lifecycle attributes, including real estate management, deployment and transition, integrated logistics support, sustainment¬†/ technology evolution, and disposal.
  • Risk Management¬†- Identifies, analyzes, and manages the uncertainties of achieving program requirements by developing strategies to reduce the severity or likelihood of those uncertainties.
  • Trade Studies - assists decision making by analyuzing selecting the best-balanced solutions to match requirements that enable the capabilities
  • Configuration Management - Establishes and maintains consistency and manages change in the system performance, functional, and physical attributes.
  • Verification and Validation - Determines if system requirements are correct. Determines that the solution meets the validated requirements.

What Does All This Mean?

When we hear our customers don't know what they want. Or, our customers don't know the target budget for the work they are asking us to do for them. What they are saying is I don't know what DONE looks like in an tangible way that can be used to measure the performance of the project.

So one of two things has to happen when this is the case...

  1. The customer has to spend money to find out what they actually want. This is done all the time on our larger enterprise, defense, and space programs. It's paying to explore. It's establishing the credibility of the capabilities by spending money to do so
  2. Prepare for project failure.

So when we here that famous - infamous actually - phrase let's explore. Ask a serious question, and demand a serious answer ...

Who's pay for us to explore to discover what we should have already know? 

Don't get an answer? Run away from that project, it's going to be a failed project.


Categories: Project Management

EVM World Coming Soon

Herding Cats - Glen Alleman - Fri, 04/18/2014 - 15:04

Speaking on Techncial Performance Measures and conducting workshop on same topic with Mr. Kranz and Tom Coonce of IDA.

Categories: Project Management

We're Asking the Wrong Question

Herding Cats - Glen Alleman - Thu, 04/17/2014 - 04:15

The right question for any suggested improvement, change, or suggesting we stop doing that need to produce an answer to ...

Does this suggestion increase the probability of project success?

This means tracing the suggestion to the outcome of the project being better, faster, cheaper, or some other tangible measure of improvement. 

What does project success look like?

The delivery of agreed-upon capability within established resource constriants, e.g. funding, schedule, facilities.

Five factors are used to assess the success

  • Capabilities - do we know what capabilities will be needed, when they'll be needed, ¬†for what cost, to meet the business plan, competitive market position, or any other assessment of success?
    • It's the capabilities that enable the customer to do¬†valuable things for their customers, themselves, or their citizens.
  • Requirements - do we know what technical and operational requirements must be in place to fulfill the needed capabilities?
    • It's the capabilty to do something of value that the customer bought.
  • Resources - what resources will be needed to deliver these capabilities, fulfilled by the requirements within the expected cost and time needed to meet the business or mission goals for the Return on Investment?
    • ROI = (Value - Cost) / Cost
    • As a business or funding agency, this ROI is a primary assessment of success.
    • Did we get what we planned to get for the money we thought we would spend on the day we thought we would? All within the expected probabilistic confidence range?
  • Execution - do we have a means of measuring progress toward producing value for the customer?
    • This value needs to be available at a point in time to meet the plan for the business or the mission
    • This time and cost of the available capabilities is an essential need for any business.
    • Without a goal such as this there is no real crticality to the project. If the project is not critical, then any approach can be viable. The probability of success is really not an interesting question to ask.

So Now What?

When we hear about something new, anything new, how can we test it that suggestion against business needs, mission needs, governance, or strategy. This starts with establishing the domain in which the suggestion might possibly work. Then proposing the framework in which it has worked or might work. Then a proposed way to assess the possible benefits of performing the sugegsted solution.

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Wed, 04/16/2014 - 12:52

Wisdom begins when we learn the difference between "that makes no sense" and "I don't understand".
Mary Doria Russell

It is that difference that is needed to assess when a idea passes the smell test. 

Categories: Project Management

Software Creativity - Jazz or Beethoven's Ninth Symphony

Herding Cats - Glen Alleman - Wed, 04/16/2014 - 01:18

Giants_of_JazzThere is a popular notion that writing software is like jazz. A loose collection of participants, improvising around a theme to produce an emergent outcome. 

These participants play off each other, react to emergent streams of melody, contribute their own special talent to the music and pretty much work in a a self directed manner over the course of the performance.

While I'm not a fan of analogies, this is a useful one for the purpose here. There are certainly domains where the Jazz analogy describes what is going on in the trio in the picture to the left.

Beethovne 9th Ode to JoyBut what about other music? Music that is just as creative, just as moving, just as impactful to the listener. Beethoven's Ninth Symphony's Ode to Joy with the poem from Friedrich Schiller 1785 work is an example.

Words that have moved nations and populations. Following Beethoven's Ninth was a movie we saw over the weekend that described this result.

In the Ninth, each performer has a score to follow, led by the conductor, but also by the concert master and the  senior players in each section. The vocals are also led by a senior performer.

In the software business there are likely similar domains and projects. Ones that can be improvised and ones that require conductors, a concert master, and players who follow the score.

In both cases - and this is where the analogy falls apart - is the players are highly skilled, experienced in the art, having played the basic themes 1,000 of times over before improvising or following the score. 

The jazz performance is not made up as it goes. OK, fusion is, but that crap makes my head hurt. Melodies, rules for cords are practiced for 10,000 hours (Gladwell), relationships between the players have magical connections not available to mere mortals. The Jazz Trio and the Berlin Philharmonic are populated with highly skilled and experienced professionals. We've all heard our children play in the school band and know what that sounds like. All the platitudes in the world about agile axioms are of no worth without the necessary capabilities to actually get the work done properly.

Applying the notion that agile software development is like jazz makes as much sense as saying I can sit in the 3rd chair of the trombone section (my high school band position) and play my contribution to Beethoven's Ninth without a Curtis Institute degree in performance and 10 years experience (my aunt was a professional pianist in the late 1950's from Curtis). 

It's not gonna happen - in both analogies - without the prerequisites of professional performance capabilities. Otherwise the result sounds like we're back in High School Music class with Mr. Meach (my teacher).

So how long will it take us to be capable performing to a level needed to not  smell like we're high school kids in the marching band? I don't know let's make an estimate.

Related articles Analogies, the Good, the Bad, and the Ugly The "Real" Root Cause of IT Project Failure
Categories: Project Management

Building a Product Users Want: From Idea to Backlog with the Vision Board

Mike Cohn's Blog - Tue, 04/15/2014 - 15:58

Many of you will know Roman Pichler as the author of Agile Product Management with Scrum. For the last few years Roman has been working on various ideas to support envisioning and ideation. I’ve asked him to write a guest post here describing his Vision Board and how it connects to Scrum’s product backlog. I’m sure you’ll find his ideas very interesting.

Vision and Backlog

Scrum is a great framework for building a product with the right features. It encourages the use of a vision shared by the product owner, the ScrumMaster, the development team, and the stakeholders, and it provides a product backlog that allows the team to move towards the vision by creating product increments.

Unfortunately, there is little guidance on how the backlog is derived from the vision. Once we have an idea for a new product or new features, how do we know which user stories we should include in the backlog? And how can we tell who should be at the sprit review meeting to help us understand if we are building the right product?






In the worst case, we could implement the wrong stories, get feedback from the wrong people, and build a product nobody wants and needs.

Four Questions

I have found it very valuable to answer the following four questions before stocking the product backlog:

  • Who are the users and customers?
  • Why would they use and buy the product?
  • What makes the product special? What are its key features?
  • What are the business goals the product should deliver and how are they met?

Without knowing who the users and customers are and why they would employ the product, it’s impossible to write meaningful user stories. Similarly, we don’t understand what should make the product special and stand out, it is difficult to make informed decisions about the product functionality, the user interaction, the UI design right, and even the key architecture and technology choices. And without being clear on the business goals and the product’s business model, it will be hard to justify the investment and attract a budget.

Enter the Vision Board

The Vision Board is a simple yet effective tool that helps agile teams capture their vision and systematically answer the four questions above. The following picture shows the Vision Board, and I explain its sections below. You can download the tool for free at:

Vision Statement is a concise summary of your idea that describes your intention and motivation.

Target Group describes the market or segment you want to address. You should state who the users and its customers are likely to be.

Needs describes the product’s value proposition: the problems and pain points the product removes, and the benefits or gains it creates for the users and the customers. The section should make it clear why people will want to use and buy your product.

Product summarises the three to five features that make your product stand out. These are likely to correlate to its unique selling proposition, and they should address the needs identified.

Value explains why it’s worthwhile for your company to invest in the product and how the business goals can be achieved. Sample goals are increase revenue, enter a new market, reduce cost, develop the brand, or gain a technological advantage.

Let’s take a look at an example to make this more concrete.

A Sample Vision Board

Say we want to create a new game for children to help them enjoy more about music and dancing and learn about the topics. Then corresponding Vision Board could look like this:

The board above captures the overarching vision. It states children aged 8-12 as the intended users of the game and their parents as the customers. It lists three reasons why the kids would want to play the game, the key features of the product, and the business goal and how the business model could work.

The good news is the Vision Board above helped me to think through the market the value proposition and the business model of the new app. The bad news is it contains lots of untested assumptions that would make it a gamble to use the board to derive the product backlog. What’s required instead is to systematically identify and validate its assumptions.

Validation with the Vision Board

Validating the Vision Board starts with identifying the most crucial assumption, the assumption that must be tested now to avoid late failure – finding out too late that the problem is not worthwhile solving. Once you have identified the appropriate assumption, decide which method is best to address it and who should be in your test group.

Some of my favourite techniques for testing Vision Board assumptions are direct observation – watching target users and customers get a job done, for instance, observing how children play music games on the computer today – and problem interviews – talking to members of the target group about how they accomplish a job today, for instance, what’s good and bad about playing computer games, particularly those related to music and dancing.











Once you have run a test, collect the relevant data and analyse it. Then use the newly gained insights to change the board either radically or incrementally. An example of the latter is to adjust a need or to replace a key feature. But a radical change – called a “pivot” in Lean Startup – profoundly affects one of more sections of the Vision Board. The vision stays true but the path towards the vision changes. For instance, changing the product to an app that teaches children dancing by encouraging them to try out the moves themselves would be a pivot for the dance game.

From Vision Board to the Product Backlog

Once you have validates the key risks and critical assumptions on the Vision Board, use it to create the initial product backlog and discover the right stories, interactions, and UI design, as the following picture illustrates.








With your initial backlog and the Scrum team in place, you are ready to start sprinting.


Before writing user stories, coming up with user interface ideas or the user interaction, make sure you understand who the users and customers are, why they would use and buy your product. Find out what makes your product special, what your business goals are, and how you can meet them. As Joel A. Barker puts it: “Vision without action is merely a dream. Action without vision just passes the time. Vision with action can change the world.” You can learn more about working with the Vision Board and download the template for free at:

What Does It Mean To Be DONE?

Herding Cats - Glen Alleman - Tue, 04/15/2014 - 05:16

There is a continuing discussion in the agile community about delivering value in the order set by the customer. Along with this discussion is the use of the word DONE. A popular phrase is no requirement or piece of software can be considered DONE until it is put to use. 

This is a software developers point of view of course. But there is another view of software based products. It starts with the Measures of Effectiveness for the resulting product. These Measures of Effectiveness are:

Operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in an operation environment, under specific conditions.

This measure of DONE is not directly related to code, testing, requirements or anything like that. It is related to how Effective the software is in delivering the capabilities needed to fulfill the mission or business case. 

The individual requirements and pieces of code that implement them can be - or should be - traceable to these capabilities. For each Measure of Effectiveness, we then need a Measure of Performance. These measures characterise:

The functional or physical attributes relating to the system's operation, measured or estimated under specific conditions.

These are also not direclty related to producing code, running tests, or other direct software activities.

All the software design, testing, integration, etc. supports the creation of the ability to produce these Measures of Performance and Effectiveness. For the end user, all the development work is behind the scenes. What the customer actually bought was the ability to do something useful. To put a capability of the software system to work accomplishing a business need. Make money with this capability of course.

So What Does All This Mean?

It means that if you start at the bottom - with the software development processes - you're likley not going to see what the real picture is. This picture is that the customer paid for capabilities, measured in units of effectiveness and performance.

When we start with methods, paradigms, even cockamamie ones like not estimating the cost of the work effort needed to produce the capabilities, we loose the connection to why we are here. We are here to produce software that provides a capability. Likely more than one capability.

So when we hear words like - we can manage projects without knowing the cost or we'll let the requirements emerge, or the customer doesn't really know what they want, so we'll get started so they can decide along the way, ask how you are going to recognize DONE, before running out of time and money? 

How Do We Discover the Needed Capabilities?

Once we've decided that capabilities are in fact the place to start, how are they gathered. Here's the top level set of activities.

Screen Shot 2014-04-14 at 10.11.34 PM

Once we have these, we can start to elicit the technical and operational requirements that will fullfill these capabilities.

Screen Shot 2014-04-14 at 10.13.03 PM

These requirements can be emergent, they can evolve, they can be elicited incrementally and iteratively. But what ever way to appear they need to have a home. They need a reason for being here. They need to enable a capability to be available to the user. 

Categories: Project Management

Help Me Promote My New FREE Book!

NOOP.NL - Jurgen Appelo - Mon, 04/14/2014 - 13:00
Stoos Sparks

The PDF version of my new book will be free. Soon!
Now that the writing of my third book is nearing completed (estimated release date of the free PDF version: 3rd week of May) it seems I will have some more time to talk about it.

Tomorrow (Tuesday) I will appear in a Stoos Sparks webinar episode, to discuss remote collaboration, together with Dawna Jones, Lisette Sutherland and Elinor Slomba

The post Help Me Promote My New FREE Book! appeared first on NOOP.NL.

Categories: Project Management