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

Book of the Month

Herding Cats - Glen Alleman - Mon, 04/10/2017 - 16:41

Short Term ForecastingI've been working in the probabilistic estimating business for a decade or two. 

One of the seminal books that started it all is Short-Term Forecasting. This is the basis of Box-Jenkins and Mr. Jenkins quote that is universally misquoted by most people in the Agile community.

All Models are Wrong, Some Models are  Useful

As well - of course - is the nonsense that Forecasts are not estimates, popularized by #NoEstimates advocates.

The Box-Jenkins modeling process expands to the ARIMA (Auto-Regression Integrated Moving Average) models we use for cost and schedule models. This approach makes use of past performance to forecast future outcomes. This empirical method is used nearly universally for forecast time series in the past for outcomes in the future. From stock markets to Estimates to Complete and Estimates at Completion. In our domain, we archive all the performance numbers and then compare them against the planned performance models. This is then used to make adjustments to the Plan or the Estimate from the Root Cause of the variance.

This is called Close Loop Control, and that works on all domains where stochastic process underly the work process, from software development, to process control, to flight control systems, the natural systems.

Related articles The Flaw of Empirical Data Used to Make Decisions About the Future Do The Math Humpty Dumpty and #NoEstimates The Flaw of Averages and Not Estimating Herding Cats: Median, Mean, Mode without Variance is Worthless Doing the Math Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Deadlines Always Matter
Categories: Project Management

Book of the Month

Herding Cats - Glen Alleman - Mon, 04/10/2017 - 16:41

Short Term ForecastingI've been working in the probabilistic estimating business for a decade or two. 

One of the seminal books that started it all is Short-Term Forecasting. This is the basis of Box-Jenkins and Mr. Jenkins quote that is universally misquoted by most people in the Agile community.

All Models are Wrong, Some Models are  Useful

As well - of course - is the nonsense that Forecasts are not estimates, popularized by #NoEstimates advocates.

The Box-Jenkins modeling process expands to the ARIMA (Auto-Regression Integrated Moving Average) models we use for cost and schedule models. This approach makes use of past performance to forecast future outcomes. This empirical method is used nearly universally for forecast time series in the past for outcomes in the future. From stock markets to Estimates to Complete and Estimates at Completion. In our domain, we archive all the performance numbers and then compare them against the planned performance models. This is then used to make adjustments to the Plan or the Estimate from the Root Cause of the variance.

This is called Close Loop Control, and that works on all domains where stochastic process underly the work process, from software development, to process control, to flight control systems, the natural systems.

Related articles The Flaw of Empirical Data Used to Make Decisions About the Future Do The Math Humpty Dumpty and #NoEstimates The Flaw of Averages and Not Estimating Herding Cats: Median, Mean, Mode without Variance is Worthless Doing the Math Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Deadlines Always Matter
Categories: Project Management

Median, Mean, Mode without Variance is Worthless

Herding Cats - Glen Alleman - Sun, 04/09/2017 - 16:54

Just had a conversation of sorts where it was stated, I look at the median EQF of a portfolio as one gauge of the quality of the overall underlying data. The problem is without the variances of any single point metric, that metric is pretty much worthless.

Here's a little exercise we use at conferences and training sessions.

  • I'm going to send you on a mission to determine the Mode of a measurement. You'll get a clipboard, a hat, a folding chair, and a few other items. You'll go to two locations for 365 days and record the high temperature of the day.¬†
  • Let's start with Trinidad-Tobago. You've got your clipboard, a nice folding chair sitting on the beach, a good sun hat and sunscreen.¬†
  • Next, you'll go to Cody Wyoming, just north of my home and do the same thing

Now let's look at the Mode of those numbers. Why the Mode. It's the most recurring value in a time series. This is what we use when modeling - Estimating - variables in project planning. The Mode of a Task's work duration is the Most Likely value drawn from a sample of possible values in the Probability Distribution Function. It is the value that occurs most often in the Task's life. If we have a similar Task - through a Reference Class Forecasting process, we want to use the Mode of the duration. Not the Mean (average) or the Median (the middle most). The Mode is what the Task will take most of the time.

So now let's look at the data.

  • For Trinidad-Tobago, the number that occurs¬†most often across the 365 days of sitting in your chair writing down numbers is 84¬į F
  • In Cody Wyoming, the number that occurs¬†most often in the 365 days is - wait for it - 84¬įF

Now, these are the Mode numbers. The Most Likely To Occur. For temperatures, this is a bit of a stretch because temperatures are driven by a periodic cycle of seasons and weather.

But for task durations, this is a legitimate starting point for estimating. What is the most likley duration for this work? Without the variance on the Mode or the Mean, the Median is the middlemost number, there can be no confidence you wouldn't freeze to death in February if you go to Wyoming in your shorts and teeshirt

