Skip to content

Feed aggregator

Join the SUGSA Committee

Scrum User Group of South Africa - 11 hours 12 min ago
Enjoy SUGSA events, want to get a bit more involved? Why not join the committee? Nominations for the 2015 Cape Town SUGSA Committee, are now open to all SUGSA members. We promise you dinner and drinks with international agile celebrities (when they come for our annual event), highly entertaining committee meetings, an opportunity to be part of a […]
Categories: Communities

Python/matpotlib: Plotting occurrences of the main characters in How I Met Your Mother

Mark Needham - Fri, 01/30/2015 - 23:29

Normally when I’m playing around with data sets in R I get out ggplot2 to plot some charts to get a feel for the data but having spent quite a bit of time with Python and How I met your mother transcripts I haven’t created a single plot. I thought I’d better change change that.

After a bit of searching around it seems that matplotlib is the go to library for this job and I thought an interesting thing to plot would be how often each of the main characters appear in each episode across the show.

I’ve already got all the sentences from each episode as well as the list of episodes pulled out into CSV files so we can start from there.

This is a sample of the sentences file:

$ head -n 10 data/import/sentences.csv
SentenceId,EpisodeId,Season,Episode,Sentence
1,1,1,1,Pilot
2,1,1,1,Scene One
3,1,1,1,[Title: The Year 2030]
4,1,1,1,"Narrator: Kids, I'm going to tell you an incredible story. The story of how I met your mother"
5,1,1,1,Son: Are we being punished for something?
6,1,1,1,Narrator: No
7,1,1,1,"Daughter: Yeah, is this going to take a while?"
8,1,1,1,"Narrator: Yes. (Kids are annoyed) Twenty-five years ago, before I was dad, I had this whole other life."
9,1,1,1,"(Music Plays, Title ""How I Met Your Mother"" appears)"

My first step was to transform the CSV file into an array of words grouped by episode. I created a dictionary, iterated over the CSV file and then used nltk’s word tokeniser to pull out words from sentences:

import csv
from collections import defaultdict
 
episodes = defaultdict(list)
with open("data/import/sentences.csv", "r") as sentencesfile:
    reader = csv.reader(sentencesfile, delimiter = ",")
    reader.next()
    for row in reader:
        episodes[row[1]].append([ word for word in nltk.word_tokenize(row[4].lower())] )

Let’s have a quick look what’s in our dictionary:

>>> episodes.keys()[:10]
['165', '133', '132', '131', '130', '137', '136', '135', '134', '139']

We’ve got some episode numbers as we’d expect. Now let’s have a look at some of the words for one of the episodes:

>>> episodes["165"][5]
['\xe2\x99\xaa', 'how', 'i', 'met', 'your', 'mother', '8x05', '\xe2\x99\xaa']

So we’ve got an list of lists of words for each episode but gensim (which I wanted to play around with) requires a single array of words per document.

I transformed the data into the appropriate format and fed it into a gensim Dictionary:

from gensim import corpora
texts = []
for id, episode in episodes.iteritems():
    texts.append([item for sublist in episode for item in sublist])
dictionary = corpora.Dictionary(texts)

If we peek into ‘texts’ we can see that the list has been flattened:

>>> texts[0][10:20]
['a', 'bit', 'of', 'a', 'dog', ',', 'and', 'even', 'though', 'he']

We’ll now convert our dictionary of words into a sparse vector which contains pairs of word ids and the number of time they occur:

corpus = [dictionary.doc2bow(text) for text in texts]

Let’s try and find out how many times the word ‘ted’ occurs in our corpus. First we need to find out the word id for ‘ted':

>>> dictionary.token2id["ted"]
551

I don’t know how to look up the word id directly from the corpus but you can get back an individual document (episode) and its words quite easily:

>>> corpus[0][:5]
[(0, 8), (1, 1), (2, 2), (3, 13), (4, 20)]

We can then convert that into a dictionary and look up our word:

>>> dict(corpus[0]).get(551)
16

So ‘ted’ occurs 16 times in the first episode. If we generify that code we end up with the following:

words = ["ted", "robin", "barney", "lily", "marshall"]
words_dict = dict()
for word in words:
    word_id = dictionary.token2id[word]
    counts = []
    for episode in corpus:
        count = dict(episode).get(word_id) or 0
        counts.append(count)
    words_dict[word] = counts

There’s quite a lot of counts in there so let’s just preview the first 5 episodes:

>>> for word, counts in words_dict.iteritems():
       print word, counts[:5]
 
lily [3, 20, 47, 26, 41]
marshall [8, 25, 63, 27, 34]
barney [9, 94, 58, 92, 102]
ted [16, 46, 66, 32, 44]
robin [18, 43, 25, 24, 34]

Now it’s time to bring out matplotlib and make this visual! I initially put all the characters on one chart but it looks very messy and there’s a lot of overlap so I decided on separate charts.

The only thing I had to do to achieve this was call plt.figure() at the beginning of the loop to create a new plot:

import matplotlib
matplotlib.use('TkAgg')
import matplotlib.pyplot as plt
pylab.show()
 
for word, counts in words_dict.iteritems():
    plt.figure()
    plt.plot(counts)
    plt.legend([word], loc='upper left')
    plt.ylabel('occurrences')
    plt.xlabel('episode')
    plt.xlim(0, 208)
    plt.savefig('images/%s.png' % (word), dpi=200)

This generates plots like this:

2015 01 30 21 15 03

This is good but I thought it’d be interesting to put in the season demarcations to see if that could give any more insight. We can call the function plt.axvline and pass in the appropriate episode number to achieve this effect but I needed to know the episode ID for the last episode in each season which required a bit of code:

import pandas as pd
df = pd.read_csv('data/import/episodes.csv', index_col=False, header=0)
last_episode_in_season = list(df.groupby("Season").max()["NumberOverall"])
 
>>> last_episode_in_season
[22, 44, 64, 88, 112, 136, 160, 184, 208]

Now let’s plug that into matplotlib:

for word, counts in words_dict.iteritems():
    plt.figure()
    plt.plot(counts)
    for episode in last_episode_in_season:
        plt.axvline(x=episode, color = "red")
    plt.legend([word], loc='upper left')
    plt.ylabel('occurrences')
    plt.xlabel('episode')
    plt.xlim(0, 208)
    plt.savefig('images/%s.png' % (word), dpi=200)

2015 01 30 21 10 52

The last thing I wanted to do is get all the plots on the same scale for which I needed to get the maximum number of occurrences of any character in any episode. It was easier than I expected:

>>> y_max = max([max(count) for count in words_dict.values()])
>>> y_max
260

And now let’s plot again:

for word, counts in words_dict.iteritems():
    plt.figure()
    plt.plot(counts)
    for episode in last_episode_in_season:
        plt.axvline(x=episode, color = "red")
    plt.legend([word], loc='upper left')
    plt.ylabel('occurrences')
    plt.xlabel('episode')
    plt.xlim(0, 208)
    plt.ylim(0, y_max)
    plt.savefig('images/%s.png' % (word), dpi=200)


