Skip to content

Feed aggregator

5 minutes on scaling: Hangout & Co

Scrum 4 You - Mon, 08/18/2014 - 07:40

Natürlich nutzen wir mittlerweile neben den physischen Taskboards auch JIRA und Co. Doch jedes Mal, wenn ich diese Tools nutze, gehen mir ihre Unzulänglichkeiten auf den Geist. Sie lösen im skalierten Umfeld das eigentliche Problem nicht: Sie helfen nicht, die Kommunikation zwischen den Scrum-Teammitgliedern einer weltweit aufgestellten Organisation zu vereinfachen. Vielmehr sind sie zu Datenbanken, Reporting Tools, perfektionierten Bug Tracking Tools und Forecast Push Systemen degeneriert. Selbst bieten diese Wesen keinen Mehrwert – sie müssen sich der Lebenszeit von Entwicklern und Managern bedienen, um am Leben zu bleiben.

Dabei wäre es so einfach, ein wirklich funktionierendes, agiles Scrum-Tool zu entwickeln. Eines nämlich, das Arbeit beschleunigt und Kommunikation erleichtert, statt zu einer Belastung zu werden. Dazu bräuchte es nur ein paar Entwickler, die nach folgendem Rezept das perfekte Scrum-Tool bauen:

  1. Man nehme ein wirklich funktionierendes, d.h. stabiles Video Conferencing System wie zum Beispiel Google Hangout und verpasse ihm eine bessere Usability – sorry liebe Googles, das geht besser!
  2. Man füge eine Prise Telefoneinwahl international und kostenfrei hinzu – für die Teammitglieder, die während des Daily Scrums unterwegs sind (sorry, noch ist WLAN oder LTE auf deutschen Autobahnen und im ICE zu instabil – vor allem bei Hochgeschwindigkeitsfahrten).
  3. Dann mische man ein Whiteboard, eine Desksharing-Funktionalität, einen Persistent Chat und ein Taskboard hinzu.
  4. Nun braucht man noch die Möglichkeit, Texte auffindbar zu erstellen, die u.a. aber nicht nur an den Stories hängen. Deshalb integrieren wir ein Wiki, das sich aber bitte so wie ein Google Docs verhält.
  5. Für große Mengen an Bildern und Dokumenten brauchen wir noch Dropbox oder Evernote.
  6. Als Dessert nehmen wir noch einen integrierten Kalender, ein Shared Adressbook und eine E-Mail-Funktionalität.

Fertig. Alle zu Tisch, so kann man international arbeiten.

Ach so: Die Reporting-Funktionalitäten fürs Management lassen wir weg.
Fortschritte zeigen wir, indem wir fertige Produkte liefern – wir zeigen es nicht durch abgearbeitete Stories oder Tasks. Das ginge ja, wenn wir das Video-Chat-Programm so ausweiten könnten, dass wir ohne Probleme Demos auch für nicht Firmenmitglieder abhalten könnten.

Naja, ich träume. Aber ganz ehrlich, wir brauchen solche Tools. Die Entwicklung in der postindustriellen Netzwerkgesellschaft geht hin zu mehr Remote-Arbeit (work were you are), denn Teams kaufen sich die Kollegen dort ein, wo sie eben wohnen. Einer meiner Bekannten wohnt in St. Pölten (Niederösterreich) und arbeitet täglich für ein kalifornisches Unternehmen als Entwickler – warum auch nicht. Softwareentwicklungs-Teams können das heute. Andere Firmen werden folgen.

Wir müssen das möglich machen. Die Teams eines unserer Kunden arbeiten an zwei Orten in den USA, in China, in Indien und in München. Wir brauchen die Infrastruktur, um sie miteinander arbeiten zu lassen – und zwar produktiv. Und nein: Menschen zu einem Umzug oder hunderttausenden Flugmeilen mehr zu zwingen, ist keine wirkliche Alternative – weder steuertechnisch noch aus Sicht der Produktivität. Wissensarbeit braucht den Austausch, das miteinander Denken. Das geht in der Business Class des A380 nicht, da hilft auch die überfüllte Senatoren Lounge nichts mehr. Das ist nichts anderes als verlorene Lebenszeit.

Verteiltes, skaliertes und mulitkulturelles, grenzüberschreitendes Arbeiten wird zum Alltag werden. Kleine, schlanke Firmen werden das mit einer Symbiose aus den günstigen Lösungen wie Google HO, Confluence, Evernote und Dropbox stemmen. Große, unbewegliche Konzerne werden folgen – und dafür teure Enterprise Tools einkaufen. Vor allem müssen wir es schaffen, auch den multikulturellen Aspekt zu berücksichtigen. Schweizer, Österreicher und Deutsche – wir sprechen eine Sprache und meinen etwas völlig anderes. Ein elektronisches Board, dessen Sichtbarkeit auf die Größe eines Monitors beschränkt ist, muss also etwas anderes können, als beim Verschieben der Tasks die Farbe zu wechseln.

Related posts:

  1. 5 min on Scrum Tools
  2. Scrum Tools | VersionOne
  3. 5 min on Scrum | Tools

Categories: Blogs

Agile Executive Playbook

Imagine that you are an executive of a company (and quite possibly some of you reading this are or have a direct line to an executive).  You’ve heard about this thing called Agile and some of you have experienced it.  However, Agile is still a bit confusing because in many cases, it appears to be occurring only at the development team level.  Some of you believe that Agile is a set of practices and tools and may be surprised to know that it is nothing-more-and-nothing-less than a set of values and principles.   Maybe some of you haven’t seen the connection between applying Agile and gaining the business benefits.  What exactly is your role and responsibilities in moving your company toward Agile?  Here is some guidance on what your responsibilities should be and what may increase your chances in deriving the business benefits of Agile. 
Strategic Shifts           The key responsibility for the executive within the organizational scope is to become the sponsor of the Agile initiative.  This highlights to the employees that Agile is important and increases the chances of buy-in.  But simply proclaiming “make it so” isn’t sufficient.  The executive must continue to be a key player in this on-going sponsor role.  Here are strategic shifts that are beneficial:
  • Study the Agile values and principles.  Knowing this language helps you become more conversant in Agile and to the teams and organizational players that are involved.  Studying the values and principles will also help you ascertain if you really believe in them (or not). 
  • Move away from the iron triangle of schedule, cost or scope and move to a framework focused on value.  Prioritizing ideas via cost of delay will provide a much better value-driven pipeline of ideas.  These ideas can be decomposed into increments that can then be validated with fast feedback loops. 
  • Measure and adapt the flow of your end-to-end concept to cash pipeline.  There is a tendency to focus on just development, but it is often other parts of the pipeline where ideas wait much too long.  Consider value stream mapping to better understand waiting states and no or low value steps. 
  • Adapt the organization from a hierarchical organization to more of a self-organizing organization.  When employees feel that they have more ownership and decision-making of their work, they will apply much more brainpower and bring passion to their work.
