Skip to content

Software Development Blogs: Programming, Software Testing, Agile Project Management

Methods & Tools

Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!

Feed aggregator

Rethinking Component Teams for Flow

A couple of weeks ago, I spoke locally about Manage Your Project Portfolio. Part of the talk is about understanding when you need project portfolio management and flowing work through teams.

One of the (very sharp) fellows in the audience asked this question:

As you grow, don’t you need component teams?

I thought that was a fascinating question. As agile organizations grow, they realize the value of cross-functional teams. They staff for these cross-functional teams. And, then they have a little problem. They can’t find enough UX/UI people. Or, they can’t find enough database people. Or, enough writers. Or some other necessary role for the “next” team. They have a team without necessary expertise.

If managers allow this, they have a problem: They think the team is fully staffed, and it’s not. They think they have a cross-functional team that represents some capacity. Nope.

Some organizations¬†attempt to work around the scarce-expertise problem. They have “visitors” to a team, filling in where the team doesn’t have that capability.

When you do that, you flow work through a not-complete team. You’re still flowing work, but the team itself can’t do the work.

You start that, and sooner or later, the visitor is visiting two, three, four, and more teams. One of my clients has 12 UI people for 200 teams. Yes, they often have iterations where every single team needs a UI person. Every single team. (Everyone is frustrated: the teams, the UI people, and management.)

When you have component teams and visitors, you can’t understand your capacity. You think you have capacity in all those teams, but they’re component teams. They can only go as fast as the entire team, including the person with the scarce expertise, can deliver features. When your team is not first in line for that scarce person, you have a Cost of Delay. You’re either multitasking or waiting for another person. Or, you’re waiting for an expert. (See CoD Due to Multitasking and CoD Due to Other Teams Delay. Also See Diving for Hidden Treasures.)

What can you do?

  1. Flow work through the experts. Instead of flowing work through teams that don’t have all the expertise, ¬†flow work through the experts (not the teams).
  2. Never let experts work alone. With any luck, you have people in the team working with the experts. In Theory of Constraints terms, this is exploiting the constraint. It doesn’t matter what other work you do. If your team requires this expertise, you need to know about it and exploit it (in TOC sense of exploitation).
  3. Visualize the flow of work. Consider a kanban board such as the one below that shows all the work in progress and how you might see what is waiting for whom. I would also measure the Cost of Delay so you can see what the delay due to experts is.
  4. Rearrange backlog ranking, so you have fewer teams waiting for the scarcity.

Here’s the problem. When you allow teams to compete for scarcity (here, it’s a UI person), you don’t get the flow of work through the teams. Everything is slower. You have an increased Cost of Delay on everything.

Visualizing the work helps.

Flowing the work through the constrained people will show you your real capacity.

Needing component teams is a sign someone is still thinking in resource efficiency, not flow efficiency. And, I bet some of you will tell me it’s not possible to hire new people with that skill set locally. I believe you.

If you can’t hire, you have several choices:

  • Have the people with the scarce expertise consciously train others to be ready for them, when those scarce-expertise people become available. Even I can learn some capability in the UI. I will never be a UI expert, but I can learn enough to prepare the code or the tests or the experiments or whatever. (I’m using UI as an example.)
  • Change the backlogs and possibly reorganize as a program. Now, instead of all the teams competing for the scarce expertise, you understand where in the program you want to use that scarce expertise. Program management can help you rationalize the value of the entire backlog for that program.
  • Rethink your capacity and what you want the organization to deliver when. Maybe it’s time for smaller features, more experiments, more MVPs before you invest a ton of time in work you might not need.

I am not a fan of component teams. You could tell, right? Component teams and visitors slow the flow of releasable features. This is an agile management problem, not just a team problem. The teams feel the problem, but management can fix it.

Categories: Project Management

Cross-functional teams

Actively Lazy - Tue, 01/10/2017 - 22:16

Cross-functional teams aren’t a new idea. And yet, somehow, we still don’t seem to have got the memo.

I was listening to the excellent Scott Hanselman’s podcast “Hanselminutes” last week, he had Angie Jones on to talk about automation. Among all the great advice around ensuring that automation is a first-class citizen in your development process one thing stood out for me

you need to get your automation engineers into your scrum team

I don’t know why, but it surprised me. Are there really companies out there up to speed enough to be doing test automation; yet so behind the times with agile that they think it’s a good idea to have a dedicated team of automation engineers, removed from the rest of the dev team?

Cross-functional teams are a pretty central idea to agile – breaking down silos and ensuring that everyone that is required to produce an increment of working software is aligned and working together. It’s certainly not a new idea, but it’s clearly an idea that we’re still struggling to absorb.

But then, looking back, I remember working for a certain large company that decided they needed to “do more test automation”. So they hired a room full of automation engineers, who sat two floors away from the dev team, in a room hidden away (we honestly didn’t know they were even there for weeks, maybe even months). This team were responsible for creating an automated test pack for the application (rather than use the one the test automation engineers in the scrum teams had been working on for the last few years). But… they weren’t even talking to the scrum teams. So they were constantly chasing to keep up. As you can imagine, hilarity ensued. I say hilarity. Arguments, really. Then anger. Eventually laughter as we realised all this effort was wasted because the scrum teams wouldn’t – in fact¬†couldn’t¬†– support this new automation code.

Clearly not getting the idea of cross-functional teams is an age old problem. Compare this to a more recent client of mine – one that had a genuinely more cross-functional team. Not only did the scrum team have its own automation engineer, the developers (actual developers, not re-branded testers) were encouraged to work on the test automation tools – to everyone’s benefit. Test tooling written to the same standards as production code, with the insight and experience of the test automation specialist. This is moving beyond cross-functional teams into cross-skilled teams. Not only is every skill set you need within the same scrum team, but each individual can have multiple skills, taking on multiple roles.

Sure, you still need specialists. But with generalizing specialists you get the best of both worlds: the experience of specialists in their area, with the flexibility and breadth of ideas that come from the whole team being able to work on whatever is required. When the entire team can swarm on any area you have a very flexible team, if we need a big push for test automation the entire team can focus on it. Similarly with plenty of pairing and rotation everyone on the team will see every area and every role, allowing everyone’s unique perspective to improve the product and the process.

But then, a counter-example, the same client suffered from another age-old silo: operations. I thought devops had killed this silo, but it seems not. If the scrum team can’t release an increment of software to actual users then it isn’t a fully self-contained, self-sufficient, cross-functional team. A scrum team working with a separate test automation team seems like a crazy idea; and yet, somehow, a scrum team working with a separate operations team is much more normal, much more accepted. But it’s the exact same problem: if you don’t have everyone you need in the same scrum team then you’re going to get bottlenecks. You’re going to get communication problems. You’re going to get a “them-vs-us” attitude.

