Skip to content

Feed aggregator

Einer von uns beiden spinnt – ich bin mir nur nicht sicher, ob du oder ich

Scrum 4 You - Thu, 11/27/2014 - 08:59

Sehr geehrte Leser und Leserinnen, ich hoffe Sie sitzen gut, Ihre Rückenlehne ist aufrecht und Sie sind angeschnallt. In diesem Beitrag bewegen wir uns nämlich durch die Turbulenzen der Emotionen. Zumindest schneiden wir diese kurz an, für viel mehr reicht so ein Blog leider nicht aus.

In meiner Arbeit mit Menschen in den letzten Jahren und in meinen privaten Beziehungen ging mir dieses, in der Überschrift erwähnte Statement schon unzählige Male durch den Kopf. Erleichtert bin ich darüber, dass die erweiterte Form die schlichte Formulierung “Der spinnt“ abgelöst hat. Daran merke ich, dass die Jahre der Reflexion nicht spurlos an mir vorbeigegangen sind. Denn die Frage, wer spinnt und wer also die betreffende Situation vollkommen falsch einschätzt, ist nicht so einfach und oft nur mit “es kommt drauf an” zu beantworten.

Die Krux liegt in den unterschiedlichen Bedürfnissen, An- und Absichten einzelner Menschen. Diese entstehen durch Prägungen aus unserer Vergangenheit. Psychologen haben dazu ein gut gehütetes Geheimnis, dass ich Ihnen heute verrate und dass Ihnen vielleicht ein langwieriges Psychologiestudium erspart: Jeder Einzelne von uns ist, auch als Erwachsener, nur ein kleines verletztes Kind. Es gibt alte Muster, die heute noch immer wirken, und die sich auf unsere (Arbeits-)beziehungen verheerend auswirken können. So hat das Kind, dessen Eltern Abends zu spät nach Hause kommen, irrsinnige Verlustängste entwickelt und wird so als Erwachsener möglicherweise zutiefst verletzt sein, wenn ein von ihm geschätzter Kollege zu einem bestimmten Arbeitstermin nicht erscheint. Die übertragene Emotionalität aus der Kindheit wird dann die Arbeitsbeziehungen zwischen diesen Personen belasten. So viel zur schlechten Nachricht.

children-drawing-375615_1280

Kommen wir nun zur guten Nachricht: Jeder Einzelne von uns Menschen hat die Möglichkeit, diese Muster zu verändern. Einzige Voraussetzung dafür ist, dass wir uns diese alten Muster eingestehen und sie akzeptieren. Mit der Akzeptanz kommt auch die Lösung.

Wie kommt man aber an diese Muster heran? Eigentlich ganz einfach und daher unheimlich schwer und langwierig: Reflektieren Sie und seien Sie dabei ehrlich zu sich selbst. Methoden gibt es unzählige. Meditieren Sie, gehen Sie ins Kloster oder in Supervison (falls Ihnen der Begriff Psychotherapie zuviel Angst macht). Wenn Ihnen das jetzt zu anstrengend ist, kann ich als Motivation noch vom Goldtopf am Ende des Regenbogens erzählen, der auf Sie wartet, wenn Sie diesen Weg gehen: Sie erhalten Freiheit. Die wirkliche und wahrhafte Freiheit zu entscheiden, was Ihnen gut tut. Sie befreien sich davon, Dinge tun zu müssen, weil Sie ein inneres unbefriedigtes Bedürfnis nach Anerkennung, Wohlstand, Macht oder Beziehungen haben. Dadurch gewinnen Sie eine Lebensqualität, die Ihnen anders nie zuteil werden kann und Sie bekommen die Möglichkeit, Ihr Leben mit einem wachen Auge zu betrachten.

Um den Kreis zu schließen: Wenn Sie das nächste Mal wieder sagen wollen „Der spinnt”, werden Sie vielleicht darüber nachdenken können, welches Bedürfnis bei Ihnen gerade nicht erfüllt wird und welches Bedürfnis beim anderen gerade getriggert wird. Und mit diesem Verständnis der Situation können Sie auch Lösungen für Ihre Beziehungen finden, die Ihnen anders nie zugänglich wären.

In diesem Sinne hoffe ich, Sie haben den Flug gut überstanden und ich entlasse Sie durch die Kabinentür wieder ins Freie. Welchen Weg Sie nun wieder einschlagen, bleibt Ihnen überlassen, aber vielleicht hinterfragen Sie zukünftig, WARUM Sie genau jenen Weg einschlagen wollen. Damit gewinnen Sie ein wenig mehr Freiheit für sich.

Categories: Blogs

About importance of reading

AgileEspresso - Davide Noaro - Thu, 11/27/2014 - 01:13
“We badly need to incentivize listening. And online, listening = reading. That old school program from my childhood was right, so deeply fundamentally right. Reading. Reading is Foundamental. Let’s say you’re interested in World War II. Who would you rather have a discussion with about that? The guy who just skimmed the Wikipedia Article, or […]
Categories: Blogs

5 Tips to Become a Top Agile Blog

Ben Linders - Wed, 11/26/2014 - 10:09
I'm blogging: to share my learnings to help my readers to learn and become better in what they are doing. Luis Gonçalves published a list of 100+ top Agile Blogs and this blog is listed! It feels great to be among the worlds top blogs on software development, a big thanks to all my readers who made this possible! Success doesn't come for free, I've learned along the way how to become better in blogging by doing it and reflecting. If you want to get your blog on the 100+ top agile blogs list, here are 5 tips to improve your blog and get more happy readers. Continue reading →
Categories: Blogs

Inspired & Required – Wooga: Ansporn mit Feelgood-Spirit und Schlafkojen

Scrum 4 You - Wed, 11/26/2014 - 08:55

Feelgood-Teams, ein eigener Unternehmens-Koch, Job-Ticket für die Öffis, Home-Office oder Ruhekojen: Dass es mittlerweile mehr braucht als nur geregelte Arbeitszeiten und 30 Urlaubstage, um qualifizierte Mitarbeiter bei der Stange zu halten, haben viele Unternehmen bereits gemerkt. Es passiert was in den Unternehmenskulturen. Bestehende Strukturen werden umgekrempelt, damit die Mitarbeiter motiviert zur Arbeit kommen.

