Skip to content

Feed aggregator

Move Fast, with Stability

Rally Agile Blog - 2 hours 37 min ago

By now most of you probably heard about the impending breakup of HP into two separate companies. Some have called the division of the 75-year-old business a “watershed moment for one of tech's most iconic companies,” while others have pointed out that this was an idea originally hatched years ago -- and long-overdue in its execution.

Here’s something we thought was interesting. Interviewed about the breakup, HP CEO Meg Whitman said this:

“Nimbleness and speed are going to be an important part of the future … By separating into two companies with quite distinct markets, with quite distinct customers, we’ll be able to move faster to take advantage of the changing customer needs and accelerating our product and innovation road map.”

Get to market faster. Grow faster. Respond faster to customer demand. Move faster than the competition. These days speed isn’t just a priority; it’s a necessity. When it comes to building software, improving cycle time significantly impacts your bottom line. Speed helps you monetize incremental value and get to revenue sooner. It taps the voice of the customer early and often, giving you confidence that you’re “building the right thing.”

With software eating the world, and small companies eating the lunch of large companies, you have to get to the table fast or risk not getting a seat at the table at all. Nimbleness and speed are important attributes for any company, but they’re not particularly associated with large enterprises. As Whitman points out, this doesn’t mean enterprises are exempt from the need for speed -- but they are more likely to be unprepared for it:

“The consumer space moves like lightning speed … What has been surprising is how fast the enterprise space is moving.”

Balancing Speed and Stability

The Facebook mantra of “Move fast and break things” became a famous example of how many fast-growing companies value speed over risk … until earlier this year when Facebook, now a large and public company, changed its infamous motto to “Move fast with stability.” In fact Facebook CEO Mark Zuckerberg, who once accused growing companies of moving slowly because they were more afraid of making mistakes than of missing opportunities, has lately been singing a new tune.

“Now, instead of just throwing something out there, we’re making sure that we’re getting it right first.”

Speed is at the crux of execution agility, as we discussed last week. But speed alone doesn’t equate to winning the market. Zuckerberg’s point is an important one: you don’t want to move so fast that you’re deploying bad code and incurring technical debt, or building a strategy around features no one wants. You need confidence that you’re building the right things, and building them right.

Start with Agile

If you’re not already using Agile methodologies, there’s a wealth of evidence that it’s time for you to switch. Research from an independent study found that companies using Agile bring products to market 37% faster, and see 25% higher productivity than non-Agile companies -- with no increase in defects. More research on Agile firms found that they grow revenue 37% faster, and generate 30% higher profits. Forrester says that 40% of development is now Agile, and Computer Economics estimates that 83% of businesses have future plans to implement Agile (an increase from 59% last year.)

Then Improve Your Agile Performance

If you’re already using Agile practices, then you want to focus on how to improve your Agile performance -- so you can move faster without sacrificing quality or efficiency. Agile and Lean are built on a foundation of continuous improvement: You need to inspect, learn from, and adapt your performance to keep improving. To do this, you need data on your own performance.

We recognize the value of performance improvements, which is why we’ve culled the data of 50,000 Agile teams and 160,000 projects to identify metrics across key performance dimensions like Productivity, Predictability, Quality, and Responsiveness. These metrics provide evidence-based insights for benchmarking, measuring, and adjusting your performance with real-time feedback and improvement recommendations. Our research has also uncovered some dramatic findings -- like how teams can double productivity, cut time to market in half, and improve quality by 250%. But you don’t have to take our word for it.

Here’s Michael Santoro, Director, GVS Global Business Partnership Team at Tata Communications, on the value they saw from Agile performance metrics:

“With Rally Insights, we uncovered the performance costs of unstable teams … and are seeing 30–50% improvements in both cost and delivery duration compared to similar waterfall projects.”

And here’s GE Capital Americas CIO of business intelligence, Kelly Shen, explaining why Agile trumps traditional approaches and analytics:

“Advanced analytics is best suited for this because you’re dealing with a level of ambiguity … If you go through a traditional software development cycle, you see the data for the first time after you build something. With agile, you can start seeing things as you develop the prototype -- usually days in ...The only way to know the value of analytics is to get it in front of end users as fast as possible … Fail fast, learn early, change strategy when it’s not working.”

How's your company doing on the nimbleness and speed front? Learn more about how to measure and improve your performance. Get a copy of the Business Agility Survival Guide.

Rally Software
Categories: Companies

Partnerships & Possibilities, Episode 3, Season 6

Partnerships & Possibilities: A Podcast on Leadership in Organizations
EPISODE 2: THE DIFFERENT FACES OF LEADERSHIP


Photo Credit: Victoria Nevland via Compfight cc

[introduction] How do things get done on a self-organizing team? It seems like nobody is directing the work…

[3:55] As a manager, knowing what leadership roles you need covered on a team would help to populate your teams.

[5:30] Look for T-shaped team members, and “Pi-shaped” team members, for bench strength.

[9:30] Knowing these roles could help you charter your team.

[10:10] Pioneer and Instructor roles are the early adopters of new ideas.

[11:40] Influencer and Follower roles.

[13:25] Commentator, Advocate, and Coordinator roles.

[16:35] CAUTION: All these roles are not job titles – they are roles that some or all team members may fluidly move in and out of from time to time.

[19:50] The Promoter, Mentor, and Peacemaker roles.

[23:00] The Critic, Gatekeeper, Dissenter.

[26:20] The Reviewer and the Monitor.

Shared Leadership Roles PDF

Categories: Blogs

Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method

The Agile Management Blog - VersionOne - Thu, 10/30/2014 - 20:28

