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!

Process Management

A Really Simple Checklist For Change Readiness Assessment

A wrapping paper change barbarian

A wrapping paper change barbarian

When you begin a change process it is sometimes important to have a reminder of the critical points required to start the journey. If you were getting ready for vacation the checklist might include identifying who is going and who is in charge, deciding on a destination, a map, hotel reservations and a list of people to tell you are going. Beginning a process improvement project is not very different. I have constructed a simple checklist with five of the most critical requirements for preparing to embrace a journey of change. My critical five are:

1. An Identified Goal

2. Proper Sponsorship

3. Sufficient Budget

4. A Communication Strategy and Plan

5. A Tactical Plan

The first item on the checklist is an identified goal. The goal is the definition of where you want to go, the destination in the vacation analogy. A goal provides direction and a filter to understand the potential impact of constraints. Examples of goal can range from something as simple as, “reduce the cost of projects” or as complex as “attain CMMI Maturity Level 5”. The goal also sets the table for discussing all of the other items on the checklist, such as the required budget. One piece of advice: make sure your goal can be concisely and simply stated. In my opinion simplicity increases the chance the goal will be broadly remembered, which reduces the number of times you will need to explain the goal, which will increase the amount of time available for progress.

Proper sponsorship is next on the list. Sponsorship is important because it is provides the basis for the authority needed to propel change. There are many different types and levels of sponsorship. The word “proper” is used in this line item to remind you that there is no one type of sponsorship that fits all events and organizational culture. Examples of different flavors of sponsor include “the barbarian.” The barbarian is the type that will lead the charge, but typically is less collaborative and more a command-driven personality. Barbarians tend to be viewed as zealots who harness their belief structure to provide single minded energy towards the goal they are focused on. Having a barbarian as a sponsor can infuse change projects with an enormous amount of power. The bookend to the barbarian type of sponsorship is the “bureaucrat”. Sponsorship from a bureaucrat is very different. Instead of leading the charge bureaucrats tend to organize and control the charge. They may provide guidance, but they rarely get directly involved in the fray. The examples show two different varieties of sponsorship each that will fit in different organizations. In a life or death situation I would like to have a barbarian for a sponsor, however if I was affecting incremental changes in a command and control organization the bureaucrat would make more sense. Remember sponsorship is important because sponsorship give you access to power.

Budget is next on the checklist. The term budget can cover a wide range of ground ranging from money to availably of human resources (effort). The budget will answer the question “how much of the organization’s formal resources can you apply?” The budget that ends up being identified to support change is always less than what seems to be needed. Use this constraint as a tool to motivate your team to find innovations on the way to attaining the goal rather and a reason to rein in your goal.

The first plan I recommend building is an organizational change management plan (OCMP). The OCMP is a means to frame how your project is going to transform the future state of the organization. An organizational change management plan will integrate the project roles and responsibilities with the requirements for communication, training, oversight, reporting and the strategies to address resistance, and reinforcement activities. We will address concepts of organizational change management in essay later in 2009. The OCMP is a mixture of a high level map and how-to document that is critical to ensure you are as focused on how you are change the organization as to tasks required to define and implement specific processes.

Finally you will need a tactical plan that lays out the tasks you need to accomplish and the order the tasks need to be done. The focus and breadth of the tactical plan you use will be different depending on the project management technique that you use. For example if you use a time boxed technique like SCRUM your tactical plan will focus on identifying tasks for the current sprint based on the backlog of items required to reach your goal. Regardless of the planning technique used, a sprint backlog or detailed project schedule doesn’t matter you must have a tactical plan or risk falling into random activity. Use the technique that conforms to your project’s needs and your organization’s culture. The bottom line is that you will you need to understand the activities and order they occur in to get to your goal.

Change is difficult to accomplish in the best of times and almost impossible if you fail to start properly. The simple checklist for change readiness described in this paper was developed and compiled to help you focus on a set of topics that need to be considered when beginning any process improvement project. Are there other areas that should be on the list? Can each topic area be decomposed into finer levels of granularity? I believe the answer is certainly and I would urge you to augment and decompose the list and further to share your results. In any case a checklist that focuses you on getting your sponsorship, goals, budget and plans in order can only help you start well.


Categories: Process Management

Being a Great Software Development Manager

From the Editor of Methods & Tools - Thu, 03/27/2014 - 15:33
Any manager, when goals are not being met, identifies the impediments and whenever possible removes them. A good manager goes further by identifying and removing potential impediments before they lead to the goals not being met. A great manager makes this seem easy. Tony Bowden, Socialtext Source: Managing the Unmanageable, Mickey W. Mantle & Ron Lichty, Addison-Wesley

Code of Ethics: A Proposal

UntitledA code of ethics is a compilation of ethical principals brought together into a framework that can be used to guide behavior.  I recently asked friends I work with how many codes of ethics they are bound by, and after a bit of discussion the average was four.  Examples include: IFPUG, PMI, IEEE, SEI, society and religions.  Kevin Brennan, Vice President for Professional Development of IIBA, tweeted me that a group needs a code of ethics to define itself as a profession and they are required for certification bodies under ISO 17024.

I would be the last person to suggest that codes of ethics are a bad idea.  However, the proliferation of codes combined with their relative complexity does give me pause.  An example of the complexity of common of codes of ethics is demonstrated below:

  • IIBA: Code of Ethical Conduct – 22 items
  • PMI : PMI’s Code of Ethics and Professional Conduct – 36 items
  • IEEE: Software Engineering Code of Ethics and Professional Practice – 80 items

All three of these codes are good, however I doubt very few people can recall any of their specifics. That greatly reduces their overall effectiveness.  Layer that on top of association codes, corporate codes like the great code of ethics from Lockheed (approximately 17 items) and the complexity level goes up.  I said all of this complexity gives me pause because I would like to see process improvement professionals embrace a code of ethics, but I do not want to increase the level of ethical complexity unless it has value.  I think we can keep this deadly simple.  The code I am proposing is:

Process Improvement Code of Ethics

  1. Treat others as you would like to be treated.  (Golden Rule)
  2. Follow a process to create and maintain processes. (eat your own dog food)
  3. Meet the commitments you make.
  4.  Avoid personal conflicts of interest.
  5. Only pursue changes that benefit the organization.
  6. Make decisions as transparently as humanly possible.

I would suggest that this code is simple and to the point.  Note: I am making the assumption that you’re adhering to laws and that lying, cheating and stealing your neighbor’s Butterfinger are not on the table, based on other codes of ethics.

What is missing? If you adopted these ethical guidelines how would they affect your projects?  How would they affect your professional life?   I am looking forward to your input, reactions and suggestions.  I would also like your opinions on whether ethics and process improvement should be discussed in the same context.


Categories: Process Management

