Warning: Table './devblogsdb/cache_page' is marked as crashed and last (automatic?) repair failed query: SELECT data, created, headers, expire, serialized FROM cache_page WHERE cid = 'http://www.softdevblogs.com/?q=aggregator/categories/6' in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 729

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 730

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 731

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
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
warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/common.inc on line 153.

A Reminder of the Pseudo-Science of #NoEstimates

Herding Cats - Glen Alleman - Fri, 12/02/2016 - 02:09

When you hear...

#NoEstimates is a hashtag for the topic of exploring alternatives for making decisions in software development. That is, ways to make decisions with "No Estimates"

Think about the conjecture. How would you assess a decision in the presence of uncertainty without making an estimate of the outcome of that decision. Since there is not deterministic data available about the future, even though you may have deterministic data from the past. This would mean the future is like the past, there is no uncertainty about the future - either reducible (epistemic) or irreducible (aleatory). No conditions that were in place from the past will be changing in the future. Nothing is going to emerge that you have not accounted for. Nothing is going to change in any attribute, process, or people doing the work..

Such a process defies the principles of microeconomics of decision making. Defies the principles of managerial finance in the presence of uncertainty. Defies the principles of closed loop control systems in the presence of stochastic non-stationary systems. 

It simply defies the principles of logic

Pseudo‚Äďscience and the art of software methods from Glen Alleman
Categories: Project Management

Pushing vs. Pulling Work in Your Agile Project

If you’re thinking about agile or trying to use it, you probably started with iterations in some form. You tried (and might be still trying) to estimate what you can fit into an iteration. That’s called “pushing” work, where you commit to some number of items of work in advance.

And, if you have to service interruptions, such as support on previous projects, or support the production server, or help another project, you might find that you can’t “push” very well. ¬†You have trouble predicting what you can do every two weeks. While the iteration duration is predictable, what you predict for the content of your iterations is not predictable. ¬†And, if you try to have longer iterations, they are even less predictable.

On the other hand, you might try “pull” agile, where you set up a kanban board, visualize your flow of value, and see where you have capacity¬†in your team and where you don’t. Flow doesn’t have the built-in notion of project/work cadence. On the other hand, it’s great for visualizing all the work and seeing where you have bottlenecks.

Push and PullHere’s the problem: there is No One Right Way to manage the flow of work through your team. Every team is different.

Iterations provide a cadence for replanning, demos, and retrospectives. That cadence, that project rhythm, helps to set everyone’s expectations about what a team can deliver and when.

Kanban provides the team a perspective on where the work is, and if the team measures it, the delays between stages of work. Kanban helps a team see its bottlenecks.

Here are some options you might consider:

  • Add a kanban board that visualizes your workflow before you change anything. Gather some data about what’s happening. Are your stories quite large, so you have more pressure for more deliverables? Do you have more interruptions than you have project work?
  • Reduce the iteration duration.¬†Interruptions are a sign that you might need to change priorities. Some teams discover they can move to one-week iterations and manage the support needs.
  • Ask questions such as these for incoming non-project work: “When do you need this done? Is it more or less important or valuable than the project work?”
  • Make sure you are a cross-functional team. Teams can commit to finishing work in iterations. A group of people who are not interdependent have trouble committing to iterations.

Teams who use only iterations may not know the workflow they really have, or if they have more project or support/interrupting work. Adding an urgent queue might help everyone see the work. And, more explicit columns for analysis, dev & unit test, testing, waiting (as possibilities) in addition to the urgent queue might help the team see where they spend time.

Some teams try to work in two-week (or longer) iterations, but the organization needs more frequent change. Kanban might help visualize this, and allow the team to change what they commit to.