Every time I’ve come up against this the typical argument against operations staff being embedded within scrum teams is that they’re not working on “your stuff” all the time, so the rest of the time they’d be busy doing other stuff, unrelated to “your team” or they’d be bored. Well, maybe if we freed up that extra capacity we could release more often? Maybe they could be working on making it quicker, easier, safer to release more often? Maybe they could be more deeply involved with development when we’re making decisions which affect what they’re going to release and how it’s going to wake them up in the middle of the night. Maybe they could even help with other, non-production environments? The neglected, little siblings of production that every company seems to struggle to pay enough attention to.

Maybe, even, over time the team evolves from having the operations specialist to having team members cross skilled into operations. Under the watchful eye of the specialist could we, shock horror, let testers touch production? Could the BA manage a release? In some industries this is completely impossible for regulatory reasons, but in all the others its “impossible” for merely arbitrary reasons.

Breaking down silos is never easy – but I think it’s an interesting reflection of how far we’ve come that some silos seem frankly ridiculous now, while others just seem old-fashioned. I still hold out for the distant dream of genuinely cross-functional teams. Whenever I’ve seen this actually happen the lack of bottlenecks and mis-communication makes everything so much faster, so much easier. In the end a cross-functional team is better than silos. But a cross skilled team is better still, if you can manage it.

Categories: Programming, Testing & QA

SE-Radio Episode 279: Florian Gilcher on Rust

Eberhard talks with Florian Gilcher about the programming language Rust. Rust originates from Mozilla research. Its focus is on system programming and it is often used to replace C or C++. Topics include the concepts behind Rust; concurrent and safe programming; advanced and unique features like ownership and borrowing; the rust type system (which supports […]
Categories: Programming

Indie game developers in Latin America sustain growth after launch on Google Play

Android Developers Blog - Tue, 01/10/2017 - 01:16
Posted by Kacey Fahey, Marketing Programs Manager, Google Play

Indie game developers are some of the most exciting and innovative teams to work with. While developers large and small exist on the same field, gone are the days where you hit publish and turn your back, moving on to the next project. We've gathered a few developer stories coming out of Latin America sharing experiences and advice.

Oktagon Games

Ronaldo Cruz, Founder and CEO of Oktagon Games tells us how "reviews provide great qualitative insight on the game helping us identify problems that may not be caught by analytics."

Tiny Bytes

Tiny Bytes reduced churn by 5% using an in-game tutorial and analytics.

Impossible Apps

Cleverson Schmidt of Impossible Apps shares how introducing in-app purchases helps diversify revenue streams and "can make the game profitable and self sustainable."
How useful did you find this blogpost?
‚ėÜ ‚ėÜ ‚ėÜ ‚ėÜ ‚ėÜ

Categories: Programming

How augmented reality helps you buy furniture and capture Pokémon

Android Developers Blog - Tue, 01/10/2017 - 01:14
Posted by Jamil Moledina, Games Strategic Lead, Google Play

Online furniture seller Wayfair and Niantic's Pokémon GO have more in common than you might think. Both of these companies use augmented reality to create innovative, immersive experiences for their users. I sat down with Mike Festa, Director of Wayfair Next, and Tatsuo Nomura, Product Manager for Pokémon GO, at our recent Playtime event to discuss how developers can make the most of AR as a platform.

From 3D furniture modelling in WayfairView using Tango, to logging countless miles catching Pokémon, hear how these developers are innovating with AR, and get their advice for others looking to use AR in their apps and games.

Check out more sessions from our global Playtime events to learn best practices for your app and game businesses. Also, stay up to date with more videos from events, product news, and tips to help grow your business on Google Play with the Playbook for Developers app.

How useful did you find this blogpost?
‚ėÖ ‚ėÖ ‚ėÖ ‚ėÖ ‚ėÖ

Categories: Programming

Estimating the Risk

Herding Cats - Glen Alleman - Mon, 01/09/2017 - 19:19

Risk is everywhere on projects. This risk comes from two types of uncertainty. Aleatory uncertainty, which is the naturally occurring yields variances in the underlying processes. This uncertainty is handled with cost, schedule, and technical performance margins. Epistemic uncertainty comes from probabilistic processes that can be addressed with handling responses.

The idea of risk and its management and handling is a critical success factor for all software development.

One of the most rigorous theorems of economics [1] proves that the existing means of production yields greater economic performance only through greater uncertainty that is, through greater risk. While it is futile to try and eliminate risk, and questionable to try and minimize it, it is essential that risk be taken be the right risks...
We must be about to choosing rationally among risk-taking courses of action, rather than plunge into uncertainty on the basis of hunch, hearsay, or incomplete experience, no matter how meticulously quantified.
- Peter Drucker (1975) Management (From The Principles of Software Engineering, Chapter 6, Tom Glib, 1988).

Managing in the presence of risk - and the uncertainty that creates the risk - requires we make risk-informed decisions. These decisions are informed by the probabilistic and statistical outcomes of those decisions in the future. In order to make risk-informed decisions, we must estimate the outcomes and the impacts of those outcomes on future activities (cost, schedule, and technical performance of products and services). Without these estimates, there is no risk management. And as Tim Lister reminds us 

Without these estimates, there can be no risk management. And as Tim Lister reminds us 

Risk Management is how Adults Manage Projects. Be an adult, make estimates of the future outcomes of your risk informed decisions. 

[1] Control or Economic Law Paperback, Eugen von Boehm-Bawerk, 2010.

[2] "How Much Risk is Too Much Risk," Tim Lister, Boston SPIN

[3] "Risk Management is How Adults Manage Projects," Susanne Madsen 

[4] "Risk Management and Agile Software Development," Glen B Alleman

Related articles Essential Reading List for Managing Other People's Money Risk Management is How Adults Manage Projects Herding Cats: Economics of Software Development Herding Cats: Managing Uncertainty, Risk, Threat, and Opportunity What is a Team? Logically Fallacious Friday Herding Cats: Risk Management Capabilities Based Planning Herding Cats: Pictures About Managing in the Presence of Uncertainty Intellectual Honesty of Managing in the Presence of Uncertainty
Categories: Project Management

Scrum & Tests Refactoring in Methods & Tools Winter 2016 issue

From the Editor of Methods & Tools - Mon, 01/09/2017 - 13:36
Methods & Tools ‚Äď the free e-magazine for software developers, testers and project managers ‚Äď has published its Winter 2016 issue that discusses Better Retrospectives, Refactoring Tests, Delivering Scrum Projects and the following free software tools: doctest, MarkupKit. Methods & Tools Winter 2016 issue content: * Making Sprint Retrospectives Work * Embracing the Red Bar: […]

Spring Cloud Contracts and Spring Cloud Services on PCF

Ben Wilcock - Mon, 01/09/2017 - 12:07

We had a customer recently who were quite interested in the idea of using Spring Cloud Contract¬†(SCC) in order to prevent API ‘drift’ between microservices teams where individual development teams look after the individual API’s that form part of an enterprise application.

Spring Cloud Contract is an implementation of the ‘Consumer Driven Contracts‘ concept for the Spring platform. From the docs…

Spring Cloud Contract provides support for Consumer Driven Contracts and service schemas in Spring applications. [It provides] a range of options for writing tests, publishing assets, and asserting that a contract is kept by both producers and consumers. It works with both HTTP and message-based interactions.

To help the customer get started with SCC, I created a demonstration app for them that used the 1.0 GA version of the Ssoftware. During this¬†process, I learned that SCC is undergoing some rapid development at the moment and this meant that SCC v1.0 was occasionally a little bit ‘temperamental’ when things like filenames or folder locations change within your project. I found first few days with SCC were a learning curve but I did come to love it as the results of my effort were paid off.

I found that Spring Cloud Contract publishes very clear and helpful information about your services, improves the clarity of your testing, adds fantastic¬†wiremock stubbing capabilities, and alerts you early to any API drift which may have occurred between projects (which is essential in multi-team microservice development environments). I’ll definitely¬†be recommending SCC to clients in the future.

To try and help other newbies out, I used the original SCC samples but added plenty of¬†comments¬†into the code and the README’s to make it easier for people to just pick it up and run with it.

The code for the demo is here:

Extra Credit – Spring Cloud Services on PCF

The same customer also wanted a demo of the Spring Cloud Services (SCS) components for Pivotal Cloud Foundry so I built one and added additional Zipkin tracing (not part of SCS) into the mix. This demo should make it super easy for anyone giving PCF and SCS a trial run. It should even work on PCF Dev (if started with the SCS services) so any Spring developer, even those without PCF access at work can still give it a try. 

I enjoyed building them, and I hope that these are useful to you.

About the Author

Ben Wilcock works for Pivotal as a Senior Solutions Architect. Ben has a passion for microservices, cloud and mobile applications and helps Pivotal’s Cloud Foundry customers to become more responsive, innovate faster and gain greater returns from their software investments. Ben is a respected technology blogger who’s articles have featured in DZone, Java Code Geeks, InfoQ, Spring Blog and more.

Categories: Architecture, Programming

Quote of the Day

Herding Cats - Glen Alleman - Mon, 01/09/2017 - 00:36

It is very tempting to rely on what you are experiencing - Marlene Cimons

Categories: Project Management

SPaMCAST 425 ‚Äď Annual Tune-Up Ideas, Leadership, Kanban, Flow and Throughput


Listen Now
Subscribe on iTunes
Check out the podcast on Google Play Music

Happy New Year!  

SPaMCAST 425 features our annual tune-up ideas. We need to strive to be more effective and efficient every day or the world will pass us by!  These are suggestions that have worked for me and might be useful for you.

We will also have columns from Steve Tendon with another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here).  Steve and I talked about Chapter 14 which covers kanban, flow, and throughput.  