Key Sponsor Activities
Now let’s take a look at the more in-depth activities that you as an executive should consider playing and why.  These are more tactical, but since becoming Agile doesn’t happen overnight, they help keep the engagement and interest along the way. 
  • Treat your Agile initiative as a journey.  Because this does take time, it would benefit you to build an adaptable roadmap.  This may be best handled with a small local team of Agile champions who are committed to adopting Agile and an Agile consultant who has experience in this area.  To get a good understanding of what an Agile roadmap may look like, consider reading the book Being Agile: Your Roadmap to Successful Adoption of Agile.
  • Build a learning culture.  Consider establishing an education vision on how to best educate your organization. Infuse the education with experiments and experience. I suggest starting with the Value, Flow, and Quality materials that provide the reader with great insight into many of these new concepts and ideas, along with case studies and activities.
  • As an executive, examine your own behavior and align it with the Agile mindset of Agile values and principles with a focus of delivering customer value.  Are you speaking the language of Agile and the strategic shift that you are looking to achieve? 
  • Provide funding for the Agile initiative.  Funding should include meeting education needs, bringing in talent (coaches) as needed, and providing tool support. This may occur incrementally or per the budget cycle.  
  • Periodically provide public support for Agile. Establish an Agile communication plan, of which portions can be executed over time to keep employees aware of the progress and accomplishments of the deployment.  This may also include providing 'air cover' to the Agile deployment team and the coaches and champions and mitigating the risks that could prevent a move to Agile.  
  • Consider your staff.  Ask yourself, “are they Agile minded and aligned with the cultural shift that is needed?”  You may need to be involved with making adjustments to staff members who cannot make the switch away from command-and-control. This can be hard to do, but if they don't, then those around them will not take the change seriously.
  • Learn how to read agile metrics and measures of success. Gaining an understanding of the lagging to leading metric path, sprint burn-downs, release burn-ups, value capture, release frequency, Agile Mindset, Values, and Principles (MVP) Advisor, and other Agile-related metrics can help ensure the organization is moving in the right direction.
  • Adapt the employee compensation model toward agile behaviors being sought and away from rewarding command-and-control attributes. To change behavior, recognize the behavior you want to change, evaluate the reward system, and adapt it to the behavior that is needed for Agile. Without aligning the reward system to Agile, you will not get to behavior you want.
  • Attend the Sprint Reviews of your top products within your organizational scope. This will give you a genuine sense of progress and see actual working functionality of your products.
The intent of this article is to provide highlights of what an executive can do to get the most business benefits from their Agile initiative.  There can be other perspectives and further details.  As an executive (or those who have supported executives), what have you found helpful in your Agile journey?
Categories: Blogs

Ruby: Create and share Google Drive Spreadsheet

Mark Needham - Sun, 08/17/2014 - 23:42

Over the weekend I’ve been trying to write some code to help me create and share a Google Drive spreadsheet and for the first bit I started out with the Google Drive gem.

This worked reasonably well but that gem doesn’t have an API for changing the permissions on a document so I ended up using the google-api-client gem for that bit.

This tutorial provides a good quick start for getting up and running but it still has a manual step to copy/paste the ‘OAuth token’ which I wanted to get rid of.

The first step is to create a project via the Google Developers Console. Once the project is created, click through to it and then click on ‘credentials’ on the left menu. Click on the “Create new Client ID” button to create the project credentials.

You should see something like this on the right hand side of the screen:

2014 08 17 16 29 39

These are the credentials that we’ll use in our code.

Since I now have two libraries I need to satisfy the OAuth credentials for both, preferably without getting the user to go through the process twice.

After a bit of trial and error I realised that it was easier to get the google-api-client to handle authentication and just pass in the token to the google-drive code.

I wrote the following code using Sinatra to handle the OAuth authorisation with Google:

require 'sinatra'
require 'json'
require "google_drive"
require 'google/api_client'
 
CLIENT_ID = 'my client id'
CLIENT_SECRET = 'my client secret'
OAUTH_SCOPE = 'https://www.googleapis.com/auth/drive https://docs.google.com/feeds/ https://docs.googleusercontent.com/ https://spreadsheets.google.com/feeds/'
REDIRECT_URI = 'http://localhost:9393/oauth2callback'
 
helpers do
  def partial (template, locals = {})
    haml(template, :layout => false, :locals => locals)
  end
end
 
enable :sessions
 
get '/' do
  haml :index
end
 
configure do
  google_client = Google::APIClient.new
  google_client.authorization.client_id = CLIENT_ID
  google_client.authorization.client_secret = CLIENT_SECRET
  google_client.authorization.scope = OAUTH_SCOPE
  google_client.authorization.redirect_uri = REDIRECT_URI
 
  set :google_client, google_client
  set :google_client_driver, google_client.discovered_api('drive', 'v2')
end
 
 
post '/login/' do
  client = settings.google_client
  redirect client.authorization.authorization_uri
end
 
get '/oauth2callback' do
  authorization_code = params['code']
 
  client = settings.google_client
  client.authorization.code = authorization_code
  client.authorization.fetch_access_token!
 
  oauth_token = client.authorization.access_token
 
  session[:oauth_token] = oauth_token
 
  redirect '/'
end

And this is the code for the index page:

%html
  %head
    %title Google Docs Spreadsheet
  %body
    .container
      %h2
        Create Google Docs Spreadsheet
 
      %div
        - unless session['oauth_token']
          %form{:name => "spreadsheet", :id => "spreadsheet", :action => "/login/", :method => "post", :enctype => "text/plain"}
            %input{:type => "submit", :value => "Authorise Google Account", :class => "button"}
        - else
          %form{:name => "spreadsheet", :id => "spreadsheet", :action => "/spreadsheet/", :method => "post", :enctype => "text/plain"}
            %input{:type => "submit", :value => "Create Spreadsheet", :class => "button"}

We initialise the Google API client inside the ‘configure’ block before each request gets handled and then from ‘/’ the user can click a button which does a POST request to ‘/login/’.

‘/login/’ redirects us to the OAuth authorisation URI where we select the Google account we want to use and login if necessary. We’ll then get redirected back to ‘/oauth2callback’ where we extract the authorisation code and then get an authorisation token.

We’ll store that token in the session so that we can use it later on.

Now we need to create the spreadsheet and share that document with someone else:

post '/spreadsheet/' do
  client = settings.google_client
  if session[:oauth_token]
    client.authorization.access_token = session[:oauth_token]
  end
 
  google_drive_session = GoogleDrive.login_with_oauth(session[:oauth_token])
 
  spreadsheet = google_drive_session.create_spreadsheet(title = "foobar")
  ws = spreadsheet.worksheets[0]
 
  ws[2, 1] = "foo"
  ws[2, 2] = "bar"
  ws.save()
 
  file_id = ws.worksheet_feed_url.split("/")[-4]
 
  drive = settings.google_client_driver
 
  new_permission = drive.permissions.insert.request_schema.new({
      'value' => "some_other_email@gmail.com",
      'type' => "user",
      'role' => "reader"
  })
 
  result = client.execute(
    :api_method => drive.permissions.insert,
    :body_object => new_permission,
    :parameters => { 'fileId' => file_id })
 
  if result.status == 200
    p result.data
  else
    puts "An error occurred: #{result.data['error']['message']}"
  end
 
  "spreadsheet created and shared"
end

Here we create a spreadsheet with some arbitrary values using the google-drive gem before granting permission to a different email address than the one which owns it. I’ve given that other user read permission on the document.

One other thing to keep in mind is which ‘scopes’ the OAuth authentication is for. If you authenticate for one URI and then try to do something against another one you’ll get a ‘Token invalid – AuthSub token has wrong scope‘ error.

Categories: Blogs

Little's Law in 3D

Xebia Blog - Sun, 08/17/2014 - 17:21

The much used relation between average cycle time, average total work and input rate (or throughput) is known as Little's Law. It is often used to argue that it is a good thing to work on less items at the same time (as a team or as an individual) and thus lowering the average cycle time. In this blog I will discuss the less known generalisation of Little's Law giving an almost unlimited number of additional relation. The only limit is your imagination.

I will show relations for the average 'Total Operational Cost in the system' and for the average 'Just-in-Timeness'.

First I will describe some rather straightforward generalisations and in the third part some more complex variations on Little's Law.

Little's Law Variations

As I showed in the previous blogs (Applying Little's Law in Agile Games and Why Little's Law Works...Always) Little's Law in fact states that measuring the total area from left-to-right equals summing it from top-to-bottom.

Once we realise this, it is easy to see some straightforward generalisations which are well-known. I'll mention them here briefly without ging into too much details.

Subsystem

new doc 8_1 Suppose a system that consists of 1 or more subsystems, e.g. in a kanban system consisting of 3 columns we can identify the subsystems corresponding to:

  1. first column (e.g. 'New') in 'red',
  2. second column (e.g. 'Doing') in 'yellow',
  3. third column (e.g. 'Done') in 'green'