There is rarely enough time or resources to do everything.  Therefore, agile teams must use prioritization to decide which features to focus on and which lowest rank-order features could be pushed out of scope when close to the end of a timeboxed sprint or release.  For agile development projects, you should linearly rank-order the backlog, rather than coarse-graining prioritization where features are lumped into a few priority buckets, such as Low, Medium, High, Critical priorities.  Linear rank ordering (i.e., 1, 2, 3, 4 ….n) avoids inflation of priority, keeps everyone honest, and forces decisions on what is really important.  It discourages the “kid-in-a-candy-shop” behavior when the business side clamors that everything is high-priority or equally important.

For agile and Scrum projects, the sprint backlog contains backlog items including stories, defects and test sets.  The scope of work for each backlog item is small enough to fit inside a typical short two- to four-week sprint.  Epics (large stories) present in a release backlog may not have been decomposed into stories during release planning; they will be decomposed during sprint planning.

The responsibility of agile prioritization is shared among all members of a team; however, the prioritization effort is led by the product owner.  Here, I will use the generic term “feature” to denote an epic or a story.  The context will make it clear if “feature” means “story” (in the context of a sprint backlog) or “epic” (in the context of a program or a portfolio, and release backlog).  Note that an epic rank order is separate from a backlog item rank order. Epics and backlog items are conceptually different, and should not be mixed or aggregated while developing a rank order.

In this blog post, I will present a simple but fairly comprehensive method to linear rank-ordering a backlog.  The method is extensible, customizable and very practical.

Let me start with a simple example.  Table 1 shows a sample backlog of five features (F1 – F5) along with each feature’s “Total Value” (Column B) and “Total Effort” (Column D).

Table 1: Sample backlog with Total Value, Total Effort,
Total ROI, and Rank Order

Table1

I will soon explain what I mean by Total Value and Total Effort.  The Total Value for features is estimated by the agile team; it is a relative number and not absolute (such as dollars).  Similarly, the Total Effort for features is estimated by the agile team; it is also a relative number, not absolute (such as ideal days or hours).  Relative numbers are easier to estimate than absolute numbers, and are adequate for agile prioritization.  The Total Value for all five features is 1,791, and the Total Effort is 14.  Percent Total Value (Column C) is calculated with simple math; for example, % Total Value of Feature F1 is (190/1791) = 10.61%.  Similarly, % Total Effort (Column E) is calculated similarly; for example, % Total Effort of Feature F3 is (3/14) = 21.43%.   Figure 1 illustrates the % Total Value and % Total Effort for each of five features, F1-F5, as two pie charts.  Note that, by definition, the full pie of either Total Value or Total Effort always represents 100% of Total Value or Total Effort.

Fig1

 

Figure 1: % Total Value and % Total Effort distribution of
five features in the sample

Column F of Table 1 calculates Total Return on Investment (TROI, a relative number) for a feature as the ratio of % Total Value of the feature (Column C) to % Total Effort of the feature (in Column E).  This is an economic model that tells us how valuable a feature is based on its TROI.  Column G of Table 1 calculates % TROI for each feature; for example, for Feature F2, its % TROI is (0.87/5.72) = 15.18%.  Column H of Table 1 shows the rank order of five features based on their % TROI data.  F4 is rank-ordered # 1, F3 as #2, F2 as #3, F5 as #4 and F1 as #5.

What is the Total Value and how do you calculate it?  

I now present a comprehensive definition of “Total Value,” yet simple to calculate and very practical to use for agile projects.  First let’s start with the notion of value of a feature to its provider (the organization developing the product or solution).  This “Provider Value” consists of parameters, such as:

  • Revenue increasing parameters: Examples of these parameters are number of new sales, increase in market share, cross-sales or upsell opportunities, etc.
  • Other benefits parameters: Examples of these parameters are alignment with the product strategy, intellectual property (patents) creation, etc.
  • Cost savings parameters: Examples of these parameters are operational cost savings, customer support cost savings, etc.

Depending on your organization’s business and product, some these parameters may or may not be applicable to you.  If you are an IT organization developing solutions for internal use, “Revenue increasing parameter” is not very applicable or may need suitable modifications.

Donald G. Reinertsen has proposed a rigorous economic framework to prioritizing value delivery (“Principles of Product Development Flow, 2009”). He points out that, “If you quantify one thing, quantify the cost of delay (CoD).”  As Dean Leffingwell has pointed out, CoD of a feature is an aggregation of three factors: User Value, Time Value and Opportunity Enablement, Risk Reduction Value (“Agile Software Requirements,” Chapter 12, pp. 266-267).

  • User Value: The potential value of a feature (expressed in relative terms) in the eyes of the users.
  • Time Value: A relative estimate based on how the User Value decays over time. Features deliver higher value when delivered early, and a lower value when delivered later by the time the feature has become commoditized.  As an example, Time Value for “Implement new UI standard with new corporate branding” may be at best modest; on the other hand, “Implement new 2014 federal tax law provisions by Dec. 31, 2014” has an extremely high Time Value prior to Dec. 31, 2014 if you are developing a tax package for tax year 2014.
  • OR Value: Opportunity Enablement, Risk Reduction Value:
    • Opportunity Enablement: Work done on a capability for one or more features may be more valuable to us depending on how it helps us exploit new opportunities. As an example, “LDAP for distributed directory information service” capability implemented with one or more features may open up new opportunities in the future.
    • Risk Reduction: Risk is anything that hasn’t happened yet, but might, and would jeopardize the success of the project. As an example, work done on “Use an alternate component to deliver required performance” for one more features may be a good risk reduction approach.

Two works done independently by Noriaki Kano and Karl Wiegers are very interesting and can help us in agile prioritization by modeling agile value.  The Kano model, illustrated in Figure 2, shows how customer satisfaction changes with absence or presence of features, and the impact of feature enhancements on customer satisfaction.