Anchoring the cast is Gene Hughson’s Form Follows Function Blog with an entry in his theme of leadership patterns and anti-patterns.  This week we talk about The Great Pretender.

Remember that Penny Pullan in SPaMCAST 424 offered listeners a great offer!  Penny provided a coupon for her new book  Virtual Leadership for 20% off.  Use the code  VLF20 at, which includes post and packing in the UK and the USA.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we deliver final thoughts with three final takeaways.  

Next week we begin the re-read of Carol Dweck’s Mindset, buy a copy this week.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.


The Software Process and Measurement Cast 426 features our second annual roundtable.  Almost all of the SPaMCAST contributors discussed a number of topics, including:

  1. Is software quality really one of the most important focuses in IT in 2017?
  2. Even though people are adopting agile, is agile as principle-driven movement over?
  3. In 2017, will security trump quality and productivity?

The multiway discussion was exciting and informative!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

SPaMCAST 425 - Annual Tune-Up Ideas, Leadership, Kanban, Flow and Throughput

Software Process and Measurement Cast - Sun, 01/08/2017 - 23:00

Happy New Year!  

SPaMCAST 425 features our annual tune-up ideas. We need to strive to be more effective and efficient every day or the world will pass us by!  These are suggestions that have worked for me and might be useful for you.

We will also have columns from Steve Tendon with another chapter in his Tame The Flow: Hyper-Productive Knowledge-Work Performance, The TameFlow Approach and Its Application to Scrum and Kanban, published by J Ross (buy a copy here).  Steve and I talked about Chapter 14 which covers kanban, flow, and throughput.  

Anchoring the cast is Gene Hughson’s Form Follows Function Blog with an entry in his theme of leadership patterns and anti-patterns.  This week we talk about The Great Pretender.

Remember that Penny Pullan in SPaMCAST 424 offered listeners a great offer!  Penny provided a coupon for her new book  Virtual Leadership for 20% off.  Use the code  VLF20 at, which includes post and packing in the UK and the USA.

Re-Read Saturday News

In this week’s re-read of The Five Dysfunctions of a Team  by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing), we deliver final thoughts with three final takeaways.  

Next week we begin the re-read of Carol Dweck’s Mindset, buy a copy this week.

Visit the Software Process and Measurement Cast blog to participate in this and previous re-reads.


The Software Process and Measurement Cast 426 features our second annual roundtable.  Almost all of the SPaMCAST contributors discussed a number of topics, including:

  1. Is software quality really one of the most important focuses in IT in 2017?
  2. Even though people are adopting agile, is agile as principle-driven movement over?
  3. In 2017, will security trump quality and productivity?

The multiway discussion was exciting and informative!

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: ‚ÄúThis book will prove that software projects should not be a tedious process, for you or your team.‚ÄĚ Support SPaMCAST by buying the book here. Available in English and Chinese.


Categories: Process Management

Risk Management

Herding Cats - Glen Alleman - Sun, 01/08/2017 - 20:27

Risk Management is How Adults Manage Projects - Tim Lister

Risk ManagementRisk Management requires making estimates of many things. The uncertainties that create the risk - reducible (Epistemic) and irreducible (Aleatory), the impacts from the risks, the efficacy of the corrective actions, the residual reducible uncertainty, and any changes in the irreducible uncertainties.

Just like risk management, estimating is how adults manage projects. No risk management no adult managemnt. No estimates, no adult management. Since as that. 

Categories: Project Management

Five Dysfunctions of a Team, Patrick Lencioni: Re-Read Week 15, Final Thoughts

Five Dysfunctions of a Team

Five Dysfunctions of a Team

