Skip to content


Python: UnicodeEncodeError: ‘ascii’ codec can’t encode character u’\xfc’ in position 11: ordinal not in range(128)

Mark Needham - Thu, 05/21/2015 - 08:14

I’ve been trying to write some Python code to extract the players and the team they represented in the Bayern Munich/Barcelona match into a CSV file and had much more difficulty than I expected.

I have some scraping code (which is beyond the scope of this article) which gives me a list of (player, team) pairs that I want to write to disk. The contents of the list is as follows:

$ python
(u'Sergio Busquets', u'Barcelona')
(u'Javier Mascherano', u'Barcelona')
(u'Jordi Alba', u'Barcelona')
(u'Bastian Schweinsteiger', u'FC Bayern M\xfcnchen')
(u'Dani Alves', u'Barcelona')

I started with the following script:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player, team])

And if I run that I’ll see this error:

$ python
Bastian Schweinsteiger FC Bayern München <type 'unicode'> <type 'unicode'>
Traceback (most recent call last):
  File "", line 67, in <module>
    writer.writerow([player, team])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 11: ordinal not in range(128)

So it looks like the ‘ü’ in ‘FC Bayern München’ is causing us issues. Let’s try and encode the teams to avoid this:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player, team.encode("utf-8")])
$ python
Thomas Müller FC Bayern München <type 'unicode'> <type 'unicode'>
Traceback (most recent call last):
  File "", line 70, in <module>
    writer.writerow([player, team.encode("utf-8")])
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 8: ordinal not in range(128)

Now we’ve got the same issue with the ‘ü’ in Müller so let’s encode the players too:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player.encode("utf-8"), team.encode("utf-8")])
$ python
Gerard Piqué Barcelona <type 'str'> <type 'unicode'>
Traceback (most recent call last):
  File "", line 70, in <module>
    writer.writerow([player.encode("utf-8"), team.encode("utf-8")])
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 11: ordinal not in range(128)

Now we’ve got a problem with Gerard Piqué because that value has type string rather than unicode. Let’s fix that:

with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        if isinstance(player, str):
            player = unicode(player, "utf-8")
        print player, team, type(player), type(team)
        writer.writerow([player.encode("utf-8"), team.encode("utf-8")])

Et voila! All the players are now successfully written to the file.

An alternative approach is to change the default encoding of the whole script to be ‘UTF-8′, like so:

# encoding=utf8
import sys
with open("data/players.csv", "w") as file:
    writer = csv.writer(file, delimiter=",")
    writer.writerow(["player", "team"])
    for player, team in players:
        print player, team, type(player), type(team)
        writer.writerow([player, team])

It took me a while to figure it out but finally the players are ready to go!

Categories: Blogs

SAFe Lean-Agile Principles Have Arrived!

Agile Product Owner - Wed, 05/20/2015 - 20:18

The impression that “our problems are different” is a common disease that afflicts management the world over. They are different, to be sure, but the principles that will help to improve the quality of product and service are universal in nature.                             —W. Edwards Deming

Why the Focus on Principles?

SAFe provides an integrated set of proven practices that enterprises rely on to improve their solution development capability. Implementation of these practices however, often requires tailoring to address the needs of a specific organization.  Should an enterprise use eight, ten or twelve week PIs? Should they have a System Team at the program or at the value stream level? Should DevOps functions be supported via a hybrid ART team or fully incorporated in each Agile team? What if you can’t integrate every day, or even every iteration? Should the trains be organized around capabilities or subsystems?

As a framework, SAFe can only take things so far, after that it’s up to the judgment of those doing the implementation. But how can SAFe provide guidance with this kind of decision-making? Answer: By clearly articulating the underlying principles that make SAFe safe.

To that end, we’ve developed nine principles that summarize the key tenets of Agile, Lean process and product development, Systems thinking and product development flow, as applied in the context of building large systems and solutions. These are the fundamental tenets, the basic truths and economic underpinnings that drive the roles and practices that make SAFe effective. Of course, you can’t possibly capture this complexity in only nine principles, but that doesn’t mean you shouldn’t try. To that end, we offer the following.

Screen Shot 2015-05-19 at 4.39.03 PM

SAFe Lean-Agile Principles

These new principles can be accessed from the new Principles tab. Each is hyperlinked to a short article that describes the principle in further detail.

The Sources

These principles incorporate lessons learned from applying Agile, Lean and SAFe practices in the field for over a decade, in a hundred different contexts. We’ve observed, recorded, drafted, revised, incorporated feedback and tried again. It’s from this field experience that we’ve observed patterns that are effective in Screen Shot 2015-05-19 at 4.46.22 PMenterprise after enterprise. Underlying these successful patterns are the principles that cause those patterns to be effective. In order to find them, you just have to dig a little further into the theory, abstract a bit, write them down, read them, and then listen to what they tell you.

Screen Shot 2015-05-19 at 4.43.42 PM

They are also derived from the Agile body of knowledge—from the Agile Manifesto to the many books and methods, Scrum, XP, Kanban—and dozens of books by the Agile thought leaders we all know so well. And in order to scale, we take our inspiration from Lean Thinking, and writings on human potential and knowledge creation from seminal and ground breaking authors Deming, Drucker, Pink, Oosterwal, Ohno, Nonaka and Takeuchi, Ries, Kim, Reinertsen, Liker, Ward, Kennedy, and many more.  Some of these books represent a lifetime of learning condensed into a few hundred pages.

We are standing on the shoulders of giants. Let’s make sure we apply all that we have learned.

Categories: Blogs

Help! My Scrum Master is Running the Sprint!

Agile Game Development - Wed, 05/20/2015 - 19:15

“Hi, I had a question.  Our Scrum Master is acting like a manager, running all the meetings and assigning work.  This is what they did before Scrum.  I thought Scrum meant the team did this stuff?” - A developer

The values of Scrum apply here.
Scrum! Scrum! Scrum! Scrum!
The sprint is the team’s commitment to a goal.  True commitment to the game and continuous improvement requires a level of ownership, otherwise it’s an environment of compliance and people don’t engage as well with that.