Our charts are now easy to compare:

2015 01 30 21 23 48

2015 01 30 21 24 03

For some reason there’s a big spike of the word ‘ted’ in the middle of the 7th season – I’m clearly not a big enough fan to know why that is but it’s a spike of 30% over the next highest value.

The data isn’t perfect – some of the episodes list the speaker of the sentence and some don’t so it may be that the spikes indicate that rather than anything else.

I find it’s always nice to do a bit of visual exploration of the data anyway and now I know it’s possible to do so pretty easily in Python land.

Categories: Blogs

An Important But Uncooperative Team Member

Illustrated Agile - Len Lagestee - Fri, 01/30/2015 - 20:00

The following was question was posted to the Ask Anything page. Feel free to ask your own questions here or respond contribute your thoughts to situation in comments section below.

From: A New Scrum Master
Location: England
Subject: Important but uncooperative team member

Hello. My company is new to scrum and agile, and I am new to being a scrum master. For about a year I’ve being coaching two teams in the way of scrum and we’ve seen great progress – but I’ve recently run into a problem. One team member in one of my teams is against team work and recently has been outwardly disrespectful to me. When I took them aside and asked them how I may have offended them, I was told that I was not their boss and that I couldn’t tell them what to do. I’ve never thought of myself as the team’s manager, but someone who helps them along, trying to let them know the highest priorities in regards to the Product Owners needs/wants – never commanding anyone to do anything specifically.

The rest of the team participates in planning poker for project estimates, and helps write on the board during retros (or at the very least shares ideas or issues). This other member prefers to sit in the back of the conference room and say nothing.

During daily stand ups, the team gathers around our desks because we are in a 4 person cubical, but this person keeps their back turned to me whenever I talk and practically gives the cold shoulder. I’ve tried confrontation (one on one) and I’ve tried reasoning with them. I’ve also asked for feedback to understand how I am offending them but they simply tell me “When you get like that I’m just going to push back.” I have been told by another co-worker (who is not part of our team) that they have complained “She is not a manager! She’s never had managerial experience! Why is she a scrum master??” – to which I go back to my thought of: I am NOT a manager, nor have I thought of myself as one.

I’m afraid the negative attitude will poison the rest of that team, but the person’s work is a great asset to the team’s success. I feel strongly in keeping harmony amongst the team, as I feel it is my job to keep everyone happy and to give everyone what they need to succeed – but then how do I handle this?

RESPONSE

An agile transformation will illuminate long-hidden dysfunctions in an organization. In fact, if it doesn’t I would be a little skeptical of just how “agile” their transformation really is. What you are experiencing is a normal part of change journey but what will make or break an organization is how they respond once a dysfunction is revealed. The post Agile, The Amplifier shares more on this subject.

Reading a little into your situation, the person you refer to:

  • May be a product of bad management over the years to let disrespectful behavior fester and continue
  • May have extensive domain knowledge or expertise so managers are afraid to let them go
  • May be considered a “rock-star” or a “go-to” person and has answers people are looking for
  • May be nervous about how a collaborative and cross-functional environment such as agile will impact their standing as the “go-to” person

So what are your options? Strictly my opinion but here are a few thoughts:

The first option may be painful (and may not really be an option if you are not comfortable) but perhaps you can try to connect with this person on personal level on neutral ground. Go for coffee or lunch. There may be something else going on outside of work or perhaps they will open up about what is really disturbing them about the move to agile. You may get an opportunity to share about the expectations of your role and discuss ways for him to help you achieve those expectations. It’s a long-shot but worth a try.

The second option is for a manager to recognize the toxicity and move this person out of the organization. This may require a conversation between you and the reporting manager. It is ok to disagree and provide contrarian opinions but, from what it sounds like, being disrespectful and degrading is never acceptable. We want to give every one a chance but this person may not be right for agile (or any methodology for that matter).

The post It Only Takes One mentions how one person can create havoc on a team. While this post is directed toward managers who are currently managing disruptive people, there may be something there for you as well. Perhaps you can forward this post and the Agile, The Amplifier to the manager to start your conversation with them.

With the third option, I can assume the person is still on the team and a manager hasn’t taken action. At this point, you can leave it to the team to provide enough peer pressure for them to change or to “vote them off the island” if the disrespectful behavior continues. Perhaps you can have a member of the team have a conversation with this person so they can share how this is affecting you (and the team).

The fourth option is for you to ask not be the Scrum Master on the team anymore. Especially if this situation is causing you stress or sleepless nights. It sounds like you are doing everything right as far as the mechanics of agile are concerned so I would hate for this situation to discourage you from being an amazing Scrum Master.

Hope this helps! Feel free to email me if you have any further questions.

Becoming a Catalyst - Scrum Master Edition

The post An Important But Uncooperative Team Member appeared first on Illustrated Agile.

Categories: Blogs

Interview with The Entrepreneur's Library on Getting Results the Agile Way

J.D. Meier's Blog - Fri, 01/30/2015 - 19:47

What is Agile Results all about?   What are the most important keys to using Agile Results to master productivity, time management, and work-life balance?

If you've ever wondered what Getting Results the Agile Way is all about, or want to know how to make the most of the book, this is it.  I answer these questions and more in my interview with The Entrepreneur's Library on Getting Results the Agile Way:

Interview with The Entrepreneur's Library on Agile Results

In this interview, Wade Danielson, the creator of The Entrepreneur’s Library, asks me the following questions:

  1. What was the inspiration behind writing this book?
  2. What makes this book different from others regarding this same topic?
  3. If the reader could only take one concept/principle/action item out of the entire book, what would you want that to be?
  4. Do you have a favorite quote from your book?
  5. If there was only one book you recommend to our listeners based on the way it has impacted your life, what would that be?

Wade also gives me a chance to give a walkthrough of the book, Getting Results the Agile Way, where I explain how to make the most of the book, and what each section is really about.

It’s a unique chance to get the philosophy behind Agile Results and why it’s really a personal results system for work and life.   It’s not a system that you break yourself against.  Instead, it’s a simple system for meaningful results that supports you and the way you work.  It helps you optimize your productivity by focusing on the wins that matter, playing to your strengths, and using your best energy for your best results.

An amazing thing happens when you become more focused and productive …

You get more out of life.

And you can get more done in a day than other people get done all week.

Categories: Blogs

A Kanban Thinking Pixar Pitch

AvailAgility - Karl Scotland - Fri, 01/30/2015 - 18:44

I’ve been using the Pixar Pitch as a fun way for teams to discuss and explore the problem they are trying to solve by telling a story about what has been happening that led to the need for a kanban system. I thought it might be useful to use the formula to tell a dramatised story of what led me to first try using a kanban approach, and why that led to Kanban Thinking.

The Pixar Pitch

Once upon a time there was a team who were using Scrum to manage their work. They were cross-functional, with a ScrumMaster and Product Owner, developing and supporting a suite of entertainment websites for a global new-media organisation.