Fig2

 

Figure 2: The Kano model of customer satisfaction

  • Must-have, mandatory feature: There is low to moderate customer satisfaction for including the feature, but a high penalty for excluding it.  When this feature is present, user satisfaction remains low until a threshold is reached.  Thereafter, enhancing the feature produces a less-than-proportional reward.  The center point (the Present line in Figure 2) of this curve gives rise to the minimal marketable feature (MMF).  For a solution to be viable, it must contain some requisite set of MMFs.  However, enhancing an MMF will not produce a proportional economic return; i.e., gold plating this feature does not offer much value.  Typically, these features have either become a commodity (all competitors offer them), or they are required for some compliance or regulatory reasons.
  • Game changer, exciter, and delighter feature: This feature is unique, compelling and differentiated; even a small investment produces high customer interest and satisfaction.  There is high customer satisfaction for including the feature, but no or low penalty for excluding it.  Additional investment produces higher proportional satisfaction.  These features provide the greatest leverage for investment.  As an example, consider a car navigation device that gives accurate navigation guidance based on real-time traffic conditions, congestion, and accidents using “crowd-sourced” intelligence.
  • Linear performance feature: Investment in this feature returns proportionally higher user satisfaction; i.e., the performance is linear (see the diagonal line in Figure 2).

Note that with passage of time, ‘Game changers, exciters and delighters’ as well as linear performance features may become must-have features in a market that is intensely competitive, such as the mobile device market.  What is a game changer today (e.g., voice recognition or maps) may become a commodity feature in few years.

Karl Wiegers’ model (“First Things First: Prioritizing Requirements,” published in Software Development, September 1999) recommends an approach that is similar to the Kano model because it considers both the positive benefit of having a feature and the negative impact of its absence.

The User Value, as proposed by Reinertsen and Leffingwell, can be calculated based on the following two parameters inspired by the Kano and Wiegers models:

  1. Delighter parameter: User delightment for including the feature
  2. Penalty parameter: Penalty for excluding the feature

The information presented so far gives us a good foundation to define the Total Value.  Note that all factors or parameters in the equation below are estimated, relative numbers (not absolutes).

Total Value = Provider Value + User Value + Time Value + OR Value

Furthermore, Total Value can be based on parameter weights; i.e., it can be Weighted Total Value.   Table 2 illustrates how to combine all the above parameters into a Weighted Total Value model.

Table 2: Weighted Total Value Model

Table2

Each parameter can be assigned a Parameter Weight in the range of 0 to 10.  Weight value “0” means the parameter should not be considered (it has no weight or impact).  Weight value “1” means the parameter has the least weight (or impact), while “10” means the parameter has the most weight.  As an example, if the parameter “Increase market share” has a weight of 9, while parameter “LDAP for distributed directory information service” has a weight of 3, then the weight of “Increase market share” is three times the weight of “For distributed directory information service.”  If all parameters have the same non-zero weight (such as 3 or 8), the impact of the weight is identical and, effectively, parameters are not weighted relative to each other because they all have the same weight.

Parameter values reflect an agile team’s collective judgment or consensus based on the discussions between the product owner and the cross-functional agile team members.  Parameter value “0” means the parameter is not relevant for that feature in the row (the parameter has no importance).  Parameter value “1” means the parameter has the least importance, while “10” means the parameter has the most importance.

The Weighted Total Value for each feature is the weighted sum of products of parameter weight and parameter value.  For example, for Feature F237, the Weighted Total Value = (7*5) + (9*0) + (8*0) + (7*5) + (8*3) + (6*6) + (9*4) + (10*9) + (10*10) + (3*0) + (6*9) = 410.  The Weighted Total Value of all five features is 1,748.  Therefore, % Weighted Total Value for feature F237 is (410/1,748) = 23.46%.  Note that the Weighted Total Value for each feature is still relative.

Note that the Weighted Shorted Job First (WSJF) method used by the Scaled Agile Framework® (SAFe™) is subsumed by the TROI method proposed earlier.  WSJF captures only User Value, Time Value and OR Value.  It does not take into consideration Provider Value, an important part of the Total Value.  It neither requires nor precludes the weighted parameter model proposed in Figure 2.  It also does not specify how to calculate the User Value, and is not tied to the Kano or Wiegers model.  Thus, the Total Value model is more general than the WSJF model of SAFe.  You may choose a subset of the Total Value model to create the WSJF model, if that’s what you decide to do.

The TROI method can be subset to a very simple method of ROI = (User Value / Effort) or ROI = (Provider Value / Effort).  But it would be too simplistic to do so; ROI simply ignores the Time Value.  A higher ROI feature may be less sensitive to schedule delays than a lower ROI feature that is more sensitive; in this case, a simple ROI method will yield a wrong rank order.  So avoid using simple ROI method.  Both TROI and WSJF capture the cost of schedule delays.  As explained above, TROI subsumes WSJF.

What is the Total Effort and how do you estimate it? 

Agile teams usually take into account only development and testing effort for each feature, and estimate relative effort in story points.  I suggest that the team (consisting of cross-functional skills) takes into account not only development and testing effort, but also training (customer support staff training and customer/end-user training), delivery, deployment, operations and customer support for each feature.  Total effort needs to include not just development and testing effort, but all of the efforts listed above.  If a project is a small project of a single team that is largely stable, using story points will suffice.  Story points represent the relative estimated effort and serve as a good, reliable proxy for incurred cost or investment needed to develop, deliver, operate and support a feature.

