Skip to content

Feed aggregator

Pliiing, Gong & TickTack: Timeboxen beenden

Scrum 4 You - Thu, 10/23/2014 - 07:45

Dass Timeboxing toll ist, weil es uns ermöglicht, fokussiert und priorisiert zu schnellen Ergebnissen zu kommen und komplexe Umfelder zu stabilisieren, habe ich schon im Blogbeitrag “Was ist so cool an Timeboxing?” geschrieben. Dieses Mal möchte ich meine beiden Lieblingswerkzeuge vorstellen, die mir beim Timeboxing helfen.

Der Timer

Eines der wichtigsten Hilfsmittel, das ich in meiner Arbeit als Design Thinker kennengelernt habe und nicht mehr missen möchte, ist der Timer mit Zeitscheibe zur Visualisierung der Restzeit. Die Restzeit wird dabei durch eine immer kleiner werdende Farbfläche sichtbar gemacht. Das erzeugt positiven Zeitdruck und hilft, Meetings „in time“ zu einem produktiven Abschluss zu bringen. Der Vorteil gegenüber unsichtbaren Timern (z.B. Countdown auf dem Smartphone) ist, dass die Restzeit die ganze Zeit über im Raum sichtbar ist – nicht als abstraktes Zahlenwerk, sondern einfach und plakativ.

Probieren Sie es in einem Daily aus! Der Nutzen für den ScrumMaster ist groß: Es ist die Zeit, die das Meeting nach 15 Minuten beendet, nicht der „böse“ ScrumMaster, der sein Team zur Eile drängt. Es genügt ein Einwurf wie: „Ihr seht, dass wir nur noch 5 Minuten haben?“ und nach Ablauf der Zeit: „Es tut mir leid, aber unsere Zeit ist rum! Ich hatte das Gefühl, ihr zwei wolltet noch etwas sagen? Können die anderen wieder an die Arbeit gehen und wir besprechen das jetzt gleich noch?“ Schauen Sie dazu auch in den Blogbeitrag über Smart Timeboxing.

Unter Begriffen wie TimeTimer und ZeiTimer finden Sie unterschiedliche Varianten am Markt. Es gibt elektronisch gesteuerte Timer: Diese benötigen eine Batterie und haben ein elektronisches Piepsen, das bei manchen Modellen eine Lautstärkenregelung bietet. Kleinere Varianten sind meist rein mechanisch und haben daher durchgängig ein tickendes Geräusch – das kann in längeren, sehr ruhigen Meetings stören. Der Vorteil dieser Varianten ist, dass sie keine Batterie benötigen, sehr gut in das Handgepäck von uns Consultants passen und oft eine magnetische Rückseite haben, mit der sie einfach an jedem Whiteboard halten.

Laszlo Stein

Klangschale und Gong

Mein zweitliebstes Werkzeug nach dem Timer ist der Gong. Bei meinem elektronischen Timer stelle ich gerne die Lautstärke aus und nutze dafür den Gong. Bereits 1-2 Minuten vor Ende der Timebox schlage ich ihn ganz sanft, so dass ein kaum hörbarerer Ton meine Kollegen auf das Ende dieser Phase vorbereitet. Am Ende dann kommt dann ein lauter Schlag.

Es dauert maximal einen halben Tag (5-8 Einsätze des Gongs), bis Menschen auf dieses Signal trainiert sind und Sie damit die Aufmerksamkeit einfach und ohne ein lautes Wort steuern können. Große Gongs und Klangschalen haben eindeutig die schöneren, tieferen Töne. Damit sind auch leise Schläge möglich. Ich persönlich bevorzuge Gongs mit gebogenem Rand, die flachen Gongs (Windgongs) scheppern mir bei den lauten Tönen zu sehr. Aber wie die großen Timer sind sie für des Consultants Handgepäck nicht geeignet. Ich habe deshalb eine sehr kleine Klangschale angeschafft - daher das „pling“! Denn je kleiner die Klangerzeuger, desto höher der Ton. Sanfte leise Töne sind damit nicht möglich, das hohe „pling“ ist sehr durchdringend. Auch Zimbeln können den selben Zweck erfüllen.

Mein Tipp: Gehen Sie in ein Musikgeschäft (oder auch einen Esoterik-Laden, neben Räucherstäbchen und Traumfängern gibt es dort auch oft Klangschalen) und probieren Sie Ihr zukünftiges Hilfsmittel unbedingt aus. Sie werden erstaunt sein, welche Vielfalt sich beim Vergleich der Instrumente auftut und Sie werden irgendwann den Ton hören, den Sie  gerne mitnehmen möchten.

Die Kraft dieser beiden Werkzeuge liegt in der regelmäßigen Benutzung. Sorgen Sie dafür, dass der Einsatz so schnell wie möglich „normal“ wird und Sie werden ein sehr viel leichteres Leben als ScrumMaster haben.

Pliiing…

Related posts:

  1. Timeboxing: Zeitdruck tut gut
  2. Was ist so cool an Timeboxing?
  3. Design Thinking für Product Owner – Teil 3: Der Design-Thinking-Raum

Categories: Blogs

Raising Products

Bobtuse Bobservations - Bob MacNeal - Thu, 10/23/2014 - 07:26
Sunrise to sunset, products have a time-honored cycle. In the realm of software development, I prefer Products over Projects. Product life-cycleWho are the best people to raise a software product?...

Bobtuse can be wildly informative
Categories: Blogs

Assessing Your Enterprise Agility

Danube - Wed, 10/22/2014 - 18:04

I’ve often felt that CollabNet has been at the forefront of paradigm shifts in the software industry.

We founded Subversion, and then spent years driving its development and taking it to market.  Along the way, we added Subversion to our open ALM platform, becoming the leader in combining it with other open source (Git, Gerrit, Jenkins, Nexus, and more) development tools to the enterprise. Ultimately, we were the first to bring cloud-based approaches to large-scale, distributed software development. And, due to the “any tool, any process” nature of our TeamForge ALM platform, we have been hosting Agile initiatives and enabling DevOps long before the terms were coined as new categories.

From a client perspective, the result of this experience helped many of them – and the industry at large – achieve collaboration, business responsiveness, global visibility and innovation at levels never seen before.

