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

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

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

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

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

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

Methods & Tools

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

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

Software Development Conferences Forecast November 2015

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

Agile at Scale - A Reading List

Herding Cats - Glen Alleman - Sun, 11/22/2015 - 20:29

I'm working two programs where Agile at Scale is the development paradigm. When we start an engagement using other peoples money, in this case the money belongs to a sovereign, we make sure everyone is on the same page. When Agile at Scale is applied, it is usually applied on programs that have tripped the FAR 34.2/DFARS 234.2 levels for Earned Value Management. This means $20M programs are self assessed and $100M and above are validated by the DCMA (Defense Contract Management Agency).

While these programs are applying Agile, usually Scrum, they are also subject to EIA-748-C compliance and a list of other DID's (Data Item Description) and other procurement, development, testing, and operational guidelines . These means there are multiple constraints on how the progress to plan is reported to the customer - the sovereign. These programs are not 5 guys at the same table as their customer exploring what will be needed for mission success when they're done. These programs are not everyone's cup of tea, but agile is a powerful tool in the right hands of Software Intensive System of Systems for Mission Critical programs. Programs that MUST, deliver the needed Capabilities, at the Need Time, for the Planned Cost, within the planned Margins for cost, schedule, and technical performance.

One place to start to improve the probability that we're all on the same page- is this reading list. This is not an exhaustive list, and it is ever growing. But it's a start. It;s hoped this list is the basis of a shared understanding that while Agile is a near universal principle, there are practices that must be tailored to specific domains. And one's experience in one domain may or may not be applicable to other domains. 

Like it says in the Scrum Guide. 

Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

And since Scrum is an agile software development framework, Scrum is a framework not a methodology. Scrum of Scrums, Agile At Scale, especially Agile at Scale inside EIA-748-C prorgams has much different needs than 5 people sitting at the same table with their customer with an emerging set of requirements where the needed capabilities will also emerge.

Related articles Slicing Work Into Small Pieces Agile Software Development in the DOD Technical Performance Measures What Do We Mean When We Say "Agile Community?" Can Enterprise Agile Be Bottom Up? How To Measure Anything
Categories: Project Management

Software Development Linkopedia November 2015

From the Editor of Methods & Tools - Thu, 11/19/2015 - 17:55
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 development teams, software engineering management, metrics approaches, UX personas, tools for distributed retrospectives, exploratory testing, Agile principles and load testing. Blog: How to Make the Leap from Engineer to […]

Decision Making in the Presence of Uncertainty

Herding Cats - Glen Alleman - Thu, 11/19/2015 - 17:02

Just back from the Integrated Program Management Workshop in Bethesda MD these week, where the topic of Agile and Earned Value Management occupied 1/3 of the conference speaks and training - I was one speaking and training. I'm current working two Agile+EVM programs in the Federal Governance and started in this path back in 2003 and 2003. Today the maturity of both Agile and EVM is much greater than the early 2000's Tools, processes, and practices have improved. Now we have SAFE and Scrum of Scrums as he basis of our program controls work. 5 guys in the same room as their customer around the same table is extremely rare where I work. The threshold for EVM is $20M and full validation of the EVMS is now $100M, so small teams are simply not the paradigm. But Agile is still a powerful tool in the INTEL, Software Intensive Systems, Systems of Systems, and rapidly emerging enterprise IT projects in our domain. All driven by the NDAA section 804

In this paradigm, programs are awarded through a formal contracting process guided by the Federal Acquisition Regulations starting with FAR 15 - competitive procurement. A period of performance and a Dollar amount in some form, Not To Exceed, Firm Fixed Price, or Cost Plus, still has a dollar amount. On all these programs, requirements emerge over the course of the work. The notion that requirements are defined upfront is a Red Herring, by those not working in this domain. Capabilities Based Planning is used in most cases, for larger programs. Increasing maturity of the end item deliverables is guided by the Integrated Master Plan / Integrated Master Schedule process in he DOD and other agencies as well as applied  to large commercial programs we work.

In all cases decisions must be made in the presence of uncertainties about the future. This is the basis of all risk informed decision making, guided by Risk and Opportunity Acquisition Guide. 

