OK, I'm cheating a little on this one, but watch this 7 1/2 minute lightning webinar Why Seeing the Value Stream Is So Important  When one sees that our workflow does not match our management hierarchy, one can better understand: one of the main challenges to developing software why Scrum is a great way to avoid this challenge but how it doesn't work as well as the size of the organization...

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

Richard Hundhausen has put together a great list of funny Scrum/Agile related videos. Some of these are classics such as High Moon Studios: Portrait of Scrum and Adam Weisbart’s Shit Bad Scrum Masters say.

Be warned, not all of these are actually that funny. I’ve never found The Downfall of Agile Hitler to be funny, because the original film is harrowing and difficult to watch. I also find the Scrum Haka to be trite and unwatchable … this is what a real haka should look like.

So here’s the list and, once you’re done (in the words of Adam Weisbart), “Get back to work!”

I want to run an agile project http://www.youtube.com/watch?v=4u5N00ApR_k I want to run an agile project (part 2) http://www.youtube.com/watch?v=lAf3q13uUpE The Power of Scrum (Ian Sense Scrum Master) http://www.youtube.com/watch?v=P6v-I9VvTq4

The making-of http://www.youtube.com/watch?v=ncjdtqf1gSg Developer Abuse http://www.youtube.com/watch?v=LYlhCGng5Mk Spooning and pair programming http://www.youtube.com/watch?v=dYBjVTMUQY0 Improving Sprint Reviews (is that Jeroen?) http://www.youtube.com/watch?v=fpBQ5yxrR_c The Downfall of Agile Hitler http://www.youtube.com/watch?v=l1wKO3rID9g High moon studios: Portrait of Scrum http://www.youtube.com/watch?v=UT4giM9mxHk Shit Bad Scrum Masters Say http://www.youtube.com/watch?v=GGbsgs611MM The Scrum Haka (hideous) http://www.youtube.com/watch?v=Qvqq97unS2w Joe Justice Team WikiSpeed http://www.youtube.com/watch?v=x8jdx-lf2Dw Deathstar Project Deployment Meeting http://www.youtube.com/watch?v=2T5QNcb_Z8g Raking Leaves – A Scrum/Agile Approach http://www.youtube.com/watch?v=StBS-loIIz4 I Need Agile Methodology http://www.youtube.com/watch?v=nvks70PD0Rs

Signup for the Scrum Addendum, our free online course with articles on: Keeping Daily Scrums short, Sprint Burndown Graph signatures, Release Burndown graph patterns, Eating one’s own dog food, Distributed Scrum and patterns for Success, Beyond Continuous Integration, The Principle of Postponement, Agile Contracts and more.

When you subscribe, you will receive an email every week for 13 weeks. You’ll also receive two white papers: "A Roadmap to Agile Development: A Strategy to Increase Adoption Success", and "The Top 13 Organization Challenges of Agile Development." This is some of our best material and it’s been re-edited especially for this email series. Signup here ... it's free!

Running continuously sprint retrospectives while keeping the Scrum team awareness during this activity is one of the biggest challenge for ScrumMasters. In this article, Marc Nazarian present an game called “Turn the tables” that should help the ScrumMaster to achieve this objective. This game is a simple exercise where team members write on red and green cards two things that went well during the sprint and two things that could be improved in just one or two words. The interesting part of the game is that these cards are then passed ...

How do you prioritize your features?  Is it a gut-feel kind of thing?  Is it based on who’s yelling the loudest?  Is it based on what drives your next big sale?  Do you do it collaboratively or alone?

In his book Principles of Product Development Flow, Don Reinertsen suggests using calculated economic models to decide what work to do first.  Specifically, he advocates an approach called Weighted Shortest-Job-First, or WSJF.  All other things being equal, the shortest job will deliver value soonest, so you should do that one first.  

But all other things are not equal - some projects reduce risk more than others, some enable other opportunities, and some are more important to your customers.   So you weight the scores - roughly, value over job size.

This approach is gaining popularity in part because the SAFe framework suggests you use it.  And it sounds great on paper.  But how does it work in the real world?

At Rally, we recently held a roadmap planning meeting with one of our product lines, and we tried a collaborative game to incorporate this economic technique into our planning session.  