See the figure on the right.

By colouring the subsystems different from each other we see immediately that Little's Law applies to the system as a whole as well as to every subsystem ('red' and 'yellow' area).

Note: for the average input rate consider only the rows that have the corresponding color, i.e. for the input rate of the column 'Doing' consider only the rows that have a yellow color; in this case the average input rate equals 8/3 items per round (entering the 'Doing' column). Likewise for the 'New' column.

Work Item Type

new doc 9_1Until now I assumed only 1 type of work items. In practise teams deal with more than one different work item types. Examples include class of service lanes, user stories, and production incidents. Again, by colouring the various work item type differently we see that Little's Law applies to each individual work item type.

In the example on the right, we have coloured user stories ('yellow') and production incidents ('red'). Again, Little's Law applies to both the red and yellow areas separately.

Doing the math we se that for 'user stories' (yellow area):

  • Average number in the system (N) = (6+5+4)/3 = 5 user stories,
  • Average input rate (\lambda\lambda = 6/3 = 2 user stories per round,
  • Average waiting time (W) = (3+3+3+3+2+1)/6 = 15/6 = 5/2 rounds.

As expected, the average number in the system equals the average input rate times the average waiting time.

The same calculation can be made for the production incidents which I leave as an exercise to the reader.

Expedite Items

new doc 10_1 Finally, consider items that enter and spend time in an 'expedite' lane. In Kanban an expedite lane is used for items that need special priority. Usually the policy for handling such items are that (a) there can be at most 1 such item in the system at any time, (b) the team stop working on anything but on this item so that it is completed as fast as possible, (c) they have priority over anything else, and (d) they may violate any WiP limits.

Colouring any work items blue that spend time in the expedite lane we can apply Little's Law to the expedite lane as well.

An example of the colouring is shown in the figure on the right. I leave the calculation to the reader.

3D


We can even further extend Little's Law. Until now I have considered only 'flat' areas.

The extension is that we can give each cell a certain height. See the figure to the right. A variation on Little's Law follows once we realise that measuring the volume from left-to-right is the same as calculating it from top-to-bottom. Instead of measuring areas we measure volumes instead.

The only catch here is that in order to write down Little's Law we need to give a sensible interpretation to the 'horizontal' sum of the numbers and a sensible interpretation to the 'vertical' sum of the numbers. In case of a height of '1' these are just 'Waiting Time' (W) and 'Number of items in the system' (N) respectively.

A more detailed, precise, and mathematical formulation can be found in the paper by Little himself: see section 3.2 in [Lit11].

Some Applications of 3D-Little's Law

Value

As a warming-up exercise consider as the height the (business) value of an item. Call this value 'V'. Every work item will have its own specific value.
new doc 12_1

 

 

 \overline{\mathrm{Value}} = \lambda \overline{V W} \overline{\mathrm{Value}} = \lambda \overline{V W}

The interpretation of this relation is that the 'average (business) value of unfinished work in the system at any time' is equal to the average input rate multiplied by the 'average of the product of cycle time and value'.

Teams may ant to minimise this while at the same time maximising the value output rate.

Total Operational Cost

As the next example let's take as the height for the cells a sequence of numbers 1, 2, 3, .... An example is shown in the figures below. What are the interpretations in this case?

Suppose we have a work item that has an operational cost of 1 per day. Then the sequence 1, 2, 3, ... gives the total cost to date. At day 3, the total cost is 3 times 1 which is the third number in the sequence.

new doc 12_2The 'vertical' sum is just the 'Total Cost of unfinished work in the system.

For the interpretation of the 'horizontal' sum we need to add the numbers. For a work item that is in the system for 'n' days, the total is 1+2+3+...+n1+2+3+...+n which equals 1/2 n (n+1)1/2 n (n+1). For 3 days this gives 1+2+3=1/2 * 3 * 4 = 61+2+3=1/2 * 3 * 4 = 6. Thus, the interpretation of the 'horizontal' sum is 1/2 W (W+1)1/2 W (W+1) in which 'W' represents the waiting time of the item.

Putting this together gives an additional Little's Law of the form:

 \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W(W + 1)} \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W(W + 1)}

where 'C' is the operational cost rate of a work item and \lambda\lambda is the (average) input rate. If instead of rounds in a game, the 'Total Cost in the system' is measured at a time interval 'T' the formula slightly changes into

 \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W\left(W + T\right)} \overline{\mathrm{Cost}} = \frac{1}{2} \lambda C \overline{W\left(W + T\right)}

Teams may want to minimise this which gives an interesting optimisation problem is different work item types have different associated operational cost rates. How should the capacity of the be divided over the work items? This is a topic for another blog.

Just-in-Time

For a slightly more odd relation consider items that have a deadline associated with them. Denote the date and time of the deadline by 'D'. As the height choose the number of time units before or after the deadline the item is completed. Further, call 'T' the time that the team has taken up to work on the item. Then the team finishes work on this item at time  T + W T + W , where 'W' represent the cycle time of the work item.

new doc 12_4

In the picture on the left a work item is shown that is finished 2 days before the deadline. Notice that the height decreases as the deadline is approached. Since it is finished 2 time units before the deadline, the just-in-timeness is 2 at the completion time.

new doc 12_3

The picture on the left shows a work item one time unit after the deadline and has an associated just-in-timeness of 1.

 

 \overline{\mathrm{Just-in-Time}} = \frac{1}{2} \lambda \overline{|T+W-D|(|T+W-D| + 1)} \overline{\mathrm{Just-in-Time}} = \frac{1}{2} \lambda \overline{|T+W-D|(|T+W-D| + 1)}

This example sounds like a very exotic one and not very useful. A team might want to look at what the best time is to start working on an item so as to minimise the above variable.

Conclusion

From our 'playing around' with the size of areas and volumes and realising that counting it in different ways (left-to-right and top-to-bottom) should give the same result I have been able to derive a new set of relations.

In this blog I have rederived well-known variations on Little's Law regarding subsystems and work items types. In addition I have derived new relations for the 'Average Total Operational Cost', 'Average Value', and 'Average Just-in-Timeness'.

Together with the familiar Little's Law these give rise to interesting optimisation problems and may lead to practical guidelines for teams to create even more value.

I'm curious to hear about the variations that you can come up with! Let me know by posting them here.

References

[Lit11] John D.C. Little, "Little’s Law as Viewed on Its 50th Anniversary", 2011, Operations Research, Vol. 59 , No 3, pp. 536-549, https://www.informs.org/content/download/255808/2414681/file/little_paper.pdf

 

 

Categories: Companies

Ruby: Receive JSON in request body

Mark Needham - Sun, 08/17/2014 - 14:21

I’ve been building a little Sinatra app to play around with the Google Drive API and one thing I struggled with was processing JSON posted in the request body.

I came across a few posts which suggested that the request body would be available as params['data'] or request['data'] but after trying several ways of sending a POST request that doesn’t seem to be the case.

I eventually came across this StackOverflow post which shows how to do it:

require 'sinatra'
require 'json'
 
post '/somewhere/' do
  request.body.rewind
  request_payload = JSON.parse request.body.read
 
  p request_payload
 
  "win"
end

I can then POST to that endpoint and see the JSON printed back on the console:

dummy.json

{"i": "am json"}
$ curl -H "Content-Type: application/json" -XPOST http://localhost:9393/somewhere/ -d @dummy.json
{"i"=>"am json"}

Of course if I’d just RTFM I could have found this out much more quickly!

Categories: Blogs

Ruby: Google Drive – Error=BadAuthentication (GoogleDrive::AuthenticationError) Info=InvalidSecondFactor

Mark Needham - Sun, 08/17/2014 - 03:49

I’ve been using the Google Drive gem to try and interact with my Google Drive account and almost immediately ran into problems trying to login.

I started out with the following code:

require "rubygems"
require "google_drive"
 