Once again, I see another paradigm shift, now from workgroup “agile software development” to organizational-wide “Enterprise Agility.” And, I might add, rightfully so.

Today, many software developers work at multiple sites and use an array of open source, commercial and home-grown tools, along with a range of processes. These disparate tools and processes are often optimized for local workgroups and projects, all at the expense of business agility. This approach slows down software delivery and business responsiveness.

Our view and approach to Enterprise Agility starts with an assessment. Simply put, we’ve packaged the best processes and approaches we developed over the years with our clients as they transformed their global IT into a pragmatic blueprint. Today, we are pleased to announce this formalized process which will predictably and with measurability help organizations become more efficient and responsive. Our new services offering, Enterprise Agility Assessment, is years in the making, and it provides an actionable plan for unifying the flow of software, from planning to production. It helps workgroups achieve individual goals, while at the same time providing repeatability, IP reuse and governance for the company.

The engagement begins by identifying software delivery strengths and weaknesses, specifically those that involve organizational silos. Once the discovery process is complete, we then model a strategic action plan based on our Blueprint for Enterprise Agility.

blueprint enterprise agility Assessing Your Enterprise Agility

Blueprint for Enterprise Agility 

The Blueprint, based on unique organizational dynamics and a realistic pace of change, can be applied to any software organization looking for a practical and measurable business process for embracing Agile development, continuous integration, continuous delivery and continuous improvement. It helps organizations look beyond Agile tools and processes, and to develop the “bigger picture” for enterprise-wide business agility.

Some of the brightest minds in our company, and many customers, have contributed to this Enterprise Agility Assessment.

In the past few months, I’ve travelled globally as we’ve begun rolling this assessment out to our prospects and our partners.  Along the way, I’ve gathered many interesting perspectives on the challenges organizations face when scaling agile and other fractured tools and processes.

I’d like to get your thoughts on Enterprise Agility, too – and the challenges and successes you are seeing as you seek to scale to a global, unified view of Agile and DevOps.

 

The post Assessing Your Enterprise Agility appeared first on blogs.collab.net.

Categories: Companies

Think a Series of Sprints, Not Marathons

J.D. Meier's Blog - Wed, 10/22/2014 - 16:43

When you drive business change and digital initiatives with Cloud, Mobile, Social, and Big Data (and Internet of Things), successful businesses think a series of sprints, not marathons.

Successful businesses go digital by transforming their customer experiences, their employee experiences, and their back-office experiences through rapid prototyping, building proofs-of-concept, testing pilots, and going to production.  It’s a fast cycle of prototype –> pilot –> POC –> production.

These short cycles create rapid learning loops, build momentum, and help adapt for change.

In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share some of their lessons learned in driving digital initiatives and agile transformation.

The Digital World Moves Quickly

Avoid Big Up Front Design.  Whenever there is a big lag time between designing it, developing it, and using it, you’re introducing more risk.  You’re breaking feedback loops.  You’re falling into the pit of analysis paralysis.   Focus on “just enough design” so that you can test what works and what doesn’t, and respond accordingly.

Via Leading Digital:

“The digital world moves quickly.  The rapid pace of technology innovation today does not lend itself to multiyear planning and waterfall development methods common in the ERP era.  Markets change, new technologies become mainstream, an disruptive entrants begin courting your customers.  Your roadmap will need to be nimble enough to recognize these changes, adapt for them, and course-correct.”

Keep a Vision in Mind and Build on Success Along the Way

Hold on to the vision and use that to guide you as you test your ideas and implement them, without getting bogged down.

Via Leading Digital:

“To design an agile transformation, borrow an approach that has become common among today's leading software companies.  Keep people committed to the end goal, but pace your initiatives as short sprints of effort.  Create prototype solutions, and experiment with new technologies or approaches.  Evaluate the results, and incorporate the results into your evolving roadmap.  Adam Brotman, Starbucks CDO, explained the iterative process: 'We didn't have all the answers, but we started thinking about other things we could do ... I think it worked not to go too far, too fast, but to keep a vision in mind and keep building on success along the way.”

Test Ideas, Save Time, Adapt to Changes

Short cycle times help you respond to market change and adapt as you learn what works and what doesn’t.

Via Leading Digital:

“The test-and-learn approach will require some new ways of working in its own right, but it enjoys some distinct advantages.  By marketing ideas quickly before they go to scale, this approach saves time and money.  It's short cycle times also make it more adaptive to external changes.  Finally, it enables your transformation to sustain momentum through small, incremental successes, rather than the big-bang approach of long-term programs.”

When it comes to your digital strategy and driving business transformation, drive your business change the agile way.

You Might Also Like

10 Ways to Make Agile Design More Effective

Building Better Business Cases for Digital Initiatives

Cloud Changes the Game from Deployment to Adoption

How Digital is Changing Physical Experiences

McKinsey on Unleashing the Value of Big Data Analytics

Categories: Blogs

Cancel Your Executive Status Meetings (Do This Instead)

Rally Agile Blog - Wed, 10/22/2014 - 14:00

Last week I met with a strategy leader for an Australian financial services organization, who was trying to work out how to bring his executive team together on a regular cadence to align around strategy. He’d built a great Kanban board to visualize the large strategic projects the organization was pursuing -- sort of an executive-level roadmap -- and wanted some ideas for how to bring execs together around it.

In my role I spend a lot of time promoting a quarterly, one-day, Agile business steering meeting that brings leaders together to align on strategic priorities and harmonize their quarterly tactics. I think that such a meeting really is the heartbeat of business agility at scale. But once you’re aligned around your intentions for the quarter, how do you steer within the quarter?  

I recommend thinking about three cadences. These include:

  1. A weekly, extended management “impediments” meeting
  2. A weekly executive staff meeting
  3. A bi-monthly metrics meeting
1. Weekly Extended Management Impediments Meeting 

This Scrum of Scrums (SoS) is a short standup meeting involving your extended management team, usually 20-40 people depending on your organization’s size. The purpose of this meeting is to bring junior and senior executives together across departments to raise and resolve impediments encountered on any top priorities.