Project and Process Improvement Ethics: A Primer

Religion is just one way people learn ethics.

Religion is just one way people learn ethics.

I recently overheard an offhanded comment that went something like, “if you aren’t cheating, you’re not trying hard enough.”  What are ethics?  What is the purpose of ethical frameworks?  Why should they matter to those who manage process improvement?

Wikipedia defines ethics as a branch of philosophy that addresses questions about morality—that is, concepts such as good vs. bad, noble vs. ignoble, right vs. wrong, and matters of justice, love, peace, and virtue.  Hardly the stuff of project management or process improvement, however there is a branch of ethics called applied ethics (doesn’t that sound much more practical?) that seeks to address our daily business lives.

Interest in ethics waxes and wanes over time; they tend to wax when things go awry.  Obvious examples abound, like when Enron  went up in flames, ethics became a hot topic, at MCI during their accounting debacle and even during the BP Oil well crisis. But there are less obvious examples such as the spin to under play a risk in a status report or when someone occasionally conflates effort and progress when a project is behind.  Unless a framework or code is in place to highlight these transgressions, large or small, they go unnoticed and nothing can be changed.

Most ethical frameworks serve two common purposes. The first purpose is to guide behavior so that it is predictable.  Codes of conduct provide a path to guide both the organization’ and the individual’s actions (to an extent they can be different).  Codes of ethics, codes of conduct and the effort to enforce them help to identify deviant behavior before it can injure the organization. The second purpose is as an announcement to the larger world of the higher order rules an organization intends to follow.

The ethics enshrined in these frameworks evolve to guide behavior and provide all affected parties with an understanding of how people (and people proxies) should act.  Rules, laws and manifestos (statements of principles and ethics) are how ethics are applied in the real. The rule, “Thou shall not install un-unit tested code” creates a set of expected behaviors and a set of obligations on all parties.  Living up to the rule is a matter of ethics.  The translation of ethics into codes of conduct, rules, laws or other codes provide a line in the sand so that you can judge whether an action is ethical or not.  The more black and white the ethics rule is the easier it is to follow in real time.

Most corporate codes of conduct or ethics do not address some of the more specific issues with which a project manager of a process improvement projects will need to wrestle.  What can be done?

I begin my process improvement projects by establishing a process improvement manifesto.  The exercise has many benefits; however the primary goal is to help empower the team to make the decisions without having to get permission.  The manifesto acts a basis to form very specific code of ethics to shorten the decision making loop which will improve efficiency for normal IT projects and process improvement projects.


Categories: Process Management

Software Development Conferences Forecast March 2014

From the Editor of Methods & Tools - Tue, 03/25/2014 - 14:04
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: Big Data TechCon, March 31-April 2, Boston, USA Software Testing Analysis & Review Canada Conference, April 5-9 2014, Toronto, Canada Agile Adria Conference, April 7-8 2014, Tuheljske Toplice, Croatia Optional Conference, April 8-9 2014, Budapest, Hungary GOTO Amsterdam 2014, ...

3 Roles That Need to be Involved in Agile Estimating with Planning Poker

Mike Cohn's Blog - Tue, 03/25/2014 - 13:00

When estimating your product backlog with Planning Poker, it’s important to have the right people participate. Let’s go over who needs to be there, and what the job of each is during an agile estimating meeting.

First, of course, we start with the team. All of a Scrum team’s members should be present when playing Planning Poker. You may be tempted to estimate without the individuals in some role—don’t.

An estimate put on a product backlog item (most frequently a user story) needs to represent the total effort to deliver that item. It’s not an estimate of all the work except database changes or all the work except testing.

Those individuals need to be there because they’re needed to deliver many of the product backlog items. They’re also there because they will often have something to contribute to discussions of work they may not directly be involved in.

I’ve seen many examples when a comment by a tester about his or her own work made a programmer realize he overlooked something in his own work.

Programmers are, of course, the best at estimating programming work. And testers are best at estimating testing, and so on. But that doesn’t mean someone with a specialty in one skill won’t have something to add in a discussion about something that will be done by someone else.

Also in a Planning Poker meeting will be the ScrumMaster to estimate product backlog items. A team’s ScrumMaster is its facilitator, and so the ScrumMaster should participate in all regularly scheduled meetings, and a Planning Poker session is no exception.

But should the ScrumMaster estimate alongside the rest of the team? If the ScrumMaster is also a technical contributor such as a programmer, tester, designer, analyst, DBA, etc., then definitely.

By right of contributing in that way, the ScrumMaster holds up a Planning Poker card just like the others.

However, a pure ScrumMaster should estimate only by invitation of the rest of the team. If the others say, “Hey, we have to estimate, why don’t you?” then the ScrumMaster holds up a card each round.

A ScrumMaster who has a solid technical background (in any role) will be especially likely to estimate along with the others.

That brings us to the product owner—and, yes, by all means the product owner needs to be present during any Planning Poker estimating session. The product owner describes each item to the team before they estimate it.

Also, team members will have questions—“what should we do if … ?” “What if the user does … ?”—and the product owner needs to be present to answer those questions.

Product owners, however, generally do not hold up cards during Planning Poker sessions. However, my official answer is the same as for the ScrumMaster: if the team invites the product owner to estimate, the product owner should do so. This is pretty rare, though, and it’s far more common for a ScrumMaster to be invited to estimate.

So, like many things in Scrum, Planning Poker is a whole-team activity.

Organisational Inertia - A Predictor for Success of Agile Transformations? (Part 2)

Xebia Blog - Tue, 03/25/2014 - 01:30

In part 1 (Organisational Inertia - Part 1) I have focussed on the question: 'Organisational Inertia - What is it?’. This blog addresses the question ‘How do we measure it?’.

I'll start from the definition of Organisational Inertia as defined in part 1. Then connect to existing models of Organisational Inertia and the relation to Agile teams and show how the analog with Physics is used to find a measure for the 'acceleration'. Then I'll combine these elements to provide a way of measuring inertia. Finally I'll provide basic examples.

Definition of Organisational Inertia

Following the analogy with physics I defined Organisational Inertia in Organisational Inertia - Part 1 as:

DEFINITION

Organisational Inertia is an organisation’s capability to change after applying some force to it. Specifically, I define it as the ratio of the force applied and the speed of organisational change (acceleration) in reaction to some applied force, or in formula "Inertia (M) = Force / Acceleration".

We just shifted the problem of defining Organisational Inertia to defining ‘some applied force’ and ‘speed of change’. The next sections will provide an interpretation of these in the context of Agile teams and a model to describe 'some applied forces'.

Origin of the Forces Driving Organisational Change: Change Restraining and Change Facilitating Forces