Related articles How to Avoid the "Yesterday's Weather" Estimating Problem Want To Learn How To Estimate? Capabilities Based Planning
Categories: Project Management

Median, Mean, Mode without Variance is Worthless

Herding Cats - Glen Alleman - Sun, 04/09/2017 - 16:54

Just had a conversation of sorts where it was stated, I look at the median EQF of a portfolio as one gauge of the quality of the overall underlying data. The problem is without the variances of any single point metric, that metric is pretty much worthless.

Here's a little exercise we use at conferences and training sessions.

  • I'm going to send you on a mission to determine the Mode of a measurement. You'll get a clipboard, a hat, a folding chair, and a few other items. You'll go to two locations for 365 days and record the high temperature of the day.¬†
  • Let's start with Trinidad-Tobago. You've got your clipboard, a nice folding chair sitting on the beach, a good sun hat and sunscreen.¬†
  • Next, you'll go to Cody Wyoming, just north of my home and do the same thing

Now let's look at the Mode of those numbers. Why the Mode. It's the most recurring value in a time series. This is what we use when modeling - Estimating - variables in project planning. The Mode of a Task's work duration is the Most Likely value drawn from a sample of possible values in the Probability Distribution Function. It is the value that occurs most often in the Task's life. If we have a similar Task - through a Reference Class Forecasting process, we want to use the Mode of the duration. Not the Mean (average) or the Median (the middle most). The Mode is what the Task will take most of the time.

So now let's look at the data.

  • For Trinidad-Tobago, the number that occurs¬†most often across the 365 days of sitting in your chair writing down numbers is 84¬į F
  • In Cody Wyoming, the number that occurs¬†most often in the 365 days is - wait for it - 84¬įF

Now, these are the Mode numbers. The Most Likely To Occur. For temperatures, this is a bit of a stretch because temperatures are driven by a periodic cycle of seasons and weather.

But for task durations, this is a legitimate starting point for estimating. What is the most likley duration for this work? Without the variance on the Mode or the Mean, the Median is the middlemost number, there can be no confidence you wouldn't freeze to death in February if you go to Wyoming in your shorts and teeshirt

Related articles How to Avoid the "Yesterday's Weather" Estimating Problem Want To Learn How To Estimate? Capabilities Based Planning
Categories: Project Management

Same Same but Different †

Herding Cats - Glen Alleman - Sun, 04/09/2017 - 16:47

Much of the conversation in social media around agile techniques seems to be based on the differences between the variety of choices of a  method, a process, or a practice and definitions of terms for those choices. There seems little in the way of shared principles, when in fact, there is a great deal of sharing of principles.

I work in a domain where systems are engineered for the customer. These systems fall into the Software Intensive System of Systems (SISoS) category. In this domain innovation is the basis of success. The notion that innovation and engineering - software engineering - are somehow in conflict is common. 

... creativity is simply the production of novel, approprioate ideas, from science, to the arts, to education, to business, to everyday life. The ideas must be movel - different from what's been done before - but they can't be simpmply bizarre; they must be appropriate to the problem or opportuntiy presented. Creativity is the first step in innovation, which is the successful implementaion of those novel, approproate ideas. And innovation, is absolutley vital for long-term corporate success - "Motivating creativity in organmizations: On doing whay you love and loving what you do," [2]

In many conversations about managing in the presence of uncertainty - which is the ubiquitous condition for all non-trivial software development projects - the notion that principles, processes, and practices of Engineered Systems appear to be the antithesis of Agile software development in some quarters. 

Both agile advocates and engineered systems advocates practice innovation and creativity. Both fields are supported by a history of creating innovations - and in fact, collaborate on many of the programs I work. In the software engineering domain, like the developer domain, design is the basis of innovation. Design from a generalized perspective is purposeful ...

... thinking, problem-solving, drawing, talking, consulting and responding to a range of practical and aesthetic constraints to create - ideally - the most appropriate solution(s) under the given circumstances. - [3]

So why is there a great divide between the traditional engineered software-intensive system of systems and the current agile development paradigm that appears to reject the basic principles of developing value-based products from capital investments, using the core principles of managerial finance and microeconomics of decision making in the presence of uncertainty rejected by many in the agile development community? 

Why does the engineered system paradigm reject many of the practices of the agile community as undisciplined, ad hoc with little or no basis in the principles of management? 

Let's start with five core organizational principles of agile...

  1. Regular delivery of incremental business value - defined in a Product Roadmap, scheduled in a Cadence or Capability release plan.
  2. Iterative development focused on the delivery of Features that enable the needed Capabilities that fulfill the business case or accomplish the mission of the software system.
  3. Responding to changing requirements and priorities to assure continuous release of products needed to enable the needed Capabilities to be fulfilled.
  4. Engaging in multiple levels of planning with detailed planning occurring at the Sprint level to produce working software for needed Capabilities produced as planned in the Product Roadmap.
  5. Open and regular collaboration across teams and stakeholder to assure a shared vision of the desired project outcome.

