Skip to content

Feed aggregator

Customer Spotlight: Elekta

Rally Agile Blog - Thu, 09/10/2015 - 21:45

Occasional stories about Rally customers who are doing cool and interesting things.

Elekta develops clinical solutions for treating cancer and brain disorders, and yes — the technologies are as powerful and sophisticated as you might expect. The systems require an enormous effort behind the scenes to maintain and integrate, not to mention the constant drive toward innovation.

Until recently, the engineering teams at Elekta were struggling to keep up. It’s a familiar story in the waterfall world: competing priorities, high work in progress (WiP), missed deadlines, and an atmosphere of disappointment and distrust.

In the past two years, the organization has turned these trends around using an agile transformation to gain clearer visibility into capacity and create better alignment between engineering and the business. Leaders are taking decisive actions to limit WiP and communicate priorities clearly across the company. As a result, quality and predictability have improved.

How did Elekta do it? Hear directly from Todd Powell, Executive VP of Elekta Software, and read on for some of the factors contributing to their successful transformation.

Success factor 1: Get the PMO involved

In 2013, Elekta Software launched its agile at scale transformation, aiming to overhaul the entire waterfall approach. The idea was to align the work with business value, restore trust between engineering and the business, and create a more rewarding work environment for employees. It also meant giving up extensively scoped plans and adopting a more agile approach to execution.

This was a big shift, especially for a PMO accustomed to defining and documenting requirements from top to bottom. They quickly realized that a “directionally correct” plan turned out to be far more reliable than one that was rigidly scoped. And it was faster — at the scale of a few weeks rather three months. The PMO has played a major role in driving the organizational change necessary for Elekta to truly transform its product development lifecycle.

Success factor 2: Use data to drive decisions

In the past, the product and engineering groups didn’t have a clear understanding of their actual capacity, so they couldn’t push back on roadmap commitments. In effect, there was no forcing function for true business prioritization — instead, everything was a high priority.

By adopting Rally’s portfolio scenario planning prototype (productized in June), the PMO can spin up scenarios based on different growth variables across a three-year planning horizon. These scenarios are key to demonstrating capacity to decision makers and showing how different funding levels affect the backlog. They also give the company a lot of data on performance and speed, which enables realistic decisions about the work.

With this data-driven portfolio planning approach, the PMO put the agile transformation on solid footing and convinced leadership to make important changes in how the work is funded, flowed to teams and delivered.

Success factor 3: Think beyond product delivery

Elekta’s agile transformation is creating real value for the business, not just in terms of engineering predictability and quality. It has given the company a framework for aligning engineering with the product organization and beyond, including marketing and sales. This alignment goes a long way toward creating a culture of trust and higher morale. Team members can rely on each other to deliver on schedule, and engineering teams are no longer pulled into “death march” projects.

Listen to the full Elekta PMO story, as presented at RallyON 2015.

Interested in portfolio management capabilities in Rally? Take the product tour.

Learn how agile portfolio management helps you translate strategic goals into realistic execution plans. Read our white paper.

Chase Doelling
Categories: Companies

Managing JavaScript’s this With ES6 Arrow Functions

Derick Bailey - new ThoughtStream - Thu, 09/10/2015 - 13:30

For a long time now, there have been 5 basic rules for managing JavaScript’s “this”. I’ve previously compiled these rules in to an email course and ebook that outlines how effectively work with them.

Now, with ES6 (officially known as ES2015) as the latest and greatest standard of the JavaScript language, I’ve updated both the ebook and email course to include the new rule that helps you manage “this”: arrow functions – and I want to share this new chapter with you!

Arrow functions

Fortunately, this rule is not another arcane syntax exception, but a simplification taken from other languages to reduce the code in callback functions and manage “this” more logically. 

ES6 Arrow Functions

With ES6, a callback function can be defined using the new “arrow function” syntax. This syntax allows you to get rid of the word “function” and put a literal “=>” arrow in between the parameter list and function body.

There are several syntax variations, depending on the number of arguments and lines of code in the function. No matter which syntax version you are using, though, they all flow from this basic form:

If you were to write the same callback function without the arrow syntax, it would look like this:

While it is possible to reduce the arrow syntax further, the difference between arrow functions and standard functions is insignificant when you look at the number of characters to type.

The real value in arrow functions is not in the syntax reduction, then, but in the way it manages “this” for you.

Lexical Scope

When you write an arrow function in JavaScript, the value of “this” is said to be determined through “lexical analysis”. This is a fancy phrase to say that “this” comes from the surrounding code, where the function is called.

As a simple example, look at the following code and the arrow function within:

Note that there is no “that = this” hand-waving… no .bind, .call or .apply, either. There is nothing in this code to explicitly state what the value of “this” will be when “this.selectManager(employee)” is called.

The arrow function syntax uses the knowledge of where the code lives to see that it should use the value of “this” from the parent function. In other words, the value of “this” in the “addNewEmployee” function will also be the value of “this” inside of the arrow function callback for the event handler. 

This has some tremendous benefits, as you can imagine. But this doesn’t solve every single riddle of “this”, and it doesn’t absolve you from the other rules either.

Changing The Surrounding “this” Changes The Arrow Function’s

When working with the code in the above “orgChart” example, the value of “this” within the addNewEmployee function is still managed by the standard rules of “this”. If you call the method in this manner:

Then the value of “this” within the “addNewEmployee” function and within the arrow function callback will be the “orgChart” object. However, if you change the invocation pattern for addNewEmployee, you will also change the value of “this” in both locations.

In this example, the standard function invocation pattern is used, leaving the value of “this” to be either the global object or undefined if your code is in strict mode. When the code gets to the callback for the “complete” event handler, the value of “this” will not be what you expect. The callback function will fail because “this” is not pointing at “orgChart”, and the “selectManager” method will not be found.

Worth 10x It’s Weight In Deleted Code

The danger in the arrow function’s value of “this” may sound dramatic, but it is no different than the danger of using “this” with “that = this;” or “.apply” or any other method of managing “this” in JavaScript. The benefits of the new arrow function syntax also far outweigh the potential detriments. 

Use the arrow function syntax with your JavaScript code, as soon as you can. This feature is worth the mental weight (and potential tooling weight to run ES6 code today) and the weight of all the code you will delete. You’ll not have to worry about “that = this”, or “.bind”, “.call” and “.apply” when working with arrow functions. You’ll only have to manage the value of “this” in the surrounding code – which is something you are already doing. 

Master The Other 5 Rules

The 5 core rules for managing JavaScript’s “this” still apply, even if you are using ES6 arrow functions, as mentioned already. If you’d like to master the complete set of rules and greatly improve your own JavaScript abilities, check out The Rules To Master JavaScript’s “this” – available in two formats:

The content of both of these formats is the same. Each format includes all 5 core rules for managing “this”, and has been updated to includes the above content as email / chapter 6!

Get the ebook or the email course, and master JavaScript’s most notorious keyword.

Categories: Blogs

Learning Agile Software Development the Hard Way

1. ReadRead one or more of the following:(FREE) Explore Don Well's site: Extreme Programming: A Gentle Introduction.

(FREE) Read the Scrum Guide.2. Participate in the communityJoin a local user group. currently dominates.  I'd suggest also finding or setting up a local Lean Coffee.

Follow Agile people on Twitter.  My handle is @jchyip.  There's an old 2012 list of "The Top 20 Most Influential Agile People".  Probably a reasonable group of people to start with.

Subscribe to Agile blogs.  There's an old 2011 list of "The Top 200 Agile Blogs".  Probably a reasonable place to start.3. Learn and practice the craft
  1. Learn about User Stories and User Story Mapping
  2. Learn Test Driven Development (TDD)
  3. Practice TDD and Pair  Programming
    • Practice using Code Katas.  Alternatively, look for similar language-specific exercises for your particular programming language.  For example, Ruby Quiz.
    • Find or setup a Coding Dojo.  This seems to have become more rare so instead...
    • Join or host a CodeRetreat.
  4. Learn about testing in the Agile context
  5. Learn about Continuous Integration and Continuous Delivery
  6. Write about what you are learning