Over the past 14 weeks, we completed a re-read of  The Five Dysfunctions of a Team by Patrick Lencioni (Jossey-Bass, Copyright 2002, 33rd printing).  The book lays out a hierarchal model of the dysfunctions that can plague a team or organization. For me, there are three main takeaways.  The first is the model of the five dysfunctions. They are:

  • Dysfunction 1: Absence of Trust
  • Dysfunction 2: Fear of Conflict
  • Dysfunction 3: Lack of Commitment
  • Dysfunction 4: Avoidance of Accountability
  • Dysfunction 5: Inattention to Results

As we noted earlier in the re-read, you can think of each of dysfunction as a card in a precariously balanced house of cards.  Each card is important and, if withdrawn, the whole structure will collapse.  Each dysfunction builds on each other and,  unless dealt with, can poison a team or organization.  When using the model to facilitate the behavior change of a team, use the overall model as a critical reminder that you can’t just jump to the end state. Improving any team requires the application of careful and concerted effort continuously over time.  

The second takeaway is that trust is always the starting point. The model is built on trust. ¬†Lencioni is not the first person to recognize how critical trust is to effective organizations. ¬†In SPaMCAST 424 Penny Pullan quoted Tom Wise who defines trust as credibility plus reliability plus intimacy divided by self-orientation. ¬†We will tackle this equation in a future blog entry; however, it is important to recognize that trust is a complex topic that doesn’t just emerge from a meeting¬†but requires facilitation and experience. ¬†The fable that is at the heart of the 5 Dysfunctions makes this point through Kathryn’s Offsite meetings followed the team returning to the office to apply the lessons they learned.

The third takeaway is more of a reminder. One person can poison a team whether through an attribute or putting their needs ahead of the team. The impact reduces the effectiveness and efficiency of the team. In the book, we see examples of characters both with bad attitudes that putt their need or the needs of their department ahead of the goals of the organization.  In the book, Nick’s behavior came to a crisis over the acquisition he proposed. The crisis helped him decide to commit to the team. Mikey’s crisis, on the other hand, forced Kathryn to remove the poison with the organization.

Since my initial read of 5 Dysfunctions, I have measured teams against the model Lencioni laid out in the book. ¬†The model has been useful for me to plot a path to coach for coaching and in some cases even to know just how far I plan to help a team evolve. ¬† Lencioni’s book is a tool that is useful for anyone that leads a team or coaches a team or organization. ¬†I am glad I have it on my bookshelf!

Next week we begin the re-read of Carol Dweck’s Mindset, buy a copy this week.


Previous Installments in the re-read of  The Five Dysfunctions of a Team by Patrick Lencioni:

Week 1 ‚Äď Introduction through Observations

Week 2 ‚Äď The Staff through the End Run

Week 3 ‚Äď Drawing the Line though Pushing Back

Week 4 ‚Äď Entering Danger though Rebound

Week 5 ‚Äď Awareness through Goals

Week 6 ‚Äď Deep Tissue through Exhibition

Week 7 ‚Äď Film Noir through Application

Week 8 ‚Äď On-site through Fireworks

Week 9 ‚Äď Leaks through Plowing On

Week 10 ‚Äď Accountability through The Talk

Week 11 ‚Äď Last Stand through Rally

Week 12 ‚Äď Harvest through The March

Week 13 ‚Äď Model Overview through Team Assessment

Week 14 – Model Overview


Categories: Process Management

Economics of Software Development

Herding Cats - Glen Alleman - Sat, 01/07/2017 - 22:15

Making decisions in the presence of uncertainty with limited resources is the domain of Macro and Micro Economics

Making decisions in resource-limited situations at the national or global scale is macroeconomics. Macroeconomics is the study of how people make decisions influenced by tax rates, interest rates foreign policy, and trade policy. Microeconomics is the study of how people make decisions on a personal scale and treats decisions that individual and organizations make. For example, about which software to buy, which Features in the development backlog should be implemented next, what prices to charge for products and services.

Software development is an exercise in microeconomics, since it deals with limited resources - time, cost, and what value is produced in exchange for the time and money.

Because of the limitations of resources, projects need to operate withing a world of limited resources, the uncertainties - both reducible and irreducible - that create risk, and the emerging attributes of all project work. This is the foundation for estimates. Estimates with accuracy and precision values needed to make credible decisions. These estimates are critical to both developers and customers. Underestimating software engineering costs could result in management approving proposed systems that potentially exceed budget allocations, or underdeveloped functions with poor quality, or a failure to complete a project on time. Overestimating costs may result in too many resources committed to a project, or, during contract bidding, result in losing a contract and loss of jobs.

These estimates are used for generating requests for proposals, contract negotiations, scheduling, monitoring, and control.

Managing in the presence of uncertainty requires a Closed Loop Control process. Where targets are set, work is performed, feedback received, corrective actions taken it steer toward the target. Without that target and the error bands on the target and the processes used to steer, Close Loop Control will be ineffective - constantly chasing a moving target, with understanding of what could result, versus what should result. 

Accurate and precise estimates - with predefined values for the accuracy and precision needed to satisfy the attributes of the Closed Loop Control system - are needed because:

  • The work and the outcomes of that work must be classified and prioritized¬†while the project progresses toward the¬†target.
  • Any changes required and assessment of the impact of the change on the cost, schedule, and technical performance of the product or service.
  • To determine¬†what resources¬†to commit to the project and how those resources will be used.
  • Inform those paying for the work, the probability of completing¬†on or before a needed date and¬†at or below needed cost.

Since uncertainty creates risk, managing in the presence of uncertainty is Risk Management. Since risk management is how adults manage projects, † making estimates in the presecnce of uncertanty is adult management.
No Estimates? No Adult Management.

Here are three starting resources for Software Economics:

  1. Software Engineering Economics, Barry Boehm
  2. The Economics of Software Quality, Capers Jone, and Olivier Bonsignou
  3. The Economics of Iterative Software Development": Steering Toward Better Business Results, Walker Royce, Kurt Bittner, Mike Perrow

† Tim Lister, Risk Management is Project Management for Grownups


Related articles Pune: Bangalore man arrested in connection with brutal murder of software engineer Economics of Software Development I Think You'll Find It's a Bit More Complicated Than That Logically Fallacious Friday Complex, Complexity, Complicated Herding Cats: Managing Uncertainty, Risk, Threat, and Opportunity Essential Reading List for Managing Other People's Money
Categories: Project Management

Conferences, Events and Webinars


Many of the contributors to the Software Process and Measurement Cast are give webinars, attend and present at conferences.  On a monthly basis, I will provide a list of webinars and conferences that we will be attending. If I get discount codes for any of the conferences I will pass them on to you!

Webinars (All Free)

ITMPI AGILE TECHNICAL PROJECT MANAGEMENT Storytelling: Developing the Big Picture for Agile Efforts Tuesday, Feb 07, 2017 |11:00 AM EST  

