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

Software Development Conferences Forecast May 2014

From the Editor of Methods & Tools - Tue, 05/27/2014 - 14:50
Here is a list of software development related conferences and events on Agile ( Scrum, Lean, Kanban) software testing, programming (Java, .NET, JavaScript, Ruby, Python, PHP) and databases (NoSQL, MySQL, etc.) that will take place in the coming weeks and that have media partnerships with the Methods & Tools software development magazine: The Reliable Software Developers Conferences, May 20 – June 5, UK Better Software & Agile Development West, June 1-6 2014, Las Vegas, USA GOTO Amsterdam 2014, June 18-20, 2014, Amsterdam, The Netherlands AGILE2014, July 28 – August 1, Orlando, USA Agile ...

Scaling Agile? Think Out, Not Up

I taught the Influential Agile Leader workshop with Gil Broza last week in Edinburgh. (That’s why I was quiet. I was traveling and teaching. No time for writing, blogging or tweeting.)

Possible Small World Network for Nine Agile TeamsOne of the participants asked me what I thought about scaling agile. Before I could explain about small-world networks, not hierarchies, he said, “I am sure the way you scale agile is out, not up.

Well, blow me over with a feather. He said it more simply than I did.

If you look at my picture of a technical program team, you can see that’s how it works.

Technical Program with Communities of Practice

Technical Program with Communities of Practice

The technical program team has feature teams alone, if they can be alone. Joe, Tim, and Henry all have stand-alone feature teams.

If they need to be “collected” because they work on related features, they collect themselves. Sally has collected feature teams.

The teams scale out, at the technical level, not up. The technical program team does not have to get to bigger. When I ran programs in the past, I emailed the program team meeting agenda (it was a problem solving meeting) to everyone, and say, “Here are the people I need to attend. Everyone else: let me know if you are attending.”

Now, there’s a limit to how big a program can get for the software program or the hardware program. At some point, the it’s so hard to coordinate the interdependencies, it’s not worth the bigness.

If the teams are delivering small features all the time, you don’t need as many people as you think you do. The smaller the batch size, the fewer the people required. Your momentum will be greater. If you don’t believe me, think about that for a minute or two.

When you think scaling agile, think out, not up. You use small world networks, and when you say, “think out, not up,” it’s a very nice catch-phrase.

Categories: Project Management

Bounded Applicability

Herding Cats - Glen Alleman - Tue, 05/27/2014 - 04:32

“The basic concept of bounded applicability…simply states that any method or tool has limits. You know you are reaching those limits as the cost/benefit ratio of handling new issues becomes adverse. At this point you should not carry on doing the established approach more furiously, but instead realise that you are approaching a boundary and gain perspective so you can look on the other side.” — elearnspace

When we hear anything about making inmprovements to processes, technology, people, or tools - test if those suggestions have been placed in a bounded applicability.

Categories: Project Management

Dealing with Complexity in Software Projects - The theory that explains why Agile Project Management works

Software Development Today - Vasco Duarte - Tue, 05/27/2014 - 04:00

Why do projects fail? This is a question that haunts all project managers. Good and bad, experienced and beginners, Agile or non-Agile. The reason for that is simple: we believe that if we crack the code of why projects fail, we will be able to avoid failure in our own projects. After all who does not want to be in a successful project?
We believe that if we crack the code of why projects fail, we will be able to avoid failure in our own projects. But before we can can answer such a difficult question, we need to understand the factors that influence project failure. Many will immediately say that lack of planning or bad planning are major causes for project failure. We've all been told that more planning is the solution. And we have been told that the "right" planning is the solution. Sure, we all know that, but does that "right kind of planning" look in practice?
Enter Agile...

We know that "the right planning" is the solution, but we need to have a functional definition of what that "right planning" looks like. Agile has contributed greatly to further our understanding of software projects. For example: thanks to Agile we now can confidently state that individuals and their interactions are a key enabler for successful projects, not just "the right kind of planning". But there is more...

We are also starting to understand that there are some fundamental failures in the existing Theory of Project Management. Thanks for researchers like Koskela and Howell[1] we even have a framework to analyze what is wrong - very specifically - with traditional Project Management. Most importantly, that framework also helps us understand what needs to be different for projects to succeed in the new world of Knowledge Work.

In the article below (sign-up required) I explore the differences between the existing theory of project management and what Agile methods (such as Scrum) define as the new way to look at project management.

This paper explains some of the ideas that are part of  the "Chaos Theory in Software Projects" workshop. In that workshop we review the lessons learned from Complexity and Chaos theory and how they apply to Project Management.

The goal of the workshop is to give project managers a new idea of what is wrong in the current view of project management and how that can be changed to adapt project management to the world of Knowledge work. To know more about the workshop don't hesitate to get in touch: vasco.duarte@oikosofy.com.