3. Learn the big picture
  1. Read about the Agile Fluency Model
  2. Read Patterns of Enterprise Application Architecture by Martin Fowler
  3. Explore Lean Software Development
  4. Explore Kanban for software development
  5. Explore Lean Startup
  6. Watch Spotify Engineering Culture videos (Part 1) (Part 2)
  7. Attend conferences.  I recommend smaller, local, not vendor-focused conferences rather than the massive ones.  Open Space conferences tend to be good if you get the right crowd.  YOW! / GOTO / QCon tend to be good.  Lean Kanban conferences tends to be good.
4. Explore the less known
  1. Read Crystal Clear by Alistair Cockburn
  2. Read Agile Software Development by Alistair Cockburn
  3. Read Lean Product and Process Development by Allen C. Ward
  4. Read The Principles of Product Development Flow by Donald G. Reinertsen
Categories: Blogs

New Scrum / Agile Resource Library

Notes from a Tool User - Mark Levison - Wed, 09/09/2015 - 22:20

Agile Scrum Resource LibraryIf you’ve ever attended Mark’s training, you know that he reads an insane amount of reference and research on Scrum and Agile. He shares those resources – some invaluable, some handy, and some simply provocative and obscure – with course attendees in a long and growing list of links that he believes can help them toward their Scrum/Agile goals.

Scrum Master Resources – A good ScrumMaster needs to know much more than just Scrum applications and exercises. An understanding of supporting tools and methodologies, an arsenal of examples and approaches to solve problems and keep things fun but still productive, and a big picture view of how Agile can be applied throughout an organization as well as other aspects of daily life, are all important keys to being an effective ScrumMaster. These resources will provide helpful ideas and suggestions on these and much more.

Scrum Product Owner Resources – A Scrum Product Owner needs to hone their skills in communicating needs and priorities to the team, keep aware of market demands and changes, and be an effective – but diplomatic and fair – liaison between buyers and builders. These resources will help with practical advice on everything from creating personas and user stories, to backlog grooming, and beyond.

Scrum Developer Resources – References include real stories of Emergent Architecture, examples of how Continuous Deployment can be done and where it is already being done, Legacy code survival strategies, and more.

This carefully curated and organized collection of all things Agile will continue to be updated with treasures that Mark finds. It’s a huge and valuable resource of more than 800 articles, posts, links, books, and more.

If you know of a great resource that we haven’t included and should, tell Mark on Facebook or Twitter!

Categories: Blogs

About More with LeSS: A Decade of Descaling with Large-Scale Scrum

DFW Scrum User Group - Wed, 09/09/2015 - 15:20
We were fortunate in June to have Craig Larman, co-creator of Large-Scale Scrum (LeSS), speak to our group. The main goal of LeSS is not to enable traditional big groups to “meet their commitment” more efficiently—it is to see the ineffectiveness … Continue reading →
Categories: Communities

Private properties in ES2015: the good, bad and ugly

Xebia Blog - Wed, 09/09/2015 - 13:16
code { display: inline !important; }

This post is part of a series of ES2015 posts. We'll be covering new JavaScript functionality every week!

One of the new features of ECMAScript 2015 is the WeakMap. It has several uses, but one of the most promoted is to store properties that can only be retrieved by an object reference, essentially creating private properties. We'll show several different implementation approaches and compare it in terms of memory usage and performance with a 'public' properties variant.

A classic way

Let's start with an example. We want to create a Rectangle class that is provided the width and height of the rectangle when instantiated. The object provides an area() function that returns the area of the rectangle. The example should make sure that the width and height cannot be accessed directly, but they must be stored both.

First, for comparison, a classic way of defining 'private' properties using the ES2015 class syntax. We simply create properties with an underscore prefix in a class. This of course doesn't hide anything, but a user knows that these values are internal and the user shouldn't let code depend on its behaviour.

