Skip to content

Feed aggregator

Pliiing, Gong & TickTack: Timeboxen beenden

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

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

Der Timer

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

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

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

Laszlo Stein

Klangschale und Gong

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

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

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

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

Pliiing…

Related posts:

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

Categories: Blogs

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

Superman Syndrome

Agile Tools - Tom Perry - Mon, 10/20/2014 - 06:49

apple-bag-collaboration-154-820x550

There you are, in your tenth meeting of the day. You haven’t even had lunch, just one meeting after another. You’d skip the meetings, but you are required and half the meetings are yours anyway. You finish the day without having accomplished one single thing (except a bunch of meetings). Your todo list has only grown longer and the only time remaining is after hours (because nobody can schedule a meeting then). If this is you, then you might have superman syndrome.

It’s pretty common in software development. The nicest people get sucked into it (no, really, they’re too damn nice). You are competent, eager to please, and really can’t say no. It’s a great ego boost – you are needed! Well, I’ve got some bad news: you’ve got Superman Syndrome.

That’s right, you got it bad. Now sit down. This is where we get to play product owner. Product owner of your life. Write down that list of all thing things you have to do. Go ahead, put it in priority order. That’s right, it’s not easy. Product ownership is a bitch. Good, now cancel all your meetings. I know it hurts. Do it anyway. Send some polite excuse about being behind in your work (because it’s true) and you’ll catch up with them later (maybe never).

Now take that one thing at the top of the list (it is just one thing, right?) and get to work. Here’s the new rule, you don’t get to work on anything else until that thing is done. Take comfort in the fact that you are working on the most important thing that you could be working on. No one can fault you for that. You see what we are doing is limiting your work in progress (WIP). Limiting the amount of work you take on is like kryptonite to Superman Syndrome.

While we’re at it, let’s just turn outlook off. Yeah, completely off. You have a WIP limit here too: twice a day. Once before lunch and once before you go home. That’s it. That’s all.

While we are having so much fun setting WIP limits, we might as well put a WIP limit on your meetings. That’s right, nobody can reasonably expect you to do your job AND attend every single meeting: so don’t. Set a reasonable limit (no more than 2 hours of meetings/day). That way you are available if the issue is REALLY important, but otherwise, they’ll have to just get along without you. Again, polite apologies all around.

Try that on for a while and see how that works for you. Come back and chat with me when you think you are ready to change your WIP limits.

Now to take my own advice…wish me luck.

Yours truly, Superman
Filed under: Agile, Coaching Tagged: Coaching, meetings, superman, time management, WIP, work in progress
Categories: Blogs

LeanStartup : Customer Development Is Customer Coaching

One of the most important activities as a Lean Startup entrepreneur is building the right interviews that will help building the "right product", as the Pretotyping Manifesto tells us.  My latest experience as  a Lean Startup mentor was with Business School class students.  With me in the mentoring team ( and in the photo) were Florian Champagne , Sébastien Orifici, who holds the innovation course, and Frank Debane , whom I thank to have invited me to join the team. The intense experience of helping about 10 projects structure the good questions for customers interviews,  revealed how similar  customer development and coaching are.  The highest value in Customer Development comes from asking good questions . The highest value of a coaching session does from asking "powerful questions". Do you see a pattern here? Entrepreneurs Are Asked To Be ... Customer Coaches Entrepreneurs learn from the Lean Startup approach that the first think they need to do is to challenge their vision. They are asked to stay humble and not impose their solution over customers that , hmmm, may not want that at all. They are asked to listen to market's voice and adapt their solution instead of trying to influence customers behavior.  The top 3 recommandations in true Customer development approach are :
  1. Don't rely of vanity metrics : number of likes , followers , visits on your product idea page is no sign of commitment 
  2. Be aware of false positives : don't count your family and friends in the measure of your success 
  3. Customers are experts of the problem  : if you want to build a successful solution, listen to real problem of customers instead of your ideas of the problem. 
So let's summarize what is the recommended entrepreneur's behaviour : 
  • Listen and observe, don't push your assumptions 
  • Customer is expert of the problem, they will find the most adapted solution 
Coaching experts will tell that  "listen and don't provide solutions" is the right attitude of a coach. Coaching is not about providing answers, coaching is about helping clients come out with answers that they are the only one to have , as the problem is theirs. So you see it ? Bright entrepreneur skilled in customer development are ... customer coaches.
Interview Questions are Powerful Questions The Lean "Gemba Walk" turned in "Get Out Of The Building" activity in Lean Startup ( as Lean Startup Machine initially defined it ) . Briefly it invites entrepreneurs to get into the "customer arena" and proceed to customer face-to-face interviews instead of running fancy marketing customer study analysis from company's ivory tower. To have effective feed-back , there is a key condition : prepare the customer interviews and ask the right questions right.  What are the patterns of good customer interviews questions ? Here is a quick hint :
  • Don't ask closed questions ( that will get a Yes/No answer). Closed questions are the main source of false positive and you won't get much of the binary choice.
  • Ask "Why", "How", "What" questions to avoid closed questions. Don't hesitate to repeat them . 
  • Invite to storytelling: ask customers to tell  their experience in the domain you're interviewing about 
  • Be interested about their problem ,  customers talk, you listen . 