For large projects with multiple teams (organized perhaps into programs and portfolios), story points estimated by each team must be normalized so they have the same scale and semantics; otherwise, combining story points across teams — or doing any math based on story points — does not have a well-defined meaning.  You may use the Calibrated Normalization Method to normalize story points across multiple teams of a project.  This method is applicable to backlog items as well as epics, even when epics are not broken down into stories.  Using the Calibrated Normalization Method, the estimated relative effort for all features (epics and stories) and workitems (defects, spikes, regression testing, reducing technical debt, etc.) can be expressed in a single, common currency of normalized story points, and has the same meaning across the whole enterprise.

Agile Prioritizer Template

I now provide a downloadable Agile Prioritizer template to make the math easier for calculating Total Value, Total Effort and Rank Order so you can quickly do agile prioritization in linear rank-order fashion.  The template has an instruction worksheet that shows how to customize the template for your specific needs.  You may subset the template if your needs are relatively simple.  As you fill out the Agile Prioritizer template, it will instantly provide you the rank order of features.

Product owners should treat this as their “first-cut rank order,” carefully reviewing all data calculated in white cells of the template to develop insightful understanding.  Pay close attention to what may seem surprising or unexpected.  Present and discuss this data to your agile team members.  If there is a need to change any information that you had entered in the template, go for it.  The template will immediately recalculate the rank-order information.  Final rank order should be recorded in Column D of the template by making any adjustments for dependency information recorded in Column F, and by applying your judgment.

Try to minimize dependencies among features as much as possible.  But a small number of unavoidable dependencies may remain for reasons such as:

  • System or resource constraints
  • If a specific sequence reduces the risk substantially than other possible sequence(s)
  • Business reasons
  • Reuse opportunities (design reuse, code reuse, knowledge reuse, etc.).

Any other changes in the rank order based on your judgment should be done and reflected in Column D, which indicates the final rank order of features in the backlog.  There may be other factors involved that may not neatly fit in the model of the Agile Prioritizer template, such as the latest competitive intelligence.  There is a definite role for human judgment; a good product owner or team demonstrates good judgment in producing the final rank order.

I would like to make the following key points as I wrap up this blog post:

  1. All prioritizations are local and temporal: Note that, by my definitions here, the Total Value of a feature is a global property of the feature, while Total Effort is a local property of the team implementing the feature. A feature with a lower-weighted total value may require less relative total effort from a specific team, and therefore, should be implemented ahead of another higher-weighted total value feature, if that feature requires more total effort from the team.  All priorities are inherently local.
  2. Prioritization changes as time goes on: Rank order of a backlog may need to be readjusted or recalculated at the end of a sprint, release cycle, or major event.  As features are added, deleted, revised, refined, groomed, and as more knowledge becomes available, it will be necessary to recalculate the rank order of a backlog. Game changer features may become basic-commodity, must-have features.  The Agile Prioritizer template makes the prioritization job easy.  Even the weight or parameter values may change.  And with experience, a team or an organization may decide to customize the Agile Prioritizer template differently. However, make sure that a rank order indicating linear priority does not create rigidity or reduce agility.  It should only provide guidance to the team in deciding what to focus on and what may be pushed out as the team approaches the end of the timebox.  Also, don’t prioritize too early; prioritize as needed, closer to “just in time.”
  3. Keep the TROI model simple: Although the Agile Prioritizer template is temptingly easy to extend by adding more parameters, resist that temptation.  A more elaborate model may not necessarily mean “more accurate” rank ordering.  It is adequate to pay attention to the parameters influencing the Provider Value, User Value, Time Value and OR Value as appropriate to your business and your situation.  But don’t overdo it.  You may even subset the model to match it exactly with the SAFe WSJF if you are working on SAFe projects, and need to follow the WSJF-based prioritization.
  4. Financial calculations are not required: Often business managers ask for specific financial information, such as how much expected revenue the product will generate, or expected cost savings. Those questions are much more difficult to answer, and are not essential to doing agile prioritization.  Relative Total Value and Relative Total Effort numbers are adequate and are easier to estimate as shown in this blog post.

I would love to hear from you on this topic: How do you to plan to use what you’ve learned here and the downloadable Agile Prioritizer template to better prioritize your work? Do you see a need to enhance or customize the template, and in what way?  Let me know either here, by email (Satish.Thatte@VersionOne.com), or on Twitter@smthatte.

Categories: Companies

Agile Pune, Pune, India, November 21-22 2014

Scrum Expert - Thu, 10/30/2014 - 19:18
Agile Pune 2014 is a two-day conference organized by the Agile Software Community of India (ASCI). Its goal is to bring together Agile enthusiasts from around the world to share ideas, socialize, and work together on advancing the state of Agile/Lean Software development. Workshops will be run the two days before the conference. In the agenda of Agile Pune you can find topics like “Applying Gamification Techniques in Agile”, “Agility at Scale – Platform versus Product Concerns”, “Skype Goes Agile: Don’t Repeat our Mistakes”, “To Deploy or Not-to-Deploy – Decide Using ...
Categories: Communities

JetBrains Launches YouTrack 6

Scrum Expert - Thu, 10/30/2014 - 18:47
JetBrains has announced the availability of YouTrack 6, the new major release of their comprehensive issue tracking and project management tool. YouTrack has gained widespread popularity among development teams and companies thanks to its no-nonsense, IDE-style approach to issue tracking. With powerful customization possibilities, effective time management, agile project management capabilities that support Scrum and Kanban workflows, and support for multiple languages, YouTrack is ready to support any business process. Following a period of organic growth from issue tracking to project management, YouTrack 6 can satisfy the tracking, reporting and analysis needs ...
Categories: Communities

Kanban Coaching Masterclasses in 2015

David J. Anderson & Associates - Thu, 10/30/2014 - 18:11