The barrier to allowing ownership is fear.  I often hear the micro-managing Scrum Master’s fear of what will happen if the team doesn’t follow their leadership.  "They might fail!", they cry.   There is often an underlying suspicion that others on the team are not competent because they'll make mistakes.   The news is that competence doesn't mean you don't make mistakes!

Allowing teams to make mistakes and safely fail from time-to-time requires trust and courage.  Trust requires respect.  A lack of trust and respect is a cultural root of evil.  When I see locked supply cabinets, dictated core hours or time-sheets, web filters, people referred to as “resources” etc. I know that the true adoption of Scrum will be a bit harder.

How can this be done?
Courage is requiredShifting from a mindset of individual compliance to team commitment requires courage all around.  The Scrum Master and the team must summon the courage to take chances and fail every once in awhile.  Emboldening the team to find this courage is more challenging than micromanaging via a task spreadsheet, but it’s also more fulfilling.  It doesn’t happen overnight, but trust and respect can be grown.

Scrum Masters can start with some simple things:
  1. Silence yourself! Stop doing all the talking.  Learn to allow awkward silences.  The team will fill the silence with their own ideas and solutions.
  2. Ask questions, even when you know the answer.  Teach them to catch fish rather than giving them fish to eat.
  3. Be courageous.  Demonstrate respect and protect the team.
The development team assumes a part of this challenge as well.  It’s often hard for them to shift from being assigned tasks to accepting responsibly for planning and executing their own work.  Respect and openness among each other is critical.

For example: if an artist is having problems getting code to work with a model, the entire sprint goal is threatened, but the team's focus on their shared goal should guide them to solve this problem on their own.   There is no need to blame the artist for not solving their own problem.  There is no need for someone wearing a manager’s hat to assign an engineer to fix the problem.

Does this mean managers/producers should be fired?
Don't expect leadership to
be overthrown, but leveragedAn underlying fear from managers or producers jumping into the Scrum Master role is that they should continue doing what they've been good at in the past or they'll be let go.

In the ten years that I have been training teams to use Scrum, I haven’t seen this happen.  I’m not saying it never will, but most stories I hear reflect my own as a manager in a studio that adopted Scrum.

I found that as teams became more self-organizing, there was a growing part of my time that needed to be filled with other things.  Eventually, about half my day was freed up by not micro-managing.  This wasn’t bad because the work that teams took from me was never the work I enjoyed doing.  So, I joined a team as their product owner and ended up enjoying the work far more as I was closer to the game and the people making it.

This might not be the path for every manager.  Agile should lead a studio to ask what practices and roles are benefitting their games and the people making them and what parts are not.  Again, this can threaten the status quo, which is why a lot of larger, established studios have a harder time adopting agile.

"Now I can make cool movies about
monkeys taking over the world!"The bottom line is that these values have to win out for you to have full success with agile.
Categories: Blogs

Gibt es ein Leben nach dem Jobtitel?

Scrum 4 You - Wed, 05/20/2015 - 08:00

So wie bei vielen anderen Unternehmen auch gibt es auf unserem Portal mehrere Stellenanzeigen. Wir suchen wie verrückt: Senior Consultants, Senior Entwickler, ScrumMaster, Scrum Coaches etc. Vor ein paar Tagen stieß ich in diesem Zusammenhang auf einen spannenden Blogbeitrag von Johann-Peter Hartmann von Mayflower, in Deutschland bekannt für die agile Softwareentwicklung u.a. in PHP. Sein Artikel „Warum wir keine Titel und Positionen mehr haben“ hat mich sehr nachdenklich gemacht. Er schreibt: „Scrum macht jeden Sprint eine Retrospektive, um die Prozesse und Organisationsform kontinuierlich zu adaptieren. Kanban schleppt ein ganzes Sammelsurium von Messinstrumenten mit, um überhaupt feststellen zu können, wie es im Projekt aussieht und was gerade gebraucht wird. Agil fordert cross-funktionale Teams, bei DevOps wird die Brücke in den Betrieb geschlagen. Das Team ist eigenverantwortlich. Es trägt die Verantwortung selbst. Nicht der Projektleiter, nicht der Teamleiter, nicht der Senior Architect und nicht der Technical Lead. Und wenn alles angepasst werden kann, und alle Entscheidungen vom Team ausgehen, bilden Positionen und Titel da eine Ausnahme? Alles darf angepasst werden, nur die Titel und Positionen nicht? Das Team darf entscheiden und ist verantwortlich, ausser da ist ein Technical Lead, ein Architect oder ein Team Lead?”

Johann-Peter hat damit natürlich vollkommen recht und diese Frage ist genial. Sie zeigt, dass man am Ende auch die eigene Organisation hinterfragen muss. Doch wie wirkt das nach außen? Findet man Entwickler oder Consultants, wenn man nicht explizit nach z.B. „Senior Consultants“ sucht? Ich denke, das ist schwer und das schreibt er auch: „Und dann kommt die Irritation. Denn sie (die Bewerber) wollen Teamleiter, C*O, irgendwas mit Personalverantwortung, Head of *, * Lead oder Senior Architect werden. Auf gar keinen Fall einfach nur Developer. Nein, ein Titel muss her, man will ja die eigene Leistungsfähigkeit in der Karriere abgebildet sehen. Tja, und damit können wir – und viel wichtiger wollen wir – gar nicht dienen. Weder die HR-Abteilung noch die Geschäftsführung kann Leute auf Positionen einstellen oder einen Titel vergeben. Denn die existieren bei uns nicht mehr.”

Diese Idee, dass es keinerlei Positionen mehr gibt und dass es sich natürlich auch auf die Stellenanzeigen auswirkt, ergibt Sinn. Aber Moment … jemand vergibt die Jobs und wählt aus. Der Gesetzgeber verlangt zum Beispiel bei einer GmbH einen Geschäftsführer, der im Interesse der Gesellschaft handelt und möglicherweise sogar die Interessen der Gesellschaft gegen die Interessen der Gesellschafter abwiegt. Er ist also mit Leib und Seele gesetzlich in der Position der Gesamtverantwortung gebunden, ob er das nun persönlich will oder nicht.