We started by estimating relative job size.  Our group of 14 tech leads, product owners, and other leaders started with a bunch of stickies on a whiteboard representing value we wanted to deliver.   I asked the team to sort them by size - smallest items at the top of the board; largest at the top.  As they moved the items, they discussed each move.  People took turns, and asked clarifying questions.  

“Why do you think that one is so huge?” asked Greg, a product marketing director.  

“Because I have no idea what it means! It could be anything!” replied Ryan, a dev manager.   Together, they were able to clarify some details and get it sized, and we processed about 40 items in about 20 minutes.

As the movements slowed down, I stepped in and forced the stickies into 5 clusters.  I asked the team to correct my clustering if I had made mistakes, and they adjusted a few stickies.

We then translated them into rough cost.

I then asked the group about the smallest cluster.   “Do we think each one of these on its own could be completed by a team in significantly less than 3 months?”.  They said yes.  “How about the next group? Is that still less than 3 months?”  Yes.  “How about this next group?  Is it about 3 months, or is it more?”.  I did some simple math to figure a rough loaded cost for a team for a month, and used that to put rough dollar amounts on each size - $100k, $150k, $250k, $750, $1M+.

A couple of things about this:

1. You don’t have to be very accurate about this.  You just need a rough sense of relative size.
2. The dollar cost went up steeply for the larger items.  I wanted a dollar amount on the bigger items that would prompt fear, and then conversation about how it could be broken down.  Beyond 3 months, you have no idea how big these items really are.  But, if they’re valuable, you can break them down more.

Value Scoring

Once we had our jobs roughly sized, we used a Google spreadsheet to value score them. Dean Leffingwell and the SAFe folks recommend calculating relative scores for user value, time value, and risk/reduction opportunity enablement value for each item to get a good sense of cost of delay. But I had 14 people in the room and I figured across the group I could get similar results a quicker way.

I went with Johanna Rothman’s suggestion to let people distribute value points across all the items any way they wanted, and then explain their rationale.  

Here’s how it looked:

It’s not a ‘buy-a-feature’ activity.  Rather, each person got 10,000 points (enough to feel rich) to distribute however they wanted across all the items.  After 5 minutes, each person talked through their rationale.

This was the important part.

If Tom and Alan are using completely different rationales to prioritize, and then we just use a formula to rank our items, and that formula happens to put Alan’s favorites at the top of the list, Tom doesn’t feel heard.  The reality is that each person has a very good reason for the scores they offered.  The goal of this meeting is to have a really rich conversation about value.  I want to go beyond Reinertsen’s goal of getting our priorities right.

I want the whole team bought in to our decisions.  The conversation about the rationale helps us get there.

Then we sorted the list, highest value score first.  This was interesting - we saw a lot of obviously important items bubble to the top.  Some of them were very large.  We talked about how people felt about the results - what was missing that they felt should have been higher.  

The magical calculation

Then Michael, an internal coach, spoke up, and suggested we try a weighted-shortest-job-first score.  To do this, we divided our total value score by the cost (the value/cost column in the picture above).  A number of items that were small but valuable jumped higher up in our list.  This led to another valuable conversation

So we’re done, right?

Does the WSJF scoring solve all prioritization problems?  Do you work on items in exactly that order?  Not exactly.    We did another activity to lay out our work into our roadmap, and this led to further conversations about the capabilities of different teams, dependencies with other groups, and the like.  It’s not a perfect technique, but it was an incredibly valuable input for us.

For more on  managing a portfolio, tracking and prioritizing work according to its value, and effectively aligning business strategy with development work, join our Portfolio webinar series.

Alex Pukinskis

