Skip to content

Blogs

Broadcast Communication

Agile Tools - Sun, 09/28/2014 - 04:56

SONY DSC

In the agile development community, we are all hip to the notion of two way communication. It can be via any mechanism you choose: email, instant messaging, smoke signals or the hands-down, all-time winner – face to face. That’s fantastic, but there is another form of communication that we can develop: one-way communication.

What’s the value of that, you ask? Isn’t two way communication a lot better? The answer is yes, two way communication is great and has it’s place, but one way communication has a different purpose – one that agile teams should learn to develop as well. In fact, most agile teams don’t do very well at the one way communication beyond the team at all.

Let me explain: One way, or broadcast communication doesn’t require any response. You just shout out the news and go about your business. Now of course if there is no one to hear the news, then it really doesn’t make much difference (if a tree falls in the forest…). However in the case of working on a team, there is usually someone around. Broadcasting simply shares information with absolutely no expectation of any information or reply in return. It’s all giving and no receiving. Others can get the information and then act accordingly without ever engaging in dialog.

Some examples of one way communication include: status reports, information radiators: including burndown charts, kanban boards, etcetera. There are tools that promote one way communication such as Twitter and Yammer. I suppose even a wiki or blog qualifies too.

There is one other thing about broadcast communication that I like, especially when it comes to swarming. One way communication removes any expectation of compliance. When you broadcast information, the receivers get to decide what they want to do with it. There is no expectation of any sort of action. Commands are weakened or non-existent with this type of communication. That’s a good thing if you are swarming.

A few sentences back, I made the claim that Agile teams aren’t very good at broadcasting information beyond the team. Many of the teams that I work with tend to be very inward facing. The communication is rich between team members, but it’s very sparse if you are outside the team. This may also be a reflection of the hierarchical nature of many of the companies I’ve worked with. Teams need to take advantage of every mechanism they can find to radiate information outside the team. Some opportunities include:

  • The Scrum of Scrums or other program or portfolio meetings
  • Information radiators OUTSIDE the team. Broadcast doesn’t work if everyone has to come to you to get the message.
  • Attending other forums, other teams status meetings
  • Status reporting – yes, status reports are the root of all evil, but they are a form of one way communication.

If you aren’t using one way broadcast, give it at try. It’s a powerful communication tool – and essential to promote swarming.


Filed under: Agile, Process, Scrum, Swarming, Teams Tagged: communication, information radiators, one way broadcast, Swarming
Categories: Blogs

1. Capitalisation target; 2. ???; 3. Profit!

The organisation has a capitalisation target.

Everyone encourages managers to increase the capitalisation of their areas.  If they don't, they won't get funded.

The simplest way to increase capitalisation rate is simply changing numbers in spreadsheets.  This is mostly independent of whether or not the work is creating an asset because it's easier to move a number than it is to argue.
I've been told that from a corporate finance perspective, the priority is:
  1. Appropriate accounting of capital and operating expense
  2. Effective use of financial investment to achieve strategic goals
"How might we meet our capitalisation target?" is a question that leads organisations away from either of those goals.
Instead, if we want appropriate accounting, we might ask..."How might we improve the accuracy of our accounting?"This might lead to...
  • Training sessions, guides, etc. on appropriate capitalisation
  • Integration with tooling
  • Only assessing capitalisation after delivery of the assets.  That is, operating using OPEX and only journalling to CAPEX upon release.  I'd call this "as-built accounting".
Instead, if we want to have more effective financial investment, we would just ask that question..."How might we be more effective with our financial investment?"This might lead to...

  • Clearer communication of strategic intent
  • Collective prioritisation of the portfolio
  • Smaller batch sizes to allow for staged investment
  • More sophisticated ways of assessing investments (e.g. Cost of Delay)
Categories: Blogs

Swarming Roles

Agile Tools - Sat, 09/27/2014 - 07:55

athletes-ball-football-2199-828x550

So far in this series I have covered the values and principles of the swarming methodology. Now let’s talk about roles on swarming teams. In nature, when you look at swarms, flocks and schools there are all kinds of specialization. The nature of the roles can be fixed (i.e. workers and queens) or they can be dynamic (foraging, nursing, etc.). So there are a very broad range of roles that we can find in the animal world. Given those models, there are a few things we can identify as critical to swarming teams:

  • Swarms don’t have Managers, Masters or Owners
  • Swarms have radical diversity
  • Membership is not fixed

There are none of the typical command and control structures to be found on a swarming team. There is no manager. There is no owner. There is no one person making any of the decisions for the group. Swarming doesn’t work without complete equality. That doesn’t mean there can’t be leaders, they are still necessary, but it is only leadership by virtue of their ideas, not any sort of hierarchy or power relationship.

Swarms require diversity. Swarm based decision making is enabled by diversity in the group. Without that diversity, the swarm is likely to have too narrow a perspective and come up with poor answers. This comes from the wisdom of crowds – it doesn’t work without diversity. True diversity is rare in our business. I’m not talking about just race and sex (although more diversity there is necessary), I’m actually talking about a diversity of knowledge and interests. We need people who aren’t software engineers on our teams. Anyone can play: the admin, the fisherman, the librarian, the doctor and the engineer. I think of this as radical diversity.

Finally, the membership of the team doesn’t stay the same. It ebbs and flows with the popularity of the project and the ideas that are being worked on. Anyone can come or go on any given day. They are able to follow their passions where ever they may go. Swarm teams can recruit, sell, and dissipate completely. Nothing about the membership on swarming team is mandatory.

 