In unserer Serie „Inspired & Required“ wollen wir Unternehmen vorstellen, die ein bisschen innovativer aufgestellt sind als andere und besonders ungewöhnliche Maßnahmen ergreifen, um auf diese Weise ihren Mitarbeitern zu helfen, ihren Job gut zu machen. Den Anfang machen wir heute mit Wooga (http://www.wooga.com/) aus Berlin. Die Softwareentwickler für Mobile Games erfinden und gestalten weltweit erfolgreiche Spielekonzepte für Handy, Facebook und Co. und bringen mehr als 250 Mitarbeiter aus 40 Nationen unter ein Dach.

Obwohl Wooga schon lange kein kleines Startup mehr ist, hat es sich die Strukturen eines solchen bewusst bewahrt. Denn das große Ganze setzt sich aus kleinen Game-Teams zusammen, die wiederum handeln können wie agile Startups. In jedem einzelnen organisieren und gestalten bis zu 10 Köpfe ein eigenes Projekt und treffen bis zum Schluss jede einzelne Entscheidung selbst. Seit zwei Jahren gibt es bereits ein Feelgood-Team im Unternehmen, das sich ganz besonders um Neuzugänge aus dem Ausland kümmert. Wooga hilft nicht nur bei der Integration ins Unternehmen, sondern greift auch bei mühsamen Behördengängen unter die Arme, genau wie bei der Wohnungssuche. So können Neuankömmlinge erst mal 6 Wochen in einer Übergangswohnung bleiben, die von Wooga organisiert und bezahlt wird. Denn: Je schneller der Mitarbeiter sich angekommen fühlt, desto schneller packt er auch konzentriert seine Arbeit an.

Ein weiteres wichtiges Thema ist die soziale Vernetzung der einzelnen Mitarbeiter. Regelmäßig werden Neuzugänge zum Pizzaessen mit dem Management-Team eingeladen, damit man sich kennenlernen kann. Beim monatlichen Mystery-Lunch beispielsweise wird ein Tisch immer von vier Leuten geteilt, die sonst nicht so viel miteinander zu tun haben. So schauen alle mal über den eigenen Tellerrand hinaus und bekommen einen Einblick in das, was die anderen eigentlich so machen. Dem Unternehmen ist zudem wichtig, auch langfristig mit der Konkurrenz mitzuhalten. Den Schlüssel dazu sieht Wooga in seinen Mitarbeitern und stellt jedem von ihnen jährlich ein großzügiges Weiterbildungsbudget zur Verfügung, das an zwei vollen Tagen im Jahr zur persönlichen Ausbildung genutzt werden kann.

Und das ist noch lange nicht alles: Um jederzeit fit für wichtige Entscheidungen zu bleiben, gibt es bei Wooga Ruhekojen, welche die Mitarbeiter für einen kurzen Powernap nutzen können, wenn das Gehirn mal nicht so arbeitet, wie es sollte. Und hat man mal keine Lust, immer nur Spiele zu entwickeln, kann man sich auch im Game Room eine Auszeit nehmen und selbst ein paar Spiele zocken, bis man wieder auf klare Gedanken kommt.

Wooga gehört mit seinem Konzept sichtlich zu den Vorreitern, die sich rasch der wandelnden Arbeitswelt angepasst haben, um auch in Zukunft nur die besten Talente bei sich im Team begrüßen zu dürfen. Mit seiner Feelgood-Strategie schafft das Unternehmen genau die kreative Umgebung, die ihre Mitarbeiter brauchen, um gute Online-Spiele zu erschaffen.

Drei Fragen an Gitta Blatt, Head of People bei Wooga

Gibt es bei Wooga ein spezielles Arbeitszeitenmodell?
Wooga setzt beim Thema Arbeitszeiten auf Vertrauen, da wir davon ausgehen, dass jeder unserer Mitarbeiter persönlich für sich erfolgreich sein möchte. Produktivität ist bei uns wichtiger als reine Anwesenheit. Es gibt in unserem Arbeitsalltag gewisse Ankerpunkte in Form der zwei täglichen Stand-up-Meetings um 9:30 und 18:00, bei denen auch die meisten Teammitglieder anwesend sind. Aber grundsätzlich entscheiden unsere Mitarbeiter selbst, wann sie kommen und gehen.

Wie kommt Wooga auf so kreative Ideen wie den Mystery-Lunch oder die Ruhekojen?
Bei uns wird nichts wirklich geplant. Jeder darf seine Ideen beitragen, das ist wie ein riesengroßes Brainstorming. Ideen, die viele gut finden, werden im Kleinen ausprobiert. Wenn diese funktionieren und auf Anklang stoßen, werden sie etabliert.

Warum sind agile Methoden vor allem in der Softwareentwicklung so populär?
In der Softwareentwicklung herrscht ein hohes Tempo an Innovation und Veränderung. Etwas, das man zu Beginn eines Projekts geplant hat, kann im Laufe der Entwicklung an Aktualität verlieren. Unsere Produkte sind eigentlich nie wirklich fertig, denn die Ergebnisse müssen immer weiter verbessert werden und dafür ist ein hoher Grad an Flexibilität nötig. So ist z. B. ein Spiel von Wooga auch nach der Fertigstellung und dem eigentlichen Launch ein Service, der weiter gepflegt und entwickelt werden muss.

Categories: Blogs

Applying the Agile Manifesto to Mobile Testing

Scrum Expert - Tue, 11/25/2014 - 20:35
If we often associate Agile mainly with project management, the principles of the Agile Manifesto can also be applied to other software development activities. In this article, Nadya Knysh explains how to use these principles in mobile software development and more specifically in the testing of mobile apps. Author: Nadya Knysh, A1QA, http://www.a1qa.com/ The beginning of this century was marked by the birth of a document that has strongly influenced software development: the Agile Manifesto. Signed by 17 software developers in February of 2001, this document presents a list of ideas that ...
Categories: Communities

Quick Retrospective

Scrum 4 You - Tue, 11/25/2014 - 08:25

The Retrospective meeting is one of the six meetings in Scrum. The main purpose of this meeting is to get an overview of the last sprint. The Development Team has the opportunity to reflect on the process and to identify the advantages and disadvantages of the current sprint and its work procedures.

I would like to introduce you to four different types of a quick retrospective, especially focused on teams who are participating in this type of meeting for the first time. It is common that team members are not really willing to open up and express their feelings, problems, experiences at the first couple of times. Therefore, only the Scrum-Team (DevTeam, SM, PO) is allowed in that meeting, others can only join with the DevTeam’s permission. It is a learning process and the team has to adapt to this new environment of openness. However, every team is more than welcome to use these methods regularly and for other intentions, eg. a short retrospective after every meeting to analyse how helpful and productive it was. A retrospective after a sprint review would give an insight on how stakeholders experienced the meeting.

Rocket Retrospective
  • Outcome: Quick self-awareness
  • Timebox: 15 minutes
  • Material: Marker, post-its, paper cards

Procedure
It is important that you limit the time to your time box and do not extend any parts of the meeting.
The first step is called “Appreciation” and it should not take longer than five minutes because your DevTeam members just have to write down all the positive changes that had an impact on them and their project.

The second step is referred to “Collection of Information”. Every team member gets a card and a pen and he/she has to write down something that should be implemented or something that should be eliminated. Additionally, it is necessary that the person explains what exactly the problem is, why it is a problem and what are the benefits if it is implemented/eliminated. The members have to finish this task within five minutes. Afterwards, all cards are put upside down on a table, so nobody can see what is written on them. Once all cards are on the table the ScrumMaster collects and shuffles the cards.

The last step is termed “Making a Decision”. Each team member has to pick up one card of the table and take “ownership” of it. Then he/she has to write at least one proposal of action on the back of the note. It could be something as simple as writing an email or meet with another team member for 10 minutes two times a week, etc. Once everybody has finished this task, they present their card one by one with the issues and proposed follow-up actions. If some cards are similar those team members get together and put their solutions together on the back.

The ScrumMaster should keep the cards and put them on a whiteboard for everybody to see. The ScrumMaster has to bring the cards at the next retrospective for the participants to give appreciation on them.

Gifts & Hooks
  • Outcome: Participants will discover their colleagues’ strengths and expectations
  • Timebox: 15-30 minutes
  • Material: Pen and paper

Procedure
The participants have to write down their strengths on paper within 10 minutes. Their strengths are called gifts because they have to list how they could contribute to the project to make it successful. Afterwards every participant has to list every ‘hook’, which are all the things that stand in their way to work more efficiently. At the end everybody shortly presents their list and then the discussion can start on how to remove those hooks preferably.

Genie in a Bottle
  • Outcome: Intuition for urgent problems
  • Timebox: 15-20 minutes
  • Material: Flip chart and pens

Procedure
The team tracked down an ancient bottle. A genie appeared when they opened it. The genie told the team that he/she will grant them three wishes regarding changes at their workplace. And the genie will fulfil them. Now the team splits up into groups of three and list their three wishes on a flip chart and hangs it on the wall for everyone to see. Every team explains why they think those three wishes are the most important ones . The ScrumMaster asks the participants what needs to change for the wishes to become true. Now the SM has a list of the most urgent impediments he/she has to take care of. The charts will be presented at the next retrospective again to see if anything has changed in the meantime.

Hot-air Balloon
  • Outcome: Identify things that influence the work flow
  • Timebox: 15 minutes
  • Material: Pens, post-its, whiteboard

Procedure
The ScrumMaster should draw a hot-air balloon on the whiteboard and then ask the participants to write notes and stick them on the following areas: fire, hot air, and forces pulling down. The team has to identify what helps them to go higher and what pushes the project forward by placing those post-its on fire and hot air. Meanwhile, the things that hinders them to work productively are the forces pulling them down. This should not take more than five minutes. Then the team has 10 minutes left to discuss the issues.

ballon-106920_1280

Categories: Blogs

Agile Tour Bangkok, Bangkok, Thailand, November 29 2014

Scrum Expert - Mon, 11/24/2014 - 18:17
The Agile Tour Bangkok is a one-day event focused Agile software development and Scrum. The main objective of this conference is to promote to the Thai software development community. Local and international Agile practitioners will share their rich experiences. In the agenda of Agile Tour Bangkok you can find topics like “Enterprise Scaling Strategy”, “Agile Business (Transform Your Organization Through Agile)”, “The Principles Of Agile Metrics”, “Agile and Waterfall from the view of Plato and Aristotle”, “Practical Guide for First Time Product Owners”, “Do and Don’t for Continuous Delivery”, “Agile ...
Categories: Communities

Friendly Rivalry in the Silicon Desert Part 2

About SCRUM - Hamid Shojaee Axosoft - Mon, 11/24/2014 - 17:26

If you haven’t already, read Part 1 of the Friendly Rivalry in the Silicon Desert.

Out of the blue, on October 21st, AppointmentPlus initiated a new challenge: a flag football face off!

flag football challenge

Our fearless leader Hamid Shojaee did not hesitate to respond, “We never back down from a challenge. So it’s on!” And after some intense pre-game smack talking, the game was on!

Take a look at the pre-game coverage on AZTechBeat.

axosoft flag fooball team

Was this the biggest upset in AZ Tech Flag Football history? That’s not for me to decide. We heard guys like Steve Booze saying they were going to beat us 77-0 and that we shouldn’t even show up. We don’t pay too much attention to that junk. We were prepared, we had a game plan and we executed it. We may not be the most impressive team on paper, but the game isn’t played on paper, it’s played on the field. Axosoft is a team, a unit, not a bunch of individuals looking to make a name for themselves. You think guys like Mike Parrish put in the extra reps to be on the cover of the Mr. Software calendar? No – that’s just a bonus. Do you think Gustavo Figueroa became the most popular flag futbol player in all of Mexico by worrying about his stats? Of course not. When you have a bench as deep as ours, it makes the coach look really good. Not many teams can grab a camera man and an accountant and expect them to make plays like Shane and Jessica did. Am I disappointed we didn’t win? Of course. But we were the ones with the ball, with no time on the clock and the opportunity to win the game.

Although we tied, 20-20, we’re happy to report that the rivalry match ended sharing good beer with good company :)

