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

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.
—Mike

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: romanpichler.com/tools/vision-board/

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.

Summary

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: romanpichler.com/tools/vision-board/

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

Scrum Repair Guide Giveaway

Mike Cohn's Blog - Mon, 04/14/2014 - 03:11

Our newest venture, Front Row Agile, launched last week to bring online agile and Scrum training from the industry's leading educators to people all over the world.

To celebrate its launch, we're running a raffle to give away my newest online training, the "Scrum Repair Guide," to one winner. 

Entering the contest is simple. Head on over to the contest page at Front Row Agile to learn more. The contest starts today and ends at midnight Pacific Time this Thursday, April 17.

As part of the giveaway, I'll be donating $1 for every person who participates to the non-profit organization, Best Friends, which provides alternatives to euthanizing animals housed in shelters. 

 

 

 

 

 

 

 

 

 

 

Good luck!

Quote of the Day

Herding Cats - Glen Alleman - Sun, 04/13/2014 - 21:40

Ninety percent of everything is crud - Theodore Sturgeon

In God We Trust

Related articles Models ...
Categories: Project Management

Many Explorers Don't Make It Home

Herding Cats - Glen Alleman - Sat, 04/12/2014 - 22:15

When I hear the phrase we're exploring I'm reminded that in fact many who explore without a plan, measures of their progress progress against this plan, a risk management Plan-B for getting home when things go wrong, and without insufficient resources to survive the trip - come home empty handed or many time don't come home at all. Exploring without these items is called wandering around in the wilderness looking for something to eat. 

Here's a simple tale about an actual explorer, Ernest Shackleton, who experienced failure and near death on their first expedition to the South Pole (ADM Scott), that informed his attempt the reach the Pole a second time, only to experience failure again. In the first example prepartion was weak, management inconsistent, and lacking an actual strategy, no Plan-B. The second attempt, without Scott, was well planned, well provisioned, well staffed. When trouble started, Plan-B and then Plan-C were put in place and executed. 

  What's the Point About Managing Projects? So when we hear we're exploring and there is no destination in mind, or named problem to be solved, or even a description of possible root causes of the un-named problem, remember Shackleton's first trip and Scott's mismanagement of that exploration. On the second trip Shackleton had estimated what he would need, what route he would take, what skills his crew needed, what Plan-B would be, and even Plan-C when that didn't work, and most of all he estimated the probability of success to be high enough it was worth the risk to reach the South Pole and return to tell about it. The Polar expedition for Shackleton was a project, planned and executed with credible estimates of every step along the way, including the possibilities hat everything could go wrong and it did. Through is leadership, they lived to tell about it. Related articles Performance-Based Project Management(sm) Released Agile as a Systems Engineering Paradigm 1909 - Ernest Shackleton, leading the Nimrod Expedition to the South Pole, plants the British flag 97 miles (156 km) from the South Pole, the furthest anyone had ever reached at that time. Black Swans and "They Never Saw It Coming" 3 Impediments To Actual Improvement in the Presence of Dysfunction
Categories: Project Management

IT Governance and Decision Rights

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

GoveranceIn the discussions around #NoEstimates, it's finally dawned on me - after walking the book shelf in the office - the conversation is split across a chasm. Governance based organizations and non-governance based organizations. 

Same is the case for product development organizaitons. Those producing a software product for sale or providing a service in exchange for money. There are governance based product organizations and non-governance based product organizations. 

I can't say how those are differentiated, but there is broad research on the top of governance and business success using IT. The book on the left is a start. In this book there is a study of 300 enterprises around the world, with the following...

Companies with effective IT governance have profits that are 20% higher than other companies¬†pursuing similar strategies. One viable explanation for this differential is that IT governance¬†specifies accountabilities for IT-related business outcomes and helps companies align their IT¬†investments with their business priorities. But IT governance is a mystery to key decision makers¬†at most companies. Our research indicates that, on average, only 38% of senior managers in a¬†company know how IT is governed. Ignorance is not bliss. In our research senior management¬†awareness of IT governance processes proved to be the single best indicator of governance¬†effectiveness with top performing firms having 60, 70 or 80% of senior executives aware of how¬†IT is governed. Taking the time at senior management levels to design, implement, and¬†communicate IT governance processes is worth the trouble‚ÄĒit pays off.