Much of this experience is applicable outside of major program development. Based in 5 Immutable Principles of project success

  1. What does Done look like in units of measure meaningful to the decision maker?
  2. What's the Plan to get to Done with the needed Capabilities, at the needed Time, for the needed Budget  to starting returning the needed value or fulfilling the mission? 
  3. What resources are needed to deliver the needed Capabilities, at the needed Time, for the needed Budget?
  4. What impediments will be encountered along the way to Done, and what activities are needed to removed these impediments?
  5. How is progress being measured to inform the decision makers of the probability of success of the program?

These 5 principles are applicable to all project work no matter the domain, process, procedures, or tools.

I came across the briefing below while researching materials of a client. The decision making processes here at deterministic. In practice these are probabilistic branches. Each branch of the decision tree has a probability of occurrence. So making decisions require making estimates of not only the probability of occurrence, but also the probabilistic outcome of that decisions. 


So, you think you are good at making decisions? - 8th October - Aberdeen from Association for Project Management   Making decisions in the presence of uncertainty between the multiple choices and the impacts of those choices requires making estimates of probabilistic outcomes. To suggest otherwise willfully ignores the Microeconomics of decision making and the Managerial Finance processes that funds those decisions.  Related articles Moving EVM from Reporting and Compliance to Managing for Success Agile Software Development in the DOD 5 Questions That Need Answers for Project Success
Categories: Project Management

How Long Are Your Iterations? Part 1

I spoke with a Scrum Master the other day. He was concerned that the team didn’t finish their work in one 2-week iteration. He was thinking of making the iterations three weeks.

I asked what happened in each iteration. Who wrote the stories and when, when did the developers finish what, and when did the testers finish what? Who (automated tests, testers or customers) reported defects post-iteration?

He is the Scrum Master for three teams, each of whom has a different problem. (The fact that he SMs for more than one team is a problem I’ll address later.)

Team 1 has 6 developers and 2 testers. The Product Owner is remote. The PO generates stories for the team in advance of the iteration. The PO explains the stories in the Sprint Planning meeting. They schedule the planning meeting for 2 hours, and they almost always need 3 hours.

Staggered_dev_testingThe developers and testers work in a staggered iteration. Because the developers finish their work in the first two-week iteration, they call their iterations two weeks. Even though the testers start their testing in that iteration, the testers don’t finish.

I explained that this iteration duration was at least three weeks. I asked if the testers ever got behind in their testing.

“Oh, yes,” he replied. “They almost always get behind. These days, it takes them almost two weeks to catch up to the developers.”

I explained that the duration that includes development and testing is the duration that counts. Not the first two weeks, but the total time it takes from the start of development to the end of testing.

“Oooh.” He hadn’t realized that.

He also had not realized that they are taking too much work (here, work in progress, WIP). The fact that they need more time to discuss stories in their planning meeting? A lot of WIP. The fact that the developers finish first? That creates WIP for the testers.

Sequential work makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag time between the time the development is done and the testing is done?

The next post will be about when you have a longer duration based on interdependencies.

Categories: Project Management

Leave Work Unassigned and See Who Steps Forward

Mike Cohn's Blog - Tue, 11/17/2015 - 16:00

Create vacuums and then see who steps in to fill them

Early in my career, I noticed the project managers in my company drove nicer cars than we programmers did. (This was back before companies had learned to fully value their technical staff.) After a few years of noticing those nicer cars, I asked my boss what I needed to do to become a project manager. He told me, "When you start acting like a manager, I'll make you a manager."

This advice wasn't unique to him. I've since heard it from many other bosses. And it's actually not bad advice.

The problem with my boss's advice was that there were no opportunities for me to start acting like a manager. Each of the company's projects already had a project manager assigned to it. If I had started acting like the manager of a project that already had a manager, the officially appointed manager would have been quite annoyed with me.

If my boss had really wanted me to start acting like a manager in order for him to promote me into that role, he should have left a void in the organization for me to fill. In fact, an important part of a leader's job in an agile organization is to create vacuums so that the right people can step forward and fill them.

Creating a vacuum entails deliberately leaving a gap in an organization. Rather than filling the gap by identifying a specific person or group of people to fill it, a leader can point out the gap, and then see what happens. The benefit of this approach is that it allows people to work in areas where they are passionate.

As an example, many years ago, I was working as a VP of software development. Some of the first XP teams in that company discovered the benefits of continuous integration, and I was excited to spread this practice across the department. I could have appointed someone to make that happen.