Associated with Organisational Inertia are two competing forces as described in the Inertia model of Connor & Lake [Con88] (see also [Kin98]). This model describes the Change-restraining forces and the Change-facilitating forces.

The origin of the forces driving Organisational Inertia [Lar96]

The model recognises that there are forces that hinder change and that there are forces that facilitate change.

One of the Agile principles is to regularly reflect on how you are doing and improve. By doing so Agile teams not only improve over time but they change too. An Agile team that changes will force the environment to change with it.
For more detailed information on this, check out the ‘fitness landscape’ [App11] chapter 15 “How to improve everything”.

Another common way Agile teams force the environment to change is by pulling more work in than the environment is capable of delivering. Or, by pushing more working software into production and thereby literally pushing the limits of what the environment is capable to process. The latter mechanism drives organisations towards DevOps [Deb11]. The combination of applying a force to both the up- and down-stream teams is what drives the need for BusDevOps (Agile Delivery Model), see Agile Delivery.

Examples I often see in practise of how Agile teams force the organisation (or environment) to change include:

  • a faster delivery rate forces the environment to cope with more releases and simultaneously forces the business to keep up by supplying user stories at a higher rate,
  • raising impediments,
  • the business wants more features than IT can deliver (this often drives the need to transition form a traditional way of working to an agile way of working).

For a systemic view on cause and effect related to Organisational Inertia see e.g. [Lar96].

How (Agile) Teams Act As Change-Facilitating Forces

Agile teams continuously improve. The way they improve I divide in 3 types. With each type I associate a 'force'. The next section will go into details of quantifying them.

In Management 3.0 [App11] chapter 15 “How to improve everything” the concept of the ‘fitness landscape’ is explained. In this metaphor the team is part of the landscape (the environment of the team within the organisation) in which the team optimizes a certain variable, for instance the business value it creates. The optimum is symbolised by the highest mountain peak. Through improvements the team finds its way to the highest peak. Besides team intrinsic changes the team can also change the environment and thereby change the landscape by moving mountains towards the team instead of moving towards the mountain.

Following this metaphor there are three ways for a team to reach the top of the highest peak:
I) gradually improve (changes intrinsic to the team),
II) large improvements (kaikaku) and jump to other (nearby or remote) mountains, or
III) change the environment, i.e. moving the mountains to the team.

Gradual Improvements (Type I Changes)
Agile teams regularly evaluate how they are doing. A common practise is to perform a retrospective every two weeks. In the retrospective the team decides what to change and executes these improvements in the next sprint (or time period). With these improvements the team walks the ‘fitness landscape’ to the nearest mountain peak. The improvements may be gradual and internal to the team. By this we mean that it increases the velocity and does not force the environment of the team, i.e. the organisation, to change. The team does not exert a force to the organisation.

Large Improvements (Type II Changes)
It may also be the case that the improvements within the team either dramatically increase the velocity or many gradual improvements increases the velocity over a certain threshold. When this happens - in my experience it is not a question whether this will happen but rather ‘when’ - it will force the direct environment of the team to change with it.

For example, when teams start to deliver user stories faster the business needs to keep up by having enough user stories ready.

Another example is that operations needs to keep up by putting more features into production.

This way the team applies a force to the surrounding organisation that needs to change as well. The team is not just walking the ‘fitness landscape’ but forcing the landscape to change as well [App11].

Moving Mountains (Type III Changes)
Changing the landscapeThe third way for teams to apply a force is to raise impediments and have the organisation help them by addressing the most important impediments. By structurally solving impediments the organisation is changing the ‘fitness landscape’ [App11] by moving the mountain peaks to the team.

With 'structurally solving impediments' I mean that solving the impediments requires company policies to be changed.

An Organisation’s Speed of Change

The final part is to have a way of measuring the speed of change while the Agile team exerts a force upon the organisation. Before we can answer this question we need to identify how to observe that an organisation changes. Possible variables are:

  • the trend of the (average) resolution time of impediments,
  • change in the rate of bringing features to production,
  • change in the rate of taking work to the team(s),
  • company policies being changed.

Potentially this could become a long list. But are all these changes relevant? Ultimately it’s the bottom line that counts. It’s all about the outcome. Let’s try to come up with variables that are of value to the business. This is pretty close to the bottom line. At least close enough. Variables that come into mind include:

  • change in the rate of business value per unit of time,
  • change in rate of an organisation’s (agile) maturity rating,
  • change in rate of product incidents per unit time.

These are all variables that can be measured and are the (complex) outcome of the changes made.

The choice depends on the goal that you want to achieve with the (agile) transition. As long as this is communicated clearly to the organisation and progress is being made as measured using this or these variables, you are measuring the rate of success and there will be enough energy in the organisation to continue the transition and avoid Organisational Gravity kicking in.

Metrics for Organisational Inertia

From the aforementioned examples we recognise the following metrics for the 'forces' (Change Facilitating):

  • [F1] the number of raised impediments per time period, e.g. per sprint or per month,
    Force = <Number of Raised Impediments per Period>,
  • [F2] difference in rate (throughput) for pre-sprint, sprint and post-sprint parts in a so-called cumulative flow diagram,
    Force [F2a] = <Business Value Delivered in Production per Period> - <Work According to DoR Worth of Business Value per Period>, or
    Force [F2b] <Business Value Delivered in Production per Period> - <Work Completed according to DoD Worth of Business Value per Period>

Force [F2a] measures the 'strength' with which the (Scrum) team is pulling work from the Product Owner. A positive value means that the PO cannot keep up with the team.
Force [F2b] is similar for the IT-Ops - (Scrum) team interaction. Positive values indicate the (Scrum) team is pushing work for production at a faster rate than the organisation is capable of taking into production.

The associated metrics for measuring the 'acceleration' (speed of change) are:

  • [A1] the trend of the average number of resolved impediments per time period; count only resolved impediments that required changes in company policies,
    Acceleration = Δ(<Number of Resolved Impediments per Period>)/<Period>,
  • [A2] the trend or change in the rate of business value (outcome) delivered per time period,
    Acceleration = Δ(<Business Value Delivered in Production per Period>)/<Period>.

The metrics just given are readily available to Scrum teams and can easily be applied to any team, kanban type of system, or to any part of the total value stream.

Putting It All Together

Using the results of the previous section I quantify Organisational Inertia in terms of measurable variables available to (Agile) teams.

Gradual internal improvements that the team makes (Type I changes) often lead to Type II changes after a certain period of time. Therefore I only explicitly address Type II and Type III changes (as explained earlier).

Are We Moving the Mountains? (Type II Changes)
Taking the change facilitating forces as a basis the Organisational Inertia is derived as follows.