football teams unite

Check out the game footage below!

Categories: Companies

Friendly Rivalry in the Silicon Desert Part 1

About SCRUM - Hamid Shojaee Axosoft - Mon, 11/24/2014 - 17:21

A little friendly competition has been unfolding over the past few months between Axosoft and neighboring AZ tech company AppointmentPlus – or AppointmentMinus as we like to affectionately refer to them. It all started back in August when AppointmentPlus challenged Axosoft to the ALS Ice Bucket Challenge. This was certainly the thing to do at the time, and nearly all Axosoft employees had already completed the challenge. In good spirit, our company donated $1,000 to the ALS cause and planned our response to AppointmentPlus.

Footage from Axosoft’s Nerf attack on AppointmentPlus

As seasoned Nerf-war veterans, we decided the only appropriate response was to attack the AppointmentPlus headquarters with Nerf guns blazing. The AxoWarriors charged into AppointmentPlus showing no mercy on the AP employees. The battle raged on for what must have seemed like an eternity for the majority of AP employees who did not even attempt to fight back. Ultimately Axosoft reigned victorious and disappeared nearly as quickly as we had come – except this time with many hostages in tow.

Media coverage from Tishin Donkersley, AZTechBeat

Over the next days and weeks we admittedly taunted AppointmentPlus with hostage photos in hopes to initiate negotiations for beer and wine in exchange for returning the stuffed-animal hostages. AppointmentPlus had no intentions of engaging in our hostile negotiation tactics. Eventually we returned the hostages, and the rivalry shenanigans settled into nothingness for several months.

appointmentplus hostage

And then… Friendly Rivalry in the Silicon Desert Part 2

Categories: Companies

News update 2014/11 – Here Be Dragons – Scaling Agile

ScrumSense.com - Peter Hundermark - Mon, 11/24/2014 - 16:49

Serpents and DragonsPeter Hundermark has shared the slides of his presentation, “Here Be Dragons – Scaling Agile“, from the global Scrum Gathering in Berlin and the regional Scrum Gathering in Cape Town.

The presentation focuses on the structural and process dimension of scaling agility. Peter describes 3 “laws” of scaling and sets out 10 patterns that he has found helpful over the years as a consultant and coach.
 
 
 

Interesting Links Interesting Links Momentum BTS Momentum BTS have embarked on a journey of learning and innovation by introducing Kanban as a way of managing their work. They have posted a short video on YouTube illustrating the impact these changes have had on their teams. Scrum Sense has had the privilege of being a part of this journey.

 

InfoQ have also published an article on Momentum’s adoption of Kanban. Discover the reasoning behind their journey and how they went about implementing the changes.

 

Scrum Gathering South Africa Karen & Sam of Growing Agile, interviewed attendees of the October 2014 Scrum Gathering in Cape Town and have created a very cool video of which sessions they enjoyed most and what they learnt.

 

 

Upcoming Courses

 

Certified Scrum Master (JHB)
01-02 Dec 2014 – Fully booked!
FNB Conference & Learning Centre, Sandton

 

Certified Scrum Master (CPT)
26-27 Jan 2015
Steenberg Hotel, Cape Town

 

Certified Scrum Product Owner (CPT)
23-24 Feb 2015
Steenberg Hotel, Cape Town

 

Certified Scrum Master (JHB)
10-11 Mar 2015
FNB Conference & Learning Centre, Sandton

 

Course Schedule and Book Online

 

The post News update 2014/11 – Here Be Dragons – Scaling Agile appeared first on ScrumSense.

Categories: Blogs

Coal in your bug tracking stocking this Christmas?

What is your plan for being a better developer next year?  What's the technique that will repay your efforts many fold?  Testing - automated test to be specific.  There are all types of automated testing.  The agile mind set thinks of testing first, not in a reactive manner, but as a preventative and design effort.

For three years, The Container Store has been using application performance management (APM) technology from AppDynamics to locate bugs in the website, target them immediately and fix them.

Sometimes there's a slowdown in a particular region. Other times it's from a certain database and often from a single line of code. Just this year, the Container Store upped its contract with AppDynamics, buying more software so the company can test new features before deploying them and minimize the number of live fixes necessary.

"We said we want to be more proactive instead of reactive," said A.J. Azzarello, a quality assurance engineer at The Container Store in Dallas. "We can catch errors and slow response times in test prior to production so they never impact our customers."From CNBC's article: Don't let software bugs ruin Christmas by Ari Levy


Categories: Blogs

Der reflektierte Umgang mit sich selbst: Führung und Grundhaltung

Scrum 4 You - Mon, 11/24/2014 - 08:59

Wenn ich an meine langjährige Führungspraxis denke, nehme ich eine komplexen Prozess wahr, in dem vor allem eines immer wieder auf dem Prüfstand gestellt wurde: meine Haltung zur Profession Führung, als Führungskraft und zu den Menschen die ich führen durfte. Wie Menschen Führung – ob disziplinarisch oder lateral – ausüben, hängt in hohem Maß von ihrer (unbewussten und bewussten) Grundhaltung, von ihrer Rollenidentität ab. Das Führen von Menschen ist eindeutig und zuallererst ein Haltungsthema. Boris Gloger meint dazu in unserem gemeinsamen Buch “Selbstorganisation braucht Führung”: “Der erste entscheidende Schritt dazu ist: Vergessen wir alles, was wir aus Büchern, Vorträgen, Seminaren und von unseren eigenen Vorbildern über Führung zu wissen meinen! Damit meine ich auch dieses Buch! Es soll anregen, kann aber Ihr eigenes Denken und Ihre eigenen Schlussfolgerungen nicht ersetzen. Hinterfragen Sie einfach alles noch einmal, fangen Sie wieder von vorne an. Dieser Schritt ist entscheidend: Sie selbst sollten für sich ein neues Modell von Führung erfinden.“ Und damit eine ganz spezifische, individuelle Haltung entwickeln.

Immer wieder werde ich in Führungstrainings von skeptischen Teilnehmern gefragt, ob sie hier stromlinienförmig optimiert werden sollen. Die Antwort kann nur lauten: auf keinen Fall. Es geht nicht ums Klonen von standardisierten Führungsrobotern, sondern es geht um Anstöße für die individuelle (Selbst-) Reflexion, um die eigene Entscheidung, was in der Führungsrolle individuell “passt” und wie sie funktional und positiv interpretiert und ausgefüllt werden kann. Und es geht um das Andocken an die bisherigen subjektiven Erfahrungen zum Thema Führung. Denn jeder Mensch hat eine Vielzahl von Situationen er- und durchlebt, in denen er geführt wurde, in denen er Führung beobachtet und eingeordnet hat und die ihn heute mehr oder weniger stark prägen.

