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

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

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

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

Warning: Cannot modify header information - headers already sent by (output started at /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/database.mysql.inc:135) in /home/content/O/c/n/Ocnarfparking9/html/softdevblogs/includes/bootstrap.inc on line 732
Software Development Blogs: Programming, Software Testing, Agile, Project Management
Skip to content

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

Methods & Tools

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

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

Software Development Conferences Forecast October 2015

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

Ensuring a Consistent Design Without an Upfront Design Phase

Mike Cohn's Blog - Tue, 10/27/2015 - 17:00

In last week’s post, I wrote about how to integrate UI designers into the agile sprint. I said that designers should work as part of the team on the current sprint but should spend some of their time (perhaps even most of it) looking ahead at what is coming next.

But this raises a concern I’d like to address in this post. How do UI designers ensure a consistent design without having an upfront design phase in which they design the entire product?

Guide the Design Intentionally

First, designers intentionally guide the design of a system. Because an agile project does not have an upfront design phase, design is said to be emergent. That is, the design emerges over time. It is not created in a phase of the project.

However, the design does not emerge randomly. The design emerges guided by the skilled intent of the designer. The designer identifies areas of the system and designs those first. The designer then works with the team to build those, incorporates feedback from real users, and then identifies the next areas of interest to design.

This process is repeated iteratively and incrementally. The key is that each area is chosen intentionally by the designer as one that will provide insights into the remaining design issues. Design does not proceed randomly.

Think about how you might put together a jigsaw puzzle. You would not put a puzzle together by randomly picking up pieces and looking to match them together. Instead, you would probably start by finding the corner pieces, then the edges, and so on. With the entire border outlined, you might move onto a specific color or pattern. This approach could be described as both emergent and intentional.

Take Advantage of Incremental Delivery to Incorporate Early Feedback

A huge advantage to UI designers on agile projects is the ability to get actual feedback from real users early in the process. In exchange for giving up the ability to design an entire system upfront, designers get something very valuable in return -- this opportunity for feedback.

As designers learn to avail themselves of this feedback, they realize that the ability to change parts of a product late in the process outweighs the benefits of total freedom in an upfront design phase.

Think Holistically, Work Incrementally

Novelist E.L. Doctorow has said that writing a novel is like “driving a car at night. You never see further than your headlights, but you can make the whole trip that way.” I think the same applies to designing products.

A designer should have a vision for the full journey, but can make the drive seeing only as far ahead as as the headlights reveal.

On an agile project, designers need to think holistically but work incrementally. The designer and novelist both know where they are ultimately headed, but each gets there by looking only a certain distance ahead at any time.

Hofstadter's Law Is Misguided

Herding Cats - Glen Alleman - Mon, 10/26/2015 - 17:49

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law¬†‚ÄĒ‚ÄĮDouglas Hofstadter,¬†G√∂del, Escher, Bach: An Eternal Golden Braid¬†

4-IMG_1870Hofstadter's Law is actually about self-referencing systems. The statement about how long it takes is a self-referencing statement.

The #NoEstimate community uses it as an example that you can't estimate, because even when you do it's going to be wrong.

This of course willfully ignores the principles, practices, and processes of mathematical estimating. Both Parametric and probabilistic estimates.

In both these paradigms, parametric and probabilistic, uncertainty is the core driver of variance both Irreducible and Reducible uncertainties. 

Here's the well known approach to managing in the presence of unceratnty

Managing in the presence of uncertainty from Glen Alleman   So what the #NoEstimates advocates fail to understand is that in the presence of reducible (epistemic) and irreducible (aleatory) uncertainty, actions must be taken to address these uncertainty and prevent these from unfavorably impact the project outcomes, as suggested in ... Bliss Chart
  • Irreducible uncertainty can be addressed with¬†Margin. Cost margin, schedule margin, technical performance margin.
  • Reducible uncertainty can be addressed with redundancy,¬†risk retirement¬†activities, that¬†buy down the risk resulting from the uncertainty to an acceptable level.

In both cases managing in the presence of uncertainty means following Tim Lister's advice...

Risk Management is how Adults Manage projects

So when Hofstadter's Law is used without addressing the reducible and irreducible uncertainties and the resulting risk to project success, the result is Hofstadter's Law.

A self reference circular logic leading directly to project disappointment.  

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