The engineered SISoS domain has the same paradigm in principle because these principles and five implementation principles are Immutable. The five implementation principles are...

  1. What does done look like described in units of measure meaningful to the decision makers?
  2. What is the plan to reach done for the cost and delivery date to produce the needed value to those paying for the work?
  3. What resources are needed to provide the needed capabilities to fulfill the business case or accomplish the mission?
  4. What impediments will be encountered along the way to Done and what handling activities will be applied to remove or reduce these impediments?
  5. How will progress to plan be measured so the decision makers will have confidence their investment will be returned as planned?

So what's the disconnect we hear between Agile and Traditional systems development? 

The first is the principles listed above are not established first before idea exchange starts. So when there is a gap in the semantics of a conversation, there is no touchstone to go back to. Without this shared understanding of the principles, the conversation becomes self-centered (an echo chamber) and any possible exchange in pursuit of learning is lost.

Second is there is no shared domain as the basis for applying those principles. I work in the SW Intensive System of Systems world. Others work in website development, others work in internal IT shops. While the principles of developing software for money are likely to be the same, the processes and practices can be dramatically different. What is a good practice for our spaceflight avionics system development, is probably of little use to a web developer. And vice versa.

Until we come to agree that the principles are a starting point, and then put a shared domain on top of those, it will be an argument without end.

Same Same but Different

† "Same Same but Different" is a phrase used a lot in Thailand, especially in an attempts to sell something but can mean just about anything depending on what the user is trying to achieve.

[1] Same Same but Different Perspectives on Creativity Workshops by Design and Business," Alexander Brem and Henrik Spoedt, IEEE Engineering Management Review, Vol. 4, No. 1, First Quarter, March 2017, pp. 27-31

[2] "Motivating Creativity in Organizations: On Doing what you Love and Loving What You Do," T. M. Amabile, California Management Review, 40, pp. 39-58, 1997.

[3] The Design History Reader,  Grace Lees-Maffei (Editor), Rebecca Houze (Editor), Bloomsbury Academic, April 15, 2010.

Related articles The Customer Bought a Capability The Reason We Plan, Schedule, Measure, and Correct Who Builds a House without Drawings? Two Books in the Spectrum of Software Development Complex, Complexity, Complicated
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 04/08/2017 - 16:21

‚ÄúIf a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related‚ÄĚ ‚Äď Martin Shub

When there are practices suggested without principles, those practices have no way of being tested for applicability to the problem at hand. So when you hear We have a way to fix some problem, ask by what principles can you suggest your solution with fix the problem? And of course, ask have you found the root cause of the problem or are you just treating the symptom?

Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 04/08/2017 - 16:21

‚ÄúIf a profession is to sharpen its skills, to develop new skills and applications, and to gain increasing respect and credibility, then theory and practice must be closely related‚ÄĚ ‚Äď Martin Shub

When there are practices suggested without principles, those practices have no way of being tested for applicability to the problem at hand. So when you hear We have a way to fix some problem, ask by what principles can you suggest your solution with fix the problem? And of course, ask have you found the root cause of the problem or are you just treating the symptom?

Categories: Project Management

Velocity versus Speed (Update)

Herding Cats - Glen Alleman - Sat, 04/08/2017 - 15:17

Velocity is a speed in a specific direction. Velocity is Distance traveled divided by time in a specific direction. This is defined as a Vector. Speed and Direction. 

Velocity

The direction can be a compass heading. A compass heading of an aircraft - 270¬į. The aircraft can have a 2nd dimension of measure - the compass heading and climbing or descending¬†at a¬†measure of feet per minute.

CompassImage005
Speed is Distance traveled over Time. When we are driving we have a speedometer. It says 55 Miles Per Hour. OK, I rarely drive 55 MPH but pretend I was. In one hour (time) I will cover 55 miles. This measure doesn't include the direction. We're driving on the road for the most part, so the direction is predetermined. With speed, we're measuring the distance over that road over time, no matter what the shape of the road is - straight or curved, flat or mountainous. 

Velocity in Agile Software Development

Velocity is a term used in agile development. In agile, A velocity is an arbitrary unit of measure, calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project. The velocity is calculated by counting the number of units of work (Stories or Story Points or any other arbitrary measure) completed in an interval of time (a Sprint), the length of which is determined at the start of the project (some small number of weeks).

These units can be Story Points, Stories, kumquats, or Corgi dogs, and the interval can be a Sprint of 2 or 3 weeks or any other unit. Usually, they are Story Points or Stories, but this is arbitrary. 