This is not a status meeting, and indeed, if you have any meeting reporting red / yellow / green status on your tactical initiatives, cancel it right now; you’re wasting time. Initiatives are often green until they’re suddenly red, and by then it’s too late to do anything. Huge amounts of waste goes into producing beautiful status reports that obscure what’s actually going on.

We run the SoS meeting standing in two concentric circles. The inner circle (close to the conference table) is for anyone with important news or significant impediments that they need help with; they’re the ones who speak. The outer circle (against the wall) is for everyone else: they only listen, unless they want to offer help with an impediment. This meeting often lasts just a few minutes, and never more than 30. The group leaves when the inner circle is done and all impediments have been managed.  

an example of an executive meeting format with concentric circles

It can help to track the readouts from this meeting on a simple impediments board, logging recent results, issues, and actions, so that when people walk into the meeting they can quickly recall the context of the last meeting without taking up meeting time.

Just like team-level Scrum, a meeting like this needs a facilitative leader who can keep people focused, handle distractions, and help the group move to action. But at this level, your facilitator needs to be comfortable interrupting senior executives who are rambling. This requires a tricky balance. It can help to ask the group explicitly, “Do I have your permission to facilitate so we can get to results quickly?”

2. Weekly Executive Staff Meeting

It usually makes sense to hold the SoS meeting just before your standing (closed) executive staff meeting, because it gives your senior leadership team the pulse of the issues before doing a deeper dive on their own work. If you’re doing a meeting like this, keep it. If you’re not doing it, start one.

3. Bi-monthly Metrics Meeting

This meeting is a deep dive on key metrics for the business, and may last 1-2 hours. It usually begins with key financial results (revenue, cash flow, and whatever other macro business results make sense for your organization.) Then it dives deeper into your business improvement metrics.

If you’re doing strategy deployment well, you have tactics for improving your business results and leading indicators that tell you whether you’re making progress towards achieving your results. If you’re using a balanced scorecard, all this should be sounding familiar.  

On a regular two- or four-week cadence, your senior leaders should be able to dive deeply into these leading indicators so you can sense whether you need to steer your tactics. If you expected your pipeline to be twice as big in the current quarter, or if you’re seeing a growing backlog in a specific part of your business, you can take action to adapt in the coming business steering meeting. The metrics cadence gives you time to get ahead of this work, so you can steer tactically during your quarterly meeting.

Bringing It All Together

The quarterly meeting is essential to building alignment at this level; once you’re doing it, these three regular meetings enable to you to steer and deliver on your tactical plans.  

What’s the heartbeat of business agility for your organization? 

Learn more about business agility: why you need it, and how to get it. Find out more about how good meetings help you take the pulse of your organization.

  Alex Pukinskis
Categories: Companies

Cancel Your Executive Status Meetings (Do This Instead)

Rally Agile Blog - Wed, 10/22/2014 - 14:00

Last week I met with a strategy leader for an Australian financial services organization, who was trying to work out how to bring his executive team together on a regular cadence to align around strategy. He’d built a great Kanban board to visualize the large strategic projects the organization was pursuing -- sort of an executive-level roadmap -- and wanted some ideas for how to bring execs together around it.

In my role I spend a lot of time promoting a quarterly, one-day, Agile business steering meeting that brings leaders together to align on strategic priorities and harmonize their quarterly tactics. I think that such a meeting really is the heartbeat of business agility at scale. But once you’re aligned around your intentions for the quarter, how do you steer within the quarter?  

I recommend thinking about three cadences. These include:

  1. A weekly, extended management “impediments” meeting
  2. A weekly executive staff meeting
  3. A bi-monthly metrics meeting
1. Weekly Extended Management Impediments Meeting 

This Scrum of Scrums (SoS) is a short standup meeting involving your extended management team, usually 20-40 people depending on your organization’s size. The purpose of this meeting is to bring junior and senior executives together across departments to raise and resolve impediments encountered on any top priorities.

This is not a status meeting, and indeed, if you have any meeting reporting red / yellow / green status on your tactical initiatives, cancel it right now; you’re wasting time. Initiatives are often green until they’re suddenly red, and by then it’s too late to do anything. Huge amounts of waste goes into producing beautiful status reports that obscure what’s actually going on.

We run the SoS meeting standing in two concentric circles. The inner circle (close to the conference table) is for anyone with important news or significant impediments that they need help with; they’re the ones who speak. The outer circle (against the wall) is for everyone else: they only listen, unless they want to offer help with an impediment. This meeting often lasts just a few minutes, and never more than 30. The group leaves when the inner circle is done and all impediments have been managed.  

an example of an executive meeting format with concentric circles

It can help to track the readouts from this meeting on a simple impediments board, logging recent results, issues, and actions, so that when people walk into the meeting they can quickly recall the context of the last meeting without taking up meeting time.

Just like team-level Scrum, a meeting like this needs a facilitative leader who can keep people focused, handle distractions, and help the group move to action. But at this level, your facilitator needs to be comfortable interrupting senior executives who are rambling. This requires a tricky balance. It can help to ask the group explicitly, “Do I have your permission to facilitate so we can get to results quickly?”

2. Weekly Executive Staff Meeting

It usually makes sense to hold the SoS meeting just before your standing (closed) executive staff meeting, because it gives your senior leadership team the pulse of the issues before doing a deeper dive on their own work. If you’re doing a meeting like this, keep it. If you’re not doing it, start one.

3. Bi-monthly Metrics Meeting

This meeting is a deep dive on key metrics for the business, and may last 1-2 hours. It usually begins with key financial results (revenue, cash flow, and whatever other macro business results make sense for your organization.) Then it dives deeper into your business improvement metrics.

If you’re doing strategy deployment well, you have tactics for improving your business results and leading indicators that tell you whether you’re making progress towards achieving your results. If you’re using a balanced scorecard, all this should be sounding familiar.  

On a regular two- or four-week cadence, your senior leaders should be able to dive deeply into these leading indicators so you can sense whether you need to steer your tactics. If you expected your pipeline to be twice as big in the current quarter, or if you’re seeing a growing backlog in a specific part of your business, you can take action to adapt in the coming business steering meeting. The metrics cadence gives you time to get ahead of this work, so you can steer tactically during your quarterly meeting.

Bringing It All Together