Instead, at the next department meeting, I talked about how impressed I was with what those teams had done, and how it was going to be important for us to spread that good practice to other teams. Without explicitly saying so, I let it be known that this was something people could work on.

Of course, for this to work, leaders also need to create a culture in which employees do not have every waking moment of every day committed to project work. Companies don't need to go so far as the well-known Google 20 percent time, but employees should generally have some time they devote to work of their own choosing.

This is a sign that leaders trust employees. It is also a recognition that it is impossible for a leader or manager to identify the highest priority work in all cases.

If you're a leader in an agile organization, the next time you need something done, rather than assigning someone to the work, consider creating a vacuum and seeing who steps into it.

Creating Great Estimates as a Team

I’ve been teaching workshops these last few weeks.¬†A number of the participants think that they need to create great estimates. I keep hearing, “I have to create accurate estimates. My team needs my estimate to be accurate.”

I have found that the smaller the work, the better the estimate. If people work as a team, they can provide more accurate estimates than they can alone. And, if they work as a team, the more likely they are to meet the estimate.

The people in my workshops did not want to hear this. Many of them wanted to know how to create an estimate for “their” work, accounting for multitasking.

I don’t know how to create great estimates when people assume they work alone, or if they multitask.

In all of my experience, software is a team activity (especially if you want to use agile or lean). For me, creating an estimate of “my” work is irrelevant. The feature isn’t done until it’s all done.

When we create solo estimates, we reinforce the idea that we work alone. We can work alone. I have discovered I have different ideas when I pair. That’s one of the reasons I ask for review, if I am not actively pairing. I have also discovered that I find problems earlier when I pair or ask for frequent review. That changes my overall estimate.

Multitasking creates context switching, with built-in delays. (See¬†Cost of Delay Due to Multitasking, Part 2¬†or Diving for Hidden Treasures.) I don’t know how to account for the context-switch times. For me, the context-switching time varies, and depends on how many switches I need to do.

PredictingUnpredictable-smallIf you want to create great estimates, estimate as a team. For hints, see Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Cost or Schedule.

I urge you to make the thing you estimate small, you consider how you work with other people to deliver this thing, and you do one chunk of work at a time. All of those ideas will help you create better estimates. Not for “your” work, but for the work you deliver to your customer.

Categories: Project Management

Immutable Principles of Managerial Finance When Spending Other Peoples Money

Herding Cats - Glen Alleman - Mon, 11/16/2015 - 12:57

One of the primary responsibilities of  management is to make decisions during the execution of projects so that gains are maximized and losses are minimized. Decision analysis is critical for projects with built-in flexibility, or options. when these choices operate in the presence of uncertainty. [1]

The notion that we can spend other peoples money in the absence of the immutable principles of Managerial Finance and Microeconomics of decision making pervades the #Noestimates community. Here's a few of those principles to counter that fallacy.

  • We can't determine the value of a software feature or product unless we know the cost to acquire that feature or product.¬†If we determine the value of a feature in our new ERP system is worth $150,000 in savings to us every year.¬†What if to acquire that feature, it costs $50,000 one time and $10,000 a year in maintenance, a typical 20% maintenance charge.¬†That sounds pretty good. But what if¬†to acquire that feature it costs $1,200,000 for a one time charge and $150,000 a year in maintenance? It'll take 80 years¬†to break even not counting the maintenance. This is the principle of cost benefit analysis. And since both the cost and benefit are random variables in the future we'll need to estimate both and construct time phased money to determine the cash flow, sunk cost recovery and benefit flow..

We can't know the benefit until we know the cost to achieve that benefit

  • When we need to make a decision in the presence of uncertainty, and there are multiple choices we need to choose between all of them and pick one. If we know something about the cost of each choice,we can assess the beneficial outcome of that¬†choice. The cost of the choice - that is to acquire a feature - also has a cost of NOT choosing the other choices. This is the¬†opportunity cost between all the choices. This opportunity cost makes visible not¬†only the beneficial outcome of our choice, but the cost of NOT making the other choices.