For those people that are familiar with coaching the interviewing pattern should ring a bell. Because what is asked from entrepreneurs to build a solid delighted customer base is to have a customer and market ... coaching attitude .
Emerging Marketing Approach
Traditional Marketing may teach us that the key to success is to create a need. Today's world of frugality that has a tendency to run away from consuming behavior is probably not aligned anymore on this vision.Marketing of tomorrow that will bring make entrepreneurs successful might shift from "owning the market" to "coaching the market".And "create the need" will definitively shift to "make customer realise they have a need that they were not truly aware about". A completely different story.

Related Posts
Test Driven Business Featuring Your Lean Startup Products
Entrepreneurs , What Is Your Unfair Advantage 
Lean Startup For Services 



Categories: Blogs

Simplicity of Measure

Agile Tools - Tom Perry - Sun, 10/19/2014 - 07:01

Fitbit_Dashboard

I got a fitbit bracelet the other day. It’s a pretty nifty gadget. It tracks the number of steps that I take in a day, as well as measuring movement while I’m asleep. I’ve been very impressed with the number of things that you can derive from a simple measure of the frequency of movement. You get number of steps, activity level, calories burned, sleep periods, and a few other metrics. All of that from one simple measure of how often my hand moves.  Admittedly, some of those measures are inferred based on some simple assumptions like how many calories that the average person burns in a fixed period of time. However there is nothing wrong with that, The measure doesn’t have to be 100% accurate in order for it to be useful to me. I can see the trends and understand if my calories burned is changing for the better or for the worse without having the exact number of calories that I burn in an hour. An approximation is certainly sufficient.

It’s really quite impressive that you can derive so much from a single metric. It made me wonder about the metrics that we keep on Agile teams. Whether it’s velocity or throughput, there are metrics that we use for a lot of different purposes. We use velocity to tell us how much work the team can take on per sprint. We derive duration using velocity. I like the notion of having a small set of metrics like velocity that we can use for a variety of measures.


Filed under: Agile, Tools Tagged: fitbit, measure, Metrics, Tools
Categories: Blogs

Make Resolving Impediments a Habit

Agile Tools - Tom Perry - Sat, 10/18/2014 - 08:43

David_City_Rey_grocery_store

I’ve talked a lot about the rigors of finding and resolving impediments for a team. There is one thing that I have left out: the people part. I learned this lesson at a conference that I was co-hosting. I had been in charge of setting up the food for the event. Getting the caterer, arranging for meals, that sort of thing. As you might imagine, it’s a pretty tough job to satisfy the dietary requirements for a very large group of people. I learned of whole categories of food allergies and needs that I had never even imagined existed! There was a little bit of every imaginable combination. Everything from your standard gluten free diet all the way to lacto-ovo-pesca-leguma-veganitarians (OK, I made that last one up).

We did the best we could to satisfy the needs of most folks and pretty much called it good. About halfway through the conference, someone mentioned that there was no food that fit in their dietary needs. I expressed my sympathies and referred them to the grocery store around the corner. I really didn’t give it another thought. A few minutes later, I heard the same complaint made by the same person, but this time the reply was, “I’ll get you something, I’ll be right back” And that person ran off to the store themselves. Wow!

I was humbled. The difference between my reaction and theirs was the difference between someone who could empathize and take action to resolve the impediment, and someone who couldn’t. The lesson I learned that day was that in order to help people with their impediments, it takes empathy. You have to feel their need, and be receptive to doing anything to help them out. I think I had missed that before. That willingness to serve the needs of others is really important. All the strategies in the world for resolving impediments won’t help anyone if you don’t care.


Filed under: Agile, impediment Tagged: Impediments, leadership
Categories: Blogs

Partnerships & Possibilities, Episode 2, Season 6

Partnership & Possibilities - Diana Larsen - Fri, 10/17/2014 - 15:00

Partnership & Possibilities: A Podcast on Leadership in Organizations
EPISODE 2: REVISITING INFLUENCE

Photo Credit: Send me adrift. via Compfight cc

How do  you observe yourself or your colleagues influencing each other? What kinds of influence do you see as critical for lasting positive changes?

Leave a comment on this blog or email us at info@futureworksconsulting.com

Summary

[1:40] Sharon is working with the leadership of a large non-profit with an enormous number of volunteers, who do the real work of the organization.

[4:00] Working with volunteers is all about building a sense of community and purpose to motivate people to do what needs to be done – all through “influence”.

[6:15] Power and influence are orthogonal.

[8:05] Compliance and influence are also different things.

[10:20] Motivation comes from within – it doesn’t get applied from outside. You can’t inoculate people with it.