Quote of the Month October 2015

From the Editor of Methods & Tools - Mon, 10/26/2015 - 10:39
The man/month likes the software architect because he can do without thinking. The software architect likes the man/month because he can think without doing. Source: Emanuel Chenu, http://emmanuelchenu.blogspot.fr/2009/02/lhomme-mois-v1.html (translated from French)

How Many Definitions Are There? Let Me Count the Ways

Herding Cats - Glen Alleman - Thu, 10/22/2015 - 06:00

In any discussion of project management, software development, and business management, agreeing on a shared set of definitions is critical por progress in exchanging ideas. When standard definitions are redefined to suit the needs of those conjecturing a new approach, it makes it more difficult to have a meaningful conversation.

One recent example is the No Estimates advocates redefining the meaning of estimate and forecast. Where forecasting is NOT estimating, so the No Estimates moniker can be applied to what is essentially estimating, 

  • Estimate: a human judgement derived estimate
  • Forecast:¬†a data driven forecast

First let's look at some definitions of Estimate as applied to project and program work. The estimate is applied to something. Cost, Schedule, some technical performance parameter. So we can't just use Estimate by itself. It needs to be an estimate of something. Here's some things we can estimate and the processes of performing those estimates on projects that involve uncertainty. If there is no uncertainty in the project the need for estimating goes away. Just observe the empirical data and calculate the needed value - cost, schedule, or technical performance.

  • Analogy Cost Estimate - An estimate of costs based on historical data of a similar (analog) item.
  • Ball Park Estimate - Very rough estimate (usually cost estimate), but with some knowledge and confidence. (‚ÄúSomewhere in the ball park.‚ÄĚ)
  • Budget Estimate - a Cost estimate prepared for inclusion in the budget to support ¬†projects funding.
  • Cost Estimate - A judgment or opinion regarding the cost of an object, commodity, or service. A result or product of an estimating procedure that specifies the expected dollar cost required to perform a stipulated task or to acquire an item. A cost estimate may constitute a single value or a range of values.
  • Cost Growth - A term related to the net change of an estimated or actual amount over a base figure previously established. The base must be relatable to a program, project, or contract and be clearly identified, including source, approval authority, specific items included, specific assumptions made, date, and the amount.
  • Cost Model - A compilation of cost estimating logic that aggregates cost estimating details into a total cost estimate.
  • Engineering Cost Estimate - is derived by summing detailed cost estimates of the individual work packages (tasks, sprints, iterations, defined packages of work that produce a single useable outcome)and adding appropriate burdens. Usually determined by a contractor‚Äôs industrial engineers, price analysts, and cost accountants.
  • Estimate at Completion (EAC) (Cost) - Actual direct costs, plus indirect costs or costs allocable to the contract, plus the estimate of costs (direct and indirect) for authorized work remaining.¬†
  • Long Range Investment Plans - are broad plans based on best estimates of future top-line resources that form the basis for making long-range affordability assessments of products or services produced by the project.¬†
  • Manpower Estimate - An estimate of the most effective mix of direct labor and contract support for a project.¬†
  • Parametric Cost Estimate - is a cost estimating methodology using statistical relationships between historical costs and other program variables such as system physical or performance characteristics, contractor output measures, or manpower loading.¬†
  • Project Office Estimate (POE) - is a detailed estimate of development and ownership costs normally required for high-level decisions by the business. The estimate is performed early in the project and serves as the basepoint for all subsequent tracking and auditing purposes.
  • Should Cost Estimate - is an estimate of the project cost that reflects reasonably achievable economy and efficiency during the development and operational phases of the product or service.¬†
  • Standard Error of Estimate - is a measure of divergence in the actual values of the dependent variable from their regression estimates. (Also known as standard deviation from regression line.) The deviations of observations from the regression line are squared, summed, and divided by the number of observations.
  • Technical Performance Measurement (TPM) - describes all the activities undertaken by the buter to obtain design status beyond that treating schedule and cost. TPM is the product of design assessment that estimates the values of essential performance parameters of the current design as contained in Work Breakdown Structure (WBS) product elements through tests. It forecasts the values to be achieved through the planned technical program effort, measures differences between achieved values and those allocated to the product element by the Systems Engineering Process (SEP), and determines the impact of these differences on system effectiveness.