The quarterly meeting is essential to building alignment at this level; once you’re doing it, these three regular meetings enable to you to steer and deliver on your tactical plans.  

What’s the heartbeat of business agility for your organization? 

Learn more about business agility: why you need it, and how to get it. Find out more about how good meetings help you take the pulse of your organization.

  Alex Pukinskis
Categories: Companies

Bye, bye Oldie

tinyPM Team Blog - Wed, 10/22/2014 - 13:54

It already is! The new version of documentation in tinyPM. For those who like to wade through the jungle we left the good old one here. The brand new, more civilized edition, equipped with intuitive menus, which we have prepared using Grails, is available here (www.tinypm.com/docs/guide). We changed the design to a more modern, transparent and consistent color.

Success

Fast but not furious

Previous documentation of tinyPM had a one continuous layout. The new one has a division into sections. It’s easier to navigate as well thanks to the added menu, always displayed on the side. The documentation includes a description of:

tinyPM Docs

From Grails with love

The documentation is generated using the standard mechanism of Grails to create the documentation for the application. Check it out here: grails.org/doc/latest/guide/single.html#docengine. We adapted it to the very great needs of tinyPM to work on our own templates and css styles. The result? A completely different look, and underneath the same syntax wiki for quick and easy creation of documentation.

How do you like it? Are there any gaps, lacks or mistaken attacks? :-)

Categories: Companies

What is UX?

Growing Agile - Wed, 10/22/2014 - 12:09

On Monday Karen and I did a talk with Debre Barrett from Flow Interactive on What is UX? This was at the Scrum Gathering of South Africa. Our aim was to give teams a few techniques that they can use, and tp spread the word that the user should ALWAYS be involved.

The slides are on slideshare: http://www.slideshare.net/growingagile/what-is-ux-40577849

Categories: Companies

Paired Mathematics

Agile Tools - Wed, 10/22/2014 - 07:56

4404087460_9beb6332bd_b

This evening my daughter was sitting at the kitchen table, pencil in hand, confronting a full page of math homework. It was one of those dreadfull rote exercises where one has to solve variations on the same problem over and over again until either the exercises are complete or the child expires from boredom. I remember those math exercises, usually associated with the dictum to “Show your work” – meaning that every exercise would take what seemed like hours to complete. I’m breaking out in a cold sweat just thinking about it.

Nobody I know really likes these sorts of homework assignments. I guess they are a rite of passage in grade school. Seeing the dread in her eyes, I sat down and proceeded to just start talking her through it. It was all the usual stuff. I’d ask questions, and talk about different ways of solving the problem. I’d check her results and ask more questions. And I’d challenge her to do silly things (Write your numbers as tiny as you can. Smaller. smaller!). I’d stop and ask her how she did it, because Dad doesn’t know the new math (I really don’t – today they use all sorts of fun strategies that I never learned as a kid). And of course there was a high five at the end.

And then it occurred to me that we were pair programming!

Well, pair problem solving anyway. She was driving – doing the work. I was navigating, validating her work and thinking about how to tackle the next challenge. We had a dialog going on where we questioned each other. It turns out we both tend to make the same kinds of silly mistakes: like father, like daughter. I just see those mistakes better because I’m navigating, and I’m more experienced.

It seems a very similar pattern to what we do when we are pair programming. Someone is working on the problem, the other is verifying, asking questions, looking ahead. And both are very focused. It’s very intense – requiring full concentration. But, depending on who it is, it can be playful too.

That sounds like a nice way to work. Better than individually grinding away. Of course programming and math problems from grade school are very different things. But it made me wonder, is a place where we all pair a more pleasant place?


Filed under: Agile, practice Tagged: math, pair programming, pairing
Categories: Blogs

Was ist so cool an Timeboxing?

Scrum 4 You - Wed, 10/22/2014 - 07:37

In Scrum und Design-Thinking arbeiten wir eigentlich immer mit Timeboxing. Warum? Was ist so toll an Zeitbegrenzungen?

Wenn Sie einen alten Bekannten an der Bushaltestelle treffen und sagen: “Hey, mein Bus kommt in drei Minuten. Erzähl mir schnell, wie es Dir geht.” Dann können Sie sicher sein, dass er unter den vielen tausend Informationen automatisch die wenigen herauspickt, die er in diesem Moment für die wichtigsten hält. Sicher variieren die Informationen, je nachdem, wie Ihre Beziehung zueinander ist und wie er sich Ihnen gegenüber darstellen möchte. Aber in sekundenschnelle priorisiert Ihr alter Bekannter in der Gewissheit, dass Sie seine Informations-”Lieferung” bewerten werden. Und mit der Sicherheit, dass diese Situation für die nächsten drei Minuten stabil bleibt, dass Sie höflich zuhören und sich auf ihn einlassen werden.