Filed under: Agile, Swarming Tagged: diversity, no managers, principles, radical diversity, roles, Swarming, values
Categories: Blogs

Neo4j: COLLECTing multiple values (Too many parameters for function ‘collect’)

Mark Needham - Fri, 09/26/2014 - 22:46

One of my favourite functions in Neo4j’s cypher query language is COLLECT which allows us to group items into an array for later consumption.

However, I’ve noticed that people sometimes have trouble working out how to collect multiple items with COLLECT and struggle to find a way to do so.

Consider the following data set:

create (p:Person {name: "Mark"})
create (e1:Event {name: "Event1", timestamp: 1234})
create (e2:Event {name: "Event2", timestamp: 4567})
 
create (p)-[:EVENT]->(e1)
create (p)-[:EVENT]->(e2)

If we wanted to return each person along with a collection of the event names they’d participated in we could write the following:

$ MATCH (p:Person)-[:EVENT]->(e)
> RETURN p, COLLECT(e.name);
+--------------------------------------------+
| p                    | COLLECT(e.name)     |
+--------------------------------------------+
| Node[0]{name:"Mark"} | ["Event1","Event2"] |
+--------------------------------------------+
1 row

That works nicely, but what about if we want to collect the event name and the timestamp but don’t want to return the entire event node?

An approach I’ve seen a few people try during workshops is the following:

MATCH (p:Person)-[:EVENT]->(e)
RETURN p, COLLECT(e.name, e.timestamp)

Unfortunately this doesn’t compile:

SyntaxException: Too many parameters for function 'collect' (line 2, column 11)
"RETURN p, COLLECT(e.name, e.timestamp)"
           ^

As the error message suggests, the COLLECT function only takes one argument so we need to find another way to solve our problem.

One way is to put the two values into a literal array which will result in an array of arrays as our return result:

$ MATCH (p:Person)-[:EVENT]->(e)
> RETURN p, COLLECT([e.name, e.timestamp]);
+----------------------------------------------------------+
| p                    | COLLECT([e.name, e.timestamp])    |
+----------------------------------------------------------+
| Node[0]{name:"Mark"} | [["Event1",1234],["Event2",4567]] |
+----------------------------------------------------------+
1 row

The annoying thing about this approach is that as you add more items you’ll forget in which position you’ve put each bit of data so I think a preferable approach is to collect a map of items instead:

$ MATCH (p:Person)-[:EVENT]->(e)
> RETURN p, COLLECT({eventName: e.name, eventTimestamp: e.timestamp});
+--------------------------------------------------------------------------------------------------------------------------+
| p                    | COLLECT({eventName: e.name, eventTimestamp: e.timestamp})                                         |
+--------------------------------------------------------------------------------------------------------------------------+
| Node[0]{name:"Mark"} | [{eventName -> "Event1", eventTimestamp -> 1234},{eventName -> "Event2", eventTimestamp -> 4567}] |
+--------------------------------------------------------------------------------------------------------------------------+
1 row

During the Clojure Neo4j Hackathon that we ran earlier this week this proved to be a particularly pleasing approach as we could easily destructure the collection of maps in our Clojure code.

Categories: Blogs

Making an Impact with Kanban Thinking

AvailAgility - Karl Scotland - Fri, 09/26/2014 - 16:26

This post pulls together a number of ideas  on impact into a single place, and will become the content for a page in Impact on the Kanban Thinking site.

What is Impact

Outputs creates Outcomes which have Impact.

Designing a Kanban System involves the evolution and discovery of a good design. It cannot be pre-determined in advance. Thus instead of defining a future-state and working towards it, we start with the current-state and work away from it, exploring and assessing different alternatives. Each output of a design iteration will create different outcomes, and those that improve the system can be said to have a positive impact, while those that worsen the system have a negative impact.

Impact, therefore, describes the disposition of the system, or its tendency to behave in a certain way. Rather than defining a planned destination, impact points to the desired direction, such that we can check whether any changes are moving us towards or away from the direction we want to be heading. Impact can be assessed by using narrative techniques to capture stories about utopian (and dystopian) futures, and subsequently asking whether an outcome is likely to lead to more of the positive stories and fewer of the negative stories.

Describing Impacts

When imagining what impacts would be desirable, its easy for our experiences and biases to lead us to narrow our thinking and prematurely converge on only one particular type of impact. To avoid this, and encourage diversity in exploring a wide variety of potential impacts, Kanban Thinking describes three types to consider, giving different perspectives.

  • Flow. This is Doing the Thing Right. Stories will be primarily related to the process, efficiency and reliability.
  • Value. This is Doing the Right Thing. Stories will be primarily related to the product, effectiveness and validity.
  • Potential. This is Doing the Thing Sustainably. Stories will be primarily related to people, euphoria and flexibility.
Impacts as Triads

When exploring the impacts, it will become apparent that there is not always an obvious and neat mapping to either flow, value or potential. Thus, the three impacts can be thought of as a triad, with each being a vertex of a triangle.

Triads are concept I learned from Dave Snowden and used by the Cognitive Edge Sensemaker Suite (note that they have a patent associated with this), where a triangle is used as a measuring instrument to assess against three parameters. By using triads, impacts can be placed relative to where they have the strongest affinity, without having to decide on any one in particular. Imagine an impact being connected to each vertex with elastic. The greater the affinity to a vertex, the greater the tension, with the final position being a result of the combination of all three. Thus the story in the triad below has the strongest affinity with the Flow vertex. The next strongest is Potential, with Value being the weakest.

