Podcasts about standish group

Join Brian Milner in another episode of the Agile Mentors Podcast series on unlocking the secrets of a sustainable pace. Today he’s delving into the power of "No" in Agile. Tune in to discover the truth behind feature usage, prioritize value-driven choices, and tips for mastering the art of saying no without losing your job. Overview Today on the Agile Mentors Podcast, Brian Milner sheds light on the power of saying "No" in Agile organizations. "No" is an integral part of a healthy Agile organization. Learn how prioritizing value-driven choices empowers success in delivering the highest value to customers every time. Listen in as Brian shares valuable insights on establishing shared desired outcomes to ensure alignment and effective decision-making within teams and organizations. Tune in for practical tips on mastering the art of saying "No" with confidence, navigating challenging conversations, and preserving relationships and job security along the way. Listen Now to Discover: [00:53] - In this episode of our summer series on practicing sustainable pace, Brian Milner talks about how important it is to say no, without losing your job. [01:40] - Challenging the 64% Myth: Unveiling the Truth Behind Feature Usage (famous Standish Group study on feature utilization and Mike Cohn’s research). [2:15] - The 2019 Feature Adoption Report | Pendo.io White Papers and The Surprising Power of Online Experiments. [02:49] - Slack's monetization woes - unveiling the reality: 70% of features fail to deliver. [03:13] - Product development philosophy: switching course to design features people care about. [04:49] - Unlocking Agile's Key Principle: Product owners must practice saying NO daily in the mirror. [06:34] - Saying no to unlock actual value - selective deliveries for maximum impact and prioritizing quality over quantity in our deliverables. [07:17] - Saying no isn't always easy. [07:32] - Tips for navigating the art of saying no while preserving relationships and job security. [08:50] - How establishing shared desired outcomes in Agile ensures alignment and effective decision-making and fosters collaboration and value to customers. [10:11] - For product owners: how prioritizing value-driven choices ensures success for both the product and the organization. [12:56] - How developers can foster understanding and acknowledge their role while exploring how choices will impact the team and process. [13:39] - A strategic dialogue on overtime requests' downstream effects and impact. [14:54] - NO should be a regular occurrence in a healthy agile organization. [15:08] - A message from our sponsor: Better User Stories, a one-day live online training course with Mike Cohn to improve your user story writing, so your team can do its best work, faster. References and resources mentioned in the show: Standish Group Are 64% of Features Really Rarely or Never Used? #25: Scaling with Henrik Kniberg Product Ownership in a Nutshell Manifesto for Agile Software Development Mountain Goat Software’s Better User Stories Mountain Goat Software Certified Scrum and Agile Training Schedule Join the Agile Mentors Community Subscribe to the Agile Mentors Podcast on Apple Podcasts Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is the SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work.

Projects are hard. And a lot of them - maybe most of them - fail to live up to their expectations. Missed timelines, quality issues, budget overages, customer dissatisfaction - it seems sometimes like projects miss the mark more often than they hit it. But why is that? What can we learn from all those past projects that can help us make future projects more successful?  This is the question Jim Johnson set out to understand. In his years with the Standish Group, he and his team set the benchmark for one of the most respected analysis on project outcomes: the CHAOS Report. Join us in this short chat with Jim, as he tells us about the CHAOS report and some of his most important findings over the years. And maybe like Kate and I, you can also learn some important lessons from all those past project challenges. About our esteemed guest, Jim Johnson Jim Johnson is the retired founder and past chairman of the Standish Group, a globally respected source of independent primary research and analysis of IT project performance. He is best known for his research on why projects fail, as well as on system costs and availability. He is also a pioneer of modern research techniques such as virtual focus groups and case-based analytical technology. Get your copy of the CHAOS report here:  https://standishgroup.myshopify.com/    JOIN THE HAPPY HOUR! Get access to all podcasts, PDU certificates, bonus content, exclusive member Q&A webinars and more from our membership! https://pmhappyhour.com/membership STUMP THE PM'S! We love to hear about your tough PM issues, so please hit us up at podcast@pmhappyhour.com or on Linkedin and we'll see if we can help you. If we use your question, we'll send you a PM Happy Hour coaster you can enjoy at your next happy hour.  