Real existieren mehrere Konflikte, die diesem Gedanken auf den ersten Blick widersprechen:

  1. Die Bilder im Kopf der Mitarbeiter
  2. Die gesetzlichen Rahmenbedingungen
  3. Die gelernten Reflexe von Mitarbeitern und Management
  4. Das Umfeld, in dem diese Firmen arbeiten – denn die Kunden wollen oftmals mit dem Senior XY arbeiten.
  5. Die Gesellschafter/das Board – wollen die auch agil?

Nun kann man solche Überlegungen natürlich als Fatamorgana abtun und entgegenhalten: “Das ist altes Denken, traditioneller Quatsch!“ Doch Phänomene weisen uns immer auf etwas hin: Dass da etwas ist – ein zugrunde liegendes Bedürfnis, ein tief sitzender Faktor, der immer mitschwingt und vielleicht erst überwunden werden muss.

Ich kann nur von meinem eigenen kleinen Unternehmen erzählen, denn auch bei uns sind Aufstieg und Verantwortung, Gehaltserhöhungen, Selbst- und Fremdwahrnehmung immer wieder ein Thema. Warum eigentlich? Wir sind “leading edge“ im agilen Umfeld. Wir wissen, was agile Führung bedeutet und wohin der Zug fahren sollte. Wieso straucheln auch wir immer wieder? Ist es, wie ich dem Gespräch mit einem Professor der Psychologie entnommen habe, die Sozialisation? Haben uns die Gesellschaft, Schule, Familie (soziologisch gesprochen: die Institutionen) so geprägt?

Wenn die Graugans in uns schnattert

Ich vermute, die tieferliegende Ursache hinter alledem ist das Thema Rang = Status. Soziale Wesen wollen wissen, in welchem Verhältnis sie zu den anderen stehen – also auf welcher Rangstufe. Das mag jetzt zu simpel sein: Konrad Lorenz war der erste, der das am Verhalten von Graugänsen gezeigt hat. Sofern mich die Erinnerung an meine Biologie-Schulstunden nicht täuscht, arbeitete er heraus, wie wichtig die Hackordnung in sozialen Verbänden ist. Schaut man sich die neueren Erkenntnisse der Neurologie an, so ist genau der Status für uns alle immer ein Thema. Status ist wichtig, weil wir uns in sozialen Verbänden nur dann sicher fühlen, wenn wir wissen, wo wir stehen. Die bereits von Lorenz beschriebenen Phänomene sind u.a. Ausdruck dessen, dass etwas in uns nach Status (Rang, Titel usw.) strebt. Wir alle wollen Auszeichnungen, wir wollen Preise gewinnen und uns von der Masse abheben, Rangkämpfe sind „normal“ und gehören dazu. Sie sind nicht etwa Ausdruck von Machtgier, sondern entstehen aus dem Bedürfnis nach Sicherheit in der Gruppe. Alle, nicht nur „agile“ Teams, erleben diese Suche nach dem Platz in der Gruppe als Verunsicherung in der Storming Phase. Als Wissenschaft ist die Soziologie entstanden, um den Menschen aus der Unmündigkeit der nicht verstandenen Herrschaftsbeziehungen zu befreien. Soziobiologisch sind wir aber in diese Statuskämpfe hineingezwungen und vieles in unserem menschlichen Verhalten lässt sich tatsächlich auf diese Instinkte zurückführen. Aber sind wir ihnen ausgeliefert? Nur dann, wenn wir sie nicht erkennen und uns nicht von ihnen befreien.



Agilität ist eine bewusste Entscheidung

Agiles Arbeiten ist u.a. der Versuch, sich dieser Instinkte bewusst zu werden und immer und immer wieder dagegen anzugehen, um die menschliche Natur zu kultivieren.
Die Beispiele, die in „Reinventing Organizations“, in meinem Buch „Selbstorganisation braucht Führung“ und auch im Blogbeitrag von Johann-Peter Hartmann zu lesen sind, schüren die Hoffnung, dass Menschen in Teams und Organisationen beginnen, diese Zusammenhänge zu verstehen und sich immer wieder bewusst gegen das Eingefahrene entscheiden. Das ist extrem anstrengend für alle Beteiligte. Aber Verhalten lässt sich ändern, auf unterschiedliche Weise. Es beginnt mit dem Glauben daran, dass dieses andere Verhalten für alle befreiender ist und uns glücklicher, gesünder und erfolgreicher macht. Diese bewusste Entscheidung ist es, die uns in die Richtung des agilen Managements führen wird.

Ich finde es toll, dass es Mayflower gelungen ist, die Titel intern abzuschaffen. Ich würde mich sehr freuen, wenn wir in den kommenden Jahren noch öfter solche Artikel von verschiedenen Unternehmen lesen könnten. Ein Beispiel habe ich noch: Seht euch mal die Firma an. Gerhard Andrey hat bei der BWI Fachtagung in Zürich wunderbar erklärt, wie sie es in ihrem Unternehmen umgesetzt haben. Er erzählte über Open Source, über Teams und die Guilds (für die man sich u.a. bewerben muss). Toller Vortrag.

Übrigens: Beim nächsten Treffen des Software Forums Leipzig im November werden wir das Thema Führung und Selbstorganisation beleuchten und miteinander diskutieren. Vielleicht macht ihr mit?

Categories: Blogs

Neo4j: Finding all shortest paths

Mark Needham - Wed, 05/20/2015 - 00:45

One of the Cypher language features we show in Neo4j training courses is the shortest path function which allows you to find the shortest path in terms of number of relationships between two nodes.

Using the movie graph, which you can import via the ‘:play movies’ command in the browser, we’ll first create a ‘KNOWS’ relationship between any people that have appeared in the same movie:

MATCH (p1:Person)-[:ACTED_IN]->()<-[:ACTED_IN]-(p2:Person)
MERGE (p1)-[:KNOWS]-(p2)

Now that we’ve got that relationship we can easily find the shortest path between two people, say Tom Cruise and Tom Hanks:

MATCH (p1:Person {name: "Tom Hanks"}), (p2:Person {name: "Tom Cruise"}),
      path = shortestpath((p1)-[:KNOWS*]-(p2))
Graph  18

That works pretty well but what if we want to find the longest shortest path between any two people in the graph? We can calculate it like this:

MATCH (p1:Person), (p2:Person),
      path = shortestpath((p1)-[:KNOWS*]-(p2))
Graph  19

So that’s 6 hops which is actually the Bacon number – I expect we’d probably see a smaller maximum value if we imported all the movies.

And to round off the post what if we want to find the longest shortest path between the 10 people who acted in the most movies? We might start out with the following query which seems like it should do the job:

MATCH (p1:Person)-[:ACTED_IN]->()
WITH p1, COUNT(*) AS appearances
ORDER BY appearances DESC
WITH p1 AS p1, p1 AS p2
MATCH path = shortestpath((p1)-[:KNOWS*]-(p2))

Unfortunately if we run that query we get no rows returned because ‘p1′ and ‘p2′ always refer to the same node.

Instead we can calculate the shortest path between our hardest working people by creating a cross product using COLLECT and UNWIND:

MATCH (p1:Person)-[:ACTED_IN]->()
WITH p1, COUNT(*) AS appearances
ORDER BY appearances DESC
MATCH path = shortestpath((p1)-[:KNOWS*]-(p2))

Graph  20

That’s all for now!

Categories: Blogs

Agile Is Supposed To Be Simple…

Leading Agile - Mike Cottmeyer - Tue, 05/19/2015 - 20:37

I was reading about the new iteration of SAFe that came out a few days ago. I appreciate what Dean is doing with SAFe and totally get the problem he is trying to solve. That said, it makes me wonder how folks receive the ever growing complexity of the model.

Fundamentally, we have two choices as leaders of companies.

We can model and manage the complexity inherent in the system, or we can reduce that complexity. What we can’t do is pretend the complexity doesn’t exist and fail to do something about it. So often I see agile implementations that want to ignore what’s really going on.

This is too complex, agile is supposed to be simple.

True, but agile is also supposed to be 6-8 people sitting in a room with an onsite customer. Teams are supposed to have autonomy. Teams are supposed to have the power to decide. Teams are supposed to have the ability to change direction when they learn new stuff.

You can’t have your cake and eat it too.

It’s naive to think that three roles, three ceremonies, three artifacts are going to fix everything in your organization. It’s naive to think that you can self-organize the complexity away. It’s naive to think that companies are going to stop caring about when and how stuff is going to get done.

So again, we come back to two fundamental choices for making all this work. Model and manage the complexity in the system, or make the system less complex. It’s your call.

The post Agile Is Supposed To Be Simple… appeared first on LeadingAgile.

Categories: Blogs

The Scrum Values

Agile Game Development - Tue, 05/19/2015 - 19:28
The Scrum Values
  • Focus. Because we focus on only a few things at a time, we work well together and produce excellent work. We deliver valuable items sooner.
  • Courage. Because we are not alone, we feel supported and have more resources at our disposal. This gives us the courage to undertake greater challenges.
  • Openness. As we work together, we practice expressing how we're doing, and what's in our way. We learn that it is good to express concerns, so that they can be addressed.
  • Commitment. Because we have great control over our own destiny, we become more committed to success.
  • Respect. As we work together, sharing successes and failures, we come to respect each other, and to help each other become worthy of respect.

Categories: Blogs

NeuroAgile Quick Links #12

Notes from a Tool User - Mark Levison - Tue, 05/19/2015 - 17:32
A collection of links to interesting research from the world of neuroscience and behavioural psychology that can be applied (or not) to Agile/Scrum Teams. original graphic design by Freepik
Categories: Blogs

End-to-End Hypermedia: Making the Leap

Jimmy Bogard - Tue, 05/19/2015 - 17:26

REST, a term that few people understand and fewer know how to implement, has become a blanket term for any sort of Web API. That’s unfortunate, because the underlying foundation of REST has a lot of benefits. So much so that I’ve started talking about regular Web APIs not as “RESTful” but just as a “Web API”. The value of REST for me has come from the hypermedia aspect of REST.

REST and hypermedia aren’t free – they significantly complicate both the building of the server API and the clients. But they are useful in certain scenarios, as I laid out in talking about the value proposition of hypermedia:

  • Native mobile apps
  • Disparate client deployments talking to a single server
  • Clients talking to disparate server deployments

I’ve only put one hypermedia-driven API into production (which, to be frank, is one more than most folks who talk about REST). I’ve attempted to build many other hypermedia APIs, only to find hypermedia was complete overkill.

If your client is deployed at the same time as your server, lives in the same source control repository, hypermedia doesn’t provide much value at all.

Hypermedia is great at decoupling client from server, allowing the client to adjust according to the server. In most apps I build, I happily couple client to server, taking advantage of the metadata I find on the server to build highly intelligent clients:

@using (Html.BeginForm()) 
    <div class="form-horizontal">
        <hr />
        @Html.FormBlock(m => m.LastName)
        @Html.FormBlock(m => m.FirstMidName)
        @Html.FormBlock(m => m.HireDate)
        @Html.FormBlock(m => m.OfficeAssignmentLocation)

In this case, my client is the browser, but my view is intelligently built up so that labels, text inputs, drop downs, checkboxes, date pickers and so on are created using metadata from a variety of sources. I can even employ this mechanism in SPAs, where my templates are pre-rendered using server metadata.

I don’t really build APIs for clients I can’t completely control, so those have completely different considerations. Building an API for public consumption means you want to enable as many clients as possible, balancing coupling with flexibility. The APIs I’ve built for clients I don’t own, I’ve never used hypermedia. It just put too much burden on my clients, so I just left it as plain old JSON objects (POJSONOs).

So if you’ve found yourself in a situation where you’ve convinced yourself you do need hypermedia, primarily based on coupling decisions, you’ll need to do a few things to get a full hypermedia solution end-to-end:

  • Choose a hypermedia-rich media type
  • Build the server API
  • Build the client consumer