First, consider the metric for inertia (  M_\mathrm{org} M_\mathrm{org} ) based on business value, i.e. [F2b] and [A2] from the previous section. Combining these gives:

 \langle\text{Value delivered per Period}\rangle - \langle\text{Value ready (DoD) per period}\rangle = M_\mathrm{org}\times\Delta(\langle\text{Value delivered per period}\rangle)/\langle\text{Period}\rangle \langle\text{Value delivered per Period}\rangle - \langle\text{Value ready (DoD) per period}\rangle = M_\mathrm{org}\times\Delta(\langle\text{Value delivered per period}\rangle)/\langle\text{Period}\rangle

What does this formula tell us?

  • if the team’s delivery rate balances the organisation's rate of putting features into production no force is exerted and the organisation will not be forced to change; then also no change (Δ) in the delivery rate,
  • if the team delivers more functionality than the organisation can take into production, the team exerts a certain force upon the organisation which needs to undergo structural improvements causing a positive change (Δ) in the delivery rate,
  • for small values of the inertia (  M_\mathrm{org} M_\mathrm{org} ) the effect on the change in delivery rate is larger.

Note: A  unit of  measure for  M_\mathrm{org} M_\mathrm{org}  is ‘time’, e.g. 'weeks' or 'sprints' for Scrum teams.

Example 1. Suppose that the team delivers 5% more business value each sprint. Suppose further that they deliver 20% worth of value faster than can be taken to production. Then the inertia is ’4 sprint’ (20% divided by 5%).

Example 2. Suppose that no change in the rate of delivered business value is measured. Then the Organisational Inertia is infinitely large; under a change facilitating force it does not change.

The effect of Organisational Inertia on delivered business value

The effect of Organisational Inertia on delivered business value

Example 3. Suppose an inertia of ’4 sprint’ (Example 1). Further suppose that the team pushes 20% worth of features per sprint more than can be taken into production. Then it will take M_\mathrm{org}M_\mathrm{org} /20% = 20 sprints to double the production rate.

Example 4. As in the previous example, the graph to the right shows the same team but in an environment in which the inertia is twice the inertia of the other environment. The team in the environment with the least inertia delivers value at a rate that increases twice as fast as compared to the other team. This results in twice as much business value being generated.

Are the Mountains Moving? (Type III Changes)
Another possibility is to take impediments as a basis to define and measure the Organisational Inertia (  M_\mathrm{org} M_\mathrm{org} ):

 M_\mathrm{org} = \frac{F_1}{A_1} = \frac{\langle\text{Number of Raised Impediments per Period}\rangle}{\Delta(\langle\text{Number of Resolved Impediments per Period}\rangle)/\langle\text{Period}\rangle} M_\mathrm{org} = \frac{F_1}{A_1} = \frac{\langle\text{Number of Raised Impediments per Period}\rangle}{\Delta(\langle\text{Number of Resolved Impediments per Period}\rangle)/\langle\text{Period}\rangle}

Note: Only impediments that actually result in changes in the organisation should be taken into account.

Note: This can also be translated in terms of business value by estimating how much more business value the team would be able to put into production if the impediment is resolved.

Note: The unit of measure is ‘time’, e.f. 'weeks' or 'sprints'.

Conclusion

Organisational Inertia is supplementary to the concept of Organisational Gravity and an indicator for how well the team’s environment is facilitating the team’s growth. The two counter balancing driving forces of the speed of organisational change are the Change-restraining and Change-facilitating forces.

An indicator available to agile teams for the Change-restraining forces is the average number of solved impediments per time period. Change-facilitating forces are the forces that teams exert on their environment. Indicators available to agile teams are the amount of pulling from the business for more ready features and pushing completed work into production.

Using the interpretation of the formula  F=M A F=M A , well-known in physics, in terms of the Change-restraining and Change-facilitating forces as defined in the model for Organisational Inertia from Connor and Lake  [Con88], and identifying MM with  M_{\textrm{org}} M_{\textrm{org}}  expressions for Organisational Inertia are derived.

Once the organisation's inertia is known, this can serve as a prediction how long it will take to increase the organisation's delivery rate with a certain amount and is related to the business case of Agile Transformations.

References [App11] Management 3.0, Jurgen Appelo, 2011, Pearson Education, [Deb11] Devops: A Software Revolution in the Making, Patrick Debois, August 2011, Cutter IT Journal, Vol. 24, No. 8, http://www.cutter.com/promotions/itj1108/itj1108.pdf, [Con88] Managing organization change, P.E. Connor & L.K. Lake, 1988, New York: Praeger, [Kin98] The development of an instrument for measuring organisational inertia, C Kinnear, G Roodt, Journal of Industrial Psychology, 1998, 24(2), 44-54; see http://ujdigispace.uj.ac.za/handle/10210/1047, [Lar96] The Dynamics of Organisational Inertia, Survival and Change, Erik R. Larsen, Alessandro Lomi, 1996, System Dynamics conference, http://www.systemdynamics.org/conferences/1996/proceed/papers/larse308.pdf

Why Are Requirements So Hard To Get Right? (part 2)

0322141511a

Not the most efficient communication technique

IT projects have been around in one form or another since the 1940’s. Looking back in the literature describing the history of IT, the topic of requirements in general and identification of requirements specifically have been top of mind since day one.  There are numerous definitions of ‘requirements,’ however at a high level requirements can be thought of as what the functionality developed by the project should ‘do’. Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.  This confluence forms a set of three constraints that are overlaid on flowing time which ensures subtle changes are continually being introduced to all of the variables.  A breakdown of process, people or environment will reduce the effectiveness of the result or render it unusable.  The factors driving the people category are typically the most volatile and a seemingly least controllable of all of the variables within the requirements process.  This essay will focus on the ‘people’ category with subsequent essays focusing on process, environment and suggestions for solutions.

People have a major impact on the vagaries of requirements.  All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product. A few of the more intractable contributors to requirements variance are:

  1. Lack of experience
  2. Human nature
  3. Communication
  4. Organizational politics

This is the continuation of our discussion in which we address communication and organizational politics.

Communications problems can be secondary effects of other initiating events such as a software defect, a missed date or a dropped requirement. The communication component of dealing with the problem compounds the problem.  The problem is compounded by the fact that many people just don’t communicate well because:

  • They don’t listen because they think they already to know the answer,
  • There are those that do not know enough about the business therefore can not interpret what they hear,
  • There are interviewees that don’t choose to answer the question asked,
  • or Interviewers that don’t ask the right question, and
  • Or interviewees that are the wrong person to interview.

The list could go on further; there are just lots of things that can go wrong.  Communication is a combination of getting the right people with the right knowledge facilitated correctly all in the right place at the right time.