Ole og Katrine har læst og gennemtygget Standish Group's CHAOS-rapport fra 2022. Rapporten har trofast målt på softwareprojekters succes siden 1994, men dette er den sidste CHAOS-rapport nogensinde. Uden at afsløre for meget handler det om, at Standish har erkendt, at de måler på det helt forkerte.Derudover er der et par chokerende resultater, der får hovedet til at eksplodere på Ole og Katrine. Vidste du, at jo bedre en projektleder du er, jo mindre succes vil dit IT-projekt have? Det og meget mere kan du høre om i dagens episode

Jak wynika z badań prowadzonych przez organizację The Standish Group, problemy w realizacji dotykają ok. 69% projektów IT i w wielu przypadkach skutkują ich całkowitym porzuceniem. Wprawdzie w konkretnej sytuacji może istnieć możliwość osiągnięcia porozumienia między Tobą i Software House/podwykonawcą IT, co do sposobu ukończenia projektu mimo problemów, jednakże najczęściej skutkują one zakończeniem współpracy. Jak zatem możesz to zrobić i jakie konsekwencje się z tym wiążą? – odpowiedzi znajdziesz w dzisiejszym podkaście.1️⃣ Artykuły wspomniane w podkaście:- Jak bezpiecznie zakończyć współpracę z Software House w razie problemów? https://creativa.legal/jak-bezpiecznie-zakonczyc-wspolprace-z-software-house-w-razie-problemow/- Wykonanie zastępcze w umowie IT: https://creativa.legal/wykonanie-zastepcze-w-umowie-it/2️⃣ Zobacz w jaki sposób jestem w stanie Ci pomóc. Stoisz przed problemem lub wyzwaniem? Szukasz najlepszego rozwiązania dla siebie, który opisałem w tym nagraniu? Umów się na 15 minutową bezpłatną konsultację z ekspertem: https://creativa.legal/bezplatna-konsultacja/3️⃣ Chciałbyś żebym poruszył jakiś temat w podkaście? Napisz bezpośrednio na mojego maila

How fast does your team make a decision? Does the speed at which you make decisions impact your probability of success? Based upon Jim Johnson of the Standish Group's research, it would appear so! Join us as we sit down with him to talk about decision latency theory as well as how to build a "winning hand" that helps guarantee success. Enjoy! Decision Latency Theory book The Standish Group The Standish Group - Twitter  

Today Jim Johnson is our guest, we will discuss with him Infinite Flow in relation to the responsiveness of organisations towards Change Dynamics. Infinite Flow is a non-project-based software development and implementation environment.

Começo de ano é época de matar ideias e fazer posts que anunciam que tudo mudou. 2017 não seria diferente, e, junto com os posts de "5 coisas que você deveria saber sobre agilidade", "Precisamos falar sobre agilidade", e "O que aprendi trabalhando x meses com um time ágil" estão os posts que, mais uma vez, anunciam a morte da agilidade. Que, afinal de contas, já está zumbi faz tempo, já que morreu inúmeras vezes desde que o termo nasceu, a primeira deve ter sido ainda em 2001. Brincadeiras a parte, o assunto bombou na comunidade essa semana, e vamos entrar na discussão. Vem polemizar com a gente! Feed do podcast: blog.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: blog.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos:blog.lambda3.com.br/feed/podcast-nao-tecnico Pauta: A agilidade morreu? Motivações pra essa conversa. Devemos seguir todas as regras da agilidade? E quando não dá pra seguir? Agilidade falha? Projetos ágeis falham? Se há falha, então a agilidade morreu? Por que todos hoje em dia querem dizer que são ágeis? Isso é bom? Pra onde vai a agilidade agora? Qual a próxima novidade? Haverá disrupção novamente? Links Citados: A morte do “Agilismo” e o que isso pode significar pra você, por Alisson Vale Chaos Report 2015 do Standish Group (pdf) Sênior tem cicatriz, por Giovanni Bassi Agile is dead, de Mathew Kern Scrum But Replaced by Scrum And O renascimento da agilidade, por Marcelo Leite Participantes: Arthur Fücher - @thur Giovanni Bassi - @giovannibassi Marcelo Leite - @MLeiteBarros Victor Hugo Germano - @victorhg Edição: Giovanni Bassi - @giovannibassi Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 – creativecommons.org/licenses/by/3.0