Microeconomics of decision making in the presence of uncertainty is based on Opportunity costs

  • In any complex software system development domain the usefulness of a precise numerical and analytical approach to make choices breaks down. Resorting to heuristics - empirical assessment of the past, modeling of the future - is not always the best approach, since it's sometimes hard to evaluate the validity of the heuristic because of the¬†informal structure. One approach in this situation is an economics approach that recognizes software efforts expend valuable resources in the presence of an uncertain payoff. This is¬†decision making under uncertainty.¬†Like the Microeconomics¬†of¬†opportunity¬†cost - Real Options¬†is a tool applicable to this problem. We're not¬†trading¬†stock here, but a¬†real options view of capital investments is based on the observation that investment opportunities are similar¬†to a¬†call option that confers upon its holder the right but not the obligation to purchase an asset as a set cost for a period of time. This¬†value seeking¬†approach is called Real Options.

Uncertainty is a central fact of life on most large IT capital investments. Along with uncertainty comes managerial flexibility. A real option refers to the right to obtain the benefits of owning a real world asset without the obligation to exercise that right. 

So in the end, when making a decision - that is selecting from more than one choice - there are several methods listed here. 

Each of these methods of making choices in the presence of uncertainty requires making an estimate of the impact of that choice, an estimate of the cost to acquire the value for the choice, and an estimate of that value. 

 [1] Real Options: The Value Added through Optimal Decision Making, Graziadio Business Review, 

Related articles A Theory of Speculation Architecture -Center ERP Systems in the Manufacturing Domain Making Choices in the Absence of Information
Categories: Project Management

Immutable Laws of Software Development

Herding Cats - Glen Alleman - Fri, 11/13/2015 - 17:45

A 2013 webinar at Cyber Security & Information Systems Information Analysis Center, presented some Immutable Laws of Software Development. These are worth repeating every time there is a suggestion hat some method or another, or some new and untested idea is put fort that will increase productivity by 10X or increase your profitability by NOT doing core business processes.

Here's the list presented in the webinar and is dedicated to Watts Humphrey who said all these in the past. For each Immutable Law, I've made a suggestion on how to avoid the undesirable outcome.

  • The number of development hours is directly proportional to the size of the software product
    • Size Matters
    • Build products in¬†chunks of capability, deploy them incrementally when possible to provide measurable value
    • Increase the maturity of these capability with Capabilities Based Planning
  • When buyers and suppliers¬†both guess as to how long a project should take, the buyers guess will always win
    • Credible cost, schedule, and technical performance estimating must be in place and jointly used by buyer and supplier
    • The basis of estimate must include risk adjusted baseline for reducible and irreducible risks¬†
  • When management compresses schedule arbitrary¬†the project will end up taking longer
    • Any project without margin is late, over budget, and produces poor quality on dat one
    • Reducible and Irreducible uncertainty must be modeled and handled if this is o be avoided
  • Team morale is inversely proportional to the arbitrary and unrealistic nature of the schedule imposed on the team
    • All project variables - programmatic and technical must have protective margin
  • Schedule problems are normal, management actions to remediate will make them worse.
    • Margin is needed for everything, since all project variables are random variables
  • When poor quality impacts schedule, schedule problems will end up as quality disasters
    • Technical performance (quality) require cost and schedule margin to achieve to needed goal
  • Those that don't learn from poor quality's adverse impact on schedule, are domed to repeat it.
    • Recording past performance in a statistically correct manner provides¬†reference classes for modeling future performance
  • The less facts you know about a project during development, the more you will be forced to know later
    • Systems Engineering is an anchor discipline for all successful projects.
    • This is no more important than on software development projects.
    • The Systems Engineering processes applied to software development are a critical success factor
  • The number of defects injected during development will be directly proportional to the development hours expended
  • The number of defect found in production use will be inversely proportional to the percent of defect removed prior to integration, system, and acceptance testing.
    • Formal defect modeling is the starting point for quality improvements
    • Test coverage metrics are a starting point
  • The number of defect found in production use will be directly proportional to the number of defects found in integration, systems, and acceptance testing.
    • Same as above
  • When test is the principal defect removal method during development, corrective maintenance will account for he majority of the maintenance spend.
    • Designed quality is the basis of reducing defects
    • Designed quality starts with architecture, interface management, process and data models¬†
  • The amount of technical debt in inversely proportional to the length of the agile¬†sprint
    • 2 week sprints produce more debt that 4 week sprints
    • Scrum and agile in general have no notion of¬†margin so without margin debt increases
  • The earliest predictor of a software project's cost, schedule and quality outcome is the quality of the development process through code complete.
    • Process is King
  • Management actions based on metric not normalized by size will make the situation worse.
    • All numbers must be properly modeled, statistically sound, and used to make management decisions.¬†
  • On a 40 hour week, the number of task hours for each engineer will stat under 20, unless steps are taken to improve it.
    • Work processes must be modeled, recorded, and assessed to determine the capacity for work by the team.
  • Successful cost, schedule, and quality outcomes depend on the degree of convergence between the organization's official process, the teams' perceived process and the individual's actual processes.
    • Process is King
  • Insanity is doing the same thing iver and over ¬†and firing the project manager and or¬†contractor when you don't get the results you expected.
    • Strategy for the organization requires tangible assessments of the Critical Success Factors and should ¬†never be confused with Operational Effectiveness.
    • If we ask someone to do something like make a change - what are the measures of Effectiveness and Performance for the change that can be assessed to find the root cause of the failure and the needed corrective actions.
    • Don't have those? It's gonna fail.