Die Rollenidentität als Führungskraft, und damit eine spezifische individuelle Grundhaltung, entwickelt sich durch komplexe Erfahrungen im Sinne von unbewussten und bewussten Lern- und Erfahrungsmustern. Unbewusst wirkende Überzeugungen und vorgelebte Werte aus Kindheit und Jugend, die wir von unseren Eltern oder späteren Vorbildern übernommen haben, beeinflussen uns und unsere Wertvorstellungen. Man muss lernen, sich dieser einflussreichen Überzeugungen und deren Auswirkungen auf das eigene Führungsverhalten bewusst zu werden, Position zu beziehen und bei Bedarf Veränderungen einzuleiten. Drei Positionen sind dabei wesentlich.

  • Die innere Haltung dem eigenen Ich gegenüber
    „Wofür stehe ich? Was macht mich als Mensch aus? Was motiviert mich? Lebe ich diese Dinge in einer wertschätzenden Haltung? Und wie bringe ich sie in Bezug zur Führungsrolle?“ Diese oder ähnliche Fragen stellen wir uns selten bewusst. Dabei sind sie absolut zentral. Sie sind die Grundlage unserer Handlungen und unserer Kommunikation. Und die Antworten auf diese Fragen zeigen sich in jeder Begegnung mit anderen Menschen, in jedem Gespräch. Und das selbst dann, wenn man nie über die eigene innere Haltung nachgedacht hat. Ein Blick auf die Meta-Ebene ist daher hilfreich: Es liegt viel Potenzial darin, sich mit dem eigenen inneren Antrieb, mit dem Kern dessen, was mich als Person ausmacht, zu beschäftigen. Um diese Entdeckungsreise zum eigenen Wesenskern anzutreten, ist es unerlässlich, in Ruhe nach innen zu hören und zu spüren und seine biographischen “Daten” Revue passieren zu lassen.
  • Die innere Haltung den Mitmenschen (Mitarbeitern) gegenüber
    Hier geht es um das grundsätzliche Menschenbild. Werden die Menschen als solche in ihrer primären Existenz eher positiv oder negativ gesehen, als vertrauenswürdig oder eher als unlauter, als fleißig oder eher faul, als Partner oder Konkurrenten usw. Führungskräfte, deren Hauptwerkzeug die Kommunikation ist, sollten sich daher im Bezug zu ihren Gegenübern auch situativ immer wieder – besonders aber in wichtigen Situationen – bewusst reflektieren.
  • Passung von Führungsrolle und Persönlichkeit 

    Passt die innere Haltung nicht zur Führungsverantwortung, dann entsteht ein Konflikt. Wer mit Worten für etwas argumentiert, das der eigenen inneren Haltung widerspricht, wird vom anderen intuitiv als unecht empfunden. Dieses inkongruente Verhalten sorgt für unbefriedigende Ergebnisse und lässt auch die Führungskraft auf Dauer unzufrieden zurück. Das Wort Persönlichkeit kommt von „personare“ und bedeutet „durchtönen“. Die Frage ist, wie gelingt es, die eigene Persönlichkeit stimmig in der Führungsrolle durchtönen zu lassen und gleichzeitig die Rollenklarheit zu behalten? Worüber muss ich intensiv nachdenken, was ist kongruent, wo muss ich mich anpassen oder entwickeln? Besonders laterale Führungskräfte brauchen oft Zeit und intensive Reflexion, um eine adäquate Position zu finden. Natürlich trifft die individuelle Interpretation der Führungsrolle immer auch auf die Führungskultur des Unternehmens und damit auf spezifische, mehr oder weniger transparente Erwartungen an die Führungshaltung von außen. Dies ist zu berücksichtigen. Unternehmen müssen daher grundsätzliche Anforderungen an die Führungshaltung definieren, die aber Raum für individuelle Gestaltung lassen.

Der erste Schritt allerdings ist es, sich über die tiefsten subjektiven Bezüge zur Führung klar zu werden. Finde ich Führung grundsätzlich notwendig, funktional und positiv? Oder habe ich meine Probleme mit dieser Form menschlicher Interaktion, vor allem Arbeitskontext? Lehne ich Führung eher ab und sehe sie sehr kritisch? Der Selbstreflexionsbogen Führung geht also nicht auf die konkreten Elemente der Führungshaltung ein, sondern soll helfen, die grundlegendsten Erfahrungen und Bezüge zur Führung transparenter und bewusster zu machen. Er fragt nach der elementaren Haltung und geht von der Prämisse aus: Nur wer gerne führt, führt wirklich gut!

Sollten Sie in der Skalenfrage das Kreuz bei 7 und mehr gemacht haben, sind Ihre Voraussetzungen für eine Führungsrolle sehr gut. Sie können einzelne Haltungselemente prüfen und den Fokus auf gut erlernbare Führungskompetenzen legen. Setzen Sie Ihr Kreuz bei 5 und darunter, empfiehlt es sich grundlegend, über Ihre Haltung zur Führung nachzudenken. Überlegen Sie, wo Blockierungen liegen könnten und was Sie bräuchten, um einen grundlegend positiveren Bezug zu entwickeln. Sprechen und reflektieren Sie mit Kollegen, Freunden oder einem kompetenten Coach. Und vielleicht gibt es ja auch Alternativen zu einer Führungsposition, um sich beruflich zu verwirklichen.

Categories: Blogs

5 Steps to Cultivating an Agile Culture

The Agile Management Blog - VersionOne - Fri, 11/21/2014 - 18:41

We’ve all heard the maxim change is difficult.  The reasons that change is hard are far too numerous to discuss in a single blog posting.  My intent here is to specifically focus on organizational agile transformations and the difficulty of changing culture.  Additionally, I want to leave you with some hope.  While it is difficult, it is not impossible.  There are steps that you can take as an individual that can help the organization as a whole move in the right direction.

The 2013 VersionOne State of Agile Survey indicates the top three reasons cited by practitioners for adopting agile within their organizations include accelerated time to market, the ability to more easily manage changing priorities, and to better align IT and the business, respectively.  These are desired results.  Unfortunately, viewing agile as a methodology alone will only minimally achieve these results, if at all.  The same survey cited the primary barrier to agile adoption as being the inability to change organizational culture.

Many adoptions focus primarily on providing training for individuals and teams.  Training is certainly crucial; unfortunately, many initiatives stop with training.  This is insufficient to sustain the change effort’s momentum.  It’s perplexing to me that organizations expect a shift in results with training alone?  It’s unrealistic.  Even when training is provided the attendees are thrust back into an environment that does not support new experiences that validate a new way of doing things.  The pyramid in the illustration below helps to visually explain why.

Change Pyramid

Individual Change Pyramid

First, I have to give credit for this illustration to Heather Hassebroek.  I met Heather only briefly at an agile conference, where we sat next to each other and started a discussion about why we think change is so difficult.  I think the pyramid succinctly demonstrates what’s occurring.  She jotted it down and I asked her if I could use it.  She graciously said yes.  Thank you Heather!

Our experiences lie at the base of the pyramid.  These experiences create and reinforce our beliefs and values, which drives our actions and behaviors.  The actions and behaviors produce results—both good and bad.  Therefore, one of the keys to transformation efforts is that it has to be rooted in individual experiences that breathe life into the new way of doing things.

For example, let’s consider the agile principle that states the primary measure of progress is working software.  To realize this principle we must first provide experiences that reinforce new values.  I have worked with teams that have attended training and seem to understand the principles of The Agile Manifesto very well.  The mindset just seems to make sense to them.  Yet, when returning to the day-do-day routine of their projects they fail to have stakeholders attend sprint reviews and are required to provide weekly project status reports including percent complete and red, amber, green stoplight indicators.  The team’s collective experience is that working software isn’t really valued as much as a status report.  This repeated shared experience leads to apathy and stalled transformations.  Alas, the team and organization continues to slumber under the status quo.