IT Governance is a decision rights and accountability framework for encouraging desirable behaviours in the use of IT. And I'd add the creation of IT, IT products, and IT services. Since IT is a broad domain, let's exclude development effort for things like games, phone apps, plugins. and in general items that have low value at risk. This doesn't mean they don't have high revenue, but the investment value is low. So when they don't produce their desired beneficial outcome, the degree of loss is low as well.

Asessment of IT Governance focuses on four objectives:

  1. Cost effectiveness of IT
  2. Effective use of IT for asset utilization
  3. Effecrive use of IT for growth
  4. Effective use of IT for business flexibility

In all four, Weill and Ross provide guidance for assessing the capabilities of IT. In all four Cost is considered a critical success factor.

Without knowing the cost of a decision, the choices presented by that decision cannot be assessed. So when we hear #NoEstimates is about making decisions, ask of those decisions are being made in a governance based organization?

Then ask the question who has the decision rights to make those decisions? Who has the need to know the cost of the value produced by the firm in exchange for that cost. The developers, the management of the development team, the business management of the firm, the customers of the firm?

The three dependent variables of all projects are schedule, cost, and technical perfomance of produced capabilities (this is a wrapper word for everything NOT time and cost). The value at risk is a good starting point for deciding to apply governance processes or not. If you fix one of these variables - say budget (which is a place holder for cost until the actuals arrive), then the other two (time and technical) are now free to vary. Estimating their behaviour will be needed to assure the ROI meets the business goals. In the governance paradigm, these three dependent variables are part of the decision making process. Not knowing one of more puts at risk the value produced by the project or work effort. It's this value at risk that is the key to determining why, how, and when to estimate. 

What are you willing to loose (risk) if you don't need to know when you'll be done, or what you'll be able to produce on a planned day, or what that will cost, or determine if the ROI (return on investment), ROA (return on asset value), or ROE (return on equity) to some level of confidence to support your decision making - then estimating is a waste of time.

If on the other hand, the firm or customers you work for writing software in exchange for money have an interest in knowing any or all of those answers to support their decision making, you'll likley going to have to estimate, time, cost, produced capabilities to answer their questions.

It's not about you (the consumer of money). To find out who, follow the money, they'll tell you if they need an estimate or not.

Related articles Back To The Future Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Danger Will Robinson Some more answers to the estimating questions Capabilties Based Planning, Use Cases, and Agile The Value of Making An Estimate
Categories: Project Management

5 Questions That Need Answers for Project Success

Herding Cats - Glen Alleman - Thu, 04/10/2014 - 16:40

5 Success Questions

These 5 questions need credible answers in units of measure meanigful to the decision makers.

  1. Capabilities Based Planning starts with a Concept of Operations for each deliverable and the system as a whole. The ConOps describes how these capabilities will be used and what benefits will be produced as a result. This question is answered through Measures of Effectiveness (MOE) for each capability. MOEs are operational measures of success related to the achievement of the mission or operational objectives evaluated in an operational environment, under a specific set of conditions
  2. Technical and Operational requirements fulfill the needed capabilities. These requirements are assessed through their Measures of Performance (MOP), which characterize the physical or functional attributes relating the system operation, measured or estimated under specific conditions.
  3. The Integrated Master Plan and Integrated Master Schedule describes the increasing maturity of the project deliverables through Technical Performance Measures (TPM) to determine how well each deliverables and the resulting system elements satisfy or are expected to satisfy a technical requirement or goal in support of the MOEs and MOPs.
  4. Assessing progress to plan starts with Earned Value Management on a periodic basis. Physical Percent Complete is determine through adherence with the planned TPMs at the time of assessment and the adjustment of Earned Value (BCWP) to forecast future performance and the Estimate at Completion for cost and Estimated Completion Duration for the schedule.
  5. For each key planned deliverable and the work activities to produce it, Risks and their handling strategies are in place to adjust future performance assessment. Irreducible risks, such as duration and cost are handled with margin. Reducible risks are handled with risk retirement plans. Compliance with the risk buy down plan becomes a fifth assessment of progress to plan.