Unlängst schilderte mir ein guter Bekannter, ein Unternehmensberater, dass er eine Führungskraft zu unterschiedlichen Ausprägungen ihrer Kompetenz befragte. Er wollte mit der betreffenden Person gemeinsam Handlungsfelder identifizieren, in denen diese sich entwickeln könnte. Es kam allerdings heraus, dass die Führungskraft mit dem Stand ihrer Entwicklung vollends zufrieden war und dass aus ihrer Sicht derzeit kein wirklicher Handlungsbedarf bestand. Etwas irritiert erzählte mir der Bekannte, dass er sich über die vollkommen übersteigerte Selbsteinschätzung dieser Führungskraft ärgerte und er gar nicht verstehen könne, dass die Diskrepanz zwischen seiner Meinung und der der Führungskraft so groß war. Er begründete seinen Ärger mit den Worten: „Das ist so typisch. Sie (die Führungskraft) denkt tatsächlich, dass sie schon alles weiß. Es gäbe so viel zu verbessern. Ich habe die Arroganz und Ablehnung in ihrem Gesicht gesehen. Wie kann man nur so von sich überzeugt sein!“ Ich stutzte, sah meinen klagenden Bekannten mit einem Schmunzeln an und erwiderte: „Du hörst dich an wie Othello.“ Fragend sah er mich an: „Othello? Was hat der denn damit zu tun?“

Der Othello-Effekt

Othello, Feldherr in der Republik Venedig und mit der wunderschönen Desdemona verheiratet, wurde das Opfer einer Intrige. Ihm wurde der schreckliche Floh ins Ohr gesetzt, dass Desdemona eine Affäre mit seinem bestem Freund Cassio hätte. Der voreingenommene und rasend eifersüchtige Othello konfrontierte seine Ehefrau mit dieser Anschuldigung, forderte sie auf zu gestehen und beging dabei den Fehler, ihren unter Tränen vorgebrachten Unschuldsbeteuerungen keinen Glauben zu schenken. Rasend vor Eifersucht erwürgte er sie, nachdem er zuvor bereits ihren angeblichen Geliebten getötet hatte. Othello sah, dass Desdemona offensichtlich Angst hatte, als er sie zur Rede stellte. Als sie dann auch noch zu weinen begann, nachdem sie von Cassios gewaltsamen Tod durch die Hand ihres Mannes erfahren hatte, fühlte sich Othello zusätzlich bestätigt. Für die Tränen seiner Frau auf die Nachricht vom Tod ihres Geliebten und für die Angst in ihrem Gesicht konnte es nur eine Erklärung geben: Sie musste schuldig sein. Desdemonas Angst war für Othello ein Schuldbekenntnis des Ehebruchs, der ans Licht gekommen war.

 

Othello hatte Desdemona leider – wie sich später herausstellen sollte – zu Unrecht getötet und zwar ohne anderen Ursachen für die Angst und Pein seiner Ehefrau Raum zu geben: Dass nämlich Desdemonas Angst die Reaktion einer unschuldigen Frau sein könnte, die wusste, dass ihr von Eifersucht geblendeter Ehemann im Begriff war sie umzubringen. Und sie hatte ja keinerlei Möglichkeit mehr, ihre Unschuld zu beweisen, weil der Einzige, der es hätte bestätigen können, bereits tot war.

 

 

Emotion verrät uns nichts über ihren Ursprung

Emotionale Signale, wie z.B. Ärger, Überraschung oder in Othellos Fall Angst, verraten uns nie etwas über ihren Ursprung oder anders ausgedrückt (vgl. Ekman, 2011, S. 80ff):  Wenn ich das Was kenne, weiß ich noch lange nichts über das Warum. Wollen wir den Othello-Effekt vermeiden, müssen wir daher der Versuchung widerstehen, zu rasche und einseitige Schlüsse zu ziehen. Dies gelingt uns nur, wenn wir uns darum bemühen, neben der für uns offensichtlichsten, also der erstbesten Ursache für ein Gefühl, mindestens eine Erklärungsalternative zuzulassen.

 

Wenden wir uns mit dieser Erkenntnis erneut meinem Bekannten zu. Die Führungskraft reagierte auf sein Weiterentwicklungsangebot mit arroganter Ablehnung. Die offensichtlichste Ursache lag für meinen Bekannten auf der Hand: Die Führungskraft erkannte keinen Handlungsbedarf für sich. Diese ablehnende Haltung wurde durch die Erwartungshaltung meines Bekannten verstärkt, der aus seiner Sicht Handlungspotentiale identifiziert hatte und daher mit einer ganz anderen Reaktion gerechnet hatte. Fremd- und Selbsteinschätzung gingen vollkommen auseinander. Mit freundlichen Grüßen, Othello.

 