Here are 5 new experiences to consider if you want to foster an agile culture.  The list isn’t exhaustive, of course, but all of these are steps to consider if you want to reinforce new values and drive behavior change leading to positive results.

  1. Expect working software to be demonstrated at the end of a sprint.  If it can’t be demonstrated, it’s not done.
  2. If you need something from someone—call them!  Better yet, if you are co-located walk over to them and have a conversation and engage them in collaboration.
  3. If you’re a manager or executive, form stable teams.  If you do not understand the long-term competitive advantage of a high-performing stable team, you have much to learn about agile organizations.
  4. Be open about your failures at all levels (individual, departmental, managerial, etc.).  This has to start with you!  Don’t expect everyone to be open first.  You must demonstrate this behavior.  But consider this in a positive light.  Also be open about what you learned as a result of the failure.  Over time, this will help foster a learning culture.  Consider a team-level sprint or release award for the failure that led to the most learning.
  5. Experiment with pairing for 5 days.  I’m not simply referring to pair programming.  Try pairing in daily activities.  You may be surprised at the results.  If not, it’s only been for 5 days.  But give it at least that much time.  If it works you might even consider rotating pairs every week to help drive learning and building relationships.
Categories: Companies

Make Stories Small When You Have “Wicked” Problems

Johanna Rothman - Fri, 11/21/2014 - 16:10

If you read my Three Alternatives to Making Smaller Stories, you noticed one thing. In each of these examples, the problem was in the teams’ ability to show progress and create interim steps. But, what about when you have a “wicked” problem, when you don’t know if you can create the answer?

If you are a project manager, you might be familiar with the idea of “wicked” problems from   from the book Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms. If you are a designer/architect/developer, you might be familiar with the term from Rebecca Wirfs-Brock’s book, Object Design: Roles, Responsibilities, and Collaborations.

You see problems like this in new product development, in research, and in design engineering. You see it when you have to do exploratory design, where no one has ever done something like this before.

Your problem requires innovation. Maybe your problem requires discussion with your customer or your fellow designers. You need consensus on what is a proper design.

When I taught agile to a group of analog chip designers, they created landing zones, where they kept making tradeoffs to fit the timebox they had for the entire project, to make sure they made the best possible design in the time they had available.

If you have a wicked problem, you have plenty of risks. What do you do with a risky project?

  1. Staff the project with the best people you can find. In the past, I have used a particular kind of “generalizing specialist,” the kind where the testers wrote code. The kind of developers who were also architects. These are not people you pick off the street. These are people who are—excuse me—awesome at their jobs. They are not interchangeable with other people. They have significant domain expertise in how to solve the problem. That means they understand how to write code and test.
  2. Help those generalizing specialists learn how to ask questions at frequent points in the project. In my inch-pebble article, I said that with a research project, you use questions to discover what you need to know. The key is to make those questions small enough, so you can show progress every few days or at least once week. Everyone in the project needs to build trust. You build trust by delivering. The project team builds trust by delivering answers, even if they don’t deliver working code.
  3. You always plan to replan. The question is how often? I like replanning often. If you subscribed to my Reflections newsletter (before the Pragmatic Manager), back in 1999, I wrote an article about wicked projects and how to manage the risks.
  4. Help the managers stop micromanaging. The job of a project manager is to remove obstacles for the team. The job of a manager is to support the team. Either of those manager-types might help the team by helping them generate new questions to ask each week. Neither has the job of asking “when will you be done with this?” See Adam Yuret’s article The Self-Abuse of Sprint Commitment.

Now, in return, the team solving this wicked problem owes the organization an update every week, or, at the most, every two weeks about what they are doing. That update needs to be a demo. If it’s not a demo, they need to show something. If they can’t in an agile project, I would want to know why.

Sometimes, they can’t show a demo. Why? Because they encountered a Big Hairy Problem.

Here’s an example. I suffer from vertigo due to loss of (at least) one semi-circular canal in my inner ear. My otoneurologist is one of the top guys in the world. He’s working on an implantable gyroscope. When I started seeing him four years ago, he said the device would be available in “five more years.”

Every year he said that. Finally, I couldn’t take it anymore. Two years ago, I said, “I’m a project manager. If you really want to make progress, start asking questions each week, not each year. You won’t like the fact that it will make your project look like it’s taking longer, but you’ll make more progress.” He admitted last year that he took my advice. He thinks they are down to four years and they are making more rapid progress.

I understand if a team learns that they don’t receive the answers they expect during a given week. What I want to see from a given week is some form of a deliverable: a demo, answers to a question or set of questions, or the fact that we learned something and we have generated more questions. If I, as a project manager/program manager, don’t see one of those three outcomes, I wonder if the team is running open loop.

I’m fine with any one of those three outcomes. They provide me value. We can decide what to do with any of those three outcomes. The team still has my trust. I can provide information to management, because we are still either delivering or learning. Either of those outcomes provides value. (Do you see how a demo, answers or more questions provides those outcomes? Sometimes, you even get production-quality code.)

Why do questions work? The questions work like tests. They help you see where you need to go. Because you, my readers, work in software, you can use code and tests to explore much more rapidly than my otoneurologist can. He has to develop a prototype, test in the lab and then work with animals, which makes everything take longer.

Even if you have hardware or mechanical devices or firmware, I bet you simulate first. You can ask the questions you need answers to each week. Then, you answer those questions.

Here are some projects I’ve worked on in the past like this:

  • Coding the inner loop of an FFT in microcode. I knew how to write the inner loop. I didn’t know if the other instructions I was also writing would make the inner loop faster or slower. (This was in 1979 or so.)
  • Lighting a printed circuit board for a machine vision inspection application. We had no idea how long it would take to find the right lighting. We had no idea what algorithm we would need. The lighting and algorithm were interdependent. (This was in 1984.)
  • With clients, I’ve coached teams working on firmware for a variety of applications. We knew the footprint the teams had to achieve and the dates that the organizations wanted to release. The teams had no idea if they were trying to push past the laws of physics. I helped the team generate questions each week to direct their efforts and see if they were stuck or making progress.
  • I used the same approach when I coached an enterprise architect for a very large IT organization. He represented a multi-thousand IT organization who wanted to revamp their entire architecture. I certainly don’t know architecture. I know how to make projects succeed and that’s what he needed. He used the questions to drive the projects.

The questions are like your tests. You take a scientific approach, asking yourself, “What questions do I need to answer this week?” You have a big question. You break that question down into smaller questions, one or two that you can answer (you hope) this week. You explore like crazy, using the people who can help you explore.

Exploratory design is tricky. You can make it agile, also. Don’t assume that the rest of your project can wait for your big breakthrough.  Use questions like your tests. Make progress every day.

I thank Rebecca Wirfs-Brock for her review of this post. Any remaining mistakes are mine.

Categories: Blogs

Wer ist eigentlich … Christoph Schmiedinger?

Scrum 4 You - Fri, 11/21/2014 - 08:21

Wie beschreibst du deinen Eltern/ Freunden deinen Arbeitsalltag bei Boris Gloger Consulting?
Viele verbinden mit Unternehmensberatung gut gekleidete Menschen, viel reisen, Überstunden en masse und schöne PowerPoint-Foliensätze. Im Wesentlichen stimmen einige dieser Aspekte, doch ich denke, dass es bei Boris Gloger Consulting doch ein wenig anders abläuft als in klassischen Beratungen. Meiner Familie und Freunden beschreibe ich meinen Arbeitsalltag immer als äußerst abwechslungsreich und herausfordernd. In der Hauptsache bin ich dazu da, anderen Menschen zu helfen, ein Produkt erfolgreicher zu entwickeln. Dazu verwende ich moderne Ansätze, die in vielen Organisationen Widerstand hervorrufen. Auch das ist ein Grund, warum ich mit an Bord bin. Neben den Projekten beschreibe ich meinen Freunden auch oft unsere differenzierte Arbeitsweise im Unternehmen selbst, etwa das Prinzip der Freiwilligkeit oder den Freiraum, der uns gegeben wird. Viele können das nicht nachvollziehen, weil sie nicht glauben können, dass eine Firma auf Basis dieser Prinzipien funktionieren kann.

