Skip to content

Feed aggregator

I am an ironing board

Business Craftsmanship - Tobias Mayer - Fri, 10/10/2014 - 17:46

Session Notes for Open Space session at Agile Open, California, Thursday 9th October 2014. Around 25-30 people in attendance.

image

Session title: Metaphor—Why?

Introduction: (System) metaphor is one of the original XP principles, but has been neglected over time in favor of other, more actionable principles such as test-driven development and continuous integration. A system metaphor creates a shared understanding, and its absence often creates misunderstanding and misalignment. In this session I’m interested in exploring metaphor, not specifically for code, but for human systems,and also individuals. Metaphor can create new understanding, new ways of looking at familiar situations. What might it mean, for example, to say to someone, “you are an ironing board”.

Part #1

For want of a plan of any kind, I started the session with this question, and asked participants to pair up and explore what it meant to them. Some pairs explored it from a personal perspective, and some from the perspective of their work role, e.g. developer or Agile coach. In sharing we focused on “I” statements, and paraphrasing…

"When I am folded away in a closet I see the world differently to when I am out in the open, being of service."

"I seek something hot and steamy to be pressed against me."

"I am the body of workers that supports the change agent (the iron) in removing the wrinkles in my organization (the clothing). Without me there is no foundation for improvement"

A nice corollary for this last one, from the iron’s perspective, was “If I stay too long I will burn a hole, and ruin what I am trying to improve.”

The neat thing about facilitating an open space session, is the sense of release. The session goes where it goes, and all I needed to do was embrace the ideas that emerged, turn them into offers, and suggest some containment for the dialog.

Part #2

The “I am” statement led a participant to be reminded of an improv exercise called Invocation, where an object is identified of spoken of in four different ways, each one taking the speaker from objectivity to subjectivity: “It is…”, “You are…”, “Thou art…” and “I am…” We practiced this framework in the second part, people finding a new partner and offering an object of their own choice, e.g. bird, flipchart marker, redwood tree, highway… The use of this framework led people to greater empathy. Was that what we were seeking with metaphor? Perhaps. The following discussion looked at the difference between the incremental understanding and the immediate jump to “I am”. The latter is more of an analogy: I am like this thing because… opening up new ways of seeing self, while the former takes the speaker deeper into a place of understanding of the other (thing). 

Note: when my partner struggled with the “Thou art” part, I asked him to recite a love sonnet to the flipchart marker he was holding. “Thou art an extension of my imagination…”, he began. I don’t recall the rest but it was very eloquent, and oddly moving. When he tried to do the same in front of the group he wasn’t able to, and afterwards commented how wrong it felt to express intimacy in front of a large group.

Part #3

We discussed the idea of using another person as the “object”. A traffic cop. 1) It is an authority figure, uniformed, unwelcome. 2) You are a man with a job to do. You need to earn a living like the rest of us. 3) Thou art a keeper of the law, a man with a mission. Thou art possibly a family man, seeking to improve the life of your family in the best way you can. Thou enforces the law because thou believeth in justice.” 4) I am a man with a mission, a believer in truth and justice. I care for my community and want to help others do the same. This had now moved beyond metaphor into a pure empathy exercise. Time for a retrospective. Are we getting what we want from this session? Where do we want to go now?

Retrospective

I asked for the five most vocal people to form small teams. Their job was to facilitate a dialog and not speak themselves. One of them asked, what, not speak at all? I had rather meant that they did not offer input but made sure all voices were heard, but this was an idea worth exploring. Yes, facilitate in complete silence. Feedback from the facilitators was interesting. In general it improved the ability to listen. The retrospective gave us three topics to explore further, so we created an short open-space-within-open-space. 

Part #4

  1. The use of metaphor in retrospectives—how would it help to ask participants to come up with a metaphor for the last sprint? What new avenues of exploration/understanding might it encourage?
  2. Exploring common metaphors, e.g. herding cats, war room, firefighting. Many of our metaphors are negative, or derogatory, creating a (perhaps) undesirable mindset. We looked for new metaphors, and the one that shone for me was a new way at looking at “cat herder” (a typical description of a project manager). I am a builder of playgrounds. This idea completely changes how one might approach their job: don’t try to manage the chaos, embrace it and support it with fresh imagination.
  3. Empathy via Invocation. Some wanted to explore this further. I have no notes for this short session.

Time expired, so the small groups dissolved. I asked those remaining at the end to practice with each other during the event, by simply offering a “you are an [object]” challenge to one another at random moments, and see what happened. As I left the eception at the end of the day, I offered a colleague “You are a stuffed mushroom”. I look forward to hearing what he had to say to the others in the group when we next meet.

Categories: Blogs

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