Every Sprint they prioritised and planned the next couple of weeks, developed and tested functionality, fixed live issues, released updates when ready, and reviewed and retrospected their work.

And every Sprint the team was unhappy with the way they were working. The Product Owner felt that the developers could be more productive, and the developers felt that the Product Owner could be giving more guidance on what build. Stories were completed, but features took a long time to release as the team thrashed to get the functionality right, meet commitments and increase velocity.

So every Sprint they inspected and adapted. The Spring length was shortened to get quicker feedback. The style of User Stories was adjusted to try and focus more on value. And yet things did’t improve significantly.

One day they decided to stop focussing on doing Scrum, and start using ideas from Kanban, experimenting with some different approaches that they hadn’t previously tried.

Because of that they stopped using Sprints and de-coupled their cadences, reprioritising their ready queue every week, planning only when they had capacity to start new work, releasing and reviewing every fortnight, and retrospecting every month.

And instead of breaking work down into small User Stories that would take less than 2 weeks, they focussed on finishing larger MMFs, which might take months in some cases.

And they paid more attention to their Work in Process, in particular making sure they only worked on one large new feature at a time.

And instead of the Sprint Burndown they tracked their work using a Cumulative Flow Diagram, Parking Lot and Lead Time report.

Because of that the whole team became more focussed on delivering valuable features, were more collaborative in how they figured out what the details of those feature were, and were more reliable in when they delivered them.

Until finally everyone was working well together as a much happier group, delivering much more value, and in a good place to continue to improve.

Kanban Thinking

The point of this story is not to try and make one approach sounds better than another, or to suggest that any approach can be a bad choice in some way. Rather it is that the team learned about what would and wouldn’t work by asking questions about their process and experimenting with all aspects of it. The end result might have ended up being exactly what an expert or consultant might have recommended or coached. That’s OK, because what is important is the understanding that was created about why things are as they are. This capability to solve problems, as opposed to implement solutions, sets a team up to continually evolve and improve as their context changes.

This principle – helping teams to solve problems rather than implement solutions – is what fascinated me about kanban when I first came across it and started exploring how it could be used. Its what ultimately led to the emergence of Kanban Thinking as a model for helping achieve this, and the Kanban Canvas as a practical tool.

Categories: Blogs

AutoMapper support for Xamarin Unified (64 bit)

Jimmy Bogard - Fri, 01/30/2015 - 16:00

I pushed out a prerelease package of AutoMapper for Xamarin Unified, including 64-bit support for iOS.

http://www.nuget.org/packages/AutoMapper/

If you’ve had issues with Xamarin on 64-bit iOS, removing an adding the AutoMapper NuGet package reference should do the trick.

And yes, I verified this on a 64-bit device, not the simulator that is full of false hope and broken dreams.

Enjoy!

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

Categories: Blogs

Run your iOS app without overwriting the App Store version

Xebia Blog - Fri, 01/30/2015 - 14:59

Sometimes when you're developing a new version of your iOS app, you'd like to run it on your iPhone or iPad and still be able to run the current version that is released on the App Store. Normally when you run your app from Xcode on your device, it will overwrite any existing version. If you then want to switch back to the version from the App Store, you'll have to delete the development version and download it again from the App Store.

In this blog post I'll describe how you can run a test version of your app next to your production version. This method also works when you have embedded extensions (like the Today Widget or WatchKit app) in your app or when you want to beta test your app with Apple's TestFlight.

There are two different ways to accomplish this. The first method is to create a new target within your project that runs the same app but with a different name and identifier. With iOS 8 it is now possible to embed extensions in your app. Since these extensions are embedded in the app target, this approach doesn't work when you have extensions and therefore I'll only describe the second method which is based on User-Defined Settings in the build configuration.

Before going into detail, here is a quick explanation of how this works. Xcode already creates two build configurations for us: Release and Debug. By adding some User-Defined Settings to the build configurations we can run the Debug configuration with a different Bundle identifier than the Release configuration. This essentially creates a separate app on your device, keeping the one from the App Store (which used the Release configuration) intact.

To beta distribution of the app built with debug configuration easier we'll create multiple schemes.

The basics

Follow these steps exactly to run a test version on your device next to your App Store version. These steps are based on Xcode 6.1.1 with an Apple Developer Account with admin privileges.

Click on your project in the Project Navigator and make sure the main target is selected. Under both the General and Info tabs you will find the Bundle identifier. If you change this name and run your app, it will create a new app next to the old one. Add -test to your current Bundle identifier so you get something like com.example.myapp-test. Xcode will probably tell you that you don't have a provisioning profile. Let Xcode fix this issue for you and it will create a new Development profile for you named something like iOSTeam Provisioning Profile: com.example.myapp-test.

So we're already able to run a test version of our app next to the App Store version. However, manually changing the Bundle identifier all the time isn't very practical. The Bundle identifier is part of the Info.plist and it's not derived from a Build configuration property like for example the Bundle name (which uses ${PRODUCT_NAME} from the build configuration by default). Therefore we can't simply specify a different Bundle identifier for a different Build configuration using an existing property. But, we can use a User-Defined Setting for this.

Go to the Build Settings tab of your project and click the + button to add a User-Defined Setting. Name the new setting BUNDLE_ID and give it the value of the test Bundle identifier you created earlier (com.example.myapp-test). Then click the small triangle in front of the setting to expand the setting. Remove the -test part from the Release configuration. You should end up with something like this:

Screen Shot 2015-01-30 at 11.29.43

Now go to the Info tab and change the value of the Bundle identifier to ${BUNDLE_ID}. In the General tab you will still see the correct Bundle Identifier, but if you click on it you see the text is slightly grayed out, which means it's taken from a Build configuration setting.

Screen Shot 2015-01-30 at 11.35.52