[1] Koskela and Howell, The Theory of Project Management: Explanation to Novel Methods, retrieved on April 2014
Picture credit: John Hammink, follow him on twitter

Memorial Day

Herding Cats - Glen Alleman - Mon, 05/26/2014 - 21:09

Memorial-day-wallpapers

We have given some, Some have given all

Categories: Project Management

Conversation with Bob Burg

NOOP.NL - Jurgen Appelo - Mon, 05/26/2014 - 08:58
Bob Burg

Bob Burg is an expert on the topics of influence and persuasion. He is the bestselling (co)author of the The Go-Giver and he recently published the book Adversaries into Allies. In this video interview I chat with Bob about Non-Violent Communication, arrogant narcissists, emotional decisions, anger, and bribing yourself with chocolate.

The post Conversation with Bob Burg appeared first on NOOP.NL.

Categories: Project Management

Quote of the Month May 2014

From the Editor of Methods & Tools - Mon, 05/26/2014 - 07:50
I’m the Leader. I know what needs to be done and how. This is a very dangerous assumption. While Leaders can be expected to have considerable self-confidence, they are often not aware of all the implementation implications. Source: The Agile Culture, Pollyanna Pixton, Paul Gibson and Niel Nickolaisen, Addison-Wesley

The Three Elements of Project Work and Their Estimates

Herding Cats - Glen Alleman - Sat, 05/24/2014 - 04:38

There is still discussion of estimating that starts with fixing the budget as the solution for No Estimating. This of course simply moves the estimating need to the other two elements of all project work.

These three elements are:

  • The technical and operational capabilities delivered by the project
  • The cost to produce those capabilities on the planned date
  • The schedule on which they will be delivered to meet the needs of the customer on the planned date

Slide1

So when we think about these three elements, how they are coupled, how they interact, what their second tier driver are, we come back to a fundamental — immutable — question

Can We Make Decisions About How To Spend Other Peoples Money In Exchange For Value, Without Knowing The Cost, Duration, or Expected Delivered Value Of Those Activities?

So when we hear there are ways, let's look at them in the context of actual business conditions to see if they hold up to examination. This assumes of course there are actual, actionable, suggestions to making decisions in the absence of estimates.

Related articles Why Johnny Can't Estimate or the Dystopia of Poor Estimating Practices Resources for Moving Beyond the "Estimating Fallacy" Is There Such a Thing As Making Decisions Without Knowing the Cost? Four Critical Elements of Project Success
Categories: Project Management

Lesson from 40 Project and Portfolio Management (PPM) Leaders

Herding Cats - Glen Alleman - Sat, 05/24/2014 - 04:09

Screen Shot 2014-05-23 at 9.48.06 PM

Get your copy of the lessons from project leaders. Tons of advice of project success, including some from me starting on on page 57.

Related articles Learning from mistakes is overrated
Categories: Project Management