Welche weiteren Ursachen könnte das ablehnende Verhalten der Führungskraft gehabt haben? Antworten finden sich, wenn wir uns Fragen nach alternativen Ursachen stellen:

 

• Welche Erfahrungen hatte die Führungskraft in der Vergangenheit mit Weiterentwicklung gesammelt?
• Welchen Anteil hatte der Berater und die Art und Weise seines Angebots, dass die Reaktion so ausgefallen war?
• Wie würden der Vorgesetzte der Führungsraft oder das Team reagieren, wenn sie wüssten, dass diese noch Handlungsbedarf in punkto Führung hat?
• Was wohl andere Führungskräfte über mögliche Defizite dieser Führungskraft denken?

 

Wie ihr seht, eröffnen die Fragen mehrere, alternative Zugänge auf Ursachen für die Reaktion bzw. Emotion der Führungskraft. Der Othello-Effekt ist in unserem Alltag allgegenwärtig und handlungsleitend. Achtet darauf und nehmt euch Zeit dafür, Ursachen zu erforschen. Wenn ihr bei eurem Gegenüber eine Emotion wahrnehmt, dann bewertet sie nicht gleich. Oder, wenn ihr das tut, dann denkt an Othello und gebt einer zweiten Meinung zu eurer Bewertung eine echte Chance.

 

Und in Teil 2 von ScrumMaster sind Meister der Effekte und Illusionen geht es um den Halo-Effekt und seinen Einfluss auf die Teamleistung und die Teamkommunikation.

 

Literatur

Ekman, P. (2011). Gefühle lesen. Wie Sie Emotionen erkennen und richtig interpretieren. Spektrum.

Related posts:

1. Der ScrumMaster ist eine Versicherung (Mike Beedle)
2. Über das Schreiben | Schreibblockaden
3. Über das Schreiben | Leidenschaft

  Continuing with the  100 Things You Must Know to Be Effective In Software Development. Scrum talks about self-organizing, cross-functional teams. Let me make it clear, this is the best team structure I know.  Some folks have construed this to mean - teams of generalists.  That is not what it means.  It means the team has all of the skills and knowledge required to create valuable software....

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

I’ve been reading a lot lately about the concept of enterprise agile and how the heck to do it. Agile development roots point to a very team-centric concept. And its success has piqued interest from other teams, other business units, and larger enterprises when it comes to scaling agile faster, better and easier. In fact, more than 61% of VersionOne customers recently said they’re in the process of scaling agile across their organizations.

The potential of agile is awesome… but it can be difficult to successfully adopt. For people who have been there, they can tell you it’s hard…but worth it. If you’re planning an enterprise agile project and worry what growing pains you’ll run into, you’re not alone.

One highly effective approach I encourage you to look into is the concept of Scaled Agile Framework (SAFe). Ever heard of it? Dean Leffingwell, a renowned methodologist, coach, entrepreneur and author is giving a presentation on SAFe which you won’t want to miss:

AgileLIVE Webinar:“Accelerate Enterprise Agile Adoption with Scaled Agile Framework”
Join your peers for this two-part webinar series. Register Now!

Part I – Monday, May 13th at 12 Noon EDT
Join Dean Leffingwell for an overview of SAFe, a publicly-accessible knowledge base of proven lean and agile practices for enterprise-class software development. You’ll learn how SAFe enables you to:

• Deliver business results that scale
• Keep your development system – and enterprise – lean
• Increase responsiveness to rapidly changing market needs

Part II – Wednesday, May 22th at 12 Noon EDT
Join us for a look into how VersionOne supports SAFe and helps accelerate adoption of enterprise agile. Andy Powell, Product Evangelist and Scaled Agile Framework Program Consultant, along with Lee Cunningham, Enterprise Agile Coach, will focus predominantly on the Portfolio and Program levels of SAFe and will demonstrate how VersionOne provides:

• Metrics that enable your business leadership to make more informed decisions
• Visualizations to help program managers pinpoint areas of risk
• Collaboration capabilities to capture the “why” behind key decisions

If you can’t make this series, no sweat. The focus of this year’s series is helping organizations maximize the benefits of enterprise agile, so stay tuned for info on future AgileLIVE webinars!