To test if this works, you can change edit the current Scheme and change the Build Configuration of the Run action from Debug to Release. Close the Scheme window and go to the General tab again to see that the Bundle Identifier has changed to the Release BUNDLE_ID. (If you still had the General tab open and don't see the change then switch to another tab and back; the panel will reload the identifier). Make sure to change the Build configuration back to Debug in your scheme afterwards.

When you now Archive an app before you release it to the App Store, it will use the correct identifier from the Release configuration and when you run the app from Xcode on your device, it will use the identifier for testing. That way it no longer overwrites your App Store version on your device.

App name

Both our App Store app and test app still have the same name. This makes it hard to know which one is which. To solve this, find the Product Name in the Build Settings and change the name for the Debug configuration to something else, like MyApp Test.

Beta distribution

What if you want to distribute a version of the app for Beta testing (through TestFlight or something similar) to other people that also shouldn't overwrite their Apple Store version? Our Archive action is using the Release build configuration. We could change that manually to Debug to have the test Bundle identifier but then we would be getting all of the Debug settings in our app, which is not something we want. We need to create another Build configuration.

Go to the project settings of your project (so not the target settings). Click the + button under Configurations and duplicate the Release configuration. Call the new configuration AdHoc. (You might already have such a Build configuration for other reasons, in that case you can skip this step and use that one for the next steps.)

Now go to the Build Settings of your main target and change the AdHoc value of the User-Defined Setting BUNDLE_ID to the same as the Debug value. Do the same for the Product name is you changed that in the previous step.

We could already make a Beta test Archive now by manually changing the configuration of the Archive action to Debug. But it makes it easier if we create a new scheme to do this. So go to the Manage Schemes and click to + button at the bottom left to create a new scheme. Make sure that your main target is selected as Target and add " Test" to the name so you end up with something like "MyApp Test". Also check the Shared checkbox if you are sharing your schemes on your version control system.

Double click the new scheme to edit it and change the build configuration of the Archive action to AdHoc. Now you can Archive with the MyApp Test scheme selected to create a test version of your app that you can distribute to your testers without it overwriting their App Store version.

To avoid confusion about which build configuration is used by which scheme action, you should also change the configuration of the Profile action to AdHoc. And in your normal non-test scheme, you can change the build configuration of all actions to Release. This allows you to run the app in both modes of your device, which sometimes might be necessary, for example when you need to test push notifications that only work for the normal Bundle identifier.

Extensions

As mentioned in the intro, the main reason to use multiple schemes with different build configurations and User-Defined settings as opposed to creating multiple targets with different Bundle identifiers is because of Extensions, like the Today extension or a WatchKit extension. An extension can only be part of a single target.

Extensions make things even more complex since their Bundle identifier needs to be prefixed with the parent app's bundle identifier. And since we just made that one dynamic, we need to make the Bundle identifier of our extensions dynamic as well.

If you don't already have an existing extension, create a new one now. I've tested the approach described below with Today extensions and WatchKit extensions but it should work with any other extension as well.

The steps for getting a dynamic Bundle identifier for the extensions is very similar as the once for the main target so I won't go into too much detail here.

First open the Info tab of the new target that was created for the extension, e.g. MyAppToday. You'll see here that the Bundle display name is not derived from the PRODUCT_NAME. This is probably because the product name (which is derived from the target name) is something not very user friendly like MyAppToday and it is assumed that you will change it. In case of the Today extension, running a test version of the app next to the App Store version will also create 2 Today extensions in the Today view of the phone. To be able to differentiate between the two we'll also make the Bundle display name dynamic.

Change the value of it to ${BUNDLE_DISPLAY_NAME} and then add a User-Defined Setting for BUNDLE_DISPLAY_NAME with different names for Debug/AdHoc and Release.

You might have noticed that the Bundle identifier of the extension is already party dynamic, something like com.example.myapp.$(PRODUCT_NAME:rfc1034identifier). Change this to ${PARENT_BUNDLE_ID}.$(PRODUCT_NAME:rfc1034identifier) and add a User-Defined Setting for PARENT_BUNDLE_ID to your Build Settings. The values of the PARENT_BUNDLE_ID should be exactly the same as the ones you used in your main target, e.g. com.example.myapp for Release and com.example.myapp-test for Debug and AdHoc.

That's it, you can now Run and Archive your app with extensions who's Bundle identifier are prefixed with the parent's Bundle identifier.

App Groups entitlements

You might have an extension that shares UserDefaults data or Core Data stores with the main app. In that case you need to have matching App Groups entitlements in both your main app and extensions. Since we have dynamic Bundle identifiers that use different provisioning profiles, we also have to make our App Groups dynamic.

If you don't have App Groups entitlements (or other entitlements) yet, go to the Capabilities tab of your main target and switch on App Groups. Add an app group in the form off group.[bundle identifier], e.g. group.com.example.myapp. This will generate an entitlements file for your project (MyApp.entitlements) and set the Code Signing Entitlements of your Build Settings to something like MyApp/MyApp.entitlements. Locate the entitlements file in Finder and duplicate it. Change the name of the copy by replacing " Copy" with "Test" (MyAppTest.entitlements). Drag the copy into your project. You should now have two entitlement files in your project. Open the Test entitlements file in Xcode's Property List editor and add "-test" to the value of Item 0 under com.apple.security.application-groups to match it with the Bundle identifier we used for testing, e.g. com.example.myapp-test. Now go back to the Build Settings and change the Debug and AdHoc values of Code Signing Entitlements to match with the file name of the Test entitlements.

Repeat all these steps for the Extension target. Xcode will also generate the entitlements file in the extension folder. You should end up with two entitlements files for your main target and two entitlements files for every extension.

The Application Groups for testing need to be added to the provisioning profiles which Xcode will handle automatically for you. It might warn/ask you for this while building.

Conclusion

It might be quite some work to follow all these steps and to get everything to work, but if you use your normal iPhone for development and still want to use or show a stable version of your app at the same time, it's definitely worth doing. And your Beta testers will thank your for it as well.

Categories: Companies

10/10/10

There's an interesting decision making technique that I came across in the book Decisive. It's called 10/10/10. The technique was developed by Suzy Welch. She has a book by the same name.

The idea is to think about how you will feel about a decision in 10 minutes, 10 months, and 10 years. The idea being discussed in Decisive is how to avoid short-term emotion when making a decision. Bad decisions, they say, are made while having strong emotions such as anger or greed.

For example, I recently bought a new car, what a lot of people would agree can be an emotional event. Ten minutes after I walked out the door, I'd be excited about the new car and happy with my decision.

In ten months, I may still be thinking about the car I didn't buy and if I would have been happier in that one.

Ten years from now I'll be happy I choose the car that was more reliable over the one that would have been fun, but probably had more problems. If I didn't keep the car ten years, I would have been happy that the car I choose was the one with the higher resale value.

So next time you have a decision to make, think about 10/10/10.
Categories: Blogs

R: ggplot2 – Each group consist of only one observation. Do you need to adjust the group aesthetic?

Mark Needham - Fri, 01/30/2015 - 02:27

I’ve been playing around with some weather data over the last couple of days which I aggregated down to the average temperature per month over the last 4 years and stored in a CSV file.

This is what the file looks like:

$ cat /tmp/averageTemperatureByMonth.csv
"month","aveTemperature"
"January",6.02684563758389
"February",5.89380530973451
"March",7.54838709677419
"April",10.875
"May",13.3064516129032
"June",15.9666666666667
"July",18.8387096774194
"August",18.3709677419355
"September",16.2583333333333
"October",13.4596774193548
"November",9.19166666666667
"December",7.01612903225806

I wanted to create a simple line chart which would show the months of the year in ascending order with the appropriate temperature.

My first attempt was the following:

df = read.csv("/tmp/averageTemperatureByMonth.csv")
df$month = factor(df$month, month.name)
 
ggplot(aes(x = month, y = aveTemperature), data = df) + 
  geom_line( ) + 
  ggtitle("Temperature by month")

which resulted in the following error:

geom_path: Each group consist of only one observation. Do you need to adjust the group aesthetic?

My understanding is that the points don’t get joined up by default because the variable on the x axis is not a continuous one but rather a factor variable.

One way to work around this problem is to make it numeric, like so:

ggplot(aes(x = as.numeric(month), y = aveTemperature), data = df) + 
  geom_line( ) + 
  ggtitle("Temperature by month")

which results in the following chart:

2015 01 30 00 25 18

This isn’t bad but it’d be much nicer if we could have the month names along the bottom instead.

It turns out we can but we need to specify a group that each point belongs to. ggplot will then connects points which belong to the same group.

In this case we don’t really have one so we’ll define a dummy one instead:

ggplot(aes(x = month, y = aveTemperature, group=1), data = df) + 
  geom_line( ) + 
  ggtitle("Temperature by month")

And now we get the visualisation we want:

2015 01 29 23 28 23

Categories: Blogs

Laloux Culture Model

Agilitrix - Michael Sahota - Thu, 01/29/2015 - 21:33

Looking for a way to help evolve your organization’s culture? Frederic Laloux’s model provides a clear picture of how culture may evolve in an organization.

The model comes from Reinventing Organizations – a landmark book in the development of organizations that unleash the talents of people to get astonishing results. The book is grounded in case studies from around the world of organizations that are succeeding in a new way of working. The book has inspired me and helped me see much more clearly what is possible for myself and the clients I work with.

Laloux Culture Model

Frederic has a really awesome model for understanding organizational culture. It looks like this:

It shows how our society (over thousands of years) has evolved new ways of working together. Each stage has value: more advanced is not necessarily better – it’s about fit for context. It is derived from other models such as Integral, Spiral Dynamics, etc. Note that Laloux does not call this a culture model – he refers to it as stages in evolution of consciousness and organization.

Centralized Power & Structure [Red & Amber]

Red is about power: I am the leader – do what I say or else. Key innovations are the division of labour and authority. Examples include street gangs or tribal militias.

Amber organizations channel power through a hierarchy with formal roles and reporting lines (command & control). They establish stable processed that allow them to scale to a large size. Current examples are: military, government agencies, public school systems.

Achievement [Orange]

Orange is about a shift to focus on achievement: bigger and better. Innovation is key: how do we evolve our process? What projects do we need to improve things? With orange, we create plans and hold people accountable for results (predict & control). Since the focus is now on results, a meritocracy is formed based on who actually delivers. The organization is seen as machine to be exploited. Examples are multinational organizations and charter schools.

People [Green]

Green organizations focus on the empowerment of workers (within the hierarchy) as the key for driving success. There are explicit shared values that guide behaviour and decision-making. Green organizations have family as a guiding metaphor. They also have a clear purpose to support coherent activity. Green organizations see a bigger picture beyond profits: workers, customers and their role in the community. Examples include Southwest Airlines, Zappos, Ben & Jerry’s.

Shared Power [Teal]

Teal organizations are decentralized into autonomous teams or groups. Power is shared and people are self-managing. Decisions are made independently – there is no centralized group telling people what to do. Decision-making independence is enhanced with visibility and advice. Trust replaces process. People’s whole selves (mind, body, heart, spirit) are welcomed. The organization evolves through an emergent process since everyone can make decisions. The metaphor for Teal is that of a living system. Examples include: Patagonia, Morning Star,… (more in the book).

Go Read The Book

Creating Organizations Guided by the next stage of human evlolutionThis is the best book I have read in years. It has helped me tremendously in getting a deeper understanding of the work I have been doing with culture for the last few years and helped me see the larger pattern of organizational evolution much more clearly.

In upcoming posts, I will write more about how to use this model and the Teal stage.

 

 

 

 

 

The post Laloux Culture Model appeared first on Catalyst - Agile & Culture.

Related posts:

  1. Whole Agile – Unleash People & Organizations Agile is incomplete. We need to augment it to create...
  2. Letting Go of Agile (Culture) “If you want something very, very badly, let it go...
  3. VAST – Virtuous Cycle for Connection It’s all about how we show up. If we show...

YARPP powered by AdBistroPowered by

Categories: Blogs

Clean Tests: A Primer

Jimmy Bogard - Thu, 01/29/2015 - 16:25

Over the course of my career, I’ve an opportunity to work with a number of long lived codebases. Ones that I’ve been a part of since commit one and continue on for six or seven years. Over that time, I’ll see how my opinions on writing tests have changed throughout the years. It’s gone from mid 2000s mock-heavy TDD, to story-driven BDD (I even wrote an ill-advised framework, NBehave), to context/spec BDD. I looked at more exotic testing frameworks, such as MSpec and NSpec.

One advantage I see in working with codebases for many years is that certain truths start to arise that normally you wouldn’t catch if you only work with a codebase for a few months. And one of the biggest truths to arise is that simple beats clever. Looking at my tests, especially in long-lived codebases, the ability for me to understand behavior in a test quickly and easily is the most important aspect of my tests.

Unfortunately, this has meant that for most of the projects I’ve worked with, I’ve had to fight against testing frameworks more than work with them. Convoluted test hierarchies, insufficient extensibility, breaking changes and pipelines are some of the problems I’ve had to deal with over the years.

That is, until an enterprising coworker Patrick Lioi started authoring a testing framework that (inadvertently) addressed all of my concerns and frustrations with testing frameworks.

In short, I wanted a testing framework that:

  • Was low, low ceremony
  • Allowed me to work with different styles of tests
  • Favored composition over inheritance
  • Actually looked like code I was writing in production
  • Allowed me to control lifecycle, soup to nuts

Testing frameworks are opinionated, but normally not in a good way. I wanted to work with a testing framework whose opinions were that it should be up to you to decide what good tests are. Because what I’ve found is that testing frameworks don’t keep up with my opinions, nor are they flexible in the vectors in which my opinions change.

That’s why for every project I’ve been on in the last 18 months or so, I’ve used Fixie as my test framework of choice. I want tests as clean as this:

using Should;

public class CalculatorTests
{
    public void ShouldAdd()
    {
        var calculator = new Calculator();
        calculator.Add(2, 3).ShouldEqual(5);
    }

    public void ShouldSubtract()
    {
        var calculator = new Calculator();
        calculator.Subtract(5, 3).ShouldEqual(2);
    }
}

I don’t want gimmicks, I don’t want clever, I want code that actually matches what I do. I don’t want inheritance, I don’t want restrictions on fixtures, I want to code my test how I code everything else. I want to build different rules based on different test organization patterns:

public class ApproveInvoiceTests {
    private Invoice _invoice;
    private CommandResult _result;
    
    public ApproveInvoiceTests(TestContext context) {
        var invoice = new Invoice("John Doe", 30m);
        
        context.Save(invoice);
        
        var message = new ApproveInvoice(invoice.Id);
        
        _result = context.Send(invoice);
        
        _invoice = context.Reload(invoice);
    }
    
    public void ShouldApproveInvoice() {
        _invoice.Status.ShouldEqual(InvoiceStatus.Approved);
    }
    
    public void ShouldRaiseApprovedEvent() {
        _result.Events.OfType<InvoiceApproved>().Count().ShouldEqual(1);
    }
}

Fixie gives me this, while none others can completely match its flexibility. Fixie’s philosophy is that assertions shouldn’t be a part of your test framework. Executing tests is what a test framework should provide out of the box, but test discovery, pipelines and customization should be completely up to you.

In the next few posts, I’ll detail how I like to use Fixie to build clean tests, where I’ve stopped fighting the framework and I take control of my tests.

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

Categories: Blogs

What Development & Test Managers do in Agile Organizations

Johanna Rothman - Thu, 01/29/2015 - 15:28

Is there room for functional managers, such as development and test managers, in agile organizations? Maybe. It depends on whether they take the role of an agile manager.

If you have organized as a feature teams-based organization, the functional managers (development, test, analysis, whatever) can take these responsibilities:

  • Develop trusting relationships with the people on the project team, and in their function.
  • Provide coaching and mentoring opportunities for people.
  • Provide communities of practice for the people.
  • Remove obstacles for the people and team.
  • Start and nurture the hiring effort whenever you need to hire new people.
  • Help people with career development.
  • Provide feedback to people, and help people learn how to provide feedback (meta-feedback).
  • Provide coaching and meta-coaching when people want it.
  • Help the organization understand its capacity and make decisions about the project portfolio.
  • Help influence the rest of the organization with the agile culture.

Functional managers are champions for the team, and shepherds for the process. They are servant leaders.

Here’s what functional managers do not do:

  • Have status conversations. If the team is agile, the team understands its status. If you need help seeing their board, that’s a problem the team needs to solve. If they need help seeing their status, they need to change their board or their process for updating each other.
  • Move people on or off teams, once you or the team establishes itself.
  • Ask people to do something the team has not committed to, or that the product owner has not added to the kanban board. That’s right. “Your” team doesn’t work for you; the team works for the product owner.
  • Micromanage any part of the project work. Or, manage any part of the project work.

What does this mean? It means that the team members are leaders. Agile pushes responsibility into the teams, and away from traditional management. Agile requires leadership at all levels.

Agile challenges managers to recreate their jobs. An agile transformation requires managers work in an agile way, and work differently than before.

If you want to learn more about the role of leaders and managers in agile, join Gil Broza and me at The Influential Agile Leader, either in San Francisco or London this year. We still have an early bird price until mid-February. Don’t miss this opportunity to help your agile transition and your career.

Categories: Blogs

How It Works: User Stories

Rally Agile Blog - Thu, 01/29/2015 - 15:00

Next Tuesday, February 10, our TeamStart webinar series will answer your questions about "Writing Great User Stories." Whether you’re just getting started with Agile or consider yourself an expert, join us to get and give some good Q+A. We’re going to talk about writing compelling stories that focus on business value. Here are a few questions from past "User Stories" webinars:

  • What are some tips for writing a great user story?
  • When do I break down user stories?
  • Who should drive the definition of acceptance criteria?

Here's a preview of what you'll learn in the TeanStart webinar.

Tips for Writing a Great User Story

A great user story has three areas of focus: Who, What, and Why. A great user story is also written from the perspective of the user (hence the name); and a great user story "tells a story" about what that user wants to be able to do, and why (for what outcome.)

Who: Define the person who receives value from a new user story. For example:

As a user of the website ...
As an internal team member ...
 

What: Indicate what needs to be delivered, from the perspective of the user. For example:

... I want to purchase my items with a credit card ...
... I need a new testing infrastructure ...
 

Why: Show the value the user gains from the story:

... so that I have a convenient and secure way to pay electronically.
... so that I can prepare for the new test requirements of our organization.

When to Break Down User Stories

When the estimated size of a user story exceeds the total velocity available in a team’s iteration, the story cannot fit and must be broken down into smaller stories. User stories can be broken down multiple times as they move up the backlog -- transitioning from a large, loosely-defined, parent story into a set of small, defined, child user stories that make progress towards the overall goal.

Who Should Drive the Definition of Acceptance Criteria

The entire development team assists the product owner in creating acceptance criteria. Product owners represent the business and stakeholders, and communicate the needs of a story to the team. Teams communicate with the product owner about what implementation methods are possible, and how a story may be completed to meet business needs.  


What are your questions? Get them answered. Join the TeamStart webinar series on Tuesday, February 10th, to learn about "Writing Great User Stories."

Rob Ward
Categories: Companies

Optional Conference, Budapest, Hungary, March 24-25 2015

Scrum Expert - Thu, 01/29/2015 - 11:28
The Optional Conference is a two-day event focused on Agile software development and Agile management that take place in Budapest, Hungary. It features local and international Agile and Scrum experts that engage the audience in presentations and workshops. In the agenda of the Optional Conference, you can find topics like “Waste is Optional”, “Case study: winning a tender with Story Mapping”, “Finding the right practice for the various levels of planning”, “Keeping Governance and Audit Agile”, “Radical Management”, “The Scaling Dilemma”, “Agile Teams: Self-Organizing, Collocated, and Distributed”, “Agile Architecture – How ...
Categories: Communities

8 Rituals of Amazing Scrum Masters

Illustrated Agile - Len Lagestee - Thu, 01/29/2015 - 01:00

Having worked with many Scrum Masters, I am beginning to recognize patterns and behaviors of some of the best. It appears to me that the Scrum Masters having the most impact with their teams and throughout the organization establish strong rituals for themselves. These rituals provide the momentum to overcome the challenges and busyness of the day.

The following rituals are a compilation of observing, leading, and coaching many Scrum Masters over many years so I would never expect one person to establish all of them but perhaps you can introduce one or two into your daily life.

Prepare for the day. While this could apply to everyone, amazing Scrum Masters will establish a ritual of taking a few minutes in the morning (or the previous evening) to think about the day ahead. To get started, ask yourself a couple of questions every day. Is the team in flow? If not, why? Is my team healthy? If not, what is keeping us from strength and vitality?

Foster a serendipitous environment. This will require a ritual of shaping positive experiences for people and will mean designing “intentional collisions” into everyday life. For example, purposefully finding ways for technical people to interact with product or business people or creating fun activities where developers and testers need to work together. This Wall Street journal article describes this occurrence well.

Replace “when” thinking with “why,” “what,” and “how” thinking. Most of the time anyway. Completion dates will always be an important to the organization but the first response should always be “why is the team operating at their current pace?” and “how can we create an environment of agility and speed?” The “when” will be taken care of with the mechanics of Scrum. A burn-down chart or release plan will always tell the “when” story based on empirical data emerging as the team is building the product. Of importance to you is why, what, and how behind the data.

Really allow change to happen. While many Scrum Masters align with the “welcoming change” principle of agile, few are brave enough to actually allow change to become a ritual. This could be a perpetuation of legacy dysfunctional behavior where experimentation is frowned upon and mistakes are punished. Change is a bit frightening but embrace it and allow something cool to emerge.

Observe and listen. The crucial ability for a Scrum Master (or coach) to watch and hear the dynamics of a team is a difficult ritual to master (certainly for me). This ritual will often need to correspond with a ritual of speaking less. By observing and listening, many more opportunities to serve will emerge.

Connect daily. I am a believer in the ritual of stopping by every team member at least once a day to have a quick one-on-one conversation. Just to see how people are doing (professionally and personally) and check if they need anything.

Relentlessly eliminate impediments. Amazing Scrum Masters make removing impediments and waste an everyday ritual and not just a once in while thing. They are constantly asking what is causing my team, my department, my organization to stumble and what can we do to resist the status quo.

Reflect daily. In the book Becoming a Catalyst: Scrum Master Edition, each section has “Everyday Retrospective” questions to trigger a few thoughts on how to review your day and trigger opportunities for increasing your impact. Block off a couple minutes or use your commute time and develop your own approach to capture your thoughts on the day. This reflection should feed the prepare for the day ritual.

QUESTION: What rituals have you established to help you become a better Scrum Master? Share them with the community below.

Becoming a Catalyst - Scrum Master Edition

The post 8 Rituals of Amazing Scrum Masters appeared first on Illustrated Agile.

Categories: Blogs

SonarQube 5.0 in Screenshots

Sonar - Wed, 01/28/2015 - 17:56

The team is proud to announce the release of SonarQube 5.0, which includes many new features

  • Issues page redesign
  • Keyboard shortcuts added to Issues
  • Built-in SCM support

Issues page redesign

With this version of the SonarQube platform, the Issues page has had a complete overhaul.

Issues are grouped in the list by file, and from the list of issues, you can easily navigate to the issue in the context of the code, as you’re used to seeing it,

Issue search has also been overhauled. You can still choose from criteria, but now next to each facet of the criteria, you see a count of the relevant issues.

Selected facets are highlighted in blue, and selecting/deselecting a facet immediately (okay, there’s a quick trip to the server and back) updates your search results and the issue counts next to all the other facets.

Keyboard shortcuts added to Issues

The intent behind the redesign is to allow you to use the Issues page quickly and efficiently to manage issues on a daily basis. To that end, extensive effort has gone into providing a broad set of keyboard short cuts. ‘?’ brings up the list, and Esc closes it.

From the list of issues, right-arrow takes you to the issue-in-context, and left-arrow takes you back to the list. In either context, up-arrow/down-arrow takes you to the next issue – in the same file or the next one – and you can use the shortcuts to comment, assign…

Built-in SCM support

SCM “blame” information has been an important data point in the SonarQube interface for a long time, but until now a plugin was required to use it. Now SCM data comes as part of the platform, with built-in support for SVN and Git.

Speaking of Git, its rise in popularity has meant that the use of ‘/’ in branch names has become increasingly common. Until now, that was unsupported by SonarQube. That changes with 5.0, presumably making many Git-ers happy. :-)