Welchen Beruf wolltest du als Kind unbedingt ergreifen?
Als Kind wollte ich die klassischen Abenteuer-Berufe wie Feuerwehrmann oder Polizist ergreifen. Vielleicht war es aber auch die Hilfsbereitschaft, die mich dazu motivierte. Ich denke, dass ich mit meiner Berufswahl als Consultant diese Wünsche zumindest teilweise ausleben kann. Immerhin ist jedes Projekt immer wieder ein Abenteuer und ich liebe es, anderen Menschen zu zeigen, dass sie ihren Arbeitsalltag erleichtern und gleichzeitig erfolgreich sein können.

Wie siehst du deine bisherige Karriere? Viel Zufall oder überwiegend sorgfältige Planung?
Meine bisherige Karriere war überwiegend sorgfältig geplant. Ich habe bereits kurz vor meiner Matura (Abitur) den Entschluss gefasst, gleichzeitig einen verantwortungsvollen Job anzunehmen und mein Studium am Abend und Wochenende zu absolvieren. Fünf Jahre später bin ich froh, diesen Weg gewählt zu haben. Ich erkenne, wie viel Vorsprung ich durch meine zusätzlichen fünf Jahre Berufserfahrung nach meinem Studienabschluss hatte oder noch immer habe. Auch der Weg ins Consulting war geplant, da ich nach fünf Jahren im gleichen Unternehmen „raus“ in die weite Welt und „Neues“ kennenlernen wollte. Da mich agile Methoden bereits im letzten Unternehmen und auch während meines Studiums fasziniert haben, fiel die Wahl auf eine Unternehmensberatung mit Fokus auf agile Methoden und dann letztendlich auf Boris Gloger Consulting.

Christoph_Schmiedinger

Gibt es ein bestimmtes Ritual in der Arbeitswoche, auf das du nicht verzichten könntest?
Interessanterweise habe ich bei dieser Frage als Erstes den Weekly Report, den wir dem Kunden zu Abschluss der Arbeitswoche schicken, im Kopf. Für mich ist dieses „Absenden“ der formale Abschluss der Projektwoche, mit dem ich meine Gedanken für das Projekt zum Wochenende ruhen lasse.

Unter all den Projekten, die du für Boris Gloger Consulting realisiert hast: Welches ist dein All-Time-Favourite?
Ich hatte erst ein Projekt bei Boris Gloger Consulting, das ich nun bereits seit mehr als sechs Monaten begleite. Ich denke aber, dass es durchaus einer der All-Time-Favourites werden könnte. Die große Herausforderung in dem Projekt waren die sehr unterschiedlichen Typen und Charaktere (Entwickler, SAP-Berater und Anwender), die erst zur Zusammenarbeit bewogen werden mussten. Es war großartig zu sehen, wie diese Entwicklung über den Lauf der Sprints zunehmend stattgefunden hat, so dass wir nach ein paar Monaten ein hoch performantes und gut zusammenarbeitendes Team geschaffen haben.

Drängende Kundenanfragen, E-Mail-Flut, Meeting-Marathon oder als Consultant jeden Tag an einem anderen Ort: Was ist dein Geheimrezept, um im hektischen Arbeitsalltag einen kühlen Kopf zu bewahren?
Bereits während meines Studiums, das ich neben meinem 40-Stunden-Job absolviert habe, habe ich mir angewöhnt, ein gutes Zeitmanagement zu betreiben. Dazu gehört neben einer ordentlich gepflegten To-Do-Liste auch die richtige Einstellung bzw. Herangehensweise. Ich versuche beispielsweise, alle Aufgaben so früh wie möglich abzuschließen, auch wenn die Deadline noch weit entfernt scheint. Das hilft mir, nicht zu sehr in Stress zu geraten, wenn diese Termine näher rücken. Zusammengefasst ist mein Rezept ein strukturiertes und zeitnahes Abarbeiten der zu erledigenden Themen.

Was ist für dich das Besondere an der Arbeit bei Boris Gloger Consulting?
Das Besondere ist einerseits das Projektumfeld, das äußerst spannend und herausfordernd ist. Immer wieder gibt es neue Projekte, in denen man am liebsten selber mitwirken will, weil das Problem oder die Situation einfach nur aufregend und spannend ist. Andererseits ist es die Atmosphäre im Unternehmen selbst. Alles basiert auf Freiwilligkeit und jeder kann sich einbringen, wo er seine eigenen Stärken sieht, solange es zum Unternehmensziel beiträgt. Dieser Freiraum ist anfangs ungewohnt, auch ich habe ein paar Wochen bis Monate gebraucht, um mich damit zurecht zu finden. Nun bin ich in vielen Themen engagiert und weiß, wo ich zu den Unternehmenszielen beitragen kann und das auch tue.

Gibt es eine Marotte, mit der du deine Kollegen regelmäßig auf die Palme bringst?
Da ich ein sehr ruhiger und friedliebender Mensch bin, sind es wenn nur kleine Marotten, wie beispielsweise meine Penibilität beim Review von Blogbeiträgen, in denen ich regelmäßig viel in der Wortwahl und Satzstellung ändere.

Was machst du in deiner Freizeit, um runterzukommen?
In meiner Freizeit verbringe ich viel Zeit mit meiner Lebensgefährtin, auch weil wir uns unter der Woche nicht bzw. äußerst selten sehen. Dabei stehen nicht außergewöhnliche Hobbies, sondern einfach die gemeinsame Zeit im Vordergrund. Das heißt, wir unternehmen total unterschiedliche Dinge und gerade das, worauf wir spontan Lust haben. Gerne komme ich aber auch allein „runter“, meist bei sportlichen Aktivitäten wie Rad fahren, Snowboarden oder Tauchen.

Scrum ist für mich…
die perfekte Methode, ein großes Vorhaben strukturiert und erfolgreich zum Ziel zu bringen und zugleich das Team zufriedener mit seiner Arbeit zu machen.

Categories: Blogs

Organizational Design and Scrum

Scrum Expert - Thu, 11/20/2014 - 19:47
It’s very easy to become hierarchical and turn into a “bank” when software company is growing fast. Is there a way to avoid that? How to keep the focus on value creation? What about Value departments, not Functional departments? This presentation shares ideas what we can learn from Scrum and apply in organizational design. It shares hypothesis how a company could look like when everybody is focused on value creation. Video producer: Agile Latvia
Categories: Communities

Rally: Our Dev Team Therapist

Rally Agile Blog - Thu, 11/20/2014 - 15:00

(Guest blogger and Rally user Erine Gray is the founder of Aunt Bertha, a software platform that makes it easy for people to find and apply for food, health, housing and education programs in the U.S.)

This is the story of how Aunt Bertha used Rally to get our team organized, communicate better, and start loving each other again. It was kind of like group therapy.

I’m only sort of joking. Our team doubled in size this year and there are now more people writing code. There’s more knowledge to be transferred. There’s more testing that needs to be done. There’s more that can go wrong. And things did go wrong; like any relationship, communication is key.

A Story

We had a new customer, Critical Mass, who wanted its users to be able to know if they qualified for a local cancer program using rules common in the cancer program space: current age, age at diagnosis, type of cancer, and current stage of cancer. We’ve always had ways of determining whether someone qualified for a program based on their income, but we didn’t have an easy way to extend this qualification to other eligibility rules, like these.

Ideally, a cancer survivor should be able to see—with the click of a button—whether or not they qualify for a cancer program, and why. They should be able to see something like this:

Since Aunt Bertha’s mission is to make program information accessible, we were excited to build this feature into our product. However, we had a problem.

Teamwork and Knowledge Transfer

When we first started using Rally at Aunt Bertha, we had two new programmers on the team. I was the lead developer, and I was terrible at knowledge transfer. Release after release would go by and features were not delivered on time. And it was my fault.

I had no doubt in my mind this feature should be built, and I knew how I was going to do it. I had a vision of what it was supposed to look like and a rough idea of how the algorithm would work, since I’d written most of the search code over the last three years.

The trouble was that building this feature was going to be a significant amount of work, and I didn’t have time to build it. Programmers are typically optimistic about how long it takes to do stuff, but we have short memories. It’s kind of like golf: we only remember those great drives that lay up perfectly on the fairway; we don’t remember the time we spent digging through the weeds to find our ball (or the late nights spent debugging only to find out we put a semicolon in the wrong place.)