More than 1,000 developers across 72 events will join together on June 1-2 for National Day of Civic Hacking. Their mission? To use publicly-released data, and code to solve challenges relevant to our neighborhoods, our cities, our states and our country.

Here are 10 reasons why you should join:

1. Make a difference while building your local Agile and open source community
2. It’s only one or two days! And it might also open minds, hearts and doors to work that extends us beyond all of our “day jobs”
3. 24 data feeds and 17 federal government partners will lead to some great hackathon magic
4. President Obama and Todd Park, National CTO, are opening the White House for hacking via a lottery, and as a demo platform for the best applications
5. All this work will help the government open more data and thus create a better informed public
6. Tim O'Reilly will be proven as a prophet and general good guy for helping promote open source, open data and hacking for the last decade 
7. Get $200 off your registration for our RallyON conference by joining us to hack with the team from the National Renewable Energy Lab in Boulder
8. Your volunteering opens your eyes to the role of citizen engineers in solving the world’s toughest problems
9. Don’t have an event near you? Join a Rally team remotely using FlowDock and AgileZen
10. Support a culture of hacking that can lead to continuous innovation in your own organization

As part of our Rally for Impact efforts to help create and mobilize citizen engineers that are technically, environmentally and socially responsible, we are a proud sponsor of the National Day of Civic Hacking. Thanks to organizers like Code for America, Innovation Endeavors and Random Hacks of Kindness. And thanks to the organizational skills built by Second Muse, sites are finding great local and state resources.

Please consider joining, sharing and re-posting about National Day of Civic Hacking in your company and community

Join us in Boulder, CO to learn from industry experts and peers, hear what's next for Rally's product suite; and have a little fun while you're at it!

Schedule of Events

RallyON Hackathon
Fri - Sat, May 31 - June 1
National Civic Day of Hacking
Sat - Sun, June 1- 2
RallyON! Conference
Mon - Wed, June 3 - 5

Ryan Martens

I formed LKU as an equal partner with David Anderson in 2011 with high hopes of an organization that would manifest the values of industry service, thought leadership and inclusion.  I envisioned it as a place to provide industry awareness of the value of Lean and Kanban, a listing of courses on Lean and Kanban, and as a way of identifying those truly experienced Lean and Kanban trainers and...

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

Als Management Consultant bekomme ich regelmäßig die Möglichkeit, die Scrum-Implementierung in den unterschiedlichsten Branchen und Unternehmen zu beobachten bzw. zu begleiten. Interessanterweise ähnelt in der Auslegung von Scrum kaum ein Unternehmen dem Nächsten – nicht einmal, wenn es um die Abhaltung der Scrum-Meetings geht. Selbst das kürzeste Meeting im Scrum Flow, das Daily Scrum, sieht stets anders aus. Vor allem bei Scrum-Neulingen habe ich die Erfahrung gemacht, dass ein gewisser, vorher gemeinsam mit dem Coach geübter Ablauf dem neuen ScrumMaster etwas Sicherheit bietet. Mein Vorschlag sieht meist so aus:

Zweck

Synchronisation innerhalb des Dev-Teams, um das Sprintziel und somit das Release zu schaffen.

Ziel

Als Team wissen wir, was erledigt werden muss, damit die committeten Stories auf Done gesetzt werden können.

Ablauf