Das machen wir uns auch in unserer täglichen Arbeit zunutze. In meiner Erlebniswelt gibt es drei Aspekte, warum ich Zeitbegrenzungen nicht mehr missen möchte:

  1. Lieferung
    Der wohl offensichtlichste Effekt ist, dass am Ende einer Timebox immer ein bewertbares Ergebnis steht. Am Ende eines Scrum-Sprints wird ein Produktinkrement geliefert. Am Ende einer Research Session steht Information bereit. Am Ende des Meetings stehen Entscheidungen oder ein Informationsaustausch. Und am Ende eines Brainstormings stehen viele Ideen. Die Zeitbegrenzung hilft dabei, die Arbeit zu planen, so dass die Arbeitspakete in die Timebox passen. Eine User Story muss so klein sein, dass sie innerhalb eines Sprints erledigt werden kann. Ein Prototyp muss so gestaltet sein, dass er innerhalb der Präsentations- oder Testzeit bewertet werden kann. Ein Teamtreffen bekommt eine Agenda, die in der bereit gestellten Zeit abgearbeitet werden kann. Das Schöne am Ende der Timebox ist, tatsächlich etwas geschafft zu haben. Und je kleiner die Timeboxen sind, desto häufiger kann man dieses schöne Gefühl genießen. Und sollte es am Ende einer Timebox einmal nicht die erwartete Lieferung geben, so ist auch das ein Ergebnis. Erinnern wir uns an das Sprichwort “lieber ein Ende mit Schrecken als ein Schrecken ohne Ende”. So wird auch aus diesem Ergebnis eine Chance. Die Chance, Dinge, die zu lange brauchen, zu beenden.
  2. Aufmerksamkeit und Fokus
    Mit der Zeitbegrenzung fokussieren wir uns ganz automatisch. Je kürzer die Timebox ist, je stärker der Zeitdruck im Nacken sitzt, desto eher lenken wir unsere Aufmerksamkeit auf die dringendsten Dinge. Stellen Sie sich eine Teenager-Party vor, die Eltern sind das ganze Wochenende verreist … Plötzlich: Es ist Samstag Abend, die Eltern rufen an. Sie kommen noch heute zurück und werden in einer Stunde zuhause sein! Was passiert im Kopf der Tochter / des Sohnes? Ein uraltes Überlebens-Programm springt an: Was dürfen die Eltern auf gar keinen Fall sehen? Und es wird sofort gehandelt! Zeitbegrenzungen lenken unsere Aufmerksamkeit und bringen uns ins Handeln. “Doing as a way of thinking” ist einer unserer Leitsätze bei Boris Gloger Consulting. Der wichtigste Schritt ist der erste! Je weniger Zeit wir haben, desto schneller müssen wir den ersten Schritt gehen.
  3. Stabilität
    Eine Timebox begrenzt in der Regel nicht nur einen Zeitrahmen. Wir legen für die begrenzte Zeit auch andere Rahmenbedingungen fest und schaffen eine stabile Umgebung. Dies ist einer der wichtigsten Aspekte, warum wir mit Scrum wieder Herr des Chaos werden können: In chaotischen und komplexen Umgebungen schaffen wir mit einem Sprint eine Blase der Stabilität. Für 2 Wochen sind die Anforderungen festgeschrieben, auch die benutze Technologie bleibt stabil. Rituale (Meetings) geben einen Rhythmus vor und damit die Sicherheit, dass die Grenzen morgen die gleichen sein werden wie heute. Es ist wie mit Kindern: Auch Kinder benötigen Grenzen, um Sicherheit, um Verlässlichkeit zu spüren, um den Rahmen zu füllen und sich geborgen zu entwickeln. In Scrum ist das der Rahmen, in dem Selbstorganisation wachsen kann. Mitarbeiter und Kollegen “wissen, woran sie sind”. Mit dem nächsten Sprint kann diese Blase der Stabilität natürlich neu positioniert werden, aber der verlässliche Rahmen bleibt immer. Gleiches gilt für kurze Timeboxen. In einer Ideation-Phase im Design-Thinking: Beispielsweise einigen wir uns für 20 Minuten darauf, dass wir die Aspekte der Machbarkeit oder Wirtschaftlichkeit nicht berücksichtigen. In diesem stabilen Rahmen können wir ernsthaft überlegen: “Wie würde Superman das Problem lösen?” oder “Wie funktioniert das auf Raumschiff Enterprise?”
Integration und Konsequenz

Mit großen Timeboxen könne Sie schnell Stabilität erzeugen und mit kurzen Timeboxen erhöhen Sie  schnell die Produktivität. Aber seien Sie vorsichtig: Es geht nicht darum, die Kollegen permanentem Stress auszusetzen. Vielmehr sollen sich Phasen hoher Konzentration und Phasen des Entspannens sinnvoll abwechseln. Achten Sie darauf, dass die Konzentrationsphasen maximal 90 Minuten lang sind und dann von einer Pause unterbrochen werden, die es erlaubt, die Aufmerksamkeit in eine ganz andere Richtung zu lenken.

Und noch ein letzter Hinweis: Zeitbegrenzungen müssen eingehalten werden, damit sie funktionieren! Das klingt einfacher als es ist. Wie Sie sich diese Aufgabe mit einem TimeTimer und einem Gong erleichtern können, lesen Sie in einem anderen Blogbeitrag.

Related posts:

  1. Timeboxing: Zeitdruck tut gut
  2. 15 Minuten sind 15 Minuten
  3. Die Lieferung eines ScrumMasters in sieben Schritten – was er wirklich tut und was nicht

Categories: Blogs

Edge of Tomorrow Today

Portia Tung - Selfish Programming - Tue, 10/21/2014 - 23:10

Love Your Life

Tom Cruise has been a continuous source of inspiration in my personal Agile journey in so many ways.

In Jerry Maguire, he emphasised the importance of “Show me the money!”, a quote I use whenever I talk about prioritisation by business value.

Then there are the diverse and dangerous missions he gets assigned to, to which he always responds with a purposeful smile and a gleam in his eye.

And now his latest film has proved to be the ultimate inspiration to people like us, agents of change for greater good.

The parallels between the hero’s conundrum in Edge of Tomorrow (aka Live Die Repeat) bears more than a canny resemblance to what many of us experience at work. Day after day after day. It’s no wonder then things eventually get us down.

That’s when I remember what Peter Drucker says, grand daddy of organisational culture. “Organisations form and deform people,” he said.

It seemed like such a bleak observation when I first heard it all those years ago, that I found myself boldly reply, “It takes two to tango. People allow themselves to be formed and deformed.”

I know that according to systems thinking a bad system beats good people every time, but what if those good people worked together to improve the system? To change the game for a better tomorrow?

I know how hard things can be when everything seems intent on catching you out or making you stumble.

In my experience, the trick is to keep playing when the going gets tough and make friends. Because you never know when you’ll need them. And a lifelong journey of change is best enjoyed in good company and laughter.

What if each of us could “re-set” and change the future by learning from each moment that passes?

Live. Love. Repeat.

Categories: Blogs

Is Your Culture Working the Way You Think it Is?

Johanna Rothman - Tue, 10/21/2014 - 17:14

Long ago, I was a project manager and senior engineer for a company undergoing a Change Transformation. You know the kind, where the culture changes, along with the process. The senior managers had bought into the changes. The middle managers were muddling through, implementing the changes as best they could.

Us project managers and the technical staff, we were the ones doing the bulk of the changes. The changes weren’t as significant as an agile transformation, but they were big.