What Does All This Mean?

With these top level questions, many approaches are available, not matter what the domain or technology. But in the end if we don't have answers the probability of success will be reduced.

  1. If we don't have some idea of what DONE looks like in measures of effectiveness, then the project itself is in jeopardy from do one. The only way out is to pay money during the project to discover what DONE looks like. Agile does essentially this, but there are other ways. In all ways, knowing where we are going is mandatory. Exploring is the same as wandering around looking for a solution. If the customer is paying for this, the project is likely a R&D project. Even then the "D" part of R&D has a goal to discover something useful for those paying.
  2. When we separate capabilities based planning from requirements elicitation, we are freed up to be creative, emergent, agile, and maximize our investments. The technical and operational requirements can then be traced to the needed capabilities. This approach sets the stage for valiation of each requirement. Answering the question - why do we have this requirement? There is always mention of feature blot, this is an approach to test each requirement for its contirbution to the business or mission benefit of the project.
  3. The paradigm of Integrated Master Planning (IMP) provides the framework for assessing the increasing maturity of the project's deliverables. The IMP is the strategy for producing these deliverables along their path of increasing maturity to the final deliverables. Terms like preliminary, final, recviewed, accepted, installed, delivered, available, etc. are statements about the increasing maturity.
  4. Measuring physical percent complete, starts with the exit criteria for all packages of work on the project. This is a paradigm of agile, but more importantly it has always been the paradigm in defense and space domain. The foundation of this is Systems Engineering that is just starting to appear in enterprise IT projects.
  5. Risk Management is how adults manage projects - Tim Lister This says it all. Don't have a risk register, an assessment of the probability of occurrence, impacts, handling plans, residual risk and its impact - those risks are not going away. Each risk has to be monetized and their handling included in the budget. 

 

Categories: Project Management

You Make It Happen (I Go Where People Send Me)

NOOP.NL - Jurgen Appelo - Thu, 04/10/2014 - 08:59
management-workout-header-2

I don’t decide which countries I go to. You do.

My new one-day workshop follows an important principle:
I go where people send me.
Selecting countries and cities
Every week I get questions such as ‚ÄúWill your book tour come to Argentina?‚ÄĚ ‚ÄúWhen will you visit China?‚ÄĚ and ‚ÄúWhy are you not planning for Norway?‚ÄĚ

And every time my answer is the same: I go where people send me. The backlog of countries is based on the readers of my mailing list

The post You Make It Happen (I Go Where People Send Me) appeared first on NOOP.NL.

Categories: Project Management

Manage Your Job Search is Out; You Get the Presents

I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!

For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.

I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.

Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.

Categories: Project Management

Don't Start With Requirements Start With Capabilities

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

Lot's of myth floating around about requirements elicitation and management. Starting with requirements is not how large, complex, mission critical DOD and NASA programs work. Start with Capabilities. This cna be directly transferred to Enterprise IT.

Here's a map of the planned capabilities for an ERP system. This figure is from Performance-Based Project Management¬ģ where all the deatails of this and other principles, practices, and processes needed for project success can be found.

Here each business systems capability is outlined in the order needed to maximize the business value. In agile parlance, the customer has prioritized the deliverables. But in fact the prioritization is part of the strategic planning needed to assure that the cost investment returns the maximum value to assure the business receive maintains a positive ROI throughout the life of the project

Capabilities Map

The first step is to identify the needed capabilities. Here's the steps

Capabilities Based Planning

Only when we have the capabilities defined for each stage of the project can we start on the requirements. All the capabilities need to be identified and sequenced, otherwise we can't be assured to business goals can be met for the planned investment. With the planned capabilities, we can start on the requirements

Requirements Steps

