Skip to content

Feed aggregator

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

Rally Scores a B Corp Three-peat

Rally Agile Blog - Fri, 09/26/2014 - 22:07

 

 

Why do YOU love Rally? That’s the question we asked all our employees when we found out we earned the Best for the World: Worker Impact award for the third year in a row! We made the list by scoring in the top 10 percent of all Certified B Corporations for employee impact on the B Impact Assessment — a comprehensive evaluation of a company's impact on its workers, community, and the environment. Rally scored particularly high in the work environment and compensation, benefits, and training categories.

 

All Certified B Corps, including well-known companies such as Ben & Jerry’s, Dansko, Method, Patagonia, and Seventh Generation, must meet the same rigorous standards of being a socially-conscious business. We are thrilled to be honored among these companies as one that is Best For Workers.

 

One of our core values, make and meet commitments ensures we hold ourselves accountable to our team members and to Rally when meeting our business objectives and goals.

 

To spread the good news about the award, we wanted to celebrate in ways that would make a lasting impression. First, we hosted a thank-you party at Boulder headquarters with desserts prepared by employees of Community Table Kitchen, a social enterprise of Boulder’s Bridge House that provides culinary arts training for people transitioning out of homelessness as a stepping stone to mainstream employment and self-sufficiency.

 

 

 

Ryan Martens, our CTO and founder, joined me in sharing our thoughts on the award and how much it means not only to Rally but to us personally.

 

“At Rally, we've always believed that for-profit business should be a force for social good, and that passionate, engaged employees are key to solving some of the worlds toughest, most complex problems,” said Martens. “Our employees are critical to making that vision a reality, and we're proud to be recognized for fostering an environment where employees can thrive.”

 

Next, we asked employees worldwide to share why they think Rally is a great place to work. In addition to posting some #RallyLoveNotes in our All Employee flow on Flowdock, we’ll be showcasing even more responses on a visual display that will live at our Boulder headquarters.

 

Our hope is that the display serves as ongoing inspiration for our employees, customers, and visitors for years to come.

 