In the next few posts, I’ll walk through end-to-end hypermedia from my experiences of shipping a hypermedia API server and a client consumer.


Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

Is Your Program Team Just a Messin’ an a Gommin’?

Leading Agile - Mike Cottmeyer - Tue, 05/19/2015 - 15:09

A long, long, well… long time ago when I was a young man, my Grandma Lossie would get all dressed up and her best friend Gladys would come pick her up for a night out. When I asked those two what they were up to, one of these two south Georgia ladies would always say, “We are just a messin’ an a gommin’!”  It was at this point that I always insinuated they were going out to pick up younger men.  They would cackle, but they really meant that they were messing around doing nothing and having a bit of fun.

Outside looking in, it can often seem like agile teams are “messin’ and a gommin”.  Especially if you aren’t in the value stream yourself.  So make sure you pay close attention, go to demos, etc. before passing judgement.   Here is a partial list of things that I expect a Program Team to do in a larger agile system.

A Program Team (or product owner team) is the second tier in larger agile systems. The following are a set of thoughts for new agile Program Teams that I stand up. I’ll start with a restating of why they exist and move into what these teams do day-to-day.

Making Agile work… a refresher

To make agile work you need:

  • Clarity in your backlog
  • A team that stays together
  • A cross-functional team that can produce working tested software
Two Key Areas

During the day-to-day work, a Program Team has two areas of focus. They create a clear backlog that teams can consume by creating an actionable release plan. They deliver on a release plan commitment.


During Delivery a Program Team collectively fills the traditional product owner role by:

  • Prioritizing work, making tradeoffs, and reducing risk early
  • Providing architectural guidance to ensure longer roadmap views are considered and to guard against overbuilding by building the simplest possible thing
  • Giving clear test guidance to simplify automation strategies and balance manual and automation testing
  • Providing visual guidance when, and only if, needed for clarity to delivery teams
  • Breaking down larger stories to reduce risk early in the release

The Program Team does this in order to hold themselves accountable for the quality of the product, the rate of delivery, and the long-term survivability of the product.

Release Planning

During planning a Program Team provides clarity by:

  • Making an actionable backlog that can be completed by the agile teams
  • Performing Rapid Feature identification and story mapping
  • Defining features and stories “clear enough” as the way to maximize throughput of the Program while maintaining predictability

During Planning a Program Team provides a credible plan by:

  • Performing breakdown not to the scenario level, but rather to a level that can fit into a sprint. Remember that during Delivery program team will elaborate on big stories to reduce risk
  • Not planning on dependent story points. The only dependencies accepted should be those where the dependency has a track record of consistently delivering on commitments. Any other acceptance really isn’t credible
  • Providing architectural guidance to ensure longer roadmap views are considered

Planning and Delivery, that’s what Program Teams focus on every day. Their retrospectives should focus on these areas. Keep in mind that this is a beginning and not an end goal. While this is a rational place to start, most will have problems getting here because they can’t form teams, can’t define an actionable, clear release plan, or they don’t have the ability to produce product with a cross-functional team.  If you are ready to do those things great, if not you just might be “Messin’ an a Gommin” so get help.

The post Is Your Program Team Just a Messin’ an a Gommin’? appeared first on LeadingAgile.

Categories: Blogs

News update 2015/05 – 25% discount off Leading Self-Organising Teams course - Peter Hundermark - Tue, 05/19/2015 - 13:37

Joanne Perold has written a very interesting piece on why she feels dysfunction in an organisation is often attributed to competing KPIs. The current incarnation of KPIs in most organisations is reinforcing the dysfunction and not solving the right problems. Instead we need to ask ourselves, “What is the problem we are trying to solve?”

This month’s blog post, ‘Are incorrectly applied KPIs the root of all evil‘  is well worth the read!

Simple Agile Leadership ModelLeading Self-Organising Teams course

We are offering an early-bird special on our upcoming Leading Self-Organising Teams course. Book before the 31st May 2015 and receive a 25% discount!

Learn and practice leadership skills based on a state-of-the-art model for Lean/Agile leadership. Develop mastery in an essential set of people-related skills that complement the technical skills you already possess. Take charge of your own leadership development!

Join us on the 07-08 July 2015 in Sandton to broaden your leadership knowledge. Click HERE for more info.

Upcoming Courses

Certified Scrum Product Owner (JHB)
02-03 June 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Master (JHB)
23-24 June 2015
FNB Conference & Learning Centre, Sandton

Certified Scrum Product Owner (CPT)
29-30 June 2015
Steenberg Hotel, Cape Town

Leading Self-Organising Teams (JHB)
07-08 July 2015
FNB Conference & Learning Centre, Sandton

Course Schedule and Book Online

The post News update 2015/05 – 25% discount off Leading Self-Organising Teams course appeared first on ScrumSense.

Categories: Blogs

RSpec and the Death of Should

I love writing expectations like the following:

account.balance.should be_zero

It was one of the reasons I first fell in love with RSpec and had a reason to move from dabbling in Ruby to diving in. This was hard and clear evidence that Ruby crushed testing syntax of Java in a way it could never compete with. Just a beautiful DSL with a single little word ‘should’.

Expect has come along to replace and it accomplishes the same thing with a bit more syntax and parens:

expect(account.balance).to be_zero

It reads well, but I still like ‘should’ better and I’m not as upset as some about object purity and polluting objects with an extra method. Our development team concluded as much for the last few years. We’d put a quick vote up every 6 months or so to keep should() or bite the bullet and move onto expect. Should always won, but over time the objections became more mild and newer team members had gotten adjusted to expect elsewhere. When the vote came up again a few weeks back, we finally voted to default to the new expect syntax.

My vote had changed from preferring should to being neutral on it. Over time most of that came from working on newer Ruby open source projects and following the new expect syntax when adding tests in a pull request. Idioms and styles evolve and I’d seen enough adoption to justify retiring my old friend should(). The small benefit has been with Jasmine with its very similar expects now doesn’t lead to accidentally writing a should() in a Jasmine spec. I still miss should(), but having everyone use the same assertion approach is better for the group.