That’s all, Folks!

Time now to download the new version and try it out. But don’t forget that you’ll need Java 7 to run this version of the platform (you can still analyse Java 6 code), and don’t forget to read the installation or upgrade guide.

Categories: Open Source

30 seconds and 5 lines of code later

Derick Bailey - new ThoughtStream - Wed, 01/28/2015 - 13:00

I was about to pull my hair out.

I had been looking at my monitor for nearly an hour, trying to wrap my head around the inverse tree traversal that I had to do. Start at the bottom, work my way up, find my way back to where I started and update each node along the way. It didn’t sound too hard… why was I having such a difficult time envisioning the code?
talk-to-someone

After exclaiming to my friend Cory that my brain was about to explode, I dove in to a very high level description of the problem. When a parent node goes in to an error state, I have to mark all the children as unresolvable… but I’m looking at an array of items where each item knows about it’s parents.

30 seconds in to the conversation, Cory asked me a question.

5 lines of code later, I had a working solution and it was brilliant!

Perspective

The truth is that I already had everything I needed – everything, except for the right perspective on the problem. I wasn’t looking at things from the right angle.

I had this preconceived notion that I had to start from the bottom of the tree structure I was dealing with. All Cory did was ask me if I knew which node was going in to an error state, at the moment it went in to error. Yes, of course I did – I was marking it as error. So, can’t I just travel down from there? Well, no… I … have already pre-computed the child nodes in a previous iteration! YES! I can travel down the tree from there!