So 30 Story Points over 2 weeks means 15 Story Points per week - on average - or 5 Story Points per day - on average. This is the average Speed, the instantaneous speed is different, just like the instantaneous speed changes many times a minute. The speed in the agile example is the number of Story Points and the direction is toward the end - direction. But that end we need a  unit of measure as well. The Stories and Tasks from the Product Backlog is a direction. Those Stories are definitized from Features in the Prodict Roadmap and Release Plan. That's how we get direction in agile for Velocity.

Velocity = Speed in a Direction. Velocity is a Vector. Speed is a Scalar

Does Velocity effect Cycle Time? 

Cycle time is the total time from the beginning to the end of a work process. Cycle time includes process time, where the object under work is acted upon to bring it closer to an output, and delay time, during which a unit of work is spent waiting to take the next action. For software development, the object is the Story and the development of the Code that implements the Story along with the testing and all the other activities of producing the outcome from the work effort.

If we think of cycle time as the time the Story spends being developed (including all the work to produce working software), over some period of time inside the Sprint, including the entire Sprint. Then we can say...

The cycle time for a Story is the total time from beginning to end for the production of Working Software. Howe long were we working on the Story. This is a unit used in Little's Law as well. The direction this Story is going is toward the end of the Sprint. So the Story has a Velocity. But since the direction is fixed - toward the last day of the Sprint, the passage of time from start to end of the development effort, is it's Seed.

So here's the Question

Does Velocity impact Cycle Time? Answer? YES It Does

Why? Cycle Time and Velocity - when there is a fixed direction (the Sprint) over a fixed duration (2 or 3 weeks where we work) affect the total amount of time the Story is being worked (as we say in our defense software development domain). This time being worked is the Cycle Time for that Story. How fast the work is being done (Speed, as in Velocity with a fixed direction) will impact how long the Story is being worked.

The faster we go the faster the Story will be completed. 

So yes,

Velocity does impact the Cycle Time. It impacts that Cycle Time directly. Go fast, finish fast. Finish fast, lower Cycyle Time

After talking this over this morning with a colleague who is responsible for many of the aspects of Agile development in manned and unmanned space flight systems where I work, here's a summary of the notion of Velocity from her point of view - which like mine is from Physics and Math

Screen Shot 2017-04-07 at 3.13.33 PM

  • Speed is the rate of the production of Story Points by the team over some time - the Sprint
  • The direction is the Product Roadmap -¬†where are we going. The Stories and the Features they implement need to have some reason for being there.

So velocity and throughput are directly related. The faster outcomes appear the larger the throughput, measured in a fixed block of time. Since Story Points are a relative (Ordinal) unit of measure expressing an estimate of the effort required to fully implement a product backlog item or any other piece of work, we can assign Story Points to the rate of movement - 20 story points per sprint. This can also be referred to as the capacity for work. Our team can deliver 20 Story Points per Sprint. 

And of course each of these variables are random variable impacted by uncertainty, so estimates are needed in the presence of this uncertainty to determine if we are going be delivering what we said we were going to deliver when the Sprint started.

Lastly, when we hear Story Points are not hours, that is also incorrect. We can assign the arbitrary unit of measure - the Story Point - to any Cardinal measure. One program I work assigns ONE Story Point to be 6 hours (an Ideal Day). This is purely arbitrary of course, but once we've exited Story Time where we use Story Points to prioritize the Story, they are converted into Ideal Days to confirm our capacity for work matches the calendar period of performance for that work. 

By the Way

There a poster on a cubical wall across from my cubical that says ...

Aardvark

Why is this important? The staff on that side of the passage are contract managers for a Manned Space Flight Vehicle. They are always arguing about the meaning of Affect and Effect and how contractually binding the words they are arguing about, usually some piece of hardware that was built or procured and how that piece of hardware is integrated into a larger piece of hardware - last week the connectivity bolts that attached the spacecraft to the adapter ring on top of the launch vehicle and how it's behaviour will AFFECT the performance of the system after the EFFECT of an explosive separation, which by the way must work 100% of the time or people die.

 

 

Related articles Estimates Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management
Categories: Project Management

Same Same but Different †

Herding Cats - Glen Alleman - Sat, 04/08/2017 - 00:19

Much of the conversation in social media around agile techniques seems to be based on the differences between the variety of choices of a  method, a process, or a practice and definitions of terms for those choices. There seems little in the way of shared principles, when in fact, there is a great deal of sharing of principles.

I work in a domain where systems are engineered for the customer. These systems fall into the Software Intensive System of Systems (SISoS) category. In this domain innovative is also the basis of success. The notion that innovation and engineering - software engineering - are somehow in conflict is common. 

... creativity is simply the production of novel, approprioate ideas, from science, to the arts, to education, to business, to everyday life. The ideas must be movel - different from what's been done before - but they can't be simpmply bizarre; they must be appropriate to the problem or opportuntiy presented. Creativity is the first step in innovation, which is the successful implementaion of those novel, approproate ideas. And innovation, is absolutley vital for long-term corporate success - "Motivating creativity in organmizations: On doing whay you love and loving what you do," [2]