class Rectangle {
  constructor(width, height) {
    this._width = width;
    this._height = height;

  area() {
    return this._width * this._height;

We'll do a small benchmark. Let's create 100.000 Rectangle objects, access the area() function and benchmark the memory usage and speed of execution. See the end of this post on how this was benchmarked. In this case, Chrome took ~49ms and used ~8Mb of heap.

WeakMap implementation for each private property

Now, we introduce a WeakMap in the following naive implementation that uses a WeakMap per private property. The idea is to store a value using the object itself as key. In this way, only the accessor of the WeakMap can access the private data, and the accessor should be of course only the instantiated class. A benefit of the WeakMap is the garbage collection of the private data in the map when the original object itself is deleted.

const _width = new WeakMap();
const _height = new WeakMap();

class Rectangle {
  constructor (width, height) {
    _width.set(this, width);
    _height.set(this, height);

  area() {
    return _width.get(this) * _height.get(this);

To create 100.000 Rectangle objects and access the area() function, Chrome took ~152ms and used ~22Mb of heap on my computer. We can do better.

Faster WeakMap implementation

A better approach would be to store all private data in an object for each Rectangle instance in a single WeakMap. This can reduce lookups if used properly.

const map = new WeakMap();

class Rectangle {
  constructor (width, height) {
    map.set(this, {
      width: width,
      height: height

  area() {
    const hidden = map.get(this);
    return hidden.width * hidden.height;

This time, Chrome took ~89ms and used ~21Mb of heap. As expected, the code is faster because there's a set and get call less. Interestingly, memory usage is more or less the same, even though we're storing less object references. Maybe a hint on the internal implementation of a WeakMap in Chrome?

WeakMap implementation with helper functions

To improve the readability of above code, we could create a helper lib that should export two functions: initInternal and internal, in the following fashion:

const map = new WeakMap();
let initInternal = function (object) {
  let data = {};
  map.set(object, data);
  return data;
let internal = function (object) {
  return map.get(object);

Then, we can initialise and use the private vars in the following fashion:

class Rectangle {
  constructor(width, height) {
    const int = initInternal(this);
    int.width = width;
    int.height = height;

  area() {
    const int = internal(this);
    return int.width * int.height;

For the above example, Chrome took ~108ms and used ~23Mb of heap. It is a little bit slower than the direct set/get call approach, but is faster than the separate lookups.


  • The good: real private properties are now possible
  • The bad: it costs more memory and degrades performance
  • The ugly: we need helper functions to make the syntax okay-ish

WeakMap comes at both a performance as well a memory usage cost (at least as tested in Chrome). Each lookup for an object reference in the map takes time, and storing data in a separate WeakMap is less efficient than storing it directly in the object itself. A rule of thumb is to make sure to do as few lookups as necessary. For your project it will be a tradeoff to store private properties with a WeakMap versus lower memory usage and higher performance. Make sure to test your project with different implementations, and don't fall into the trap of micro-optimising too early.

Test reference

Make sure to run Chrome with the following parameters: --enable-precise-memory-info --js-flags="--expose-gc" - this enables detailed heap memory information and exposes the gc function to trigger garbage collection.

Then, for each implementation, the following code was run:

const heapUsed = [];
const timeUsed = [];

for (let i = 1; i <= 50; i++) {
  const instances = [];
  const areas = [];

  const t0 =;
  const m0 = performance.memory.usedJSHeapSize;

  for (let j = 1; j <= 100000; j++) {
    var rectangle = new Rectangle(i, j);

  const t1 =;
  const m1 = performance.memory.usedJSHeapSize;

  heapUsed.push(m1 - m0);
  timeUsed.push(t1 - t0);

var sum = function (old, val) {
  return old + val;
console.log('heapUsed', heapUsed.reduce(sum, 0) / heapUsed.length);
console.log('timeUsed', timeUsed.reduce(sum, 0) / heapUsed.length);
Categories: Companies

On Epiphany and Apophany - Elizabeth Keogh - Wed, 09/09/2015 - 13:14
We probe, then sense, then respond.

If you’re familiar with Cynefin, you know that we categorize the obvious, analyze the complicated, probe the complex and act in chaos.

You might also know that those approaches to the different domains come with a direction to sense and respond, as well. In the ordered domains – the obvious and complicated, in which cause and effect are correlated – we sense first, then we categorize or analyze, and then we respond.

In the complex and chaotic domains, we either probe or act first, then sense, then respond.

Most people find action in chaos to be intuitive. It’s a transient domain, after all; it resolves itself quickly, and it might not resolve itself in your favour… and is even less likely to do so if you don’t act (the shallow dive into chaos notwithstanding). We don’t sit around asking, “Hm, I wonder what’s causing this fire?” We focus on putting the fire out first, and that makes sense.

But why do we do this in the complex domain? Why isn’t it useful to make sense of what we’re seeing first, before we design our experiments?

As with many questions involving human cognition, the answer is: cognitive bias.

We see patterns which don’t exist.

The term “epiphany” can be loosely defined as that moment when you say, “Oh! I get it!” because you’ve got a sudden sense of understanding something.

The term “apophany” was originally coined as a German word for the same phenomenon in schizophrenic experiences; that moment when a sufferer says, “Oh! I get it!” when they really don’t. But it’s not just schizophrenics who suffer from this. We all have this tendency to some degree. Pareidolia, the tendency to see faces in objects, is probably the best-known type of apophenia, but we see patterns everywhere.

It’s an important part of our survival. If we learn that the berry from that tree with those type of leaves isn’t good for us, or to be careful of that rock because there are often snakes sunning themselves there, or to watch out for the slippery moss, or that the deer come down here to drink and you can catch them more easily, then you have a greater chance of survival. We’re always, always looking out for patterns. In fact, when we find them, it’s so enjoyable that this pattern-learning, and application of patterns in new contexts, forms the heart of video games and is one reason why they’re horribly addictive.

In fact, our brains reward us for almost seeing the pattern, which encourages us to keep trying… and that’s why gambling is also addictive, because a lot of the time, we almost win.

In the complex domain, cause and effect can only be understood in retrospect.

This is pretty much the definition of a complex domain; one in which we can’t understand cause and effect until after we’ve caused the effect. Additionally, if you do the same thing again and again in a complex domain, it will not always have the same effect each time, so we can’t be sure of which cause might give us the effect. Even the act of trying to make sense of the domain can itself have unexpected consequences!

The problem is, we keep thinking we understand the problem. We can see the root causes. “Oh! I get it!”… and off we blithely go to “fix” our systems.

Then we’re surprised when, for instance, complexity reasserts itself and making our entire organization adopt Scrum doesn’t actually enable us to deliver software like we thought it would (though it might cause chaos, which can give us other opportunities… if we survive it).

This is the danger of sensing the problem in the complex domain; our tendency to assume we can see the causes that we need to shift to get the desired effects. And we really can’t.

The best probes are hypothesis-free.

Or rather, the hypothesis is always, “I think this might have a good impact.” Having a reasonable reason for thinking this is called coherence. It’s really hard, though, to avoid tacking on, “…because this will be the outcome.” In the complex domain, you don’t know what the outcome is going to be. It might not be a good outcome. That’s why we spend so much time making sure our probes are safe-to-fail.

I’ve written a fair bit on how to use scenarios to help generate robust experiments, but stories – human tales of what’s happening or has happened – are also a good way to find places that probes might be useful.

Particularly, if you can’t avoid having a hypothesis around outcomes (and you really can’t), one trick you can try is to have multiple outcomes. These can be conflicting, to help you check that you’re not hung up on any one outcome, or even failure outcomes that you can use to make sure your probe really is safe-to-fail.

Having multiple hypotheses means we’re more likely to find other things that we might need to measure, or other things that we need to make safe.

I really love Sensemaker.

Cognitive Edge, founded by Dave Snowden of Cynefin fame, has a really lovely bit of software called Sensemaker that collects narrative fragments – small stories – and allows the people who write those stories to say something about their desirability using Triads and Dyads and Stones.

Because we don’t know whether a story is desirable or not, the Triads and Dyads that Sensemaker uses are designed to allow for ambiguity. They usually consist of either two or three things that are all good, all bad or all neutral.

For instance, if I want to collect stories about pair programming, I might use a Dyad which has “I want to pair-program on absolutely everything!” at one end, and “I don’t want to pair-program on anything, ever,” at the other. Both of those are so extreme that it’s unlikely anyone wants to be right at either end, but they might be close. Or somewhere in the middle.

In CultureScan, Cognitive Edge use the triad, “Attitudes were about: Control, Vulnerability, or Indifference.” You can see more examples of triads, together with how they work, in the demo.

If lots and lots of people add stories, then we start seeing clusters of patterns, and we can start to think of places where experiments might be possible.

A fitness landscape from Cognitive Edge shows loose and tightly-bound clusters, together with possible directions for movement.

A fitness landscape from Cognitive Edge

In the fitness landscapes revealed by the stories, tightly-bound clusters indicate that the whole system is pretty rigidly set up to provide the stories being seen. We can only move them if there’s something to move them to; for instance, an adjacent cluster. Shifting these will require big changes to the system, which means a higher appetite for risk and failure, for which you need a real sense of urgency.

If you start seeing saddle-points, however, or looser clusters… well, that means there’s support there for something different, and we can make smaller changes that begin to shift the stories.

By looking to see what kind of things the stories there talk about, we can think of experiments we might like to perform. The stories though have to be given to the people who are actually going to run the experiments. Interpreting them or suggesting experiments is heading into analysis territory, which won’t help! Let the people on the ground try things out, and teach them how to design great experiments.

A good probe can be amplified or dampened, watched for success or failure, and is coherent.

Cognitive Edge have a practice called Ritual Dissent, that’s a bit like the “Fly on the Wall” pattern, but is done in a pretty negative way, in that the group to whom the experiment is being presented critiques it against the criteria above. I’ve found that testers, with their critical, “What about this scenario?” mindsets, can really help to make sure that probes really are good probes. Make sure the person presenting can take the criticism!

There’s a tendency in human beings, though, to analyze their way out of failure; to think of failure scenarios, then stop those happening. Failure feels bad. It tells us that our patterns were wrong! That we were suffering from apophany, not epiphany.

But we don’t need to be afraid of apophany. Instead of avoiding failure, we can make our probes safe-to-fail; perhaps by doing them at a scale where failure is survivable, or with safety nets that turn commitments into options instead (like having roll-back capability when releasing, for instance), or – my favourite – simply avoiding the trap of signalling intent when we didn’t mean to, and instead, communicating to people who might care that it’s an experiment we want to try.

And that it might just make a difference.

Categories: Blogs

Targetprocess 3.7.8: Custom Graphical Reports Improvements

TargetProcess - Edge of Chaos Blog - Wed, 09/09/2015 - 11:44
Custom Graphical Reports Improvements – Parallel Data

Starting from v.3.7.8 you can add several data plots to the same axis and see them at the same time.

For example, you want see the average, minimum and maximum Cycle Time trends for your user stories, grouped by Team

parallel report settings

result parallel report

Fixed Bugs
  • Top settings menu: “Report Issue” renamed to “Email Support”
  • Fixed top Project/Team selector to show programs with 0 dependent projects
  • Fixed problem with board setup not opening after refreshing the page
  • Fixed quick add popup auto closing in the list view
  • Fixed error when adding a test case in a No User Story cell on a board with user stories as lanes and test cases as cards
  • Burn Down Charts fixed to show independent Features and Epics effort
  • Fixed descriptions with CK editor to work in Internet Explorer 10
  • Fixed left menu to preserve group expansion state on a page reload
  • Fixed corrupted emoji in descriptions and comments
  • Fixed SSO settings edit
  • Fixed quick add on double click in a lane
  • Fixed plugin profile deletion
  • Fixed unable to plan Projects from the Timeline view
  • Fixed error on a try to add quickly an entity with a ‘No team’ on a Board with Team/Team State axes
  • Fixed XS card zoom level on a Timeline to show unit title for allocations
Categories: Companies

Secrets from the Experience Report on Kanban

Agile Ottawa - Wed, 09/09/2015 - 06:13
Once again, the community met and shared their stories, their successes and their failures. This time, it was about Kanban. Dag Rowe facilitated an agile 101 at the beginning of the evening with a quick exploration of some Agile Metrics.  While preparing the crowd for … Continue reading →
Categories: Communities

Perfectly Executing the Wrong Plan

TV Agile - Tue, 09/08/2015 - 17:59
App developers ask themselves excellent questions about their users: Do people need my app? Can people use my app? Why do people sign up and then not use my app? However, app developers answer their excellent questions in invalid and unreliable ways. It is shocking to see how much effort app developers put in writing […]
Categories: Blogs

Using Budget Instead of Estimates in Agile

Scrum Expert - Tue, 09/08/2015 - 15:58
Categories: Communities

Collaborative Estimation Technique: Challenge, Estimate or Override (CEO)

Learn more about transforming people, process and culture with the Real Agility Program

Great technique described by Shahin Sheidaei on his blog: Challenge, Estimate or Override (CEO) Game for Effective Estimations.  It is much quicker than the Planning Game, and probably a bit slower than the Bucket System.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Collaborative Estimation Technique: Challenge, Estimate or Override (CEO) appeared first on Agile Advice.

Categories: Blogs

Exploring Strengths with Core Qualities

Ben Linders - Tue, 09/08/2015 - 12:52
Teams can improve their way of working by exploring their strengths using a core qualities exercise in their agile retrospectives. The exercise described in this blog post, which is based on ideas from positive psychology and Solution Focused, helps team to become even better in things that they are great at. It enables them to deliver more value to their customers and stakeholders. Continue reading →
Categories: Blogs

Scrum Q&A Webinar on September 23

Ben Linders - Tue, 09/08/2015 - 10:54
Luis Gonçalves (co-author of our book Getting Value out of Agile Retrospectives) has invited me to his Scrum webinar series. I will be talking about deploying agile practices effectively, continuous improvement, agile retrospectives and much more. Continue reading →
Categories: Blogs

Evolution of a User Group

My favorite current user group is the Coder Consortium in Sacramento. It covers generally new languages or less popular older languages. The evolution happened over the course of several years. Originally the core of the group was a bunch of Java devs who were a bit disgruntled with the language and the frameworks and the whole Enterprisiness of it. A few of us started messing around with Groovy and Grails, especially given we couldn’t find paying jobs doing Ruby yet. Eventually we decided to start up a Groovy User Group.

The Groovy User Group ran for a few years overlapping with a large number of JUG regulars. We were able to try out some new tools and experience things like Spock or Griffon. Gradually though we noticed members experimenting with new JVM languages like Scala and Clojure. As that trend became more prevalent, we jokingly referred to the group as the Alternative JVM Languages Group.

Finally, about a year ago we morphed into the Coder Consortium. While the name may leave something to be desired we fully embraced newer and unusual languages both on and off the JVM. We tried to do an into to 10 languages in 2 hours, but I think we made it through 7 or so. And next week we’re lining up a talk based on this paper comparing a number of languages in Github.

Categories: Blogs

Coaching Corner: Advanced Agile Coach Class Coming - Materials Available Now

NetObjectives - Mon, 09/07/2015 - 21:43
Thought I'd let people know about Net Objectives' building an advanced Agile coaching class. This will essentially cover what we've learned over the last 10+ years of doing Agile at scale while being thought leaders in Scrum, Kanban and the Kanban Method.  The idea started out as we've been hiring great coaches but realized that not all of them had the deep toolbox we've built over the last...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

The Top 10 Project Management Books

J.D. Meier's Blog - Mon, 09/07/2015 - 19:22

"No one can whistle a symphony. It takes a whole orchestra." — H.E. Luccock

Being an effective program manager at Microsoft means knowing how to make things happen.  While being a program manager requires a lot more than project management, project management is still at the core.

Project management is the backbone of execution.

And execution is tough.  But execution is also the breeding ground of results.  Execution is what separates many teams and individuals from the people who have good ideas, and the people that actually ship them.  Great ideas die on the vine every day from lack of execution.  (Lack of execution is the same way great strategies die, too.)

If you want to learn the art and science of execution, here is a handful of books that have served me well:

  1. Agile Management for Software Engineering, by David Anderson.  David turns the Theory of Constraints into pragmatic insights for driving projects, making progress where it counts, and producing great results.   The book provides a great lens for thinking in terms of business value and how to flow value throughout the project cycle.
  2. Agile Project Management with Kanban, by Eric Brechner.  This is the ultimate guide for doing Kanban.  Rather than get bogged down in theory, it’s a fast-paced, action guide to transitioning from Scrum to Kanban, while carrying the good forward.  Eric helps you navigate the tough choices and adapt Kanban to your environment, whether it’s a small team, or a large org.  If you want to lead great projects in today’s world, and if you want to master project management, Kanban is a fundamental part of the formula and this is the book.
  3. Flawless Execution, by James D. Murphy.  James shares deep insight from how fighter pilots fly and lead successful missions, and how those same practices apply to leading teams and driving projects.   It’s among the best books at connecting strategy to execution, and showing how to get everybody’s head in the game, and how to keep learning and improving throughout the project.  This book also has a great way to set the outcomes for the week and to help people avoid getting overloaded and overwhelmed, so they can do their best work, every day.
  4. Get Them On Your Side, by Samuel B. Bacharach.  Stakeholder management is one of the secret keys to effective project management.  So many great ideas and otherwise great projects die because of poor stakeholder management.  If you don’t get people on your side, the project loses support and funding.  If you win support, everything get easier.   This is probably the ultimate engineer’s guide to understanding politics and treating politics as a “system” so you can play the game effectively without getting swept up into it.
  5. How to Run Successful Projects III: The Silver Bullet, by Fergus O'Connell.  While  “The Silver Bullet” is a bold title, the book lives up to its name.  It cuts through all the noise of what it takes to do project management with skill.  It carves out the essential core and the high-value activities with amazing clarity so you can focus on what counts.  Whether you are a lazy project manager that just wants to focus on doing the minimum and still driving great projects, or you are a high-achiever that wants to take your project management game to the next level, this is the guide to do so.
  6. Making Things Happen: Mastering Project Management, by Scott Berkun.  The is the book that really frames out how to drive high-impact projects in the real-world.  It’s a book for program managers and project managers, by a real Microsoft program manager.  It’s hard to do projects well, if you don’t understand project management end-to-end.  This is that end-to-end guide, and it dives deep into all the middle.  If you want to get a taste of what it takes to ship blockbuster projects, this is the guide.
  7. Managing the Design Factory, by Donald G. Reinertsen.  This is an oldie, but goodie.   One of my former colleagues recommended this to me, early in my career.  It taught me how to think very differently and much more systematically in how to truly design a system of people that can consistently design better products.  It’s the kind of book that you can keep going back to after a life-time to truly master the art of building systems and ecosystems for shipping great things.  While it might sound  like a philosophy book, Donald does a great job of turning ideas and insight into action.  You will find yourself re-thinking and re-imagining how you build products and lead projects.
  8. Requirements-Led Project Management: Discovering David's Slingshot, by Susanne Robertson and James Robertson.  This book will add a bunch of new tools to your toolbox for depicting the problem space and better organizing the solution space.  It’s one of the best books I know for dealing with massive amounts of information and using it in meaningful ways in terms of driving projects and driving better product design.
  9. Secrets to Mastering the WBS in Real-World Projects, by Liliana Buchtik.  If ultimate tool that project managers have, that other disciplines don’t, is the Work Breakdown Structure.  The problem is, too many project managers still create activity-based Work Breakdown Structures, when they should be creating outcome-based Work Breakdown Structures.  This is the first book that I found that provided real breadth and depth in building better Work Breakdown Structures.  I also like how Liliana applies Work Breakdown Structures to Agile projects.  This is hands down the best book I’ve read on the art and science of doing Work Breakdown Structures in the real world.
  10. Strategic Project Management Made Simple: Practices Tools for Leaders and Teams, by Terry Schmidt.  This book helps you build the skills to handle really big, high-impact projects.  But it scales down to very simple projects as well.  What it does is help you really paint a vivid picture of the challenge and the solution, so that your project efforts will be worth it.  It’s an “outcome” focused approach, while a lot of project management books tend to be “activity” focused.  This is actually the book that I wish I had found out about earlier in my career – it would have helped me fast path a lot of skills and techniques that I learned the hard way through the school of hard knocks.   The strategic aspect of the book also makes this super relevant for program managers that want to change the world.   This book shows you how to drive projects that can change the world.

Well, there you have it.   That’s my short-list of project management books that really have made a difference and that can really help you be a more effective program manager or project manager (or simply build better project management skills.)

Too many people are still working on ineffective projects, getting lackluster results, slogging away, and doing too much “push” and not addressing nearly enough of the existing “pull” that’s already there.

These are the project management books that build real competence.

And where competence grows, confidence flows.

Categories: Blogs

Knowledge Sharing

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