Organization politics can cause communication problems by creating filters between the speaker and listener.  One example of a problematic type of organization politics is a topic called solution-driven requirements (also called a solution searching for a reason or an answer searching for a question). In teams or groups that organize around specific technical solutions (vendor packages) for example tend to look for ways to apply their solution to increase or maintain their organizational base. Unfortunately humans are great at recognizing patterns, and a solution is a pattern.  Pattern recognition is a survival technique however it has drawbacks for gathering requirements.  Gathering requirements with the solution already in mind is  like a solution hunting for a problem. Anything that potentially blocks the ability for interviewees to express themselves freely or for interviewers to hear business needs can potentially create a scenario where errors or omissions occur. Remember when all you have is a hammer you’re apt to see everything as a nail rather to consider that you might need some other tool.

There are a number of tactical solutions for all of these issues, however the first step to solving requirements issues that are people-centric begins with recognizing that a problem exists.  One best practice that I would recommend, taking a page out of the Agile handbook, is to use coaches to support the people working on gathering and managing requirements.  The role of coaches is to be the voice of the people focused inward on the team and the work.  A coach observes how work is done, provides support and instruction in a consistent and focused manner when and where it is needed.  This role is different from that of project manager which is externally focused, interacting with outside parties and clearing external roadblocks.  While people are not the only factor driving the quality of requirements, they are a critical factor.  Pay attention to how people are being deployed, provide support and instruction and make darn sure the right people are in the right place at the right time.


Categories: Process Management

Done & Retrospectives in Scrum, Software Architecture in Methods & Tools Spring 2014 issue

From the Editor of Methods & Tools - Mon, 03/24/2014 - 16:05
Methods & Tools – the free e-magazine for software developers, testers and project managers – has just published its Spring 2014 issue that discusses how to be bone in Scrum; why, when and how to perform successful retrospectives; Why it is better to chop onions instead of layers for a improved software architecture. Methods & Tools Spring 2014 contains the following articles: * The Principles of Done * Doing Valuable Agile Retrospectives * Chop Onions Instead of Layers in Software Architecture * Ranorex – Automated Testing Tool for Desktop, Web & Mobile Applications 40 pages of ...

SPaMCAST 282 – Ben Linders and Luis Gonçalves on Retrospectives

Software Process and Measurement Cast - Mon, 03/24/2014 - 03:00

Listen to the Software Process and Measurement Cast 282. In the SPaMCAST 282 we feature our interview with Ben Linders and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all projects and organizations need to deliver more value over time.

Luis Gonçalves is an Agile Coach, Co-Author, Speaker and a Blogger. He has been working in the software industry since 2003, being an Agile practitioner since 2007. Luis is the co-author of “Getting Value Out of Agile Retrospectives” and a co-founder of a MeetUp group in Munich called High Performing Teams.

He likes to write and share ideas with the world and this made him passionate blogger. You can follow his blog: http://lmsgoncalves.com. People can find Luis on twitter: @lgoncalves1979

Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. Co-author of Getting Value out of Agile Retrospectives. As an advisor, coach and trainer he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English) and as an editor for Agile at InfoQ. You can find him on twitter: @BenLinders.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on user stories.  A user story is a brief, simple requirement statement from the user perspective. User stories are narratives describing who is interacting with the application; how they are interacting with the application and the benefit they derive from that interaction.

Upcoming Events

ISMA 9

I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.

More information

QAIQuest 2014

I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI's mission is to pull together the expertise and educational efforts of the world's leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

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

Categories: Process Management

SPaMCAST 282 – Ben Linders and Luis Gonçalves on Retrospectives

www.spamcast.net

http://www.spamcast.net

Listen to the Software Process and Measurement Cast 282. In the SPaMCAST 282 we feature our interview with Ben Linders and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all projects and organizations need to deliver more value over time.

Luis Gonçalves is an Agile Coach, Co-Author, Speaker and a Blogger. He has been working in the software industry since 2003, being an Agile practitioner since 2007. Luis is the co-author of “Getting Value Out of Agile Retrospectives” and a co-founder of a MeetUp group in Munich called High Performing Teams.

He likes to write and share ideas with the world and this made him passionate blogger. You can follow his blog: http://lmsgoncalves.com. People can find Luis on twitter: @lgoncalves1979

Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. Co-author of Getting Value out of Agile Retrospectives. As an advisor, coach and trainer he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He shares his experience in a bilingual blog (Dutch and English) and as an editor for Agile at InfoQ. You can find him on twitter: @BenLinders.

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our essay on user stories.  A user story is a brief, simple requirement statement from the user perspective. User stories are narratives describing who is interacting with the application; how they are interacting with the application and the benefit they derive from that interaction.

Upcoming Events

ISMA 9

I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.

More information

QAIQuest 2014

I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast

I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

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


Categories: Process Management

Why Are Requirements So Hard To Get Right?

photo (14)IT projects have been around in one form or another since the 1940’s. Looking back in the literature describing the history of IT, the topic of requirements in general and identification of requirements specifically have been top of mind since day one.  There are numerous definitions of ‘requirements,’ however at a high level requirements can be thought of as what the functionality developed by the project should ‘do’. Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.  This confluence forms a set of three constraints that are overlaid on flowing time which ensures subtle changes are continually being introduced to all of the variables.  A breakdown of process, people or environment will reduce the effectiveness of the result or render it unusable.  The factors driving the people category are typically the most volatile and a seemingly least controllable of all of the variables within the requirements process.  This essay will focus on the ‘people’ category with subsequent essays focusing on process, environment and suggestions for solutions

People have a major impact on the vagaries of requirements.  All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product. A few of the more intractable contributors to requirements variance are:

  1. Lack of experience
  2. Human nature
  3. Communication
  4. Organizational politics

We’ll discuss the first two today and deal with points 3 and 4 on Monday.

Two types of experience are the most germane to this discussion.  The first is whether participants have knowledge of the problem space from a business perspective. Without that the requirements may not practically address the project needs. Knowledge of and experience in the problem space is critical for effectiveness. One technique that has been developed to mitigate this risk is to ensure access to business knowledge through co-location with a business partner.  This kind of access is a central tenet of the most of the Agile methods. The second category is experience with the requirements process itself. Without experience gathering, recording and managing the requirements process, it will be difficult to ensure information gathered is correct and that the results developed will be apt to be more costly than necessary and less valuable than needed.  Agile methods use coaching to reinforce this knowledge and experience, while other methods use training and processes.  The goal is the same in both cases: efficiency and effectiveness.

Human nature can act as tool to focus or redirect the requirement process.  Watching several requirements gathering systems has lead me to the conclusion that there is a natural tendency for groups to jump to defining the solution before defining the need.  This can lead to a number of communication issues.  Needs provide a locus for grounding the work, which focuses the solution.  It is important to remember in the grand scheme of life needs change before the solution changes, rather than the solution changing the need (even though in exceptional cases this can be true).