So now to the killer concept

If the project you are working has no uncertainty and therefore has no resulting risk, the need for estimating is greatly reduced of not eliminated. If there is uncertainty and resulting risk, then Tim Lister has something to say...

Risk Management is How Adults Manage Projects

So no Uncertainty, No Risk, No need for Risk Management, low if any need for estimates of the outcomes of the decisions made the project participants.

Can This Really Be True?

Ask if your project has NO uncertainties? Nothing in the future that is unknown at the moment. No process that has any variance, in the past, now, or in the future. Nothing is going to change. All the work will run at the same efficiency as it does now. No defect will appear. No changing performance behaviors as the result of new development.

A bit about uncertainty. There are two kinds. Reducible and Irreducible. Reducible uncertainty is event based. That is there is a probability associated with the uncertainty coming true. For example there is q 30% probability of rain today over the forecast area. This is an event based uncertainty. To protect yourself from this uncertainty, depending on where you live, bring a rain coat.

There is irreducible uncertainty. This is the naturally occurring variances in the underlying system of interest. For example, I drive to the airport every Tuesday morning every other week to work at a client site.  There is Reducible uncertainty around the weather. I'll look at the weather report to see what is going to happen. But given the weather, there will be an impact on the traffic. Snow or Sleet will have a different impact than rain or sunshine. This impact is a variances in the traffic flow which I have no control over. The only protection for not missing my flight is to have sufficient time margin
in the drive. On a clear day, not traffic, no other impediments, it's 45 minutes from driveway to my favorite parking spot on east side of DIA, Level 1. Margin is applied depending on the events and underlying processes of travel.

So when the term Estimate and its related term Forecast are redefined so estimating is not seen as estimating, it pollutes the conversation. This conversation is critical to increasing the probability of success of projects in all domain. 

  • Estimates are about the past, present, and future - an estimate of the numberBrachiosaurus that walked on the beach on what is now called Dinosaur Ridge¬†in Morrison Colorado. Or the Estimate of the number of cars on E-470 headed to Denver International Airport. Or the estimate to complete for the lane expansion on CO-36 between Boulder and Denver.
  • Forecasts are about the future - a weather forecast.
Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
Categories: Project Management

Incorporating UI Design in Agile Sprints

Mike Cohn's Blog - Tue, 10/20/2015 - 15:00

A question I’ve been getting a lot lately is whether UI designers should be part of the Scrum team and whether they should do their work as part of an agile sprint. It’s a big topic. So let’s dive right in.

The Two Goals of an Agile Sprint

There are really two things a team should be doing each sprint:

  • Building new functionality
  • Building new knowledge

We all know that teams have to build new functionality each sprint. That is, after all, the purpose of most projects--to deliver new capabilities into the hands of users.

But teams also need to build new knowledge. A team should finish each sprint smarter than it started. Sometimes a team learns things about a technology it is using or about how users view the functionality it has built. Other times, a team might learn something about itself and how it is performing.

Both goals are important.

What UI Designers Do During the Sprint

During each sprint, UI designers should pursue the twin goals of building functionality and building knowledge. Within a sprint, a UI designer will be helping the rest of team turn a design into implemented, tested code while simultaneously thinking about the next feature (or two) to be built. This means, a designer is both in the sprint and looking ahead at what comes next.

The result is something like what is shown in the figure below. This figure shows that while coding and testing one part of the product backlog, the user interface designers will spend some of their time (perhaps a majority of it) looking further down the product backlog at upcoming items. Yet, it remains one team working on one sprint at a time.

The UI designer’s top priority must be to the work of the current sprint. If a team member needs a clarification on a design for a product backlog item being worked on in the current sprint, the designer stops thinking about next sprint and answers the question about the work of the current sprint.

How About Other Roles?

Pause for a moment and consider everything I’ve just written about UI designers. But think now about product owners, analysts, database designers, architects or perhaps anyone with a significant responsibility to think ahead about what is to come on the project.

Everything still applies. It’s just a difference of the amount. Designers may spend the majority of their time building knowledge, but they’ll still spend some time building functionality. And one of the other roles I just mentioned may do the opposite. Every role on an agile project will split its time between building functionality and building knowledge.

Avoid Perfecting the Design the Upfront