In many conversations about managing in the presence of uncertainty - which is the ubiquitous condition for all non-trivial software development projects - the notion that principles, processes, and practices of Engineered Systems appear to be the antithesis of Agile development in some quarters. 

Both agile advocates and engineered systems advocates practice innovation and creativity. Both fields are supported by a history of creating innovations - and in fact, collaborate on many of the programs I work. In the software engineering domain, like the developer domain, design is the basis of this innovation. Design from a generalized perspective is purposeful ...

... thinking, problem-solving, drawing, talking, consulting and responding to a range of practical and aesthetic constraints to create - ideally - the most appropriate solution(s) under the given circumstances. - [3]

So why is it there is a great divide between the traditional engineered software-intensive system of systems and the current agile development paradigm that appears to reject the basic principles of developing value-based products from capital investments? Why are the core principles of managerial finance and the microeconomics of decision making in the presence of uncertainty rejected by the agile development community? 

Why does the engineered system paradigm reject many of the practices of the agile community as undisciplined, ad hoc practices with little or nor basis in the principles of management? 

Let's start with five core organization principles of agile...

  1. Regular delivery of incremental business value - defined in a Product Roadmap, scheduled in a Cadence or Capability release plan
  2. Iterative development focused on the delivery of Features that enable the needed Capabilities that fulfill the business case or accomplish the mission of the software system
  3. Responding to changing requirements and priorities to assure continuous release of products needed to enable the needed Capabilities to be fulfilled.
  4. Engaging in multiple levels of planning with detailed planning occurring at the Sprint level to produce working software for needed Capabilities produced as planned in the Product Roadmap
  5. Open and regular collaboration across teams and stakeholder to assure a shared vision of the desired project outcome

The engineered SISoS domain has the same paradigm in principle because these principles and five implementation principles are Immutable. The five implementation principles are...

  1. What does done look like described in units of measure meaningful to the decision makers
  2. What is the plan to reach done for the cost and delivery date to produce the needed value to those paying for the work?
  3. What resources are needed to provide the needed capabilities to fulfill the business case or accomplish the mission?
  4. What impediments will be encountered along the way to Done and what handling activities will be applied to remove or reduce these impediments?
  5. How will progress to plan be measured so the decision makers will have confidence their investment will be returned as planned?

So what's the disconnect we hear between Agile and more Traditional systems development? 

The first is the principles listed above are not established first before idea exchange starts. So when there is a gap in the semantics of a conversation, there is not touchstone to go back to. Without this shared understanding of the principles, the conversation becomes self-centered (an echo chamber) and any possible exchange in pursuit of learning is lost.

Second is there is no shared domain as the basis for applying those principles. I work in the SW Intensive System of Systems world. Other work in website development, others work in internal IT shops. While the principles of developing software for money are likely to be the same, the processes and practices can be dramatically different. What is a good practice for our spaceflight avionics system development, is probably of little use to a web developer. And vice versa.

Until we come to agree that the principles are a starting point, and then put a shared domain on top of those, it will an argument without end

Same Same but Different

† "Same Same but Different" is a phrase used a lot in Thailand, especially in an attempts to sell something but can mean just about anything depending on what the user is trying to achieve.

[1] Same Same but Different Perspectives on Creativity Workshops by Design and Business," Alexander Brem and Henrik Spoedt, IEEE Engineering Management Review, Vol. 4, No. 1, First Quarter, March 2017, pp. 27-31

[2] "Motivating Creativity in Organizations: On Doing what you Love and Loving What You Do," T. M. Amabile, California Management Review, 40, pp. 39-58, 1997.

[3] The Design History Reader,  Grace Lees-Maffei (Editor), Rebecca Houze (Editor), Bloomsbury Academic, April 15, 2010.

Related articles The Customer Bought a Capability The Reason We Plan, Schedule, Measure, and Correct Who Builds a House without Drawings? Two Books in the Spectrum of Software Development Complex, Complexity, Complicated
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Thu, 04/06/2017 - 14:34

Cost estimation is part science, part art. There are many well-defined processes within the cost estimating discipline. There is also a subjective element to cost estimating that makes the discipline an art (NASA, 2004).

Categories: Project Management

Find Root Cause, Fix It, and Only Then Make Suggestions for Improvement

Herding Cats - Glen Alleman - Thu, 04/06/2017 - 02:30

We hear all the time suggestions for improvement. Or suggestions for outright abandonment of established Processes and sometimes even established Principles.

Before listening to any of these and most important making any changes, do a Root Cause Analysis (RCA) of the problem. Most descriptions of a problem are actually descriptions of a Symptom, not the Cause.

If you don't find the cause, fix it, and monitor the fix, you will not actually be fixing anything.