Related articles Estimating Guidance How to Deal With Complexity In Software Projects? Overarching Paradigm of Project Success
Categories: Project Management

Misuses a Valid Concept

Herding Cats - Glen Alleman - Wed, 11/11/2015 - 21:28

It's common these days to re-purpose a quote or a platitude from one domain into another and assume it's applicable to the second domain. My favorite recent one is

"Layers of redundancy are the central risk management property of natural systems‚ÄĚ - Taleb

Taleb is the author of Black Swan, about long tailed statistical processes in the financial domain. These Black Swans tend to bite you when you least expect it. Are there Black Swans in the software development domain? Only if you're not looking. Financial systems are rarely engineered to perform in specific ways. Software systems are, st where I work and I suspect everywhere someone is paying money for the system to be developed or acquired. 

So let's look at the Taleb quote that is often re-quoted by agile people and especially those advocating no estimates.

First some full disclosure. One of my graduate degrees in Systems Management, which is a combination of Systems Engineering and Finance. As well I work with systems engineers and support systems engineering processes in the aerospace and defense  domain. So I'll predisposed to view the work through the eyes of Systems Engineering. Everything is a System is a good starting point for what we do. 

Now let's look at the Taleb quote through the eyes of Systems Engineering and the software systems that are engineered in the domain we work. There are many kinds of redundancy found in our systems. To avoid falling victim to platitudes that abound in the agile and No estimates domains, let's start with a framing assumption.

Redundancy  provides resiliency to the system to withstand disruption within acceptable degradation parameters and to recover within an acceptable time and composite costs and risks.

In Taleb's (financial trading systems) domain resilience is desirable as it is in software intensive systems. Software systems that fly the airliner you ride on, manage the trains, process credit card transactions, control air traffic, manage the moving parts of your car. Any system where software is the dominate component for the proper functioning of the product or service.

There are rules for assessing the resiliency that results from redundancy or other system design aspects

  • Absorption rule - is a buffering characteristic that prevents overload of the system. Redundancy can provide this protection. The Microsoft¬†Always On product provides¬†this as well as other resiliency and redundancy¬†capabilities.
  • Limit Degradation support rule - provide a lower limit to which the system can degrade before failing. This is he¬†circuit breaker for your home. Also the¬†circuit breaker for the stick exchange.
  • Margin Support Rule - margin is added to the system to protect from disruptions. This can be schedule margin, cost margin, technical performance margin, operational margin. Any kind of margin that allows the system to continue to operate properly inside the range of parameters.¬†

This notion of margin is absent from Agile development. And the result is when things go wrong, you're late, over budget and the product doesn't work. To have margin we must be able to estimate how much margin. Too much margin is a waste. Too little margin will not protect the system from disruption. 

  • Physical Redundancy rule -¬†buy two in case one breaks¬†was the request when I first started writing code for a Ballistic Missile Defense radar system. We were buying the original Sun I cards to replace legacy computers. I went on from there to work at a Triple Redundant process control startup as the Software Manager. Where we developed a physically redundant computer and software system in the petro-chem and nuclear power domain.¬†Fault-Tolerant System¬†Reliability¬†in the¬†Presence¬†of Imperfect¬†Diagnostic¬†Coverage, describes how that triple redundancy was protected through realtime fault detection and dynamic reconfiguration of the hardware components.¬†
  • Functional Redundancy rule - is sometimes called¬†design diversity and avoids the vulnerabilities of Physical Redundancy.
  • Layers of Defense rule - states that for a failure to occur a disturbance has to penetrate a series of layers simulate to layers of Swiss Cheese. The system has¬†holes like the holes in Swiss Cheese, that allow the failure to penetrate to the next level, where they can be handled.