In 2002, Jim Johnson of the Standish Group (made famous by their Chaos Report of software project “success”) presented findings of features and functions used in a typical system. The number of features that were never or rarely used totaled a whopping 64% while sometimes, often and always weighed in with 16%, 13% and 7% respectively. For those acquainted with the Pareto principle (80/20 rule), notice how the often and always used features - those things we should concentrate on building for our customers and those things things that bring us the most value – is exactly 80%. In other words, a great deal of our effort is generally spent creating things that customers do not use or want.

Anforderungsmanagement Der Fachbuchautor Christof Ebert schreibt in seinem Buch „Systematisches Requirement Engineering“: „Früher dachte ich, Termin und Budgetüberschreitungen kommen von schlechter Schätzung. Dann dachte ich, sie kommen von hoher Komplexität. Heute weiß ich, dass sie davon kommen, dass praktisch alle Projekte zu spät begonnen werden. Dann fehlt die Zeit für die Anforderungsanalyse und Planung. Damit ist das Scheitern vorprogrammiert.“ (Ebert, 2012) Die Einsicht deckt sich auch mit meinen Erfahrungen der letzten 20 Jahre. Und das unabhängig ob es sich um Auftragsentwicklungen, oder interne Unternehmensprojekte handelt. Es wird viel Zeit in die Akquise und die Verhandlungen zu einem Projekt gesteckt. Der Auftrag liegt auf dem Tisch und das Projektteam steht womöglich auch schon in den Startlöchern. Jetzt müssen sie schnell produktiv werden. Da ist die Verlockung groß, die Anforderungen nicht weiter ins Detail zu zerlegen und abzustimmen, sondern schon mal beginnen zu lassen. Aber was versteht man eigentlich genau unter einer „Anforderung“? Eine Anforderung beschreibt, was der Kunde, Auftraggeber oder Benutzer vom zu entwickelnden Produkt erwartet (Nutzen, Eigenschaften, Verhalten, Attribute, Mehrwert) „Könntest Du mir bitte sagen, welchen Weg ich von hier aus nehmen soll?“, fragt Alice im Wunderland die Katze am Wegesrand. „Das hängt vor allem davon ab, wohin Du gehen willst“, antwortet diese. „Ich weiß es nicht…“, sagte Alice. „Dann ist es egal, wohin Du gehst“, antwortet die Katze. (Carroll, 1865) Auch wenn dieser amüsante Dialog aus dieser herrlichen Geschichte witzig anmutet, steckt doch sehr viel Weisheit darin. Ohne ein klares Ziel, wird uns der Weg den wir gehen irgendwo hinbringen. Auf das IT Projektgeschäft übertragen ist es damit aber reiner Zufall wenn wir das treffen, was der Kunde eigentlich wollte. Viel höher ist die Wahrscheinlichkeit dass wir völlig daneben liegen. Fällt das in einem frühen Projektstadium auf, können mittels Changerequest vielleicht noch notwendige Änderungen eingesteuert werden. Je später im Zeitverlauf eines Projektes aber noch Änderungen durchgeführt werden, desto größer sind die Auswirkungen. Das betrifft sowohl Wechselwirkungen mit der Änderungen mit bereits realisierten Systemteilen, als auch Auswirkungen bestehende Dokumentationen und Architekturen. Damit ist ein Designfreeze so früh wie möglich anzustreben und ab dann Änderungen nur noch über einen geregelten Prozess zuzulassen. Dieser intensiv zu managende Änderungsprozess muss die Auswirkungen von ChangeRequests transparent machen. Dafür ist kompetentes Personal einzuplanen. Nur wenn die Auswirkungen und damit Risiken einer Änderung im Detail klar sind, kann über ihre Umsetzung entschieden werden. Mit diesem kleinen Ausflug in das Änderungsmanagement wird klar, dass es deutlich besser ist, Änderungen nach Möglichkeit zu vermeiden. Ist diese Aussage aber richtig, wenn man sich moderne agile Entwicklungsmethoden ansieht, die Änderungen willkommen heißen? Ich glaube ja, denn auch bei agilen Methoden sind klare Anforderung die Basis für den Projekterfolg. Doch Anforderungen sind per Definition unsicher. Christof Ebert schreibt dazu in seinem Buch, dass sich Anforderungen mit einer monatlichen Rate, die 1-5% des gesamten Projektauftrags betragen ändern. Das heißt, dass von Anforderungen, die mit insgesamt 100 Personenwochen Projektaufwand abgeschätzt wurden, sich pro Monat Anforderungen im Umfang von bis zu 5 Wochen ändern! Diese 5 Wochen relative Änderung sind nicht immer mit 5 Personenwochen Aufwand zu erledigen. Stellen Sie sich vor, dass die Änderung erst kommt, nachdem die Anforderung bereits integriert ist. Dann kann eine Änderung ein Vielfaches des ursprünglich dafür notwendigen Aufwands betragen. Diese Hebelwirkung unterstreicht nochmals den Geschäftsnutzen eines systematischen Requirement Engineerings. Was über dieser 5% Änderungsrate pro Monat liegt, gefährdet den Projektverlauf massiv und die daraus resultierenden Projektrisiken können nur mit iterativen oder agilen Vorgehensweisen kompensiert werden. Die Standish Group erstellt seit 1994 alljährlich den Chaos Report der sich mit dem Erfolg- bzw. Misserfolg von IT Projekten beschäftigt. Sie gehört zu den bekanntesten und wichtigsten Langzeitstudien im Bereich Projektmanagement, seit 1994 wurden über 40.000 Einzelprojekte wissenschaftlich untersucht. Die Studie unterteilt in Typ1, Typ2 und Typ3 Projekte. • Typ 1 • Projekt erfolgreich abgeschlossen: Das Projekt wurde rechtzeitig, ohne Kostenüberschreitung und mit dem ursprünglich geforderten Funktionsumfang abgeschlossen. • Typ 2 • Projekt teilweise erfolgreich: Das Projekt wurde abgeschlossen, es kam jedoch zu Kosten- und/oder Zeitüberschreitungen oder es wurde nicht der vollständige geplante Funktionsumfang erreicht. • Typ 3 • Projekt nicht erfolgreich: Das Projekt wurde abgebrochen. Die Studie untersucht Ursachen für Erfolg und Misserfolg und stellt eine Korrelation zwischen Erfolgswahrscheinlichkeit und Projektgröße fest. Die festgestellten Haupterfolgsfaktoren sind: 1. Einbindung der Endbenutzer 2. Unterstützung durch das obere Management 3. Klare Anforderungen Die Hauptpunkte, die zum Scheitern der Projekte führen sind: 1. fehlende Zuarbeit durch Benutzer 2. unvollständige/unklare Anforderungen 3. häufige Anforderungsänderungen (http://de.wikipedia.org, 2015) Auch wenn die Studie in den letzten Jahren stark unter Kritik stand und vor allem die von der Standish Group unbelegten Abbruchzahlen angezweifelt werden, die Studie bestätigt das Paradigma moderner Projektmanagementsysteme, klare Anforderungsdefinition und intensive Einbindung der aller Stakeholder in das Projekt zu forcieren. Interessant in diesem Zusammenhang ist auch die Beobachtung, dass in Krisenzeiten wie in den Jahren 2001 nach dem 11. September und 2008 in der Wirtschaftskrise die vermeintlich unnötigen Ausgaben für Anforderungsmanagement und Reviews drastisch reduziert wurden. Dies hatte jeweils dramatischen Einfluss auf die Projekterfolge der betreffenden Jahre. Christof Ebert resümiert in seinem Buch „Technologische Herausforderungen sind keine gravierenden Projektrisiken. Schlechtes Projektmanagement dagegen schon.“ (Ebert, 2012) Doch wo sind die Schwierigkeiten zu klaren Anforderungen zu kommen? Da ist wie oben bereits erwähnt häufig einfach der Zeitfaktor. Doch wie wichtig es für den Anforderungsmanager ist, Anforderungen immer weiter herunter zu brechen und zu hinterfragen zeigt die Praxis. Mit den folgenden Beispielen möchte ich das etwas deutlicher machen: • Beispiel1: Der Auftraggeber erwähnt Funktionen nicht, weil sie für ihn selbstverständlich sind o Hier muss die Devise lauten, „denken Sie nicht für Ihren Auftraggeber, sondern lassen Sie es sich erklären“. Der Auftraggeber und seine Vertreter sind in der Regel die Spezialisten für das was am Ende herauskommen soll. Als Anforderungsanalyst lässt man sich hier häufig schnell dazu verleiten zu glauben verstanden zu haben und nicht weiter fragen. Sprechen Sie aus was Sie glauben verstanden zu haben und lassen Sie sich ihre Auffassung bestätigen. Sie kennen die Bedürfnisse des Kunden und das was er braucht, niemals so gut wie er selbst. Eine der Schlüsselregeln im Requirement Engineering besagt, dass man dem Kunden das liefern muss was er will und nicht das, was er (vermeintlich) braucht. • Beispiel2: Schwammig formuliere Anforderungen o Schwammige Formulierungen sind irgendwie tierisch bequem- für beide Seiten. Deshalb sind sie ja auch so beliebt. Der Auftraggeber soll sich festlegen- weiß aber im Detail vielleicht gar nicht so genau was er will. Gut wenn die Formulierung da butterweich formuliert ist und man da am Ende noch jede Menge Interpretationsspielraum hat was eigentlich gemeint war. o Auf der anderen Seite ist da natürlich die Auftragnehmer Seite. Auch hier sind schwammige Formulierungen eine bequeme Sache- vor allem wenn man noch nicht so genau weiß wie man es machen will und was das Ergebnis wirklich alles können wird. o Schwammige Anforderungen sind also allseits beliebt- zumindest in der Definitionsphase der Anforderungen. Spätestens wenn es an die Realisierung geht, fallen diese mit aller Gewalt auf die Füße. Dann hagelt es Changerequests und Designfehler wegen unklarer Anforderungslage • Beispiel3: Anforderungen die erst spät klar werden o Je innovativer und komplexer ein Projekt ist, desto höher ist die Wahrscheinlichkeit, dass sowohl von Auftraggeber- als auch von Auftragnehmer Seite Anforderungen erst sehr spät in der Realisierungsphase klar werden. Dieser Gefahr entgegnet man durch eine gründliche Anforderungsanalyse in der die künftigen Anwendungsszenare durchgespielt und immer wieder auf Konsistenz geprüft werden. Daraus ergeben sich die 3 Hauptrisiken des Anforderungsmanagements: • Fehlende Anforderungen o Es ist wichtig zu aller erst den Business Case des Kunden zu verstehen. Mit dem Verständnis für den Business Case, wird der Nutzen klar, der für den Kunden nach erfolgreicher Projektrealisierung entstehen soll. o Das blose Abfragen all dieser Anforderungen macht eine Anforderungsspezifikation aber noch lange nicht vollständig. Es ist wichtig den Grund, die Querbeziehung zwischen den Anforderungen und die Perspektive aus der heraus die Anforderung formuliert wurde zu verstehen. • Falsche Anforderungen o So wie man vergeblich nach fehlerfreier Software sucht, so muss man auch von fehlerhaften Anforderungen ausgehen. Doch qualitativ unzureichende Anforderungen die widersprüchlich-, inkonsistent-, lückenhaft sind, oder Denkfehler aufweisen führen nicht nur zu ständigen ChangeRequests, sie reduzieren auch die Arbeitsmotivation des Projektteams das durch solche Anforderungen zunehmend orientierungsloser wird. o Nur durch frühzeitiges validieren und verifizieren der Anforderungen, werden Fehler aufgedeckt. Die späteren Anwendungsszenare sind immer und immer wieder durchzuspielen um solche Fehler aufzudecken. o Am besten machen das erfahrungsgemäß die Tester. Diese haben ein Händchen für das Fehlerpotenzial und entdecken bei Reviews sehr viel mehr Fehler als Projektmanager oder Architekten. Darüber hinaus, ist es ein hervorragendes Training für die eigentlichen Tests, denn dadurch sind die Anwendungsszenare bestens bekannt. • Sich ändernde Anforderungen o Anforderungen deren Änderungen nicht kontrolliert werden, führen zu Termin und Kostenüberschreitungen und haben negativen Einfluss auf die Qualität o Auf keinen Fall dürfen Änderungen durchgeführt werden, deren Auswirkungen nicht analysiert und bewertet wurden. o Ab der zweiten Projekthälfte ist es ratsam, nur noch sehr wichtige Änderungen ohne größere Auswirkungen zuzulassen. o Ich wurde kürzlich von einem sehr jungen Softwareentwickler gefragt, ob man meiner Meinung nach jedes Projekt und sei es noch so klein, managen muss? Ich antwortete ihm, dass selbst ein Kleinstprojekt ein funktionierenden Änderungsmanagement benötig. Nur so ist dokumentiert, welche Anforderungen aktuell gültig sind und wo Änderungen anstehen. Hast Du Deinem Kunden erst einmal einen Termin auf Basis der vereinbarten Anforderungen versprochen, wirst Du es häufig erleben dass schon kurze Zeit danach die ersten Änderungswünsche hereinschneien. Das ist zwar ganz normal- muss aber abgefangen werden. Denn meist handelt es sich ja nur um „Kleinigkeiten“ die man doch noch so mitmachen kann. Doch auch vermeintliche Kleinigkeiten haben Wechselwirkung mit anderen Systemteilen, erhöhen die Komplexität und den Testaufwand. Ehe man sich versieht baut man sich mit einer solchen Kleinigkeit einen Fehler an ganz anderer Stelle ein. Und wenn man es erst einmal zugelassen hat, dass der Auftraggeber noch Anforderungen nachschieben darf, wird man das sehr schnell kaum noch unterbinden können. Und wie soll das Projekt dann zum vereinbarten Termin fertig werden? Änderungen erzeugen Aufwand für Realisierung, Test und Dokumentation und der muss sich auf die benötigte Realisierungszeit niederschlagen. Man müsste sich ja unterstellen lassen, den Aufwand nicht ehrlich kalkuliert zu haben, wenn Änderungen möglich sind, ohne dass dies Auswirkung auf Zeit und Geld hat. Nur wer Änderungen kontrolliert, hat die Möglichkeit die Erreichung der Projektziele zu kontrollieren. So, für heute möchte ich damit Schluss machen. In der nächsten Folge greifen wir dieses Thema wieder auf ich möchte Ihnen dann etwas über die verschiedenen Arten von Anforderungen erzählen. Bis dahin wünsche ich Ihnen viele grüne Meilensteine tschüss und bye bye Ihr Andreas Haberer Literaturverzeichnis Carroll, L. (1865). Alice im Wunderland. USA: Bassermann, Edition, 2014. Ebert, C. (2012). Systematisches Requirements Engineering. Stuttgart: dpunkt.Verlag Heidelberg. http://de.wikipedia.org. (1. 01 2015). Von http://de.wikipedia.org/wiki/Chaos-Studie: http://de.wikipedia.org/wiki/Chaos-Studie abgerufen Weitere Informationen finden Sie unter www.Bundesvereinigung-ITPM.de

Total Duration 27:05 Download episode 116 Never Had a Failed Project? Have you ever had a project that failed? Be careful--this is a truth test! If someone tells you they always deliver on time, on budget, with all the specified scope, be wary! Delivering projects successfully every time sounds great in an interview but a challenge in the real world. My guest today is Jim Johnson, Founder and Chairman of The Standish Group. Jim has a passion to understand why things break and how to fix them. In this discussion we talk about why projects break, and some ideas on how to improve the likelihood of successfully delivering. You can learn more about Jim and The Standish Group at http://www.StandishGroup.com. Call Me! Why do you listen to The People and Projects Podcast? What has helped you? What questions do you have for me? I love hearing from listeners and I want to hear from you! So call me! You can leave a message on our Podcast Listener Feedback line by phone or Skype. You can leave a message by phone at 847-550-3747 or by Skype at andy.kaufman.i-lead. Thanks! Thank you for joining me for this episode of The People and Projects Podcast! Have a great week! SKIPPY by Podington Bear is licensed by Attribution-NonCommercial 3.0 International License. LIES by Devora Clark is licensed under a Creative Commons License Agreement. CANDLEPOWER by Chris Zabriskie is licensed by Attribution License.