It’s a problem that we often face in many different contexts. We have an idea that guides us toward a solution to a problem, and we get fixated on that idea. Or we have a problem that seems to twist itself in circles with no way out. But the moment we explain the situation to someone else, the solution suddenly becomes obvious.

That subtle shift in perspective when we have to explain a few extra details, when that person asks an “obvious” question, or when we just say the words out loud and they suddenly don’t make sense… forcing yourself to turn your implicit knowledge of a situation in to an explicit statement can be a very powerful thing, indeed.

Let The Anti-Social Be Social (Occasionally)

I’m not a people person, quite honestly. I don’t always want to be alone, but I rarely want to be the center of attention or in a big crowd. I’m definitely on the shy scale, and the awkward side of things in real life. I put on a good show, sometimes, but not always.

When I talk about the importance of talking, then, it shouldn’t be taken lightly.

This is advice that comes from years of experience in sitting around, pulling my hair out, trying to solve something and having the solution become perfectly obvious the moment I begin talking about it. This is such a regular occurrence for me, that I can’t imagine not having someone to talk to on a regular basis. It doesn’t have to be every day (and frankly, I don’t want it to be every day). But a couple of days a week, for me, is critical.

I Need That Conversation

That one conversation, that small spark of perspective change, that moment of being forced to explain something in new terms… that’s the reason I go in to my client’s office twice a week, and the reason Cory and I go to a coffee shop every Wednesday.