Impact Triad

While triads are an approach not directly supported by the canvas in its current form, the deliberate choice of words to describe each impact creates multiple possible triads which could be explored. Deciding where an impact goes generally requires more thinking, and generates greater dialogue and insight.

FlowValuePotential Thing RightRight ThingThing Sustainably ProcessProductPeople ReliabilityValidityFlexibility EfficiencyEffectivenessEuphoria

Generating lots of utopian (and dystopian) future stories, instrumented with these triads, will generate patterns which can give a sense of where the improvement opportunities are for making an impact.

Example

Here’s an example of thinking about impact from the three perspectives. It is intentionally lacking in direct relevance to minimise the risk of biasing your own answers to the questions.

When I go running, I’m generally wanting to improve my health and fitness. What impact do I want to have?

  • From a Flow perspective, impact could be about pace and speed. I could imagine a utopian future where I can run a 4 minute mile.
  • From a Value perspective, impact could be about distance and stamina. I could imagine a utopian future where I can run 100 miles.
  • From a Potential perspective, impact could be about friendship and community. I could imagine a utopian future where I am the president of a local running club.

None of these are mutually exclusive. If I can run a 4 minute mile, then there is a high likelihood that I’ll be involved in a running club, and training longer distances as well. However, explicitly exploring the different perspectives avoids me just focussing on one thing such as speed, to the detriment of friendship or stamina.

What stories would you like to tell about the impact your kanban system makes in the future?

Categories: Blogs

Refurbishing a Mail Slot and Doobell

Radyology - Ben Rady - Fri, 09/26/2014 - 15:01
When I moved into my house, the mailbox was in pretty sorry shape. It was corroded, and the mail flap was stuck open. On top of that, it had an integrated doorbell that didn't work. Lastly, the entire border of... Ben Rady
Categories: Blogs

When everything is “most important” … nothing is

Derick Bailey - new ThoughtStream - Fri, 09/26/2014 - 13:00

inbox-overflow

It can be difficult to prioritize -

especially when everything is highest priority and most important.

But the truth is, when everything is the highest priority or the most important thing you have to do, then nothing is. That doesn’t mean you don’t have important things to do. It only means that your time and priorities are not being managed correctly. The result will be floundering around, trying to figure out what to do, and generally being stuck in fire-fighting mode where the only thing you can focus on is the thing that is currently on fire.

This isn’t a good place to be.

Learning To Say No… Again

I’ve dealt with this issue in the past, and it seems to be coming up again in my life. I’ve had to say no to more and more things recently, because I seem to have been stuck in fire-fighting mode for far too long. So I unloaded a few of the “important” things and sat down to try and organize my time and priorities.

Starting With My “Every Week” Things

Organizing my time was easy at first. I have a list of things that always happen every week:

  • Client work (for my 1 client)
  • This weekly email
  • WatchMeCode episode release
  • family things, etc

These are things that always happen in my week – they are clearly the highest priorities for me.

But after that, I was getting stuck in the cycle of trying to figure out what to do next and not being able to focus or set priorities. Should I work on more screencasts? Should I work on SignalLeaf? Should I do marketing for either of those? Do I need to blog more on DerickBailey.com? Or on SignalLeaf? What about … the list was getting overwhelming, and I wasn’t getting anything done.

Focus: 1 Week At A Time

For a while, all of my projects suffered. I was jumping back and forth between too many things in a given week or given day. Doing this was causing everything to fall further and further behind because I couldn’t focus. Then Josh and John, from my entrepreneur group, suggested I try to focus 1 week at a time.

Once I had my “every week” items scheduled I needed to pick one project to work on each week. At the beginning of a week, I plan out what I am going to do for the week on that one project. Other projects and responsibilities get pushed to the side during that week, so that I can focus and stay focused.

For example, one week I’ll work on SignalLeaf. The next week, I’ll work on WatchMeCode. After that, back to SignalLeaf or maybe some other thing that came up recently. Somewhere in the mix, I’ll decide that I need to move DerickBailey.com forward, and I’ll plan a week of working on that.

Setting these week long sprints of work on a given project is helping me move every project forward, instead of wondering when any given project will be moved.

How It Has Helped So Far

I’ve only been doing this for 2 weeks now, as I’m writing this to you. But so far it has helped me a lot. My 2 weeks of focus have allowed me to make very large leaps and bounds forward on all fronts of that week’s project. I’m no longer trying to decide between projects – I have an entire week in which I will work on one of them.

Being able to focus like this has helped out every project I have, already – even if I’ve only planned to work on a project and haven’t actually done the work yet. At least now, I have a plan for it instead of just worrying about when I’ll get to it.

The Future Of Focus

This week I’m focusing on WatchMeCode, and next week will be focused on a presentation for a conference. After that, I’ll get back to SignalLeaf…. after that… well, I’m not planning that far ahead, yet. And I’m ok with that. The further out I go, the less specific my plans need to be. I can have a general idea of where I’m heading more than a month from now, but I only need to know what my next 2 or 3 weeks look like.

That doesn’t mean I won’t at least think that far ahead. It only means that I don’t have to write it down or commit to it yet. I’m sure there will be times when I do have a specific deadline for something (like a conference) and I’ll need to plan that far ahead. But for now, I’m going to run with only 1 or 2 weeks planned and see how it goes.