Aunt Bertha was also in a growth phase. I didn’t need to be the lead programmer anymore. I had to delegate, but I was afraid because I knew that this feature would touch hundreds of lines of code that only I understood.

Enter Rally

Around this time our product manager, Ruby, started implementing Rally for our software development process. Prior to Rally, we had used Github as a code repository and for issue tracking. It was a nice, lightweight way of keeping track of issues and milestones, but now we had more developers and staying organized was a real challenge. We needed more rigor and structure.

I didn’t know much about agile software development. Ruby implemented a bi-weekly sprint planning meeting, and gave us all homework. Our job was to look at all of our stories, and break them down into digestible tasks.

I took the Critical Mass eligibility rule story and began to break it down. In the past I would typically jump into a feature, only to discover later just how complex it was. Breaking down a feature into stories and tasks really forced me to think about the problem in small chunks. That was when the light bulb went off in my head: I could indeed delegate some of these tasks to our new developers. I didn’t have to be the one to do it all; I just had to coach them along.

I’m happy to report we built a pretty amazing feature that’s making it easier for cancer survivors to navigate the myriad programs out there. Our developers can now dig into the most complex code, and I can now concentrate on getting new customers and setting the longer-term vision for the product.

Rally helped us communicate better, and set deadlines that we could actually make. Rally helped us understand that big problems are nothing but a series of small problems.

Making It Fun

One of my favorite views in Rally is the Story Estimation screen.

After we’ve developed our stories and added the requisite tasks, our next step is to estimate about how long a story (or feature) will take to build. This screen allows you to easily drop in a story by the estimated size. We size ours based on the size of our dogs (we’re a dog friendly office.)

A small story is a “Cinco.” A “Rosie” (that’s my dog) is a medium-sized story. A “Beowolf” (Chris’ dog) is a big story.

Cinco, Rosie, and Beowolf represent small, medium, and large story sizes

It may seem silly to estimate your workload this way, but the truth is that sizing is relative. What matters is how many Beowolfs, Rosies, or Cincos you can accomplish in a two-week sprint.

Why We Chose Rally

We considered plenty of options: we could have just stayed with Github, and we looked at Rally competitors. But we ended up going with Rally for a couple of reasons. One reason was that Rally offers its products at a discount for fellow B Corporations (Aunt Bertha has been a B Corporation since 2011.) The primary reason, however, was an encounter I had with Rally’s founder, Ryan Martens.

Ryan was a mentor at Boulder’s Unreasonable Institute, and when Aunt Bertha went through the 2012 Unreasonable Institute in Boulder, I had a chance to interact with Ryan. During that summer the team would spend most evenings with mentors: getting our questions answered, hearing about their experiences, or just sharing stories. I distinctly remember one of Ryan’s comments on business and ethics: the passion of his delivery and his desire for our success made me a fan immediately. Simply put, he seemed like a guy I wanted to be like, someday. And Rally is a company we want to be like someday.

Erine Gray
Categories: Companies

Avoid Failure to Launch: Kick-Start Your Next Initiative

The Agile Management Blog - VersionOne - Thu, 11/20/2014 - 14:43

Guest post from two Davisbase consultants:  Adam Mattis and Leslie Morse

The Challenge

It’s a great day:  you wake up, the sun is shining, there is no traffic on the way to work, and when you get to the office… there it is. A shiny, new, fully sanctioned project. It’s GO TIME!

Easy there, killer. Before you dive in head first, let’s take a step back and get our proverbial ducks in a row.

All too often with agile-run initiatives or projects, we skip the foundational efforts that set the team up for success. In business environments where teams are constantly challenged to do more, faster, and with less, these foundational efforts are often overlooked. However, this quick-to-launch mentality ends up costing us much more, further on down the line.

What are these foundational efforts that we speak of? Let’s take a step back to bootcamp and remember the importance of:

  • Product Vision
  • Product Roadmap
  • User Roles
  • Initial Backlog Population
  • The Architectural and UX Runway

Three Preconditions for Starting Work

No one embarks on a new effort, initiative, project, or body of work with the intent to fail. However, agile development is often used as an excuse to make it up as you go along. Let’s frame up the goal of foundational work for agile workstreams by creating a user story.

user story table

 

1.  Business Readiness:  The degree to which business stakeholders are in alignment on what the vision is, who it is intended to benefit, and how much money should be investing in realizing the value.

2.  Architectural Readiness:  Ensuring that key IT stakeholders understand the vision and target scope for the effort as well as the definition of a high-level architectural approach to delivering value.

3.  Team Readiness:  Critical collaboration activities and workshops necessary to prepare the team for an incremental delivery cadence.

BUSINESS READINESS

The business defines the ‘what’ for an agile team; therefore, readiness on behalf of the business is of paramount importance before engaging the technology group. But what does business readiness look like?

Business Case: Defining the Need

The business case provides justification for funding a new initiative. Depending on your organization, this could be something as simple as an elevator pitch, or a much more detailed document outlining market opportunities, value propositions, return structures, etc.

Regardless of the level of detailed that is needed, having a clearly documented business case helps build a shared understanding of value among executives, sponsors, and key stakeholders. Continued support from these individuals is as key to the product launch as is the technical solution.  See Figure 1 for an example of the Elevator Pitch Structure.

FIGURE 1: Elevator Pitch Structure

figure 1

Product Vision

With the business case crafted, the next task is to develop a cornerstone for the team to focus on. This cornerstone, or product vision, serves as the high-level focus from which every epic, every feature, and every user story is created. All work done by the agile team should be focused on satisfying the product vision.

The vision should be comprised of the product name, a value statement, and a few key features that differentiate the product. The vision may also outline some basic technical requirements such as OS compatibility or platform such as “web-based.”

FIGURE 2 – Design the Box

figure 2

 

While it is important for the product owner and key stakeholders to understand and align on the vision when preparing to kick-start the initiative, keep in mind that it will be necessary to have a vision workshop with the cross-functional agile team in order to ensure a shared understanding of the product they are building. Once created, the product vision should be posted in a common team area to serve as an information radiator. The vision will help keep the team focused throughout the work cycle.

Product Roadmap

The product roadmap helps link the product vision to the work which agile teams do every day. The roadmap is not intended to be a commitment or project plan, but simply a guide that the agile team uses to plan their work during release planning sessions.

Without a roadmap, teams are left without a clear strategic vision. It is a common misconception that agile teams do not strategize. The reality is that agile teams are highly strategic and nimble enough to shift focus with rapidly changing market conditions.

FIGURE 3 – Product Roadmap

roadmap

 

The roadmap focuses on high-level themes, epics, or features – and, like the backlog, remains fluid throughout the course of the initiative. To be effective, the artifact should be highly visible and referred to often. As market conditions and priorities change, so should the roadmap and other downstream artifacts. Again, aligning on the roadmap before engaging the agile team is critical in order to avoid swirl and confusion when getting the team started. It is important to ensure that business stakeholders understand that the roadmap will most certainly evolve as the team begins work.

User Roles

With the ‘what’ defined in the business case, product vision, and product roadmap, it is now time to consider the ‘who.’ The definition of user roles seems like a fairly straightforward task, but once the discussion begins, teams are often surprised at how difficult the task can be.

Consider Facebook. On first thought it may seem simple: New User, Existing User, Administrator. Not so fast. Really think about all of the different interactions that take place on Facebook.

New User Existing User Business User Group Administrator Advertiser Photo Poster Marketplace User Under 13

And that’s not even scratching the surface!

Now consider any system within your organization and imagine how challenging it would be to identify all of the different paths and user types within the system. Consider the importance of evaluating the individual needs of each of these users in creating a solution.

Remember, one of the key benefits of an agile culture is the delivery of high-quality, customer-focused software. If the team is not sure who they are solutioning for, it is likely that the product will not sufficiently satisfy the needs of anyone.

Baseline User Stories & The Backlog

With the product and users now defined, it is time to elicit basic needs from our business partners. Remember, the business product owner (BPO) is the tip-of-the-spear for all things business. The BPO serves as the single voice for the customer, product management, sales, marketing, legal, finance, and all of the other organizations that make up the business function. The BPO and supporting team need to elicit baseline user stories from each of these groups and place them on the backlog for prioritization.