Workshop Visualization (#wallpaper, #noprojector)

NOOP.NL - Jurgen Appelo - Wed, 05/21/2014 - 18:33
slide1

One discussion that keeps popping up among trainers and facilitators is whether to use presentation slides during a course or workshop. The traditional approach is to use them extensively, but a number of facilitators are in favor of a #noslides approach. Some of them prefer to write and draw everything on the spot during their workshops. My own preference is to take a nuanced view between those two extremes.

I think, the question should not be, “Should we use slides or not?”

It should be, “What kind of visualization is the most effective?”

The post Workshop Visualization (#wallpaper, #noprojector) appeared first on NOOP.NL.

Categories: Project Management

Software Development Linkopedia May 2014

From the Editor of Methods & Tools - Wed, 05/21/2014 - 12:22
Here is our monthly selection of interesting knowledge material on programming, software testing and project management.  This month you will find some interesting information and opinions about project estimation, how software developers feel about Agile, unit testing worst practices, team leadership, giving feedback in Scrum, software architecture, using commercial load testing and Scrum tools for free, sustainable Agile and data models for NoSQL databases. Blog: Paying the Cost for More Precise Estimates Blog: Where did all the developers go? Blog: Getting Unit Testing to Fail Blog: Real Teams Have Leaders! Blog: The Software Chicken and ...

Paying the Cost for More Precise Estimates

Mike Cohn's Blog - Tue, 05/20/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

I don’t mean the boss has to slip the team a $20 tip. What I’m referring to is the time the team will spend creating that estimate.

If a boss wants a really quick, down-and-dirty estimate of when a set of features will be done, I can answer that instantly. My answer: in the future. It’s certainly accurate.

But, it’s probably not what the boss is looking for. (And don’t blame me if you get fired for trying that answer!)

Perhaps a better estimate is needed. So the team puts more effort into estimating and thinks harder about what’s being asked for. They may come up with something like, “Three to six months.” That’s certainly better than “in the future.” And often, it’s good enough for decisions like, “Should we start this project?” and, “Should we add more teams?”

But, many bosses will insist on something more precise—perhaps an answer like, “In August.” Note that telling your boss a month is still framing your estimate as a range, which is vital to giving an accurate estimate. But, it’s much more precise than saying, “Three to six months.”

To add precision to an estimate requires time. And that is the cost I’m referring to.

As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”

When asked by a boss to provide an estimate you’d prefer not to provide, do not argue with the boss that the estimate is unnecessary. That will usually get you nowhere. Instead take the attitude that you’re happy to provide the estimate (even if you aren’t), but challenge the boss about how precise or detailed the estimate needs to be.

If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate.

Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.

Paying the Cost for More Precise Estimates

Mike Cohn's Blog - Tue, 05/20/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

I don’t mean the boss has to slip the team a $20 tip. What I’m referring to is the time the team will spend creating that estimate.

If a boss wants a really quick, down-and-dirty estimate of when a set of features will be done, I can answer that instantly. My answer: in the future. It’s certainly accurate.

But, it’s probably not what the boss is looking for. (And don’t blame me if you get fired for trying that answer!)

Perhaps a better estimate is needed. So the team puts more effort into estimating and thinks harder about what’s being asked for. They may come up with something like, “Three to six months.” That’s certainly better than “in the future.” And often, it’s good enough for decisions like, “Should we start this project?” and, “Should we add more teams?”

But, many bosses will insist on something more precise—perhaps an answer like, “In August.” Note that telling your boss a month is still framing your estimate as a range, which is vital to giving an accurate estimate. But, it’s much more precise than saying, “Three to six months.”

To add precision to an estimate requires time. And that is the cost I’m referring to.

As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”

When asked by a boss to provide an estimate you’d prefer not to provide, do not argue with the boss that the estimate is unnecessary. That will usually get you nowhere. Instead take the attitude that you’re happy to provide the estimate (even if you aren’t), but challenge the boss about how precise or detailed the estimate needs to be.

If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate.

Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.

Paying the Cost for More Precise Estimates

Mike Cohn's Blog - Tue, 05/20/2014 - 15:00

The following was originally published in Mike Cohn's monthly newsletter. If you like what you're reading, sign up to have this content delivered to your inbox weeks before it's posted on the blog, here.

I have no problem with a boss who asks a team to provide an estimate for how long a huge set of product backlog items will take to deliver. There could be hundreds of items – perhaps even thousands, and I have no issue with the boss asking for an estimate. I will be happy to provide a boss with that information.

So long as the boss understands that information has a cost.

I don’t mean the boss has to slip the team a $20 tip. What I’m referring to is the time the team will spend creating that estimate.

If a boss wants a really quick, down-and-dirty estimate of when a set of features will be done, I can answer that instantly. My answer: in the future. It’s certainly accurate.

But, it’s probably not what the boss is looking for. (And don’t blame me if you get fired for trying that answer!)

Perhaps a better estimate is needed. So the team puts more effort into estimating and thinks harder about what’s being asked for. They may come up with something like, “Three to six months.” That’s certainly better than “in the future.” And often, it’s good enough for decisions like, “Should we start this project?” and, “Should we add more teams?”

But, many bosses will insist on something more precise—perhaps an answer like, “In August.” Note that telling your boss a month is still framing your estimate as a range, which is vital to giving an accurate estimate. But, it’s much more precise than saying, “Three to six months.”

To add precision to an estimate requires time. And that is the cost I’m referring to.

As long as a boss is willing to pay that cost, a good team should be willing to provide an estimate at whatever level of detail and precision the boss wants. The problem is when the boss wants a highly precise estimate and isn’t willing to pay the cost, for example, “I need to know by lunch time today exactly when this large project can be delivered.”

When asked by a boss to provide an estimate you’d prefer not to provide, do not argue with the boss that the estimate is unnecessary. That will usually get you nowhere. Instead take the attitude that you’re happy to provide the estimate (even if you aren’t), but challenge the boss about how precise or detailed the estimate needs to be.

If providing the estimate will cause all other work to stop for a week, the boss needs to understand that. If the boss has a true need for the estimate, he or she may be willing to let all other work stop. If the boss just wants an estimate to feel good or to hold the team accountable, the boss will probably settle for an easier-to-provide but less precise estimate.

Information has a cost. If the person asking for that information is willing to pay that cost, you need to be willing to provide the information.

Quote of the Day

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

“If a man gives no thought about what is distant, he will find sorrow near at hand.”
— Confucius

When you hear that we can't make estimates, we don't need to make estimates, we don't want to make estimates, because somehow, some way, they are the smell of dysfunction. Think of this quote.

If we don't now what the cost of our work will be in the end, when that work will be complete, what will be produced from that work — and most importantly of that work will actually produce what those paying us to do the work need to do their work — then we're likely going to come to grief.

Categories: Project Management

Top 200 Management & Leadership Authors (Maybe Not Experts)

NOOP.NL - Jurgen Appelo - Mon, 05/19/2014 - 12:57
top 50

Several weeks ago, I wanted to know who are the most interesting management & leadership writers (worldwide, in the English language). Which authors should I follow? Which blogs should I read? What books do I add to my backlog? Which writers have a great reputation? Of course, a not unreasonable secondary objective was to learn how does my work compare to the others? As I always say, how do you know you’re making progress when you don’t measure?

The post Top 200 Management & Leadership Authors (Maybe Not Experts) appeared first on NOOP.NL.

Categories: Project Management

To Stay In Business You Need to Know Both Value and Cost

Herding Cats - Glen Alleman - Sun, 05/18/2014 - 00:08

Show-me-ROI
I hear all the time, in agile we focus on value generation. Any viable business focuses on producing value for its products or services. Saying that is a tautology. There can be no viable business without some kind of value proposition that is acceptable to some number of customers to produce enough revenue to cover the costs of producing that value.

But not knowing the cost of that value, the cost to produce that value, managing the cost to produce that value, and controlling the costs during the value production process - There is not sustainable business

And by the way, the date on which that value will appear, since revenue stream or benefit stream needed to pay for the cost of that value needs to start on the planned time to produce the planned business performance needed to stay in business. Nice products late or nice products for too much cost is a going out of business strategy.

The next time you hear, we focus on value first, call BS. Focusing on value in the absence of focusing on cost of that value is a going out of business  strategy (unless you're a sovereign).

In the bottom line management of any viable business you get a divide by zero error if you don't know the cost of the value produced.

Since both value and cost are random variables in any development business - and random variables on production business as well - we need to have estimates for both cost and value at the same time. These estimates need confidence levels, cumulative probabilities of being at or below and on or before conversations. And an understanding of how the work processes drives these random variables as the project or service proceeds.

It can't be said any more clearly

Both Value and the Cost of that Value are needed for any hope of staying in Business

So don't let those asserting we focus on value to get away with that weak statement. Producing products for money is driven by the business processes first. Those producing those products need to get paid.

And when we here, don't estimate budget, then we're fixing one for the three variables of all projects, and the other are still free to vary in random ways. These ways need to be estimated as well, otherwise that fixed budget, may or may not be enough to deliver the needed capabilities on the needed date to deliver that needed value.

Slide1

Related articles Four Critical Elements of Project Success Everything is a Random Variable
Categories: Project Management

Spike It! Article Posted

One of my clients was having trouble with estimating work they had never done before, so I wrote an article explaining spikes. That article is up on agileconnection: Need to Learn More about the Work You’re Doing? Spike It!

It was a little serendipity; I taught an estimation workshop right after I explained how to spike in email. That article almost wrote itself.

You can use a spike in any project, agile or not. Spikes are for learning.

I also explain what to do when managers say, “Use the code in the spike” and you think, “Oh no!” See for yourself.

Would-be authors: want to write an article for agileconnection.com? I’m interested.

 

Categories: Project Management

Interview with Esko Kilpi

NOOP.NL - Jurgen Appelo - Fri, 05/16/2014 - 14:21
esko-kilpi

As part of my global book tour I hope to have fascinating conversations with management & leadership experts around the world. One of them is Esko Kilpi, a researcher and consultant in Finland who has a focus on the “arts and sciences of complex interaction”. With Esko I talked about management & complexity.

The post Interview with Esko Kilpi appeared first on NOOP.NL.

Categories: Project Management

45 New Books (by Top Authors) for Your Management Book Shelf

NOOP.NL - Jurgen Appelo - Thu, 05/15/2014 - 16:38
books.jpg

You may have seen that I supplied the data for Inc.com’s Top 50 Management & Leadership Experts. People seem to like it very much.

Well, what I also did was find the answer to the question, “What are the latest book releases of the management & leadership experts?”

I discovered new books by Tim Harford, Daniel Kahneman, Dan Ariely, Henry Mintzberg, Jason Fried, Simon Sinek, Peter Senge, Malcolm Gladwell, Chip & Dan Heath, John Kotter, Clayton Christensen, and many more… My reading backlog just doubled in size!

The post 45 New Books (by Top Authors) for Your Management Book Shelf appeared first on NOOP.NL.

Categories: Project Management