We've listed only 1 public Kanban Coaching Masterclass for 2015 in San Diego in January on the week of the 19th. So far we have 11 out of 12 places subscribed and one client expects to fill that final place. We will be listing a 2nd spillover class also in January for the week of 12th January. This should be posted by end of next week. If you are interested in attending a 2015 masterclass please follow the sales link at the bottom of this page. We do not plan to list any more public masterclasses in 2015.

read more

Categories: Companies

Things Product Managers Should Know About Being a Product Owner

Scrum Expert - Thu, 10/30/2014 - 17:37
The product owner is one of the three roles of the Scrum framework for Agile project management. The product owner is responsible for defining and prioritizing the backlog and to convey the product vision to the Scrum team. Some people have compared this role to the traditional product manager position, but the context is different.In her blog post, Ellen Gottesdiener shares nine things that every product manager should know about being an Agile product owner. These nine hints for the new product owner are: 1. Put the Ends before the Means. 2. Share ...
Categories: Communities

Agile Singapore Conference, Singapore, November 12-14 2014

Scrum Expert - Thu, 10/30/2014 - 17:00
The Agile Singapore Conference is a three-day event focused on all aspects of agile software development and Scrum. It is an occasion to learn, interact and network with Agile practitioners from South East Asia and worldwide Agile experts. In the agenda of Agile Singapore Conference you can find topics like “The Power of an Agile mindset”, “Introduction to Large-Scale Scrum (LeSS)”, “Building an Agile Government”, “Applying Agile Development Practices in Distributed Teams”, “You Can’t be Great without Technical Excellence”, “User-Centered Agile Product Development in an Enterprise and a Startup”, “Worse Is ...
Categories: Communities

Set your Mind on Experimentation Mode

Rally Agile Blog - Thu, 10/30/2014 - 14:00

Recently Michael “Doc” Norton, Global Director of Engineering Culture at Groupon, gave an opening keynote at SDEC 2014 in Winnipeg, Canada. He addressed the mixed crowd of software development practitioners, talking about Experimentation Mindset. SDEC is considered one of the forward-thinking conferences on Agile Development; as the organizers state: “(it) attracts leading agile practitioners from around North America to share their real-world experiences gained through delivering technology-related solutions”. This keynote, therefore, was targeted to forward-thinking software development practitioners ready to embrace hot new ideas in Agile.

The Experimentation Mindset could be described as approaching all our assumptions about product, customer, or quality as a hypothesis not a stated fact, and designing experiments to test whether the hypothesis holds true. The experiments are proving assumptions, and, as a rule, failures are both expected and acceptable. The team or company, that permits and encourages their people to experiment and grow, is boosting exploration of ideas that may reside in uncharted territory.

Experimentation is a scientific approach that leads to innovation and breakthrough; it invites risk and encourages teams to work outside of their comfort zone. Experimentation goes hand-in-hand with flexibility. When moving in one direction results in a dead end, such a mindset allows to quickly adjust and change course quickly, nimbly, and efficiently.

Experimentation Mindset is a distinct characteristic of skilled software testers. Forming hypotheses and using experiments to validate assumptions is a method used by skilled testers in exploring software for issues. James Bach, the expert software tester and world renowned testing teacher, provides the following methods in Exploration Skills and Tactics (“Exploratory Testing Dynamics”, created by James Bach, Jonathan Bach, and Michael Bolton): 

  • Conceiving and describing your conjectures. Considering possibilities and probabilities. Considering multiple, incompatible explanations that account for the same facts. Inference to the best explanation.
  • Constructing experiments to refute your conjectures. As you develop ideas about what’s going on, creating and performing tests designed to disconfirm those beliefs, rather than repeating the tests that merely confirm them.
  • Making comparisons. Studying things in the world with the goal of identifying and evaluating relevant differences and similarities between them.
  • Observing what is there. Gathering empirical data about the object of your study; collecting different kinds of data, or data about different aspects of the object; establishing procedures for rigorous observations.
  • Noticing what is missing. Combining your observations with your models to notice the significant absence of an object, attribute, or pattern.

Experimentation Mindset fits best with Agile teams and organizations, where the process framework itself supports frequent feedback loops through short iterations followed by retrospectives. Applying Experimentation Mindset requires discipline, most notably mental discipline and an open, unbiased mind. It also requires courage – to accept the failures not as impediments that teams try to either ignore or get rid of, but as an important part of the journey. 

Approaching product delivery with the Experimentation Mindset might be the shortest road to success and innovation, achieved with scientific accuracy and supported by empirical evidence. As such, it’s a worthwhile approach to try.

Hear Anna Speak at Rally!

Join us November 5 at Rally's Denver offices.

Who: Anna Royzman, international speaker, thought leader in quality and testing What: "Context-Driven-Testing and the Changing Role of the Tester in High-Performing Teams" Where: Rally Software, Denver Office Auditorium, 1550 Wynkoop Street When: Wednesday, November 5, 6:00 PM  What else: Pizza and beer will be served Anna Royzman
Categories: Companies

Set your Mind on "Experimentation Mode"

Rally Agile Blog - Thu, 10/30/2014 - 14:00

Recently Michael “Doc” Norton, Global Director of Engineering Culture at Groupon, gave an opening keynote at SDEC 2014 in Winnipeg, Canada. He addressed the mixed crowd of software development practitioners, talking about Experimentation Mindset. SDEC is considered one of the forward-thinking conferences on Agile Development; as the organizers state: “(it) attracts leading agile practitioners from around North America to share their real-world experiences gained through delivering technology-related solutions”. This keynote, therefore, was targeted to forward-thinking software development practitioners ready to embrace hot new ideas in Agile.

The Experimentation Mindset could be described as approaching all our assumptions about product, customer, or quality as a hypothesis not a stated fact, and designing experiments to test whether the hypothesis holds true. The experiments are proving assumptions, and, as a rule, failures are both expected and acceptable. The team or company, that permits and encourages their people to experiment and grow, is boosting exploration of ideas that may reside in uncharted territory.