Categories: Blogs

Major SAFe LSE Update with Big Implications

Hello Folks,

As you probably know, I’ve moved most of my blogging activity to the Scaled Agile Framework Blog. For a major update on SAFe LSE and the future of SAFe, check out this post.

I’ll be maintaining this blog for just a while longer. As the SAFe blog is dedicated to SAFe content, I plan to start my personal blogging again on my website at I’ll be describing a few other topics I’ve been researching lately, and some great books and background reading, all of which is too early for SAFe.


Categories: Blogs

How Agile Helped a Business Analyst

TV Agile - Mon, 05/18/2015 - 17:23
As companies introduce agile practices, the business analyst (BA) role is often left by the wayside. The BA title doesn’t exist in Scrum and other agile implementations, leaving many BAs wondering where—or if—they fit in. But fear not! The skills of a good BA are even more valuable in an agile environment. Diane Zajac-Woodie tells […]
Categories: Blogs

Is Agile Working for Your Project?

Johanna Rothman - Mon, 05/18/2015 - 15:59

My column is up on It’s called Is Agile Working for Your Project?

I hope you enjoy it.

Categories: Blogs

Organisier dich oder geh!

Scrum 4 You - Mon, 05/18/2015 - 12:05

Als ich vor ein paar Wochen auf Fast Company den Artikel über den Versuch von Zappos-Gründer Tony Hsieh las, seine Mitarbeiterinnen und Mitarbeiter per Dekret zur Selbstorganisation zu zwingen, musste ich schmunzeln. In den Zeilen seiner E-Mail konnte ich förmlich spüren, wie genervt und hilflos er ist. Psychologen nennen das wohl „Übertragung“: Ich bezog mich auf ihn, ich konnte mich in ihn hineinversetzen, weil ich vor drei, vier Jahren genau so hilflos war. Ich wollte unser Unternehmen, Boris Gloger Consulting, zu einem Ort der Selbstorganisation machen, den Kolleginnen und Kollegen die Verantwortung für unser Unternehmen und so viel Entscheidungsspielraum wie nur irgend möglich geben. Aber sie nahmen das Angebot nicht an. Die Menschen in unserem Unternehmen wollten Anleitung, ließen sich von vermeintlichen Chefs kommandieren und die Hierarchie schlug ständig zu. Aber ich will hier gar nicht von uns sprechen, sondern nur deutlich machen, dass ich die Lage von Tony Hsieh zu verstehen glaube.

Neue Organisation nach altem Muster

Schmunzeln musste ich, weil Hsieh meiner Auffassung nach in seiner Hilflosigkeit genau den Fehler macht, den er bekämpfen will: Er schlägt als CEO nach Chefmanier zu und fordert die Veränderung ein. Übersetzt sagt er eigentlich: „Wer nicht mitmachen will, darf gerne gehen!“ Das erzeugt keine Sicherheit oder das Gefühl: „Mein Chef versteht mich und ist für mich da.“ Es erzeugt nur noch mehr Druck. Druck, weil ich als einzelner Mitarbeiter – so zeigt es mir mein Boss Hsieh gerade – offenbar nicht dazugehöre, wenn ich nicht folge. Gleichzeitig ist Hsiehs Impuls verständlich, er legt damit aber auch offen, dass er selbst die neue Klaviatur der Führung im Kontext der Selbstorganisation noch nicht perfekt beherrscht. Also lebt er in seiner Firma die alte, traditionelle Struktur. Das soll kein Vorwurf sein, sondern eine Analyse: Der Fisch beginnt am Kopf zu stinken. Die Veränderung zu einer anderen Organisation fängt immer und ausschließlich bei der Führung an. Klar gibt es Grassroot-Bewegungen und die agile Community hat so begonnen, aber in einer Organisation braucht es den so oft zitierten Buy-in der Top-Führung. Dieser Buy-in ist aber nur ein Anfang. Wie es funktionieren kann, lernt man am Beispiel von Bodo Janssen, CEO und Eigentümer der Hotelkette Upstalsboom.

Im Video “Wertschöpfung durch Wertschätzung” zeigt er wunderbar, dass die Veränderung seiner Organisation mit ihm selbst angefangen hat. Das Ändern seiner Haltung war entscheidend. Sicher, er als CEO musste einen Weg finden, um seine Mitarbeiter mitzunehmen, aber das gelang nur durch sein aktives Engagement. Sein ständiges Arbeiten an seinen Ideen und sein ständiges Kommunizieren darüber veränderte das Unternehmen innerhalb von zwei Jahren. Das bestätigt auch die Forschung von Frederick Laloux. Obwohl einige sicher mit Recht sagen, dass sein Buch “Reinventing Organizations” keine großartigen neuen Erkenntnisse enthält, macht Laloux sehr deutlich, dass die Veränderung mit der Haltung des CEO steht und fällt und es dann beinahe egal ist, wie der Weg zur Teal-Organisation aussieht. Ich erwähne Laloux an dieser Stelle, weil er diesen Aspekt in dem von Hsieh zitierten Skype-Call vergessen zu haben scheint. Denn er hätte Hsieh vielleicht raten sollen, an seiner eigenen Haltung zu arbeiten anstatt einen Mechanismus einzuführen und die Nichteinverstandenen gehen zu lassen.

Achtung: Es liegt mir fern, Hsieh oder Laloux zu kritisieren, denn ich kann das absolut nachvollziehen. Ich möchte nur etwas deutlich machen: Selbstorganisation braucht einen Rahmen und einen Menschen, der diesen Rahmen – Nonaka nennt das Ba (Raum) – aufspannt. Dieser Mensch muss diesen Raum so erfüllen, dass die Kollegen darin beginnen können, sich selbst zu organisieren und Entscheidungen selbst zu fällen. Diesen Raum zu erzeugen und auszuhalten, dass es nicht sofort so funktioniert wie man es sich als Chef wünscht, immer wieder aufs Neue die eigenen Verhaltensweisen zu hinterfragen und zu einer neuen Form von Führung und des Arbeitens zu kommen – das ist ein langer Weg. Ich weiß aber, dass sich dieser Weg auszahlt.