Start here and learn how to actually make improvements by finding the cause of the problem and stop fixing symptoms that leave the problem in place or may even make it worse.

Screen Shot 2017-04-05 at 1.48.18 PM

Categories: Project Management

Thinking About Cadence vs. Iterations


Many people use an iteration approach to agile. They decide on an iteration duration, commit to work for that iteration and by definition, they are done at the end of the timebox.

I like timeboxing many things. I like timeboxing work I don’t know how to start. I find short timeboxes help me focus on the first thing of value. Back when I used staged-delivery as a way to organize projects, we had a monthly milestone (timebox) to show progress and finish features. The teams and I found that a cadence of one month was good for us. The timebox focused us and allowed us to say no to other work.

A cadence is a pulse, a rhythm for a project. In my example above, you can see I used a timebox as a cadence and as a way to focus on work. You don’t have to use timeboxes to provide a cadence.

A new reader for the Pragmatic Manager asked me about scaling their agile transformation. They are starting and a number of people are impatient to be agile already. I suggested that instead of scaling agile, they think about what each team needs for creating their own successful agile approach.

One thing many teams (but not all) is a cadence for delivery, retrospectives and more planning. Not every team needs the focus of a timebox to do that. One team I know delivers several times during the week. They plan weekly, but not the same day each week. When they’ve finished three features, they plan for the next three. It takes them about 20-30 minutes to plan. It’s not a big deal. This team retrospects every Friday morning. (I would select a different day, but they didn’t ask me.)

Notice that they have two separate cadences for planning: once a week, but not the same day; and once a week for retrospectives on the same day each week.

Contrast that with another team new to agile. They have a backlog refinement session that often takes two hours (don’t get me started) and a two-hour pre-iteration planning session. Yes, they have trouble finishing the work they commit to. (I recommended they timebox their planning to one hour each and stop planning so much. Timeboxing that work to a shorter time would force them to plan less work. They might deliver more.)

A timebox can help a team create a project cadence, a rhythm. And, the timebox can help the team see their data, as long as they measure it.

A project cadence provides a team a rhythm. Depending on what the team needs, the team might decide to use timeboxes or not.

For me, one of the big problems in scaling is that each team often needs their own unique approach. Sometimes, that doesn’t fit with what managers new to agile think. I¬†find that when I discuss cadence and iterations and explain the (subtle) difference to people, that can help.

Categories: Project Management

The Art of Software Gardening

From the Editor of Methods & Tools - Wed, 04/05/2017 - 14:56
Software development has evolved a lot the last decade. Developers are not considered code monkeys any more. They’re expected to write clean and maintainable code that continuously evolve with business needs. Some times they need to work remotely in dynamic and multi-cutltural environments using a variety of technologies and programming languages. Nevertheless they still want […]

Quote of the Day

Herding Cats - Glen Alleman - Wed, 04/05/2017 - 02:33

It is the mark of an instructed mind to rest satisfied with the degree of precision which the nature of the subject admits and not to seek exactness when only an approximation of the truth is possible - Aristotle, 384 ‚Äď 322 BC

Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Systems Engineering

Herding Cats - Glen Alleman - Mon, 04/03/2017 - 03:45

For non-trivial problems in any domain, Systems Engineering provides a starting framework for identifying problems, assessing possible solutions, implementing those solutions, measuring the performance of the efforts to deliver the solutions and the effectiveness of those solutions. Here's the collective wisdom of Systems Engineering from Mitre.

Screen Shot 2017-04-02 at 8.15.30 PM

This book has many resources for a variety of problems in many domains, including agile development. This text speaks to managing in the presence of uncertainty and the processes needed to make decisions including estimating.

Systems engineering and policy analysis must account for costs and affordability. An elegant engineering solution that the customer cannot afford is useless; so too is a policy option that would make many people happy, but at a prohibitive cost. Therefore, careful efforts to estimate the cost of a particular option and the risk that the actual cost may exceed the estimate are necessary for systems engineering and policy analysis. Engineers who design products for commercial sale are familiar with the concept of ‚Äúprice points,‚ÄĚ and a manufacturer may wish to produce several products with similar purposes, each of which is optimal for its own selling price. In the case of systems engineering for the government, it may be necessary to conduct a policy analysis to determine how much the government is willing to spend, before conducting a systems engineering analysis to arrive at the technically ‚Äúbest‚ÄĚ solution at that cost level.

Related articles Capabilities Based Planning First Then Requirements Systems Thinking, System Engineering, and Systems Management Essential Reading List for Managing Other People's Money Release Early and Release Often Making Conjectures Without Testable Outcomes
Categories: Project Management

Own the Future of Management, with Me

NOOP.NL - Jurgen Appelo - Sun, 04/02/2017 - 08:21
Sorry, the deadline has passed. I’m not selling shares at this time.