Experimentation is a scientific approach that leads to innovation and breakthrough; it invites risk and encourages teams to work outside of their comfort zone. Experimentation goes hand-in-hand with flexibility. When moving in one direction results in a dead end, such a mindset allows to quickly adjust and change course quickly, nimbly, and efficiently.

Experimentation Mindset is a distinct characteristic of skilled software testers. Forming hypotheses and using experiments to validate assumptions is a method used by skilled testers in exploring software for issues. James Bach, the expert software tester and world renowned testing teacher, provides the following methods in Exploration Skills and Tactics (“Exploratory Testing Dynamics”, created by James Bach, Jonathan Bach, and Michael Bolton): 

  • Conceiving and describing your conjectures. Considering possibilities and probabilities. Considering multiple, incompatible explanations that account for the same facts. Inference to the best explanation.
  • Constructing experiments to refute your conjectures. As you develop ideas about what’s going on, creating and performing tests designed to disconfirm those beliefs, rather than repeating the tests that merely confirm them.
  • Making comparisons. Studying things in the world with the goal of identifying and evaluating relevant differences and similarities between them.
  • Observing what is there. Gathering empirical data about the object of your study; collecting different kinds of data, or data about different aspects of the object; establishing procedures for rigorous observations.
  • Noticing what is missing. Combining your observations with your models to notice the significant absence of an object, attribute, or pattern.

Experimentation Mindset fits best with Agile teams and organizations, where the process framework itself supports frequent feedback loops through short iterations followed by retrospectives. Applying Experimentation Mindset requires discipline, most notably mental discipline and an open, unbiased mind. It also requires courage – to accept the failures not as impediments that teams try to either ignore or get rid of, but as an important part of the journey. 

Approaching product delivery with the Experimentation Mindset might be the shortest road to success and innovation, achieved with scientific accuracy and supported by empirical evidence. As such, it’s a worthwhile approach to try.

Hear Anna Speak at Rally!

Join us November 5 at Rally's Denver offices.

Who: Anna Royzman, international speaker, thought leader in quality and testing What: "Context-Driven-Testing and the Changing Role of the Tester in High-Performing Teams" Where: Rally Software, Denver Office Auditorium, 1550 Wynkoop Street When: Wednesday, November 5, 6:00 PM  What else: Pizza and beer will be served Anna Royzman
Categories: Companies

Agile Smells Versus Agile Zombies in the Uncanny Valley

Leading Agile - Thu, 10/30/2014 - 07:00
Code Smell

A code smell is a hint that something may have gone wrong somewhere in your source code. Martin Fowler included the term smell in his book Refactoring way back in 2000, referring to something that may not be right. Just because something smells, it does not mean there is a problem; it does mean, however, that there should be further investigation.

Agile Smell

Similar to a code smell, Agile smell is a hint that something may have gone wrong somewhere in your Agile practices.  Be it a variation in the length of iterations, volatility in velocity, or having teams where the ScrumMaster is also the Product Owner, these smells are out there with every client I’ve met.  The thing is, the further you get from textbook Scrum, the harder it becomes to sniff out potential problems.

Uncanny Valley

I don’t like to use the term smell. I prefer to say that you’re in “the valley”.  I’m referring to the uncanny valley.  When something looks and moves almost, but not exactly, like a healthy person, it causes a response of revulsion among some observers. The “valley” refers to the dip in a graph (see below) of the comfort level of observers. Ever watch Polar Express?  Though it is a kids movie, it creeps the hell out of me and it makes me feel really uneasy. The characters look pretty real but their movement is just a little off and their eyes look dead.  That uneasiness I feel is the uncanny valley.  To that, I believe there is an Agile uncanny valley and it’s full of Agile zombies.

uncanny valley

Agile Zombie

Potential problems with Agile practices are out there but many people are oblivious to them.   I’ve seen customers rely on people who have  certifications but no experience. I’ve seen customers rely on trainers or salesmen, who talk about ideal situations in a conceptual world.  This is off-putting to me and I label that persona the Agile zombie.  It’s like the Polar Express all over again.  To smell problems at scale, you need coaches or consultants who have been dropped into multiple situations and have the tools and techniques to get a read on things lickedy split.  This is one reason we do assessments.  We need to know where you are.  We may find you are doing a great job.  We may also find you are deep in the valley.

Uncanny Agile Valley

People do or say things that sound benign on the surface but when you ask them why a few times, you realize something isn’t quite right.  Do you conduct ceremonies or follow a governance but don’t know why? You may be in the valley.  Do you hyperfocus on metrics without considering how they could negatively impact the behaviour of your teams or why you’re collecting the data? You may be in the valley.  Do you structure your teams without thoughts of dependencies or scaling? You may be in the valley.  Do you evangelize practices but don’t know if they are appropriate, based on organizational goals?  That’s right, you may be in the valley.

Are you in the valley?

The post Agile Smells Versus Agile Zombies in the Uncanny Valley appeared first on LeadingAgile.

Categories: Blogs

What is DevOps, Anyway?

The Agile Management Blog - VersionOne - Wed, 10/29/2014 - 20:04

We just got done moderating the latest webinar in the AgileLIVE series… “The Challenges and Rewards of DevOps.” The series started last week with Damon Poole, chief agilist at Eliassen Group. Damon did a really good deep-dive into What is DevOps? and we wrapped up today in Part 2 with Andy Powell and Ian Culling of VersionOne.