Some POs don’t realize they need to ask questions about value for all the work coming into a team. If the work bypasses a PO, that’s a problem. If the PO does not rank the work, that’s a problem. And, if the team can’t finish anything in a one-week iteration, that’s a sign of interdependencies or stories that are too large for a team. (There might be other problems. Those are the symptoms I see most often.

You can add a kanban board inside your iteration approach to agile. You might consider moving to flow entirely with specific dates for project cadence. For example, you might say, “We do demos every month on the 5th and the 19th of the month.” That would provide a cadence for your project.

You have choices about pushing work or pulling work (or both) for your project. Consider which will provide you most value.

P.S. If you or your PO has trouble making smaller stories, consider my workshop, Practical Product Ownership.

Categories: Project Management

Software Development Conferences Forecast November 2016

From the Editor of Methods & Tools - Tue, 11/29/2016 - 16:00
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 […]

The Core Principles of Agile

Mike Cohn's Blog - Tue, 11/29/2016 - 16:00

I recently watched a video titled, "Why Is Modern Art So Bad?"

One of points of the video was that for centuries, art improved because artists demanded of themselves that they meet the highest standards of excellence.

The video claimed that this aspiration in art was eventually pushed out by the claim that "beauty is in the eye of the beholder." All art then became personal expression and essentially anything could be art.

And we've probably all been to museums and seen--or at least heard of--exhibits that left us wondering, "How is that art?"

Without standards of excellence in art, anything can be art.

Agile without Standards

And the same applies to agile. Without standards of excellence for agile, anyone can call anything agile.

I encounter this today in talking to companies that are agile because the boss has declared them agile. They don't deliver frequently. They don't iterate towards solutions. They don't seek continuous improvement. Teams are not empowered and self-organizing. But they must be agile because someone has slapped that label on their process.

Worse, we all see this today in heavyweight methodologies that don't resemble the agile described in the Agile Manifesto. But they must be agile because it's right there in the name of the process.

Many of us, as experienced agilists, can recognize what is truly agile when we see it. Yet agile is hard to define. It's more than just the four value statements or 12 principles of the Agile Manifesto. Or is it less than those?

What Do You Think?

What do you think are the core principles or elements of agility? Please share your thoughts in the comments below.

What I’ve Been Writing Lately

You might have noticed I have not written as much in this blog for the past couple of months as I normally do. That’s because I’ve been involved in another writing project that’s taken a ton of my time.

I’m part of the writing team for the Agile Practice Guide. The Guide is a joint venture between the Agile Alliance and the PMI. See Bridging Mindsets: Creating the Agile Practice Guide.

We work in timeboxes, iterating and incrementing over the topics in the guide. We sometimes pair-write, although we more often write and review each other’s work as a pair.

If you would like to review the guide as a subject matter expert, send me an email.¬†You’ll have about a month to review the guide, starting in approximately January 2017. I am not sure of the dates yet, because I am not sure if we will finish all our writing when we originally thought. Yes, our project has risks!

Categories: Project Management

Quote of the Month November 2016

From the Editor of Methods & Tools - Mon, 11/28/2016 - 13:32
There is surely no team sport in which every player on the field is not accurately aware of the score at any and every moment of play. Yet in software development it is not uncommon to find team members who do not know the next deadline, or what their colleagues are doing. Nor is it […]

Estimates, Forecasts, Projections

Herding Cats - Glen Alleman - Sun, 11/27/2016 - 15:33

There is the misuse of the terms of statistics and probability in many domains. Politics being one. The #Noestimates advocates are another of the most prolific abusers of these terms. Here are the mathematical definitions. not the Wikipedia definition, not the self-made definitions used to support their conjectures.

Estimates

  • An Estimate is a value inferred¬†for a population of values¬†based on data collected from a sample of data from that population. The estimate can also be produced parametrically or through¬†a simulation (Monte Carlo is common, but Method of Moments is another we use).¬†
    • Estimates can be about the past, present, or future.
    • We can estimate the number of clams¬†in the Pleistocene¬†era that are in the shale formations near our house.
    • We can estimate the number of people sitting in Folsom¬†Field for lat night's game against¬†Utah. The Buff's won and are now the PAC-12 South Champs.
    • We can estimate the total cost, total duration, and the probability that¬†all the Features will be delivered on the program¬†we are working for the US Government. Or ANY software project for that matter.
  • Estimates have precision and accuracy.
    • These values are estimates as well.
    • The estimated completion cost for this program is $357,000,000 with an accuracy of $200,000 and a precision of $300,000.
    • Another way to speak about the estimated cost is¬†This program will cost $357,000,000 or less with 80% confidence.
  • An estimate is a¬†statistic about a whole population of possible values from a previous reference period or a model that can generate possible values given the conditions of the model.¬†

An estimate is the calculated approximation of a result

Forecasts

  • Forecasts speculate future¬†values¬†for a population of possible values with a certain level of confidence, based on the current and past values as an expectation (prediction) of what will happen:
    • This is the basis of weather forecasting.
    • If you listen carefully to the weather forecast it says¬†there is a 30% chance of snow next week over the forecast area.
    • We live at the mouth of a canyon at 5,095' and of there is a 30% chance of snow in Boulder (8 miles south), there is a much lower chance in our neighborhood.
    • Business forecasts, weather forecasts, traffic forecasts are typical. These forecasts usually come from models of the process being forecast. NOAA and NCAR are in our town, so lots of¬†forecasting going on. Weather as well as climate.
    • Not so typical¬†to Forecast the cost of a project or forecast the delivery date. Those are estimated values.
    • For example a financial statement¬†presents, to the best of the responsible party's knowledge and belief, an entity's expected financial position, results of operations, and cash flows. [2]
  • In a forecast, the assumptions represent¬†expectations of actual future events.
    • Sales forecasts
    • Revenue growth
    • Weather forecasts
    • Forecasts of cattle prices in the spring

A forecast is a prediction of some out come in the future. Forecasts are based on estimating the processes that produce the forecast. The underlying statistcal models (circulation, thermal models) of weather forecasting are estimates of the compressable fluid flow of gases and moisture in the atmsophere (way over simplified).

Projections/Prediction

  • Projections indicate what future values ¬†may exist for a population of values if the assumed patterns of change were to occur. Projections are not a prediction that the population will change in that manner.
    • Projected revenue for GE aircraft engine sales in 2017 was an article¬†in this week's¬†Aviation Week & Space Technology.¬†
    • A projection simply indicates a future value for the population¬†if the set of underlying assumptions occurs.

A prediction says something about the future.

Project cost, schedule, and technical performance Estimates

All projects contain uncertainty. Uncertainty comes in two forms - aleatory (irreducible) and epistemic (reducible). If we're going to make decisions in the presence of these uncertainties, we need to estimate what their values are, what the range of values are, what the stability of the underlying processes that generate these values are, how these values interact with all the elements of the project and what the impact of these ranges of value will do to the probability of success of our project.

Project decision in the presence of unceratinty cannot be made without estimates. Anyomne claiming othewise does not understand statsiics and probability of orucomes on projects

As well anyone claims estimates are a waste, not needed, misused by management, of any other dysfunction, is doing them wrong. So as we said at Rocky Flats - Don't Do Stupid Things On Purpose. Which means when you do hear those phrases, you'll know they are Doing Stupid Things on Purpose.

And when yo hear, we don't need estimates we need budget, remember:

In a world of limited funds, as a project manager, Product Owner, or even sole contributor, you’re constantly deciding how to get the most return for your investment. The more accurate your estimate of project cost is, the better able you will be to manage your project’s budget.

Another example of not understanding the probability and statistics of projects and the businesses that fund them is, there are two estimates needed for all projects that operate in the presence of uncertainty:

  • Estimate at Completion (EAC)
    • EAC is the expected cost of the project when it is complete.
    • This can be calculated¬†bottom-up from the past performance and future projections of performance for the projects work - which in the future will be an estimate.
  • Estimate to Complete
    • ETC is the expected cost to complete the project.
  • The ETC used to calculate the EAC
    • EAC = Actual Costs to Date (AC) + Estimated Cost to Complete (ETC).
    • EAC = Actual performance to date / Some Index of Performance.

This last formula is universal and can be used no matter the software development method.

  • Agile has such a formula - it's called the Burn Down Chart. We're¬†burning down story points at some rate. If we continue at this rate, we will be done by this estimated date
  • Same for traditional projects.¬†We're spending at a current rate - the run rate - if we keep spending at this rate, the project will cost that much
  • Earned Value Management provides the same EAC and can also provide an Estimated Completion Date (ECD)
  • Earned Schedule¬†provide a better ECD

 Wrapup

Nothing in progression can rest on its orginal plan - Thomas Monson [5]

All project work is driven by uncertainty. Uncertainty is modeled by random variables. These variables can represent aleatory uncertainty or epistemic uncertainty. This uncertainty creates risk and as stated here often

Risk Management is How Adults Mange Projects - Time Lister

So if you hear the conjecture that decisioins can be made in the presence of uncertainty without estimates, you'll now know that is a complete load a crap, run away.

If this topic interests you here's a Bibliography of materials for estimating and lots of other topics in agile software development that is updated all the time. Please read and use these when you hear unsubstantiated claims around estimating in the presnece of uncertainty. Making estimates is our business and this resoruce has served us well over the decades.

Other Resources

  1. Australian Bureau of Statistics
  2. Financial Forecasts and Projections, AT §301.06, AICPA, 2015
  3. Earned Value Management in EIA-748-C
  4. Earned Schedule uses the same values as Earned Value, to produce an estimated complete date, www.earnedschedule.com I started using ES at Rocky Flats to explain to the steel workers that their productivity as measured in Budgeted Cost for Work Complete (BCWP or EV) means they are late. ES told them how late and provides the date of the projected completion of the planned work
  5. Project Management Analytics: A Data-Driven Approach to Making Rational and Effective Project Decisions, Harjit Singh, Pearson FT Press; 1st Edition, November 12, 2015.

 

Related articles Why Guessing is not Estimating and Estimating is not Guessing Critical Success Factors of IT Forecasting Eyes Wide Shut - A View of No Estimates IT Risk Management Architecture -Center ERP Systems in the Manufacturing Domain
Categories: Project Management

Quote of the Day

Herding Cats - Glen Alleman - Sat, 11/26/2016 - 22:35

When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knpowledge is of a meager and unsatisfactory kind. -- Lord Kelvin Popular Lectures and Addresses, 1889.

Without numbers, without some means of assessing the situation, the outcomes, the impacts, any conjecture is of little use. 

Categories: Project Management

Iterations and Increments

general-agile-picture-copyright-1024x645Agile is iterative and incremental development and frequent delivery with cultural change for transparency.

What do the words iterative and incremental mean?

Iterative means we take a one-piece-at-a-time for creating an entire feature. Iterative approaches manage the technical risk. We learn about the risk as we iterate through the entire feature set.

Incremental means we deliver those pieces of value. Incremental approaches manage the schedule risk, because we deliver finished work.

Agile works because we manage both technical and schedule risk. We iterate over a feature set, delivering chunks of value. (One reason to deliver value often is so we can change what the team does next.)

Here’s a way to think about this if I use a feature set called “secure login.” Now, no one wants to log in. But, people want to have security for payment. So secure login might be a way to get to secure payment. The theme, or what I have been calling a feature set, is “Secure login.” A feature set is several related features that deliver a theme.

If you want to iterate on the feature set, you might deliver these valuable increments (I first wrote about this in How to Use Continuous Planning):

  1. Already existing user can log in.
  2. Users can change their password.
  3. Add new user as a user.
  4. Add new user as admin.
  5. Prevent unwanted users from logging in: bots, certain IP addresses, or a physical location. (This is three separate stories.)

If you implement the first story, you can use a flat file. You can still use a flat file for the second story. Once you start to add¬†more than 10 users, you might want to move to some sort of database. That would be a story. It’s not “Create a database.” The story is “Explore options for how to add 10, 100, 1000, 10000 users to our site so we can see what the performance and reliability implications are.”

Notice the explore as part of the story. That would lead to a spike to generate options that the team can discuss with the PO. Some options have performance implications.

Every time the team iterates over the feature set, they deliver an increment. Since many teams use timeboxes, they use “iterations” as the timebox. (If you use Scrum, you use sprints.) Notice the term “iterate over the feature set.”

In incremental life cycles, such as staged delivery, the team would finish all the features in the one feature set. Incremental life cycles did not necessarily use timeboxes to timebox the incremental development. In iterative life cycles, such as spiral or RUP, the team would develop prototypes of features, or even partially finish features, but the final integration and test occurs after all the iterative development was done.

In agile, we iterate over a feature set, delivering incremental value. If you don’t finish your stories, you’re in an iterative life cycle. If you don’t limit the features you finish and finish “all” of them, you are in an incremental life cycle.

There is No One Right Way to select a life cycle for your project. If you want to use agile, you iterate over a feature set in a short time, delivering chunks of value.

If you are having trouble slicing your stories so you can create feature sets, see my Product Owner Workshop (starting in January). Super early bird expires this coming Friday.

Categories: Project Management

Software Development Linkopedia November 2016

From the Editor of Methods & Tools - Mon, 11/21/2016 - 15:08
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about introvert project manager, scaling Agile, Test-Driven Development, UX vs UI, philosophy and programming, retrospectives, BDD in Java and Agile metrics. Blog: How Introvert Can Survive as Project Manager Blog: #AgileAfrica […]

Is Your Organization Killing Your Software?

From the Editor of Methods & Tools - Thu, 11/17/2016 - 16:19
When asked ‚ÄúWhat is your architecture?‚ÄĚ most people immediately respond with how their software is laid out and what their plans are for improving parts of it. Rarely does anybody really think through their team and organizational architecture, and even more rarely do people understand how that may fundamentally impact how the software gets written […]

Risk Management is How Adults Manage Projects

Herding Cats - Glen Alleman - Tue, 11/15/2016 - 17:33

Risk Management is How Adults Manage Projects - Tim Lister

Here's how we manage risk on our software intensive system of systems using Agile. 

Risk management requires making estimating of the reducible and irreducible uncertanties that create risk. If you're not estimating these uncertanties and their impacts, you're not managing as an adult.

Related articles IT Risk Management Risk Management is How Adults Manage Projects Estimating is Risk Management Mr. Franklin's Advice Late Start = Late Finish
Categories: Project Management

The Myth of the Scrum Master and Actual Life Experiences

Herding Cats - Glen Alleman - Tue, 11/15/2016 - 00:11

Just listened to Tony Richards "The Capital Role of Scrum" in Scrum Master Toolbox Podcast (yes I know, this is Vasco's podcast and it does have value when he sticks to Scrum topics). Vasco describes the scrum Master as the Scrum Mom. 

This brings to mind a concept we (wife and me) came to a bit late in our child raising experience.  We encountered Parenting with Love and Logic a bit late - middle school. In this paradigm, there are 3 types of parents.

  • The drill sergeant¬†parent
  • The helicopter¬†parent
  • The consultant parent

In the Scrum paradigm

  • Drill Sergent - enforces compliance with rules using the policies and procedures of the firm's software development lifecycle (SDLC). Remember Jack Welsch's quote¬†bureaucracy protects the organization from the incompetent. ¬†When everyone is competent less bureaucracy is needed.¬†
  • Helicopter -¬†rescue the team when they get in trouble. This transfers the accountability for¬†getting things done to the Scrum Master, rather than the Scrum Team.

It's the Consultant that serves as the best parenting style. For an Agile (Scrum) Team, the parenting actions in Love and Logic have direct applicability. I'm not suggesting the Scrum master or Scrum Coach is the parent of the team. Rather the paradigm of parenting is applicable. Vasco may not have realized that, but parenting is very close to managing the action of others for a beneficial outcome of both those performing the work and those paying for the work.

  • Provide messages of personal worth and strength - a team is defined as¬†a small group of qualified individuals who hold each other accountable for a shared outcome. The SM needs to¬†message that idea at all times. Determine if the team is behaving as a team, and when they are not consulting with them to determine why not, what can be changed to get back to the¬†team processes. Here's one of the best talks about what a Team does when it is working properly.
  • Very seldom mention responsibilities - if the team is acting like a team, then they have a¬†shared accountability for the outcomes. This is self-defining the responsibilities. The have agreement on this accountability for a shared outcome means having a process to reveal the outcome. Product Roadmap, Release Plan, backlogs, Big Visible Charts again, are ways to¬†broadcast the results of the¬†shared outcome Alistair Cockburn calls these¬†Information Radiators.
  • Demonstrates how to take care of self and be responsible - the SM behaves as a¬†consultant advisor.
  • Shares personal feelings about own performance and responsibilities - communication¬†is¬†all ways (meaning¬†not top down, not bottom¬†up, not dominated by the vocal few).
  • Provides and helps team explore alternatives and then allows the team to make their own decision - making those decisions is the basis of Scrum. Along with the¬†accountability of the team for those decisions.
  • Provides ‚Äútime frames‚ÄĚ in which the team may complete responsibilities - all software development is time-based. Those paying for the work hopefully understand the¬†time value of money. Time is the only thing a team can't get more of. Self-managing in the presence of uncertainty means the team must manage the time aspects of their work.
  • Models doing a good job, finishing, cleaning up, feeling good about it¬†-¬†the SM walks the walk of being a consultative guide.¬†
  • Often asks, ‚ÄúWho owns the problem?‚ÄĚ helps the team¬†explore solutions to the¬†problem¬†- guides the team to the solution through Socratic interaction. This means the SM needs to have some sense of what the solutions might be. Having little¬†understanding of the product domain, means not being able to ask the right questions. Without that skill and experience, the Team can easily get in trouble.
  • Uses lots of actions, but very few words - big visible charts, directed question, artifacts of the teams work, self-created outcomes that demonstrate success as a team for that¬†shared outcome speak much louder than words.¬†
  • Allows the team to experience life‚Äôs natural consequences and allows them to serve as their own teacher -¬†the notion of fail fast and fail often is misunderstood in the business world by the teams. It is many times taken as we don't need to know what done looks like and we can have it emerge as we go. In Love and Logic, the paradigm means failures as a young child have much lower consequences than failures as a young adult. Learn to see what failures will occur and avoid them. Falling out of a chair¬†at age 3 is much less critical than falling off the side of a mountain at age 16 with no protection ¬†- helmet or belaying ropes. Make mistake early on, the cost of mistakes later can be life threatening.

Summary

Scrum teams must act as teams in the Jon Katzenbach notion. The Scrum Master must act as the consultant parent for that team. The term Scrum Coach has two aspects. The parenting coach (consultant) and the coach found on sports teams. Agilist many times forget this. The sports coach is not a player. The sports coach may have played and knows the game. But the agile coach, like the sports coach, has insight to how to improve the performance of the team, that the team members themselves do not have. This is evidenced by the Super Bowl win of the Broncos and the World Series win of the Chicago Cubs. 

Categories: Project Management

Little Book of Bad Excuses

Herding Cats - Glen Alleman - Mon, 11/14/2016 - 16:13

Long ago there were a set of small books from the Software Program Managers Network and Norm Brown's work on Industrial Strength Management Strategies, which was absorbed by an organization which is no longer around. I have all the Little Books and they contain gems of wisdom that need restating in the presence of the current approaches to software development and hype around processes conjectured to fix problems.

The Software Program Managers Network produced books. I have 7 of them.

  • Little Books of Configuration Management
  • Project Breathalyzer
  • Little Book of Bad Excuses
  • Little of Testing Volume I and II
  • Condensed Guide to Software Acquisition Practices
  • Little Yellow Book of Software Management Questions

These books are built on the Nine Best Practices for developing software-intensive systems and short briefing that goes with the paper

Let's start with formal risk management. There was a twitter post yesterday asking about the connection between Agile development and Risk Management. Agile is a participant in risk management but it is not risk management in and of itself.

From Bad Excuses book, here's a list for Risk Management and the Project Breathalyzer where these  items live in a larger context

  1. What are the top ten risks as determined by the customer, technical, and program management?
  2. How are these risks identified?
  3. How are these risks resolved?
  4. How much money and time has bee set aside for risk mitigation?
  5. What risks would be classified as showstoppers and were these derived?
  6. How many risks are in the Risk Register? How recently has the Risk Register been updated?
  7. How many risks have been added in the last six months?
  8. Can a risk be named that was mitigated in the last six months?
  9. What risks are expected to be mitigated or resolved in the next six months?
  10. Are risks assessed and prioritized in terms of their likelihood of occurrence and the potential impact to the program?
  11. Are as many viewpoints as possible involved in the risk assessment process?
  12. What percentage of the risks impact the final delivery of the system?
  13. To date how many risks have been closed out?
  14. How are identified risks made visible to all project participants?

No matter the development method - agile or traditional - risk management is how adults manage projects (Tim Lister). No risk management no adults at the table.

Categories: Project Management

Little Book of Bad Excuses

Herding Cats - Glen Alleman - Mon, 11/14/2016 - 16:13

Long ago there were a set of small books from the Software Program Managers Network and Norm Brown's work on Industrial Strength Management Strategies, which was absorbed by an organization which is no longer around. I have all the Little Books and they contain gems of wisdom that need restating in the presence of the current approaches to software development and hype around processes conjectured to fix problems.

The Software Program Managers Network produced books. I have 7 of them.

  • Little Books of Configuration Management
  • Project Breathalyzer
  • Little Book of Bad Excuses
  • Little of Testing Volume I and II
  • Condensed Guide to Software Acquisition Practices
  • Little Yellow Book of Software Management Questions

These books are built on the Nine Best Practices for developing software-intensive systems and short briefing that goes with the paper

Let's start with formal risk management. There was a twitter post yesterday asking about the connection between Agile development and Risk Management. Agile is a participant in risk management but it is not risk management in and of itself.

From Bad Excuses book, here's a list for Risk Management and the Project Breathalyzer where these  items live in a larger context

  1. What are the top ten risks as determined by the customer, technical, and program management?
  2. How are these risks identified?
  3. How are these risks resolved?
  4. How much money and time has bee set aside for risk mitigation?
  5. What risks would be classified as showstoppers and were these derived?
  6. How many risks are in the Risk Register? How recently has the Risk Register been updated?
  7. How many risks have been added in the last six months?
  8. Can a risk be named that was mitigated in the last six months?
  9. What risks are expected to be mitigated or resolved in the next six months?
  10. Are risks assessed and prioritized in terms of their likelihood of occurrence and the potential impact to the program?
  11. Are as many viewpoints as possible involved in the risk assessment process?
  12. What percentage of the risks impact the final delivery of the system?
  13. To date how many risks have been closed out?
  14. How are identified risks made visible to all project participants?

No matter the development method - agile or traditional - risk management is how adults manage projects (Tim Lister). No risk management no adults at the table.

Categories: Project Management

How to Lie With Statistics

Herding Cats - Glen Alleman - Sun, 11/13/2016 - 15:49

The book How To Lie With Statistics, Darrell Huff  tells us how the make the numbers look the way we want them to look, without actually changing the numbers.  One common way to is adjust the coordinates scales. Either in this way, by not have the full y-axis scale. This approach makes it look like the voter turnout is dramatically different between 2008 and 2016. Which it is as a percentage

Screen Shot 2016-11-11 at 7.56.04 AM

The Republican vote was lower than the Democratic vote, but the scale makes it look much different

Screen Shot 2016-11-11 at 7.58.02 AM

Of course, there's my favorite where the y-axis has no scale - supposedly normalized - but normalized in heterogeneous units - Cats versus Cumquats. In this case, as well the Ideal has no basis in fact since both the estimate and the actual are random variances subject to the uncertainties of project management - aleatory and epistemic uncertainties. The missing error bands hide what is the Root Cause of the non-ideal actuals. Each dot (diamond and triangle) needs a confidence band from the original estimating process. Was that estimate an 80% confidence estimate, a 60% confidence estimate, a wild ass guess. With this knowledge the single point results are worthless in determining what could the numbers have been, why they are the way they are, and what could we possibly do about making them better.

Without knowing why those projects dod not follow the ideal - meaning the actuals matched the estimate, the chart is just a bunch of date with no information for taking corrective actions to improve project performance.

Screen Shot 2016-11-11 at 8.01.02 AM

So first go buy How To Lie with Statistics, (you can find a downloadable version at Archive.org) then download How to Lie with Statistical Graphs.

Along with

  • Statistics, A Very Short Introduction, David J. Hand
  • Principles of Statistics, M. G. Bulmer
  • Flaws and Fallacies in Statistical Thinking, Stephen K. Campbell
  • Stanard Deviations: Flawed Assumptions, Tortured Data, and Other Ways to Lie with¬†Statistics, Gary¬†Smith

You can start to push back on graphs, charts, assumptions, and conclusions derived from bad statistics

After that go buy Apollo Root Cause Analysis: Effective Solution to Everyday Problems Every Time, Dean Gano and learn that without the CAUSE is the numbers you see in a graph, you have no way to taking any action to make them better. You're just by stander to possible bad statsitics.

Categories: Project Management

The Agile Cannon

Herding Cats - Glen Alleman - Sat, 11/12/2016 - 18:30

The paper Agile Base Patterns in the Agile Canon, Daniel R Greening, 2016 49th Hawaii International Conference on System Sciences is an important contribution to the discussion of agile at scale in organizations beyond 5 developers at the table with their customer.

The Agile Cannon is composed of 5 elements

  1. Measure Economic Progress
    • Plans don't guarantee creative success - creative efforts operate in an¬†economy - as system where people manage limited resources to maximize return and growth
    • Forces¬†on economic progress
      • Economics¬†- actions that be participants without well-defined economic guidance, wander aimlessly. They don't know what they value. They don't know their costs
      • Measurement - lagging measures applied to current decisions can fail perversely
      • When measurement drives rewards, perceived value is gamed. Creativity is improved with rewards of mastery, autonomy, and purpose [1]
    • Measure economic progress with well-chosen, evolving metrics
      • Identify desired outcomes
      • Identify relevant¬†metrics
      • Create a forecasting discipline
      • Embrace objectivity
      • Evolve
  2. Proactively Experiment to Improve
    • Not improving¬†fast¬†enough
    • Forces on proactive improvement
      • Complacency - passive observation¬†
      • Loss of control creates risk of failure
      • Quest for control (in manufacturing sense) makes innovation harder [2]
      • Non-creative work is easier
      • Uncertainty creates confusion
    • Proactively¬†experiment to improve
      • Run adaptive improvement experiments
      • Before changing anything assess different options and explore possible results
      • Experiments¬†can be evolutionary or revolutionary
      • Establish a hypothesis
      • Innovation causes variability
      • Kaizen emphasis¬†on small improvements
      • Variation accompanies chaos and complex adaptive systems
      • Two solutions to all this
        • Compensate for metric variations¬†by including¬†learning¬†metrics
        • Compensate¬†for cost variation¬†by including risk reduction metrics
    • Teams that apply experiment¬†techniques can become¬†hyper-productive [3]
  3. Limit Work-In-Progress
    • When going too slow, more detailed¬†plans makes it worse
    • Forces on WIP¬†
      • Inventory - fungible assets helps increase productivity, but increase costs
      • Congestion - as randomly timed requests increase system utilization, delay before request started increases exponentially
      • Cognition - the most limited resource for creative people is time and attention
    • Limit WIP to improve value flow
      • Cognition and backlogs = a clear mind helps prioritize work
        • Focus¬†on most profitable work
        • Establish¬†a Zero backlog approach to planning - Scrum creates Sprint Backlog. Highly effective Scrum teams have seven items in Sprint Backlog
        • Create¬†fractually structured Product Backlog - seven small backlog items, followed by seven bigger ones.¬†Fractually Structured backlog limits the amount of planned effort invested¬†early in a large project, reducing planning, decreasing sunk cost bias, and encourages rapid¬†adoption to new information
      • Collaborative Focus
        • Swarm on top most items
        • Goal is completion - shippable product
        • Communication delays are a form of WIP
      • Value Stream Optimization
        • Visibly track active work by category
        • Limit WIP in each category
        • Organize using VSM [4]
  4. Embrace Collective Responsibility
    • Forces on Collective Responsibility
      • Readily claim responsibility for success, but refrain from claim responsibility for failure
        • Deny the problem
        • Blame others
        • Blame circumstances
        • Feel obligation to keep doing our job
    • Help People embrace collective responsibility
      • Autonomy
      • Understanding
      • Agency
    • Organizational culture largely determines if teams and individuals embrace and sustain collective responsibility
  5. Solve Systemic Problems
    • Forces on systemic problems
      • Operating with many actors, dysfunctions of others limits agility
      • Competing for attention from dependencies creates queue that increases latency¬†
    • Collaboratively analyze and mitigate systemic dysfunction
      • Root Cause Analysis [5]
      • Static analysis¬†- dependency mapping
      • Dynamic analysis - analyze flow

[1] D. Pink, Drive: The surprising truth about what motivates us (2011). 

[2]¬†R. Ashkenas, ‚ÄúIt‚Äôs Time to Rethink Continuous Improvement,‚ÄĚ HBR blog http://j.mp/hbrci (2012).¬†

[3]¬†C.R. Jakobsen et al, ‚ÄúScrum and CMMI ‚Äď Going from Good to Great: Are you ready-ready to be done-done?‚ÄĚ Agile Conference 2009, IEEE.¬†

[4] G. Alleman, "Product & Process Development Kaizen for Software Development, Project, and Program Management, LPPDE, Denver Colorado, April 2008

[5]¬†D.R. Greening, ‚ÄúAgile Pattern: Social Cause Mapping,‚ÄĚ http://senexrex.com/cause-mapping/ (2015).¬†

Categories: Project Management

Veterans Day

Herding Cats - Glen Alleman - Fri, 11/11/2016 - 15:41

Veterans-day1

For all of us who have served, are serving, and those who gave their lives in service of our country - honor them today

Categories: Project Management

My Core Values

NOOP.NL - Jurgen Appelo - Fri, 11/11/2016 - 14:00
My Core Values

I’m writing this the day after Donald Trump won the election to become the 45th President of the United States. It is a day many of us are sure to remember.

Others have written enough about Trump’s behaviors, ethics, and his style of communication. There is nothing for me to add. Maybe the best way of dealing with the current situation (and the next four years) is to reflect on our own personal values. Criticizing others is easy. But what about being more critical of ourselves?

So… I had a good look at myself, the things that motivate me, and the aspects of my work ethic that I value above everything else. After extensive deliberation, I came up with five core values. I call them my IICCC (double I, triple C):

Independence: I do everything to stay free and autonomous
Integrity: I treat everyone fairly and equally, without discrimination
Curiosity: Exploring and understanding the world has my highest priority
Creativity: Making new things and being innovative is equally important
Competence: When I do work I enjoy, I aim to become very good at it

That’s it! Those are my new core values.

Of course, defining your values is the easy part. The hard part is living them. That will require regular reflection and maybe some rewards for my good behaviors. Some chocolate cookies perhaps.

Let’s hope that Donald Trump is doing a similar exercise.

(This post is part of my soon-to-be-announced Agility Scales project.)

(c)2015 Nichole Burrows, Creative Commons 2.0

The post My Core Values appeared first on NOOP.NL.

Categories: Project Management

Book of the Month

Herding Cats - Glen Alleman - Thu, 11/10/2016 - 19:04

It's been a busy month for reading. I've been on the road, so I try and focus on reading rather than on working while on the plane. Here are three books underway that are related for the programs we work

Practical Guide to Distributed Scrum

This book contains processes for improving the performance of Scrum teams when they are distributed.

Two of my clients are in this situation. Mainly because the cost of living near the office is prohibitive and travel distances are the worst in Metro DC.

The book shows how to develop User Stories using a distributed team, engaging in effective release planning, managing cultural and language differences, resolving dependencies, and using remote software processes.

Logically Fallacious

It seems many of the idea debates we get into are based on logical fallacies. 

Here's a nice book on how this happens and how to address the issues when it comes up.

Agile!

I've saved the best for last.

This is a MUST READ book for anyone working with agile or thinking about it.

With the Logically Fallacious book in hand, Agile! can be read in parallel.

There is so much crap out there around Agile, this book is mandatory reading. 

From the nonsense of #Noestimates to simply bad advice, Bertrand calls it out. Along with all the good things of agile

 

Related articles Five Estimating Pathologies and Their Corrective Actions Taxonomy of Logical Fallacies Essential Reading List for Managing Other People's Money Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing Mike Cohn's Agile Quotes
Categories: Project Management