1. Das Dev-Team trifft sich im Halbkreis vor dem Taskboard. Der ScrumMaster steht seitlich ca. einen halben Schritt außerhalb dieses Halbkreises. Gäste stehen komplett außerhalb des Halbkreises.
2. Begrüßung durch den ScrumMaster – ein “Guten Morgen” reicht aus. Hier ist ein motiviertes Auftreten wichtig: Wenn der ScrumMaster als Coach des Teams schon keinen Bock hat, wie soll das Team dann erst Lust bekommen? Der ScrumMaster startet mit einer Begrüßung und macht auf die geplanten Termine für den Tag aufmerksam.
3. Falls jemand im Dev-Team noch keine Vorstellung hat, welche Arbeit er an diesem Tag leisten kann/ möchte/wird, sollte er sich gleich anfangs zu Wort melden, damit das restliche Team ihn für potenzielle Aufgaben in Erwägung ziehen kann.
4. Nacheinander erzählt jedes Teammitglied seinen Kollegen Folgendes:
   1. Was habe ich seit dem letzten Daily umgesetzt? (falls fertig, wird der Task von Work In Progress in Done gehängt) Falls die Aufgabe wider Erwarten innerhalb des letzten Tages nicht fertiggestellt werden konnte, erklärt das Teammitglied kurz, wodurch die Aufgabe behindert wird. Dann wird ein Punkt auf das Post-It gemacht. Ggf. wird diese Störung am Impediment Backlog, auf dem Task bzw. an der Story visualisiert.
   2. Was werde ich heute tun? Hier zieht sich das Teammitglied eine Aufgabe aus der To Do Spalte der höchstpriorisierten User Story und hängt sie in Work In Progress. Falls möglich, plant das Teammitglied gleich Pair Programming mit einem Teamkollegen bzw. Unterstützung, die er in Anspruch nehmen möchte.
   3. Was behindert mich in meiner derzeitigen Arbeit? (Visualisierung nicht vergessen…)
   4. Wo benötige ich Hilfe?
   5. Meine heutige Verfügbarkeit
   6. Das nächste Teammitglied übernimmt und beantwortet dieselben Fragen gegenüber dem restlichen Team. Dies passiert reihum, bis das Team seine Arbeit synchronisiert hat und jeder weiß, was er heute mit wem bearbeiten soll.
   7. Ist eines der Teammitglieder nicht da, übernimmt ein anwesendes Teammitglied die Punkte des abwesenden Kollegen und hängt die jeweiligen Aufgaben auf dem Taskboard für ihn um.
5. Der ScrumMaster fasst abschließend folgende Punkte zusammen:
   1. Neue Impediments, die in diesem Daily ans Tageslicht gekommen sind und um die er bzw. jemand im Team sich kümmern wird
   2. Inwieweit sind aktuelle Impediments schon gelöst bzw. ist dafür die Hilfe des Dev-Teams nötig?
   3. Neue Termine, falls ein detaillierter Abstimmungsbedarf zwischen Teammitgliedern sichtbar geworden ist
   4. Die eigene heutige Verfügbarkeit, ggf. einer Vertretung
   5. Falls der Product Owner anwesend ist: Spätestens jetzt noch fragen, ob er weitere  Anmerkungen hat
6. Das Burn-Down Chart wird von einem Teammitglied aktualisiert.

Alles was man für dieses kurze Stand-Up benötigt, sind ein ScrumMaster, ein Dev-Team, ein Taskboard und ein Burn-Down Chart. Gäste, vor allem der PO, sind immer herzlich willkommen. Die Rahmenbedingungen von max. 15 Minuten, täglich, stehend, selber Ort, selbe Zeit dürfen deshalb aber nicht außer Acht gelassen werden.

Was haltet ihr von diesem kleinen “How-To”? Wie sieht der Ablauf des Daily Scrums bei euch aus?!

Related posts:

1. Christbaumschmücken Advanced
2. Erfolgreiches Nichtwollen
3. 10 Things about ScrumMasters

As we all know, the Agile Manifesto was authored at a ski lodge in Utah in 2001. These important guidelines and principles drive much of what we do. These simple, elegant words are very difficult to use in the real world and sometimes, in my opini...

Background When I attended the February 2013 Agile SoCal group meeting in Orange County, California, the main event was a presentation by George Schlitz, founder of BigVisible Solutions. The title of this presentation was Agile Beyond the Teams ...

Yesterday, this report showed only a daily cumulative quantity of tickets, we have improved upon it.

Do you use estimates on your daily work? - Good news, today you can choose "Ticket Estimate" from the “Type” select box.

 

You will be able to see the same Cumulative Flow chart, but this time you will see the sum estimation of your tickets (per status).

Which type of Estimating do you use?

