Skip to content

Feed aggregator

Die Sache mit der Freiwilligkeit

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

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

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

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

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

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

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

Related posts:

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

Categories: Blogs

VersionOne and CA Technologies Partner on Agile Project Management

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

Agile Scrum Master, Square One Resources , Norwich, UK

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

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

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

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

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

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

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

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

Categories: Companies

Project Goals using Effects or Feature List

Dear Junior
There has always been two ways to set goals for a project, either you can define the goal of the project to be a list of feature to be implemented, or you can define some effect you want to see. Both of these have been around for a long time, and effect goals have always been superior. 
Setting goals as a feature list is actually pretty simple - you simply state "these features I want to see before we consider this project closed". An online bookstore could say that it wants search-by-author, categories, and others-have-bought recommendations.
Following up during the project will simply consists of checking how far on this check-list the development team has progressed.
Effect goals are a little bit harder to set. You have to figure out and express why you want to have work done, what purpose it fulfils, in what way it makes your world better. Said bookstore must then express that it hopes people each customer will by 0.35 more books per checkout on average, or that it will increase its customer base with 10 000 new customers.
Following up during the project using this approach will consist of measuring the business parameters and watch the values change. A tricky part is that the full impact of the project might not be seen until the development work is "finished" (whatever that means), or even not until some time thereafter.
To put things a little bit into context, it is not the "bookstore" that starts a project - it is always a person involved, in this case probably the product owner of the online store. And, this is the person who should explain why she is about to spend a lot of peoples' time and a lot of the organisation's money.
I have always found that measuring success on effect, or impact, is the more intellectually honourable approach. To be frank, setting goals as a feature list does really say "this much work I want to have done" or rephrased "this much money I want to spend", nothing about what value it should result in. And if you want to have a group of people to work to bring your ideas to come real, the least you can do is to explain to them the value you think it will bring. Setting goals on effect is really about that - bringing purpose to the work.

Now, these two ways of setting goals and measuring success have a fundamental impact on how to manage projects in an agile manner, but that will have to wait until a later letter.
Yours
   Dan
Categories: Blogs

Function references in Swift and retain cycles

Xebia Blog - Thu, 10/09/2014 - 15:49

The Swift programming language comes with some nice features. One of those features are closures, which are similar to blocks in objective-c. As mentioned in the Apple guides, functions are special types of closures and they too can be passed around to other functions and set as property values. In this post I will go through some sample uses and especially explain the dangers of retain cycles that you can quickly run into when retaining function pointers.

Let's first have a look at a fairly simple objective-c sample before we write something similar in Swift.

Objective-c

We will create a button that executes a block statement when tapped.

In the header file we define a property for the block:

@interface BlockButton : UIButton

@property (nonatomic, strong) void (^action)();

@end

Keep in mind that this is a strong reference and the block and references in the block will be retained.

And then the implementation will execute the block when tapped:

#import "BlockButton.h"

@implementation BlockButton

-(void)setAction:(void (^)())action
{
    _action = action;
    [self addTarget:self action:@selector(performAction) forControlEvents:UIControlEventTouchUpInside];
}

-(void)performAction {
    self.action();
}

@end

We can now use this button in one of our view controllers as following:

self.button.action = ^{
    NSLog(@"Button Tapped");
};

We will now see the message "Button Tapped" logged to the console each time we tap the button. And since we don't reference self within our block, we won't get into trouble with retain cycles.

In many cases however it's likely that you will reference self because you might want to call a function that you also need to call from other places. Let's look as such an example:

-(void)viewDidLoad {
    self.button.action = ^{
        [self buttonTapped];
    };
}

-(void)buttonTapped {
    NSLog(@"Button Tapped");
}