As the program progresses, the BPO will be accountable for making sure any inputs from the business team are ready for the agile  team at the appropriate time. A few examples of these items may include legally approved verbiage, approved graphics from the marketing team, and any special promotional offers from the sales team. The BPO, with full control over the prioritization of the backlog, must maintain awareness of upcoming user stories and their dependency of these inputs.

ARCHITECTURAL READINESS

Now that we understand the ‘what,’ it is time to engage the technology group! HOLD ON… let’s tap those brakes! You’re only partially right. With the ‘what’ defined, we still have not begun to explore the solution. To begin framing up the ‘how,’ we need to engage the solutions architect.

Developing Shared Understanding

The solutions architect is in a unique position to begin bridging the gap between business need and technology execution. This individual has a broad view of all technology groups, infrastructure types, and data locations. In bringing the architect in early, the business will be able to get an accurate gauge of the technical feasibility of their ask, as well as the level of effort involved to deliver.

Identify IT Impacts

Once the feasibility study is complete, the solutions architect will start to map out the solution. This sketch will include the identification of new infrastructure, data flow mapping, and systems impacts. With this analysis complete, leaders can determine the right skill sets and organizational units that need to be involved in forming the agile team(s) who will work on the initiative.

TEAM READINESS

Let’s assume you’ve followed a good plan for initiating this new body of work. Your product owner is firing on all cylinders, business stakeholders are in alignment and engaged, the architects have a vision for the solution needed to deliver value, and the cross-functional set of agile team members are locked and loaded.  Please, please, please — don’t make the assumption that those folks are clairvoyant and have a shared understanding of what the organization is looking to achieve!

Agile teams need to practice the full Five Levels of Agile Planning [See Figure 4]. It doesn’t mean the product owner and business stakeholders do Levels 1-3 and the team only engages in Levels 4-5.  The entire agile team plus key stakeholders need to collaborate in order to prepare for the first sprint planning event. Highly effective agile teams engage in Levels 1-3 of planning during a timeboxed period often called Sprint Zero. When well-facilitated, it could take only a week, but spending more than four weeks on these activities would likely lead to analysis paralysis. Key preconditions, activities, and outcomes of Sprint Zero are outlined in Figure 5.

FIGURE 4 – Five Levels of Agile Planning

figure 4

 

FIGURE 5 – Sprint Zero Summary

figure 5

Start Small & Improve Incrementally

Feeling overwhelmed?  If you’ve got a gap in your pre-planning processes or you’re currently feeling the pain associated with a lack of readiness in one of these three areas, consider one of these three techniques in order to improve. After that, make a backlog of all of the opportunities to improve your pre-planning processes, prioritize the list, and affect change incrementally over time.

1.  The Stakeholder Engagement Cadence

Product owners are intended to be the single source of truth around ‘what’ the agile team needs to deliver. In order to effectively do this, product owners need to fully understand their stakeholders and proactively engage them so that priorities and acceptance criteria are the best quality possible.Figure 6 outlines a framework for a stakeholder engagement cadence where stakeholders are classified into one of three groupings (Advisors, Supporters, or Sponsors) and then, based on the classification, are brought together once a month, twice a month, or weekly, based on their level of involvement in the workstream. To learn more about this technique, check out Proactive Stakeholder Engagement, a post on Davisbase’s #BecomingAgile blog.

FIGURE 6 – Stakeholder Engagement Cadence

figure 6

 

2.  The Backlog Refinement Cadence
It is essential that teams keep a product backlog deep enough to sustain incremental delivery. While pure Scrum doesn’t call for teams maintaining a runway of “ready” stories or a projection of the backlog items they will be completing in which sprint, in practice – it is a useful planning approach for keeping flow within the system and aligning the dependencies and coordination points that often exist within organizations of scale and complexity. Figure 7 outlines a backlog refinement approach that creates focus for agile teams and helps build the discipline to keep one sprint’s worth of stories in a “ready” state, as well as get the details and specifications just enough in advance of the sprint where they will commit to the work.  When paired with the Stakeholder Engagement Cadence, this information radiator can also be useful for creating context on topics for collaboration. To learn more about the cadence for backlog refinement, check out the #BecomingAgile Webinar recording Strategies for Grooming Your Backlog.

FIGURE 7 – Refinement Cadence

figure 7

 

3.  The Architectural Feedback Loop

In a similar manner to how feedback is generated often in software demonstrations, it is equally as important for feedback to be passed on the to architect. On an agile team, the solutions architect is working six to eight weeks ahead of the development team laying down the architectural runway. If the development team finds that some elements of the architecture are either missing or not working, it is important to pass that information along to the architect on a regular basis in order to correct the issues in upcoming iterations.

As a result of this feedback loop, many technical and architectural user stories will begin to appear on the backlog. These elements can appear either on a product backlog in the case of tactical changes, or as the Scaled Agile Framework® (SAFe™) tells us, enterprise changes may appear on the program backlog.

FIGURE 8 – Architectural Epics

figure 8

Image courtesy of ScaledAgileFramework.com, 2014

 

 

Please comment on this post and keep the conversation going. We’re constantly looking for better ways of doing things and get excited by helping others with #BecomingAgile. Learn more by checking out these additional resources:

About the Authors

Adam Mattis and Leslie Morse are colleagues at Davisbase Consulting and, combined, have over 29 years of experience delivering value with software and information systems.

Adam is a program manager by trade residing in Nashville, TN. He spends most of his time working with new teams adopting agile practices. You can reach him at adam.mattis@davisbase.com or on Twitter @AgitatedAgilist.

Leslie is a business analyst by trade and resides in Columbia, SC. Most often she engages with organizations initiating agile transformations. You can reach her at leslie.morse@davisbase.com or on Twitter @lesliejdotnet.

Categories: Companies

The Napoleon Corporal

Leading Agile - Thu, 11/20/2014 - 14:08

In my previous post, Replacing Backlog Grooming, I wrote about leveraging a Product Owner (PO) Team instead of the “Scrum” team in Progression Workshops (backlog grooming).

To clarify, the members of the PO teams are mainly populated by a Product Owner (Product Lead) and facilitator (could be a Scrum Master), but from there we’ll include others like a development lead, a testing lead, and an architect. We use the team construct over a single person because we’re operating at scale, with multiple delivery teams.  The Leads and Architects are thinking bigger-picture strategy and are aware of external dependencies that need to be avoided or dealt with.  The goal is to progress work along, getting it ready for the delivery team.  To help bridge the knowledge gap with the delivery teams, there are members of the delivery teams who will attend the progression workshops, mostly to play the part of the Napoleon Corporal. (I call them that, not the client)

For those unfamiliar with the term Napoleon Corporal:

Napoleon recognized how vital it was to have an enlisted soldier in the planning process. During every Battle Plans briefing Napoleon would have a Corporal shine his boots knowing that the Corporal was listening. Once the General Staff finished the brief, Napoleon would look down at the Corporal and asked if he understood the plan. If the Corporal answered, Yes Sir! The General would have his Staff execute the plan. If the Corporal answered, No Sir! The General would have the General Staff rewrite the plan.

It doesn’t matter if you’re doing textbook Scrum or something at scale.  Your people still need a shared understanding. If not, you’re going to start seeing a lot of delays and a lot of rework.

When you have a Scrum or Kanban team, you’re not always getting “A” players. Sometimes it’s a real mixed bag.  To expand the military metaphor, sometime you don’t get a Corporal. Sometimes, you get yourself a Boot Private.  If work is outsourced, developers and testers won’t necessarily have domain experience. They might be great coders or testers but not experienced in financial, medical, or other verticals.  You need to get them to understand the mission and the mission is not necessarily to write and test code. The shared understanding is how to solve a problem for the customer.

Depending on the experience of the delivery team, the conversation (and backlog) may need to be simplified enough to be understood by someone junior to a Corporal.

 

The post The Napoleon Corporal appeared first on LeadingAgile.

Categories: Blogs

9th International PMI Poland Chapter Congress

Leading Answers - Mike Griffiths - Thu, 11/20/2014 - 05:31
I will be in Warsaw next week for the 9th International PMI Poland Chapter Congress – themed “Mission Impossible”. I am very much looking forward to it and sessions like the “Global Challenges of Mega Projects” by Virginia Greiman of... Mike Griffiths
Categories: Blogs

Scrum Knowledge Sharing

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