Here are some of the comments in my notes:

  • DevOps is inextricably linked to Continuous Deployment/Delivery/Everything.
  • DevOps automates and accelerates the build-test-deploy infrastructure.
  • DevOps reinforces that “working software in customers’ hands is the measure of DONE, not features that made it into the release.”
  • DevOps is a goal. You can’t just leap into it. It requires trust, people working closely together.
  • Ops often hears: “’Those dev cowboys’ want to deploy every minute of every day.” Ops is here to make sure nothing breaks in production. DevOps aligns ‘em.
  • For DevOps to work, it is critical to have really good collaboration and trust between development and operations teams.

But the most interesting comment I heard came over the Q&A panel from an attendee:

“Is DevOps infecting Dev people with Ops thinking, or is it the other way around?”

What do you think? Whether you are already rolling with DevOps at your organization, or just trying to learn  what is DevOps… we’d like to hear your opinions.  If you want a copy of the recordings for AgileLIVE: The Challenges and Rewards of DevOps, simply post a comment here and we’ll send them.

Categories: Companies

Reflections on Design Patterns After Two Decades

NetObjectives - Wed, 10/29/2014 - 19:08
On the 20th Anniversary of Design Patterns, the InformIT editorial team decided to ask several patterns gurus for their reflection on patterns over the last two decades.  You can see the entire article here. Here's Jim Trott and my post - Design Patterns in an Agile World After two decades of use, design patterns are as misunderstood as they were when they were first introduced. They are...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Tyranny of the Ever Decreasing Timebox

David J. Anderson & Associates - Tue, 10/28/2014 - 23:48

Agile software development methods, with the exception of Feature-Driven Development, adopt the use of fixed time increments, often wrongly called “iterations”. In Scrum, these are known as Sprints. A Sprint is a fixed period of time with a defined scope and a commitment to complete that scope within that time window. Originally, Scrum defined 4 week sprints. This was changed later, circa 2004, to a recommendation for 2 weeks to be the default length for a sprint. In general it is recognized that agility is related to the frequency of interaction with the customers or business owners, and the frequency of deliveries. Hence, smaller timeboxes are more desirable. Software quality is often related to batch size and time to complete work in a non-linear fashion, hence, smaller batches, completed in short periods of time leads to dramatically fewer defects.

As a result of all these advantages, organizations adopting Agile software development methods, have been under pressure to adopt the use of shorter and shorter timeboxes for their sprints or iterations. On the face of it, smaller timeboxes and hence smaller batch sizes for the sprint backlog, are a good thing. However, smaller timeboxes create two types of pressure that are often difficult to cope with and adjust to: firstly, smaller batches require an ever more detailed approach to requirements analysis and development – the need to write every more fine-grained stories which can be completed within the smaller time window; and the need for an ever more accurate approach to estimation, so that a realistic commitment can made.

read more

Categories: Companies

Five Tips for Tactical Management

Johanna Rothman - Tue, 10/28/2014 - 19:15

Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:

  1. Schedule and conduct your one-on-ones. Being a manager means you make room for  the people stuff: the one-on-ones, the coaching and feedback or the meta-coaching or the meta-feedback that you offer in the one-on-ones. Those actions are tactical and if you don’t do them, they become strategic.
  2. As a manager, make sure you have team meetings. No, not serial status meetings. Never those. Problem solving meetings, please. The more managers you manage, the more critical this step is. If you miss these meetings, people notice. They wonder what’s wrong with you and they make up stories. While the stories might be interesting, you do not want people making stories up about what is wrong with you or your management, do you?
  3. Stop multitasking and delegate. Your people are way more capable than you think they are. Stop trying to do it all. Stop trying to do technical work if you are a manager. Take pride in your management work and do the management work.
  4. Stop estimating on behalf of your people. This is especially true for agile teams. If you don’t like the estimate, ask them why they think it will take that long, and then work with them on removing obstacles.
  5. If you have leftover time, it’s time to work on the strategic work. What is the most important work you and your team can do? What is your number one project? What work should you not be doing?  This is project portfolio management. You might find it difficult to make these decisions. But the more you make these decisions, the better it is for you and your group.

Okay, there are your five tips. Happy management.

Categories: Blogs

VersionOne Announced its 2014 Fall Release

Scrum Expert - Tue, 10/28/2014 - 18:46
VersionOne has announced its 2014 Fall Release which includes native CA PPM integration, advanced project forecasting through Monte Carlo simulation, and portfolio-level reporting with SAFe 3.0. These new capabilities make scaling easier by aligning agile and traditional project teams under a single vision. The new VersionOne capabilities help portfolio managers easily visualize and manage feature-level agile project activity in the context of enterprise business plans: * CA PPM VersionOne native integration: A partnership with CA Technologies delivers an integrated solution that synchronizes agile ALM and PPM to provide a complete picture of ...
Categories: Communities

Toronto Agile & Software, Toronto, Canada, November 10 2014

Scrum Expert - Tue, 10/28/2014 - 18:36
Toronto Agile & Software is a one-day conference focused on Agile software development that takes place in Toronto, Canada. You will gain key insights and learning on the practical implementation of Agile methodologies within companies. Practitioners will find out about the latest developments, tools and methodologies. In the agenda of Toronto Agile & Software you can find topics like “Principle-Centered Agility: Your Path to Better Options”, “Implementing Agile Development in an Enterprise Environment”, “Creating Alignment for Agile Change”, “Agile Architecture and Modeling – Where are we Today?”, “Scrum and Kanban – ...
Categories: Communities

Role of a Project Manager in Scrum

DFW Scrum User Group - Tue, 10/28/2014 - 18:23
We had a great turnout at DFW Scrum last TUE for “The Role of the Project Manager in Scrum”. Many organizations struggle with what to do with the Project Manager when they have a Scrum Team. Chris Eberhardt and myself … Continue reading →
Categories: Communities