Categories: Blogs

Retrospective Prime Directive in nine languages

Ben Linders - Mon, 05/18/2015 - 09:21
The retrospective prime directive is a sentence that is used by facilitators to establish safety in a retrospective meeting. Safety is crucial if you want people to speak up and be open, which is an important precondition to reflect and learn which is what agile retrospectives are all about. Since our book is being translated into many languages we now have translations of this unique and important statement. Continue reading →
Categories: Blogs

Are incorrectly applied KPIs the root of all evil? - Peter Hundermark - Mon, 05/18/2015 - 08:46

We have all heard it before “show me how you measure me and I show you how I behave” (I think the original quote is from Eliyahu M. Goldratt). It’s been quoted and requoted so many times it’s hard to tell, and it’s true.

I see the effects of this issue every day, which leads me to ask the question…

Are incorrectly applied KPIs the root of all evil?

I see dysfunction in organisations all the time, as do many people I am sure. I often ask the question, “is that part of your KPI’s?” The resulting answer “yes” just reinforces this more often than not.

I was speaking to the product owner of an interesting project. He was complaining about the number of bugs logged that were essentially duplicates. I asked how the testers were measured, and he said “bug counts.”
It feels to me that KPIs are trying to solve multiple problems, and that we have lost sight of the goal of encouraging a behaviour of self critical improvement, instead of informing a behaviour of compliance.

Trust / Performance

The first problem I see, is that people don’t trust each other to do a good job or rather that organisations don’t trust the awesome people they hire. We create performance bonuses and remuneration around objectives, because we believe that people need external motivators to get work done. There is an underlying belief system that says people need carrots and sticks in order to be their best. I believe that if you give people a clear common goal, and the resources to achieve that goal, remove the impediments, then they will try their best to achieve the goal, regardless of bonuses.

Instead we link specific outcomes to people’s value.

By doing this we are essentially linking their value and success in the organisation to these KPIs. People want to feel like they are adding value. The resulting behaviour is that they will do everything in their power to achieve the stated KPI outcome. This, in and of itself is not a bad thing. The problem arises when this goal is at odds with another person’s goal (or KPI) or with the overall business strategy. How we set these up is part of the problem.
Creating an environment of visibility and openness is a far better way to encourage trust and performance. People will more often than not do their best to be committed to a team and to deliver on what they have promised. No one wants to be the person that let the team down. A collaborative team environment that encourages honesty and trust is far better than a group of people with conflicting goals. Rating people individually while trying to foster a team culture will likely create dysfunction, competition and unhealthy conflict.

Lack of direction

Closely linked to the lack of trust is a lack of direction. What I see is that companies have not clearly defined their strategic objectives and created a clear common goal for the people in their organisation to move towards. Setting up Global KPIs as an indicator of progress or as an overall goal, makes more sense to me than individual competing KPIs.

An example of this I have seen is that, we have 100+ projects that need to be delivered and no clear alignment about what we are trying to achieve with these projects and which ones are most valuable to the organisation. Project Managers are rated on getting Project X in on time and this is linked to their performance bonus, whilst teams need to deliver on all 100 which is frequently an unachievable goal. Teams are forced to make priority decisions on a daily basis about what is the most important thing. They make these decisions while lacking valuable context and information.

How the Project Manager or Project Sponsor is rated, drives her behaviour. She will do whatever it takes to make sure that Project X is delivered on time. If Project X is not the best for the business, that is not her focus. If Project X gets executed poorly and shipped with loads of bugs, that is not her primary concern. The KPI was to get the project done on time and that will inform her behaviour, her goal is to add value and meet her targets.

By setting her KPI and linking it to a monetary incentive, we are basing her value and reward on a single goal over which she has no direct control. The resulting behaviour is to conceal the truth about progress, to compete with other project managers or project sponsors, and to not always share valuable information, especially if it does not serve her end goal. This has large impacts on the global strategy that most people are unaware of.
Setting a clear, common goal and ensuring that people have the necessary resources (yes, I mean actual resources) to achieve that goal is far better than creating competing KPIs. Setting goals that align to business strategy across all areas will help teams and individuals make better decisions about what to do next. Giving those individuals enough information about where we are going and why we need to get there will encourage them to work smarter and with more collaboration. So it seems that this starts with better prioritisation and alignment at all levels (Brad Swanson has a great post on this).

Creating Competition

Some organisations believe that creating competition between divisions and departments is healthy and that it helps the business to grow. I have seen instances where this has created a large amount of dysfunction. What often happens is that each division has KPIs that compete with other divisions, except of course the service departments, like “IT”, who often have to service all of these divisions, and generally at the same time.

Now you have different divisions vying for “resources” (if you’ll excuse the term) and the result of this is that each team member is 20% allocated to this and 30% allocated to that and 45% allocated to the next thing, and 5% allocated to learning. These individuals spend their days context-switching between competing stakeholder requests or in project update meetings. Likely less than 50% of their work day is spent doing the making that everyone is hoping for. As a result, each person is actually only able to contribute minimal time to the project. The transaction costs are so high that it ends up taking years for a team to ship anything.

Having alignment is better than competition, especially when there are only one or two teams that can deliver to the business. If the Project Managers and Product Owners are aligned in their goals, then it will be much easier to ship the most important things, because it will be easier to get focus for the teams on one specific thing. Setting people against each other will only result in more context switching and higher transaction costs. The knock-on effect is that everything takes longer to get done.

The current incarnation of KPIs is NOT, I believe, effectively solving the problems we want to solve. We pit people against each other and encourage them to compete; for time, for resources, and for people. We create environments where people are fighting to get their needs met and not for the overall needs of the business. In an environment like that, it is the loudest person or bully that will win every time, and that doesn’t always make for the best business decisions.

According to Gerald Weinberg, it’s useful to apply the rule of threes when thinking about any problem. Gerald suggests that if we can’t come up with at least three ways to solve the problem, then we don’t understand the problem effectively.

Perhaps in the case of KPIs we have lost sight of the problem we were trying to solve.