With requirements in place for each capability, we can then start development. This is done incrementally and iterative using our favorite agile method. Doesn't mater as long an incremental delivery of value of the approach.

Categories: Project Management

Announcing FrontRowAgile.com for Video Training

Mike Cohn's Blog - Mon, 04/07/2014 - 22:14

I’m happy to announce the release of a new website, FrontRowAgile.com. FrontRowAgile.com will provide the highest quality video training on agile and Scrum.

The site launches with two courses from me and with courses from others soon to follow. In addition to hosting all my current and upcoming video courses, FrontRowAgile.com will soon feature:

  • Ken Rubin on Agile Portfolio Management
  • Ilan Goldstein on Scrum Shortcuts: Agile Tactics, Tools and Tips
  • Mitch Lacey on The Scrum Field Guide Online and Scrum for Managers
  • Pete Deemer on Distributed Scrum Primer and The Manager and Scrum

Currently, FrontRowAgile.com hosts my Agile Estimating and Planning video course plus a new course I’m happy to announce: The Scrum Repair Guide.

The Scrum Repair Guide will help you overcome some of the most common and difficult problems that ScrumMasters and their teams face.

Featuring 36 videos split into short, easily watched segments, each video addresses one topic. Watch them all or watch just the ones you’re interested in. With the same number of Emmy Award nominations as Season 8 of Game of Thrones (none so far), you’re sure to find this course informative and entertaining.

The Agile Estimating and Planning course has been a favorite since it was published on the Mountain Goat Software site. It is now available exclusively on www.FrontRowAgile.com.

In it you will find advice on sprint planning; release planning; story points vs. ideal time; fixed-date, fixed-scope, and fixed-price plans; and estimating on multi-team projects.

 

[Note: If you own a license to Agile Estimating and Planning on the Mountain Goat site, please continue logging in here and watching the course as you have been. We have plans to migrate all Mountain Goat Software video course owners to Front Row Agile as soon as we can.]

Looking to earn PDUs toward your PMI-ACP or PMP credentials? Or pursuing a Certified Scrum Professional (CSP) designation? These courses each earn you four PDUs and SEUs.

Additionally, each course will earn you a valuable certificate of completion and badges you can share on your own website, resume, or social media profiles.

 

 

 

 

 

 

 

 

 

And there’s more good news: With the move to Front Row Agile, all streaming licenses are being moved from six-month licenses to permanent licenses. That’s right—you’ll be able to watch these videos long after Doctor Who goes off the air.

And to celebrate, I’ve cut the price of Agile Estimating and Planning licenses in half. It used to be $200 for a six-month streaming license. Now it’s $100 for a permanent streaming license. The Scrum Repair Guide is available at the same price. Each of these courses offers well over 3 hours of video you can watch over and over.

If you want to watch without an Internet connection, download licenses are still available for each course. Quantity discounts are available and we have an innovative approach to company (site) licenses—email us at info@frontfrowagile and we’ll tell you more.

FrontRowAgile.com is committed to becoming the leading provider of video-based training on agile and Scrum. Sample videos from each course are available on the site.

Press Inquiries:

If you are interested in publishing a review of FrontRowAgile.com or of either course, please email us for one of a limited number of promotional licenses we are making available. Let us know which course you’re interested in reviewing and a link to where you would publish the review.

Announcing FrontRowAgile.com for Video Training

Mike Cohn's Blog - Mon, 04/07/2014 - 22:14

I’m happy to announce the release of a new website, FrontRowAgile.com. FrontRowAgile.com will provide the highest quality video training on agile and Scrum.

The site launches with two courses from me and with courses from others soon to follow. In addition to hosting all my current and upcoming video courses, FrontRowAgile.com will soon feature:

  • Ken Rubin on Agile Portfolio Management
  • Ilan Goldstein on Scrum Shortcuts: Agile Tactics, Tools and Tips
  • Mitch Lacey on The Scrum Field Guide Online and Scrum for Managers
  • Pete Deemer on Distributed Scrum Primer and The Manager and Scrum