So when we hear a platitude like Layers of redundancy are the central risk management property of natural systems ask what kind of redundancy, what kind of fault handling and response processes. In fact ask first is that quote used as a platitude even applicable in the domain of interest? Or is it just a phrase picked up and repeated with little or no understanding of the principles, practices, or processes to which it CAN be applied. 

[1] The Theory and Practice of Reliable System Design, Daniel Siewiorek and Robert Swarz

Related articles Systems Thinking, System Engineering, and Systems Management The Use, Misuse, and Abuse of Complexity and Complex Want To Learn How To Estimate? Agile as a Systems Engineering Paradigm Software Engineering is a Verb
Categories: Project Management

Veterans Day 2015

Herding Cats - Glen Alleman - Wed, 11/11/2015 - 16:00


For all who have served. For those I know directly in my professional and personal life. For all who have served throughout our United States. Let's celebrate our service. 

Categories: Project Management

Marine Corps Birthday

Herding Cats - Glen Alleman - Tue, 11/10/2015 - 19:26


Having served with Marines, Happy Birthday. Having had Marines on my work teams, Happy Birthday

Semper Fi

Categories: Project Management

Who Can Add Items to the Product Backlog?

Mike Cohn's Blog - Tue, 11/10/2015 - 16:00

My wife, daughters and I use Wunderlist to manage our shared grocery list. Any time one of us notices something we're out of, that person adds it to the grocery list. Then, whoever is taking their turn at doing the weekly grocery shopping checks items off the list while in the store. It works really well.

I’m thinking about this because someone asked me recently about who on an agile team can add items to the product backlog. Can only the product owner add items to the product backlog?

My view is that anyone on a team should be allowed to add to the product backlog. A tester may come with a good new feature idea. The tester is allowed to add that item to the product backlog. The same is true for any other role on the team.

Although anyone can add to the product backlog, it is the product owner who prioritizes what the team works on. This means that while you or I may contribute a new idea to the product backlog, if it's a bad idea, the product owner will probably put it near the bottom of the product backlog (where it may never get worked on).

The product owner may even take it off the product backlog and throw it away if it's something the product owner does not want, or is so low priority that the product owner knows the team will never get to it.

Note that I still consider this as a team having had a chance to add that item to the product backlog. The item was added even if only momentarily. It was then briefly considered before the product owner removed it.

So, anyone can add an item to the product backlog. But it's the product owner who determines what happens to the product backlog item.

When adding groceries to Wunderlist, I like to tease my wife that my dog has gotten a hold of my iPhone and entered his grocery request for "BONEZ." Yes, although, my dog is capable of using Wunderlist on an iPhone, he types in all caps and cannot properly spell "bones."

I'll often enter this two or three times into the grocery list when it's my wife's turn to shop. And as the product owner for that weeks' shopping, she will promptly ignore her team's request to buy BONEZ.

Very practically speaking, what I recommend product owners do is have a location in the product backlog tool into which team members can add new stories. The product owner then periodically reviews new items in this section, and handles them appropriately.

Some are moved to areas in the tool where they'll be worked on. Others (like "BONEZ") might be deleted as low priority.

In general, a product would suffer if all ideas had to originate with the product owner. New ideas should be valued regardless of the source. The product owner prioritizes what the team works on, but that does not mean that all ideas have to originate in the product owner's head.

Quote of the Month November 2015

From the Editor of Methods & Tools - Tue, 11/10/2015 - 15:31
Because we are working in such small increments, the only thing we need to come up with at a Retrospective is something to try out for the next few weeks: an experiment. Because we are only going to try the experiment for a limited amount of time, any negative impact is controlled by the fact […]

Grady Booch: The Future of Software Engineering

From the Editor of Methods & Tools - Fri, 11/06/2015 - 10:21
No matter what future we may envision, it relies on software that has not yet been written. Even now, software-intensive systems have woven themselves into the interstitial spaces of civilization, and we as individuals and as a species have slowly surrendered ourselves to computing. Looking back, we can identify several major and distinct styles whereby […]