Purpose, not Features

NetObjectives - Tue, 10/28/2014 - 12:51
I keep hearing people ask about how to improve agile requirements. I agree that mere decomposition of epics into features into stories into right sized stories into tasks is not enough. In fact, it misses the point. In fact, most of the time customers don't know what they want. Henry Ford said - "If I had asked people what they wanted they would have said 'faster horses'".  So how can we find out...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Agile Assessments – A Deeper Dive

Leading Agile - Tue, 10/28/2014 - 12:50

In my previous post Agile Assessments, I wrote about reasons to do an assessment and considerations when doing one.  In this post, I’ll continue the assessment topic with focus on Rating Scales and Frequency.

Select a Rating Scale

When conducting an agile assessment or self-assessment, an understandable rating scale should be used that allows the rater to assign a value to the practice or capability being rated.

Using Numbers

A Scale of 1 to n is so common it has become part of our vocabulary and for good reason:  It’s easy to understand and very straightforward.

Including a qualitative description of each number in the scale will improve the usefulness of the rating scale. For example, if a rating of 2 is described as “Apprentice” or “Beginner”, the category is more likely to mean the same thing to different people. And if we expand the definition further, the raters are even more likely to apply the rating similarly.  Let’s look at this further in the following example:

Numeric Only Numeric + Minor Qualification Numeric + Detailed Qualification 0 0 – Not started 0 – Not started – The practice/capability is not yet understood and/or is not yet in use by the team 1 1 – Apprentice 1 – Apprentice – Beginning to learn and apply practice/capability. Guidance from experts is recommended. 2 2 – Journeyman 2 – Journeyman – Practice/capability is well understood and is sustainable by the team. 3 3 – Expert 3 – Expert – Practice/capability is fully internalized. Team can teach and mentor others.

Each level of qualification brings more clarification and shared understanding of the numeric rating.  Keep this in mind when you select a scale and include a description for each that will help the raters apply the scale with some degree of consistency.  Consistency in the interpretation of the rating scale will be important to a team as they continue to self-assess periodically.  It is also important for the organization when measuring progress across teams to get an overall view of an agile transformation.

Using Colors and Symbols

Graphic/visual representations, in addition to or instead of a numeric scale, can bring life to the assessment process and quick interpretation of the assessment results, particularly if you have an open work space to display them.  Standard traffic light colors, plus black, offer a simple translation:

◉ Black – Not Started
◉ Red – Practice/capability has started but needs significant improvement
◉ Yellow – We are practicing the competency consistently
◉ Green – Team has fully embraced practice/capability and internalized it into culture

You often see the use of four/five stars in online ratings of movies, books and restaurants and we all understand that a ‘5 star hotel’ is very luxurious and comes with many amenities.  Our assessment star rating scale would look something like this:

★★★★★ – Not started
★★★★★ – Just beginning use of practice/capability
★★★★★ – Practice/capability is understood but not used consistently
★★★★★ – Practice/capability is used most of the time
★★★★★ – Demonstrable evidence practice/capability has been mastered
★★★★★ – Teaching and mentoring others on practice/capability

Like the traffic light colors, it’s a visual rating that we’re used to seeing and doesn’t require a lot of thought to interpret.  The stars really do represent numbers though and you can choose to use them mathematically and roll up scores to a major category level or overall assessment score.

My preference when conducting an assessment for an organization where I am the rater is to use a numeric scale that includes a clear and detailed qualitative description.  This helps me take more time to consider the criteria and the circumstances.  When guiding a team on their self-assessment, I’ve observed that the use of the graphic/visual format takes away the reluctance some individuals have when choosing a number, allows the process to go faster and achieves a result closer to reality.  Personally, I find that I can over think numbers but don’t second guess so much when selecting the color Yellow or 4 Stars.  You may not find this true if you’re not a visual thinker.

How Often Should You Reassess?

If you look back at some of the reasons to do an assessment from my Agile Assessments post, many of them set the expectation that it’s a recurring activity.  A few from the list include: “Establish Baseline”, “See how you’re tracking against your transformation goals”, and “Determine if you’re ready to move to next level”.  While ideally you’re already using metrics to improve your processes in general, an agile assessment or assessment instrument has a more specific purpose and lifespan in support of an agile transformation.   Once a team and/or organization reaches a greater level of maturity in their adoption and agile becomes ’the way you build software”, the assessment instrument will largely cease to provide value.  It doesn’t mean you stop continuously improving but we have the retrospective for that.

The frequency of the assessment should take into consideration the rate of change you’re expecting between assessments. For example, if I assess a new team, send them to training and leave them mostly alone to figure it out, I’m not going to anticipate a great deal of improvement in the next 30 days and therefore, I may wait a couple months to re-assess.  Contrast that with a team who is given training, has a scrum master or other leader on the team with agile experience, and they also have continued and focused coaching.  I would expect to see change in a months time and will want to have visibility to the progress via the assessment results.  Every few sprints is a good, general guideline when you’re getting started.  Once you set the interval, stick to it.

Most important to me is that someone is using the assessment results for a clear purpose.  I’ve seen teams complete their self-assessment on a regular cadence because the organization required them to but do absolutely nothing with it.  I know the company was truly interested in understanding how their transformation was progressing and to know where support was needed for the team but the assessment results weren’t being used to understand progress or areas for improvement.  If the results aren’t being used or understood, it might be time to step back and re-evaluate.

On to Methods and Results

You can look forward to my next post where I’ll share a few different approaches for administering an assessment and how to report your results.

The post Agile Assessments – A Deeper Dive appeared first on LeadingAgile.

Categories: Blogs

Scrum Knowledge Sharing

SpiraPlan is a agile project management system designed specifically for methodologies such as scrum, XP and Kanban.