Since today, I am no longer the only owner of the Management 3.0 business. I have co-owners. Yay!! And you can now join me as a co-owner too.

Management 3.0 is about better management with fewer managers. The ideas and practices help leaders and other change agents with managing for more happiness at work. And the brand was named the leader of the Third Wave of Agile, because of our focus on the entire business, rather than just on development practices and projects. By improving the management of organizations, we hope we are helping to make the world a better place.

As a co-owner of Management 3.0, you support and participate in my adventure. Either passively or actively, you help our team to offer healthy games, tools, and practices to more managers in more organizations.

Since last week, a Foundation owns the Management 3.0 business model and this Foundation has issued virtual shares. The business has grown by more than 40% each year in 2014, 2015, and 2016. In other words, the ownership of shares not only contributes to happier people in healthier organizations. It is also a smart business investment!

Until 1 April 2017, I sell virtual shares (officially: certificates) for EUR 50 per share. On 1 April 2017, I stop selling them for a while. I may continue selling more shares later, but probably at a higher price. And there are more reasons not to wait!

When you buy 10 or more shares before 1 April 2017, I send you a free copy of the book Managing for Happiness, personally signed by me on a unique hand-drawn bookplate.

When you buy 100 or more shares before 1 April 2017, you are entitled to a free one-hour keynote on location (excluding travel and accommodation expenses).

When you buy 1,000 or more shares before 1 April 2017, you gain the status of honored business partner, with special privileges and exclusive access to the team and me.

And everyone who buys shares has a chance to win one of my last eight copies of #Workout, the exclusive Limited Edition. Some people sell it for $2000+ on Amazon.

It is important to known that Management 3.0 is a global brand. I prefer that ownership is distributed across the world. I reserve the right not to sell too many shares to people in the same country. (And yes, it’s first come, first served.)

What are the next steps?

1. Check out my FAQ for all details (read it here);
2. Fill out the application form (APPLY HERE);
3. Sign the simple agreement (I will send it);
4. Pay the share price (information will follow).

I asked the notary and my accountant to make it so simple that it’s five minutes of work and you could be co-owner in one day.

When this simple procedure is complete, we add you to the exclusive list of Management 3.0 owners. You can proudly wear a bragging badge on your website, and the team will inform you about new developments on a regular basis.

Don’t wait too long!

This offer is valid until 1 April 2017. The available shares per country are limited.

OWN THE FUTURE OF MANAGEMENT – APPLY NOW

The post Own the Future of Management, with Me appeared first on NOOP.NL.

Categories: Project Management

Principles, Processes, and Practices of Project Success

Herding Cats - Glen Alleman - Sat, 04/01/2017 - 00:30

Principles are timeless. Practices and Process are Fads.

A Principle a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning. A Practice is an application or use of an idea, belief, or method rather than just the Principle of such application or use. A Process is a series of steps and decisions involved in the way work is completed.

For project management domain, what are some Principles? Fundamental truths that serve as the foundation for a system of belief? Here's my version in the form of questions that when answered form the foundation for the Practices and Processes.

  1. What does Done look like in units of measure meaningful to the decision makers?
  2. What is the Plan and the Schedule for the work in that Plan to reach Done for the needed cost on the needed date to deliver the needed Value to those paying for the work?
  3. What are the resources - time, talent and treasure - needed to reach Done as planned?
  4. What impediments will be encountered along the way to Done and what work must be performed to handle these impediments?
  5. What are the units of measures of progress to plan for each deliverable?

With these 5 Principles, there are 5 Processes needed to implement them

Screen Shot 2017-03-31 at 5.21.34 PM
Each of these processes has Practices that have been shown to be widely applicable in many domains, including Agile development

Let's start with Identifying the needed Capabilities. Capabilities are what the customer bought. They are the ability to get something done.

Screen Shot 2017-03-31 at 5.22.28 PM

Once the Capabilities are identified, we need the technical and operational requirements of the solution that implements the Capabilities

Screen Shot 2017-03-31 at 5.23.13 PM

With the Requirements in place - and these can be a list of Features held in the Product Roadmap and Release Plan for agile, we need to lay out how they will be built

Screen Shot 2017-03-31 at 5.24.36 PM

Then we need to execute this baseline

Screen Shot 2017-03-31 at 5.25.22 PM

With execution underway, managing the risks of the project becomes our focus beyond the engineering work

Screen Shot 2017-03-31 at 5.26.36 PM

With all this in place - to whatever scale is appropriate for the problem at hand, we need the final pieces

Screen Shot 2017-03-31 at 5.28.11 PM Screen Shot 2017-03-31 at 5.28.41 PM

There, now we've got Principles, Processes, and Practices all connected.

Related articles Two Books in the Spectrum of Software Development We've Been Doing This for 20 Years ... Applying the Right Ideas to the Wrong Problem Estimating Processes in Support of Economic Analysis Managing in Presence of Uncertainty
Categories: Project Management