Currently, FrontRowAgile.com hosts my Agile Estimating and Planning video course plus a new course I’m happy to announce: The Scrum Repair Guide.

The Scrum Repair Guide will help you overcome some of the most common and difficult problems that ScrumMasters and their teams face.

Featuring 36 videos split into short, easily watched segments, each video addresses one topic. Watch them all or watch just the ones you’re interested in. With the same number of Emmy Award nominations as Season 8 of Game of Thrones (none so far), you’re sure to find this course informative and entertaining.

The Agile Estimating and Planning course has been a favorite since it was published on the Mountain Goat Software site. It is now available exclusively on www.FrontRowAgile.com.

In it you will find advice on sprint planning; release planning; story points vs. ideal time; fixed-date, fixed-scope, and fixed-price plans; and estimating on multi-team projects.

 

[Note: If you own a license to Agile Estimating and Planning on the Mountain Goat site, please continue logging in here and watching the course as you have been. We have plans to migrate all Mountain Goat Software video course owners to Front Row Agile as soon as we can.]

Looking to earn PDUs toward your PMI-ACP or PMP credentials? Or pursuing a Certified Scrum Professional (CSP) designation? These courses each earn you four PDUs and SEUs.

Additionally, each course will earn you a valuable certificate of completion and badges you can share on your own website, resume, or social media profiles.

 

 

 

 

 

 

 

 

 

And there’s more good news: With the move to Front Row Agile, all streaming licenses are being moved from six-month licenses to permanent licenses. That’s right—you’ll be able to watch these videos long after Dr. Who goes off the air.

And to celebrate, I’ve cut the price of Agile Estimating and Planning licenses in half. It used to be $200 for a six-month streaming license. Now it’s $100 for a permanent streaming license. The Scrum Repair Guide is available at the same price. Each of these courses offers well over 3 hours of video you can watch over and over.

If you want to watch without an Internet connection, download licenses are still available for each course. Quantity discounts are available and we have an innovative approach to company (site) licenses—email us at info@frontfrowagile and we’ll tell you more.

FrontRowAgile.com is committed to becoming the leading provider of video-based training on agile and Scrum. Sample videos from each course are available on the site.

Press Inquiries:

If you are interested in publishing a review of FrontRowAgile.com or of either course, please email us for one of a limited number of promotional licenses we are making available. Let us know which course you’re interested in reviewing and a link to where you would publish the review.

Is There Such a Thing As Making Decisions Without Knowing the Cost?

Herding Cats - Glen Alleman - Mon, 04/07/2014 - 18:46

How Much is that DogyyExtensive research has shown given that a current project is more than fifteen percent complete, the overrun at completion will not be less than the overrun incurred to date; and the percent overrun at completion will be greater than the percent overrun incurred to date. Assuming no change in scope or reduction in delivered capabilities, this overrun is locked.

Without knowing the original Estimate At Complete (EAC), the funders of the project have no way of making decisions about the project's total cost, its  incremental cost, or how to adjust scope and duration to meet the expected cost incurred in exchange for the expected value produced from this cost. Without this cost information, and related schedule, and techncial performanc information, the notion of decision making is nonsense. 

We can't make a decision without knowing the cost and benefits of the resulting decision

The absence of an estimated cost, duration, and delivered capability prevents the business from knowing if they are making the right decision about the investment in the project. So if decision-making is what management does, not knowing this information prevents credible decisions from being made

Not estimating these three data items ‚Äď cost, schedule, and technical performance (delivered capabilities) ‚Äď is simply bad business management. What ever unfavorable outcomes ‚Äď overruns, failed business capabilities, unhappy customers (ACA the most recent example) ‚Äď is well deserved.

The notion that we can make decision in the absence of estimates of their cost and benefit, appears to be unfounded conjecture, with no evidence of its validity. 

Categories: Project Management

Software Development Mantra