Liz Andora
Categories: Companies

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

    Agile Business Conference, London, UK, 8-9 October 2014

    Scrum Expert - Thu, 09/25/2014 - 17:58
    The Agile Business Conference is a two-day conference that takes place in London where meet and engage with the experts and thought leaders who have implemented focused, efficient Agile change programmes in a wide variety of industries. In the agenda you can find topics like “I’m an Alien … I’m a Business Analyst in an Agile world!”, “Scaling agile effectively in business systems through roadmap and budget planning”, “Agile Maturity”, “Agile Programme Management Steve”, “The ABC of Agile Biology Class – How your body and mind transforms your team to greatness”, ...
    Categories: Communities

    Lean Agile South Africa, Cape Town & Johannesburg, South Africa, 6-10 October 2014

    Scrum Expert - Thu, 09/25/2014 - 17:53
    Lean Agile South Africa is a set of two two-days conferences focused on Agile and Lean that will take place in Cape Town the 6-7 October 2014 and in Johannesburg the 9-10 October 2014. In the agenda you can find topics like “The Building Blocks of Scale” by Mary and Tom Poppendieck, “Embracing the Agile Mindset for Organizational Agility”, “Culture Eats Lean for Breakfast”, “12 Adoption Failure Modes”, “Lean Testing”. Web site: http://www.leanagile.co.za/ Locations for the 2014 conference: Cape Town: The Clock Tower Centre, South Arm Road, V&A Waterfront, Cape Town Johannesburg: The Core, 1st ...
    Categories: Communities

    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

    Super-Sized Agile

    Agile Management Blog - VersionOne - Thu, 09/25/2014 - 14:00

    Guest post by Bob Schatz of Agile Infusion, LLC

    agile-infusion-bob-schatzThe interest in expanding agile development practices is growing at an increasingly faster rate. The good news is that this indicates that companies are seeing positive results in their initial experiences on projects and are looking to further the expansion, even beyond product development. The challenge is recognizing that these early successes required overcoming many obstacles and shifting the mindset of a number of people. And that these things get exponentially harder as you introduce change across the enterprise.

    The pressure is also put on consultants, trainers, authors, speakers, agile software tool vendors, and coaches to codify and simplify models to reduce the strain from employing agility at scale or “super-sized agile). When success happens, everyone wants to share the experience, but they often focus on showing the model that worked for them in a specific case. Since the structures are simple by design, this creates a feeling that it must be relatively painless to just replicate the experience in other parts of the company, and then to other companies.

    This is similar to what we’ve seen in the past with the basic Scrum process, Lean/Six Sigma, the Toyota Production System and just about any process improvement strategy that has a significant success story to tell. As a result, there has been a flood in the community of scaled agile methods that are all too similar to be called different. Arguments ensue on a daily basis; thought leaders pit their methods against the others trying to prove why they have the right answer. A slew of marketing professionals try to position each method as the better answer in hope of attracting a “big fish” company that will tout how successful the method made them. Right now, we have no less than six scaled agile methods actively being marketed, not to mention the hybrids that companies are presenting in conferences, articles and such. And the methods just keep coming! Ultimately, success will require:

    • Identifying the problem you are trying to solve
    • Understanding your current organization and its ability to satisfy consumers
    • Identifying the gaps
    • Designing an organization and process
    • Growing your leaders at all levels
    • Execution and relentless continuous improvement

    In order to bring us back to the ground, I would like to tell a couple of my own stories which might help you and your organization focus on keeping things simple and overcoming the struggles that all organizations will eventually face in order to instill a culture of continuous improvement and process innovation. These will be critical to serving your customers better than anyone else can.

    Back to the Future

    My first story is from what seems not too long ago, but I guess that’s what all of us “old-timers” say.  I came into the software profession as a programmer in 1984. I was hired by GE in Valley Forge, PA in the start of my senior year of college when defense contractors were building up at an incredible pace.  I was really looking forward to seeing how the little projects we were doing at school would apply to working on a massive Department of Defense project. And just to be honest, a lot of my school projects involved punch cards. So, the first scaling problem I had was keeping a huge deck of cards in the right order!

    The first project I was assigned to at GE was a massive system involving hardware, space vehicles, communications, ground stations, and a host of other components and challenges that made my head spin. The system involved thousands of people across multiple contractors and government agencies all working together to solve a huge problem. It was even more complicated by the fact that this was a classified system where we had to deal with compartmentalization and people with different need-to-know levels that restricted with whom you could collaborate.  The project management was mostly visual techniques and we relied heavily on interface control documents, which let us know the inputs and outputs for our piece of the puzzle. (In reality, those documents were not entirely accurate, coordinated, or followed, which caused more than a few defects later in the project).

    We all relied heavily on each other to communicate from one component or process to the next. System integrators tried to keep an eye on all of the parts to ensure a smooth system-wide deployment. These projects went on for years. We employed what we now know as the waterfall development model, but at the time we just referred to it as MIL-STD version 2167.  Now, I’m not claiming that these were smooth projects. They were terrible and required massive amounts of overtime (which luckily we were paid for), rework, and heroics of some of us to pull it off. These were much different times, but looking back, we did what always worked, and used common sense and a will not to fail. We were motivated to serve our nation’s best interests and we were young, enjoying cashing in those big overtime checks. Organizing ourselves was less of  an issue, knowing that we had to solve important problems and everyone was focused on success.

    For my 12 years there, the projects got bigger and more complex. We kept using the same organization techniques because they worked for us in those circumstances.  Every project required a level of heroics at the end, which nobody would tolerate today. These were different times. Today’s software development environment requires faster speed, much higher quality, and the ability to adapt to a much higher rate of change. My point here is that we didn’t need a model to tell us what to do and, to my knowledge, there was never a Scaled Waterfall Model.

    A Burning Platform

    Fast-forward through a number of great experiences, including a very successful start-up where I really learned the value of agility in its purest sense before “agile development” was a term. At the end of 2001, I wound up as the vice president of development at Primavera Systems. Now part of Oracle, Primavera makes enterprise portfolio, program, and project management software. This was where we used Scrum staring in early 2003 in an organization with almost 150 people — that became one of the first, and certainly well-publicized agile success stories.

    We started off with the goal to improve our lives, our products, and our relationships with other groups in the company. We had serious issues with our product and process. More importantly, our people were suffering. Nothing I tried in all of my leadership experience to date had worked to my satisfaction in my first year there, so it was time to radically re-tool.  Scrum was just a leap-of-faith decision to attempt to save us.

    Our challenges began with figuring out how to create Scrum teams. We wound up with about 20 of them all working on a single, large enterprise product. We ran into a lot of issues with builds and people stepping on each other, so we innovated. We set our focus on stopping the branch/merge environment and forced ourselves into a single trunk, so everyone was now responsible.  We had discussions about how to coordinate dependencies, coordinate development of feature sets involving multiple teams, and how to deal with obstacles that affect many teams. As with everything we didn’t have an answer for, we designed experiments and tried them. This led us to create the idea of having a representative from each team form another Daily Scrum after each team conducted their own to coordinate and deal with cross-team topics. This eventually became known as the Scrum of Scrums. It also led to solving the issue of having 10 product owners learning to coordinate their decision-making by establishing a chief product owner role.

    We created the idea of an integration Scrum team focused on testing integrations with other products in our portfolio, as well as third-party integrations. They also did continuous performance testing. We carved out fixed days/times for functional meetings so that directors of development, testing, documentation, etc. could spend two to three hours developing their people and their disciplines. We had teams who organized around certain product areas, architecture, and database development, helping to keep everything coordinated. We kept working on the process to improve and expand it.

    Once we had a good handle on our own work, we had all other organizations participate in Sprint Reviews so they could get access to the product being developed. We brought in end users from the very start and just kept getting more and more of them to participate, which really helped us to build a better product. They became increasingly engaged in helping us manage our portfolio and product backlogs.  As we moved forward, we dealt with other challenges like having multiple chief product owners, all with their own products wanting to use the same Scrum teams, and learning to manage the flow of work.  Later, we encountered  the challenges of distributed development and forming Scrum teams in India and the Ukraine.

    Through it all, we just kept doing the hard work of solving problems and not looking for the silver bullet as Ken Schwaber had taught us so well. The message is clear; agile development practices are simple by design; implementing them is hard. It requires people who want to improve their circumstances. They want to serve their customers better than everyone else. They are willing to use their smarts to design experiments that will help them get there. And they are willing to fail sometimes, but learn quickly.

    So, Now What Do We Do?

    The answers to large-scale agility do not lie in a book, or a set of slides, or a poster. Every project that has more than one team is a project at scale, and every environment is different. The answers will emerge when people are willing to put in the work. There are no shortcuts; seeking shortcuts will only result in change initiatives that will not survive the test of time. Stories like these can help spark ideas, but they are not to be followed like a recipe. Doing so only sets us up to repeat history. So, the first question is not which model to follow, its asking yourselves “What problem are we trying to solve?”

    Categories: Companies

    Why is it Called an Agile Transformation?

    Agile Management Blog - VersionOne - Thu, 09/25/2014 - 13:56

    Guest post by Charlie Rudd of SolutionsIQ

    We’re not in Kansas anymore.

    Most organizational change initiatives are not called transformations. So how come agile change initiatives are? To answer this question, let’s first review some examples of organizational change as well as the impact they have on the people in the organization.

     

    charlie-rudd-solutionsiq-image

     

    Note in the above table how the magnitude of change deepens as you move from the top to the bottom of the table. At the top of the table, the change has little impact on the day-to-day work of most individuals. However, at the bottom, the impact of change can be quite profound. For example, changing the corporate culture uproots deeply embedded behavior and necessarily changes long-standing beliefs and assumptions.

    Working with this principle, we can identify three levels of organization change magnitude:

    Superficial org change

    This type of org change has little impact on your day-to-day responsibilities and activities. Many corporate re-orgs are actually superficial. For example, your company may hire a new VP, but that doesn’t necessarily affect the project you’re working on, the work you perform on it, or the people you work with.

    Significant org change

    This type of org change has a greater impact on you. Your job or your work environment is affected, but usually not your role or job description. For example, some work procedures may change, and you may receive training or new software tools as a result. You may even have to join a new team or someone new joins your team. Perhaps you have to move to an office in a different building. Whatever the case, when your organization undergoes a significant org change, you are definitely affected even if the effect is rather minimal.

    Transformational org change

    Often, after a transformational org change, you have a new role that you have never performed before. Your job responsibilities change radically. So do your supervisors and their responsibilities. You have to approach your work in an entirely novel way, learning completely new skills, and often a new vocabulary. The unwritten rules that used to guide how you act and what you do no longer apply. Your work world is completely new. It’s surprising. It’s refreshing. It’s strange.

    Let’s now consider where agile transformation fits within this org change magnitude framework:

    Agile org change

    In an agile transformation initiative, some of the change is superficial – some more significant – but when successful, the bulk is transformational. Learning new practices and tools are needed, but not sufficient for lasting success. Change must go deeper, in many cases down to the roots of corporate values, and what had been unquestioned management principles. It must encompass a new way of thinking about work and your place in this new world. Long-standing assumptions and unwritten rules go out the window as you discover new ways to work together with your colleagues, every day. This is why it’s called an agile transformation:  you, your job, your responsibilities, your management, and your organization are transformed into something new.

    So are we in Kansas anymore? In a word:  nope. We’re not in Kansas. Agile transforms your world. It’s surprising. It’s refreshing. It’s strange. Whatever you think agile may be, there’s one thing it’s not:  business as usual.

    Categories: Companies

    So You Want to Scale Your Agile?

    Agile Management Blog - VersionOne - Thu, 09/25/2014 - 13:45

    Guest post by AgileBill Krebs of Agile Dimensions

    Some teams – such as sustaining engineering teams – are fine with Kanban. This method shows work on a taskboard as it progresses from waiting, to doing, to done, with an eye toward cycle time and focusing on a few things at once.

    Some teams are fine with traditional Project Management Body of Knowledge (PMBOK – from the PMI) – as in special client engagements.  This covers key project aspects such as cost, procurement, communications, and may use a Gantt chart to plan jobs of known but varying sizes.  Unlike most of our agile projects, this will assume there is little likelihood of change.

    Some teams are fine with Scrum development.  Two-week iterations and sprints give vital visibility into progress, and also windows for change.  Teams learn empirically and use these iteration windows to tune and adjust their product and procedures.  Extreme Programming (XP) plans in a similar fashion, but adds some technical practice to build quality in.

    These teams often have nine or fewer people, with three to six months for work.  But what if the project or product you deliver has 40 people?  100 people? 300 people?

    Projects like these would require scaling up your agile.  Authors such as Jutta Eckstein, Scott Ambler, Kenny Rubin, and Dean Leffingwell have all described ways to do this.

    Using such concepts in practice with dozens of teams has shown six key areas:

    1)  Roll-out – does management and the teams know agile at scale is different?  Are they committed to doing it, and have they had some training on multi-team agile?   Do you have someone prepared to program manage a team of teams?

    2)  Common language – one team can use whatever terms they wish.  But when team of teams (aka, Scrum of Scrums) forms, it quickly becomes a mess where some say ‘Feature’ and some say ‘Epic.’  Pick a scaled agile methodology and vocabulary, and make that your organization’s common language.

    3)  Features – it helps organize larger projects to use the ‘parent’ of a story.  Let’s call this a ‘Feature’ (like Dean Leffingwell’s Scaled Agile Framework® or SAFe™).  While we still use small Stories, it becomes more important to plan ahead using larger Features so other teams can know when to depend on our output.  This also helps stakeholders gain a picture of our product even as the number of Stories multiples as the team grows in size.

    4)  Align the business – with larger projects, it becomes even more important for business-facing parts of your organization to connect with your scaled agile process. Planning at higher levels such as portfolio (multiple products) and program (multiple teams) becomes more integral to how we work.  But working with our market experts is harder if they do not understand our terminology and approaches to delivering at scale.  Other areas such as accounting and your project management office may need to understand your scaled approach as well.

    5)  Kick off each release – spend a little more time before each release to look for dependencies between high-level features.  Let teams know what’s coming, and have them discuss how they will deliver together.

    6)  More than a dozen teams – it makes sense to forge four or even 10 teams into a group that delivers a product.  But if you product requires more than a dozen teams, that will be big enough to demand another sub organization with its own program manager.

    Agile development has been used in many projects, large and small.  Keeping these six factors in mind will help with your enterprise-strength projects. Taskboards may be sufficient with smaller projects, but larger projects benefit from tools designed to see things at more levels – portfolio, program, and team.

    What steps can your project take to work smoothly between teams? 

    agilebill“AgileBill” Krebs has over 20 years of programming, performance, project management, and training in the IT industry at 5 IBM labs, banking, telecom, and healthcare.  He has used agile since 2001, and taught it to over 2,000 people worldwide. He has presented at agile conferences, IBM Research, and conferences on education. Bill’s certifications and groups include SPC, PMI-ACP, CSP, ICE-AC, and others.  He hosts the Distributed Agile Study Group and is a member of ALN, the Scrum and Agile Alliances, ACM, AERA, PMI, and more. He is pursuing a graduate degree in education technology, while working as an enterprise agile coach in the healthcare IT industry.

    Scaled Agile Framework is a registered trademark and SAFe is a trademark of Scaled Agile, Inc.

     

    Categories: Companies

    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 yet finished, stuff that takes up our bandwidth, blocks up resources, etc.. Even things that are blocked or waiting are WIP. Visualize and limit WIP
    • WIP is what it is, regardless of priorities (priorities are what we should be focusing on, WIP is what we are actually doing. They sometimes match…)
    • It’s almost always a good idea to visualize WIP, whether it is at a team level or company level or whatever. Invisible WIP is hard to discuss, hard to challenge, and hard to limit. And hence, invisible WIP tends to grow and slow us down.
    • Make WIP in-your-face-Visible! Ideally on the wall, since people will see it (and hence discuss it) without having to actually find and open a document. If it’s not on the wall, it tends to be ignored or forgotten. Analog visualization (stickynotes etc) usually works best, but showing a digital visualization on a screen works too.
    • Use a “noise threshold” to avoid micromanagement. Avoid cluttering the visualization with hundreds of tiny things. For example, the noise threshold for a team-level visualization could be “if it’s less than 2 hours of work, just do it, don’t bother putting up a sticky”. At a department level the noise threshold could be “things that involve more than one team for more than a week”. Items smaller than that are allowed to “fly under the radar” (which has the added bonus of provided an incentive to break work down into small chunks).
    • If there’s lots of noise, aggregate and visualize the noise (so that it too can be discussed/challenged/limited). For example “# of currently open Jira tickets” instead of displaying each individual ticket.
    • The goal is to visualize all significant WIP that is burdening this team or department or project or whatever, and to do it in a way that doesn’t involve managing hundreds of individual notes on a board.
    • It’s almost always a good idea to define WIP limits. The WIP limit is just “how much stuff can we have in progress before we start getting bogged down with multitasking and coordination overhead”. Start high and gradually reduce it, it’s an awesome way to drive out waste! This is one of the key principles in Kanban.
    • Current WIP will sometimes be higher than the WIP limit! That’s OK. It’s an alerting system. Current WIP is simply our current reality, while WIP limit is our desired reality. Visualizing both makes the problem explicit. As long as we’re over the limit, our main focus is finishing things (or canceling them) and we are super-restrictive about starting new things.

    Here’s an interesting study that shows how WIP limits dramatically benefit quality and speed “The Impact of Agile – Quantified

    Priorities are something different.

    Cascading priorities

    • Priorities are a guidelines to help us decide what new WIP to take on (when our WIP limits allow it), and what things to reject or postpone. Without clear priorites, we risk unaligned autonomy and suboptimization.
    • Priorities also help us resolve resource conflicts within our current WIP (“Joe is needed for both of these tickets, which should he focus on first?” or “Let’s help Team X first, Team Y’s stuff is lower prio”)
    • Priorities should be limited, too! Something like 1-3 items is usually sufficient. Because if everything is important, nothing is important! And if the list is too long, no one will read it or remember it.
    • Priorites can be fluffy ( “our current priorities are 1) repay technical debt, and 2) improve the backoffice UX”.)
    • …. or specific (“our current priorities are 1) Deliver feature X, and 2) Prototype feature Y, and 3) Install the new build tool”)
    • Priorities may correspond directly to the WIP items (“these 3 WIP items are top priority”, or “the WIP items on the board are stack-ranked in priority order”). But they don’t have to be that specific.
    • The test for useful priorties is:
      • 1) “This list of priorities helps us decide what to do today, and what NOT to do today!”
      • 2) “This list of priorities is so short and clear that everyone involved knows it by heart!”.
      • 3) “We all understand why these priorities make sense for the company”
    • Priorites are not exhaustive. We may have lots of things going on that are not directly related to our top 3 priorities. That’s OK, but:
      • Non-priority work should by default not conflict with priority work. There are of course exceptions (“the server just crashed, bring it up again NOW!”), use common sense and talk about it.
    • Guiding principle:
      • 1) Can you contribute to a high-prio item today (directly or indirectly)? If so, do it! Not sure? Ask!
      • 2) If you can’t contribute to a high-prio item, then work on something lower prio, but don’t let it conflict with people working on high prio work.
      • 3) Be explicit about your choice and why.
    • Priorities are cascading (or hierarchical, if you prefer, I just tried to find a less ominous-sounding word)
      • Your team has priorities. So does your department. So does the whole company. Higher level priorities trump lower level priorities, and are essential for alignment. That means:
        • 1) Lower level priorities should, at best, be aligned with higher level priorities (ex: “Department’s priority is Y, Team’s priority is Y”, or “Department’s priority is Y, team’s priority is X which contributes to Y”)
        • 2) Lower level priorties should, at least, not conflict with higher level priortities (ex: “Department’s priority is Y, but that involves mostly other teams, our team can’t really contribute, so we’ll instead prioritize X, and make sure we don’t take time from anyone working on Y”).
    • Avoid individual priorties. That tends to kill teamwork. Better to share priorities at a slightly higher level, such a team or workstream or project.
    • Priorities change (of course!)
      • It’s useful to have a recurring prioritization meetings to reevaluate priorities (every sprint for a team, every 6 weeks for a department, or whatever).
      • … but priorities can also change at any time in between!
      • Higher level priorities shouldn’t change as often, as they have ripple effects on lower level priorities and WIP. Causes confusion. The frequency of prioritization meetings should correspond roughly to how often we expect priorities to need to change.
    • Long-lived and short-lived priorities can be on the same list!
      • For example “our priorities are 1) customer support, 2) project X, 3) tech debt”. Project X might be short-lived and soon to be replaced by Project Y, while “customer support” might stay top priority for years!
    • When a priority list has more than one item, be clear about what this really means.
      • Ex: If our top priorities are “Project A and Project B”, what does it mean? Is A more important then B? Or are they equally important, but more important than other projects? Should we try to work exclusively on A if possible, or should we balance our time between both A and B?
      • No exact rules needed, just some guiding principles.

    If used appropriately, cascading priorities and WIP visualization and WIP limits can really help your organization be focused and fast!

    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

    Knowledge Sharing


    SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.