Skip to content

Feed aggregator

Move Fast, with Stability

Rally Agile Blog - Fri, 10/31/2014 - 14:00

By now, you've probably heard about the impending breakup of HP into two separate companies. Some are calling the division of the 75-year-old business a “watershed moment for one of tech's most iconic companies."

Here’s something we thought was worth calling out: 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 larger 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%. We think the data make a pretty compelling case, but maybe you'd rather take someone else's 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

Partnership & Possibilities - Diana Larsen - Fri, 10/31/2014 - 13:51

Partnerships & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: 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

hdiutil: could not access / create failed – Operation canceled

Mark Needham - Fri, 10/31/2014 - 11:45

Earlier in the year I wrote a blog post showing how to build a Mac OS X DMG file for a Java application and I recently revisited this script to update it to a new version and ran into a frustrating error message.

I tried to run the following command to create a new DMG file from a source folder…

$ hdiutil create -volname "DemoBench" -size 100m -srcfolder dmg/ -ov -format UDZO pack.temp.dmg

…but was met with the following error message:

...could not access /Volumes/DemoBench/DemoBench.app/Contents/Resources/app/database-agent.jar - Operation canceled
 
hdiutil: create failed - Operation canceled

I was initially a bit stumped and thought maybe the flags to hdiutil had changed but a quick look at the man page suggested that wasn’t the issue.

I decided to go back to my pre command line approach for creating a DMG – DiskUtility – and see if I could create it that way. This helped reveal the actual problem:

2014 10 31 09 42 20

I increased the volume size to 150 MB…

$ hdiutil create -volname "DemoBench" -size 100m -srcfolder dmg/ -ov -format UDZO pack.temp.dmg

and all was well:

....................................................................................................
..........................................................................
created: /Users/markneedham/projects/neo-technology/quality-tasks/park-bench/database-agent-desktop/target/pack.temp.dmg

And this post will serve as documentation to stop it catching me out next time!

Categories: Blogs

The Agile Reader – Weekend Edition: 10/31/2014

Scrumology.com - Kane Mar - Fri, 10/31/2014 - 08:26