Scrumology.com - Kane Mar - Fri, 10/10/2014 - 10:20

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.

  • Cynical Agile and Scrum Dictionary – Yuriy Zubarev #LOL #Fun
  • RT @velkan12: great video about agile work flow #uzility #agile #kanban #scrum @UzilitySoftware
  • #Accenture is hiring! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) in #Kolkata, apply now! #job http://t.co/APOkPL5c4E
  • New #job opening at #Accenture in #Kolkata! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) http://t.co/HNDrDB5jYS
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Kolkata, apply now at #Accenture! #job http://t.co/J8EA4sSMW2
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) needed in #Kolkata, apply now at #Accenture! #job http://t.co/cq0jRBBEqV
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#job) wanted in #Kolkata. #Accenture http://t.co/nxNrcH441O
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/p7YkCMXHO2
  • How to Plan an Agile Sprint Meeting? – http://t.co/RDht7k2Quw
  • Check out this #job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at #Accenture (#Kolkata) http://t.co/gvDp7Ebrwp
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/sfvfCKO7nP
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/nbresrR6fT
  • #Accenture is hiring an Agile Methods (Scrum/FDD/XP/Crystal/DSDM), apply now! (#Kolkata) #job http://t.co/9YuKpxFYgf
  • @rkasper But wait- there’s more #agile #scrum #lean #management #innovation #leadership #triballeadership
  • How to be a Product Owner in 3 Steps — — #agile #scrum http://t.co/jUrGElkP3r
  • Try TargetProcess3 — fascinating agile project management software #targetprocess #kanban #scrum
  • New #job opening at #Accenture in #Kolkata! Agile Methods (Scrum/FDD/XP/Crystal/DSDM) http://t.co/kZJHjnRiTB
  • Apply now to work for #Accenture as Agile Methods (Scrum/FDD/XP/Crystal/DSDM)! (#Kolkata) #job http://t.co/oweptJLVwW
  • Agile by McKnight, Scrum by Day is out! Stories via @spencerhurst @SaraHitchcock
  • 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • RT @AstrolabeMe: Cynical Agile and Scrum Dictionary – Yuriy Zubarev #LOL #Fun
  • RT @mscurah: 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • Medical Mutual: Web Business Analyst – Agile Scrum Master 14-267 (#Strongsville, OH) #IT #Job #Jobs
  • RT @mscurah: 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • RT @mscurah: 5 Myths About #DevOps… And One Hard Truth via @Champagnie #Agile #PM #Scrum
  • I liked a @YouTube video Best Online Agile Scrum Project Management Methodology Certification
  • #Accenture is hiring an Agile Scrum #Master in #SanFrancisco, apply now! #job http://t.co/paRu7PGY3H
  • RT @MasterScrum: The Lorax Would Be a Great Product Owner!
    Lessons in #scrum from a Dr Seuss classic. #agile
    http://…
  • RT @yochum: Spotify engineering culture (part 2) #agile #scrum #startup http://t.co/yo5LFi6ffc
  • RT @yochum: Spotify engineering culture (part 2) #agile #scrum #startup http://t.co/yo5LFi6ffc
  • RT @yochum: Spotify engineering culture (part 1) #agile #scrum #startup http://t.co/vLrxNsGCxq
  • Keep it Simple: What is Agile SCRUM: #scrum #agile
  • RT @AstrolabeMe: Cynical Agile and Scrum Dictionary – Yuriy Zubarev #LOL #Fun
  • RT @FreeScrumEbook: Keep it Simple: What is Agile SCRUM: #scrum #agile
  • Your stuff is too big make it smaller! #agile #scrum #thatsIntelligence
  • RT @christianlmiles: Your stuff is too big make it smaller! #agile #scrum #thatsIntelligence
  • Managing in Agile – Introducing Scope Changes
    via @AgilePJ
    #PMI-ACP#Agile#Scrum
  • #Scrum vs. #Kanban – an interesting discussion… #ScrumvsKanban #Agile
  • RT @terealvarezv: “@ShirlyRonenRL: AgiloPedia: #Stattys – Write & Slide #scrum #agile” ~~ #worthwatching
  • Agile Canada » Project Manager & Scrum Master – Colligo Networks – Vancouver, BC: Evange… #Canada #Agile #Jobs
  • #DevOps team? DevOps toolchains! #agile #scrum http://t.co/F1NlEriG1s
  • RT @Neomobile_Group: #DevOps team? DevOps toolchains! #agile #scrum http://t.co/F1NlEriG1s
  • RT @CriticalMfg: Yes, we’re #lego fans RT @CriticalMfg: Scrum training @ Critical Manufacturing #scrum #agile http:/…
  • Plus d’infos sur TV du stand @sii_ouest #atrennes #managementVisuel #calottes cc @msieur_tim http://t.co/kegUvh7Zwa
  • New #job: Business Analyst – Ecommerce / Agile / Scrum / Web Applications,Chester .. #jobs
  • RT @yochum: 10 Things You Could Do When You’re Done Writing Code #agile #scrum
  • Categories: Blogs

    Empower Teams to Increase Quality

    Ben Linders - Fri, 10/10/2014 - 09:29
    When an organization is experiencing quality problems with their products, agile software development often isn't the first solution that comes up in people's minds. Often I see people trying to address them using classical waterfall based approaches, only to find out that it will make problems even worse. I recommend agile, not only to deliver working software faster but also with the right quality. This posts shows how empowering the team helps to increase the quality of product. Continue reading →
    Categories: Blogs

    Post Mortem Magazine

    Agile Tools - Tom Perry - Fri, 10/10/2014 - 09:23

    console-controller-games-498-825x550

    Years ago I used to read a magazine called Game Development (at least I think that was it). I’ve never worked in game development myself, but I found it fascinating to take a little peek into the world of the game development teams. They were always working on some cutting edge game engine technology that enabled “the next generation of jaw dropping graphics” and some form of ridiculously enhanced gaming experience. At the time it seemed to me like the game developers were very much the real deal – the applications I wrote were childish by comparison. The level of performance optimization they engaged in was astronomical compared to anything I dealt with. The geometry they used to describe the 3D worlds they created was a language all it’s own. It looked like all the cool kids were in gaming.

    There was a regular article in the magazine called something clever like “Post Mortem”. Every month they would publish a post mortem written by a project manager or team that had just released a new game. These were not happy-go-lucky-aren’t-we-cool reports. No, these were unflinching, unsparing critiques of all that happened on the project. There was drama, daunting challenges, and total train wrecks. This stuff was riveting!

    I used to think to myself, “Everybody should be doing this!” I was already working on agile projects at the time. I was dutifully doing a team retrospective every 2 weeks, but I never got the nerve to publish one. I probably should have, but I didn’t think at the time that our stuff would be all that interesting (in hindsight I have had my fair share of project train wrecks). Nobody else published post mortems either. This gaming magazine was the only place I’ve seen them widely published.

    It would be interesting to have a magazine composed of just project post mortems and retrospectives. In a very real way it would be a collection of experimental results. Some of those experiments would be successes and many would be failures, and each and every one of them would be useful.

    Of course who would read such a publication? Project Management geeks? Scrum Masters? And what would we advertise in this little catalog of triumphs and disasters? Anti-depressants? Liquor? Well, all kidding aside, I really do think it would be useful. Of course nobody makes magazines anymore. It would have to be a blog or something. Not a bad idea really. Hmmm…


    Filed under: Agile Tagged: Agile, development, Games, gaming, post mortem, retrospectives, Teams
    Categories: Blogs

    Die Sache mit der Freiwilligkeit

    Scrum 4 You - Fri, 10/10/2014 - 07:30

    Ich war diesen Sommer in London auf Urlaub. Und ja so wie es sich für das Londoner Wetter gehört, gab es auch im Sommer viel Regen. Nun gut, was tun im Regen? Am besten in eines der tollen Museen gehen. Die große Überraschung: Man kann die einige Stockwerke umfassenden Standard-Ausstellungen gratis besuchen! Am Ausgang ist es jedem selbst überlassen, ob er an das Museum Geld spenden möchte. Alle Mitarbeiter betonen immer wieder, dass man völlig freiwillig spenden kann und keinerlei Zwang herrscht.

    Für mich als Wienerin war das tatsächlich etwas ungewohnt. Drei Museen später leuchtete es mir aber immer mehr ein: Ich hatte in den letzten drei Museen viel mehr gespendet als den Richtwert, den die Museen vorgeschlagen hatten. Ich wusste nicht so richtig warum, aber ich genoss jede Ausstellung viel leichter und ungezwungener (ich hatte ja auch keine Unmengen für den Eintritt gezahlt). Beim Rausgehen spendete ich wegen der guten Erfahrung und der mir zugestandenen Freiwilligkeit also viel mehr.

    Das Thema der Freiwilligkeit taucht immer wieder in vielen Scrum-Teams auf. Soll es eine Anwesenheitspflicht geben für die Dailys, Sprint Plannings, Reviews und Retrospektiven? Viele sagen, es herrsche absolute Anwesenheitspflicht, jeder habe zu erscheinen, da sich das Team sonst nicht selbst organisieren könne. In vielen Teams werden Einladungen für alle Meetings versendet und es wird erwartet, dass man teilnimmt. Da ist von Freiwilligkeit keine Rede.

    Vor einigen Wochen habe ich einen Kollegen getroffen, der mir von einem Team erzählte, mit dem er anfangs als ScrumMaster Schwierigkeiten hatte. Das war für mich nichts Überraschendes, bis er erwähnte, er hätte den Teammitgliedern von Anfang an gesagt, sie müssten nicht in die Meetings kommen. Sie würden zu 100 % auf Freiwilligkeit beruhen. In der Runde herrschte Verwunderung: Wie sollten denn die Meetings funktionieren, wenn die Leute keine Lust hätten und dann auch noch alles auf ihrer Freiwilligkeit beruhte?

    Der Kollege meinte nur, dass innerhalb eines Sprints alle Teammitglieder zu den Dailys dazugestoßen seien. Sie wären pünktlich gewesen und hätten alle Scrum gemacht – bis auf einen. Dieses eine Teammitglied nahm auch nach zwei Sprints nicht an den Dailys teil, sah sich das Taskboard an und beendete seine Storys zeitgerecht. Er nahm aber nur an den Meetings teil, an denen er teilnehmen wollte. Im dritten Sprint nahm er am Daily teil, in dem er bisher nur zugesehen hatte. Im vierten Sprint schrieb er bereits eigene Tasks. Im fünften Sprint half er dem PO mit komplexeren Storys, die in seinem Fachgebiet lagen. Inzwischen sind fast sechs Monate vergangen, das komplette Team nimmt an allen Meetings teil und organisiert sich selbst ganz freiwillig.

    Man muss Menschen manchmal etwas mehr Vertrauen schenken, als man vermutlich möchte, aber es zahlt sich aus. Alle Museen in London können sich durch die freiwilligen Spenden ihrer Besucher erhalten.
    Jeder spendet so viel wie er kann oder will – und siehe da, es ist möglich.

    Related posts:

    1. ScrumMeetings moderieren oder „ein ScrumMaster hat nichts zu tun“
    2. Klassiker | Sprint Planning
    3. Certified ScrumMaster class in Wien | 5 Mai 2008

    Categories: Blogs

    VersionOne and CA Technologies Partner on Agile Project Management

    Scrum Expert - Thu, 10/09/2014 - 18:42
    CA Technologies and VersionOne have unveiled a PPM (Project & Portfolio Management) and Agile project management solution integration that gives technology leaders the insight to strategically plan, manage and track both Agile and waterfall project portfolios from concept to completion in a single console. Available today, native integration between the latest release of CA PPM (formerly CA Clarity™ PPM) and the VersionOne® Agile project management solution helps software organizations extend upstream visibility of Agile projects, presenting them as prioritized strategic investments into their overall portfolio planning, funding and resource management process. Portfolio ...
    Categories: Communities

    Agile Scrum Master, Square One Resources , Norwich, UK

    Scrum Expert - Thu, 10/09/2014 - 18:00
    Agile Scrum Master is immediately required by leading global organisation based in Norwich. Extensive experience working as an Scrum Master is required. Experience sharing scrum initiatives through the whole organization, collaborating with the rest of Scrum Masters. Great communication and coaching skills, a good story teller. Passionate about Agile and lean ways of working, passionate about team dynamics. Good understanding of the software development process. Really cares about people, know how to motivate people and help the team to be high performance. Challenge the team when needed. Ability to coach individuals and ...
    Categories: Communities

    10 Things You Could Do When You’re Done Writing Code

    The Agile Management Blog - VersionOne - Thu, 10/09/2014 - 16:45

    So you’re two-thirds of the way through your iteration and there are no more development tasks to complete. Nice work! Understandably, your instinct is to pull another story into the iteration, but doing so has risks and disadvantages. When you add additional work into the iteration, you’re increasing the batch size. This causes additional complication due to increased changes in the code base. It usually results in carryover, which has a demoralizing effect on the team. And it eliminates an opportunity to get feedback on the emergent product before additional work is embarked on.

    Remember, the iteration was planned so that all members of the team can function at optimum efficiency, not so that the developers can program at optimum efficiency (Yes, there is a difference).

    Before you peek into your product owner’s backlog and working on something outside the iteration plan, have a look at this list and consider doing one or more of these things instead:

    1.  Refactor something you recently wrote
    2.  Add unit tests to an uncovered area of code
    3.  Find a technical tutorial on the Internet
    4.  Offer to pair with a developer on another team
    5.  Estimate open items in the backlog
    6.  Create some automated functional tests
    7.  Clean your desk
    8.  Ask your product owner about the next release
    9.  Help your product owner create acceptance criteria for items in the backlog
    10. Implement a prioritized improvement suggestion from the last retrospective

    This isn’t an exhaustive list. What am I missing? Let’s see how many more items we can add to it. Give me your ideas in the comments, or tweet them – @johnkrewson.

    Categories: Companies

    Small Internal Releases Lead to Happy Customers

    Johanna Rothman - Thu, 10/09/2014 - 15:42

    If you saw Large Program? Release More Often, you might have noted that I said,

    You want to release all the time inside your building. You need the feedback, to watch the product grow.

    Some of my clients have said, “But my customers don’t want the software that often.” That might be true.  You may have product constraints, also. If you are working on a hardware/software product, you can’t integrate the software with the hardware either until the hardware is ready or that often.

    I’m not talking about releasing the product to the customers. I’m not talking about integrating the software with the hardware. I’m talking about small, frequent, fully functional releases that help you know that your software is actually done.

    You don’t need hardening sprints. Or, if you do, you know it early. You know you have that technical debt now, not later. You can fix things when the problem is small. You see, I don’t believe in hardening sprints.

    Hardening sprints mean you are not getting to done on your features. They might be too big. Your developers are not finishing the code, so the testers can’t finish the tests. Your testers might not be automating enough. Let’s not forget architectural debt. It could be any number of things. Hardening sprints are a sign that “the software is not done.” Wouldn’t you like to know that every three or four weeks, not every ten or twelve? You could fix it when the problem is small and easier to fix.

    Here’s an example. I have a number of clients who develop software for the education market.  One of them said to me, “We can’t release all the time.”

    I said, “Sure, you can’t release the grading software in the middle of the semester. You don’t want to upset the teachers. I get that. What about the how-to-buy-books module? Can you update that module?”

    “Of course. That’s independent. We’re not sure anyone uses that in the middle of the semester anyway.”

    I was pretty sure I knew better. Teachers are always asking students to buy books. Students procrastinate. Why do you think they call it “Student syndrome”? But I decided to keep my mouth shut. Maybe I didn’t know better. The client decided to try just updating the buy-the-book module as they fixed things.

    The client cleaned up the UI and fixed irritating defects. They released internally every two weeks for about six weeks. They finally had the courage to release mid-semester. A couple of schools sent emails, asking why they waited so long to install these fixes. “Please fix the rest of these problems, as soon as you can. Please don’t wait.”

    The client had never released this often before. It scared them. It didn’t scare their customers. Their customers were quite happy. And, the customers didn’t have all the interim releases; they had the planned mini-releases that the Product Owner planned.

    My client still doesn’t release every day. They still have an internal process where they review their fixes for a couple of weeks before the fixes go live. They like that. But, they have a schedule of internal releases that is much shorter than what they used to have. They also release more often to their customers. The customers feel as if they have a “tighter” relationship with my client. Everyone is happier.

    My client no longer has big-bang external releases. They have many small internal releases. They have happier customers.

    That is what I invite you to consider.

    Release externally whenever you want. That is a business decision. Separate that business decision from your ability to release internally all the time.

    Consider moving to a continuous delivery model internally, or as close as you can get to continuous delivery internally. Now, you can decide what you release externally. That is a business decision.

    What do you need to do to your planning, your stories, your technical practices to do so?

    Categories: Blogs

    The Life of a Product Owner Proxy

    Scrum Expert - Thu, 10/09/2014 - 12:20
    Being a Product Owner (PO) Proxy is difficult. You are pulled between product managers and engineers, holding the middle ground can be a challenge. Translating technical issue to Product Management and Customer issues to Engineering is a valuable task, but sometimes it can feel like a thankless one too. This presentation shares experiences and thoughts on this challenging but not often coveted role.Video producer: http://agileprague.com/
    Categories: Communities

    Bosnia Agile Day, Sarajevo, Bosnia and Herzegovina, 27 October, 2014

    Scrum Expert - Thu, 10/09/2014 - 10:07
    The Bosnia Agile Day is a one-day conference that bring international and local Agile experts to discuss Agile software development and project management practices like Scrum. In the agenda you can find topics like “The Disciplined Agile Enterprise: Harmonizing Agile and Lean”, “Fitness for Purpose – The Kanban way for focused Agility”, “Coordinating Large Agile Projects”, “Scrum in practice – Developer’s view”, “Agile Secure Development”, “Effective Agile Teams – Behind the open door” Web site: http://agile.ba/en/events/event/16-bosnia-agile-day-2014 Location for the 2014 conference: Hotel Sarajevo, Džemala Bijedića 169 A, 71000 Sarajevo, Bosnia and Herzegovina
    Categories: Communities

    A Team Named “Sue”

    Agile Tools - Tom Perry - Thu, 10/09/2014 - 08:32

    Johnny_Cash_(1964)

    My daddy left home when I was three
    And he didn’t leave much to ma and me
    Just this old guitar and an empty bottle of booze.
    Now, I don’t blame him cause he run and hid
    But the meanest thing that he ever did
    Was before he left, he went and named me “Sue.”

    -Johnny Cash, A Boy Named Sue

    I love this song. It makes me chuckle every time I hear it. Its a story about a man who names his son “Sue” because he knows it will be the source of mockery and make him into a stronger man. It’s a tongue in cheek little rhyme that covers themes of fathers, sons, manhood and what’s in a name.

    Today I was looking at a list of team names. Every single team in the list had named themselves after whatever they were working on. For example, there might be names like Printing Team, or UI Team, or Database Team. And check this out: if there was more than one Printing Team, guess what they called the second team? You got it: Printing Team 2.

    I shook my head and thought to myself, “Who named you Sue?”

    Right off the bat, I have to confess that I’m really a bit mystified by this kind of behavior. I refuse to believe that a normal human being, not coerced by any outside force, would name themselves after whatever they are working on. I’m working on a Mac right now. Maybe I should change my name to Mac too…nope…not gonna do it. It doesn’t make any sense to me (and I’m not really Scottish). I would rather name myself after something fun or aspirational. I’d use things like:

    • Mountains (Team Everest, Denali, or K2)
    • Animals (Team Angus, Viper, or Gerbil)
    • Cartoon Characters (Team Mickey, Goofy, or Donald)
    • Tools (Team Hammer, Bandsaw, or Monkey Wrench)
    • Rock bands (The Police, Metallica, or Tower of Power)

    The possibilities are endless…just like my cliches. Often I think that a team is either intentionally or unintentionally given a name by those who are sponsoring or responsible for setting up the team. After all, early in a project, before everyone shows up, you need a name for this new thing. Often this name is used purely for utilities sake, perhaps with the assumption that the team will replace the name with one of their own. The team adopts it by default, because that’s what everyone else calls them, and they never bother to change it again.

    I’m sure there are also places that just tell teams what they want them named. Hello, welcome to Acme! We’re going to put you on team “Sue”. I think that’s ridiculous. Here are my rules for team naming (don’t worry, no one will adopt them):

    1. You can’t name yourself after what you are working on
    2. No one individual can name the team. The team must name itself

    If you want someone to feel empowered and respected, you really need to let them decide what they are going to be called. If you can’t even do something as trivial as that, then you are probably going to struggle in other areas too.

    So what are your rules for naming teams?

     


    Filed under: Agile, Coaching, Teams Tagged: empowered, Johnny Cash, label, naming, Teams
    Categories: Blogs

    Persönliches geht vor Fachlichem

    Scrum 4 You - Thu, 10/09/2014 - 07:30

    Im Business ist es wie in anderen Bereichen des Lebens auch: Es funktioniert in erster Linie über persönliche Beziehungen. Mag ich jemanden persönlich, nehme ich sogar fachliche Mängel in Kauf.

    Glaubt Ihr nicht? Ich wohne in Prenzlauer Berg in Berlin, da gibt es eine Weinbar, die von einem Italiener geführt wird. Niemand nennt den Namen der Bar, wenn er da hingeht, alle gehen zu Johnny. Johnny begrüßt alle herzlich und persönlich, egal wie groß der Stress ist. Für die persönliche Begrüßung nimmt er sich Zeit. Und er macht ganz klar, dass gerade Du ihm besonders wichtig bist. Außerdem ist Johnny großzügig. Es gibt zu jedem Wein immer ein großes Glas Leitungswasser, das ständig nachgefüllt wird, und zu jedem Getränk gibt es einen kleinen Teller Tapas dazu.

    Der Laden ist immer voll. Die Leute mögen es gemocht zu werden und nehmen die mittelmäßige Qualität in Kauf. Die Weine sind so la la. Geraucht werden darf auch, was im Winter in dem kleinen Laden zu tränenden Augen führen kann. Im Sommer sitzt man draußen und ab 22:00 Uhr kommt er alle 5 Minuten vorbei und macht “psst” wegen der Nachbarn. Das hindert niemanden daran, zu Johnny zu gehen.
    Wenn ich den Menschen Wertschätzung entgegenbringe, ihnen zeige, dass ich sie mag und gern mit ihnen arbeite, ihre Stärken sehe und kommentiere – dann muss ich mit meiner fachlichen Kompetenz schon sehr neben den tatsächlichen Anforderungen liegen, bevor der Kunde sich gegen eine weitere Zusammenarbeit entscheidet. Solange ich noch etwas finde, was mir bei Johnny schmeckt, Bier statt Wein z.B., werde ich weiter hingehen. So lange ihr einen Mehrwert für den Kunden liefert, wird er einen Grund finden, euch zu halten. Wer sich jetzt an das super-leckere Restaurant erinnert, in dem der Kellner so pampig war, der weiß genau, was ich meine.

    Jetzt glaubt ihr mir vielleicht und sagt: “Gut, dann bin ich eben nett zu den Leuten.” Aber es gibt da eine Schwierigkeit. Ich kann nicht vortäuschen, dass ich jemanden mag. Und ich werde die Person nicht mögen, ihre Stärken gar nicht sehen, wenn sie Eigenschaften hat, die ich an mir selbst nicht mag. Das heißt, um stabile, wertschätzende persönliche Beziehungen aufzubauen, werde ich an mir selbst arbeiten dürfen. Schatten integrieren, wie es so schön heißt. Mich also mögen lernen, so wie ich jetzt gerade bin. Johnny hat eine intakte und stabile Familie. Er ist emotional satt und genährt und kann dadurch ganz viel Herzlichkeit verschenken.

    Wem es zu anstrengend ist, das Herz des Kunden zu gewinnen, der kann natürlich weiterhin durch hohe fachliche Qualität und zeitliches Engagement den Verstand des Kunden überzeugen.

    Wo und wie nährt ihr euch fachlich und persönlich?

    Related posts:

    1. S wie Scrum
    2. Mr. Change, könnten Sie meine Gefühle bitte etwas weniger aufwirbeln?!
    3. Reading: Johnny Bunko — The Last Career Guide you´ll ever need

    Categories: Blogs

    Phase-Gates : Trapped in Wagile (part 2 of 4)

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

    In previous article, I outlined three fundamental characteristics of waterfall system. Phase-gates are the most distinguishable characteristic of a waterfall organization.

    Recap

     Phases are are strictly linear sequence of activities to build a product or deliver a project. These activities are divided along process lines. Funding and progression to the next sequential [...]

    Categories: Blogs

    Large Program? Release More Often

    Johanna Rothman - Wed, 10/08/2014 - 15:47

    I’m working on the release planning chapter for Agile and Lean Program Management: Collaborating Across the Organization. There are many ways to plan releases. But the key? Release often. How often? I suggest once a month.

    Yes, have a real, honest-to-goodness release once a month.

    I bet that for some of you, this is counter-intuitive. “We have lots of teams. Lots of people. Our iterations are three weeks long. How can we release once a month?”

    Okay, release every three weeks. I’m easy.

    Look, the more people and teams on your program, the more feedback you need. The more chances you have for getting stuck, being in the death spiral of slowing inertia. What you want is to gain momentum.

    Large programs magnify this problem.

    If you want to succeed with a large agile program, you need to see progress, wherever it is. Hopefully, it’s all over the program. But, even if it’s not, you need to see it and get feedback. Waiting for feedback is deadly.

    Here’s what you do:

    1. Shorten all iterations to two weeks or less. You then have a choice to release every two or four weeks.
    2. If you have three-week iterations, plan to release every three weeks.
    3. Make all features sufficiently small so that they fit into an iteration. This means you learn how to make your stories very small. Yes, you learn how. You learn what a feature set (also known as a theme) is. You learn to break down epics. You learn how to have multiple teams collaborate on one ranked backlog. Your teams start to swarm on features, so the teams complete one feature in one iteration or in flow.
    4. The teams integrate all the time. No staged integration.

    Remember this picture, the potential for release frequency?

    Potential Release Frequency

    Potential for Release Frequency

    That’s the release frequency outside your building.

    I’m talking about your internal releasing right now. You want to release all the time inside your building. You need the feedback, to watch the product grow.

    In agile, we’re fond of saying, “If it hurts, do it more often.” That might not be so helpful. Here’s a potential translation:  “Your stuff is too big. Make it smaller.”

    Make your release planning smaller. Make your stories smaller. Integrate smaller chunks at one time. Move one story across the board at one time. Make your batches smaller for everything.

    When you make everything smaller (remember Short is Beautiful?), you can go bigger.

    Categories: Blogs

    Interviewing Programmers – start with code

    Diary of a ScrumMaster - Tom Howlett - Wed, 10/08/2014 - 12:24

    I spent the day yesterday interviewing programmers for a new start-up near Bristol. It’s a job I love. I’m always intrigued to hear about peoples careers and how the approach the challenges we present. For me recruiting a programmer has to start with code. I don’t really care about the CV and the application process for this job involved a quick coding problem. Passionate programmers are able to communicate their ability far more easily through code than by  describing their experiences.

    Traditionally interviews usually start with a discussion about the role and the candidate’s past experience. It’s often an uncomfortable conversation, everyone is a bit nervous and out of their comfort zone and I rarely get anything useful from it. I’ve learn’t that if you start with code, sitting side by side, sharing thoughts on the pre-interview problem, good candidates quickly relax. Then is the time to asking questions that go beyond programming. For me these questions focus on how they like to collaborate with others. I’ve noticed the answers I get after we’ve looked at code are very different. Some trust and mutual respect has been established and people tend to share more openly how they really feel.

     


    Categories: Blogs

    What is Scrum? (slides from my talk at KTH)

    Henrik Kniberg's blog - Wed, 10/08/2014 - 10:10

    Here are the slides for my talk “What is Scrum?” at KTH (Royal Institute of Technology). It was a guest talk at a course called Projektstyrning. Hoping to inspire young entrepreneurs to plant agile DNA in their companies from the very beginning. Last time I spoke at KTH was 6.5 years ago, that’s when I met the first Spotify team, and I’m really happy to have been able to influence and participate in their journey!

    Here are some sample slides from the talk:

    What is Scrum? Screen Shot 2014-10-07 at 08.20.00 Don't go overboard with agile

    Categories: Blogs

    Living in the Space Between the Notes

    Agile Tools - Tom Perry - Wed, 10/08/2014 - 08:26

    black-and-white-classic-concert-1601-825x550

    “The most critical aspect of the work, both artists said, was not the objects themselves, but the space between objects.”

    -Daniel J. Levitin, This is Your Brain on Music

    As I was reading Levitin’s book this evening I came across the quote above and had to pause. Levitin does an excellent job of explaining musical concepts like pitch, timbre, tempo and harmony in an easily accessible way. He was making the point that the art in music can be just as easily found in the absence of things as in the presence of the aforementioned properties. The moment between each note being just as much a part of the music as the actual notes themselves.

    It made me wonder where “the space between objects” could be found in our teams and our processes. I think there are a few different ways you could interpret that sort of space in terms of how we work with teams. With any methodology that you practice, there are well established notes that you play. There is a cadence or rhythm to the standup meetings. You find a tone or pitch of the conversation. And sometimes, if you get really lucky, you just might find harmony.

    So what would we find in that space between the notes? If I’m assessing a value stream, then you could describe the work steps as the notes and the delay between steps as the waste or absence of value adding work – the empty space, if you will. Can a value stream have a rhythm and a meter? In other words, although you can reduce waste, perhaps even eliminate some of it, you never get rid of all of the waste. The speed with which work flows through the process increases, and you have a faster tempo.

    Another way of considering the space between notes would be to observe that all of our work gets done at a different pace depending on what we are trying to accomplish. There are times when the pace is slow, when we are learning and struggling with new ideas. And there are times when the pace is fast, and life goes all “Heavy Metal” on us. What varies is the slack that you give yourself when you work. I find that when I want to come up with ideas, I need a fair amount of slack, or unscheduled time. I need to doodle and noodle and put spit wads on the ceiling. I need space to think or perhaps more importantly, to NOT think. On the other hand, when the work is coming fast and furious, I know that I’m very likely going to have a hard time creating anything new, let alone remembering what I had for lunch.

    The real work lies in the space between our ceremonies. What sort of tune are you playing?


    Filed under: Agile, Process Tagged: Agile, music, notes, rhythm, space, Teams, work
    Categories: Blogs

    Zwei Jahre Scrum bei EWE

    Scrum 4 You - Wed, 10/08/2014 - 07:30

    Mit Neugier und Aufregung hat die easy+ Mannschaft von EWE am 8. Oktober 2012, also genau vor 2 Jahren, ihr erstes Scrum Intro Training erlebt. Inzwischen sind bis zu 12 Scrum Teams für die Weiterentwicklung des Abrechnungs- und Kundenmanagement-Systems zuständig. Wir sind stolz, dass wir diese großartige Mannschaft in den letzten zwei Jahren begleiten durften! Alle haben mutige Schritte zur Agilität gemacht, mit den unvermeidlichen Höhen und Tiefen – vor allem aber hat es auch viel Spaß gemacht. In unserer Case Study könnt ihr nachlesen, welchen Weg wir gegangen sind. Inzwischen sind im Konzern andere Initiativen entstanden, die von Lean und agilen Prinzipien inspiriert sind. Um den Austausch zwischen diesen Initiativen zu fördern, haben wir vor Kurzem sogar eine Community of Practice gegründet.

    Ich habe ein paar Kollegen bei EWE gefragt, was sie für sich und das Team mitnehmen, wenn sie auf die letzten zwei Jahre zurückblicken:

    “Rückblickend finde ich es spannend, dass ich von einem Skeptiker (“Wie soll das denn für eine Organisation unserer Größe funktionieren?”) zu einem Verfechter des agilen Mindsets geworden bin und mir nun gar nicht mehr vorstellen könnte, so zu arbeiten wie früher.” Nils Mathiesen, ScrumMaster of ScrumMaster, EWE swb ISIS GmbH

    “Ich habe nicht geglaubt, dass wir in nur zwei Jahren so viel erreichen könnten. Und auf dem Weg ist uns klar geworden, dass wir noch viel mehr auf immer höheren Ebenen bewegen können. Ich bin sehr zuversichtlich, dass wir noch einen langen und lohnenswerten Weg vor uns haben. Vor Kurzem war ein Kollege aus einem anderen Bereich bei uns. Er war gerade ziemlich im Stress bzw. unsicher in einem neuem Projekt, bei dem gerade niemand die Anforderungen kennt. Er wusste einfach nicht, mit welchem Vorgehen er dieses Projekt angehen könnte. Ein Kollege und ich arbeiten jetzt schon seit 2 Jahren mit Scrum und haben oft die Rolle des PO übernommen, daher waren wir von dieser Situation wenig überrascht. Sofort hatten wir eine Vorstellung davon, wie wir damit umgehen würden: ein Discovery Workshop mit Kunden, ein erstes Backlog Grooming, etc.” Markus Theilen, Domain Architekt easy+, EWE swb ISIS GmbH

    “Im richtigen Moment gab es immer den richtigen Gloger, um uns zu unterstützen.” Nils Nussbaumer, Domain Product Owner, EWE isis swb GmbH

    Danke, dass wir diese Entwicklung begleiten durften und dürfen!

    Gemeinsam mit Markus Theilen berichten wir auf der OOP 2015 am 27. Januar 2015 in München über unsere Erfahrungen (Track Di 6.2). Hier geht es zum Abstract.

    Related posts:

    1. Mehr wissen! Moderationstraining
    2. Coaching Ausbildung – Contrain – Mantz/Rösner
    3. Ich bin aus jenem Holze

    Categories: Blogs

    Why offshoring Agile development often doesn’t work

    Coaching Agile Teams by Lyssa Adkins - Wed, 10/08/2014 - 00:00

    Lorraine is a seasoned Agile Coach and Certified Scrum Master with over ten years of Agile experience managing software development and implementation projects. She has published about ‘Agile and offshoring’ and ‘how to improvise Scrum’ in CIO Magazine (tinyurl.com/pvkd99n), ComputerWorld and the Agile Journal.

    Lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value, says Lorraine Pauls Longhurst.

    Many enterprises these days are outsourcing software development to offshore teams. Your organisation may have even tried it as a way to get access to highly skilled resources cheaply, and scale development resources up and down as you need them.

    But more often than not, I hear of project failures that are blamed on offshoring. People say things like: “The offshore developers just didn’t understand what we needed” or “They developed completely the wrong thing.”

    So why is it so hard? The main cause for these types of problems is a failure in communication and lack of teamwork. This has been my experience as an Agile delivery manager and coach.

    As an example, let’s take a typical software development project following Scrum (the most popular Agile framework) such as the deployment of a customised ERP system.

    The entire team including developers, business analysts, testers and a product owner (who represents the business users) sit together in the same room.

    The group should communicate informally and act like a team by following Scrum guidelines such as letting members choose their own tasks on a shared board, and ensuring everyone helps out to meet the bi-weekly (sprint) goals.

    The product owner can easily illustrate requirements by writing something on the board or giving a quick verbal example. And when you do it right, Agile enables organisations to develop a solution that can change as the business requirements are adjusted.

    It enables you to deliver a working solution to users within a couple months with only the highest priority features to start. Then the team re-aligns the solution by continuously communicating with the business (or product owner).

    I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.

    It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.

    Now, take that same ERP deployment, but have the team based offshore. The team members have never met each other, are not all sitting together and do not have the same working hours.

    Due to the lack of face-to-face communication, cultural differences and time zone issues, the developers start to misunderstand requirements. In an attempt to close the communication gap, the product owner starts to use more written communication, which causes more misunderstandings.

    The next thing that happens is because the team has never met one another, the onshore developers don’t treat the offshore developers as part of the team.

    The offshore developers start to work on their tasks independently, become less likely to clarify aspects of the project, and because they feel that they need to fend for themselves, they start to blame each other when something goes wrong.

    In my experience, this lack of communication and teamwork leads to poor productivity and a solution that doesn’t provide value.

    Make it work offshore

    So how can you make Agile work with offshore developers? You need to get back that informal communication and teamwork that is there on a successful Agile team.

    You need to overcome the issues that arise due to the fact that the team members have never met one another, are not all sitting together and do not have the same working hours.

    All team members must be treated the same, and communicated with in the same manner, whether they are onshore or offshore.

    Increase informal communication

    In an Agile project, there is usually less written documentation and more face-to-face communication. The product owner verbally explains business value rather than giving the team detailed functional and technical requirements.

    If the team understands the value of a requirement (or user story), then they are able to discuss alternative solution options. I believe this is one of the key things that can make an Agile project provide more value than a traditional project approach.

    To get the entire team to communicate face-to-face more, I suggest using a ‘blended’ team. Rather than an entire outsourced team, a few offshore resources are embedded within the onshore development team.

    The reason I’ve found that a blend of both onshore and offshore resources works well is it’s easier to ensure that requirements are communicated in an Agile manner (not just written down and handed over to the offshore team).

    I was involved in one project where the product owner verbally explained requirements to the onshore developers and wrote down requirements for the offshore developers.

    It was pretty clear that rather than trying to resolve communication issues, they were just trying to avoid them. Instead we put tools in place to ensure the product owner was able to easily communicate face-to-face with everyone consistently, in as simple a manner as possible.

    Video conference is the closest thing to face-to-face communication with offshore team members. When coaching a team, I ensure that team members are talking to each other informally by video conference at least once a day real-time, during the overlapping working hours (instead of by email or instant messaging).

    We used a ‘video wall’, where we had a large TV screen permanently on (using Skype or something similar). The entire offshore team sat together in one room so we could easily see everyone.

    Onshore developers would walk over to the screen, say ‘hi’ and have a brief chat with the rest of the offshore team.

    With Scrum, the team uses a task board to determine what needs to be accomplished in the sprint. Rather than a physical task board, we used an on-line tool to review and update the task board.

    Offshore developers chose tasks themselves rather than having them assigned to them and everyone could see who was working on what. When issues arose, everyone pitched in to help out to ensure that all the tasks were complete.

    Focus on teamwork

    Everyone knows the benefits of teamwork in principle, but in practice it is much more difficult especially when part of the team is based offshore. There are a few methods I use to get everyone to work together towards the same sprint goals.

    I have found that the only way people start helping each other out is if they feel like they really know the other team members, and understand what motivates them.

    To encourage this kind of social interaction, we did a video conference chair race – India vs Australia. It was a fun way to get the team joking around with each other.

    We also brought the offshore team members over to Australia for a few weeks. A little real face-to-face time went a long way.

    I mentioned earlier that I believe if the team understands the business value behind a requirement (or user story), then they are able to discuss alternative functional and technical solutions and come up with what is best.

    To make this work, all the team members must speak up and act like an equal member of the team.

    Early in one of my projects, I found that the team was under-estimating the amount of development work and one of the offshore developers wasn’t able to deliver on time.

    Our onshore designer was coming up with innovative user-friendly ideas but what I wanted the developers to do was discuss the designs as a team and come up with the best option that still fit within the timeframes we had.

    To help resolve this issue, I asked one of the offshore developers to take a leadership role in the planning session and although he was to listen to the others for their input, it was up to him to give the estimates for the tasks.

    The one caveat was that he then had to meet those estimates. This exercise seemed to give him the confidence to speak up much more in later planning sessions and act like an equal team member.

    To make offshoring work with Agile, you need to overcome the communication and teamwork issues inherent in a team that have never met each other, are not all sitting together and do not have the same working hours.

    Overcoming these issues is a challenge, but with the implementation of a ‘video wall’, an on-line task board, plus some coaching, you can still gain the benefits of Agile with a ‘blended’ team (mix of onshore and offshore developers).

    http://www.cio.com.au/article/547142/why_offshoring_agile_development_often_doesn_t_work/?fp=16&fpid=1

    This post originally appeared on CIO Magazine on 6/14/2014.

     

    Categories: Blogs

    Scrum Knowledge Sharing

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