There are a number of tactical solutions for all of these issues, however the first step to solving requirements issues that are people-centric begins with recognizing that a problem exists.  One best practice that I would recommend, taking a page out of the Agile handbook, is to use coaches to support the people working on gathering and managing requirements.  The role of coaches is to be the voice of the people focused inward on the team and the work.  A coach observes how work is done, provides support and instruction in a consistent and focused manner when and where it is needed.  This role is different from that of project manager which is externally focused, interacting with outside parties and clearing external roadblocks.  While people are not the only factor driving the quality of requirements, they are a critical factor.  Pay attention to how people are being deployed, provide support and instruction and make darn sure the right people are in the right place at the right time.


Categories: Process Management

Safe to Fail Experiments Are About Learning

Safe to fail experiments are about education.

Safe to fail experiments are about learning

In IT, ‘safe to fail’ describes activities that are used to generate knowledge. Additional terms that might be used are probes, spikes, R&D and prototypes. The outcome of a safe to fail experiment can be innovation, the information necessary to make decisions or to discover alternatives.  All these scenarios are appropriate for a safe to fail experiment however regardless of intent sometimes safe to fail  experiment are not safe nor are they appropriate.

Safe to fail experiments are appropriate in situations where learning is required to deliver a project. An experiment or a bit of prototyping might be needed to learn whether something is possible or if there is a more effective way to perform a repetitive task. For example, earlier in my career my team converted credit card portfolios from one provider to another. We used a standard process for most of the hard work. We were always looking for a way to make the process more efficient  using mock conversions as experiments. The goal was to find better processes and techniques.  These experiments did not always yield process changes, but they always added to our knowledge of what would and wouldn’t work. Another opportunity for safe to fail experiments is in situations where several possible alternatives exist. You need an experiment to determine which (if any) of the alternatives make sense. A test or an experiment is considered successful if it proves either that an alternative is a good choice OR if the results can be used to cross an alternative off the list. Organizations that judge results that can disqualify an alternative as a failure are apt sort out alternatives in the market place rather than before they go into production because experiments will not be safe. Finally, safe to fail experiments are useful tools in formal decision-making frameworks. For example, frameworks built to comply with the CMMI process area, Decision Analysis and Resolution (DAR), often leverage safe to fail experiments to generate data for formal, structured decision-making.

Safe to fail experiments are not always appropriate.  Many projects exist with a both fairly well understood solution and a hard deadline. In some portion of these projects the solution may not be perfectly optimal or the coolest possible solution, but it is doable in the timeframe. Experimenting to find a more optimal solution when taking the time and effort could cause you to miss the due date is not appropriate. In the credit card example mentioned earlier, we explored new ideas and optimization between projects to avoid experiments that would put the conversion at risk or cause the team to miss more of their weekend than was already necessary. Experiments that imperil the commitments a team has made or inhibits their ability to effectively deliver are not experiments and are safe to fail. Experimenting is also not appropriate where negative results are thought of as a black mark on a career. In this case straying from the tried and true approaches are generally a bad idea. This scenario tends to occur in highly politicized or overly competitive organizations. In this type of scenario if you can’t change the environment, I would suggest experimenting with other job opportunities. A third scenario is more questionable than absolutely inappropriate. In scenarios where there is little potential upside to the experiment experimentation is probably not a good idea. In most organizations, time and attention are always in short supply. Every team needs to judge what it needs to learn and ration resources that are in short supply when there is little or no perceived upside.

Safe to fail experiments are scenarios where an organization or team truly wants to sift through possible alternatives before using them in a project or in production. Safe to fail experimentation is an application of the scientific method (testing hypotheses) to generate knowledge and decisions so that teams and projects deliver more value.


Categories: Process Management

Teams Have Peak Load

photo1Peak load is an engineering concept that has found its way into software development and maintenance conversation.  In electrical engineering, it is a measure of the maximum electrical demand a system will make on the electrical grid. Software testers apply a version of this concept in stress and load testing scenarios. Peak load is by definition a spike over a specific period of time and not a sustainable level of performance. When applied to a software team, the peak load is how much additional work a team can do for a short period of time. While the principles in Agile Manifesto call for a sustainable pace, all teams know that they can call on a reserve of energy for a brief period of time to accomplish a specific goal.

In classic plan-based projects, we have all observed teams expending huge amounts of energy just prior to the overall due date or implementation. Similar patterns of behavior can sometimes be seen on sprint teams when the team is rushing to complete their committed stories as the last day of the sprint approaches.

In a normal Agile team, the average velocity (the average number story points or function points completed) is a good proxy for a stainable pace. I generally suggest that a team can occasionally increase its velocity by approximately 10 – 20% for a single sprint. For example, a team that averaged 20 function or story points might be able to commit to deliver 22 – 24 points as their peak load. In some more extreme spikes, there are frequently stories that are not completed or have quality problems.  However, this all assumes that the average velocity is really the team’s norm, rather than something they have achieved while being whipped. The problem with a team working at peak load is that sooner or later the team will have to revert to the mean, which means that it will look like the team is underperforming. If the team’s performance is graphed you will see a classic saw tooth pattern. The lack of consistency can hurt the team’s ability to deliver by first exhausting the team and them creating a scenario where they publicly underperform.

In electrical systems pushing a machine or appliance to peak load stresses the system and generates wear and tear. In the long run, this leads to breakdowns and the need for repairs. Teams are no different.  The big difference is that, given a compelling goal and then time to recover, teams can rise to a higher of performance, to a peak load, for a short period of time without have to be put in the shop for repair. The idea of pushing a team to a peak load should be used judiciously.


Categories: Process Management

Who is Responsible? You Are!

He's looking at you...

He’s looking at you…

Who is responsible for results on a sprint team? I was once asked “whose throat I should step on when the project is in trouble?” In a classic project, the answer would be the project manager (or a similar position). In an Agile project that is living up to the principles espoused in the Agile Manifesto, the answer is a bit messier and that messiness makes a command and control leader very nervous.

Agile projects using Scrum as their organization and management framework have three basic roles: product owner, scrum master and team.  If we were looking for a throat, which one would we select? The product owner owns the backlog, the budget, is charge of prioritizing the work and provides leadership. The scrum master coaches, teaches and generally facilitates the team while removing barriers to performance and provides leadership. The whole team plans the work, tackles issues and swarms to problems and individuals provide leadership when necessary. Agile teams are self-organizing and to an extent self-managing (the organization generally decides on which projects get done based on strategic plans). The whole team is involved in planning the work and, at least at situational level, everyone on the team can provide leadership. If you were to ask the members of an Agile team to point at who is in responsible, you might not have many people pointing in the same direction. Therefore is the answer that no one is responsible?