You can get the Weekend Edition delivered directly to you via email by signing up http://eepurl.com/0ifWn.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: What Software Project Benchmarking and Estimating Can Learn from Dr. Seuss #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • RT @BlancheSabb: [CDP] Connaissez-vous la différence entre #ScrumMaster dédié & #ScrumMaster intégré ? #agile http:/…
  • ☆★☆ JOB ALERT ☆★☆ #Job #Atlanta – Scrum Master / Agile Coach view full details
  • ☆★☆ JOB ALERT ☆★☆ #Job #Auburn Hills – Agile PM/Scrum Master view full details
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agile #scrum
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • Dot Net Technical Lead / C# Software Developers (Agile/Scrum) (Colombo 01) http://t.co/NgAw2wU017
  • RT @MasterScrum: What Does QA do on the First Day of a Sprint? #agile #scrum http://t.co/180ciIpkkt
  • RT @MasterScrum: User Acceptance Testing in #Scrum #Agile
    The transparency and customer collaboration that… http:…
  • RT @yochum: IT Development Project Manager – E-Commerce, SaaS, Scrum Master: Minimum Required Skills: E-Comm… #agi…
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • #jobs4u #jobs Agile Project Manager with Banking experience and Scrum Certified, [Chicago, #IL] #banking
  • RT @jobz4banking: #jobs4u #jobs Agile Project Manager with Banking experience and Scrum Certified, [Chicago, #IL] #b…
  • RT @yochum: Agile Prioritization: A Comprehensive and Customizable, Yet Simple and Practical Method #agile #scrum
  • ☆★☆ JOB ALERT ☆★☆ #Job #Atlanta – Scrum Master / Agile Coach view full details
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • RT @cgougler: RT @iovation: #Scrum Stories. Lessons from an #agiledevelopment Development Luminary @rlunde @TotherAl…
  • Agile Canada » Project Manager / Agile Scrum Manager at Recruitment Rocket (Halifax, NS):… #Canada #Agile #Jobs
  • RT @cgougler: RT @iovation: #Scrum Stories. Lessons from an #agiledevelopment Development Luminary @rlunde @TotherAl…
  • “Scrum cannot work w/o XP” ~ @jbrains on the Fundamental Theorem Of Agile Software Development h/t @YvesHanoulle
  • RT @dfkaye: “Scrum cannot work w/o XP” ~ @jbrains on the Fundamental Theorem Of Agile Software Development h/t @Yves…
  • #new_comment on ‘Training and retaining the basics of ..’ #AgileIndia2015 @ConfEngine. Your feedback?
  • #Agile – What does Self-Organizing team mean? – http://t.co/IyaiqR2ZZm
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • Agile Canada » Project Manager / Agile Scrum Manager at Recruitment Rocket (Halifax, NS):… #Canada #Agile #Jobs
  • A #scrum master is a member of the scrum team – not its boss. #agile ^ @ryanripley
  • RT @andyhammar: Awesome #scrum #agile graphic from @henrikkniberg talk, dont go overboard with agile! http://t.co/t1…
  • What does the Scrum Master actually do in agile projects? – http://t.co/GkYERi0wzl
  • Categories: Blogs

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

    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

    Another example of Object Theater

    Matteo Vaccari - Thu, 10/30/2014 - 19:37
    Mastermind

    This year I gave my Web Applications students the task of writing a Mastermind game. You can see some of their work here, here and here. The game works like this: the computer starts a new game by inventing a random secret code, composed of 4 digits from 1 to 6. For instance: 5414.

    The player must deduce what is the secret code by trying guesses. To continue the example if my first guess is 1234, the computer will answer “-+” which means that I got one number right (+) and another number is present in the secret code but in a different position (-). Of course, I don’t know which! I can then try more guesses, until I have enough clues to guess right.

    You get a score for each completed game, that is equal to the number of guesses. Of course, the lower the score, the better.

    A player will earn a score that is the average of all the games he or she completed.

    Procedural!

    Teaching Object-Oriented programming was not one of the goals of the course. Therefore, most programs I got were very procedural. (Please note that the example that follows is from a good student and his work earned a very high score in my course. It was a good web application, even though it was not object-oriented).

    I’d like to show an example of procedural code. This is a controller object that handles a “guess”.

    public void guess() throws IOException {
      String gameId = request.getParameter("game_id");
      String code = gamesRepository.findSecretCode(gameId);
      String guess = request.getParameter("guess");
      String answer = compareCodes(code, guess);
      String player = gamesRepository.find_game_player(gameId);
      guessesRepository.createGuess(gameId, player, guess, answer);
      gamesRepository.incrementGameScore(gameId);
    
      // if game is won
      if(answer.equals("++++")){
        gamesRepository.setFinished(request.getParameter("game_id"));
        int oldScore = gamesRepository.getPlayerScore(player);
        playersRepository.addFinishedGame(player, oldScore);
      }
    
      // return json data
      response.getWriter().write(toJson("answer", answer));
    }
    

    This is classic procedural code; the game logic is found in the controller (method compareCodes()) and the repositories (three repositories!). There are no domain objects.

    The database structure is something like

           1      *      1      *
    player -------- game -------- guesses
    

    The gameRepository adds a row to the games table when a new game is added. The guessesRepository adds a row to the guesses table when a new guess is guessed. The controller must take care to call the proper repositories at the right time. The controller “knows” the database structure; if the database structure changes, the controller code will probably also change.

    Object-Oriented

    What I’d like to do instead is

    • Domain objects that handle all the game logic
    • No logic in the repositories or the controller
    • Just one repository is enough, thank you. The repository should take care of adding rows to the proper tables.

    The domain object should probably be the MasterMind game.

    game.guess(request.getParameter("guess"));
    

    The “guess” message is what sets the domain logic in motion. The controller should not need to know anything else.

    Q. What if the game is won? Who updates the player’s score?

    A. The game object should do that.

    Q. Where do we see that the game updates the player’s score?

    A. Not in the controller. The controller does not know or care. Handling victories is something that is done in the game object.

    Q. Really! How do we update the player’s score?

    A. The game probably knows its player, and tells it to update its score if the game is won.

    Q. How does the game get a reference to its player?

    A. The controller does not know. But see next question.

    Q. Where do we get the game object from?

    A. From a repository, of course. We suppose that the repository will return it with all the dependencies that it needs to have. If the game needs a reference to its player, the repository must take care to set it up.

    String gameId = request.getParameter("game_id");
    Game game = gamesRepository.findGame(gameId);
    
    game.guess(request.getParameter("guess"));
    

    Q. How is the state of the game persisted?

    A. By asking the repository to save the game.

    // Here we are in the infrastructure world
    String gameId = request.getParameter("game_id");
    Game game = gamesRepository.findGame(gameId);
    
    // Now we pass to the realm of pure domain logic
    game.guess(request.getParameter("guess"));
    
    // And now we return to the infrastructure world
    gamesRepository.save(game);
    response.getWriter().writer(toJson(game));
    

    So we have seen another example of object theater. The infrastructure details are dealt with before and after the main action. The main action is sending “guess” to the game object. There is where the functional requirements is dealt with. Before that, and after that, is infrastructure code that deals with non-functional, performance requirements.

    Categories: Blogs

    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

    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

    Driving Business Transformation by Reenvisioning Your Customer Experience

    J.D. Meier's Blog - Thu, 10/30/2014 - 18:03

    You probably hear a lot about the Mega-Trends (Cloud, Mobile, Social, and Big Data), or the Nexus of Forces (the convergence of social, mobility, cloud and data insights patterns that drive new business scenarios), or the Mega-Trend of Mega-Trends (Internet of Things).

    And you are probably hearing a lot about digital transformation and maybe even about the rise of the CDO (Chief Digital Officer.)

    All of this digital transformation is about creating business change, driving business outcomes, and driving better business results.

    But how do you create your digital vision and strategy?   And, where do you start?

    In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned from companies that are digital masters that created their digital visions and are driving business change.

    3 Perspectives of Digital Vision

    When it comes to creating your digital vision, you can focus on reenvisioning the customer experience, the operational processes, or your business model.

    Via Leading Digital:

    “Where should you focus your digital vision? Digital visions usually take one of three perspectives: reenvisioning the customer experience, reenvisioning operational processes, or combining the previous two approaches to reenvision business models.  The approach you take should reflect your organization’s capabilities, your customer’s needs, and the nature of competition in your industry.”

    Start with Your Customer Experience

    One of the best places to start is with your customer experience.  After all, a business exists to create a customer.  And the success of the business is how well it creates value and serves the needs of the customer.

    Via Leading Digital:

    “Many organizations start by reenvisioning the way they interact with customers.  They want to make themselves easier to work with, and they want to be smarter in how they sell to (and serve) customers.  Companies start from different places when reenvisioning the customer experience.”

    Transform the Relationship

    You can use the waves of technologies (Cloud, Mobile, Social, Data Insights, and Internet of Things), to transform how you interact with your customers and how they experience your people, your products, and your services.

    Via Leading Digital:

    “Some companies aim to transform their relationships with their customers.  Adam Bortman, chief digital officer of Starbucks, shared this vision: 'Digital has to help more partners and help the company be the way we can ... tell our story, build our brand, and have a relationship with our customers.' Burberry's CEO Angela Ahredts focused on multichannel coherence. 'We had a vision, and the vision was to be the first company who was fully digital end-to-end ... A customer will have total access to Burberry across any device, anywhere.'  Mare Menesquen, managing director of strategic marketing at cosmetics gitan L'Oreal, said, 'The digital world multiples the way our brands can create an emotion-filled relationship with their customers.’”

    Serve Your Customers in Smarter Ways

    You can use technology to personalize the experience for your customers, and create better interactions along the customer experience journey.

    Via Leading Digital:

    “Other companies envision how they can be smarter in serving (and selling to) their customers through analytics.  Caesars started with a vision of using real-time customer information to deliver a personalized experience to each customer.  The company was able to increase customer satisfaction and profits per customer using traditional technologies.  Then, as new technologies arose, it extended the vision to include a mobile, location-based concierge in the palm of every customer's hand.”

    Learn from Customer Behavior

    One of the most powerful things you can now do with the combination of Cloud, Mobile, Social, Big Data and Internet of Things is gain better customer insights.  For example, you can learn from the wealth of social media insights, or you can learn through better integration and analytics of your existing customer data.

    Via Leading Digital:

    “Another approach is to envision how digital tools might help the company to learn from customer behavior.  Commonwealth Bank of Australia sees new technologies as a key way of integrating customer inputs in its co-creation efforts.  According to CIO Ian Narev, 'We are progressively applying new technology to enable customers to play a greater part in product design.  That helps us create more intuitive products and services, readily understandable to our customers and more tailored to their individual needs.”

    Change Customers’ Lives

    If you focus on high-value activities, you can create breakthroughs in the daily lives of your customers.

    Via Leading Digital:

    “Finally, some companies are extending their visions beyond influencing customer experience to actually changing customers' lives.  For instance, Novartis CEO Joseph Jimenez wrote of this potential: ‘The technologies we use in our daily lives, such as smart phones and tablet devices, could make a real difference in helping patients to manage their own health.  We are exploring ways to use these tools to improve compliance rates and enable health-care professionals to monitor patient progress remotely.’”

    If you want to change the world, one of the best places to start is right from wherever you are.

    With a Cloud and a dream, what can you do to change the world?

    You Might Also Like

    10 High-Value Activities in the Enterprise

    Cloud Changes the Game from Deployment to Adoption

    The Future of Jobs

    Management Innovation is at the Top of the Innovation Stack

    McKinsey on Unleashing the Value of Big Data

    Categories: Blogs

    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

    Object-Oriented Theater

    Matteo Vaccari - Thu, 10/30/2014 - 17:34

    Update 30/10/14: I first read about the “Object Theatre” in a message by Anthony Green on the GOOS mailing list; I didn’t remember it consciously when I wrote this post, but it certainly has been working in my brain ever since. The “Object Theatre” metaphor is his invention, not mine. Thanks Kevin and Anthony for pointing it out.

    Yesterday evening I attended a good introduction on functional programming by Mario Fusco. One of his slides illustrated a well-known principle of functional programming. There are pure functions, and “functions” with side effects. Good FP style suggests to keep non-pure functions at the edges of the program, so that the inner core of your program only contains pure, mathematical functions.

    He showed this picture

    http://www.slideshare.net/mariofusco/if-you-think-you-can-stay-away-from-functional-programming-you-are-wrong/41

    In fact, a very similar picture can be drawn for good object-oriented style. In good OO style, you want to separate your domain objects from infrastructure objects. The domain objects contain just domain logic, they execute in memory and have no references to file system, databases or network services. They can be mutable, of course! But they are “pure logic” in the sense that they live in a platonic world where we are only concerned with the functional behaviour of our programs.

    Infrastructure objects, on the other hand, deal with everything else: user interface, databases, file systems, web services… All the things that are needed to connect our platonic world of objects to the outside world.

    So what’s good OO style in this context? In my opinion, it’s good to keep the infrastructure objects in an outside shell, while the inner core of the program contains only pure domain objects. Let me give you an example.

    Suppose you have a Counter object that needs (for non-functional reasons!) to be made persistent. The functional logic is about incrementing and decrementing the value of the counter. The infrastructure logic is about making sure that the counter retains its value across reboots (which is definitely a non-functional requirement.)

    The wrong way to do this is

    // bad style! don't do this
    class Counter {
      public Counter(int id, CounterDao dao) {
        this.id = id;
        this.dao = dao;
      }
    
      public void increment() {
        value++;
        dao.incrementCounter(id);
      }
    
      private int value = 0;
      private int id;
      private CounterDao dao;
    }
    

    The usage of this counter would be

    CounterDao dao = ...;
    Counter counter = new Counter(123, dao);
    
    // here we perform logic and also persist the state
    counter.increment();
    

    The above example is bad style, because it mixes persistency logic with functional logic. Bah! A better way to do it is:

    class Counter {
      public void increment() {
        value++;
      }
      private int value = 0;
    }
    

    See? Only pure logic. We don’t care about persistency there. We could use the counter this way:

    // we start this use case in the world of infrastructure
    CounterDao dao = ...;
    Counter counter = dao.findCounter(id);
    
    // here we enter the world of pure logic
    counter.increment();
    
    // here we return to the world of infrastructure
    dao.save(counter);
    

    I like to call this structure “object theatre”. Imagine your domain objects as actors in a play. You want to setup a scene where your actors are set up in a certain way: Arlecchino talks to Colombina, Colombina has a fan in her hand, etc. When the scene starts, the actors perform each according to their character. When the scene ends, we lower the curtain.

    I imagine that an object-oriented system works the same way. When a request arrives, we set up the scene by retrieving all the proper objects from various repositories and we connect them appropriately. This is setting the scene. Then we send a message to one object that sets some logic in motion. The objects send messages to each other, carrying out a computation. This is playing out the scene. When the domain objects are done, we conclude by returning the objects to their respective repositories. This is lowering the curtain.

    Categories: Blogs

    SAFe Overview Video by Inbar Oren

    Agile Product Owner - Thu, 10/30/2014 - 17:32

    Inbar Oren, the maker of the short and fun “SAFe 3.0 in 9 minutes video” (see http://scaledagileframework.com/foundations/), recently presented an overview of SAFe to an audience at Adventures in Agile meet-up in London. Of course, it took him longer than nine minutes, but you can learn a lot more about SAFe in this video:

    https://www.youtube.com/watch?v=9TJDobOJMQw

    Thanks Inbar!

    Categories: Blogs

    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

    Scrum Gathering South Africa 2014 Report Back

    Growing Agile - Thu, 10/30/2014 - 12:57

    Last week we attended the Scrum Gathering in South Africa. As usual it was a well organised conference with loads of learning and great sessions. We recorded a video podcast of the sessions we attended and what we enjoyed.

    Sam also interviewed some people at the conference to find out what other people enjoyed to.

    Well done to SUGSA for yet another awesome event!

    Categories: Companies

    Agile Quick Links #25

    Notes from a Tool User - Mark Levison - Thu, 10/30/2014 - 12:08
    AgileSome interesting reading for the Agile community:
    Categories: Blogs

    Agile Smells Versus Agile Zombies in the Uncanny Valley

    Leading Agile - Mike Cottmeyer - 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

    Candy or Death: The Automatic Halloween Candy Dispenser

    Radyology - Ben Rady - Thu, 10/30/2014 - 05:59
    Let's start with a word problem. Assume you live in a busy trick-or-treating neighborhood and that, on average, a group of four rings your doorbell every minute and takes 1/2 oz of candy per person. If you leave a bowl... Ben Rady
    Categories: Blogs

    Knowledge Sharing


    SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.