Don’t underestimate the value of other people’s perspectives… or the value of you being willing to listen to someone else and ask “obvious” questions. You may find yourself on the giving end of that spark of genius, if you only let yourself be available.

– Derick

Categories: Blogs

Zeit für eine neue Meeting-Kultur

Scrum 4 You - Wed, 01/28/2015 - 08:27

Meetings haben ihren guten Ruf verloren. Vorbei die Zeiten, in denen ein gut gefüllter Terminkalender Indikator für Produktivität war. Heute sind Meetings gleichbedeutend mit langweiligen Diskussionsrunden, in denen alles getroffen wird – außer Entscheidungen. Dabei sind Meetings im Grunde völlig in Ordnung – seit Urzeiten kommen Menschen in Familie, Gesellschaft und Wirtschaft zusammen, wenn es darum geht, die wichtigen Dinge im Leben zu besprechen. Es wird immer irgendeine Form von Meetings geben – die Frage ist nur, wie diese sinnvoll gelebt werden können. Hier ein paar Tipps & Tricks für eine neue Meeting-Kultur.

Alle Hände voll zu tun

Oft sind Meetings wie gute Vorsätze für das neue Jahr: Es ist leicht, sie zu fassen, aber verdammt schwer, sie konsequent umzusetzen. Deshalb ist unbedingt darauf zu achten, dass alle Meetings mit einem klaren Nutzen ausgehen, indem am Ende Maßnahmen, Vereinbarungen, Commitments konkretisiert werden. Mehr noch: Anstatt die Maßnahmen bloß zu benennen, warum diese nicht gleich umsetzen?