• Do not use estimates: Default estimate value is 1.0, so you will get the same graph as Ticket Count.
• Show estimated total time: Estimate value is saved as a float value representing the total time, you will see a cumulative report of tickets total time.
• Show estimated points: In this case you can manually set points to each ticket, the result will be a summation over time of points in tickets.
• Estimate as T-Shirt sizes: (Small / Medium / Large): Same as estimated points but with predefined values.
  • Small => 1.0 points.
  • Medium => 3.0 points.
  • Large => 7.0 points

We have been collecting this data for a week so far - full month Cumulative Flow Chart will be available in three weeks. If you use estimates on tickets, then this upgrade is for you. Enjoy!

Read more about how Assembla can help You.

I recently read the excellent and fascinating book “The Power of Habit” by Charles Duhigg. The book doesn’t only cover habits of individuals, but also habits of communities and organizations. Reading it reminded me of a conversation I had with our CEO, Robert Holler about V-Days.

V-Day is our monthly company-wide gathering that brings everybody together to keep them in the loop as well as connected to each other. Family members, friends, and even job candidates are also invited. V-Day starts with lunch in the Game Room, continues with a break for everybody, reunites everybody for short presentations by each department about the last month, and usually ends with a “keynote” address by Robert.

The result?

• We generally feel informed about what is going on in the company
• We enjoy hearing the update rhymes Maggie finds the time to create about the Services department.
• We get to know new (and old) team members during lunch and the break
• We meet spouses and kids of co-workers, and they get to see where their parents go during the day
• We build shared memories

So what is the link between V-Days and The Power of Habit? I’m abbreviating a bit here, but you can build a habit by deciding on a certain routine that follows a certain cue – and practice it until it starts to be a habit. So non-habitual routines can turn into habits. However, they can also spawn additional habits by creating scheduled events that foster certain routines. For creating certain organizational behavior or company culture, the trick is figuring out which habits are most prominent in them, and which corporate event would most encourage those habits.

V-Days are a great example of that elusive “habit-fostering event.” They support three of the most prominent company habits – which also happen to be quintessential to agile teams: (1) Remember and share information that concerns others, (2) Interact with other people in VersionOne on a personal level as well as a professional one, and (3) Remember to acknowledge great work getting done.

I asked Robert if he had read the book, but he had not. Nevertheless, V-Day makes for a great illustration of many of Duhigg’s points, and IMHO a company-wide regular and fun get-together like this is one more secret to building agile culture.

 

Continuing with the  100 Things You Must Know to Be Effective In Software Development. If you read day 1, you knew what was coming today.  Acceptance Test-Driven Development is one of the greatest trim-tabs of software development. ATDD is one of the most powerful, easiest to introduce practices available.  It is about making sure you know what you need to build before you build it.  It has a...

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

It's been just over a week since Rally's IPO on the NYSE under the symbol RALY. We're settling back into our everyday work, and as I look back, I am again humbled to be one of the companies that trade in the public markets, and proud to be listed on the NYSE.

The morning of our IPO, I got to see Rally's logo on the front of the iconic NYSE building, I stood on the bell podium and pushed a giant green button with our founder Ryan Martens. And I toasted (with orange juice) enthusiastic employees in their offices around the world live from the bustling trading floor. 

But what struck me most throughout that day, and the days following, was the gratitude I felt. Tremendous gratitude. 

Thank you, Rally team. Rally is made up of individuals who are smart, committed and passionate. I am humbled that I get to come to work with you every day.

Thank you, customers. We work with and constantly learn from our customers and users. We continue to look to our customers as guides and partners, many of whom are helping redefine their industries through innovative software-powered products and services. We dedicate our success to date and our focus into the future to them. 

Thank you, partners, vendors and community members. Rally's ecosystem is strong and vibrant, and I know we are lucky to have those support systems all over the world.

In the midst of a lot of really hard work, we've had some fun and celebrations over the last week or so. Below are some of my highlights:

Here is a video of the NYSE opening bell ceremony:

Later I was proud to represent Rally, and our customers in talking with the media about a very special day for our company. Here's one take by our Boulder, Colorado-based Daily Camera.

Most fun for me as someone who values our culture so highly, here are a few photos of our employee celebrations that took place nearly simultaneously around the world.

Thank you for joining us on this journey, it's been – and will continue to be – a great ride.

Tim Miller