Because our view controller (or it's view) retains our button, and the button retains the block, we're creating a retain cycle here because the block will create a strong reference to self. That means that our view controller will never be deallocated and we'll have a memory leak.

This can easily be solved by using a weak reference to self:

__weak typeof(self) weakSelf = self;
self.button.action = ^{
    [weakSelf buttonTapped];
};

Nothing new so far, so let's continue with creating something similar in Swift.

Swift

In Swift we can create a similar Button that executes a closure instead of a block:

class ClosureButton: UIButton {

    var action: (() -> ())? {
        didSet {
            addTarget(self, action: "callClosure", forControlEvents: .TouchUpInside)
        }
    }

    func callClosure() {
        if let action = action {
            action()
        }
    }
}

It doing the same as the objective-c version (and in fact you could use it from objective-c with the same block as before). We can assign it an action from our view controller as following:

button.action = {
    println("Button Tapped")
}

Since this closure doesn't capture self, we won't be running into problems with retain cycles here.

As mentioned earlier, functions are just a special type of closures. Which is pretty nice, because it lets us reference functions immediately like this:

override func viewDidLoad() {
    button.action = buttonTapped
}

func buttonTapped() {
    println("Button Tapped")
}

Nice and easy syntax and good for functional programming. If only it wouldn't give us problems. Without it being immediately obvious, the above sample does create a retain cycle. Why? We're not referencing self anywhere? Or are we? The problem is that the buttonTapped function is part of our view controller instance. So when the button.action references to that function, it creates a strong reference to the view controller as well. In this case we could fix it by making buttonTapped a class function. But since in most cases you'll want to do something with self in such a function, for example accessing variables, this is not an option.

The only thing we can do to fix this is to make sure that the button won't get a strong reference to the view controller. Just like in our last objective-c sample, we need to create a weak reference to self. Unfortunately there is no easy way to simply get a weak reference to our function. So we need a work around here.

Work around 1: wrapping in closure

We can create a weak reference by wrapping the function in a closure:

button.action = { [weak self] in
    self!.buttonTapped()
}

Here we first create a weak reference of self. And in Swift, weak references are always optional. That means self within this closure is now an optional and need to unwrap it first, which is what the exclamation mark is for. Since we know this code cannot be called when self is deallocated we can safely use the ! instead of ?.

A lot less elegant than immediately referencing our function immediately.

In theory, using an unowned reference to self should also work as following:

button.action = { [unowned self] in
    self.buttonTapped()
}

Unfortunately (for reasons unknown to me) this crashes with a EXC_BAD_ACCESS upon deallocation of the ClosureButton. Probably a bug.

Work around 2: method pointer function

Thanks to a question on StackOverflow about this same problem and an answer provided by Rob Napier, there is a way to make the code a bit more elegant again. We can define a function that does the wrapping in a closure for us:

func methodPointer<T: AnyObject>(obj: T, method: (T) -> () -> Void) -> (() -> Void) {
    return { [weak obj] in
        method(obj!)()
    }
}

Now we can get a weak reference to our function a bit easier.

button.action = methodPointer(self, ViewController.buttonTapped)

The reason this works is because you can get a reference to any instance function by calling it as a class function with the instance (in this case self) as argument. For example, the following all does the same thing:

// normal call
self.buttonTapped()

// get reference through class
let myFunction = MyViewController.buttonTapped(self)
myFunction()

// directly through class
MyViewController.buttonTapped(self)()

However, the downside of this is that it only works with functions that take no arguments and return Void. i.e. methods with a () -> () signature, like our buttonTapped.

For each signature we would have to create a separate function. For example for a function that takes a String parameter and returns an Int:

func methodPointer<T: AnyObject>(obj: T, method: (T) -> (String) -> Int) -> ((String) -> Int) {
    return { [weak obj] string in
        method(obj!)(string)
    }
}

We can then use it the same way:

func someFunction() {
    let myFunction = methodPointer(self, MyViewController.stringToInt)
    let myInt = myFunction("123")
}

func stringToInt(string: String) -> Int {
    return string.toInt()
}
Retain cycles within a single class instance

Retain cycles do not only happen when strong references are made between two instances of a class. It's also possible, and probably less obvious, to create a strong reference within the same instance. Let look an an example:

var print: ((String) -> ())?

override func viewDidLoad() {
    print = printToConsole
}

func printToConsole(message: String) {
    println(message)
}

Here we do pretty much the same as in our button examples. We define an optional closure variable and then assign a function reference to it. This creates a strong reference from the print variable to self and thus creating a retain cycle. We need to solve it by using the same tricks we used earlier.

Another example is when we define a lazy variable. Since lazy variables are assigned after initialisation, they are allowed to reference self directly. That means we can set them to a function reference as following:

lazy var print: ((String) -> ()) = self.printToConsole

Of course this also creates a retain cycle.

Conclusion

To avoid creating retain cycles in Swift you should always remember that a reference to an instance function means that you're referencing the instance as well. And thus when assigning to a variable, you're creating a strong reference. Always make sure to wrap such references in a closure with a weak reference to the instance or make sure to manually set the variables to nil once you're done with them.

Unfortunately Swift does not support weak closure variables, which is something that would solve the problem. Hopefully they will support it in the future or come up with a way to create a weak reference to a function much like we can use [weak self] now in closures.

Categories: Companies

Small Internal Releases Lead to Happy Customers

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

That is what I invite you to consider.

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

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

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

Categories: Blogs

Retrospective Plan from a new ScrumMaster

Growing Agile - Thu, 10/09/2014 - 14:00

It’s always great as a coach when you see someone take what you have taught them and really embrace it. Rushida Hendricks is a new Scrum Master at Liberty Health. This is the retrospective plan she created for her team’s fourth retrospective.

Sprint 4 Retrospective 791x1024 Retrospective Plan from a new ScrumMaster

What I love about this plan is that the bulk of the time is spent in Generate Insights and Decide What to Do, the most important parts of the retro.

She has allowed 20 minutes of buffer time in a 90 minute retro, which means no section needs to be rushed if an interesting discussion is happening.

I love the checkin since it focussed the retro on the team and their needs. A common mistake of new teams is to think the retrospective is for the Scrum Master.

Generate Insights follows on nicely from the previous activity, using the output from one activity as the input for the next. Again this is something that takes experience to get right.

There is a nice mix of individual and group activities to ensure that everyone is participating. Rushida is also using technique of having people write down there thoughts (e.g. in the close) before they share them, which works well for more introverted team members.

You can download the full plan here: Sprint 4 Retrospective Full

Categories: Companies

How to make wall-related decisions in Distributed Agile projects

Agile World - Venkatesh Krishnamurthy - Thu, 10/09/2014 - 13:41

I authored the following article for Cutter which got published today. So, it is hot out of the press.

The subject that every distributed Agile team is questioning is the topic of setting up visual walls. Conflicts arise when purists argue in support of setting up visual boards across all locations, while the distributed teams consider it an inconvenience.

Many companies don't realize the importance of making the right decisions related to visual walls. Typically, wall setup is left to the ScrumMaster. These companies don't realize that this "single-handed" decision could result in loss of productivity, increased stress levels, and thousands of dollars in loss due to waste.

====  I am recommending a principle based approach for deciding if the information needs to be displayed on Physical wall or Digital wall. ===============

Wrong wall decisions or forcing wall decisions on a team could end up with stale walls and thousands of hours could be wasted in maintaining these walls. Be sure your organization considers the core principles during its exploration of walls.

Since this article is available only for Cutter Members, kindly continue reading rest of article on Cutter

image

Categories: Blogs

The Life of a Product Owner Proxy

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

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

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

A Team Named “Sue”

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

Johnny_Cash_(1964)

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

-Johnny Cash, A Boy Named Sue

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

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

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

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

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

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

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

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

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

So what are your rules for naming teams?

 


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

Persönliches geht vor Fachlichem

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

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

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

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

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

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

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

Related posts:

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

Categories: Blogs

My next Boulder SPC Class Oct 21-24, 2014

Hi Folks,

I’ll be teaching my next SPC certification in Boulder October 21-24. This is the second US  course I’ll be teaching based on SAFe 3.0 and, the first from a recent update to Leading SAFe 8.1. This should be a fun course; at least I’m excited about teaching from the new baseline! It will probably sell out, but there are a few seats left add of today. You can register here.

Hope to see you there.

–Dean

Categories: Blogs

Demystifying the Language of Commitment

BigVisible Solutions :: An Agile Company - Wed, 10/08/2014 - 21:22

Making and keeping commitments is often a controversial topic within organizations. In my experience commitment-making is more challenging than it might seem on the surface and a lot of bad feelings and unfulfilled expectations arise because people lack some of the basic tools in the language of commitment. A commitment exists in language. “If you […]

The post Demystifying the Language of Commitment appeared first on BigVisible Solutions.

Categories: Companies

New Notifications Option

Agile Zen - Wed, 10/08/2014 - 19:59

The notification system now supports ignoring cards that are not assigned to you. Head to your settings page (top right when logged in) and click on the Notifications tab. Check the box below to only receive notifications for your cards:

Screen Shot 2014-10-07 at 4.27.37 PM

Jayme

Categories: Companies

SAFe Program Consultant Training – Review

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

I want to give some perspective on SAFe and the training that I have been attending these last few days.  The training itself is not actually over, but we are very near the end.  Just one day left, but it is dominated by the SPC exam and open Q&A on advanced topics.  In other words, we have covered the essence of SAFe.

Ad Hoc, Pragmatic and Transformative

When I think about organizations or departments trying to become Agile enterprises, I generally categorize those efforts into three approaches.

The “Ad Hoc” approach is typified by a grassroots movement or an executive decreeing “be Agile” with no one really knowing what that means.  A lot of organizations have some teams in this condition – they try Scrum, try some other Agile-ish things, and have modest successes.  When the enterprise is large enough, these ad hoc approaches reach a natural limit of effectiveness before they become severely blocked by organizational considerations.  Then, the leadership of the organization must turn to systematic approaches to becoming an Agile enterprise: the Pragmatic approaches or the Transformative approaches.

The “Pragmatic” approach acknowledges the difficulty of change, particularly for those in middle management.  There is still a deep acknowledgement of the Agile values and principles, but the pragmatic part is to say that the organization will take quite a long time to adopt those values and principles end-to-end, top-to-bottom.  These pragmatic approaches typically have low risk and good results.  SAFe (Scaled Agile Framework) falls into this category along with DAD (Disciplined Agile Delivery) and possibly others that I’m not aware of.

The “Transformative” approach acknowledges the deep nature of Agile as a cultural transformation that can be done quickly when there is urgency to do so.  There is still an acknowledgement that Agile can be difficult for many people as it requires a change in mindset and deep habitual behaviours.  These approaches are transformative because they require all protagonists in the enterprise to be open to this deep and fast change to a new culture.  LeSS (Large Scale Scrum) and RAP (Real Agility Program) are both systematic transformative frameworks.

SAFe, as a pragmatic approach, has a number of excellent features that will help an organization accomplish its business and technology goals.

Scaled Agile Framework – Practical, Pragmatic, and Still Pure Agile

One big concern I had about SAFe, based on other people’s comments, was that it somehow was compromising the values of the Agile Manifesto.  I want to say clearly and unequivocally that SAFe is most certainly true to Agile.  This fact was demonstrated multiple times and in multiple ways throughout the training:

  • Explicit statements that SAFe is based on the Agile Manifesto.  At one point, Dean Leffingwell emphatically repeated several times that “we live or die by the Agile Manifesto!”
  • Clear examples of SAFe implementations making choices based on the values and principles of the Agile Manifesto.  It was common to talk about situations where SAFe ScrumXP teams, Agile Release Trains and the people involved made decisions based on “individuals and interactions”.
  • Practices and guidelines that implement the values and principles of Agile are pervasive throughout SAFe.  The Inspect and Adapt meeting, Program Increments, daily business collaboration with SAFe ScrumXP teams, customer collaboration through various forms of backlogs, reviews and demos, focus on simplicity and technical excellence with Architectural Runway, Test-Driven Development and other Agile engineering practices.
  • The instructors (not just Mr. Leffingwell) often mentioned their own philosophy of being flexible with the SAFe “framework” by making appropriate context-specific changes to the details.
  • Even participants in the class who have already started using SAFe in their organizations shared stories that clearly indicated a strong emphasis on the values and principles of Agility.

At the same time, SAFe manages to create a relatively simple interface with a traditional management organization.  This is critical and what makes it really effective as a pragmatic approach to enterprise agility.  For example, at the Agile Release Train level, there are nine roles identified (e.g. System Architect, Product Management, Business Owners).  The explicit acknowledgement and identification of these roles and how they interact with the SAFe ScrumXP teams through meetings, artifacts and other processes and tools helps an organization to map Agility at the staff level to traditional concepts at the middle-management level.  This interfacing is also pervasive throughout the SAFe framework and occurs at all levels of effort from individual team members up to high level business leaders.

Some people have grumbled about the complicated diagram as “proof” that SAFe can’t be Agile.  But a different way of looking at the diagram is that it is comfort for management.  I really appreciate this.  Back in 2004 and 2005 when I was consulting at Capital One on their first enterprise attempt at Agile, one of the coaches I was working with shared a story with me about the importance of comfort.  The project manager for an important project was very nervous that there was no Gantt chart in Agile.  At a personal level, she needed the comfort of having a Gantt chart to track the work of the team.  The coach for this project told the project manager “please, make your Gantt chart – just make sure that you let the team organize themselves without being disturbed to help you with the Gantt chart.”  Most Agilists are anti-Gantt.  This was a real eye-opener for me.  That project manager went on to gain confidence in the Agile team and was able to eventually discard the Gantt chart.

SAFe isn’t just a framework, it’s actually a scaffolding.  When you build an arch, you need a scaffold to keep everything in place until the keystone is in place.  In creating an Agile enterprise, you use SAFe as a scaffold to get you to Agility.

Lean, Agile and Leadership

This training has also spent a lot of time discussing Lean thinking, Lean product flow and Lean leadership.  SAFe asserts four principles of Agile Leadership:

  1. Take a systems view
  2. Embrace the Agile Manifesto
  3. Implement product development flow
  4. Unlock the intrinsic motivation of knowledge workers

I like this list.  I might change the wording slightly, but in going through the details of what these mean, it is clear that if leaders could adopt these principles, every organization would be a much better place to work.

There is a fair amount of time spent on helping leaders make the shift in thinking from traditional “scientific management” to “Agile leadership”.  There are a lot of good reading references given in these discussions including “Five Dysfunctions of a Team”.  There is also a lot of time spent on value stream thinking including some great discussion exercises.

Organizational Structure in SAFe

SAFe does not define all the structures throughout the whole organization.  By design, it is not end-to-end, top-to-bottom.  It does define a structure for three levels of activity: the team level, the program level and the portfolio level.

At the team level, SAFe relies on a slightly modified version of Scrum and Extreme Programming (XP) that it calls SAFe ScrumXP.  As a Certified Scrum Trainer, I’m confident that the Scrum described is “good enough” to be legitimate Scrum even if there are small variations.  One example is in the idea of commitment.  Scrum espouses the value of Commitment.  In “old” versions of Scrum, the Scrum Team was required to commit to the work of the Sprint (the business scope).  SAFe keeps this concept.  However, if you look in the most recent version of the Scrum Guide, this concept is no longer present.  One thing that I think is absolutely fantastic is that several of the XP technical practices are required practices in SAFe: Test Driven Development, Continuous Integration, Pair Programming, User Stories, Acceptance Test Automation and Refactoring.  I wish that Scrum would get around to officially requiring these practices.  This set of canned answers is sometimes an irritant for Scrum folks, but the fact is that, again, middle managers are often made more comfortable by being provided with concrete answers.  And, in my not-so-humble opinion, SAFe is providing the right answers.  Since all this is at the Team level, middle managers are even more comfortable because they can tell all these staff-level people how to work.

At the program level, SAFe scales the basic concept of a Sprint up to a larger “Program Increment” (PI) concept.  The core concept that holds the program level together is the Agile Release Train which is based on a limit to the number of people who can work effectively in a social network (Dunbar’s number ? 150).  Again, SAFe is quite definitive about process at this level: Sprints are 2 weeks long and PIs are 5 Sprints long (10 weeks).  Timeboxing is explained effectively with the concepts of cadence and synchronization as a way to ensure predictability at the program level.  Unlike the simplicity of the Team level, the Program level in SAFe introduces a number of important connectors to transitional organizations.  This is done through defining several roles that have extremely close analogues to traditional roles (and even use a lot of the same names), and through other artifacts such as vision, roadmap, non-functional requirements, and features.  There are even a number of recommended metrics for evaluating the performance of the program (not the people).

At the Portfolio level, SAFe simplifies again somewhat in that there are no new aspects of cadence or synchronization introduced, and the number of defined roles and artifacts at this level is relatively small.  One important difference at this level compared to the Program and Team levels is the introduction of a Kanban approach used to feed “Program Epics” to the Agile Release Trains at the Program level.  At this level, Kanban is used to drive the flow of value, but there is not as much emphasis on continuous improvement here (although there is when SAFe discusses leadership).  At all three levels, there is a constant emphasis on the lean concept of focusing on value rather than cost.  This comes in many of the details, but may be a bit difficult for middle managers.  Fortunately, the Portfolio level  includes some excellent advice on working with budgets and allocating those budgets to business vs. technical needs and based on the effort required at the Program level with the Agile Release Trains.  SAFe recommends revisiting budgets every six months (I believe this is meant to be every 2 Product Increments) and is the only aspect of cadence and synchronization at the Portfolio level.

The Training

I’ll admit that overall I didn’t particularly enjoy the training.  I love SAFe.  As a trainer myself, I’m too critical perhaps.  Certainly, the training I deliver has evolved over ten years of work with lots and lots of feedback and mentorship.  However, in the Agile community, the overall standard for training has improved greatly over the last 5 years and I would love to see our three trainers who helped with this course improve their delivery.

There are a also some general comments about the training that I would like to make that are about personal preference.

First, I would prefer more small exercises that are experiential.  For example, there was a great deal of time spent on centralized vs. decentralized decision-making and leadership which could have been compressed greatly with a simple exercise like the “Command and Control Walking Simulation” which takes about 5 minutes to drive home the point unequivocally.  The first two days were largely lecture with a couple big exercises (both the lecture and the big exercises were generally good).

Second, the slides.  The slides.  The slides.  The slides… and more slides!!!  Too much by far.  And using the slides for lecture made it very difficult to stay on track for time with lots of slides missed or touched on only very briefly.  This is anxiety-inducing and boredom-inducing for me.  Some people like lots of slides, but most people don’t.

Third, not enough breaks for a 9 to 6 training session.  Usually just one break in the morning and one in the afternoon as well as a short lunch.  Two breaks and a longer lunch would have made it much more tolerable from a personal comfort level.  At one point on the third day I just had to take an extra break and I ended up missing about 30 minutes before I felt ready to come back.

Final Words

I’m happy I invested in this for both myself and for Travis.  We have learned a lot about SAFe, a little about Agile and Lean, and we are both excited about offering SAFe-related services to some of our clients.  At this point I am convinced that it is appropriate and good under some common (but not universal) conditions.

I will probably write several more articles about SAFe as I process the information and start to relate it to more specific aspects of Agile, Lean, organizations, management, leadership, productivity, and, of course, our own Agile Enterprise framework, the Real Agility Program. I’m excited and happy to see that the two frameworks are not competitive or exclusive in any significant way… more about that of course!

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

Emotional Intelligence is a Key Leadership Skill

J.D. Meier's Blog - Wed, 10/08/2014 - 17:19

You probably already know that emotional intelligence, or “EQ”, is a key to success in work and life.

Emotional intelligence is the ability to identify, assess, and control the emotions of yourself, others, and groups.

It’s the key to helping you respond vs. react.  When we react, it’s our lizard brain in action.  When we respond, we are aware of our emotions, but they are input, and they don’t rule our actions.  Instead, emotions inform our actions.

Emotional intelligence is how you avoid letting other people push your buttons.  And, at the same time, you can push your own buttons, because of your self-awareness.  

Emotional intelligence takes empathy.  Empathy, simply put, is the ability to understand and share the feelings of others. 

When somebody is intelligent, and has a high IQ, you would think that they would be successful.

But, if there is a lack of EQ (emotional intelligence), then their relationships suffer.

As a result, their effectiveness, their influence, and their impact are marginalized.

That’s what makes emotional intelligence such an important and powerful leadership skill.

And, it’s emotional intelligence that often sets leaders apart.

Truly exceptional leaders, not only demonstrate emotional intelligence, but within emotional intelligence, they stand out.

Outstanding leaders shine in the following 7 emotional intelligence competencies: Self-reliance, Assertiveness, Optimism, Self-Actualization, Self-Confidence, Relationship Skills, and Empathy.

I’ve summarized 10 Big Ideas from Emotional Capitalists: The Ultimate Guide to Developing Emotional Intelligence for Leaders.  It’s an insightful book by Martyn Newman, and it’s one of the best books I’ve read on the art and science of emotional intelligence.   What sets this book apart is that Newman focused on turning emotional intelligence into a skill you can practice, with measurable results (he has a scoring system.)

If there’s one take away, it’s really this.  The leaders that get the best results know how to get employees and customers emotionally invested in the business.  

Without emotional investment, people don’t bring out their best and you end up with a brand that’s blah.

You Might Also Like

10 Emotional Intelligence Articles for Effectiveness in Work and Life

Emotional Intelligence Quotes

Positive Intelligence at Microsoft

Categories: Blogs