Principles, Processes, and Practices of Project Success

Herding Cats - Glen Alleman - Thu, 03/30/2017 - 23:39

In the project management world, everyone is selling something to solve some problem. This includes product vendors, consulting firms, and internal providers. I'm on the internal provider side most of the time. Other times, I on the consulting firm acting as an internal provider. I not on the vendor side.

Over the years (30 something years) I come to understand and write about the Principles, Processes, and Practices of project success in a wide variety of domains. From software systems to heavy construction, to metal bending companies, petrochemicals, pulp and paper, drugs, consumer products, industrial products, and intellectual property.

Over this time I've been guided by project planning and control people, engineers, sales people, marketing people, and senior business leaders. 

Here's what I've learned. There are 5 Principles, 5 Practices, and 5 Process that can be applied to increase the probability of success of all projects.

The notion that we should move our focus to Products and away from Projects ignores (sometimes willfully) what the role of a project is. Those suggesting we don't need projects (#NoProjects) probably don't understand the actual role of project work, but that another post.

Here's the summary of these Principles, Practices, and Processes. 

Screen Shot 2017-03-30 at 3.22.48 PM

Each of the Principles, Practices, and Processes are independent in the following manner. Again, no matter the domain, context, engineering or development method. From putting in the Spring Garden to flying to Mars, to building the flight avionics for the spacecraft flying to Mars

Screen Shot 2017-03-30 at 4.38.31 PM

So when someone suggests some new way of managing a project, use this to check to see if their new ways covers the Principles, Processes, and Practices.

Related articles Risk Management is How Adults Manage Projects Root Cause of Project Failure Want To Learn How To Estimate? Essential Reading List for Managing Other People's Money
Categories: Project Management

Reference Class Forecasting

Herding Cats - Glen Alleman - Thu, 03/30/2017 - 17:18

Our long time friends have moved to our neighborhood here in Colorado. Their moving van arrived today.

Moving Van

We brought coffee to them while their old house was being unloaded into the new house. Talking with the moving van owner, he started telling stories about estimating the load in pounds. The agent makes the first estimate of the weight of the load, issues a quote for the cost of the move. Then the van owner picks up the load and weighs the truck before getting on the road. He told us the range of precision and accuracy is all over the place, depending on the agent. Sometimes it's very close. Sometimes it's not.

The quality of the estimate depends on the skill and experience of the estimator. The reference class estimating process is part of that skill and experience.

If we switch to software development. I relistened to Agile for Humans podcast with Steve McConnell about estimating. Steve's discussion was focused on how to make good estimates. How to put these to work to make business and technical decisions. These themes are based on how book Software Estimation: Demystifying the Black Art. This book should be on the shelf of any credible developer.

After listening again, it was clear those providing a forum for the No Estimates advocates have failed to address the fatal flaw of the No Estimates discussion.

There is NO principle by which you can decide in the presence of uncertainty without estimating. 

The podcast provided a nice overview of why we should estimate, how to estimate, and what to do with those estimates. Even discussed how to deal with the dysfunctional aspects of management when making estimates. But in the end, we need estimates to credibly provide value in exchange for money.

There can be no consideration for NOT estimating, except on de minimis projects. Just like the moving van owner, he needs an estimate for the weight of the load. From there he can confirm that load will fit on the truck. The trailer has a load limit of 33,000 pounds. The mechanics of household goods has a reference class parameter for the size of 33,000 pounds. This comes from empirical data of moving household goods. Some houses have heavier goods, some have lighter goods. But the estimator knows how to adjust for that.

It seems those in the software development business who conjecture that estimates are not needed, are the smell of dysfunction, are evil, should be stopped, have failed to understand not only the basic need for the estimate when making decision in the presence of uncertainty, but also the basic principles of estimating in the presence of the uncertainties that always exist on projects.

When the idea of No Estimates is given equal weight to Steve's message, it willfully ignores the principle of decision making. And replacing that principle with the practices and processes that attempt to make a decision without estimates.

This is like the moving van owner saying I get wild estimates, wrong estimates, estimates that cause me problems with my trailer, tractor, load management, and fee payments for carrying cargo across state lines. So I have an idea, I'll just not ask for or use any estimate, I'll just start emptying the house in Seal Beachm=, California and start planning to move the house to Colorado. What could possibly be wrong with that?

 

Related articles The Flaw of Empirical Data Used to Make Decisions About the Future The Flaw of Averages and Not Estimating Managing in Presence of Uncertainty Monte Carlo Simulation of Project Performance Myth's Abound Misunderstanding Making Decisions in the Presence of Uncertainty Herding Cats: Software Development for the 21st Century Want To Learn How To Estimate? Eyes Wide Shut - A View of No Estimates
Categories: Project Management

Software Development Conferences Forecast March 2017

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