Advice for Interviewing ScrumMasters

Mike Cohn's Blog - Tue, 11/03/2015 - 16:00

Interview ScrumMasters by Asking About Real-World Situations

Interviewing Scrum Masters can be difficult because the job is harder than most to turn into a checklist of things a candidate needs to know and things a candidate will do. Much of the interviewing for a Scrum Master will be the same as interviewing for any other position, so I don’t want to spend a lot of time repeating general job interview advice in this post. Instead, I want to focus on things unique to the role of Scrum Master.

However, I do want to stress the importance of making sure candidates are comfortable during the process (interviews are stressful!) and asking open-ended questions. Also, spend time preparing for the interviews by thinking about what makes an ideal Scrum Master.

6 Desirable Attributes of a Good Scrum Master

While your list may differ, I have six things I look for in great Scrum Masters. As you interview each candidate, see how well candidates measures up against these criteria. At the end of each interview, I simply mark each candidate with a 1 to 5 score for each attribute, but any sort of marking scale you want will work.

  1. Responsible
    Scrum Masters are able and willing to assume responsibility, but also know when to step back and let the team do so when appropriate. An orchestra conductor once explained that he has no real power over how the individual musicians play. Yet he feels a tremendous responsibility toward helping them be the best musicians they can be. AI good Scrum Master thrives on responsibility without power.
  2. Humble
    Good Scrum Masters are not driven by their egos. You want a Scrum Master who puts the team’s needs above his or her own. I’ve been in sprint reviews in which a non-coding Scrum Master grabbed the keyboard and said things like, “Here’s what I had the team do …” and “Here’s what I had them build next …” That’s not the language of a humble Scrum Master. Perhaps, “Here’s what we did …” -- but even better: be quiet, and hand the keyboard to a team member.
  3. Collaborative
    A good Scrum Master works to ensure a collaborative culture exists within the team. The Scrum Master needs to make sure team members feel able to raise issues for open discussion. When disputes arise, collaborative Scrum Masters encourage teams to think in terms of solutions that benefit all involved rather than in terms of winners and losers.
  4. Committed
    Some Scrum Masters take a laidback attitude toward the success or failure of the project. That’s not right. A good Scrum Master needs to be as committed to the success of a project as the team. I want to find candidates who will be tenacious in resolving impediments and highly committed to the ultimate success of the project.
  5. Influential
    Scrum Masters often need to lead without direct authority. Being able to influence others is important. Some Scrum Masters achieve this through persuasive argumentation skills. Others through charisma and personality. It doesn’t really matter which method a Scrum Master uses. But Scrum Masters will need to influence team members as well as those outside the team, so being influential is a desirable trait.
  6. Knowledgeable
    By knowledgeable I mean either of the technology or the domain. I put both of these in the “is a plus” category. I do not need a Scrum Master to be a former technical person. And I don’t need the Scrum Master to have worked in the domain of the project. But, each of these is a plus that could set a candidate apart from other candidates.

How Will a Scrum Master Perform?

Beyond looking for certain attributes of a Scrum Master’s personality, I want to assess how a candidate will perform in various situations. To do that, I like to ask a few situational questions of the candidate. For example:

The boss is at a trade show and needs two new unplanned features by tomorrow. Last week when this happened, you just put in a little overtime and wedged it in. Same thing the time before. If you don’t come through, it will cost you sales and your boss will be mad.

What do you do?

By asking questions like this, I put the Scrum Master in plausible, real-life situations and see how he or she will respond. I can then gauge whether I agree with the response, whether it’s reasonable, appropriate, and so on.

I like to combine hypothetical situational questions such as the one above with open-ended questions about the candidate’s own real experience such as:

  • Tell me about the worst advice you ever gave a team.
  • Tell me about one of the times you helped a team that you’re most proud of.

Questions like these are great because they give you insight into a candidate’s specific background. But I always include some hypothetical, situational questions because that allows me to more easily compare candidates.

Think about the question above with the boss wanting the new, unplanned features for the trade show. Imagine having heard answers to that from five different candidates for your open Scrum Master position. The answer to a question like that is often sufficient for me to know which candidate I want to hire.

Situational questions and a candidate’s answers to them can be a powerful tool in assessing who will be a good fit for an open Scrum Master job.