[15:55] The model Sharon’s looking at currently looks at 6 types of influence.

[20:20] Convincing, selling, and so on, is also not influence. And influence will get you more mileage.

[22:23] Benefit must accrue on both sides for change to last – this is real influence.

[24:30] You can give feedback if you can do it with caring and respect. If you don’t care and respect the other person, don’t bother. The same is true of influencing – do I care about this person?

[28:00] An important element of influence is creating an environment that supports what you want to have happen.

 

Categories: Blogs

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

Scrumology.com - Kane Mar - Fri, 10/17/2014 - 08:53

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.

  • #IT #Job in #Strongsville, OH: Web Business Analyst – Agile Scrum Master 14-267 at Medical Mutual #Jobs
  • Check out this SCRUM MASTER Overview on YOUTUBE: #scrum #agile
  • RT @FreeScrumEbook: Check out this SCRUM MASTER Overview on YOUTUBE: #scrum #agile
  • How to Plan an Agile Sprint Meeting? – http://t.co/qfwlkKpZi6
  • Agile by McKnight, Scrum by Day is out! Stories via @AgileUniversity @BCSMemberGroups @KristinRunyan
  • Skyhook Wireless is looking for: Agile Project Manager (Scrum Master)
    #job
  • Why Are Scrum Teams Supposed to Be Small? #agile #scrum #development #framework
  • Pic from last nights event: GA Presents at Sydney Agile + Scrum Meetup. See more events at GA: http://t.co/AsofQyj2wd
  • I’m hiring – Scrum Master in Rock Island, IL #Scrummaster #agile
  • PessoALL, está aberto as inscrições para treinamento “Scrum Foundations” dia 22/11 #scrum #agile #adaptworks
  • Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • RT @yochum: Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • RT @yochum: Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • RT @yochum: Leading Answers – Mike Griffiths: The Economics of Compassion in the New Economy #agile #scrum
  • #jobs4u #jobs Seeking Boston Based Agile Project Leadership / Scrum Master / Product Owner … #projectmanagement
  • #HongKong #Jobs Application Developer, Java, Oracle, Unix, Linux, SQL, Agile, Scrum, Test Driven… #Job #HongKongJobs
  • RT @jobz4pm: #jobs4u #jobs Seeking Boston Based Agile Project Leadership / Scrum Master / Product Owner … #project…
  • Komt er een vierde vraag tijdens de daily standup? Kijk vanavond op #scrum #agile
  • Skyhook Wireless is looking for: Agile Project Manager (Scrum Master)
    #job
  • #Scrum Master With Agile Experience #ScrumJob #TCS #Chennai #Job @sathish_ganesh @vinothselvam F
  • Avoidance of Organizational Dysfunction Leads to Scrum Masters’ Failure – #Agile #Scrum
  • Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • RT @CodehireJobFeed: Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • RT @CodehireJobFeed: Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • Scrum Methodology, Mountain Goat Software | Scrum, as mentioned w.r.t JetBrains’ issue tracker framework
  • RT @yochum: New Article: Estimate Before, During, and After the Software Project #agile #scrum
  • 32 Scrum master interview questions – #scrum #coaching #agile
  • Do you know what are the characteristics of a great Scrum Master? Check if you have them: #scrum #agile #coaching
  • Video course: Scrum: An Introductory Course To #Agile | Was $99 Now just $24! | by @BrainConcert
  • RT @CodehireJobFeed: Kareo needs a Lead Software Engineer #irvine #angularjs #scrum #Play #Agile #SOAP via @codehire
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai, apply now! #job http://t.co/a4yzUUUK06
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Chennai, apply now! #job http://t.co/F7dE8ijORZ
  • RT @lgoncalves1979: 32 Scrum master interview questions – #scrum #coaching #agile
  • RT @ITJobsInChennai: #Scrum Master With Agile Experience #ScrumJob #TCS #Chennai #Job @sathish_ganesh @vinothselvam…
  • Scrum’s creators seek definitive place for Scrum knowledge #agile #scrum #ITlife #devlife
  • RT @Scrumartikelen: Leuk en duidelijk filmpje waarin het #agile #Manifest eenvoudig wordt toegelicht: #scrum
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture in #Chennai http://t.co/YwiYFna94j
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Chennai at #Accenture. Apply now! #job http://t.co/s7o7mVW8JC
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Chennai at #Accenture. Apply now! #job http://t.co/UWN1lqK0zg
  • ☆★☆ JOB ALERT ☆★☆ #Job #Malvern – Project Manager/Scrum Master (AGILE exp REQUIRED) view full details
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Chennai) #job http://t.co/kcMzdpIQTs
  • Agile Development and Scrum (@ Mood Cafe in Istanbul, Turkey) http://t.co/0YYjKee0mx
  • Bij zoeken we een Software Engineer BI – #Oracle #SQL #SCRUM #Agile
  • Categories: Blogs

    Scrum Knowledge Sharing

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