Everyone on the team is in charge.  Everyone on the team is accountable for meeting the goals that the organization sets out as interpreted by the product owner (through the backlog) and accepted by the team.  The planning activities of public acceptance and commitment to the goals and stories of the sprint creates a pressure to do what has been committed. Demonstrations act as the bookend to the public commitment with the team publicly showing how they performed against the goals they committed to attaining. If we assume that the team is empowered to attain the goals they have committed to attaining, then the team truly is responsible as a whole.

Answering that the team is responsible sounds way too squishy for some organizations. In the end, whoever controls the budget is the person that should be accountable. This suggests that the product owner should be responsible or IT management if the budget is allocated as overhead. Neither of these scenarios is conducive to empowering a self-organizing team.

Who is in charge of a typical sprint team? Every person on the team is responsible for holding each other accountable for meeting their goals. The product owner and scrum master have a direct hand in setting and facilitating the goal, therefore everyone on the team is both accountable and responsible. The layers of interlocking responsibility produce significant peer pressure. That means that every team member can truthfully say that they ARE responsible for the project.


Categories: Process Management

Function Points Are Still Relevant

Untitled

Are function points relevant in 2014? In this case, the question is whether function points are relevant to the size of an application, a development or an enhancement project. IFPUG Function Points were proposed in 1979 by Allan J. Albrecht, published in 1983 by Albrecht and Gaffney while at IBM and then updated and extended over the years. Just like using a tape measure to determine the size of the room, function points are a tool to determine the size of the application or project. In order to determine relevance we need to answer two questions:

  1. Do we still need to know “size”?
  2. Is knowing size sufficient to tell us what we need to know?

Size as a measure has many uses, but the two most often cited are as a component in parametric estimation and as a denominator in metrics such as time-to-market and productivity. While there still might be an intellectual debate on the effectiveness of estimation, there has been no reduction in the sponsors, executives, purchasing agents and the like requesting a price or an end date that you will be held accountable to meet.  Until those questions cease, estimation will be required. Parametric estimation processes (the second most popular form of estimation, after making up a number) require an estimate of size as one of the inputs.  Parametric estimation helps to avoid a number of the most common cognitive biases exhibited by IT estimators (e.g. optimism and assumption of knowledge).

Size is also used as a normalizing factor (a denominator) to compare effort (productivity), duration (time-to-market) and defects (quality). This type of quantitative analysis is used to answer questions like:

  • Is our performance improving?
  • Are the techniques being used delivering value faster?
  • Are we staffed appropriately?

Function points deliver a consistent measure of functional size based on a consistent set of rules.

The second and perhaps more critical question is whether the balance between functional requirements (things users do) and non-functional requirements (things like usability and maintainability) have changed when implemented in the current environment. If the balance has changed then perhaps measuring functional size is not relevant or perhaps not sufficient for estimation or productivity analysis.  A literature search provides no quantitative studies on whether the relationship between functional and non-functional requirements (NFRs) has changed.  Anecdotally, the new architectures, such as heavily distributed systems and software as a service, have caused an increase in the number and complexity of NFRs. However there is no credible academic evidence that a change has occurred.

It should be noted that some measurement organizations like the IFPUG have developed and begun evolving measures of non-functional size.  IFPUG has released the(SNAP) version 2.1, which measures the size of NFRs. These measures are still in the process of being incorporated into software estimation tools and are considered an augmentation to functional size measures like IFPUG Function Points or COSMIC (another form of function points).

Function points are still relevant because organizations, sponsors and purchasing agent still want to know how much a project will cost and what they will get for their money.  Organizations still want to benchmark their performance internally and externally.  Answering these kinds of questions require a standard measure of size. Until those questions stop being important, function points will be relevant.

FYI: Many times the question of relevance is really code for: “Do I have to spend my time counting function points?”  We will tackle that issue at a later date, however until then if effort is the real issue, call me and let’s discuss Quick and Early Function Points.


Categories: Process Management

NoSQL Databases Adoption Survey Results

From the Editor of Methods & Tools - Tue, 03/18/2014 - 14:20
NoSQL databases (MongoDB, Couchbase, Riak, Cassandra, etc…) are getting more and more visibility in software development discussions and conferences. The last Methods & Tools survey wanted to know if organizations were using NoSQL databases. The results are mixed. On one side, 60% of the participants answered that their organization was not using at all this technology, with 20% that are even unaware of their existence. On the other side, more than 25% of the organizations had NoSQL-based applications in production, which is not so bad for a relatively new technology largely ...

Know Exactly What Velocity Means to Your Scrum Team

Mike Cohn's Blog - Tue, 03/18/2014 - 13: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.

When talking about it informally, I define velocity as simply a measure of how fast a team is going. And for most purposes, this definition works quite well. However, it creates confusion on some of the finer points of what should count in calculating a team's velocity. This confusion comes about because there are really two more precise ways of defining velocity. Let's see what they are.

1) Velocity measures how much functionality a team delivers in a sprint.
2) Velocity measures a team's ability to turns ideas into new functionality in a sprint.

Those may sound the same. They are subtly different. To see how, suppose you hop in a river and begin swimming. After an hour, you measure how far you've traveled, and you are 2 kilometers from where you began. In agile terms, we might want to call this your velocity and say you swim 2 kilometers per hour or per sprint, if a swimming sprint is an hour long.

But, what if the river had been flowing at the rate of one kilometer per hour against you while you swam? In that case, you really swam 3 kilometers. Measured against the banks of the river, you've only moved two kilometers of physical distance. But while going forward two kilometers, you overcame being pushed backward one kilometer by the river.

So, is your velocity two or three? If we use our first definition—velocity is how much a team delivers in a sprint—then velocity is two. This swimmer delivered 2 kilometers of progress.

If we use our second definition—velocity is the ability to turn ideas into new functionality—then velocity is three. This swimmer has the ability to deliver 3 kilometers of progress per sprint, and we'd see that he was swimming in a lake with no current instead of a river.

To see how this applies to an agile project, consider the issue of whether a team should earn velocity credit for fixing bugs during a sprint. A team that uses velocity to measure how much functionality is delivered in a sprint will not claim credit for bug fixes. No new functionality has been delivered. So no points are earned.

A team using defining velocity as the ability to turn ideas into functionality, on the other hand, will claim credit for bug fixes. Their logic is that the time spent on bug fixing could have been spend adding new functionality except the product owner prioritized different work for them.

For many teams, the two definitions will yield the same value. Values will differ most for teams doing work for which they are not taking velocity credit--usually teams doing things like a lot of bug fixing or doing large amounts of refactoring.

Neither of these subtle differences in the definition of velocity is always better than the other. The one you use should largely depend on what you hope to learn by measuring it and by your expectations about the future.