Still An Experiment. Looking To Improve.

I may have only been doing this for 2 weeks so far, but right now I’m feeling like this is going to be the way that helps me move forward with all of my projects (in addition to reducing the number of projects I have, that is).

But even with this tool in place, I know I can still do better. What tools and techniques do you have in place to help manage your time and focus? I’d love to hear about how you handle things. Leave a comment below, and let me know!

– Derick

     Related Stories 
Categories: Blogs

Swarming Principles

Agile Tools - Fri, 09/26/2014 - 08:56

animal-beetle-insect-329-825x550

In an earlier post I introduced a set of values that might be used to guide swarming teams. Values are a good start. They provide very broad guidelines to give teams guidance when making big picture decisions. Principles help give more specific guidance. So here are a few principles that are aimed at guiding teams practicing swarming as a discipline.

Swarming Principles

  • The most important thing I can do is whatever I am most passionate about today
  • Prefer one way broadcast over two way communication
  • Using agreed upon protocols enhances the effectiveness of our communication and decision making

The first principle tells us that we need to be fully engaged in whatever we care most about. That means that people move to where ever they have the most interest. Teams are spontaneously formed dynamic entities that are composed of people who share a common passion.

The second principle tells us that we not only need to communicate, we need to radiate. Information needs to be broadcast exuberantly without reservation or hesitation.

The third principle tells us that one of the foundations for emergent behavior is in simple protocols. We need to be explicit and disciplined in how they are applied and we need to be always seeking new protocols to add to the mix.


Filed under: Agile, Swarming Tagged: methodology, principles, Swarming, values
Categories: Blogs

Es liegt an dir, was du aus der Arbeitswelt machst

Scrum 4 You - Fri, 09/26/2014 - 07:45

Das Team von Boris Gloger Consulting besteht nicht nur aus Beraterinnen und Beratern. Unser „Backbone“ ist im wahrsten Sinne des Wortes das Rückgrat, das dem Unternehmen seine Stabilität gibt: Die Kolleginnen kümmern sich um die Finanzen, ums Marketing und um den Kontakt mit BewerberInnen und Freelancern. Seit August unterstützt Diana Eiswirt das Team. Sie absolviert bei uns ihre Ausbildung zur Kauffrau für Büromanagement – unser allererster Azubi, darauf sind wir sehr stolz! Diana hat sich bereit erklärt, das Arbeitsleben für einen Blogartikel aus ihrer Sicht als junge Einsteigerin in die Arbeitswelt zu betrachten. Danke Diana!

Man sollte nicht auf Mitmenschen hören, die sagen: „Du wirst die Schulzeit noch vermissen.“ Es ist zwar gut möglich, dass dies passiert, wenn man z.B.eine tolle Schulzeit mit vielen Freunden und Ausflügen hinter sich hat, aber einen großen Unterscheid zwischen Schule und Arbeit sehe ich bislang noch nicht. Seit ich am 01.08.2014 bei Boris Gloger Consulting meine Ausbildung begonnen habe, weiß ich, dass Arbeiten auch Spaß machen kann.

In der Schule lernt man, aber in der Arbeit gibt es auch noch genügend zu lernen.
In der Schule hast du deine Freunde, aber du kannst deine Kollegen auch zu deinen Freunden machen.
Man muss für die Schule morgens früh raus, das muss man bei der Arbeit auch.

Wo liegt also der große Unterschied? Ich finde, so viel anders ist es gar nicht. In der Schule geben die Lehrer die Anweisungen und Aufgaben, in der Arbeit wird der Lehrer durch einen Chef ersetzt – es funktioniert also nach dem selben Prinzip. Ob du letztendlich die Schulzeit vermisst, liegt in deiner Hand und daran, was du aus der Arbeitswelt machst. Es ist ein neuer und wichtiger Lebensabschnitt, um den keiner drumherum kommt, früher oder später muss da jeder durch. Doch dieser Abschnitt lässt uns nochmals mehr erwachsen werden und anders denken.

Als Auszubildende habe ich mittlerweile schon meine festen Aufgaben, die ich zu erledigen habe, und trotzdem lerne ich so gut wie jeden Tag etwas Neues – das bringt Abwechslung in mein Berufsleben. Abwechslung ist für mich gut, da es das Arbeiten nicht langweilig werden lässt.

Momentan gehören zu meinen Aufgaben:

  • Reisekosten bearbeiten
  • die Kontakte in unserem CRM-Programm verwalten
  • Trainees für Trainings anmelden und Bestätigungen versenden
  • Zertifizierungen bearbeiten
  • Vorlagen erneuern bzw. in unser neues Corporate Design bringen

Bis jetzt ist es zwar noch nichts Großes, das ich eigenständig machen kann, aber trotzdem macht es mir Spaß! Es macht Spaß, auch wenn es nicht immer ganz einfach war: Immerhin musste ich erst einmal mit den Programmen zurechtkommen. Doch das wird von Tag zu Tag besser und ich werde immer sicherer.

Ich freue mich jeden Tag aufs Neue, zur Arbeit zu kommen, um Neues zu lernen. Ich hoffe, es bleibt mein ganzes Berufsleben so – dass meine Arbeit mir Freude bereitet und ich jeden Tag gerne dorthin gehe.
Sicherlich wird es den einen oder anderen Tag geben, der nicht so läuft, wie ich es mir gewünscht habe, und dennoch wird mich das nicht abschrecken. Arbeiten muss nicht so schlimm sein, wie viele es sagen. Arbeit ist das, was man daraus macht!