Kanban is coming to New England!  Code Genesys, a Boston IT Solutions firm, has partnered with David J. Anderson & Associates to sponsor a series of workshops on the Kanban method throughout 2013.  The Kanban Method is an emerging flow-based system for managing software engineering projects and operations. Scrum is an iterative Agile methodology that has become popular and has contributed much to process improvement in development teams. We’ll start by covering the basics on how to get started and the advantages this method offers compared to other approaches for managing product development. It covers key ideas like grooming and prioritization, release planning, demand analysis, metric analysis, setting WIP, classes of service, SLEs etc. By the end of the Workshop participants will:   Gain a basic understanding with the Kanban Game   Understand how to get started and start using Scrumban in your team   Own a data driven approach to evolutionary improvement   Know where to look for & get help Class Schedule Day 1 Introduction to Scrumban GetKanban Simulation Scrumban Mechanics     Epics & Stories     Work Item Types, Kanban System Design, WIP limits     Cumulative Flow Diagrams, SLAs, Little’s Law     System Thinking     Iterations & Sprints     Points & Velocity     Story Grooming Day 2 More advanced topics     Classes of Service     Cost of Delay     Shared or Cross Functional Resources Evolutionary improvement     Models for improvement Bottlenecks, Variability, Metrics     Velocity Planning, Predictions Scrumban in your organization     Organizational practices, Roll Out Plan     Transition Planning Register today! Only $1500 per personEarly bird rate $1000 until August 10 Discount Code: About the presenter Ajay Reddy started his professional career as a software engineer, and spent many years leading development teams and larger IT functions. He now spends the majority of his time helping technology organizations improve performance by successfully adopting agile practices. Ajay is consistently recognized for quickly adding value to the organizations with which he works through his “active communications, persistent yet compassionate mentoring, and leading by example.” Ajay is an Associate of David J. Anderson & Associates, founder of Code Genesys (a Boston-based IT Solutions company), and managing partner of ScrumDo.com (a cloud-based project management tool for Scrum teams). Location:Boston, MA, USA Venue: TBD  

Kanban is coming to New England!  Code Genesys, a Boston IT Solutions firm, has partnered with David J. Anderson & Associates to sponsor a series of workshops on the Kanban method throughout 2013.  The Kanban Method is an emerging flow-based system for managing software engineering projects and operations. Scrum is an iterative Agile methodology that has become popular and has contributed much to process improvement in development teams. The Scrumban Practitioner course teaches what we call the Scrumban Method — a non-prescriptive blending of the ideas of Scrum with Kanban. We’ll start by covering the basics on how to get started and the advantages this method offers compared to other approaches for managing product development. It covers key ideas like grooming and prioritization, release planning, demand analysis, metric analysis, setting WIP, classes of service, SLEs etc. By the end of the Workshop participants will:   Gain a basic understanding with the Kanban Game   Understand how to get started and start using Scrumban in your team   Own a data driven approach to evolutionary improvement   Know where to look for & get help Class Schedule Day 1 Introduction to the Scrumban Method GetKanban Simulation Scrumban Mechanics     Epics & Stories     Work Item Types, Kanban System Design, WIP limits     Cumulative Flow Diagrams, SLAs, Little’s Law     System Thinking     Iterations & Sprints     Points & Velocity     Story Grooming Day 2 More advanced topics     Classes of Service     Cost of Delay     Shared or Cross Functional Resources Evolutionary improvement     Models for improvement Bottlenecks, Variability, Metrics     Velocity Planning, Predictions Scrumban in your organization     Organizational practices, Roll Out Plan     Transition Planning Register today! Only $1500 per personEarly bird rate $1000 until May 10 Discount Code: About the presenter Ajay Reddy started his professional career as a software engineer, and spent many years leading development teams and larger IT functions. He now spends the majority of his time helping technology organizations improve performance by successfully adopting agile practices. Ajay is consistently recognized for quickly adding value to the organizations with which he works through his “active communications, persistent yet compassionate mentoring, and leading by example.” Ajay is an Associate of David J. Anderson & Associates, founder of Code Genesys (a Boston-based IT Solutions company), and managing partner of ScrumDo.com (a cloud-based project management tool for Scrum teams). Location:Boston, MA, USA Venue: TBD