One day, the Big Bosses, the CEO and the VP Engineering spoke at an all-hands meeting. “You are empowered,” they said. No, they didn’t say it as a duet. They each said it separately. They had choreographed speeches, with great slide shows, eight by ten color glossies, and pictures. They had a vision. They just knew what the future would hold.

I managed to keep my big mouth shut.

The company was not doing well. We had too many managers for not enough engineers or contracts. If you could count, you could see that.

I was traveling back and forth to a client in the midwest. At one point, the company owed me four weeks of travel expenses. I quietly explained that no, I was not going to book any more airline travel or hotel nights until I was paid in full for my previous travel.

“I’m empowered. I can refuse to get on a plane.”

That did not go over well with anyone except my boss, who was in hysterics. He thought it was quite funny. My boss agreed I should be reimbursed before I racked up more charges.

Somehow, they did manage to reimburse me. I explained that from now on, I was not going to float the company more than a week’s worth of expenses. If they wanted me to travel, I expected to be reimbursed within a week of travel. I got my expenses in the following Monday. They could reimburse me four days later, on Friday.

“But that’s too fast for us,” explained one of the people in Accounting.

“Then I don’t have to travel every other week,” I explained. “You see, I’m empowered. I’ll travel after I get the money for the previous trip. I won’t make a new reservation until I receive all the money I spent for all my previous trips. It’s fine with me. You’ll just have to decide how important this project is. It’s okay.”

The VP came to me and tried to talk me out of it. I didn’t budge. (Imagine that!) I told him that I didn’t need to float the company money. I was empowered.

“Do you like that word?”

“Sure I do.”

“Do you feel empowered?”

“Not at all. I have no power at all, except over my actions. I have plenty of power over what I choose to do. I am exercising that power. I realized that during your dog and pony show.

“You’re not changing our culture. You’re making it more difficult for me to do my job. That’s fine. I’m explaining how I will work.”

The company didn’t get a contract it had expected. It had a layoff. Guess who got laid off? Yes, I did. It was a good thing. I got a better job for more money. And, I didn’t have to travel every other week.

Change can be great for an organization. But telling people the culture is one thing and then living up to that thing can be difficult. That’s why this month’s management myth is Myth 34: You’re Empowered Because I Say You Are.

I picked on empowerment. I could have chosen “open door.” Or “employees are our greatest asset.” (Just read that sentence. Asset???)

How you talk about culture says a lot about what the culture is. Remember, culture is how you treat people, what you reward, and what is okay to talk about.

Go read Myth 34: You’re Empowered Because I Say You Are.

Categories: Blogs

Foundations of Excellence

Learn more about our Scrum and Agile training sessions on WorldMindware.com

I was thinking about the concept of becoming excellent at something.  My son is a budding artist.  He and I had a conversation a few months ago about talent or aptitude.  I said to him that I felt that aptitude is only latent: you need to put effort into something in order to expose your talent.  He was concerned that he didn’t have any aptitude because he had to work so hard to become better at drawing.  I compared him to myself and my brother, Alexei: when we were growing up, we both put a lot of effort into drawing.  Quickly, I fell behind my brother in skill.  He clearly had aptitude.  But he also put in a lot of effort into exposing that talent.  I was reminded of all this because my son is struggling with math.  He has aptitude, but he hasn’t put much effort into it.  I was wondering why?

Then I realized that aside from aptitude and effort, two more things need to be in place to achieve excellence: willingness and confirmation.

Willingness is the internal drive, usually motivated by an unconscious set of factors, but sometimes also coming from a strong conscious decision.  Willingness can come from unusual combinations of circumstances.  I was extremely willing to learn mathematics in my youth.  This came from two experiences.  One, in grade 2, was when my teacher told me that I shouldn’t be learning multiplication (my dad had taught me while on a road trip).  I was upset that I shouldn’t be able to learn something.  Then, in grade 3, I had a puppet called Kazir (a gift from my babysitter who told stories about space adventures with Azir and Kazir the Baha’i astronauts).  I brought Kazir to school one day and while doing math problems, I pretended that Kazir was helping me.  Suddenly I found math easy.  These two events plus a few others contributed strongly to my desire, my willingness to learn math.

Confirmation is the set of environmental factors that helps keep us on a path of learning.  These environmental factors are sometimes mimicked in the corporate world with bonuses and gamification, but these are really distant shadows of what confirmation is really about. Confirmation is when the stars align, when everything seems to go right at just the right time, when the spirit inspires and moves you and the world to be, in some way, successful.  The trick about confirmation is that success is not usually about monetary success.  It’s usually about social, relational or even sacrificial success.  As an example, when I was in grade 7, I was chosen with a small group of people in my class to do accelerated math studies.  This was a great honour for me and was a confirmation of my interest in math.

In organizational change, and in particular in changing to an Agile enterprise, we need to be aware that excellence requires that these four factors be in place.  Aptitude is, to some degree, innate.  We can’t trick people to have aptitude.  If someone is just fundamentally bad at a certain thing, despite vigorous educational efforts, then that person likely doesn’t have the aptitude.  Effort is about both having time and resources, but also, then about willingness.  And willingness, in turn, can only be sustained with confirmation.  Too much discouragement will break a person’s willingness.  The Agile enterprise requires a great number of skills and abilities that are not normally part of a person’s work environment prior to attempting to adopt Agile.  Keeping these four things in mind can help people in an organization to reach excellence in Agility.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail
Categories: Blogs

TDD and Asychronous Behavior

NetObjectives - Tue, 10/21/2014 - 15:39
Test-Driven Development posits that all behaviors in a system should be specified in tests. Sometimes this appears to be challenging either because the system has design flaws that make it hard to test, or because the technique needed to create the tests is not immediately clear. Sometimes it is a bit of both. At our blog Sustainable TDD, Amir Kolsky and I have outlined the techniques needed for...

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

Do we need a Tech Lead?

thekua.com@work - Tue, 10/21/2014 - 12:03

A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.

Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.

Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.

Tabs Spaces
Image take from Emacswiki

The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.

Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.

When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Categories: Blogs

Best Practices for a Culture of Continuous Improvement

TV Agile - Tue, 10/21/2014 - 09:14
Doing Kanban for the sake of doing it is unsexy and has usually rather low value. Introducing Kanban means working towards the vision of a culture of continuous improvement. Surprisingly, the cultural change does not happen magically after a change agent pushed the practices of Kanban into a company. The cultural change already starts by […]
Categories: Blogs

