Skip to content

Feed aggregator

Lean Kanban France, Paris, France, November 5–6 2014

Scrum Expert - Fri, 10/24/2014 - 12:26
Lean Kanban France is a two-day conference focused on the Lean and Kanban approaches to project management that takes place in Paris, France. Presentations are in French and English. David Anderson, Bjarte Bogsnes and Don Reinertsen will present keynotes. In the agenda of Lean Kanban France you can find topics like “How do you help teams for whom Kanban is simply card walls? Beyond shallow implementation at scale”, “Becoming a Learning Organization the Kanban Way”, “Continuous delivery, a plug-in for Kanban “, “Cost of Delay workshop”, “Good and bad ways to ...
Categories: Communities

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

Scrumology.com - Kane Mar - Fri, 10/24/2014 - 09:08

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

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

  • 3 out of 4 people make up 75% of the population!… has 100,000+ users! #agile #scrum #poker
  • SL #APM: #Agile #Scrum #PM
  • RT @artarmin: 3 out of 4 people make up 75% of the population!… has 100,000+ users! #agile #scrum #poker
  • RT @yochum: Agile Tools – Tom Perry: Paired Mathematics #agile #scrum
  • Master Scrum: “The #Lean #Startup Principles … guidelines for taking flight in #agile https://t.co/ieTF5Bp61z
  • Are you unsure how to scale agile within your organisation? #agile #enterprise
  • Scrum Expert: Progress Software Acquired Telerik Teampulse Editor #agile #scrum
  • RT @yochum: Scrum Expert: Progress Software Acquired Telerik Teampulse Editor #agile #scrum
  • RT @yochum: Scrum Expert: Progress Software Acquired Telerik Teampulse Editor #agile #scrum
  • Getting things done by eating an Elephant – #agile #scrum http://t.co/URgfx2msuK
  • What does the Scrum Master actually do in agile projects? – http://t.co/ope64q4S85
  • What Characteristics Make Good Agile Acceptance Criteria? – http://t.co/RxFGxEdkb9
  • Scrum Framework Explained: #scrum #agile
  • RT @FreeScrumEbook: Scrum Framework Explained: #scrum #agile
  • Agile by McKnight, Scrum by Day is out! Stories via @henrikkniberg @astorrs @Saket_tg
  • #Agile – How does Planning Poker work in Agile? – http://t.co/og4lbSNDuY
  • “Sprint and scrum has been used to develop many of the most complicated designs in human history.” #agile
  • How to Plan an Agile Sprint Meeting? – http://t.co/dOiL1RRXVM
  • #HongKong #Jobs Java Developer, Java, Unix, Linux, SQL, Agile, Scrum, Test Driven Development,… #Job #HongKongJobs
  • #jobs4u #jobs C++ Engineer – Windows, MAC, Linux, Agile/Scrum, Cloud Computing #BOS #boston #MA
  • + istenen doğrultuda gitmesini sağlıyorsunuz.” #AgileLeadersST #agile #scrum
  • Serçelerimiz belirlendi! #AgileSparrow #agile #scrum
  • Yazarımız Yelda Erdoğan’ın ilk yazısı : “Agile Dönüşüm” #agile #scrum #adaptasyon #dönüşüm
  • RT @craigstrong: Gamify the cardwall #gamification #agile #teams #scrum #kanban #agile2014
  • Product Owner – Agile SCRUM #jobs #marketingjobs
  • How to #measure #efficiency of #scrum team. Find out here: @coMakeIT #cloud #agile #dedicatedteam #software
  • ¿Y qué pasa con la integración continua de bases de datos? (.jgarzas) #agile #scrum #agil #xp
  • RT @artarmin: 3 out of 4 people make up 75% of the population!… has 100,000+ users! #agile #scrum #poker
  • Об имитаторах, тлеющем Манифесте и Скраме #agile #scrum http://t.co/jinRh2sqNy
  • I’m hiring – Contract Agile Business Analyst in Slough, United Kingdom #job #scrum #agile
  • Sobre Project Management y otras historias de Agile Vía comu.iebschool.
  • Categories: Blogs

    Progress Software Acquired Telerik Teampulse Editor

    Scrum Expert - Thu, 10/23/2014 - 19:24
    Progress Software Corporation has announced that it has entered into a definitive agreement to acquire privately held Telerik AD for $262.5 million. Telerik enables its 1.4 million strong developer community to create compelling user experiences across cloud, web, mobile and desktop applications. Telerik is the supplier of the TeamPulse Agile project management tool that allows you to use Scrum, Kanban or your own process. Telerik’s revenue for the last twelve months was over $60 million, with annual bookings growth of over 20%. The combination of Progress and Telerik will create a ...
    Categories: Communities

    Sense, Create, and Respond to Change

    Rally Agile Blog - Thu, 10/23/2014 - 14:00

    Last week we looked at how today’s global markets require new ways of doing business, so that you can respond quickly to threats and opportunities. We showed you why it’s not enough simply to implement Agile practices into your development shop; you need to build agility into the culture and behavior of your entire organization. And we defined agility as the integral characteristic that allows you sense, create, and adapt to change -- quickly and confidently.

    The compelling driver of agility is the speed and impact with which innovations are changing entire industries -- what many refer to as disruption. McKinsey advises that the companies that have survived and thrived amid disruptive change are those that have developed capabilities for speed, transformation, and innovation:

    “ … these companies built the organizational capacity and agility required to lead during the disruption. They made big shifts in leadership focus and major changes to resource allocation, and they developed a faster organizational clock speed and leaner cost structure.”

    Lest you think disruption is something that hits you like a freight train, one you see coming from a mile away, consider the phenomenon of dematurity: this is what happens when companies in an established industry (say, healthcare, automotive manufacturing, or power) experience a series of small innovations over a short period. Over time these “mini-disruptions” add up, and in the aggregate they can cause radical changes to the industry.

    “It is all too easy to be caught off guard—to ignore the small changes that appear one by one, to fail to believe they will affect you, and to end up at the tail of the wave, outpaced by competitors who saw the possibilities earlier,” says PwC strategy and innovation advisor John Sviokla.

    “The solution lies in gaining better sensitivity—in other words, improving your ability to recognize and respond to the signals of incremental change."

    Get Outside the Building

    To sense change, your entire organization needs to be attuned to shifts in the market. You need to leave the office, in a literal and figurative way. You need to gain understanding of the technology driving change and innovation, and you need to regularly take the pulse of the customer.  

    As you sense change, your organization must be prepared to both “create” opportunities and “respond” to threats. This is where speed and agility come into play.

    Speed is paramount. Information Week’s 2014 Strategic Survey of CIOs cites speed of execution as their top concern. Market windows are incredibly tight, and big companies face competition from nimble start-up competitors.

    Agility is what gives companies the ability to move quickly and with confidence. It’s the product of having a disciplined approach to managing change. Agility isn’t a one-time thing; it should become part of your organization’s DNA.

    Where to Start

    We’ve identified three kinds of agility you need to build across your organization.

    Your foundation is execution agility, where speed and performance in your software development help you deliver value faster and gain a competitive advantage.

    Then you need to connect your execution with your strategy. Portfolio agility lets you create opportunities with focus and insight into your organization’s highest-value initiatives.

    At the broadest level, business agility builds responsiveness into your company culture. You’ll have the confidence to create change through lean innovation and the resilience to respond to change however it impacts you.


    Keep learning. Get a copy of the Business Agility Survival Guide.

    Rally Software
    Categories: Companies

    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

    Centralized Control : Trapped in Wagile (Part 4 of 4)

    Agile Thinking - Dhaval Panchal - Wed, 10/22/2014 - 21:00

    This is the last part in the series “Trapped in Wagile”. In the kick-off article I outlined three fundamental characteristics of waterfall organizations. In subsequent articles I explained Phase-Gates (part 2) and Large-batch handoffs (part 3). In this article I am diving deeper in to centralized control characteristics. Tendencies to centralize [...]

    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

    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

    Paired Mathematics

    Agile Tools - Tom Perry - 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

    QA Test Case Management with Axosoft

    About SCRUM - Hamid Shojaee Axosoft - Tue, 10/21/2014 - 19:29

    Test cases – it’s what QA guys and gals write when they aren’t testing. We figure some of our customers need a little boost when trying to incorporate their QA folks into the Axosoft tool, so here are a couple suggestions that might make life easier for the lovely faces at Quality Assurance.

     

    Summon the Custom Items Tab

    Surprise! You have a secret item type that you may not be using. It’s not enabled by default, so let’s first help you find this before we touch on test case management. First (assuming you’re both the admin and subscribed to our flagship product: Axosoft Scrum), go to Tools/ System Options/ General and you’ll see an unchecked box for Custom Items. Let’s check it and refresh.

    Check the Custom Items tab to enable this new item type.

    Check the Custom Items tab to enable this new item type.

     

    Then to enable the tab, just check it here.

    Then to enable the tab, just check it here. I know, I went bananas with the yellow arrows.

     

    Be sure your new tab is enabled like above. Voila, you now have access to a new item type. Please feel free to rename this to your heart’s content by going to Tools/ System Options/ System Labels. In this example, I’m going to rename this item, ‘Test Cases.’

    You can change the name here for any of your item types.

    You can change the name here for any of your item types.

     

    Hopefully you are starting to see some of the pieces fall into place. As its own item type, you gain access to a new array of unique workflows, field templates, and custom items for test cases. So writing these cases and organizing them into the right folders should feel pretty familiar (as if you were creating defect or feature requests).

    It's a who new backlog tab for testing, or whatever you need.

    You can create a new backlog tab for testing.

    Splendid! I have my backlog of test cases, but how do I tie them to the corresponding user story, defect, or item? Ah, with another Axosoft feature you may not be using: Related Items. If you go to Tools/ System Options/ Details Panel, you can check the boxes across all the item types to enable this feature.

    )

    Check the Related Items’ boxes across the board.

     

    Once we save, the Related Items pane will appear at the bottom of the Details Panel. Now all you need to do is select an item and create the relationship between other items, so in this example, let’s relate to test cases!

    Relate items from the details panel and hitting 'Add.'

    Relate items from the details panel and hit ‘Add.’

    Okay, so what does all this mean? It means your QA team should now be able to create test cases at will against a particular release. When they actually begin testing, each test case can move through the workflow until it is complete. QA can create worklogs for test cases as well, but Actual Duration won’t roll up across item types. If this is important to you, then check out a much simpler alternative below.

    Alternative #2: Let’s just use sub-items

    Should your testing be fairly straight-forward, consider using sub-items for your test cases instead. It’s pretty easy, all you do is select the primary item in question (probably a defect or feature), and nest a sub-item to represent your test case. The added advantage is that all your estimates and actual durations will roll up to the parent item. However, things might get hairy if you have a series of test cases you need to manage (that’s where the first option might be a better fit).

     

    Best Practice: Templates of Test Cases

    Our QA team must run a standard barrage of tests for each release. It’s the same set of tests, so they’ve created a folder within Axosoft that houses every single one of these cases. From here they just duplicate the folder…

    Select the project folder with all your Test Cases and do a detailed copy from the More menu...

    Select the project folder with all your Test Cases and do a detailed copy from the More menu…

     

    Now, toss the items into the QA release…

    Drag and drop the items over

    Drag and drop the items over

    And get to work!

    We hope this illuminates your testing options with Axosoft. At the very least, you now have a new item type at your disposal and a means to relate items together.

    Categories: Companies

    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

    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

    Time After Time

    Agile Tools - Tom Perry - 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

    Are Prejudices Stopping your Agile Efforts?

    Scrum Expert - Mon, 10/20/2014 - 17:40
    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. This article discusses these misconceptions and provides some tips on how to overcome these prejudices to get Agile adoption on track in your organization. Author: Kevin Dunne, QASymphony, http://www.qasymphony.com/ Adopting Agile may be the next big thing for your team, but adopting new practices always presents challenges for any organization. We all know ...
    Categories: Communities

    Waarom Agile?

    Ben Linders - Mon, 10/20/2014 - 17:16
    Agile werken kan je helpen om organisatiedoelen te bereiken. Agile tot een doel verheffen werkt meestal niet, het doel is om resultaten te bereiken, niet om agile te worden. Het is belangrijk om goed te weten waarom je de agility van je organisatie wilt vergroten en wat je met een agile werkwijze verwacht te bereiken. Continue reading →
    Categories: Blogs

    Agile Brazil, Florianópolis, Brazil, November 5–7 2014

    Scrum Expert - Mon, 10/20/2014 - 08:44
    Agile Brazil is a three-day conference that is the largest event about Agile and Scrum in Brazil. It features keynotes and practical presentations with local and international Agile experts. Talks are both in Portuguese and English. In the agenda of Agile Brazil you can find topics like “Taming Big Balls of Mud with Diligence, Agile Practices, and Hard Work”, “Pragmatic, Not Dogmatic TDD: Rethinking How We Test”, “Mental Models in High Performing Agile Teams”, “Extreme Pair Programming”, “Visual Regression Testing with PhantomCSS”, “UX Design for Startups”. Web site: http://www.agilebrazil.com/2014/en/ Location for the 2014 ...
    Categories: Communities

    Brauchen wir noch Daily Standups?

    Scrum 4 You - Mon, 10/20/2014 - 07:45

    Durch Zufall bin ich vor Kurzem auf den Service www.iDoneThis.com gestoßen. Als ich mir anschaute, was dort geboten wird, habe ich sofort an die “Daily“-E-Mail bei Web.de gedacht. Wir schrieben dort am Ende des Tages an den Teamleiter eine kurze E-Mail mit den Dingen, die wir heute getan hatten. So wusste er, was der Stand der Dinge war. Leider wurde das oft vergessen, weil es keinen automatischen Reminder gab. Die “Dailys” wurden immer länger und das Reporting wurde zur Last. Die Idee selbst fand ich jedoch immer gut. In meinem Unternehmen nutzen wir Confluence, ein Wiki von Atlassian, in dem wir ein “Logbuch” haben. In dieses Logbuch schreiben wir unsere Aktivitäten des Tages hinein. Daher gefällt mir vielleicht auch die die Idee von iDoneThis so gut. Denn nun bekomme ich am Ende des Tages eine E-Mail und kann eintragen, was ich getan habe. Diese E-Mail wird einfach per Reply beantwortet. Am nächsten Morgen schickt mir iDoneThis eine E-Mail mit allen Aktivitäten des Teams.

    So weit so gut – doch dann bin ich über die Kundengeschichten von iDoneThis gestolpert. Ganz besonders fasziniert hat mich die Geschichte von Bufferapp. Ich kenne Buffer als User und es gibt im Netz mittlerweile viele interessante Stories über diese kleine Firma. Die Story, die iDoneThis über Buffer erzählt, ist für einen Scrummie verblüffend: Sie sagen, dass Buffer die Daily Standups durch iDoneThis ersetzt hätte (den ganzen Text findet ihr hier):

    “As a remote team, Buffer needed a better way to stay on the same page. Previously, everyone would get on a daily group Skype call in which each person would take three minutes to talk about what they did, how their co-workers could help, and their improvements. With the team growing larger, the standup process wasn’t scaling over Skype, as they began to have to deal with Skype malfunctions, different timezones, and ever-increasing meeting lengths. Holding traditional standups over video chat also meant that “if you jump in and talk about something that somebody just said, you’re basically interrupting their three minutes. So what we would actually do is not ask that many questions.” They tried email, but it became a hassle as email threads got longer and longer, and each new message bumped the thread in everyone’s inbox and created another alert. Buffer turned to iDoneThis. It’s a way to understand what teammates are working on, and every time I read people’s iDoneThis, I feel connected with the team. With iDoneThis, rather than having to spend an hour in a meeting, you only have to read your email. We send an email to your team every evening asking, “What’d you get done today?” Just reply. The next day, we send a single email digest to everyone on the team with the contents of what might otherwise take a lengthly and tiresome meeting. Leo remarks, “It allows us to track performance, which easily gets lost in a chat room or an in-person standup. If new people come on board, they can look through and see what has been worked on. And of course, it’s amazing to keep in sync with everyone, working as a remote team. iDoneThis is invaluable to us and has changed our productivity for the better.”

    Unser Logbuch hat gegenüber dieser Lösung einen Nachteil: Ich muss nachschauen, was jeder getan hat. Hier bekomme ich automatisch einen Überblick. Kann diese Lösung das Daily Standup ersetzen? Ich bin mir nicht sicher – mit meinen Kolleginnen in Baden-Baden treffe ich mich jeden Morgen zum Daily Scrum per Google HangOut (Skype war einfach nicht verlässlich genug) und es ist großartig. Diese 15 Minuten sind für uns sehr wichtig. Was wir nicht haben, ist ein Board. Aber wir brauchen es auch nicht, denn es geht bei unseren Dailys nicht ums Reporting, sondern einzig um die Zusammenarbeit. Wir stellen bei unserer Arbeit bereits fest, dass das Nicht-Zusammensein schnell Fremdheit erzeugt. Mir immer wieder in Erinnerung zu rufen, wo die anderen gerade sind – selbst mit unserem Einsatzplaner LaLinea (ein selbst geschriebenes Einsatztool) verliert man schnell den Überblick. Vielleicht kann da ein Tool wie iDoneThis helfen. Probiert es für Euch doch mal aus. Lasst uns wissen, ob es hilft.

    Related posts:

    1. The 10 things I use most:
    2. Impact of collocation on team effectiveness – Study
    3. Boris is in Belo Horizonte and Recife, Brazil

    Categories: Blogs

    Scrum Knowledge Sharing

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