In giving the designer permission to look ahead, the agile team is not asking the designer to complete the design. Rather the designer should do just enough in advance that the product backlog item can be completed by the rest of the team in the later sprint when the team works on it.

At the end of the sprint, the team should feel that if they had received any less information from the designer, it would have been impossible to finish the product backlog item within the sprint. This means that some product backlog items may need to be looked at in massive detail (and more than one sprint ahead) whereas others may not need to be looked at in advance at all.

Additionally, any items a designer does look at beyond the current sprint should be chosen through discussion with the product owner. The designer wants to avoid working on something a product owner later deems unnecessary.

Does This Lead to Bad Design?

A common concern is that this could lead to a bad design. Wouldn’t it be better if the designer could think holistically about the entire system upfront? In next week’s blog, I’ll explain why working this way does not lead to bad designs.

Share Your Thoughts

How does your team work with its UI designers? If you’re a designer, how do you work with your team? Please share your thoughts with us below.

Software Development Linkopedia October 2015

From the Editor of Methods & Tools - Mon, 10/19/2015 - 14:38
Here is our monthly selection of knowledge on programming, software testing and project management. This month you will find some interesting information and opinions about software testing mindmaps, remote retrospectives, testing patterns, DevOps, Agile documentation, UX deliverables, Agile testing, Agile metrics and responsible software development. Web site: Software Testing Mindmaps Blog: Sprint Retrospective Exercise for […]

Change Isn’t Free

Mike Cohn's Blog - Tue, 10/13/2015 - 15:00

Agile teams are told to “embrace change,” which is the subtitle to Kent Beck’s wonderful Extreme Programming Explained book. Although an agile team can embrace change, the stakeholders in an organization must understand that change is not always free.

Most agile teams seems to understand this. They get that requirements changes can crossover into requirements churn, to use the traditional term for the problem. Scrum tries to solve the problem by including as part of its framework a rule that change is not allowed into a sprint. Once a sprint has started, change is kept out of the sprint, leaving the team to focus on what was selected to be worked on in the sprint.

This can work extremely well, but keeping change out of the sprint is sometimes thrown back in the face of the team. A product owner or stakeholder who is told that a change cannot be introduced will respond with, “But I thought you’re agile, and isn’t the whole point of being agile that you welcome changing requirements?”

Well, yes and no. A team can welcome changing requirements but that doesn’t mean those changes are free. Consider the following scenario:

You’re out to dinner and settle on chicken as the main dish. As the waiter walks away, you call him back and tell him you’ve changed your mind. You’d prefer the fish. No problem, he says. There is no cost to this change. The restaurant is not going to charge you for changing your mind (changing the requirements) five seconds into your order (five seconds into the iteration).

But, let’s make things a little more interesting.

Suppose the waiter takes your order for chicken and a salad to start. He brings you the salad, and you then change your order for the main dish from chicken to fish. My experience is that most restaurants will still not charge you for this. They’ll bring you the fish even though they may have started cooking the chicken.

There may be a real cost to the restaurant. But I suspect they write it off as goodwill, hoping you enjoy your meal and the courtesy they showed you. And they hope you come back more often because of it.

And let’s say you do come back. In fact, you come back every night. And every night, you jerk the waiter around by changing your order after he brings you the salad. The restaurant is incurring real costs because of you.

They may still be nice and not pass the costs of these changes onto you. But, if I were that restaurant, I’d pass a different type of cost onto you: I’d wait to start cooking your main dish until after you ate the salad so that we were both sure of your order.

Let’s consider one additional scenario. In this case, after eating the salad, you change your order of chicken to fish, as before. But before the fish comes, you call the waiter over and tell him you’ve re-considered and the steak sounds appealing.

Then, before the steak arrives, you call the waiter again and tell him you saw the linguine served to another diner and simply must have that. At some point, the restaurant has incurred real costs from all this switching and will charge you for it.

Change is not free.

You can change your order at the restaurant up to a point for free. You can change it after that and the restaurant will do all they can to minimize the impact of that change, but beyond some point there is a cost to changing.

The same is true on product development initiatives. We can and should embrace change. It is often why we want to be agile. But we can also educate our stakeholders so they understand that change introduced beyond a certain point in an iteration has a cost. And we can work together with them to minimize those costs.

Thu, 01/01/1970 - 01:00