Agile reminds us that the focus of any set of requirements needs to be on an outcome rather than a collection of whats and whos. This webinar, presented by Tom Cagley, explains the importance of understanding the big picture. REGISTER NOW

SAFe 4.0 and CMMI Deliver Hardened Large-Scale Agile February 24, 2017 | 11:00am CT

Presenters: Tom Cagley, Certified Scrum Master and Function Point Specialist, and Magdy Hanna, Chairman and CEO of International Institute for Software Testing (IIST). SAFe 4.0 and CMMI Deliver Hardened Large Scale Agile demonstrates how the combination of SAFe 4 and CMMI provides a mechanism not only to adopt Agile but to scale and harden Agile from team to the program without becoming un-Agile.  Register Now

How To: Agile Estimating and Function Point Analysis March 16, 2017 | 11:00am EST

Join Tom Cagley, Certified Scrum Master and Function Point Specialist, to learn how to incorporate Function Point Analysis into an Agile metrics program. Attendees will leave with an understanding of an estimation process that combines one part functional metrics and one part parametric estimation with two parts Agile estimating and planning.  Register Now



ISMA 13: ‚ÄúCreating value from measurement‚ÄĚ

The Mumbai Chapter of the Computer Society of India (CSI,) with the support of IFPUG, is the host organization for the next International Software Measurement & Analysis (ISMA) conference, ISMA 13, to be held in Mumbai (India) on March 5-7, 2017.

Date: March 5-7, 2017

Location: Mumbai, India,

I will be speaking, keep an eye out for the title of the presentation.


The QUEST conference is the best source for new technologies and proven methods for Quality Engineered Software and Testing.

Date: April 3-7, 2017

Location: The Renaissance Chicago Downtown; Chicago, IL

Tom Cagley will present or be involved in the following sessions:

Managers Workshop РApril 3, 2017. The Manager’s Solutions Workshop focuses on the top challenges facing managers in building, testing, and delivering quality software applications and products in today’s fast-paced and demanding environment.

Storytelling: Developing the Big Picture for Agile Efforts – Tuesday, April 4, 2017 | 8:30 am ‚Äď 12:00 pm. Storytelling is a powerful tool to elevate even the most diehard requirements analyst from a discussion of individual requirements to a discussion of outcomes.

Using Size to Drive Testing in Agile РWednesday, April 5, 2017 |11:15 am Р12:15 pm.  

Testers often struggle with estimating and planning testing in agile development, enhancement and maintenance projects.

Jeremy Berriault we also attend QAI Quest 2017 and present:

Adding QA Value through Root Cause Analysis РFriday  April 7, 2017 |10:00 am Р11:00 am.  Decisions are made based on the data available at the time of the decision.

Capability Counts 2017 – May 16 – 17 |

Join hundreds of global business leaders dedicated to performance and capability improvement from an array of background, countries, and experiences.

Date: May 16 – 17, 2017

Location: Westin, Alexandria, VA

Tom Cagley will present and participate in the following:

Coaches Cafe, Capability Challenge and a presentation (I will wait for the program to be announced)


Categories: Process Management

Learn tips from Memrise to increase in-app conversions with pricing experiments

Android Developers Blog - Fri, 01/06/2017 - 22:29
Posted by Tamzin Taylor, Partner Development Manager at Google Play, & Kristina Narusk, Head of Production at Memrise

Getting people to install your app is one thing, getting them to sign up to your paid offering is quite another. It's important to understand the complete journey your users take from installing your app to paying for something. Once you do, you can experiment on the flow to try and increase conversions. Memrise has found great success in experimenting on their language learning app to increase the number of paying users.

Four experiments Memrise use to improve conversions

Memrise makes languages fun with a number of different learning modes you can play to help increase your vocabulary in a chosen language. You can download the app for free and play some of the modes or take advantage of their premium subscription offering called 'Memrise Pro' which offers new game modes and additional features like offline learning. Memrise recently ran a number of conversion experiments with the main objective of increasing the Average Revenue Per Daily Active User (ARPDAU). These experiments tested multiple user experience and pricing experiment scenarios.

1. A/B test how messaging different user benefits can impact conversion

What they did: Memrise wanted to know what motivation and call to action would convert the most users to buy a Pro subscription from a locked game mode in the app. To do this, they ran an A/B test with two similar designs, featuring different reasons for the user to upgrade, and compared the results to their original upgrade messaging.


Test A: Focus on ‚Äėdifficult‚Äô words with an orange background. Test B: Focus on ‚Äėfavorite‚Äô words with a pink background.
Results: Test A performed the best. Conversion to Pro in Test A was 28% higher than in Test B. Pro mode usage was subsequently 9.7% higher in Test A compared to Test B too.

Next steps: After seeing how test A won the experiment, Memrise applied this creative across the board. Subscribers driven by that particular mode increased as a percentage of all subscriptions in the app by 16%. Memrise plans to run additional A/B tests at others points of conversion in the app to see if they can increase the results even further. They'll also try different text for the call to actions.

2. Test whether adapting to local price points results in sustainable uplift

In 2015, Google Play launched new minimum local price levels in countries around the world. To take advantage of the new price points, Memrise tested lowering localised prices in certain markets to better match purchasing power. Prices were an average of 6 times lower during this experiment.

Results: After 30 days, Memrise saw the following changes in conversions to paid users:

Categories: Programming

Stuff The Internet Says On Scalability For January 6th, 2017

Hey, it's HighScalability time:


Hot rods in space. The Smith Cloud plummets towards our galaxy at nearly 700,000 mph. Vroom!
If you like this sort of Stuff then please support me on Patreon.
  • 3 of top 5: Stackoverflow questions are about Git; 3,000: four-passenger cars could serve 98 percent of NYC taxi demand; 44%: US population lives within 20 miles of Amazon fulfillment center; 72%: Amazon customers shopped using mobile device; 110%: increase in industrial control system attacks; 455: Number of scripted television series aired this year; $28.5 billion/yr: App downloads on iOS;

  • Quotable Quotes:
    • @ValaAfshar: Number of robots working in Amazon warehouses: 2016: 45,000 / 2015: 30,000 2014: 15,000 / 2013: 1,000 — @JonErlichman
    • @jason_kint: updated duopoly #s. new IAB data came out yesterday. easy to run vs earnings for goog and fb, it's evident everyone else is zero sum game. 
    • rb2k_: I also haven't seen one [company in Germany] that isn't riddled with MBA grads that mainly push Jira tickets around.
    • Joe McCann: The best software developers I know are always hacking over the holidays. True story.
    • @kaffeecoder: Sigh. Async vs blocking protocol is irrelevant. What matters is communicating with other services outside your own req/response cycle.
    • Eric Jang: It's not a coincidence that Nvidia, the literal arms-dealer of deep learning, has had a good year in the stock market.
    • @markimbriaco: Just read a comment that said "Any good codebase has every part perfectly isolated". Oh, to be young and optimistic about software again.
    • @swardley: Asked "What do I think is the biggest impact AI would have?" ... hmmm, the largest erosion of social mobility in human history?
    • The Attention Merchants: It is therefore more effective for the State to intervene before options are seen to exist. This creates less friction with the State but requires a larger effort: total attention control.
    • StorageMojo: The cloud’s collateral damage to the legacy IT vendors continues to spread. A few billion here and a few billion there, and pretty soon you’re talking real money.
    • Janakiram MSV: The key takeaway is that Amazon wants enterprises to consume EC2 while it is pushing startups and developers towards Lambda. This move from Amazon will fuel the growth of serverless computing in the industry. 
    • Maxime Chevalier-Boisvert: Edsger Dijkstra famously said, “The question of whether machines can think is about as relevant as the question of whether submarines can swim.”
    • @karlseguin: Microservices without asynchronous messaging (queues) is actually a monolith with really slow and error prone method invocation.
    • AshleysBrain: We've been using WebRTC Datachannels for multiplayer gaming in the browser in our game editor Construct 2 ( for a couple of years now. Generally they work great! However the main problem we have is switching tab suspends the game, which if you're acting as the host, freezes the game for everybody. This is really inconvenient. 
    • @lstoll: 2017: Year of the return of three tier architecture.
    • @tealtan: “I will never make a racial profiling database!” *continues working on social networks, analytics, ad tech*
    • @abt_programming: Inverse bus factor: "how many developers have to be hit by a bus before a project starts to proceed smoothly?” - @gasproni
    • M.G. Siegler: The numbers speak for themselves. 2 billion words written on Medium in the last year. 7.5 million posts during that time. 60 million monthly readers now. Pageviews galore. So step 2 is simply to slap some banner ads on the site, while step 3 is to profit, right?
    • snarf21: Writing software is hard but to me the hardest part is always taking a random abstract concept from someone's mind (or worse, several people) and converting that into something "real" in a fixed timeline and budget. There will have to be lots of tradeoffs and miscues by definition. We are always making something that doesn't already exist, it is creation and creation is hard.
    • @Pinboard: Who could have foreseen the always-on home microphone might be of interest to the cops?
    • @ThePracticalDev: I heard a rumor that Santa moved over to AWS this year. Big if true.
    • Drew Purves~ “intelligence” extends beyond brains; something as simple as self-replicating RNA exhibit intelligent behavior at the evolutionary scale. The natural world is fractal, cyclic, and a biosphere, every organism is a resource to another organism. That is, learning and adaptation of each organism is not independent of other organisms
    • @meatcomputer: System clocks are always accurate and increase monotonically. Timestamps from remote machines are reliable
    • pjmlp: Everything on web development feels like an hack.
    • @kelseyhightower: In my opinion Serverless does not mean FaaS. I consider any platform that hides the management of servers from the user to be Serverless.
    • Amit: one of the lessons I learned from this journey was that the tutorials work best when I've needed that technology for a real project
    • @Carnage4Life: Snapchat' copied all the worst parts of Apple's culture & seen success. More copycats to come
    • ch: So all that's missing with the decentralized web is a centralized service to aggregate the decentralized streams?
    • @mathiasverraes: "Separation of intent and implementation" is probably a much more useful programming principle than all of SOLID combined.
    • doh: We moved back and forth between AWS and GCE (based on who gave us free credits). Once we ran out, we chose GCE and never regretted it. GCE has many quirks, for instance the inconsistency between API and the UI, it misses the richness of the services offered by AWS but everything GCE does offer is just faster, more stable and much more consistent.
    • Exponential Laws: We have argued that exponential growth would not have succeeded without sustained exponential growth at three levels of the computing ecosystem—chip, system, and adopting community. Growth (progress) feeds on itself up to the inflection point.

  • Measuring a gnat's eyebrow at a billion miles. Ivan Linscott tells the thrilling story behind the development of the New Horizons probe to Pluto. a16z Podcast: New Year, New Horizons — Pluto!  Completing the probe was a close thing. Finding enough plutonium to power system almost didn't happen. Enough wasn't found so the probe had a much lower power budget than originally spec'ed, which caused the communication system to use one FPGA instead of two. You have to use radiation hardened parts. The chips sit right next to a pile of plutonium pumping out gamma rays and neutrons. The FPGA's had a capacity of a million gates, were hardened by design, and had triple redundancy. Each gate in the array is implemented in threes. They are voted in pairs. If three agree then fine. If two agree that's the value used. They fit all the code with 5 gates margin. They also had a hero's journey sourcing a high precision oscillator. And then the frightening story of when the watchdog timer timedout and put the probe in safe mode. It turned out the JPEG compression algorithm took too long to compress an image of Pluto and that caused the timeout to fire. The reason is one of those crazy testing stories. When this feature was tested the picture of the sky was darker so it took less time to compress!

  • The impulse for folks at Twitter to delay Trump's tweets and insider trade on that information must be overwhelming.

  • 33C3 (Chaos Computer Congress) videos are now available. Great overview by Chris Hager. Lots of interesting talks. You might like: Dissecting modern (3G/4G) cellular modems; Edible Soft Robotics - An exploration of candy as an engineered material; Software Defined Emissions - A hacker’s review of Dieselgate; Rebel Cities - Towards A Global Network Of Neighbourhoods And Cities Rejecting Surveillance.

  • A compelling break down of the DNC phishing attack. Making everything viewable through a generic UI and everything programmable through a scriptable API has interesting consequences @pwnallthethings: Could have hacked? Sure. Did hack? No. Let me go through why not..The hackers weren't hacking one-by-one; so URL contraction wasn't done manually. It was done via the Bitly API...Why did the hackers include this info? Same reason they contracted links via API. Because they're not hacking 1-by-1. Are hacking at scale...When hackers hack at scale, they reuse infrastructure. They make mistakes. This isn't unusual. You can piece the bits together.

  • In the game of data you want to be at the top of the data gravity well. When your are down well nothing escapes without great cost. AWS Snowball

Don't miss all that the Internet has to say on Scalability, click below and become eventually consistent with all scalability knowledge (which means this post has many more items to read so please keep on reading)...

Categories: Architecture

Guest Post: Agile and Leadership

David Herron

The following is a guest post from a long time friend whom I have worked for and worked with. ¬†Sometimes we agree and sometimes we don’t, however, I always respect his opinion and wisdom.