Man sollte sich immer fragen:

  • Mache ich meine Arbeit gerne?
  • Ist es das, was ich bis zu meiner Rente gerne jeden Tag aufs Neue machen will?

Warum sollte Arbeit eigentlich Spaß machen? Aus dem einfachen Grund heraus, weil wir einen großen Teil unseres Lebens damit verbringen! Es ist es für den Mitarbeiter selbst, aber auch für den Chef nur von Vorteil, wenn jeder Angestellte gerne jeden Morgen zur Arbeit kommt. Das bedeutet nämlich, dass wir keine schlechte Laune haben und viel motivierter sind. Geht es uns gut, sind wir fröhlicher, aufgeschlossener und bereitwilliger für Neues und tun damit auch etwas Gutes für unsere Gesundheit. Die falsche Arbeit kann nämlich auch krank machen. Warum also nicht die Chance nutzen und Berufliches sowie Privates auf diese Art und Weise zu vereinen? Was gibt es Schöneres als glückliche, zufriedene Menschen, die nicht in jeden ihrer Tage lustlos hineinleben und schauen, was heute wohl so alles auf sie zukommen mag, sondern den Tag in die Hand nehmen und nicht den Zufall über ihr Leben regieren lassen!

Unser Leben heißt es. Also sollten wir auch etwas dafür tun, damit unser Leben läuft, wie es uns gefällt. Denn wenn wir es nicht selbst in den Händen halten, wer dann?

Testfoto @ Boris Gloger Consulting in Baden-Baden

Related posts:

  1. Bin ich am Arbeitsplatz zufrieden?
  2. Eine Erleuchtung: Scrum als Coaching-Tool!
  3. Komfort-, Stress- und Panikzone im Change Prozess

Categories: Blogs

The Agile Reader – Weekend Edition: 09/26/2014