session = GoogleDrive.login("me@mydomain.com", "mypassword")

I’ll move it to use OAuth when I put it into my application but for spiking this approach works. Unfortunately I got the following error when running the script:

/Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive/session.rb:93:in `rescue in login': Authentication failed for me@mydomain.com: Response code 403 for post https://www.google.com/accounts/ClientLogin: Error=BadAuthentication (GoogleDrive::AuthenticationError)
Info=InvalidSecondFactor
	from /Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive/session.rb:86:in `login'
	from /Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive/session.rb:38:in `login'
	from /Users/markneedham/.rbenv/versions/1.9.3-p327/lib/ruby/gems/1.9.1/gems/google_drive-0.3.10/lib/google_drive.rb:18:in `login'
	from src/gdoc.rb:15:in `<main>'

Since I have two factor authentication enabled on my account it turns out that I need to create an app password to login:

2014 08 17 02 47 03

It will then pop up with a password that we can use to login (I have revoked this one!):

2014 08 17 02 46 29

We can then use this password instead and everything works fine:

 
require "rubygems"
require "google_drive"
 
session = GoogleDrive.login("me@mydomain.com", "tuceuttkvxbvrblf")
Categories: Blogs

The Product Wall Release Workshop

BigVisible Solutions :: An Agile Company - Fri, 08/15/2014 - 17:01

Multi-team Release Planning, as it is often executed, fails to bring alignment beyond one-time, inter-team coordination. When the “Chief Product Owner” arrives with just descriptions of features, the teams don’t learn the connection between features and value. The Product Wall Release Workshop brings together all the elements of business needs, user experience, value proposition, dependency […]

The post The Product Wall Release Workshop appeared first on BigVisible Solutions.

Categories: Companies

Z is for Zukunftstag (#AgileFutureDay)

Scrum Breakfast - Fri, 08/15/2014 - 15:52
Agile is changing the world, but our schools are still preparing kids for the way world used to be. Would you like your kids to learn the ways of the future?

Thursday, November 13, 2014 is "Future Day" in Switzerland. Originally conceived as "Daughter's Day" to encourage fathers to take their daughters to work to experience non-traditional jobs for women,  it is now an annual opportunity for kids, usually in the 6th grade to get a day off from school so they can experience their parents at work and get a first taste of the real world.

My oldest attended one of my courses a few years ago (her insights were stunning, says the proud father) and this year, I will invite my youngest to attend.

Wouldn't it be cool if kids everywhere got a chance to experience the world of work, the way it should be? I'd like to call on trainers everywhere to invite the middle school aged children of their participants to join in their Agile, Lean or Scrum trainings on November 13th! Would that be cool? They can learn what collaboration can be! Let's make November 13th #AgileFutureDay!

P.S. I've got four spaces for kids on Future Day in my CSM course. No charge ;-)


Categories: Blogs

Leading SAFe 8.0 Course is Now Available

Agile Product Owner - Fri, 08/15/2014 - 15:04

We’ve just announced Leading SAFe 8.0, based on SAFe Version 3.0. It has a new pedagogy which goes faster and deeper into more advanced scaling topics, and is also more experiential. If you are new to SAFe, you can attend a class offered by our partners at locations worldwide, see Scaledagilepartners.com/events/.

If you are an SPC, you can find a webinar we recorded at the Scaled Agile Academy members area. For those applying SAFe, or if you simply want to learn more, think about becoming  a SAFe Program Consultant, and join a community of 1,000+ others implementing SAFe, and sharing their experience in our SPC forums. Classes are held frequently and worldwide, which you can see at Scaled Agile Academy.

 

Categories: Blogs

It is not the Process, Stupid

Leading Answers - Mike Griffiths - Fri, 08/15/2014 - 06:03
Even though Mickey Mouse is the symbol of Disney theme parks he is not really what these locations are about. Agile methods are similarly known by their novel processes and team ceremonies but these are largely irrelevant distractions from the... Mike Griffiths
Categories: Blogs

Posting Update

Leading Answers - Mike Griffiths - Fri, 08/15/2014 - 05:58
Thank you for visiting my site or subscribing to this feed. Regardless of how you access this content thanks for your patience. I have not been writing recently, instead using my spare time to enjoy the great summer weather we... Mike Griffiths
Categories: Blogs

An Appetite for Change

Practical Agility - Dave Rooney - Fri, 08/15/2014 - 05:19
I've been part of a discussion on Twitter about the vices of imposed Agile adoptions versus the virtues of the approach put forth by Daniel Mezick, OpenAgile Adoption. Regardless of the arguments for or against each approach, creating this dichotomy misses the point. In May 2012, organizational change consultant Maureen Cunningham gave a talk at Agile Ottawa about Change. She used a number of
Categories: Blogs

The Agile Reader – Weekend Edition: 08/15/2014

Scrumology.com - Kane Mar - Fri, 08/15/2014 - 04:20

You can get the Weekend Edition delivered directly to you via email by signing up here.

The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.

  • Accenture #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Gurgaon) #Jobs #TweetMyJobs
  • #Hyderabad #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • #TweetMyJobs #WebDesign #Job alert: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) | Accenture | #Pune #Jobs
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) – Accenture: (#Mumbai) #WebDesign #Job #Jobs #TweetMyJobs
  • #NewDelhi #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) – Accenture: (#Gurgaon) #WebDesign #Job #Jobs #TweetMyJobs
  • Accenture #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Pune) #Jobs #TweetMyJobs
  • Accenture #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Mumbai) #Jobs #TweetMyJobs
  • #WebDesign #Job in #Bangalore: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • Did you know that members get access to premium content and exclusive site features #agile #scrum
  • Accenture: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Chennai) #WebDesign #Job #Jobs #TweetMyJobs
  • RT @AgileKarma: 10 reasons why in #scrum sprint length is never extended #agile
  • #WebDesign #Job in #NewDelhi: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) – Accenture: (#Chennai) #WebDesign #Job #Jobs #TweetMyJobs
  • #Mumbai #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • Professional Agile and Scrum Certification – via @delicious
  • Accenture #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Gurgaon) #Jobs #TweetMyJobs
  • #Bangalore #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • Professional Agile and Scrum Certification Course – via @delicious
  • #WebDesign #Job in #Noida: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • HARD COPY: Scrum Mega Pack #scrum #agile
  • Accenture #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) (#Kolkata) #Jobs #TweetMyJobs
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) – Accenture: (#Bangalore) #WebDesign #Job #Jobs #TweetMyJobs
  • Agile Methods (Scrum/FDD/XP/Crystal/DSDM) – Accenture: (#Pune) #WebDesign #Job #Jobs #TweetMyJobs
  • #WebDesign #Job in #Kolkata: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • #Kolkata #WebDesign #Job: Agile Methods (Scrum/FDD/XP/Crystal/DSDM) at Accenture #Jobs #TweetMyJobs
  • Be first to apply – Eliassen Group Agile Coaching & Senior Scrum Master Training in Bethesda, MD #agilecoach
  • RT @MasterScrum: The Lorax Would Be a Great Product Owner!
    Lessons in #scrum from a Dr Seuss classic. #agile
    http://…
  • RT @AgileKarma: The mutant starfish Retrospective game by @StefanoBowen #Agile #Scrum
  • DEMO WEEK #2 ready!!! @WIKISPEED #interns #summer #wikispeed #scrum #agile #cars #technology
  • RT gabrielagill53: DEMO WEEK #2 ready!!! WIKISPEED #interns #summer #wikispeed #scrum #agile #cars #technology
  • RT @gabrielagill53: Loved this marketing method Currently looking for cool ideas to promote @WIKISPEED #interns #scr…
  • RT @gabrielagill53: DEMO WEEK #2 ready!!! @WIKISPEED #interns #summer #wikispeed #scrum #agile #cars #technology
  • Professional Agile & Scrum Certification | 1 Day P… #Aug29 @ Rochester #Education #DoMore #Conferences
  • RT @RochesterEvnts: Professional Agile & Scrum Certification | 1 Day P… #Aug29 @ Rochester #Education #DoMore #Con…
  • Professional Agile & Scrum Certification | 1 Day P… #Aug29 at @SkirvinHiltonOK #ConventionsAndTradeshows
  • RT @agileconn: Did you know that members get access to premium content and exclusive site features #agile #scrum
  • @djp1974 @WIKISPEED @PSInnovate @agileforgov I’ve used #agile & #scrum for town planning: https://t.co/QAkilPiiNu
  • RT @mashmatix: @djp1974 @WIKISPEED @PSInnovate @agileforgov I’ve used #agile & #scrum for town planning: https://t.c…
  • .@WoodyZuill @dajb2 So why not focus on changing the expectations? #CoachingUp #Agile #Scrum
  • Inscreva-se! Antes que as vagas acabem!!
    #agile #agile2014 #scrum http://t.co/AmXRTsEWDu
  • Jimmy Bogard: Conventional HTML in MVC: Client-side templates #agile #scrum
  • TargetProcess – Edge of Chaos Blog: Learn a new domain every year #agile #scrum
  • RT @caipiraagil: Inscreva-se! Antes que as vagas acabem!!
    #agile #agile2014 #scrum http://t.co/AmXRTsEWDu
  • Common pitfalls and traps in daily scrum #agile via #AgileKarma #Agile
  • New blog post: Some #NoEstimates clarity #agile #lean #kanban #scrum #pmot #baot
  • RT @neil_killick: New blog post: Some #NoEstimates clarity #agile #lean #kanban #scrum #pmot #baot
  • RT @neil_killick: New blog post: Some #NoEstimates clarity #agile #lean #kanban #scrum #pmot #baot
  • RT @gabrielagill53: DEMO WEEK #2 ready!!! @WIKISPEED #interns #summer #wikispeed #scrum #agile #cars #technology
  • A Practical Example On How To Use Agile And Scrum Tec http://t.co/t48HZhgElx
  • RT @neil_killick: New blog post: Some #NoEstimates clarity #agile #lean #kanban #scrum #pmot #baot
  • Agile by McKnight, Scrum by Day is out! Stories via @FredHagerman @ChurchInt
  • Sprint Retro video #sprint #Agile #scrum #surummaster
  • RT @amckni: Agile by McKnight, Scrum by Day is out! Stories via @FredHagerman @ChurchInt
  • Summary Sprint Retro in less than 2 min #sprint #scrum #agile
  • Good read Neil! Thx! RT @neil_killick: New blog post: Some #NoEstimates clarity #agile #scrum #pmot #baot
  • Categories: Blogs

    Learn a new domain every year

    TargetProcess - Edge of Chaos Blog - Thu, 08/14/2014 - 23:25

    How diversity helps us in problem solving, creativity and overall intelligence? It helps a lot. Diverse groups of people can produce better results and radiate more creativity. But what about your own, personal diversity? Is it a good idea to accumulate knowledge from wide range of disciplines? Does knowledge of music theory help to write better code? Does knowledge from biology make you a better user experience designer? I believe yes, and here is why.

    untitled_3_by_mpcine-d5simvn

    source: Escher Butterfly Wallpaper by MPCine

    Douglas Hofstadter and Emmanuel Sander wrote a very controversial book Surfaces and Essences. It is not an easy read, but it is time spent well. Authors unfold thinking process from language to high level constructs. They show how analogy-making helps us think, generate new ideas and fuel our creativity, including scientific insights.

    This book deeply resonated with me. In general I agree that analogy-making is a core of our creativity. I even tried to apply knowledge from Running domain to Software Development domain and generated some quite interesting ideas like Interval development. Sure these ideas can’t be proved easily, since analogy doesn’t mean the idea is great. But still it is relatively easy to take knowledge from one domain and apply it to another domain.

    How can it help me?

    All that brought me to the idea to increase my personal diversity and expand my knowledge beyond typical areas like system thinking, software architecture, groups dynamic, innovation models, user experience and other stuff every CEO learns. I read books and took courses about quite diverse topics already, but I did that in a chaotic way.

    Suddenly it became obvious to me how all these new domains can help me to be more creative and solve problems better.

    What domains should I explore?

    I think you should try anything you always wanted to learn, but didn’t have time to. It is quite hard to predict what analogies can be generated from unknown domains. For example, you always wanted to know how people paint, how art evolved and how Michelangelo painted a fresco of The Last Judgement on the altar wall of the Sistine Chapel. Dig into the art domain and learn as much as you can in a single year. Will it help you to be a better software developer? Why not? If you try to paint something you can train patience and learn how to sketch (everybody should sketch, you know). Michelangelo’s approaches may give you some ideas how to structure your work. As I said, it is hard to predict exact ideas that you’ll generate in the end, but I promise you will generate some.

    I personally want to study biology, music theory, architecture, education, medicine, go and swimming. If a simple running domain gave me new insights, I believe larger and more complex domains will bring even more value.

    Why one year?

    A year is a good timeframe to focus on something. It will be your new hobby for a full year. You can read 20+ books, take 1-3 online courses, maybe take offline courses, try to apply your new knowledge constantly. Small domains demand less time, but larger domains are hard to grasp in 2-3 months.

    I don’t believe in quick solutions. You can read a book or two about a subject and have some fresh air in your head, but it is not enough to just scratch the surface. In 10 years you will have a decent knowledge in 10 domains. That sounds cool to me.

    Did you try that?

    Nope. I started to dig into music theory recently. So far I’m just sharing the idea with a hope that there is always a chance you’ll like it and give it a try.

    And maybe, just maybe, you’ll even find your new passion. Who knows?

    Categories: Companies

    Conventional HTML in ASP.NET MVC: Client-side templates

    Jimmy Bogard - Thu, 08/14/2014 - 22:21

    Other posts in this series:

    In our last post, we brought everything together to build composable blocks of tags driven off of metadata. We did this to make sure that when a concept exists in our application, it’s only defined once and the rest of our system builds off of this concept. This reduces logic duplication across several layers, ensuring that we don’t have to “remember” to do repetitive tasks, like a required field needing an asterisk and data attributes.

    All of this works great because we’ve got all the information at our disposal on the server-side, and we can push the completed product down to the client (browser). But what if we’re building a SPA, using Angular or Knockout or Ember or Backbone? Do we have to revert back to our old ways of duplication? Or can we have the best of both worlds?

    There tend to be three general approaches:

    • Just hard code it and accept the duplication
    • Include metadata in your JSON API calls, through hypermedia or other means
    • Build intelligence into templates

    I’ve done all three, and each have their benefits and drawbacks. Most teams I talk to go with #1, and some go with #2. Very few teams I meet even think about #3.

    What I’d like to do is have the power of my original server-side Razor templates, with the strongly-typed views and intelligent expression-based helpers, but instead of complete HTML templates, have these be Angular views or Ember templates:

    image

    When we deliver our templates to the client as part of our SPA, we’ll serve up a special version of them, one that’s been parsed by our Razor engine. Normally, the Razor engine performs two tasks:

    • HTML generation
    • Binding model data

    Instead, we’ll only generate our template, and the client will then bind the model to our template.

    Serving templates, Ember style

    Normally, the MVC view engine runs the Razor parser. But we’re not going that path, we’re going to parse the templates ourselves. The result of parsing will be placed inside our script tags. This part is a little long, so I’ll just link to the entire set of code.

    HtmlHelperExtensions

    A couple key points here. First, the part that runs the template through the view engine to render an HTML string:

    builder.AppendLine("<script type=\"text/x-handlebars\" data-template-name=\"" + fullTemplateName + "\">");
    var controllerContext = new ControllerContext(helper.ViewContext.HttpContext, new RouteData(), helper.ViewContext.Controller);
    controllerContext.RouteData.Values["controller"] = string.IsNullOrEmpty(relativeDirName) ? "Home" : Path.GetDirectoryName(relativeDirName);
    var result = ViewEngine.FindView(controllerContext, subtemplateName, null, false);
    var stringWriter = new StringWriter(builder);
    var viewContext = new ViewContext(controllerContext, result.View, new ViewDataDictionary(), new TempDataDictionary(), stringWriter);
    result.View.Render(viewContext, stringWriter);
    
    builder.AppendLine("</script>");
    

    We render the view through our normal Razor view engine, but surround the result in a script tag signifying this is a Handlebars template. We’ll place the results in cache of course, as there’s no need to perform this step more than once. In our context objects we build up, we simply leave our ViewData blank, so that there isn’t any data bound to input elements.

    We also make sure our templates are named correctly, using the folder structure to match Ember’s conventions. In our one actual MVC action, we’ll include the templates in the first request:

    @Scripts.Render("~/bundles/ember")
    @Scripts.Render("~/bundles/app")
    
    @Html.Action("Enumerations", "Home")
    @Html.RenderEmber()

    Now that our templates are parsed and named appropriately, we can focus on building our view templates.

    Conventional Handlebars

    At this point, we want to use our HTML conventions to build out the elements needed for our Ember templates. Unfortunately, we won’t be able to use our previous tools to do so, as Ember uses Handlebars as its templating language. If we were using Angular, it might be a bit easier to build out our directives, but not by much. Client-side binding using templates or directives requires special syntax for binding to scope/model/controller data.

    We don’t have our convention model, or even our HtmlTag library to use. Instead, we’ll have to use the old-fashioned way – building up a string by hand, evaluating rules as we go. I could have built a library for creating Ember view helpers, but it didn’t seem to be worth it in my case.

    Eventually, I want to get to this:

    @Html.FormBlock(m => m.FirstName)

    But have this render this:

    <div class="form-group">
        <label class="required control-label col-md-2"
           {{bind-attr for="view.firstName.elementId"}}>
           First Name
        </label>
        <div class="col-md-10">
            {{view TextField class="required form-control" 
                   data-key="firstName" 
                   valueBinding="model.firstName" 
                   viewName="firstName" 
                   placeholder="First"
            }}
        </div>
    </div>

    First, let’s start with our basic input and just cover the very simple case of a text field.

    public static MvcHtmlString Input<TModel, TValue>(this HtmlHelper<TModel> helper,
        Expression<Func<TModel, TValue>> expression,
        IDictionary<string, object> htmlAttributes)
    {
        var text = ExpressionHelper.GetExpressionText(expression).ToCamelCase();
        var modelMetadata = ModelMetadata.FromLambdaExpression(expression, helper.ViewData);
        var unobtrusiveAttributes = GetUnobtrusiveValidationAttributes(helper, expression);
    
        var builder = new StringBuilder("{{view");
    
        builder.Append(" TextField");
    
        if (unobtrusiveAttributes.ContainsKey("data-val-required"))
        {
            builder.Append(" class=\"required\"");
        }
    
        builder.AppendFormat(" data-key=\"{0}\"", text);
    
        builder.AppendFormat(" valueBinding=\"model.{0}\"", text);
        builder.AppendFormat(" viewName=\"{0}\"", text);
    
        if (!string.IsNullOrEmpty(modelMetadata.NullDisplayText))
            builder.AppendFormat(" placeholder=\"{0}\"", modelMetadata.NullDisplayText);
    
        if (htmlAttributes != null)
        {
            foreach (var item in htmlAttributes)
            {
                builder.AppendFormat(" {0}=\"{1}\"", item.Key, item.Value);
            }
        }
    
        builder.Append("}}");
    
        return new MvcHtmlString(builder.ToString());
    }

    We grab the expression text and model metadata, and begin building up our Handlebars snippet. We apply our conventions manually for each required attribute, including any additional attributes we need based on the MVC-style mode of passing in extra key/value pairs as a dictionary.

    Once we have this in place, we can layer on our label helper:

    public static MvcHtmlString Label<TModel, TValue>(
        this HtmlHelper<TModel> helper, 
        Expression<Func<TModel, TValue>> expression)
    {
        var text = ExpressionHelper.GetExpressionText(expression);
        var metadata = ModelMetadata.FromLambdaExpression(expression, helper.ViewData);
        var unobtrusiveAttributes = GetUnobtrusiveValidationAttributes(helper, expression);
    
        var builder = new StringBuilder("<label ");
        if (unobtrusiveAttributes.ContainsKey("data-val-required"))
        {
            builder.Append(" class=\"required\"");
        }
        builder.AppendFormat(" {{{{bind-attr for=\"view.{0}.elementId\"}}}}", text.ToCamelCase());
        builder.Append(">");
    
        string labelText = metadata.DisplayName ?? (metadata.PropertyName == null
            ? text.Split(new[] {'.'}).Last()
            : Regex.Replace(metadata.PropertyName, "(\\B[A-Z])", " $1"));
    
        builder.Append(labelText);
        builder.Append("</label>");
    
        return new MvcHtmlString(builder.ToString());
    }

    It’s very similar to the code in the MVC label helper, with the slight tweak of defaulting label names to the property names with spaces between words. Finally, our input block combines these two together:

    public static MvcHtmlString FormBlock<TModel, TValue>(
        this HtmlHelper<TModel> helper,
        Expression<Func<TModel, TValue>> expression)
    {
        var builder = new StringBuilder("<div class='form-group'>");
        builder.Append(helper.Label(expression));
        builder.Append(helper.Input(expression));
        builder.Append("</div>");
        return new MvcHtmlString(builder.ToString());
    }

    Now, our views start to become a bit more sane, and it takes a keen eye to see that it’s actually a Handlebars template. We still get strongly-typed helpers, metadata-driven elements, and synergy between our client-side code and our server-side models:

    @model MvcApplication.Models.AccountCreateModel
    {{title 'Create account'}}
    
    <form {{action 'create' on='submit'}}>
        <fieldset>
            <legend>Account Information</legend>
            @Html.FormBlock(m => m.Username)
            @Html.FormBlock(m => m.Password)
            @Html.FormBlock(m => m.ConfirmPassword)
        </fieldset>

    We’ve now come full-circle, leverage our techniques that let us be ultra-productive building out pages on the server side, but not losing that productivity on the client-side. A concept such as “required field” lives in exactly one spot, and the rest of our system reads and reacts to that information.

    And that, I think, is pretty cool.

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

    Categories: Blogs

    What You Need to Know About Taskboards vs. Drill-Through Boards

    Have you ever wondered when to use a taskboard or a drill-through board in LeanKit? Taskboards and drill-through boards are both designed to assist with visualizing the breakdown of work, yet they have distinctly different uses. In an interview with a panel of our product experts, we learned that each option offers its own unique advantages. What’s the main distinction […]

    The post What You Need to Know About Taskboards vs. Drill-Through Boards appeared first on Blog | LeanKit.

    Categories: Companies

    A is for Agile... and changing the world

    Scrum Breakfast - Thu, 08/14/2014 - 17:53
    We are uncovering better ways of developing software, by doing it and helping others to do it...

    -- The Manifesto for Agile Software Development 
    In 2001, seventeen people signed a 73 word statement that changed software development forever. Before: a bunch of guys doing "lightweight project management." After: a set of values which coalesced into a name, "Agile" and later into a movement. People identified with the values and transformed their working worlds with things like Scrum, Extreme Programming, Kanban, Lean Startup, and still other ideas and frameworks we haven't invented yet.

    As we got better at developing software, we discovered the need for better ways at lot of things. The Agile movement inspired DevOps, which is looking for better ways to operate computer systems, and Stoos, which is looking for better ways of management. Soon, maybe scientists will look for better ways of conducting research, and maybe you will look for better ways of doing whatever you do.

    How can you use the Agile Manifesto to help you? Start with the Agile Manifesto, find some colleagues who do what you do, and play with the Manifesto a bit. Not developing software? What is your essential goal or reason for being? Adjust the manifest as necessary to fit your situation. It probably won't need many changes.

    So if you are in the HR department, what do you do? Maybe it is something like 'developing our human potential.' So what would a manifesto for agile human resources look like? Maybe something like this:
    Sample Manifesto for Agile Human DevelopmentWe are uncovering better ways of developing human potential, by doing it and helping others to do it. Through this work we have come to value:
    • Individuals and interactions over processes and tools
    • Autonomy, mastery and purpose over documentation, directives and control
    • Collaboration over contract negotiation
    • Responding to change over following a plan
    That is, while there is value in the items on the right, we value the items on the left more.This is probably not quite right, but you get the idea. And it should be your manifesto, not mine, so feel free to keep working on it!
    Want to change your world? Start looking for a better way! Maybe write your own manifesto... Want to find like-minded individuals, check out the Open Space event 24 Think Park in Zurich...



    Categories: Blogs

    Where does r studio install packages/libraries?

    Mark Needham - Thu, 08/14/2014 - 12:24

    As a newbie to R I wanted to look at the source code of some of the libraries/packages that I’d installed via R Studio which I initially struggled to do as I wasn’t sure where the packages had been installed.

    I eventually came across a StackOverflow post which described the .libPaths function which tells us where that is:

    > .libPaths()
    [1] "/Library/Frameworks/R.framework/Versions/3.1/Resources/library"

    If we want to see which libraries are installed we can use the list.files function:

    > list.files("/Library/Frameworks/R.framework/Versions/3.1/Resources/library")
     [1] "alr3"         "assertthat"   "base"         "bitops"       "boot"         "brew"        
     [7] "car"          "class"        "cluster"      "codetools"    "colorspace"   "compiler"    
    [13] "data.table"   "datasets"     "devtools"     "dichromat"    "digest"       "dplyr"       
    [19] "evaluate"     "foreign"      "formatR"      "Formula"      "gclus"        "ggplot2"     
    [25] "graphics"     "grDevices"    "grid"         "gridExtra"    "gtable"       "hflights"    
    [31] "highr"        "Hmisc"        "httr"         "KernSmooth"   "knitr"        "labeling"    
    [37] "Lahman"       "lattice"      "latticeExtra" "magrittr"     "manipulate"   "markdown"    
    [43] "MASS"         "Matrix"       "memoise"      "methods"      "mgcv"         "mime"        
    [49] "munsell"      "nlme"         "nnet"         "openintro"    "parallel"     "plotrix"     
    [55] "plyr"         "proto"        "RColorBrewer" "Rcpp"         "RCurl"        "reshape2"    
    [61] "RJSONIO"      "RNeo4j"       "Rook"         "rpart"        "rstudio"      "scales"      
    [67] "seriation"    "spatial"      "splines"      "stats"        "stats4"       "stringr"     
    [73] "survival"     "swirl"        "tcltk"        "testthat"     "tools"        "translations"
    [79] "TSP"          "utils"        "whisker"      "xts"          "yaml"         "zoo"

    We can then drill into those directories to find the appropriate file – in this case I wanted to look at one of the Rook examples:

    $ cat /Library/Frameworks/R.framework/Versions/3.1/Resources/library/Rook/exampleApps/helloworld.R
    app <- function(env){
        req <- Rook::Request$new(env)
        res <- Rook::Response$new()
        friend <- 'World'
        if (!is.null(req$GET()[['friend']]))
    	friend <- req$GET()[['friend']]
        res$write(paste('<h1>Hello',friend,'</h1>\n'))
        res$write('What is your name?\n')
        res$write('<form method="GET">\n')
        res$write('<input type="text" name="friend">\n')
        res$write('<input type="submit" name="Submit">\n</form>\n<br>')
        res$finish()
    }
    Categories: Blogs

    SAP classic – agil

    Scrum 4 You - Thu, 08/14/2014 - 07:35

    “Softwareentwicklung” wird häufig mit Menschen assoziiert, die für eine Lösung Zeile für Zeile Code in ihrem Computer schreiben. Tatsache ist, dass viele Geschäftsprozesse von Unternehmen heute durch Standardsoftware abgebildet werden. Für eine neue Anforderung muss in dieser Software nicht zwangsweise wirklich neuer Code generiert werden. In vielen Fällen reicht ein „Anpassen“, das so genannte „Customizing“, der Standardsoftware aus. Aus diesem Customizing von Standardsoftware sind bei den bekanntesten Produkten ganze Geschäftszweige entstanden. Auf den Punkt gebracht spreche ich zum Beispiel von SAP-Beratern, die mit ihrer Expertise die einzelnen SAP-Module, auch als “SAP classic” bezeichnet, so anpassen, dass sie die Prozesse des Unternehmens abbilden und somit unterstützen.

    Nun gibt es in der realen Business-Welt oft Projekte, die bereits vorhandene SAP-Module nutzen, aberpixabay_pdpics über reines Customizing der Software hinausreichen und das Modul mit maßgeschneiderten Zusätzen ergänzen. Und genau hier wird es spannend: SAP-Berater treffen auf Softwareentwickler. Warum, ist nicht ganz einfach zu erklären. Vielleicht sind es die unterschiedlichen Typen, die in den einzelnen Berufsgruppen anzutreffen sind, vielleicht sind es auch die unterschiedlichen Rollen – vielleicht aber auch etwas ganz anderes. Der Grund tut vielleicht gar nicht soviel zur Sache. Die Tatsache ist, dass ein solches cross-funktionales Team sehr gut, effizient und erfolgreich mit agilen Methoden wie Scrum zusammenarbeiten kann.

    Ich habe in meinen Projekten die Erfahrung gemacht, dass sich gerade die Berater an diese neuen Teamkonstellationen gewöhnen müssen. Ihre Vorgehensweise ist oft geprägt von traditionellem Denken –  vor der Implementierung wird ein Konzept ausgearbeitet wird. Von Vorteil ist, dass dieses Konzept zumeist in intensiver Interaktion mit dem Kunden in gemeinsamen Workshops erarbeitet wird. Problematisch ist dabei häufig die fehlende Vorstellungskraft der Kunden, der Fachbereiche des Unternehmens. Für sie ist die Welt der Datenstrukturen, Objekte und Transaktionen äußerst irreal und zumeist zu komplex, um sie vollständig zu verstehen. So entstehen oft aus monatelang diskutierten und mit dem Kunden abgestimmten Konzepten erst recht wieder Prozessabbildungen im System, die den Anwender nicht optimal unterstützen.

    Die gute Nachricht ist: Es ist möglich. Erfahrungen zeigen, dass Berater nebst Entwicklern in cross-funktionalen Teams in kurzen Iterationen miteinander arbeiten und so kontinuierlich Business Value liefern können. Customizing-Einstellungen und Codierung können so Hand in Hand in Form von User Stories erfolgen. Müssen verschiedene Möglichkeiten der Prozessabbildung doch einmal intensiver mit den Anwendern erarbeitet, besprochen und abgestimmt werden, so sollten diese Arbeitsschritte ebenfalls in Form von User Stories abgebildet werden. Ausgearbeitete und aufbereitete Entscheidungsgrundlagen entsprechen ebenfalls Lieferungen von Kundennutzen. Mit Hilfe der kontinuierlichen Lieferungen ist es dem Anwender nun auch möglich, nicht nur die Datenmodelle, sondern lauffähige Software zu begutachten. Im optimalen Fall kann er seinen Geschäftsprozess oder Teilprozesse davon bereits nach wenigen Sprints nutzen, um Feedback für das agile Team zu generieren. Alle Beteiligten können so durch die Anwendung agiler Methoden profitieren, auch oder gerade weil es sich in diesem Fall nicht nur um reine Softwareentwicklung handelt.

    Related posts:

    1. In der Welt des SAP Customizings
    2. Scrum und Festpreis
    3. Teams – co-located, distributed, dispersed

    Categories: Blogs

    Firing The Customer You Love

    Derick Bailey - new ThoughtStream - Wed, 08/13/2014 - 21:38

    Everyone talks about the toxic customers… the ones that complain all the time, take up all your resources, demand free things in exchange for not complaining, and generally make your life as a business person hell. It’s relatively easy to fire the toxic customer, I think. I’ve done it a few times as a consultant, and it gets easier over time at least. 

    But there’s one thing that no one ever talks about… something that I’ve come to think of as the 2nd worst email that your business will ever send:

    Firing the customer that you love.

    Firing the customer you love

    Building A Relationship

    It’s late 2013. I’m searching twitter for a few select keywords regarding podcasting, looking for people with whom I can engage conversation. My goal is to help others get up and running with a podcast, answer questions, and generally be a valuable resource as they are starting out. It’s how I attract customers at this early stage in SignalLeaf’s life. 

    And there they are… the perfect person for me to help. A person in a music scene that I have been involved in before; someone that has knowledge of sound, recording and production; a podcast that is going to be started soon, with a mission that I fully support and want to be part of, but is not yet set up anywhere. So I reach out. I ask if they have any questions about podcasting specifically… about hosting, about RSS feeds, about the fine details of getting a podcast online. A few tweets back and forth leads to email exchanges. More questions emerge from the emails, and it quickly turns in to phone calls. I spent probably 5 or 6 hours total, doing research, answering questions and providing the information they needed to get their podcast up and running correctly. 

    I was ecstatic when they said they wanted to use SignalLeaf for hosting even after we had talked about their concerns with using a new, unknown player in the arena. It was going to be great… and it was great. SignalLeaf grew in new and exciting ways, with the traffic that this podcast generated. Business was good and growing through sponsorship messages with them. 

    And then I asked them to leave SignalLeaf, offering to help them migrate to another service.

    The Harsh Realities Of Customer Success

    In most business, the success of your customers typically brings in more income and more customers for you. When someone uses your service a lot, they buy in to more features, higher priced plans and word-of-mouth referrals that bring you even more happy customers.

    Podcast hosting is a commodities business, to a large extent. It’s file hosting and bandwidth providing. Having a hugely successful customer when you’re a podcast host can present a few interesting challenges, though. When a podcast is explosively successful (gaining 15,000+ listens on their first episode, and moving in to the 30K to 40K listener range, per episode, in 6 months) it costs a lot in terms of bandwidth.

    Even now, in 2014, bandwidth is not free. Yes, it’s cheap. At $0.12/GB, I can serve a few thousand listens per episode on the average podcast, and not worry about exceeding the monthly subscription rate I am charging for that podcast. But when you look at my last post on figuring out where the bandwidth charges are coming from in my Amazon S3 account, it’s clear that the bandwidth costs can quickly destroy your bank account and far exceed all income from all customers, for a podcast that is genuinely gigantic in its listener base.

    Asking Them To Pay Or Leave

    It took a few months of ignoring the cause, eating the $600 to $800 per month bandwidth bill and driving my credit cards to their limit for me to realize what I had to do. Yes, this podcast was bringing in new customers through SignalLeaf sponsorships. But sadly it wasn’t enough new income for me to absorb the cost, let alone remain profitable. So I did the only thing I could do…

    I contacted the people that run the podcast, explained the situation to them (in detail – leaving nothing ambiguous) and asked them to either find another host or pay for the bandwidth.

    This was especially difficult for me, as I believed in the mission of the podcast, found it to be thoroughly entertaining and was proud to be at least a man-behind-the-curtains part of what they were doing. But I had to do it, because I was going to end up bankrupt if I didn’t.

    Ultimately, they chose to move to another host and I respect that decision. I worked to make sure the migration from SignalLeaf to the new host was as smooth as possible. I made it as easy for them to leave as it was for them to get started with SignalLeaf. I certainly hope that the effort was appreciated, even as I was escorting them out the door in to the arms of another host. 

    Some Interesting Lessons In Business

    Lesson #1: Allowing your customers to exceed your income with their use of your system is untenable. “Really? NO!” – yup. I know. It’s basic math that even I can do in my head. And it’s a problem that has befallen more than one company in the last few years. I’ve read stories about “freemium” photo sharing services that tank and shut down in the face of 30,000+ users of their service… when customers don’t pay for bandwidth in a bandwidth/commodities service… 

    Lesson #2: Sponsorships do work… but you have to target the right audience with the right message. The audience for this particular podcast was very large, and I did manage to pull in some new customers through the sponsorship. But I can only imagine how much more effective the sponsorship would be if SignalLeaf were in the same market space as this podcast… if SignalLeaf were sponsorship an entrepreneurial podcast, or a podcast about how to podcast for business, etc. 

    Lesson #3: Your favorite customer might be your “worst” customer. While it’s true that I loved what this podcast was about and want to support them, I was allowing myself to be taken for a ride and lose my shirt in the process. They may have been one of my favorite customers from a personal perspective… but they were a “bad” customer from a business perspective. I just didn’t want to admit it.

    Lesson #4: If I had been in contact with them from the start, about the cost of hosting their show, there’s a chance that we could have worked out a better arrangement. But when it came down to it, I presented the problem too late and gave them an almost ultimatum email. Shame on me for that, and I’m not surprised they chose to go somewhere else. I only hope my grace in helping them move was noted on their way out.

    An Interesting Lesson In Podcast Hosting

    In an effort to help the podcast that I was booting out the door, I contacted a few of the other podcast hosting services; the big dogs; the 8,000lb gorillas in the room. I’ve had contact with them before, so it was easy for me to get directly in touch with the right person. I asked questions about what the costs of hosting this particular podcast would be, informed the services of the downloads per episode, average file size, etc. I brought all of this information back to the people running the podcast and they made their decision based on the information I presented to them. 

    And you wanna know something REALLY interesting about the podcast hosting industry? Every podcast hosting company out there will ask you to pay for bandwidth. 

    I honestly didn’t know this, before. I was under the delusion that these services were providing unlimited bandwidth to even the smallest paid plan. It turns out this isn’t quite true, even if other services directly advertise unlimited bandwidth. The thing they don’t advertise in very large writing (but it’s there if you look hard enough) is that the “unlimited” bandwidth comes at 1 of 2 prices: sponsorship or cash.

    Most of these services don’t care about the meager traffic that your podcast generates. It’s like a gym membership… you sell more subscriptions than are being used at any given moment. But when you get in to the kind of traffic that a podcast host cares about, then you are moving in to their “professional” services. At this level, they will either ask you to use their sponsorship program or ask you to pay for the bandwidth. In any case, you end up paying for the traffic… whether it’s paid for with cash or with sponsorships. 

    This is probably the most valuable lesson for me, in all of this. This gives me new insight in to how to properly structure pricing for SignalLeaf… how to present it not as unlimited, but as one option for paying for the bandwidth that your podcast will use. I’m still struggling to define this completely, but it’s giving me a lot to think about and work with.

    SignalLeaf Is A Better Service Because Of This

    In spite of the cost associated with this podcast, they had a direct influence on the quality and stability of SignalLeaf. I probably wouldn’t have as robust a service as I do, without having served 20K to 40K of episode listen each week, for the last 6 months. I’m grateful for the opportunity that I had in hosting this podcast. I want to see nothing but the best of luck in their continued and growing success. I wish I could have found a way to turn this situation in to a profitable scenario for SignalLeaf… but it is what it is. I’m looking for the lessons that I can get from this experience. I’m doing what I can to improve the service. And I’m 100% certain that I lived up to my ideals of always helping the podcaster, to create a fan and someone that advertises for me, even when they choose to use another service.

     

     

     

    P.S. I called this the 2nd worst email that your business will ever send. So what’s the first? I’d have to say the worst email you’ll ever send (and hope you never have to) is the “we’re shutting down” email.

     

     

         Related Stories 
    Categories: Blogs

    Knowledge Sharing


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