If you expect the future to be just like today—that is, the team will spend the same amount of time doing bug fixing, refactoring and the like as they do now, then using velocity as a measure of how much forward progress is made will be the right answer for you.

However, if you expect the future to be different—perhaps the large refactoring and time spent fixing bugs will soon be over—then you may want to define velocity as the team's ability to turn ideas into functionality, and would then add to velocity the points given to those activities.

The most important thing is to clarify with everyone on the team, including the product owner and ScrumMaster, is exactly what your team means when they use the term “velocity.” Having a precise definition makes it very easy to answer questions that come up around what should be counted when measuring velocity.

Agile Can Contribute to an Acceleration Trap

Accelerating when you a plotting a change in direction can be a problem.

Accelerating when you a plotting a change in direction can be a problem.

I am often asked whether Agile techniques contribute to an acceleration trap in IT.  The Harvard Business Review (April 2010, Bruch and Menges,  http://hbr.org/2010/04/the-acceleration-trap/ar/pr) defines an acceleration trap as the malaise that sets in as an organization fails prey to chronic overloading. It is interpreted as laziness or recalcitrance, which then elicits even more pressure to perform generating an even deeper malaise. The results of the pressure/malaise cycle are generally a poor working atmosphere and employee loss. Agile is often perceived to induce an acceleration trap in two manners: organizational change and delivery cadence.

Implementing Agile requires substantial and sustained organizational change. Implementing Agile generally affects team structure, the work and process management and technical techniques impacting configuration management, testing and coding. Changes of these types are almost never deployed in a single big bang, but rather in waves with minor tweaks being made in-between changes based on feedback. All organizations have a different “carrying weight” when it comes to change, or the amount of change an organization can absorb before the level resistance overcomes the pressure to change. Many factors can influence the carrying weight an organization can internalize, and therefore avoid an acceleration trap.  Factors include including organizational change management programs (selling the change), level of involvement and the pressure to change.  The first two items on the list should be built into the change program. Organizational change management programs generally help make the case for change, layout the benefits of change and seek buy-in. Getting the people who are being asked to change involved in planning and implementing the change helps to combat feelings of victimization that can occur. The third category, the pressure to change, is generally a reflection of market performance. I have often observed that a good “near death experience” (organizationally speaking) significantly increases the ability of an organization to change. Change driven by desperation is not something anyone wants to live through and you are asking for trouble if you try to fake it.

The principles of the Agile Manifesto call for a sustainable pace of delivery. The pace should be set to be able to be maintained indefinitely. Organizations that use Agile to address projects with a fixed scope and set delivery dates will generally find early success as Agile accelerates early delivery of functionality.  This initial success is often followed by burn out as team cannot maintain the pace of delivery. A common pattern I have observed is that a team is able to increase its velocity for a few sprints until suddenly it encounters a sprint in which nothing seems to go correctly and average velocity is negatively impacted.  This saw tooth pattern can either be reflection of exhaustion or overstepping. Both are a sign of an acceleration trap.  A simple solution (or maybe an overly simplistic solution) is not to agree to fixed scope and fixed deadline projects. A less simple solution would include integrating the development of a minimum viable product (MVP) into all release plans for all relevant projects, so that unsustainable cadences can be avoided. The introduction of an MVP into the concept of a backlog and release plans will require educating both the Agile team including product owner and other IT stakeholders.

Agile can add to the possibility of an acceleration trap if change management is not addressed or the change to Agile is imposed on project teams. Further accepting unrealistic projects, Agile or not, can lead to all sorts of problems, including an acceleration trap. Neither of these categories of problems HAVE to create an acceleration trap, if action is taken early.  Failure to address the causes of the acceleration trap is more to blame than Agile.


Categories: Process Management

SPaMCAST 281 – Value Chain Mapping, Kim Pries The Software Sensei on Big Data

Listen to the Software Process and Measurement Cast at www.spamcast.net

Listen to the Software Process and Measurement Cast at http://www.spamcast.net

Listen to the Software Process and Measurement Cast 281. SPaMCAST 281 features our essay on value chain mapping. Value is generated through the transformation of raw materials into a new form, which is represented by a value chain. Driving effective change requires an understanding of your organization’s value chain.

Value chain mapping is a representation of how an organization transforms raw materials into a product and then delivers that product to its customers.  Value chains are developed so that the organization can get a full understanding of the process to see how they can generate the greatest possible value for the organization and the customer.  Once you understand the flow, it is far easier to improve it. Value Chain Mapping is a lean technique. Like Kanban, which focuses on the flow of work and which steps add business value, Value Chain Mapping helps to target process improvements.

Listen to the rest on SPaMCAST 281.

The SPaMCAST 281 also features Kim Pries’s column. The listeners have spoken and Kim’s column now has a name: The Software Sensie. In this edition, Kim tackles big data in his illuminating and technical style.

Here are the related value chain mapping blog entries:

Value Chain Mapping
Value Chain Mapping: Value Chain or Process Map?
Value Chain Mapping: Components
Value Chain Mapping: A Simplified Process
Value Chain Mapping: Troubleshooting
Value Chain Mapping: Creative Tension

Get in touch with us anytime or leave a comment here on the blog. Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week we will feature our interview with Ben Linders (this is Ben’s second appearance on the podcast) and Luis Gonçalves.  We discussed retrospectives and their great new book Getting Value out of Agile Retrospectives – A Toolbox of Retrospective Exercises. Retrospectives power the continuous improvement all project and organizations need to deliver more value over time.

Upcoming Events

Agile Philly March Meeting:

I am speaking at Agile Philly’s March 18th meeting on the topic of Function Points. The meeting begins at 630 PM EST – 830 in King of Prussia, PA – Details at http://www.agilephilly.com/events/function-points

ISMA 9
I will be attending the International Function Point Users Group conference and workshops in Madrid, Spain on March 27th with workshops on March 25th and 26th.
More information

QAIQuest 2014
I will be facilitating a ½ Day tutorial titled Make Integration and Acceptance Testing Truly Agile. The tutorial will wrestle with the flow of testing in Agile projects and will include lots of practical advice and exercises. Remember that Agile testing is not waterfall done quickly. I will also be around for the conference and look forward to meeting and talking with SPaMCAST readers and listeners.  More confernce information   ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

StarEast
I will be speaking at the StarEast Conference May 4th – 9th in Orlando, Florida.  I will be presenting a talk titled, The Impact of Cognitive Biases on Test and Project Teams. Follow the link for more information on StarEast. ALSO I HAVE A DISCOUNT CODE…. Email me at spamcastinfo@gmail.com or call 440.668.5717 for the code.

I look forward to seeing all SPaMCAST readers and listeners at all of these great events!

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

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

Available in English and Chinese.


Categories: Process Management