Scrumology.com - Kane Mar - Fri, 09/26/2014 - 06:41

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.

  • How to Plan and Execute Programs without Shooting Agile in the Foot #agile #scrum
  • VIDEO: Based on AMAZON Top #10 Best Seller. FREE SCRUM BOOK here: #Scrum #Agile
  • Are you looking for Project Management Ideas ? Visit my blog in #pmp #pmi #scrum #agile
  • Jeff Sutherland & the Power of Scrum. Free talk in Atlanta. @jeffsutherland #Scrum #Agile #Versionone #HappyFamily
  • Check out “VersionOne Presents Jeff Sutherland, Co-Creator of Scrum for an Agile Community…” via @eventbrite
  • RT @stacywms: Check out “VersionOne Presents Jeff Sutherland, Co-Creator of Scrum for an Agile Community…” via @ev…
  • Repetitive Work in Math? That’s Good Great article about learning that even applies in the workplace.#Agile #Scrum
  • Developer II Keyword C#, .Net, JavaScript, OOAD… – #SanMarcos , TX (Get NET Jobs #NET #jobs #job #GetAllJobs
  • Should your entire #scrum team be co-located? I think so. Here’s 3 reasons why! #agile #pm #pmot
  • RT @AgileUniversity: Better User Stories. Certified Scrum Product Owner class Denver w/ @RonicaRoth #Scrum #Agile @R…
  • Organize your work with Podio #pmp #pmi #scrum #agile #podio @podio
  • The Scrum Guide, the ultimate definition of Scrum. #Scrum #Agile
  • A Practical Example On How To Use Agile And Scrum Tec http://t.co/NOgZkkZp66
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • RT @FreeScrumEbook: VIDEO: Based on AMAZON Top #10 Best Seller. FREE SCRUM BOOK here: #Scrum #Agile
  • Scrum Mega Pack HARD COPY: #scrum #agile
  • Scrum Expert: Lean Agile South Africa, Cape Town & Johannesburg, South Africa, 6-10 October 2014 #agile #scrum
  • Scrum Expert: Agile Business Conference, London, UK, 8-9 October 2014 #agile #scrum
  • RT @yochum: Scrum Expert: Agile Business Conference, London, UK, 8-9 October 2014 #agile #scrum
  • RT @FreeScrumEbook: Scrum Mega Pack HARD COPY: #scrum #agile
  • RT @yochum: Scrum Expert: Lean Agile South Africa, Cape Town & Johannesburg, South Africa, 6-10 October 2014 #agile …
  • RT @yochum: Scrum Expert: Agile Business Conference, London, UK, 8-9 October 2014 #agile #scrum
  • #AGILE #SCRUM, Entrenamiento y Certificación Oficial #EXIN. Regístrate aquí: http://t.co/hrViPrA9FE
  • #RT #AUTHORRT #scrum that works ** ** #agile #project #productowner
  • Break down the silos between IT and the business – The Enterprisers Project #Agile #Scrum
  • Agile by McKnight, Scrum by Day is out! Stories via @heather_fox @rokazi
  • #Agile – Do you know how many tasks has to do an Scrum Master? – http://t.co/HsfFBXhohI
  • FREE SCRUM EBOOK as sold on Amazon: avail here. #Scrum #Agile inspired by #Ken Schwaber
  • RT @FreeScrumEbook: FREE SCRUM EBOOK as sold on Amazon: avail here. #Scrum #Agile inspired by #Ken Schwaber
  • The canonical definition of #Scrum has a new home:
    Good move @scrumalliance #unity #agile
  • Great example of #Agile #Scrum methods. Nordstrom Innovation Lab: Sunglass iPad App Case Study #video
  • RT @DanielRFeldman: Great example of #Agile #Scrum methods. Nordstrom Innovation Lab: Sunglass iPad App Case Study …
  • Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile inspired by #kschwaber
  • RT @FreeScrumEbook: Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile insp…
  • RT @FreeScrumEbook: Do you want to complete projects efficiently? Check out the FREE SCRUM EBOOK: #scrum #agile insp…
  • Agile Product Owner: Kanban for SAFe Teams #agile #scrum
  • RT @yochum: Agile Product Owner: Kanban for SAFe Teams #agile #scrum
  • Just came across on #Scrum. All 6 free vids in 75 minutes. #rails #rubyonrails #agile http://t.co/9LZEHOLtjy
  • The joy of timeboxed meetings #Scrum #Agile
  • The joy of timeboxed meetings #Scrum #Agile
  • RT @scrumology: The joy of timeboxed meetings #Scrum #Agile
  • Scrum Master / Agile Coach / Agile Project Manager – Reflex Computer Recruitment Ltd – Brighton Job Brighton
  • Categories: Blogs

    Kanban for SAFe Teams

    Agile Product Owner - Thu, 09/25/2014 - 20:16

    Hi Folks,

    I suspect many of you will be interested in this new guidance article which describes the application of Kanban for SAFe Agile Teams.  Here is the abstract to pique your interest.

    While not a software-specific method by original intent, the application of Kanban in software development can be quite useful. It provides a more granular view of the flow of work through the team, illustrates bottlenecks and delays to be addressed, and increases flow by application of work-in-process limits.  Properly used, Kanban provides a powerful set of constructs that every software enterprise should be able to apply in the scaled systems context. This article describes how Kanban can used by SAFe Teams in the content of their Agile Release Train.

    Thanks to Alex for this material contribution to SAFe, and given the fun we are all having with Agile method opinions in general, thanks also to all those whose comments we hope to receive on this post!

     

    Categories: Blogs

    Common Scrum Definition At Last!

    xProgramming.com - Thu, 09/25/2014 - 15:19

    I was asked to comment on this exciting press release:

    SCRUM ORGANIZATIONS ANNOUNCE OFFICIAL COLLABORATIVE ADOPTION OF SCRUM GUIDE

    And here’s the combined site.

    My comments:

    Strategically, the Scrum Alliance has been working toward there being a single agreed document among the “big three” Scrum organizations, Ken’s, Jeff’s, as the founders, and the Scrum Alliance, the largest organization formed in support of Scrum. (And originally formed by Ken / Jeff, one should certainly say.)

    The organizational split was brought about by the usual disagreements among people, not by any real disagreement about the ideas in and value of Scrum itself. It was, in my personal opinion, bad for everyone, even if it was inevitable given people’s differing goals.

    Carol McEwan, as new blood in the Scrum Alliance, felt the call to be unified more strongly than any historical call to schism. At her direction, when we wrote the original Core, we took care to agree with the Scrum Guide in any particular, because we were not trying to split — or further split — Scrum, but to produce a stable document that the Scrum Alliance could use as a reference and as a basis for its teaching and testing.

    Meanwhile, Carol reached out to people in Ken and Jeff’s circles, and with their help, to Ken and Jeff, and together they all hammered out an agreement to mutually own, mutually author, and mutually support the Scrum Guide. The Core team has known about this effort for months: we talked about it with Carol at the Scrum Gathering, and some of us, prior to that.

    I think it is fairly likely that the Core will remain as a sort of “study guide” for Scrum, as it contains some connecting material, like the references to the Agile Manifesto, and some specific material that supports Scrum Alliance training and testing. That’s just my guess, however. Of course, many authors will continue to write books and articles about Scrum.

    My personal view has long been that all these named ideas, Scrum, XP, Crystal, and even the related bodies of knowledge in Lean, Kanban, and so on, are close relatives, different philosophers’ view of the “same elephant”. Thus my Tumblr on that subject. I believe that we are not well served by treating these different views as being in competition, and that most of the differences are differences of understanding, differences based on individuals’ personal preferences, and differences of business goals. My own focus — to the extent that I can be said to have a focus — is in helping people see that these ideas belong together, that it is “all the same elephant”.

    So, anyway, this has been in development for at least months, years for some of us, and I’m quite pleased about it. I expect that the human differences will continue to plague us and I hope that we’ll continue to work on a broad and strong understanding of what we’re all about.

    My thanks go to Carol, for having the vision and the courage to push this through, and to all the principals for seeing the wisdom of the idea and helping this happen.

    Categories: Blogs

    Talking with Tech Leads

    thekua.com@work - Thu, 09/25/2014 - 15:04

    I am proud to announce the release of my latest book, “Talking with Tech Leads” that is now available on Leanpub.

    I started this book project over a couple of years ago when I discovered a lack of resources for helping developers transition into a role which demanded more than good development skills.

    Talking with Tech Leads

    Book Description: A book for Tech Leads, from Tech Leads. Discover how more than 35 Tech Leads find the delicate balance between the technical and non-technical worlds. Discover the challenges a Tech Lead faces and how to overcome them. You may be surprised by the lessons they have to share.

    Buy it here on Leanpub.

    Categories: Blogs

    WIP and Priorities – how to get fast and focused!

    Henrik Kniberg's blog - Thu, 09/25/2014 - 12:23
    Many common organizational problems can be traced down to management of Priorities and WIP (work in progress). Doing this well at all levels in an organization can make a huge difference! I’ve experimented quite a lot with this, here are some practical guidelines: WIP = Work In Progress = stuff that we have started and not read more »
    Categories: Blogs

    The Secondary Indirective

    Business Craftsmanship - Tobias Mayer - Thu, 09/25/2014 - 08:53

    This is an alternative to the Prime Directive for opening a retrospective. It isn’t a directive, and it needn’t be primary, just something you may like to reflect on with your fellow workers.

    We are emotional and vulnerable beings, subject to a continuous flow of influences from a myriad of sources. Sometimes we perform magnificently, other times we mess up. Mostly we are somewhere between these extremes. In this last period of work everyone did what they did, and likely had reasons for doing so. Accept what is. And now, what can we learn from our past actions and thinking that will inform and guide our future ones?

    ___

    originally posted on AgileAnarchy in 2010

    Categories: Blogs

    Coping with a Fear of Inaccuracy

    Agile Tools - Thu, 09/25/2014 - 07:53

    “Even imperfect answers can improve decision making.” – Donald Reinertson

    When I read this from Reinertson’s book on flow, I realized that I had found the reason that people have so much trouble with story points. It’s a matter of overcoming their fear of inaccuracy. They are under the misguided belief in the accuracy of using hours or days to estimate work on projects. They’re basically afraid of being wrong (aren’t we all?) and that is the source of a lot of resistance to change. Being wrong sucks. I get that. Nevertheless, I’m wrong a lot.

    Fortunately, wrong isn’t always boolean (unless you happen to step in front of a swiftly moving bus). There are shades of wrong. You can be just a little wrong, your aim just a little off, and still be headed in the right direction. Or you can be a lot wrong (the bus). That’s where frequently re-examining your decisions can help you catch the stuff that’s a lot wrong and fix it. What about the stuff that’s a little wrong? Don’t sweat it.

    In the software world, a little wrong is still pretty useful. There is a tremendous amount of error and missing information. Compared to that, being slightly wrong isn’t so bad. Being slightly wrong gets you started – at least in mostly the right direction. You’re going to fine tune it anyway, so there’s really no need for decision making precision. That will come later, when you know more.

    To me, the ability to overcome our fear of being wrong stems from an all-or-nothing mindset. We can’t allow ourselves to be even a little wrong for fear of failure. As Reinertson rightly points out, there is a time and a place for precision in decision making, but it’s not ALL the time.


    Filed under: Agile, Process Tagged: error, estimation, Planning, sizing
    Categories: Blogs

    Scrum Alliance, Scrum.org and Scrum Inc. Announce Collaboration

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

    My heartfelt congratulations on this important and historic event!  Scrum is one, again!

    From the official announcement issued by Scrum Alliance:

    SCRUM ORGANIZATIONS ANNOUNCE OFFICIAL
    COLLABORATIVE ADOPTION OF SCRUM GUIDE

    Scrum Alliance, Scrum.org, and Scrum Inc. announce the release and joint endorsement of a new community website, ScrumGuides.org. The new website is the official source of “The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game.”

     

    Dr. Jeff Sutherland and Ken Schwaber created Scrum and authored “The Scrum Guide” to ensure Scrum remains true to its core principles and values.

     

    “The Scrum Guide is the canonical definition of Scrum. Ken and I have worked closely together for decades to keep it simple, clear, and, in the true spirit of Scrum, to include only what is absolutely necessary,” says Sutherland, CEO of Scrum Inc. “Scrum is a powerful tool to radically increase productivity. Every implementation of Scrum is different, as teams and organizations apply it within their context, but the fundamental framework always remains the same. For Scrum Alliance, Scrum.org, and Scrum Inc. to come together to recognize the central place the Scrum Guide holds will provide clarity to the hundreds of thousands of Scrum practitioners across the planet.”

     

    The explosive growth of people and organizations using Scrum in recent years has led to some market confusion as to the precise definition of Scrum. The preeminent certifying bodies, Scrum Alliance and Scrum.org, coming together in support of a common definition of Scrum is a win for Scrum practitioners around the world.

     

    “The pieces of Scrum are carefully fit to each other to yield the best possible results. This has taken years for Jeff and myself to achieve. Watch for new versions as we continue to refine,” said Ken Schwaber, founder of Scrum.org.

     

    “It’s time for convergence in the Scrum community,” said Scrum.org’s operations chief David Starr. “Giving this clear explanation of Scrum clarifies the framework for the entire industry. We are pleased to support a shared and unambiguous source of truth defined by Scrum’s creators.”

     

    Carol McEwan, Scrum Alliance Managing Director, said, “This makes the most sense for the Scrum community. The Scrum Guide is based on the principles on which Scrum was founded. It offers Scrum practitioners worldwide a common standard and understanding of the foundations of Scrum. This collaboration adds real value and can only benefit everyone practicing, or considering practicing, Scrum.”

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

    The ART of the All-Hands Release Planning Meeting

    Agile Product Owner - Wed, 09/24/2014 - 23:36

    Hi Folks,

    SAFe is powered by agile.

    “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.

    Check out this blog post from down under SPC Em Campbell-Pretty to “feel the power” behind face-to-face Release Planning with SAFe:

    http://www.prettyagile.com/2014/09/SAFe-ART-PSI-release-planning.html

    A cool little video vignette is included for no additional charge.

    Thanks Em!

    Categories: Blogs

    Neo4j: LOAD CSV – Column is null

    Mark Needham - Wed, 09/24/2014 - 22:21

    One problem I’ve seen a few people have recently when using Neo4j’s LOAD CSV function is dealing with CSV files that have dodgy hidden characters at the beginning of the header line.

    For example, consider an import of this CSV file:

    $ cat ~/Downloads/dodgy.csv
    userId,movieId
    1,2

    We might start by checking which columns it has:

    $ load csv with headers from "file:/Users/markneedham/Downloads/dodgy.csv" as line return line;
    +----------------------------------+
    | line                             |
    +----------------------------------+
    | {userId -> "1", movieId -> "2"} |
    +----------------------------------+
    1 row

    Looks good so far but what about if we try to return just ‘userId’?

    $ load csv with headers from "file:/Users/markneedham/Downloads/dodgy.csv" as line return line.userId;
    +-------------+
    | line.userId |
    +-------------+
    | <null>      |
    +-------------+
    1 row

    Hmmm it’s null…what about ‘movieId’?

    $ load csv with headers from "file:/Users/markneedham/Downloads/dodgy.csv" as line return line.movieId;
    +--------------+
    | line.movieId |
    +--------------+
    | "2"          |
    +--------------+
    1 row

    That works fine so immediately we can suspect there are hidden characters at the beginning of the first line of the file.

    The easiest way to check if this is the case is open the file using a Hex Editor – I quite like Hex Fiend for the Mac.

    If we look at dodgy.csv we’ll see the following:

    2014 09 24 21 20 06

    Let’s delete the highlighted characters and try our cypher query again:

    $ load csv with headers from "file:/Users/markneedham/Downloads/dodgy.csv" as line return line.userId;
    +-------------+
    | line.userId |
    +-------------+
    | "1"         |
    +-------------+
    1 row

    All is well again, but something to keep in mind if you see a LOAD CSV near you behaving badly.

    Categories: Blogs

    Reframing to Reduce Risk

    Leading Agile - Mike Cottmeyer - Wed, 09/24/2014 - 14:53

    From what I have been able to decipher in my career businesses are around to make money. The way they make money is by offering goods and services to people willing to pay for them. Each business has their idea of the best way to deliver these goods and services they believe in some way sets them apart. Most businesses I have come across have come to settle on an approach that allows them to work on individual separately managed projects resulting in an increment of business value being delivered. Something similar to this:

    • Organize around projects
    • Present the work that needs to be done in “clearly defined” requirements
    • Staff the project appropriately according to the initial understanding of the scope and demand of the project
    • Work hard on this project until it is completed and delivered to the market

    In my experience some risks for delivering these projects on time and on budget might be identified by a project manager early on in the initial inception phase of the project and might be reviewed at the end of each project, but not much attention is paid to the risks during the life of the project.

    I understand that the following might not be a revolutionary brand new concept, but I wanted to work on exploring the intricacies of this idea with you while I continue to work through this myself.

    Staying with a “Known Loser”

    By not reassessing the risk throughout the life of the project we miss out on some great information to help us determine if the work can be completed on time (or at all for that matter) until the project is actually released.

    We will continue to sink money into the project until it is “finished” even if everyone understands that there is no way to recoup our money through the sales of the eventual end result. I believe a big reason for staying with a “known loser” is that we become emotionally invested in these projects and stop looking at them objectively.

    What if we were to stop looking at projects as work that needs to be done, and reframed them into a bucket of risk that needs to be removed.

    Shifting Focus

    By shifting the focus to reduce risk it allows us to have a different conversation about the work we are evaluating. If we are performing a lot of work without reducing our risk, we are simply pushing out the inevitable delay of a project thus causing us to spend even more money. However, if we were to focus on removing the risk associated with the funded work we can determine if it is still worth pursuing or if the money earmarked for this project would be better suited spent somewhere else.

    I have recently begun to realize that the project progress drivers I used to focus on and track are actually not very helpful to measuring the likelihood of a project being completed on time.

    Buckets of Risk

    I believe that reframing our projects as a reduction in our exposed risk will allow us to focus our conversations on how valuable this investment is as opposed to how much money we might possibly make. If we continue this theory as we get more granular with the work and identify specific “buckets” of risk that are threatening to derail our progress we can more accurately predict if we will be able to deliver our work on time. The buckets I have used to date are Technical, Business, Verification & Validation, Organization and Dependencies. Let’s see some of the questions I’ve asked for each of these risk drivers and then you can decide if you think that these drivers will help you track the progress of your project.

    Technical:

    • Do we have the technology in house already?
    • Is this going to impact our current architecture?
    • Do we have the appropriate skill set for the needed technology?

    Business:

    • Do we have clarity of scope?
    • Do we understand the target market?
    • Can we deliver on the intended business value?

    Verification & Validation

    • Do we know how we are going to test this work?
    • Do we have sufficient information to be able to know when we should address this risk?

    Organization

    • Are the teams that need to work on this risk stable and fully staffed?
    • Do we have the appropriate environments available to properly develop and test our work?

    Dependency

    • Is there anything that must be done outside of this team in order to deliver this work?
    • If there is work required by others, do we know their lead times?

    Answering these questions will provide us the information necessary to truly understand our progress and make key decisions around the work we are evaluating.

    The post Reframing to Reduce Risk appeared first on LeadingAgile.

    Categories: Blogs