Some organisational KPIs add value and direction. At agile42 we use KPIs to help create focus, direction and self critical improvement. The current incarnation of KPIs in most organisations is reinforcing the dysfunction and not solving the right problems. We apply KPIs as a solution to create performance goals because that is the way we have always done it. To quote Gerry again “Things are the way they are because they got that way”. Maybe it is time to go back to the beginning, and ask ourselves,

“What is the problem we are trying to solve?”

If we did that, we could find better ways of solving these problems without the resulting dysfunction.


The post Are incorrectly applied KPIs the root of all evil? appeared first on ScrumSense.

Categories: Blogs

I Prefer This Over That

A couple weeks ago I tweeted:

I prefer: - Recovery over Perfection - Predictability over Commitment - Safety Nets over Change Control - Collaboration over Handoffs

— ElisabethHendrickson (@testobsessed) May 6, 2015

Apparently it resonated. I think that’s more retweets than anything else original I’ve said on Twitter in my seven years on the platform. (SEVEN years? Holy snack-sized sound bytes! But I digress.)

@jonathandart said, “I would love to read a fleshed out version of that tweet.”

OK, here you go.

First, a little background. Since I worked on Cloud Foundry at Pivotal for a couple years, I’ve been living the DevOps life. My days were filled with zero-downtime deployments, monitoring, configuration as code, and a deep antipathy for snowflakes. We honed our practices around deployment checklists, incident response, and no-blame post mortems.

It is within that context that I came to appreciate these four simple statements.

Recovery over Perfection

Something will go wrong. Software might behave differently with real production data or traffic than you could possibly have imagined. AWS could have an outage. Humans, being fallible, might publish secret credentials in public places. A new security vulnerability may come to light (oh hai, Heartbleed).

If we aim for perfection, we’ll be too afraid to deploy. We’ll delay deploying while we attempt to test all the things (and fail anyway because ‘all the things’ is an infinite set). Lowering the frequency with which we deploy in order to attempt perfection will ironically increase the odds of failure: we’ll have fewer turns of the crank and thus fewer opportunities to learn, so we’ll be even farther from perfect.

Perfect is indeed the enemy of good. Striving for perfection creates brittle systems.

So rather than strive for perfection, I prefer to have a Plan B. What happens if the deployment fails? Make sure we can roll back. What happens if the software exhibits bad behavior? Make sure we can update it quickly.

Predictability over Commitment

Surely you have seen at least one case where estimates were interpreted as a commitment, and a team was then pressured to deliver a fixed scope in fixed time.

Some even think such commitments light a fire under the team. They give everyone something to strive for.

It’s a trap.

Any interesting, innovative, and even slightly complex development effort will encounter unforeseen obstacles. Surprises will crop up that affect our ability to deliver. If those surprises threaten our ability to meet our commitments, we have to make painful tradeoffs: Do we live up to our commitment and sacrifice something else, like quality? Or do we break our commitment? The very notion of commitment means we probably take the tradeoff. We made a commitment, after all. Broken commitments are a sign of failure.

Commitment thus trumps sustainability. It leads to mounting technical debt. Some number of years later find themselves constantly firefighting and unable to make any progress.

The real problem with commitments is that they suggest that achieving a given goal is more important than positioning ourselves for ongoing success. It is not enough to deliver on this one thing. With each delivery, we need to improve our position to deliver in the future.

So rather than committing in the face of the unknown, I prefer to use historical information and systems that create visibility to predict outcomes. That means having a backlog that represents a single stream of work, and using velocity to enable us to predict when a given story will land. When we’re surprised by the need for additional work, we put that work in the backlog and see the implications. If we don’t like the result, we make an explicit decision to tradeoff scope and time instead of cutting corners to make a commitment.

Aiming for predictability instead of commitment allows us to adapt when we discover that our assumptions were not realistic. There is no failure, there is only learning.

Safety Nets over Change Control

If you want to prevent a given set of changes from breaking your system, you can either put in place practices to tightly control the nature of the changes, or you can make it safer to change things.

Controlling the changes typically means having mechanisms to accept or reject proposed changes: change control boards, review cycles, quality gates.

Such systems may be intended to mitigate risk, but they do so by making change more expensive. The people making changes have to navigate through the labyrinth of these control systems to deliver their work. More expensive change means less change means less risk. Unless the real risk to your business is a slogging pace of innovation in a rapidly changing market.

Thus rather than building up control systems that prevent change, I’d rather find ways to make change safe. One way is to ensure recoverability. Recovery over perfection, after all.

Fast feedback cycles make change safe too. So instead of a review board, I’d rather have CI to tell us when the system is violating expectations. And instead of a laborious code review process, I’d rather have a pair work with me in real time.

If you want to keep the status quo, change control is fine. But if you want to go fast, find ways to make change cheap and safe.

Collaboration over Handoffs

In traditional processes there are typically a variety of points where one group hands off work to another. Developers hand off to other developers, to QA for test, to Release Engineering to deliver, or to Ops to deploy. Such handoffs typically involve checklists and documentation.

But the written word cannot convey the richness of a conversation. Things will be missed. And then there will be a back and forth.

“You didn’t document foo.”
“Yes, we did. See section 3.5.1.”
“I read that. It doesn’t give me the information I need.”

The next thing you know it’s been 3 weeks and the project is stalled.

We imagine a proper handoff to be an efficient use of everyone’s time, but they’re risky. Too much can go wrong, and when it does progress stops.

Instead of throwing a set of deliverables at the next team down the line, bring people together. Embed testers in the development team. Have members of the development team rotate through Ops to help with deployment and operation for a period of time. It actually takes less time to work together than it does to create sufficient documentation to achieve a perfect handoff.

True Responsiveness over the Illusion of Control

Ultimately all these statements are about creating responsive systems.

When we design processes that attempt to corral reality into a neat little box, we set ourselves up for failure. Such systems are brittle. We may feel in control, but it’s an illusion. The real world is not constrained by our imagined boundaries. There are surprises just around the corner.

We can’t control the surprises. But we can be ready for them.

Categories: Blogs