Tipp: Sobald in einem Meeting klar wird, dass etwas Konkretes zu tun ist – jemand muss hinzugezogen, eine Information eingeholt werden – handeln Sie sofort. Rufen Sie die Person noch während des Meetings an (bitte mit Freisprechfunktion, damit alle teilnehmen können), lassen Sie die Information vor aller Augen recherchieren, legen Sie Prototypen und Wireframes zur sofortigen Begutachtung aus. Wählen Sie einen Raum, der nicht mit Tischen und Stühlen zugestellt ist, so dass die Teilnehmer frei interagieren können. Sie werden sehen, wie das die Teilnehmer vom Raum der Möglichkeiten in den Raum der Handlungen bringt. So wird die Unterscheidung zwischen Meeting und der eigentlichen Arbeit immer irrelevanter.

Unrentable Meetings abschaffen

Wer ein Meeting einberuft, raubt den Teilnehmern Arbeits- und Lebenszeit. Das sollte nie leichtfertig geschehen und in jedem Fall gut begründet sein. Am Ende jedes Meetings ist zu überprüfen, ob die Zeit sinnvoll investiert wurde. Und ein Meeting sollte grundsätzlich nie länger als 90 Minuten dauern – es gibt genügend Studien, die zeigen, dass danach die Aufmerksamkeit der Teilnehmer den Bach hinuntergeht.

Tipp: Bitten Sie die Teilnehmer darum, vor Verlassen des Meetings ihren Return on Time Invested zu visualisieren. Zeichnen Sie dafür eine Skala von 0 (= kein Return on Time Invested) bis 5 (= sehr hoher Return on Time Invested) auf einem Flipchart und hängen Sie diese neben den Ausgang. Drücken Sie jedem Teilnehmer ein Post-It oder ein Voting Dot in die Hand, und bitte Sie die Teilnehmer, damit einen Punkt auf der Skala zu markieren. Nutzen Sie das Feedback, um sich beim nächsten Mal zu überlegen, ob das Meeting in dieser Form wirklich nötig ist.

Zeitfetischismus zahlt sich aus

Wenn ich ein Meeting für eine Stunde anberaume, dann prüfe ich nach spätestens 30 Minuten, ob wir es beenden können. Häufig ist das der Fall, denn bei einer klar definierten Agenda und Vorbereitung der Teilnehmer entsteht ein guter Kommunikationsfluss, der sich nur an wenigen, kritischen Stellen aufhält. Verharrt das Meeting hingegen in langwierigen Argumentationsrunden ohne Entscheidungen, dann wird auch die ursprünglich anberaumte Zeit nicht ausreichen – eine Unterbrechung ist dann erst recht sinnvoll, um zu einem späteren Zeitpunkt in anderer Konstellation wieder zusammenzukommen.

Tipp: Fragen Sie zur Halbzeit eines Meetings (also nach 30 Minuten bei einem einstündigen Meeting), ob eine Verlängerung erforderlich ist. Wenn ja, verlängern Sie das Meeting um die Hälfte der bereits abgelaufenen Zeit (in diesem Fall um 15 Minuten). Fragen Sie nach Ablauf dieser Zeit erneut, ob eine Verlängerung erforderlich ist. Falls ja, verlängern Sie noch einmal, teilen Sie dabei aber die verlängerte Zeit wiederum um die Hälfte (hier um 7.5 Minuten). Und so weiter. Sie werden sehen, wie die Teilnehmer von Meeting zu Meeting immer zeitbewusster werden und genau abwägen, ob eine Verlängerung erforderlich ist.

Freiwilligkeit – mit allen Konsequenzen

Menschen, die fragen, ob sie an dem Meeting teilnehmen müssen, haben meist Besseres zu tun. Es ist für mich eine Frage des Respekts, andere zu Meetings tatsächlich einzuladen (und nicht mit Pflichtfeldern einzuberufen). In jedem Meeting sollte daher das Gesetz der zwei Füße gelten:

“Wenn Sie in einer Gruppe nichts mehr lernen oder beitragen können, dann dürfen Sie gehen. Ehren Sie die Gruppe durch ihre Ehrlichkeit und suchen Sie sich neue Aufgaben, denn Sie bestimmen alleine wo, wie und wie lange Sie sich beteiligen. Lassen Sie sich von Ihren Füßen leiten. Gehen Sie dahin, wo Sie Ihre Energie und Aufmerksamkeit einbringen wollen, nur dort werden Sie produktiv sein. Dies ist ein Gesetz: Es ist mehr als nur erlaubt, es ist vorgeschrieben.” (Harrison Owen – User’s Guide to Open Space Technology)

Tipp: Machen Sie Ihrem Mitarbeitern klar, dass ab sofort kein Meeting mehr verpflichtend besucht werden muss. Denn es ist die Verantwortung jedes einzelnen zu entscheiden, wie die eigene Zeit am produktivsten einzusetzen ist. Machen Sie aber auch klar, dass die Entscheidungen der Anwesenden von den Nichtanwesenden mitzutragen sind.

Es ist Zeit, Meetings wieder produktiv und spannend zu machen. Die hier genannten Tipps sind leichter umzusetzen, als Sie vielleicht denken. Allerdings lohnt es sich, dafür eine dedizierte Rolle – die des Moderators – einzusetzen. Dieser sollte durchaus Ahnung von der Materie haben und in der Lage sein, die Diskussion etwa um gute Fragen zu bereichern. Vor allem aber sollte er oder sie in der Lage sein, Meetings so zu führen, dass Entscheidungen getroffen und am besten gleich umgesetzt werden können.

fuesse

Categories: Blogs

Blue Agility Partners With Rally on Scaled Agile Adoption

Scrum Expert - Tue, 01/27/2015 - 23:11
Blue Agility has announced a partnership with Rally. This cooperation aims to team the market-leading strengths of each company in helping enterprise-level organizations adopt and scale Agile software development initiatives in an efficient and successful manner. Together, Blue Agility and Rally will address the challenges inherent in scaling Agile to larger, enterprise-wide implementations. This includes enabling the creation, management and execution of development plans, providing the capabilities for the capture and transfer of knowledge, implementing best practices and processes, strengthening existing training and coaching services, and achieving long-term sustainability. This partnership ...
Categories: Communities

VersionOne Announces Winter Release

Scrum Expert - Tue, 01/27/2015 - 23:00
VersionOne has announced its 2015 Winter Release, which includes Strategic Themes aligned with SAFE, Epic Timeline Drilldown, Forecasting with Monte Carlo Simulation, and more. These new capabilities make scaling agile initiatives easier by enabling project and portfolio managers to view, prioritize, forecast and align projects from the highest business initiatives to execution. The new VersionOne capabilities improve business alignment and agility to adapt to evolving plans and priorities: * Strategic Themes: Ability to group and view all items that fall within a particular strategic theme, enabling product owners to easily prioritize and ...
Categories: Communities

Knowledge Sharing


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