From the Editor of Methods & Tools - Mon, 04/07/2014 - 14:51
We believe developers should have a particular attitude when writing code. There are actually several we‚Äôve come up with over time – all being somewhat consistent with each other but saying things a different way. The following are the ones we‚Äôve held to date:Avoid over- and under-design. Minimize complexity and rework. Never make your code worse (the Hippocratic Oath of Coding). Only degrade your code intentionally. Keep your code easy to change, robust, and safe to change.Source: ‚ÄúEssential Skills for the Agile Developer ‚Äď A Guide to Better Programming and Design‚ÄĚ, Alan Shalloway, Scott ...

Workshop Management 3.0

NOOP.NL - Jurgen Appelo - Mon, 04/07/2014 - 11:52
Workshop Management 3.0

The approach to organizing my new one-day workshops is a bit weird, I admit. That‚Äôs because I don‚Äôt care about doing things the ‚Äúnormal‚ÄĚ way. What I care about is exploring new ways to organize events. What I also care about is practicing what I preach in terms of modern management practices.

The post Workshop Management 3.0 appeared first on NOOP.NL.

Categories: Project Management

The Calculus of Writing Software for Money, Part II

Herding Cats - Glen Alleman - Sun, 04/06/2014 - 16:43

Boehm1981The dictionary definition of economics is a social science concerned with the description and analysis of production, distribution, and consumption of goods and services. [1]

Another definition of economics, closer to software developemnt is the study of how people make decisions in resource-limited situations. This definition matches the classical use of the term and is the basis of software economics. Since software product development always takes place in the presence of limited resoruces. Time, money, capabilities, even knowledge. And since software development always is the exchange of those resources for the production of value, looking at development from an economics point of view is a good start for any discussion around improving the process. 

Two other definitions are needed before continuing. Macroeconomics is the study of how people make decisions in a resource-limited situation on a national or global scale. Microeconomics is the study of how people make decisions in a resource-limited situation on an individual or organization scale. 

For software development, microeconomics deals more with the type of decision making needed for successful projects. And since much of the discussion these days is about making decisions on projects, let's see how the microeconomics paradigm may improve the communication.

There have been suggestions that the book above is old school and no longer applicable to the modern world of software development - e.g. Agile. Since the book is actually about engineering economics  not about software development methods, let's see what the book actually says for those who have not read it, heard Dr. Boehm speak, or in my case worked for the same firm where Dr. Boehm lead our process improvement management effort.

This book was a working text, when I attended USC as a Master's student while working at TRW (Boehm's home) for an Engineering Economics course. The book is still in print and available in used form for low prices. So those wishing to comment on the book, without having first read all 765 pages, can now do so at a low cost.

The preface of the book starts with the usual qualifiers, but contains three important objectives

  1. To make a book easy for students to learn from
  2. To make a book easy for professors to teach from
  3. To provide help for working professionals in the field

The major objective of the book is to provide a basis for a software engineering course, intended to be taken at the college senior or first year graduate level