Fighting Prejudices Against Agile

DevAgile.com - Tue, 10/21/2014 - 08:35
Adopting new software development approaches like Agile and Scrum is always a challenge. There is a natural tendency for part of an organization to resist changing and some prejudices exist against Agile, mainly due to a lack of knowledge.
Categories: Communities

Time After Time

Agile Tools - Tue, 10/21/2014 - 08:07

4e616845-2d64-4eb8-85ab-7f5dcdbab12d

Last year I led an effort to implement time tracking for our teams. A quick warning is probably in order here:

Never, ever, be the person who introduces time tracking at a company. You will be reviled before the gods and your name shall be stricken from the roles of the Agile. People will avoid you at parties, your kids will spurn you, and your pets will pee in your shoes. On the bright side, that Darth Vader helmet you have sitting in the closet will suddenly seem like a good thing to wear around the office.

So, now that we have that out of the way, back to our story. So I was leading this effort to introduce time tracking to all of the developers in our little corner of the company. The idea that had lead to this little misadventure was simple enough: if we used a time tracking tool we will get more detailed information about where time is being spent on projects than if we just make some educated guesses using excel spreadsheets (our existing mechanism). This will give us higher quality information and we will enable us to automatically handle things like capitalization easily.

That was the idea. If we ask people to report their time daily, they will give us a more accurate picture of the time that they are spending on the work. Simple enough. Our old system of excel spreadsheets made a lot of assumptions that probably weren’t true. For example:

  • Everyone works an 8 hour day
  • Everyone on a team works on a given project at the same time
  • Team membership doesn’t change during the sprint

If you use those rules then you can come up with some rough estimates for how many hours the team put into any given project on a sprint by sprint basis. You have to assume that any errors or mistakes will just be averaged out over time. That makes the time tracking very simple to do, but it makes the finance guys twitchy. They get anxious because you are making a lot of assumptions about things that we all know probably aren’t true. And they really don’t like that “It all kinda works out on average” bit either.

So we decided to go down the path of detailed time tracking. Give up all hope ye who enter here. Detailed time tracking doesn’t assume much: every hour of the day must be accounted for. However there is one hidden assumption:

  • Everyone will bother to take the time to accurately report their time for every day.

And there’s the rub. Very few people actually report their time accurately. First, you have to understand that they are ticked off that they are even asked to enter time. Second, they are very likely already entering their time in other places, like agile project management tools, HR vacation tracking tools, contractor management tools, etc. A single person might have to enter their time in 4 different systems! All you have done is add one more tool to the list and it is definitely not welcome.

So how do they use it? They either book all 8 hours of their day to the project and copy and paste every day, or they take one example day and copy and paste that. You aren’t going to get the real data, because the people using the system don’t really want to give it to you. At the end of a long day, nobody wants to have to sit down and try and figure out how much of their day was wasted in all those godawful meetings. They just don’t.

Oh, I suppose you could try policing it better – good luck with that.

You might come away from this little diatribe with the impression that I dislike time tracking. That’s not true. I realize there is a legitimate need for it in our business. However implementing it is much tougher than I realized and it’s very easy to find that the benefits really aren’t that clear at the end of it all.


Filed under: Agile, Process Tagged: benefits, time tracking
Categories: Blogs

Der krumme Ski oder wie Scrum in die Hardware zurückkam

Scrum 4 You - Tue, 10/21/2014 - 07:45

Könnt ihr euch noch an diese geraden Ski-Bretter erinnern, die schier nicht mehr zu bewältigen waren, wenn sie eine gewisse Länge überstiegen? Nur mit viel Kraft und technischem Geschick kam man heil den Berg hinunter.

1870 wurde in Norwegen der Carving-Ski erfunden und obwohl er deutlich leichter zu lenken war, konnte er sich am Markt (zunächst) nicht durchsetzen. Anfang der 1990er hatte jemand die Idee, dass es doch lustiger wäre, auf nur einem Brett zu rutschen, und hat das Snowboard erfunden. Den Berg auf einem stylischen und wendig geschnittenen Board hinabzugleiten, hat viel mehr Spaß gebracht, als sich mit diesen langen Ungetümen von Skiern abzuquälen. Skifahren war plötzlich was für unicolore Langeweiler, Snowboarden was für die coolen Bunten. Die Ski-Industrie geriet unter Druck. Als Reaktion darauf wurde begonnen, Skier – ebenso wie Snowboards – an den Enden breiter und in der Mitte schmaler zu machen. Wiedergeboren war der Carving-Ski, der den Skisport neu belebte. Denn ein Carving-Ski ist leichter zu lenken, ist wendiger und macht mehr Spaß, auch ohne viel Kraft einsetzen zu müssen.

Ganz ähnlich befruchten sich die Entwicklungsprozesse in der traditionellen Fertigungsindustrie (Hardware) und in der digitalen Welt der Software-Industrie. Die ersten Erfahrungen mit agilen Methoden wurden in der Flugzeugindustrie bereits 1943 gemacht, als die Alliierten eine schnelle Antwort auf die deutsche ‘Wunderwaffe’ brauchten. Zu Beginn wurde Software genau wie Hardware nach dem Engineering-Ansatz entwickelt: Plan – Design – Implement – Test – Wasserfall. Das war erfahrungsgemäß unzuverlässig in der Planung, teuer und vor allem hat es lange gedauert, bis man Feedback zu Entscheidungen bekam. Daher ist die Software-Industrie auf Scrum und andere agile Methoden umgestiegen und hat begonnen, ihre Produkt in Inkrementen zu entwickeln. Feedback wurde so nach jedem Schritt eingeholt und am Ende gab es ein Produkt, das wirklich einen Mehrwert lieferte. Und mehr Spaß macht es auch noch, weil die Entwickler selbstbestimmter arbeiten und in besserer Qualität produzieren können.