What Do You Ask In Scrum Master Interviews?

What do you think? What do you ask in Scrum Master interviews? Please share your thoughts in the comments below.

Sign up now to get Instant Access to the 12 Questions Every ScrumMaster Interview Should Have (function() {var $__MAForm;($__MAForm=function() { if(typeof($__MA)=='undefined'){return window.setTimeout($__MAForm,50);}else{ $__MA.addMAForm('9464f7c3-b42f-40f4-a6a3-cf0805741401', 'forms.mountaingoatsoftware.com'); }})();})();

People: Resilience Creators, Not Resources

I’ve been traveling, teaching, speaking and consulting all over the world. I keep encountering managers who talk about the “resources.” They mean people, and they say “resources.”

That makes me nuts. I blogged about that in¬†People Are Not Resources. (I have other posts about this, too, but that’s a good one.)

I finally determined what we might call people. People are “resilience creators.” They are able to recognize challenges, concerns, or problems, and adjust their behavior.

People solve problems so the project can continue and deliver the product.

People fix problems so that customer support or sales can make the user experience useful.

People deliver products and/or services (or support the people who do) so that the company can continue to employ other people, deliver the company’s work, and acquire/retain customers.

We want resilient companies (and projects and environments). When we encounter a hiccup (or worse) we want the work to continue. Maybe not in the way it did before. Maybe we need to change something about what we do or how we do it. That’s fine. You hired great people, right?

People can solve problems so that the company can be resilient. To me, that means that the people are resilience creators, not “resources.”

People create resilience when they have the ability to solve problems because you asked them for results.

People create resilience when they understand the goals of the work.

People create resilience when they have the ability to work together, in a holistic way, not in competition with each other.

What would you rather have in your organization: resources or resilience creators?

Categories: Project Management

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.

The Twilight Zone Approach to Business Decision Making

Herding Cats - Glen Alleman - Tue, 10/27/2015 - 16:28

CSVHqUjWUAAx9f1When we here about focusing on value first, delivery early and often, there is rarely any mention of the cost of that delivery. Or anything about the customers ability to accept those early and often deliveries and actually put them to work earning that value.

In the must read book Product-Focused Software Process Improvement there is a paper, Value Creation by Agile Projects: Methodology or Mystery? a Conference Paper from Lecture Notes in Business Information Processing · January 2009.

We can learn a lot from this journal paper.

Business value is a key concept in agile software development approaches. This paper presents results of a systematic review of literature on how business value is created by agile projects. We found that with very few exceptions, most published studies take the concept of business value for granted and do not state what it means in general as well as in the specific study context. We could find no study which clearly indicates how exactly individual agile practices or groups of those create value and keep accumulating it over time. The key implication for research is that we have an incentive to pursue the study of value creation in agile project by deploying empirical research methods.

The platitude of we focus on value is just that - a platitude. And like most platitudes, it gives you a warm and fuzzy feeling inside, but provides ZERO advice in terms of actionable outcomes.

Value (business value of the software) has several attributes that need to be determined before the Value of the Value can be assessed as desirable

  • What is the cost of acquiring that value?
  • When will I be able to put that value to work to start earning back that cost?
  • Over what period of time will I have to pay to acquire that value?
  • Are there any recurring costs associated with acquiring that value?
  • How do I account for the cost of acquiring¬†that value and accounting for the Value itself in the larger accounting systems for the project being funded?

This is the FASB 86 problem with Agile Software Development. This is a capitalization issue for business. All those agile and #Noestimates platitudes need to come in contact with the reality of FASB 86 and other GAAP governance when spending other peoples money. Not much to date on that.

These are all finance and accounting questions, no coding questions. So in the end...

In the economics of writing software for money and producing the Value to the customer for that software, knowing the cost to acquire that Value, the time cost of money when producing that Value, and the planned arrival date of that Value versus the business need date of that Value all have to be known to some degree of confidence in order to make credible decisions. Determining this information is called ESTIMATING.

No matter how often it is repeated the #Noestimates applicable to writing software for money - using other peoples money - it simply not true. It violates microeconomics of decision making, managerial finance principles, simple time cost of money accounting principles, and is a all around bogus idea.

Making decisions in the presence of uncertainty about future outcomes (value in exchange for cost) requires making estimates.

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