So let's look at chapters to get a feel of the concepts of software engineering economics. My comments on the chapter are in italics.

  1. Chapter 1 - Case Study of the Scientific American subscription processing system.
  2. Chapter 2 - Case Study of an Urban School Attendance system
  3. Chapter 3 - Goals of Software Engineering
  4. Chapter 4 - The Software Lifecycle: Phases and Activities. This is where the book does not represent the current practice. 1980 Agile was not known. But TRW applied an iterative and incremental development process to Cobra Dane and TRDSS, two programs I participated in as a software engineer writing signal processing code in FORTRAN 77. 
  5. Chapter 5 - The Basic COCOMO Model. This model is in use today, along with SEER , QSM, Price-S, and many other software cost and schedule modeling tools. COCOMO was the first. But all are based on some sort of reference class estimating process.
  6. Chapter 6, 7, 8, and 9 - The  COCOMO Model: Development Modes,Activity Disribution, Product, and Component level 
  7. Chapter 10 - Performance Models and Cost-Effectiveness Models
  8. Chapter 11 - Production Functions: Economies of Scale
  9. Chapter 12 - Choosing Amoung Alternatives: Decision Criteria. This is where the microeconomics starts to enter the current discussion. If we intend to make decisions about how we are going to spend our customers money, we need to consider (from the chapter)
    • Minimum available budget
    • Minimum performance requirements Performance in this context is anything techncial. We have cost, schedule, and performance the three variables of all projects.
    • Maximum effectiveness / Cost Ratio
    • Maximum Effectiveness-Cost Difference
    • Composite options
    • The basis of all decision making in the software development paradigm starts and ends with cost. This is true, simply because writing software for money, costs money.
    • Value to customer, delievry dates are of course critical decision making attributes as well.
    • Knowing how much money, how that money is being utilized - efficacy of funds, how that money is time phased - absorption of funds, and the "return on investment" of those funds Starts and Stops with estimating (because we can't know for sure in the beginning and can't wait till the end) how much it will cost to deliver the needed capabilities to produce the value for the customer.¬†[2]
  10. Chapter 13 - Net Value and Marginal Analysis - another chapter on the effacay of money
  11. Chapter 14 - Present versus Future Expenditure and Income. Another microeconomics chapter on forecasting and estimating budget, performance, and value
  12. Chapter 15 - Figures of Merit - how to decide what to do, now that you have some notion of cost, schedule, performance, and risk
  13. Chapter 16 - Goals as Constraints. Some good discussion in the #NoEstimates world about contraints. Wonder if that author is famailar with this book?
  14. Chapter 17 - Systems Analysis and Constrained Optimization. The Masters degree TRW sent us to was about Systems Engineering and Systems Management. This is one of the chapter we paid close attention to.
  15. Chapter 18 - Coping with Un-reconcilable and Unquantifiable Goals. Lots of decisions deal with these two conditions. "Deciding" means performing an "Analysis of Alternatives" from a microeconomic point of view. This is course means knowing something about the three variables of all projects. One of which is cost.
  16. Chapter 19 - Coping with Uncertainties: Risk Analysis
  17. Chapter 20 - Statistical Decision Theory: The Value of Information. Much of the discussion around current "estimating" processes fails to deal with the statistical processes involved in those decision. Small samples - 5 cycles, self-selected samples, uncalibrated baselines, use of terms (bayesian) without working examples of their use - all seem to have entered the conversation. This chapter can provide insight to managing software projects using statistical processes.
  18. Chapter 21 - Seven Basic Steps in Software Cost Estimation. When it is mentioned "software can't be etimated," this chapter had better have been read and found flawed with working, reviewed examples of it not working. Conjecture is no substitute for facts.
  19. Chapter 22 - Alternative Software Cost Estimation Methods. When we hear "we're exploring for new ways to estimate" wonder if this chapter has been read?
    • Algorithmic models
    • Expert judgement
    • Estimation by analogy
    • Parkinsonian estimating
    • Price-to-Win estimating
    • Top-down estimating
    • Bottom-up estimating
    • Summary comparison of methods
    • So next time we hear "we're exploring altenative" ask straight out - "What are those alternatives, where have you had success with them compared to other methods, what domain have you had this success, and can you share the details of this success so others can asertain if they might be applicable in their domain?¬†
    • When there is no information forthcoming to these questions, think hard about the veracity of the speaker. Maybe they don't actually have a solution to this critically important problem that is still with us in 2014.
  20. Chapters 23 - 29 are about the details of the COCOMO model
  21. Chapters 30 - 33 are about software cost estimation and life-cycle management using more the COCOMO model

So What's the Point of All This?

When we hear estimating can't be done for software, we actually know better. It is being done in every software domain. Tools, processes, books, papers, conferences, vendors, professional organizations will show you how.

When we hear this, we now know better.

[1] "Software Engineering Economics," Barry W. Boehm, IEEE Transactions on Software Engineering, Volume SE-10, Number 1, Januarym 1984, pages 4-21.

[2] This is the crux of the post, the book and the discussion around the conjecture that we can make decisions about how to spend other peoples money with estimating that spend. 

Related articles 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 - Sat, 04/05/2014 - 19: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