Das hat die hardwareproduzierende Industrie, aus Branchen wie Medizintechnik und Automotive, neugierig gemacht. Durch immer kürzere Innovationszyklen im Markt stoßen sie mit klassischen Projektsteuerungsmethoden bei der Umsetzung an Grenzen. Dank moderner Prototyp-Technologien lassen sich Ideen immer schneller in greifbare Ergebnisse verwandeln, mit denen Erfahrungen gemacht werden können. Der Weg zur Nutzung von Scrum ist frei und wird immer freier.
Mit Scrum ist jetzt auch die Hardware-Industrie wendiger und es braucht weniger Krafteinsatz, um Projekte erfolgreich umzusetzten. Und wer weiß, vielleicht verabschieden sie sich ja auch vom unicoloren blue-collar und werden bunter  ;-)

Related posts:

  1. Brief an einen jungen Projektmanager
  2. Der Wille zur Lieferung Von Franz Zauner / WZ Online
  3. Agile Hardwareentwicklung mit Scrum

Categories: Blogs

Neo4j: Modelling sub types

Mark Needham - Tue, 10/21/2014 - 01:08

A question which sometimes comes up when discussing graph data modelling is how you go about modelling sub/super types.

In my experience there are two reasons why we might want to do this:

  • To ensure that certain properties exist on bits of data
  • To write drill down queries based on those types

At the moment the former isn’t built into Neo4j and you’d only be able to achieve it by wiring up some code in a pre commit hook of a transaction event handler so we’ll focus on the latter.

The typical example used for showing how to design sub types is the animal kingdom and I managed to find a data set from Louiseville, Kentucky’s Animal Services which we can use.

In this case the sub types are used to represent the type of animal, breed group and breed. We then also have ‘real data’ in terms of actual dogs under the care of animal services.

We effectively end up with two graphs in one – a model and a meta model:

2014 10 20 22 32 31

The cypher query to create this graph looks like this:

LOAD CSV WITH HEADERS FROM "file:/Users/markneedham/projects/neo4j-subtypes/data/dogs.csv" AS line
MERGE (animalType:AnimalType {name: "Dog"})
MERGE (breedGroup:BreedGroup {name: line.BreedGroup})
MERGE (breed:Breed {name: line.PrimaryBreed})
MERGE (animal:Animal {id: line.TagIdentity, primaryColour: line.PrimaryColour, size: line.Size})
 
MERGE (animalType)<-[:PARENT]-(breedGroup)
MERGE (breedGroup)<-[:PARENT]-(breed)
MERGE (breed)<-[:PARENT]-(animal)

We could then write a simple query to find out how many dogs we have:

MATCH (animalType:AnimalType)<-[:PARENT*]-(animal)
RETURN animalType, COUNT(*) AS animals
ORDER BY animals DESC
==> +--------------------------------+
==> | animalType           | animals |
==> +--------------------------------+
==> | Node[89]{name:"Dog"} | 131     |
==> +--------------------------------+
==> 1 row

Or we could write a slightly more complex query to find the number of animals at each level of our type hierarchy:

MATCH path = (animalType:AnimalType)<-[:PARENT]-(breedGroup)<-[:PARENT*]-(animal)
RETURN [node IN nodes(path) | node.name][..-1] AS breed, COUNT(*) AS animals
ORDER BY animals DESC
LIMIT 5
==> +-----------------------------------------------------+
==> | breed                                     | animals |
==> +-----------------------------------------------------+
==> | ["Dog","SETTER/RETRIEVE","LABRADOR RETR"] | 15      |
==> | ["Dog","SETTER/RETRIEVE","GOLDEN RETR"]   | 13      |
==> | ["Dog","POODLE","POODLE MIN"]             | 10      |
==> | ["Dog","TERRIER","MIN PINSCHER"]          | 9       |
==> | ["Dog","SHEPHERD","WELSH CORGI CAR"]      | 6       |
==> +-----------------------------------------------------+
==> 5 rows

We might then decide to add an exercise sub graph which indicates how much exercise each type of dog requires:

MATCH (breedGroup:BreedGroup)
WHERE breedGroup.name IN ["SETTER/RETRIEVE", "POODLE"]
MERGE (exercise:Exercise {type: "2 hours hard exercise"})
MERGE (exercise)<-[:REQUIRES_EXERCISE]-(breedGroup);
MATCH (breedGroup:BreedGroup)
WHERE breedGroup.name IN ["TERRIER", "SHEPHERD"]
MERGE (exercise:Exercise {type: "1 hour gentle exercise"})
MERGE (exercise)<-[:REQUIRES_EXERCISE]-(breedGroup);

We could then query that to find out which dogs need to come out for 2 hours of hard exercise:

MATCH (exercise:Exercise {type: "2 hours hard exercise"})<-[:REQUIRES_EXERCISE]-()<-[:PARENT*]-(dog)
WHERE NOT (dog)<-[:PARENT]-()
RETURN dog
LIMIT 10
==> +-----------------------------------------------------------+
==> | dog                                                       |
==> +-----------------------------------------------------------+
==> | Node[541]{id:"664427",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[542]{id:"543787",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[543]{id:"584021",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[544]{id:"584022",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[545]{id:"664430",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[546]{id:"535176",primaryColour:"BLACK",size:"SMALL"} |
==> | Node[567]{id:"613557",primaryColour:"WHITE",size:"SMALL"} |
==> | Node[568]{id:"531376",primaryColour:"WHITE",size:"SMALL"} |
==> | Node[569]{id:"613567",primaryColour:"WHITE",size:"SMALL"} |
==> | Node[570]{id:"531379",primaryColour:"WHITE",size:"SMALL"} |
==> +-----------------------------------------------------------+
==> 10 rows

In this query we ensured that we only returned dogs rather than breeds by checking that there was no incoming PARENT relationship. Alternatively we could have filtered on the Animal label…

MATCH (exercise:Exercise {type: "2 hours hard exercise"})<-[:REQUIRES_EXERCISE]-()<-[:PARENT*]-(dog:Animal)
RETURN dog
LIMIT 10

or if we wanted to only take the dogs out for exercise perhaps we’d have Dog label on the appropriate nodes.

People are often curious why labels don’t have super/sub types between them but I tend to use labels for simple categorisation – anything more complicated and we may as well use the built in power of the graph model!

The code is on github should you wish to play with it.

Categories: Blogs

Knowledge Sharing


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