Agile and Leadership
David Herron (

It took me a while to get used to the fact that agile development does not incorporate the use of a project manager position. Having been brought up in a traditional waterfall, PM-centric software development environment, it was difficult for me to make the transition (mentally) to agile. After all, how can a project stay on budget and be delivered on time without following sound management principles? If there is no one at the helm to manage the project and to steer things in the right direction, how can things possibly progress and stay on track! Who is leading the way? The Agile methodology advocates for self-organizing teams. That was a foreign concept for me to get my mind around.

I have now been around enough successful agile projects and have observed first-hand that ‚Äėproject management-less‚Äô agile works. It works, in part, because agile (Scrum) promotes a team dynamic and provides a framework that demands discipline and incorporates well-defined principles and practices to guide the way. Agile promotes self-organizing teams, the meaning of which I stretch to include self-managing as well. But how can a team lead itself? What makes agile work? Where is the leadership?

As I searched for answers to that question I turned to the experts. In their highly regarded book, ‚ÄėThe Leadership Challenge‚Äô, Kouzes and Posner identify five fundamental practices of successful leaders. It turns out that the Scrum framework and the mindset of the agile team incorporate characteristics we find in successful leaders. Studies by Kouzes and Posner have shown that leaders: challenge the process; inspire a shared vision; enable others to act; model the way, and encourage the heart. These elements can be observed in agile practices.

Kouzes and Posner have observed that individuals, regardless of their position in the company, can develop their capacity to lead. Leaders care to make a difference. Doesn’t that sound like the members of an agile team? Leaders are willing to challenge the process. They have a shared vision of an improving the process for a better outcome. The Agile frameworks such as Scrum provides a model or a guideline of how to move through the process; how the work should flow. Scrum enables others to act; enables everyone to act through defined roles. All this requires hard work. As one small success builds upon another, there is cause to celebrate those accomplishments and to recognize both team and individual efforts.

Challenging the process

Defined – Change the status quo, innovation, look to improve, experiment (and take risks)

If you have decided to move from waterfall to agile then you have decided to try something different. Perhaps something better. Something to improve the way you currently develop and deliver software. You could say that you are changing or at least challenging the status quo.

As excitement builds around the thought of venturing into new territory, the team has taken on the challenge of doing something different. Not everyone likes change and not every team member will necessarily have bought into the process. But everyone is aware that they are doing something different. They may see it as an experiment and consider it to be taking risks. The ideal team composition will be a collection of team members that are advocates for agile.

Inspiring a shared vision

Defined – Make a difference, envision the future, and enlist others

A project team about to embark on an agile project has, typically, been properly trained and is prepared to begin the journey. If it is one of their first attempts at agile, then the team is most likely comprised of individuals that share the agile ‚Äėvison‚Äô. They have a sense of what is possible. They are excited about being able to make a difference. Not everyone will be onboard, but those that are will most likely try to bring the others along.

Moving forward into the ‚Äėunknown‚Äô each member of the newly formed agile team will have a vision of what to expect. Through their initial agile training, they have learned about agile practices and principles and what their roles and responsibilities will be. They have a shared vision of how they will be working as a team.

Enabling others to act

Defined – Collaboration, spirited teams, atmosphere of trust, and each person is empowered

How does agile incorporate these characteristics? Scrum serves as a great example. Within Scrum, there are assigned roles and disciplines that foster an atmosphere of trust. Each person has a role to play and each role is equally important to the success of the desired outcomes. Scrum requires collaboration and teams learn to self-organize and work together towards a shared vision of desired outcomes.

The daily standup is a good example of collaboration and developing an atmosphere of trust. Each individual is recognized and participates in the standup meeting. Team members are encouraged to be open and honest and to look to serve the teams objectives, helping other team members when and where possible.

Modeling the way

Defined – Create standards of excellence, examples, establish values, achieve small wins, and create opportunity for victories

There are various approaches/models to agile, e.g. scrum, XP, Kanban, just to name a few. To call these standards would not be the agile way, but they are all very well defined within specified boundaries. They all incorporate, to one degree or another, lean principles. The goal is to have a process whereby the workload is managed to maximize efficiency and effectiveness of the flow of work.

Using Scrum, the workflow is managed using time-boxed iterations. Each iteration delivers a number of user stories (small wins). The cycle is repeated and the flow is adjusted until the team has reached a repeatable velocity of delivered working software.  Frequently delivered software is in itself an achieved victory, a small win.

Encouraging the heart

Defined – Hard work, keeping hope alive, celebrate accomplishments

One of the first myths I heard about agile was that there were no rules, no documentation, and no discipline. Like most myths, it simply isn‚Äôt true. Agile is hard work. I would contend that in order to be successful, agile requires a great deal of discipline and adherence to defined practices. Various ‚ÄėF‚Äô words come to mind when I think of agile; flexibility, flow, freedom, fun. Agile encourages the brave at heart to experiment within the principles of the agile methods being used. One size or one model does not fit all.

There are of course other elements of agile methodologies, such as the incorporation of lean principles, which contribute to the positive outcomes of using an agile approach. I doubt that the ‚Äėfounders‚Äô of agile, those individuals that came together to create the agile manifesto, started with a foundation of leadership principles. The connections to these leadership principles are simply my observation and possible rationalization for why, in part, agile works. Using that as a starting position, it would stand to reason that agile practices can be enhanced by training individuals to become better leaders.

Leadership training is not something we hear a lot about. We subscribe to the belief that we can train people to become better project managers, but we seldom think about leadership training. If individuals can develop their capacity to lead then why not make that investment in training everyone to be a leader. A leader does not have to be an individual in a management position. Sports teams usually have a number of senior players and one or more individuals labeled as captains, but they are not necessarily the team leader(s). Leadership may not come naturally to some, but people can be trained and encouraged to be leaders. Given the proper atmosphere, one where ‚Äėthinking outside the box‚Äô is encouraged, organizations can expand their capacity to produce and to innovate as individuals pick up the challenge and lead the way.

Categories: Process Management

Downsizing society

Actively Lazy - Thu, 01/05/2017 - 21:38

The world is becoming increasingly automated. Jobs that were once done by people are now frequently done by machines instead. This started off in manufacturing, but the coming of self-driving cars will put huge numbers of people out of work; even lawyers are being replaced by machines. Some reports suggest that machines could do 50% of jobs within the next 30 years. Fifty percent! What will we do when half the population have been made redundant? How will we cope with such a restructuring of society?

To an economist, a job is an income. To a human being, it is much more than that. It provides a sense that you matter in society, that people beyond your family rely on you and even admire you.

If 50% of jobs are being done by machines, the question is¬†what will people do instead? This is an important question, because we identify as our job. Our jobs define us. Let me introduce you to Louise, she’s a doctor. And this is Barry, he’s an estate agent. I bet you have different ideas of who those two people are. What about when they’re both unemployed? Unemployable. Made redundant from society.

How would so many people survive without jobs? Where’s the money to live coming from? The only possible answer seems to be some kind of universal basic income. The idea that everyone, employed or not, receives a fixed amount of money each month from the government – replacing all existing benefits and all the bureaucracy involved in administering them. With a UBI, the 50% of people without jobs would at least have some money with which to buy food and heating. But who wants to live on handouts? Who wants to be defined as unemployed? Even if the majority of people are in the same situation.

This inevitably results in a two-tier society: those that earn little to nothing on top of the basic income; and those increasingly rare few that still have jobs the machines aren’t able to do, yet. We have the non-working class, and a diminishing middle class. How can this cause anything other than resentment, envy and anger?

This is to say nothing of the challenges of funding a universal basic income. While ideas like funding it through a wealth tax make a lot of sense, could they ever succeed? Would the wealthy half ever vote for it? Would the big businesses (and their very wealthy owners) that bankroll governments stand for it?

As Brexit and Trump have shown, voters can vote for what previously seemed impossible. And we’ve barely scratched the surface of the anger and disenfranchisement that automation will bring upon us. However, with both Brexit and Trump people¬†voted out of¬†hope. Hope for something better. For respect. For status. For jobs. Could Farage evoke such a passionate response from a platform of “more handouts”? Of massive wealth redistribution, the likes of which no socialist government has ever even proposed? It seems improbable.

If we don’t introduce a UBI, what’s going to happen? The jobs that are left aren’t going to be spread evenly. London will always have disproportionately more jobs and lower unemployment than, say, Sunderland¬†or Hull. What’s going to happen in these areas as unemployment becomes endemic? Rising anger seems inevitable. Riots. A public whipped into a frenzy of hatred against some group of “others”?

With so much anger, extreme politics is only going to increase. Does a majority of the public already feel left behind? Made redundant by automation? So far this has given us Brexit and Trump. It’s only going to get worse. Who are we going to wage war on? Syria? ISIS? China? Germany? This is the armageddon outcome. So many people feel so disenfranchised that we inadvertently start world war three.

What other outcomes are there? Another possibility is some kind of neo-luddite movement railing against technology. So far everyone’s anger at disappearing jobs has been directed at migrants. When people realise its actually technology taking their jobs, could that anger end up directed at technology instead? You can imagine someone like Farage standing against technology. Of banning automation. Of holding back progress to protect jobs. While this couldn’t hold back the tide forever, it could delay the inevitable march of technology for some years.

The flip-side of this neo-luddite revolution, is the inevitable flight of technology outside of such a regime. With the future being held back in one place, technologists will move somewhere else; to somewhere innovation is encouraged instead of criminalised. Some enterprising country, say Switzerland, would reduce taxes for technology companies to encourage them to relocate. The remaining jobs, and the people to do them, all move to an employment enclave. This exacerbates the split in society: between the wealthy employed few, and the many under-employed poor. This is the “Switzerland outcome”. A physical as well as economic split in society.

Of course, there is always the possibility that the jobs that disappear are replaced by new jobs. Jobs in manual labour become replaced with jobs like “social media consultant” that would have been unimaginable in Victorian England (some would say still are). But the signs aren’t good: in the wake of the 2007 financial crisis jobs aren’t returning in great numbers – they’re being done by robots instead. This might be the first economic recovery in history that hasn’t been accompanied by an increase in employment.

Eventually we’re bound to discover a universal basic income, or something like it. It might take a very long time – a time in which the social strife could be immense. But eventually, barring armageddon, we will have to find a way to move to a post-work society; that means finding a way for people without work to live happy, fulfilled lives.

But in a life without work, how will people find meaning in their lives? With the ready availability of automation, some people might move back onto the land – to become 21st century peasant farmers. With the help of machines it could be quite possible for a family to provide for itself and maintain a decent standard of living through farming alone. Of course, with our heavily urbanised society plenty of people have neither the space nor the wherewithal to do this; but for some this could be a good alternative to the slums from where jobs have vanished.

The ready availability of time frees people up for any project they wish to embark on. The utopian outcome is enabling everyone to become creative, to embark on personal projects and self-expression. A society full of people doing what people do best: being human and creative. Is this realistic? Some people would relish the opportunity to dedicate themselves to creative pursuits. But plenty of others would not, instead looking for the structure and security their jobs used to offer.

Could this usher in an era of grand projects? Where people band together to achieve some lofty goal? Not for financial compensation, but for the joy of being part of something bigger. With everyone’s basic needs met, instead of working for money people look for meaning. They will take part in activities that inspire them, for free. The cost of labour at this point is basically zero, for the first time in human history. The only constraint: the end goal has to inspire people. Improving the efficiency of a government department? Hardly. Flying to Mars? Almost certainly.

But there will still be plenty of people who feel they can’t contribute but need structure in their life. Iain M. Banks’¬†Culture series describes a post-work society where the machines run everything; but in Banks’ universe people dedicate themselves full-time to leisure. While no doubt attractive to some, this life seems without structure, without purpose. Can people really live like this? Work has defined us, given structure to our day, given us meaning. Without this, who are we?

It is likely that the end result is some mixture of all of these outcomes. Each individual finding their own way in an increasingly diverse world –¬†the simple answer of finding a job, any job, is no longer possible; instead people are forced to find their own answers to hard questions: what¬†am I going to do with my life?

As we approach this future, what are we to do? How can we prepare for the upcoming earthquake in society? It seems inevitable that this will be a tumultuous time. How can we smooth the transition to a post-work society?

Categories: Programming, Testing & QA

Increasing the Probability of Project Success

Herding Cats - Glen Alleman - Thu, 01/05/2017 - 19:35

Increasing the Probability of Project Success
Simple in Theory, Complex in Practice

When we hear any suggestion about improving the probability of success of a project, there are some simple tests to confirm there actually is such a thing. This means having a set of Principles, Process, and Practices to test the suggestion against. Let's start with the Principles

Let's start with the Principles

Screen Shot 2017-01-05 at 9.51.58 AM

These Five Immutable principles are time phased into Processes that provide answers to the Five Principles.

Picture1and the connections between each Process are made to form a Closed Loop control systems needed to manage any project.

Screen Shot 2017-01-05 at 10.02.00 AM

With some details for each process area

Screen Shot 2017-01-05 at 10.03.09 AM

To support these Principles and Processes, a set of Practices are needed

Screen Shot 2017-01-05 at 10.05.43 AM

These charts are an extract from the book Performance-Based Project Management: Increasing the Probability of Project Success and the abstracted training materials Handbook.

Related articles Doing the Math How to Avoid the "Yesterday's Weather" Estimating Problem Hope is not a Strategy Complex, Complexity, Complicated The Use, Misuse, and Abuse of Complexity and Complex Domain is King, No Domain Defined, No Way To Test Your Idea Herding Cats: Quote of the Day
Categories: Project Management