Skip to content

Feed aggregator

Global Scrum Gathering, Prague, Czech Republic, November 16-18 2015

Scrum Expert - Tue, 11/10/2015 - 10:39
The Global Scrum Gathering conference is a three-day event organized by the Scrum Alliance that explores the Scrum approach for Agile project management. The conference has 3 tracks that feature different senses of Scrum: Touch, Visual, and Auditory. Each track will host beginner and advanced sessions. In the agenda of Global Scrum Gathering conference you can find topics like “AdvanScrum – Spicing up your Scrum”, “Agile ...
Categories: Communities

What is an Agile Leader?

Henrik Kniberg's blog - Tue, 11/10/2015 - 07:37

Agile product development has become the norm in many industries (especially software). That means products are developed by small, self-organizing, cross-functional teams, and delivered in small increments and continuously improved based on real customer feedback. Pretty much as described in the Agile Manifesto – but replace the word “software” with “product” (because it really isn’t software-specific).

That’s all fine and dandy. However when things get bigger, with dozens of teams collaborating over organizational boundaries, things obviously get more complex and painful. Even if the entire organization is neatly organized into scrum teams, you can still end up with an unaligned mess! Here’s a picture that might feel familiar:

Misaligned teams

Before trying to “manage” this complexity, ask yourself “does it really need to be this big and complicated?”. Perhaps you are trying to build the whole elephant in one go. Perhaps your teams are organized by function, creating lots of dependencies. Perhaps your architecture is too rigid, too fragile, or too coupled.

So start by trying to simplify things. Some wise person said “Don’t scale agile – descale your org”. Maybe you can re-org into one or two teams with just the right mix of skills, all co-located and 100% focused and with direct customer contact. They may well be able to build the same product (or better) in half the time and for half the cost! Don’t fall into the mental trap of believing that more people = better. More people might be better in some cases, but the only thing you can be certain about is that more people = more cost and more complexity. The potential benefits are, well, only potential benefits.

But OK. Sometimes you really do need to get a whole bunch of teams and departments and vendors to collaborate on something big and complex. Let’s just say that’s the case. I’ll be nice and give you the benefit of the doubt.

If so, you most likely need a leader! Someone to focus entirely on coordinating the different teams, keeping the moving parts in sync, and keeping an eye on the big picture. And that’s what this article is about.

Agile relies on self-organization, which is super-effective (when done right). But with more than a handful of teams, self-organization sometimes needs a helping hand – someone to create and maintain the environment that enables self-organization in the first place – things like a clear goal, a short feedback loop, effective communication channels, etc. Essentially, make “1 + 1 = 3” (because of synergies) instead of “1 + 1 = 1.5” (because of misalignment).

Let’s call it the Agile Leader. And the main job is to create alignment!

Agile Leadership

At the team level agile methods already include leadership roles such as Product Owner and Scrum Master. But at a multiteam-level there is no formal leader role defined. That’s because smaller efforts usually don’t need a single appointed leader – the success of Scrum has shown us that effective leadership can happen without a single appointed leader. However, the more people involved, the more likely you are to need a dedicated leader, a full-time person who focuses on just that – regardless of whether you call your multi-team effort a “project”, a “program”, a “bet”, a “product” or whatever.

The leader doesn’t necessarily need to be one person, it can be a pair, or a small tight-knit team – as long as they collaborate tightly and speak with one voice. For the purpose of this article i’ll assume it is one person.

Example: At Spotify, most medium-to-large initiatives are led by a “TPD trio” – a small leadership team consisting of one person from Tech, one from Product, and one from Design. That way we make sure all three perspectives are always taken into account. However, for large efforts that span far beyond just tech and product and design, the trio isn’t enough. Should the trio be expanded, or should we have an additional leader role? And what should we call such a role? We’re still experimenting with that.

Think of the label “Agile Leader” as a placeholder for whatever you decide to call the role. If depends a bit on how you organize your work. Pick whatever title fits your context – Chief Engineer, Chief Product Owner, Project Manager (if it is a project), Program Manager, Uber Scrum Master, Release Train Engineer, Chaos Pilot, Road Manager, Zen Master, Coordinator, Driver, Project Coach, Catalyst, or whatever. Whatever you call it, it is critical function and it needs to be there for any complex cross-functional endeavor that involves more than a handful of teams. The person(s) in that role need to be motivated, dedicated, and skilled.

I intentionally call it Agile Leader in this article. The word “Agile” is there to emphasize that this article is about an agile product development context, which is very different from a waterfall context. I use the term “Leader” instead of Manager because, well, in a well-running agile organization most “management” is handled by the teams themselves. So the primary purpose of the role is to provide leadership, not management. But the distinction isn’t binary, of course.

The purpose of this article is to paint a picture of what a great Agile Leader does, so you can more easily find, grow, or become this person – and help your multi-team efforts succeed better! This is not a formal definition of the role, just my take on it.

So, in short: try to minimize the need for big, complex, multiteam efforts. If you can’t then at least make sure you have an awesome Agile Leader!

Isn’t this a Project Manager?

Maybe, but not necessarily. A “project” is just one of many ways to organize work, and often inappopriate for product development. However, If you do work in Project form, and the projects are fairly big and complex and involve synchronization among many different teams and organizations, then the Agile Leader is effectively an Agile Project Leader. I wrote a separate article called What is an Agile Project Leader, with some discussion about the project model in general. But for the actual role description that article links back to here. Don’t get stuck in a loop :)

Again, the choice of what to call the role is highly contextual. The purpose of this article is just clarify what type of leader you will need to execute it in an agile way.

What does an Agile Leader do?

My Spotify colleague Babar provided a nice summary, using a sports analogy:

  1. What does winning look like? Vision/Mission.
  2. What’s the plan? Strategy and tactics.
  3. What’s the score? Progress, status, feedback loops
  4. What is preventing us from winning? Continous improvement, people, teams, strategy, tactics.

Do we all know why we are here, what winning looks like? Do we know the plan, the strategy? Do we have a way of seeing where we are now? Do we see the impediments, things that are slowing us down? Are we continuously trying to remove the impediments?

The answer is most likely “no” to some of these questions (otherwise, congrats, keep up the good work). So that’s the job of the Agile Leader – do whatever it takes to turn these into “yes”. That won’t guarantee success, but it will certainly increase the odds.

In a smaller efforts using Scrum, this work is covered by existing roles and bottom-up cross-team collaboration. With large efforts we face misalignment across teams, and things falling into cracks between different parts of the organization. So the Agile Leader focuses a lot on communication and creating clarity. If everyone involved has the same view of where we are, where we are going, and why, then we are more likely to work together to move in that direction.

Uh, be more specific. What does the Agile Leader actually do?

So what does this mean in practice? What does an Agile Leader actually do?

I hate to say it, but…. it depends! There. I said it.

It depends on context, and what’s working well today and what’s not.

Keep asking yourself: “What needs to happen that’s not already happening? What can I do to cause this to happen, without becoming a bottleneck myself?”

Example: You notice that releasing is a pain, and that we need better release coordination between teams. Instead of running around trying to coordinate this yourself, you bring up the problem with some of the teams – check if they agree that it is a problem, and discuss how we might deal with it. Together you decide to set up a recurring meeting where people that have stuff to release sync with each other, and provide a shared living document where they can see and edit upcoming releases. Initially you facilitate the meetings yourself, but after a while they become self-managing. You encourage the teams to automate as much of release management as possible. Over time the recurring meeting isn’t needed, because the teams talk to each other directly and release coordination is no longer an issue.

Although I can’t tell you exactly what an Agile Leader should do, I will give a list of examples. Think of it as different “lenses” you may wear as leader. You might be doing some of these things yourself, but for the most part you should be creating a context where these things get done without your involvement.

NOTE: I use the term “ensure” below. Obviously a leader can’t force these things to happen, so in this context “ensure” = “do whatever you can to create a context where this happens”. In practice this may involve facilitating, encouraging, arguing, challenging, organizing meetings, creating documents, visualizing stuff, informal hallway conversations, etc.

So, here’s the list. Take a deep breath:

  • Vision/mission. Ensure the the work being done has a clear purpose, clear hypotheses, clear boundaries/scope (“what are we NOT doing”), and clear success metrics based on business impact rather than deliveries. Ensure this is crystal clear to everyone involved, teams as well as customers and other stakeholders.
  • Iterative and incremental delivery. Ensure that the work is split into sub-deliveries, to enable iterative and incremental delivery rather than big bang.  Avoid large projects whenever possible, instead try to split the work into a series of smaller projects whenever feasible.
  • Adaptive planning. Ensure that plans are created and communicated to everyone involved. Ensure the plans are adaptive rather than predictive, and updated as we learn. Ensure that deadlines are communicated and forecasts created as necessary, and updated based on empirical data as the work progresses. Make sure any constraints (date or scope) are clear to everyone.
  • Feedback.  Ensure a short feedback loop with tight and frequent communication between teams and customers. Collaborative planning, demos, etc. Ensure that hypotheses and assumptions are field-tested early and that learning happens continuously. Ensure that progress is measured based on actual deliveries and feedback and business impact, not by compliance to plan.
  • Continuous improvement and knowledge sharing. Ensuring that learning and improvement happens continuously as the work progresses (not just at the end), and that key learnings are shared within the teams as well as across different parts of the organization.
  • Focus and alignment. Ensure that participants are focused and dedicated (not multitasking), and aligned with the same list of priorities. Bash silos. Ensure that people are focusing on achieving the highest possible business impact with the lowest possible effort and output (working smart is more important than working hard).
  • Impediment removal. Ensure that waste and impediments are visualized, prioritized, and systematically removed. Encourage teams to own and solve their own impediments whenever possible. Collaborate with other managers and take ownership of impediments that are escalated.
  • Decision enablement. Ensure that decisions are made in a just-in-time manner and by the people who have the best insight into the matter, decentralized whenever possible. Ensure that nobody (including you) becomes a decision bottleneck. Minimize the number of decisions that have to be made by you.
  • Visualize status and progress. Ensure that everyone can see the “big picture” – dashboards and such showing where we are going and why, where we are now, impediments, etc. Keep it at a high level, leave the details to the teams.
  • Flow. Optimize for end-to-end flow of value, not resource utilization. Look for bottlenecks and queues, and apply systems thinking and lean principles to streamline the delivery of business value.
  • Self-organization and autonomy. Make the goal and current situation clear so that people can think and act autonomously, with no need for you to tell them what to do.  Ensure people are given problems to solve rather than tasks to execute. Harness the collective intelligence of the group, rather than trying to be a mastermind yourself.
  • Staffing and capacity planning. Work with managers to ensure that the right people and teams are available at the right time to maximize the velocity and chance of success.
  • Budgets and estimates. Ensure that any budget and contractual constraints are known and managed.  Ensure that estimates are done by the team closest to the work at hand, kept at a high level, and adjusted when necessary. Ensure that estimates are treated as estimates, not promises. Make costs transparent.
  • Dependencies. Ensure that cross-team and cross-company dependencies are visualized and managed effectively, and that teams aren’t blocked waiting for each other.
  • Cross-functional collaboration. Use techniques such as co-location and cross-functional communication channels to reduce siloing and suboptimization.
  • Communication. Create an environment that facilitates high bandwidth face-to-face communication and minimizes the need for unnecessary documents, emails, and other low-bandwidth communication. Documents should be used to support communication, not replace it.
  • Fast failure. Create a context where small failures can happen early and often, thereby reducing the risk of a big failure at the end.

Special point: Motivation. Motivation is the key currency for any creative, complex endeavor – much more important than man-hours. Motivated people build better stuff faster. The difference can be quite mind boggling! But motivation is not a separate point – you can’t just “motivate people”. Instead, people will be intrinsically motivated by things like Autonomy, Mastery, and Purpose.

A good guiding principle is “Don’t motivate people – remove the demotivators”. If people see you removing real impediments and creating a high-trust environment that helps them work effectively – that will probably motivate them a lot more than things like hawaiian t-shirt fridays, free drinks, and ping-pong tables.

Uh, that’s a loooong list! Where do I start?

Distill it into a shorter list for your context!

For example, get together with some folks, rate each item based on “how important is this for us” and “how well is this working today”. Then shorten the list to the top 5 things that are important and not working well today. Use that as a basis for finding a suitable Agile Leader (or for prioritizing your work, if you are the leader).

What about accountability?

So is the Agile Leader a single point of accountability? Is this the single wringable neck in case of failure (for some definition of “failure”…)?

No, certainly not! Everyone involved is accountable. But people should be accountable for their behaviours, not results.

That may sound crazy at first glance, but think about it for a moment…

A product may fail to succeed despite all the best efforts of the team – it may fail for random reasons, it may fail because of acts outside of the team’s control. And vice versa, a product may succeed despite crappy efforts from the team and leaders, it may succeed because of blind luck or because there was no competition. This is complicated by the fact that failure and success is usually hard to define, with a big fat gray zone in between.

An Agile Leader should ensure that, when things fail, they fail early! She does that by building in a fast feedback loop (frequent delivery to customers, validated learning, etc). She ensures that we learn from the failure and use those learnings in the next product, or next iteration of this product.

If we punish failure, we incentivize people to hide failure, and thereby minimize learning. If we punish failure, we incentivize people to avoid all risk, and thereby kill innovation. Failure (and the associated learning), should be celebrated, not punished! To a limit, of course. Keep the feedback loop short, so failures aren’t fatal…

So although the Agile Leader may act as the “face” of this project/program/product/whatever to external stakeholders, she is not personally held accountable for success or failure. She is however, held accountable for behaving in a way that maximises the odds of success. And this applies to all participants, not just the Agile Leader.

What kind of person is suitable for the role?

At the minimum, the Agile Leader needs to (in my opinion):

  1. Passionate about the product, customers, users, and business impact.
  2. Be excited about the Agile Leader role and willing to focus on it 100%
  3. Buy into most of the role description above, and want to grow in that direction.
  4. Have at least some real-life leadership experience (in any context)
  5. Have at least some real-life experience with agile ways of working (in any role)
  6. Be willing to get training/coaching/mentoring for the skills that are weak or missing
  7. Be willing spend time learning and continuously improving their skills as agile leader.

There is obviously no “perfect” Agile Leader, but below is a “Definition of Awesome”. I don’t expect anyone to fullfill all these points, but the more the better :o)

In a perfect world:

  • You are business-minded and passionate about getting people aligned towards a common goal.
  • You have experience managing large, cross-functional efforts (e.g. spanning functions such as engineering, marketing, content, legal, and others). Agile or not. Some of best leaders I’ve seen come from big failed projects – they know how not to run a project.
  • You are flexible and pragmatic about methods and processes, and are able to use your judgment to apply the model and approach that fit best with the context.
  • You have deep understanding and experience of agile and lean thinking, and some experience with concrete frameworks and techniques such as Scrum, Kanban, Lean Startup, and Continuous Delivery.
  • You steer clear of waterfall projects, but you also understand that Agile doesn’t mean No Planning or No Architecture.
  • You know how to provide strong leadership and guidance, without become a bottleneck.
  • You know how to get people inspired and rallied around a higher purpose.
  • You understand that people are people, not just resources, and that focus and motivation matter a lot more than man-hours.
  • You understand that people are most motivated and effective when given a problem to solve, rather than a solution to implement.
  • You know how to get people talking with each other across departments and other organizational borders. You aren’t scared off by politics.
  • You know how to enable self-organization in large cross-functional efforts, and how pull-based scheduling works in practice.
  • You know how to make the important stuff visible.
  • You have a knack for spotting waste and calling it out.
  • You understand that plans are important, but they are a tool and not a goal, and must be updated as you learn.
  • You understand that uncertainty is a fact of life when innovating, and is best managed through a tight feedback loop rather than detailed upfront planning.
  • You hold people accountable for their behaviour more than their results. You reward people for learning rather than punishing them for failing.
Final words

I hope this doc helps you improve the success rate of your large multi-team efforts. But don’t forget – scaling is a last resort. Scaling hurts no matter how you do it, so keep things as small as possible (but no smaller…).

Big thanks to Alistair Cockburn, Mary and Tom Poppendieck, Anders Haugeto, and a bunch of Spotifyers and Crispers who helped improve this article. I’m honoured to have such an awesome group of advisors!

Note that this my personal opinion, my take on what an Agile Leader is (or should be). Some people may disagree, that’s fine. I’m also happy for feedback, although I won’t always have bandwidth to respond.

Further reading (there’s infinite material on agile leadership, but here are some things that I happened to have read and liked):


Categories: Blogs

What is an Agile Project Leader?

Henrik Kniberg's blog - Tue, 11/10/2015 - 07:35

I wrote this article because of two observations:

  1. Many organizations use a “project model” when they shouldn’t.
  2. There is a lot of confusion and debate in the agile community about projects and project leadership.

I don’t claim to have “the answer”, but I’ve thought about this a lot and also experimented on my clients (don’t tell them… sshhhh). So, here is my take on project leadership in an agile context.

Oh, and by the way, this article is a Bait & Switch. I’m trying to get you to read What is an Agile Leader. You might save time by just skipping this and going there right away :)

Beware of “projects”

The word “project” is controversial in agile circles. Some companies use the “project model” as some kind of universal approach to organizing work, even for product development. However, a surprising number of projects fail, some dramatically. I see more and more people (especially within the software industry) conclude that the project model itself is the culprit, that it’s kind of like rigging the game for failure.

A “project” is traditionally defined as a temporary effort with a temporary group of people and a fixed budget. Product development, on the contrary, is usually a long term effort that doesn’t “end” with the first release – successful products start iterating way before the first release, and keep iterating and releasing long after. And teams work best if kept together over the long term, not formed and disbanded with each new project. Also, the traditional approach to planning and funding projects often leads us to big-bang waterfall-style execution, and hence a huge risk of failure because of the long and slow feedback loop. The project model just doesn’t seem to fit for product development.

I’ve spent many years observing and helping companies improve the way they develop products, and the trend is very clear – less project focus, more product and team focus. Seems to work a lot better! So it’s no coincidence that “Projects” and the “Project Manager” role are absent in the most widely adopted agile frameworks such as Scrum, Kanban, XP, and SAFe.

What about project management?

So what happens to project managers then? Aren’t they needed?

Wrong! Project Management hasn’t disappeared, it’s just been redistributed. The thing we are managing is a product, not a project, and management is too important to leave in the hands of a single person. In Scrum, for example, the project manager role was deliberately split into two separate roles – Product Owner (focusing on the product), and Scrum Master (focusing on the team), and the team manages itself rather than “being managed” by a PM. So most of “project management” still happens but in a different way – mostly decentralized.

What about projects? Should we abandon that model entirely?

No, don’t abandon projects entirely, just shift the default. In particular for product development, projects should be the exception, not the norm. In a typical agile context (Scrum, XP, Kanban, Continuous Delivery, etc), the project model and project manager role is often redundant and will slow you down.

But wait – what if you’re going to do something that requires a coordinated effort across many teams from different parts of the company that don’t normally work together? What if you have lots of external and internal dependencies, content licensing, hardware procurement, external vendors, regulatory compliance, and offices in multiple time zones?

Misaligned teams

THAT might be worth treating as a “project” – especially if it is a temporary effort rather than something continuous. Basically, if the whole thing has a “definition of done” then maybe it’s a project.

However, regardless of whether you call it a “project” or not, if it’s big and complex you will need a leader. And if you want the work done in an agile way, you’ll need an Agile Leader (or Agile Project Leader if you prefer). Doesn’t much matter what you call the role, there just needs to be someone at the helm (or a pair, or a small team fulfilling the role).

  • Myth: “But we’re agile and self-organizing, all these teams will magically coordinate with each other and stay aligned without a leader!”
    • My experience: You’re probably kidding yourself. Or maybe you are a rare exception.
  • Myth: “Project Leader means top-down micromanagement and big-bang waterfall processes.”
    • My experience: Only if the project leader doesn’t get Agile. Get the right person for the job (this article will hopefully help!)
  • Myth: “All projects have to be agile”
    • My experience: Not necessarily. If the work is complex and innovative, then yes. If repetitive we’re-cranking-widgets-and-we’ve-done-this-dozens-of-times-before, then probably not. Most product development falls into the first category. But I’m biased though, I’ve worked mostly with innovation-driven product companies.

So, in short: don’t use projects for everything – but when you do, make sure you have an awesome Agile Project Leader!

So what is an Agile Project Leader?

This started out as a fairly long article. Then I realized that the role I was describing was really about agile leadership in general, and not specific to the project model at all.

An Agile Project Leader is really just an Agile Leader that happens to work in a project context. So I moved that role description to a separate article, so as not to scare away people who are allergic to the project model :)

Hop over and read that article, and mentally swap in the word “project” wherever it makes sense. Told you this article is a bait & switch :)

Agile Leadership

There are some things that may be different in a project context – for example the “change agent” aspect. By definition, a project is something different than your “business as usual” work, and most likely involves collaboration between teams and departments that don’t normally work together. Unfortunately, since we’re dealing with people, this usually means some amount of politics and diplomacy. Hence, a project leader needs to deal with organizational (and cultural) boundaries – either breaking down the boundaries or improving collaboration across the boundaries. That’s a tough job, so don’t forget to give your project leader a pat on the back from time to time.

Final words

I hope this article (and the other one) helps you improve the success rate of your projects, regardless of how you solve the leadership issue! And don’t forget – despite all the talk about projects in this article, always start by asking yourself if you even need a “project” at all.

Big thanks to Alistair Cockburn, Mary and Tom Poppendieck, Anders Haugeto, and a bunch of Spotifyers and Crispers and Legoists who helped improve this article. I’m honoured to have such an awesome group of advisors!

Note that this my personal opinion, my take on what an Agile Project Leader is (or should be). Some people may disagree, that’s fine. I’m also happy for feedback, although I won’t always be able to respond.



(Why are you still here? Go read What is an Agile Leader!)


Categories: Blogs

Why No One Wants To Grow Up to Be an Enterprise Architect

I recently attended a meetup for Enterprise Architects. I had to deal with the EA world years ago when I was reorganized into managing a brand new Enterprise Architecture Department. I remember trying to make the best of it and even being hopeful that EA and Agile could be combined. I only stayed in the position about 9 months before moving onto another Application Development Manager at a new company.

I ended up leaving the meetup quite early after the discussion veered heavily into consulting, no one listening to the EAs, enterprise data models, and governance. When the topic of coding was brought up the consensus was EAs don’t code. At that point I realized I was in an alien environment and it was time to exit.

Architects and Enterprise Architects are widely disliked by many developers. The reasons are numerous:

  • Enterprise Architects are often very siloed and rarely interact with the rest of the developers.
  • EAs sometimes take pride in statement’s about not coding, but insist on choosing development tools and platforms for the organization.
  • Governance is used as a stick to force developers to only use approved technologies
  • Documentation and EA Frameworks are valued over making progress on solutions.

Having transitioned back to software based companies I can’t see ever stepping back into a company that actually has an EA department.

Categories: Blogs

Measuring the Cost of Story Points

Scrum Expert - Mon, 11/09/2015 - 17:34
Story point is a arbitrary relative measure used by Scrum teams to define the effort required to implement one story. In this article, Mahfoud Amiour proposes an approach to measure the cost of story points implementation. Mahfoud Amiour has defined from his experience as an Agile consultant a metric to measure the cost related to the implementation of story points. This metric is called SPOC (Story ...
Categories: Communities

Taking Organizational Improvement Seriously – Case Study

Notes from a Tool User - Mark Levison - Mon, 11/09/2015 - 16:12

Organizational Improvement

(Presented as an accompanying case study to Part 4 in the Scrum Alone is Not Enough series.)

In the previous post, we discussed how it’s not enough to practice Scrum at the Team level and expect that it will solve all problems. Senior Management has to get involved for real Agile change to happen and high performance to be achieved. An important aspect of that is Systemic Problem Solving, which we’ll look at closer using the World’s Smallest Online Bookstore as a case study for examples.

Systemic Problem Solving

Most teams that I encounter are very good at solving specific problems locally (at the team level). What is missing is a bigger picture, holistic view. Systems thinking (pdf) is a tool that helps you take a Systemic – or bigger picture – view of whole systems.

Let’s look at a couple of common organization problems as examples – namely “Long Regression Cycles” and “Product Owner can’t seem to stay focused on the big picture”.

Long Regression Cycles

Hereafter: LongRegressionCycle

The Org Team recognizes that it has a problem with the regression cycles as illustrated:

Regression Runtime in Days

When long regression cycles are an issue, without a systemic approach the organization might first try adding more people to do regression testing. As a second step, they might try automated testing through the browser/GUI using a special team who has access to an expensive tool. Unfortunately, as we see below, this will likely lead us down the wrong path:

Long Regression Cycle

This is a simple causal loop diagram –it’s intended to help us look past the initial problem and see deeper causes.

Variables create cause and effect within a system. In a causal loop diagram, you start with a single part of the system that you can already identify and just keep asking “what influences this part?” then draw links between the interconnected parts using arrows pointing in the direction of influence. Once you can no longer think of additional parts or influences to add, you have a closed loop.

In this example, we can envision what may happen by playing through the loop, starting at “Features added” and following its influence to the “Regression Cycle Length”. Keep going, and we can see that the often-used simple fix of asking a special team to automate regression tests through the Browser/GUI influences many variables and eventually exacerbates the problem that it was intended to solve.

The diagram makes it clear that GUI based automation is fragile, and having all the work done by a special team is creating an island of knowledge. These two problems combine, increasing the time it takes to find bugs and eventually even increases the number of bugs themselves.

To solve the underlying initial problem, we would have to also find an approach that doesn’t recreate these same issues! Instead of a special team doing all of the test automation, the work should be done by every team. Instead of doing all the automation through the browser, do most of it through public api’s (or their equivalent) that exist at the boundaries of the system.

Before making any change, the team creates a new version of the causal loop diagram to see if their proposed solution is an improvement on the original.

Product Owner Can’t Stay Focused on the Big Picture

Hereafter: UnfocusedProductOwner

In a second example, the Team sees a Product Owner making frequent revisions to the Team’s work in Sprint. We can talk to the PO about this, but we can’t just expect the PO to change unless we also identify and fix the underlying problem.

PO can't stay focused

As this image illustrates, we can see that the real problem is that the PO is under daily pressure from stakeholders to solve real and perceived customer problems. The challenge is how to set aside enough time to deal with those issues, while still making progress in the bigger goal. A causal loop diagram like this should help the organization discover the need for Portfolio Management, which would give the Product Owner some boundaries on how much short term work they should accept from the Team.

In each case, the key point is that the Org Improvement Team must make sure that they’re solving the systemic – and not just surface – problem.

So let’s look at how the World’s Smallest Online Bookstore teams might do that, using a Scrum-like framework to achieve it.

Our World’s Smallest Online Bookstore Organizational Improvement Team is working in two-week Sprints to stay in sync with their Development Teams. As we learned in this post, the Org Improvement Team operates in a manner similar to a regular Scrum Team, just with a few slightly relabeled components.

Let’s see how the Organizational Improvement Team will tackle these problems.

Organizational Improvement Queue (aka Product Backlog)

Since the causal loop diagrams above showed us that creating special teams for test automation and simply asking the Product Owner to change weren’t going to solve the problems.

The Org Team can avoid wasting time on ineffective, localized solutions and focus the Improvement Queue on finding specific things that will contribute positive systemic results. Such as:

  • LongRegressionCycle – Involve more members of each Development Team in test automation;
  • LongRegressionCycle -Find alternate means to test automation that don’t involve the browser;
  • UnfocusedProductOwner – Support the Product Owners in saying no to more expedited customer requests…
Organizational Queue Refinement (aka Product Backlog Refinement)

After discussion with the Development Team representatives and the Team level Product Owners, it is agreed that the pressure that the POs feel to respond to all customer issues within two days is getting in the way of the Teams delivering on both quality (which leads to more customer issues) and the big picture. They also identify the need for site license JetBrains IntelliJ and “Reducing Product Build Times from 15 minutes to 5 minutes”.

Sprint Planning

The Org Improvement Team commit to running several experiments to resolve the UnfocusedProductOwner challenge. Since this problem will need several months to address completely, they decide to do the following:

  • Limit the number of Customer Expedite Issues that a team will be asked to handle in one Sprint to two (down from the four that currently happen most Sprints).
  • Suspend the current PO bonus system for 6 months – taking the bonus pressure out of the equation for now. Wisely they don’t try to get rid of this altogether yet – while bonuses are often distortive and lead to strange behaviours in the short term, this is too big of a problem to tackle at this time. Instead, they’ve delayed dealing with until a later date.
  • Give the existing Portfolio Management Team a stronger mandate. Once decisions are made at the Portfolio level, these goals supersede the needs of any one customer. If there are special customer needs, they need to be approved at the Portfolio level and not just left to an individual PO.
  • In addition, to stem the worst of the problem with LongRegressionCycle, they suspend the current automation through the browser approach for now. This isn’t really a solution, it’s just avoiding making a bad situation worse. In the context of the SmallestOnlineBookStore, this may be the best that the Org Improvement Team can do for now.

The first three tactics are really just trying to give an already good PO some better tools to say no to all except the most important customer issues.

In addition to the big item that the Org Improvement Team committed to tackling, I would also find a couple of smaller, high-priority items that are likely achievable in the first sprint, such as the JetBrains Site license and “Improve Build Times by at least 5 minutes.” This won’t solve all of the problems for the Product Owners – just a manageable first step for one Sprint, which will be valuable to get the Team started, show the rest of the company that change is coming and prove to the Organizational Improvement Team themselves that they can make change.

In Sprint

Org Team Members work with ScrumMasters, Team Level Product Owners and some team members to update the Portfolio Kanban Board. They review the Portfolio Kanban Board with the rest of the management team including the C-level execs so there is a clear of understanding of which features will delivered in the near future.

Daily Scrum

Several times in the week the team members gather on the edge of the Dev Team work areas for their equivalent of a Daily Scrum. They make it clear that the events are open to all and share information about the progress on their commitments for the Sprint.

Sprint Review

At the end of the Sprint, the Org Improvement Team review how many Customer Expedite Issues each of the Development Teams had to deal with. While there was a reduction, it is still higher than their commitment in Sprint Planning. This hints that on the next Sprint, the Org Improvement Team might consider more action.

In addition, the Build Times have reduced by 3 minutes, from 15 to 12. The people who put the effort into this explain that the simplest improvements have now been done and further reductions will require upgraded hardware or parallel builds.

They invited all interested Dev Team members to the event so that the news of the improvements (small as they were) started to spread.


The Org Improvement Team realize that part of the reason they didn’t meet all of their goals this Sprint is a lack of time dedicated to solving the systemic problems. For their SMART goal, they commit to each helping drive at least one issue to truly done, setting aside other executive work if required.


In our last post we saw what we needed:

 “Respondents report that senior management sponsorship and support is far and away the most important factor in adopting Scrum.” (2015 State of Scrum Report)

To succeed:
  • Small Wins – the Org Improvement Team are making an effort to start to resolve the bigger challenges
  • Communicate – the Org Improvement Team engaged the Dev Team Members in the formal events (Daily Scrum and Sprint Review) and informal conversation to share their progress
  • Show how we’ve engaged Management to constantly review Portfolio Board, to understand Scrum, and to be involved in solving the problems that Scrum finds – the Portfolio Kanban board was reviewed by Senior Management with Dev Team Members present
  • Build on the previous successes – they haven’t been working long enough at this yet
  • Tie changes back to the bigger reason that the organization is undertaking the change (usually Quality or Time to Market). – the Org Improvement Team explains to all that the solving the Product Owner focus problem will help improve Time to Market and also Quality

Even with an Organizational Improvement Team, problems still aren’t easy to solve,  but they’re solved more easily when addressed at the right level.

Categories: Blogs

How Does A JavaScript Function Define A Type And Create Object Instances?

Derick Bailey - new ThoughtStream - Mon, 11/09/2015 - 14:30

I recently received a question from someone going through my Mastering JavaScript “this” email course, regarding day 3 of the course, where I talk briefly about constructor functions and the “new” keyword.

Cutting out pattern

In this course, I say:

The value of “this” inside of the constructor function is a new instance of that object type, where the “type” is defined by the constructor function, itself.

The question from the reader centered around type definitions and functions:

How does a constructor function define a type?  Isn’t it just a function?  What qualifies a function as a constructor function – other than the ‘new’ invocation pattern?

It’s a question that confuses a lot of developers – myself included. But, honestly, that’s about it.  It is possible for any valid JavaScript function to be a constructor function, just by adding the “new” keyword in front of it.  

But that doesn’t mean every function out there is designed to work this way.

Constructing An Object From A Function

Every function you define in JavaScript has the potential to be a constructor function. You can see evidence of this by looking at the “.prototype” attribute of any function you define (in Chrome DevTools, for example.


The .prototype attribute of the function is used as the prototype of the object instance, when you call the function with the “new” keyword.


The object is also said to be an instance of that function’s name… the “type” that was defined with the function.


The “s” object in these examples is clearly an instance of “something” with a prototype defined by that function.

But, how does that happen?

The Magic Of “new”

Behind the scenes, when you call a function with the “new” keyword, the JavaScript runtime is basically doing this:

  1. Create a new object instance
  2. Assign its prototype to the function’s .prototype
  3. Apply the function with the object instance set as “this”

Granted, this is a greatly over-simplified representation of what happens, but it is the core of the process. 

Because every function you define has a .prototype, and because of the way the “new” keyword behaves, it is possible to use just about any function as a constructor function to create new instances of that “type”.

But just because you can, doesn’t mean you should. 

Not All Functions Are Created Equal

Most functions are just functions that do some work and maybe return some value.

You could use the “new” keyword in front of any random function, if you wanted to, but the results would not be predictable if it was not intended to be a constructor function. 

For example, look at the following code and ask yourself what it would return as a plain function call vs a construction function call.

If you call this as a plain function, it will return the string as you would expect.

But what happens if you call it as a constructor?

In this case, the function no longer works as expected – the string that you wanted will not be returned. 

Yet, in another example, the return value of the normal function will still return as expected:

In this case, both the standard function call and the constructor function call return the same value.

When you have a constructor function, there is an implicit return value – the new object instance. You are allowed to override this return value with your own object instance, though – as shown in the second example.

What you are not allowed to do, is override the object return value with a primitive value like a string. The Javascript runtime will ignore the primitive return value and send back the object instance, instead. 

Don’t worry, though. It gets worse! And it does get better – especially moving forward with ES6 and beyond.

Object Methods As Constructors

In object-oriented JavaScript, an object typically has methods. These methods often make use of the “this” keyword. 

So, what happens when you have an object with a method, like this one below, and you apply the “new” keyword to it?

The result is not a pretty site:


The use of this function as a constructor has clearly broken things.

The value of “this”, when the function is used as a constructor, is not the value of “this” that the function expected. It was designed to use the object itself as “this”, but that expectation was not met. The code tried to run anyways, and very bad things happened as a result. 

But this isn’t always the case. There are times when you will have an object with a method, and it is meant to be used as a constructor function. For example:

In this case, “Company” is acting as a namespace, not a standard object. On the Company namespace, a “Department” type has been defined. This Department method is intended to be used as a constructor function.

So, what’s the difference between these two examples? How would someone know that a method is or is not supposed to be a constructor function?

Idiomatic Constructor Functions

In general, there is a common practice for naming functions with a capitalized name, to identify them as a constructor function. They also tend to be named as a noun.

For example: 

being a capitalized function name, and being a noun, there’s a high likelihood that this is supposed to be a constructor function.  Whereas, this function: 

is not likely to be a constructor function.

The naming convention follows a standard for a function that just returns a value. It’s not capitalized, and it has the word “get” in it – a word that typically means the function will return some value. 

There isn’t anything special about capitalized names for functions, though, other than a generally agreed upon standard by which most JavaScript developers work. This is, by definition, idiomatic JavaScript. 

Unfortunately this mean the the standard practices of JavaScript function names are often the only thing that separate you from a new object vs a runtime disaster. At least, until ES6 classes came around.

ES6 Classes And Type Definitions

With ES6 (officially ES2015), JavaScript tried to clarify type definitions by introducing “class” syntax. If you’ve ever worked in C#, Java or other C-syntax languages with classes, this syntax should look fairly familiar.

In this example, a simple “Bar” class is defined and a “doStuff” method is added. An object instance is created and the doStuff method is executed as expected.

What you might not realize, with this syntax, is that it is mostly just syntax sugar on top of the existing constructor functions of JavaScript.

Yes, there are some real differences in class syntax vs constructor function syntax, but once a class is defined, it is actually a constructor function (as shown by Node v4+):

As you can see in this output, the class Bar does produce a constructor function. However, it is not a “normal” function in that it cannot be called without “new”

This is one of many differences with ES6 Classes. 

The behavior of ES6 classes may be somewhat different, but in the end, it is still a constructor function with a .prototype that defines the JavaScript type at runtime.

Functions And Type Definitions

The ability to use nearly any function as a constructor by using the “new” keyword means it is possible to get yourself into some sticky situations if you’re not careful. Just because you can use any function as a constructor, doesn’t mean you should. Idioms and good document should exist to help us identify which functions should be used this way.

The ES6 syntax for class definitions attempts to move JavaScript away from this danger zone, but still builds upon the original concepts of constructor functions. And creating more possibilities, still, it is entirely possible to build object instances with prototypes, not using constructor functions. This is prototypal inheritance, after all – even with ES6 classes. 



Want To Know More About Types And Prototypes?

If you’re interested in knowing more about JavaScript’s type and prototype, check out the WatchMeCode screencasts covering both JavaScript fundamentals.


With the JavaScript fundamentals series, you’ll learn everything you need to know about objects, functions, prototypes, and more. From simple object definitions to object composition, from prototypal inheritance to constructor functions, the JavaScript Objects And Prototypes episode will cover everything you need. Then, with additional episodes covering variable scope, the dreaded “this” keyword and so much more, you’ll be on your way to mastering JavaScript, fast! 

Learn more JavaScript in minutes than you have in years with WatchMeCode screencasts.

Categories: Blogs

5 Questions to Ask Before Hiring or Promoting an Agile Leader

Illustrated Agile - Len Lagestee - Mon, 11/09/2015 - 03:03

Your Leadership Legacy Starts Here

As a leader in an organization one of your many expectations would be to determine when one of your direct reports are ready to be promoted into a leadership position or deciding who should be hired from the outside into an open leadership position reporting to you. When promoting internally, this often means deciding when an “individual contributor” should become a first-time manager. When hiring from the outside, this often means determining how this person will fit with the culture of your team, department, and company.

While this responsibility to hire and promote will always be important, for organizations attempting to transform their culture to an environment of agility the cost of a poor decision is magnified exponentially. Regardless of any holistic progress you are making in transforming your organization, a single “bad” leader can keep meaningful and revolutionary change from happening. As Scott Berkun states, “Culture is local to each boss.”

Each leader you select becomes a piece of your leadership legacy so with each choice you will need to decide what the “local culture” will be for the people reporting to their new manager. Your new leaders MUST be able to model the leadership behaviors and activities conducive to the new culture being introduced.

Often, this assessment is not easy but from my experience and observations, here are 5 questions you can ask yourself to help make the decision:

Can this person envision a future few others can see?

A compelling vision. As Robert Greenleaf states in Servant Leadership, “A leader needs to have a sense for the unknowable and be able to foresee the unforeseeable. This is partly what gives leaders their “lead,” what puts them out ahead and qualifies them to show the way.”

If the only reason you are promoting someone is due to constraints in their current salary band or because they can “put out fires,” this may come back to haunt you. Even with technical leaders such as development or testing managers, they are able to craft a view of the future within the space they are leading.

Given a choice, would people willingly follow this person?

Willing followers. For most people their leader/manager is chosen for them. An organizational chart is created or refined and people are assigned to their new boss. Very rarely can people choose who they would want to follow. What if this was reversed and people can choose the leaders they would like to work with. As mentioned in this post, willing followers may be the truest test of a servant leader.

Does the language used by this person inspire followers of their vision?

A source of encouragement and motivation. The language used during an organizational transformation is important. Change is never easy and the early-stage ecosystem being shaped is fragile. The reactions of a leader during this time are crucial. One harsh word or a command-and-control reaction to “failure” can cause significant damage. I’ve seen it over-and-over again.

An Agile leader emits words such as “I trust you.” and “We can do it.” and “What do you think?” and “I’m proud of you.” The Agile leader is in the business of building people up…they are an agent of elevating others.

Does this person foster an environment of connection and relationship?

Build community. The Agile leader is able to “knit people together.” Teams are intentionally designed with diversity and weaved together with inclusion and with openness.

When focusing on encouragement, people get bigger and by focusing on social cohesion people gets stronger. This doesn’t mean there is constant agreement but groups learn how to properly disagree and people begin to voice their opinions and concerns.

Does this person give of their time to help others grow?

Sacrificial. Time is always precious for a leader but the best always allocate time for others. An Agile leaders is focused on the growth and well-being of people and the only way this happens is through the gift of time.

Becoming a Catalyst - Scrum Master Edition

The post 5 Questions to Ask Before Hiring or Promoting an Agile Leader appeared first on Illustrated Agile.

Categories: Blogs

Are Google’s OKRs compatible with Agile?

A collaboration by JP Beaudry and Mario Moreira
Recently, someone asked us if we thought that the Objectives and Key Results (OKRs) used at Google and applied at Intel in the 1970s is compatible with the Agile mindset. In order to refresh our understanding of OKRs, we reviewed the Rick Klau presentation on How Google sets goals: OKRs. After examining the characteristics of OKRs, and with a few open questions, we are of the opinion that for the most part, they can be used in support of the Agile mindset. To provide a basic understanding, OKRs is a technique for setting and communicating goals. The first part, the objective, is the outcome that is sought. While the second part, the key results, is comprised of 3 to 5 specific and measurable pieces of evidence of progress against the objective. OKRs can be cascaded and refined at various levels in an organization. In order to allow people to be bold and think big, the guidance is that only about two thirds of OKRs be completed within a given period of time. To promote transparency, everyone’s OKRs are publicly accessible and graded.
Now back to the key question – Are OKRs compatible with Agile?  Based on our examination of OKRs, here are some reflections:
Ambitious - By design, OKRs should only be met or succeed about two thirds of the time. This lines up well with the general desire for organizations to be more innovative. There is a broad agreement that innovation is inherently uncertainty/high beta, and that a certain amount of failure/learning is inevitable. A goal of imperfection makes it safe for people to take chances

Measurable - Measurable outcomes are critical in determining whether one is getting closer to the stated objective. This is well aligned with Eric Ries’ concept of Validated Learning. It also plays well with Mario Moreira’s framework of a Lagging-to-Leading metric path

Public - I’m sure the public display of OKRs does wonders for creating alignment on priorities. This is because it makes it so much easier for all stakeholders to notice, and more importantly correct, misalignments. So much the better if the full cascade from strategy to team-level user stories is visible in one place. 

Graded - Grading OKRs forces participants to confront reality. Without an explicit process step where results are confronted, it’s too easy to skip the learning step. Without the result-driven feedback, roadmaps cannot be updated.

Because we haven’t worked with OKRs on a sustained fashion at scale to date, we have a few open questions on how they would fit in an Agile environment:    
Individual or Team At what point does the individual accountability get in the way of teamwork? Most Agile organizations spend a tremendous amount of energy creating high performing teams. It seems that individual OKRs could undermine teams
Local or Global Optimization A corollary is how to prevent local optimization that could make top-level objectives more difficult to attain. Would OKRs promote a narrow view?
In summary, it seems to me that the Objectives and Key Results (OKRs) technique has several characteristics that make them compatible with Agile environments, and few obvious downsides. The fact that OKRs are also used at LinkedIn and Twitter seems to provide further evidence of their usefulness in innovative environments. 
If you have experience with how OKRs can be used in an organization that values Agile and the discovery mindset, please consider sharing.  Bonus points if you can shed some light on the open questions in the article.  

To read more of JP Beaudry's articles, visit:   

To read more of Mario Moreira's articles, visit:
Categories: Blogs

Docker 1.9: Port forwarding on Mac OS X

Mark Needham - Sun, 11/08/2015 - 22:58

Since the Neo4j 2.3.0 release there’s been an official docker image which I thought I’d give a try this afternoon.

The last time I used docker about a year ago I had to install boot2docker which has now been deprecated in place of Docker Machine and the Docker Toolbox.

I created a container with the following command:

docker run --detach --publish=7474:7474 neo4j/neo4j

And then tried to access the Neo4j server locally:

$ curl http://localhost:7474
curl: (7) Failed to connect to localhost port 7474: Connection refused

I quickly checked that docker had started up Neo4j correctly:

$ docker ps
CONTAINER ID        IMAGE               COMMAND                  CREATED             STATUS              PORTS                              NAMES
1f7c48e267f0        neo4j/neo4j         "/docker-entrypoint.s"   10 minutes ago      Up 10 minutes       7473/tcp,>7474/tcp   kickass_easley

Looks good. Amusingly I then came across my own blog post from a year ago where I’d run into the same problem – the problem being that we need to access the Neo4j server via the VM’s IP address rather than localhost.

Instead of using boot2docker we now need to use docker-machine to find the VM’s IP address:

$ docker-machine ls
NAME      ACTIVE   DRIVER       STATE     URL                         SWARM
default   *        virtualbox   Running   tcp://
$ curl
  "management" : "",
  "data" : ""

And we’re back in business.

Categories: Blogs

IntelliJ ‘java: cannot find JDK 1.8’

Mark Needham - Sun, 11/08/2015 - 13:47

I upgraded to IntelliJ 15.0 a few days ago and was initially seeing the following exception when trying to compile:

java: cannot find JDK 1.8

I’ve been compiling against JDK 1.8 for a while now using IntelliJ 14 so I wasn’t sure what was going on.

I checked my project settings and they seemed fine:

2015 11 08 11 39 16

The error message suggested I look in the logs to find more information but I wasn’t sure where those live! I eventually found out the answer via the comments of this support ticket although I later found a post describing it in more detail.

Looking into the logs revealed the following error message:

$ less /Users/markneedham/Library/Logs/IntelliJIdea15/idea.log
2015-11-05 16:31:28,429 [ 428129]   INFO - figurations.GeneralCommandLine - Cannot run program "/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/bin/java" (in directory "/Applications/IntelliJ IDEA"): error=2, No such file or directory Cannot run program "/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/bin/java" (in directory "/Applications/IntelliJ IDEA"): error=2, No such file or directory
	at java.lang.ProcessBuilder.start(
	at com.intellij.execution.configurations.GeneralCommandLine.startProcess(
	at com.intellij.execution.configurations.GeneralCommandLine.createProcess(
	at com.intellij.execution.process.OSProcessHandler.<init>(
	at org.jetbrains.idea.maven.server.MavenServerManager$3.startProcess(
	at org.jetbrains.idea.maven.server.MavenServerManager$3.execute(
	at com.intellij.execution.rmi.RemoteProcessSupport.a(
	at com.intellij.execution.rmi.RemoteProcessSupport.acquire(
	at org.jetbrains.idea.maven.server.MavenServerManager.create(
	at org.jetbrains.idea.maven.server.MavenServerManager.create(
	at org.jetbrains.idea.maven.server.RemoteObjectWrapper.getOrCreateWrappee(
	at org.jetbrains.idea.maven.server.MavenServerManager$9.execute(
	at org.jetbrains.idea.maven.server.MavenServerManager$9.execute(
	at org.jetbrains.idea.maven.server.RemoteObjectWrapper.perform(
	at org.jetbrains.idea.maven.server.MavenServerManager.applyProfiles(
	at org.jetbrains.idea.maven.project.MavenProjectReader.applyProfiles(
	at org.jetbrains.idea.maven.project.MavenProjectReader.doReadProjectModel(
	at org.jetbrains.idea.maven.project.MavenProjectReader.access$300(
	at org.jetbrains.idea.maven.project.MavenProjectReader$1.doProcessParent(
	at org.jetbrains.idea.maven.project.MavenProjectReader$1.doProcessParent(
	at org.jetbrains.idea.maven.project.MavenParentProjectFileProcessor.processRepositoryParent(
	at org.jetbrains.idea.maven.project.MavenParentProjectFileProcessor.process(
	at org.jetbrains.idea.maven.project.MavenProjectReader.resolveInheritance(
	at org.jetbrains.idea.maven.project.MavenProjectReader.doReadProjectModel(
	at org.jetbrains.idea.maven.project.MavenProjectReader.access$300(
	at org.jetbrains.idea.maven.project.MavenProjectReader$1.doProcessParent(
	at org.jetbrains.idea.maven.project.MavenProjectReader$1.doProcessParent(
	at org.jetbrains.idea.maven.project.MavenParentProjectFileProcessor.processRepositoryParent(
	at org.jetbrains.idea.maven.project.MavenParentProjectFileProcessor.process(
	at org.jetbrains.idea.maven.project.MavenProjectReader.resolveInheritance(
	at org.jetbrains.idea.maven.project.MavenProjectReader.doReadProjectModel(
	at org.jetbrains.idea.maven.project.MavenProjectReader.access$300(
	at org.jetbrains.idea.maven.project.MavenProjectReader$1.doProcessParent(
	at org.jetbrains.idea.maven.project.MavenProjectReader$1.doProcessParent(
	at org.jetbrains.idea.maven.project.MavenParentProjectFileProcessor.processRepositoryParent(
	at org.jetbrains.idea.maven.project.MavenParentProjectFileProcessor.process(
	at org.jetbrains.idea.maven.project.MavenProjectReader.resolveInheritance(
	at org.jetbrains.idea.maven.project.MavenProjectReader.doReadProjectModel(
	at org.jetbrains.idea.maven.project.MavenProjectReader.readProject(
	at org.jetbrains.idea.maven.project.MavenProjectsTree.doUpdate(
	at org.jetbrains.idea.maven.project.MavenProjectsTree.doAdd(
	at org.jetbrains.idea.maven.project.MavenProjectsTree.update(
	at org.jetbrains.idea.maven.project.MavenProjectsTree.updateAll(
	at org.jetbrains.idea.maven.project.MavenProjectsProcessorReadingTask.perform(
	at org.jetbrains.idea.maven.project.MavenProjectsProcessor.doProcessPendingTasks(
	at org.jetbrains.idea.maven.project.MavenProjectsProcessor.access$100(
	at org.jetbrains.idea.maven.project.MavenProjectsProcessor$
	at org.jetbrains.idea.maven.utils.MavenUtil$
	at com.intellij.openapi.application.impl.ApplicationImpl$
	at java.util.concurrent.Executors$
	at java.util.concurrent.ThreadPoolExecutor.runWorker(
	at java.util.concurrent.ThreadPoolExecutor$
	at org.jetbrains.ide.PooledThreadExecutor$1$
Caused by: error=2, No such file or directory
	at java.lang.UNIXProcess.forkAndExec(Native Method)
	at java.lang.UNIXProcess.<init>(
	at java.lang.ProcessImpl.start(
	at java.lang.ProcessBuilder.start(
	... 55 more

Somewhere I had a JDK 1.7 defined which no longer existed on my machine. I actually only have one JDK installed at the moment:

$ /usr/libexec/java_home -V
Matching Java Virtual Machines (1):
    1.8.0_51, x86_64:	"Java SE 8"	/Library/Java/JavaVirtualMachines/jdk1.8.0_51.jdk/Contents/Home

A bit of exploring led me to ‘Platform Settings’ which is where the culprit was:

2015 11 08 11 45 00

That setting lives actually lives in /Users/markneedham/Library/Preferences/IntelliJIdea15/options/jdk.table.xml and once I removed it IntelliJ resumed normal service.

Categories: Blogs

Asking for Free Work – Working on Spec

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

Great video shared by Robin Dymond:

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

The post Asking for Free Work – Working on Spec appeared first on Agile Advice.

Categories: Blogs

Get in the Zone at CA World '15

Rally Agile Blog - Fri, 11/06/2015 - 20:54

Conferences can be challenging ROI activities to measure. We disrupt our daily routine of meetings, emails and conference calls to trek through airports, sit in air-conditioned ballrooms, and chat with strangers. Will it be worth it? How will we know?

We’ve all likely had moments, walking into a technical or professional conference, where we wondered whether we’d walk out with something more valuable than a piece of swag. But sometimes there’s that moment during a conference that singularly marks its worth: a speaker whose words inspire us to think differently, a presentation about an approach we’d never considered, a conversation with the person next to us who’s working through similar challenges, a peek at new technology that’s going to change the way we work.

If you’ve attended one of our RallyON conferences in the past then you know that we strive not only to yield returns on your time and effort but to pack them full of those worthwhile moments. Now that Rally is part of the CA Technologies family, we’re thrilled to plug our agile platform and disciplines into the broader CA ecosystem of solutions—and we’re eager to plug you into the premier annual gathering of CA customers, fans, partners, aficionados and explorers.

In just 10 days we’re headed to CA World ‘15 in Las Vegas, November 16-20, where we’ll join thousands of others whose worlds are driven by software for some education, motivation, innovation, transformation, inspiration, acceleration and collaboration.

This will be our first official presence at the conference since Rally was acquired by CA, and for the first time at CA World, agile will take center stage: the aptly named Agile Transformation Zone occupies a can’t-miss chunk of real estate in the conference hall. For attendees new to agile we’ll be introducing the benefits of agile, and we’ll help step up the game of those ready to take agile to the next level. We’ve organized our content around themes that affect every business in today’s economy: getting to market faster, building high-quality products that customers value, making more informed portfolio decisions, reducing risk, eliminating waste, collaborating better, scaling solutions across your business, and harnessing innovation to boost your bottom line.

We’ve carefully designed our content to help produce those memorable conference moments for you. Look for presentations on topics like agile roles and agile PPM; small-group roundtables on agile in marketing and agile metrics; demonstrations of our product roadmap and enterprise scale agile capabilities; and one-on-one sessions with our agile coaches and transformation consultants. We’ll also have whiteboarding sessions, Lean coffee discussions, games and prizes—and of course, what would a conference be without swag?

All that is just what’s going on in the Zone. CA World sessions are organized into five tracks— Security, Agile Management, DevOps, Mainframe, and Application Economy Strategies—that fully represent not just agile but the adjacent technology areas affecting your business. Featured speakers include DevOps guru Gene Kim, Forrester analyst Margo Visitacion, Quirky founder Ben Kaufman, and PayPal VP of Technology Kirsten Wolberg. For those of you who want to come away with extra technical prowess, there are education deep-dives and hands-on labs. And for the true road warriors among you, there’s even a bike ride around Lake Mead.

Joining our own customers like ADP and UnitedHealthcare will be CA customers like Blue Cross Blue Shield, Colgate-Palmolive, Honda, Target  and T-Mobile. Networking with folks across such a broad range of companies and industries turns out to be pretty powerful, because we discover how much we have to learn from each other. By stepping out of our regular routines to attend a conference like CA World, we’re bound together not just by the constraints of a hotel ballroom but by the cares, concerns, practices and products we have in common.

We hope you can join us at CA World ‘15 on November 16 and look forward to seeing you there! We’re going to make it memorable and worth your while.

Categories: Companies

Gartner Top 10 Strategic Technology Trends for 2016

Agile Elements - Fri, 11/06/2015 - 18:50

Always interesting and fun to share. Here’s Gartner’s annual prediction of strategic trends shaping technology over next 4 years. Gartner groups these into three broad trends:

The first three trends address merging the physical and virtual worlds and the emergence of the digital mesh. While organizations focus on digital business today, algorithmic business is emerging. Algorithms — relationships and interconnections — define the future of business. In algorithmic business, much happens in the background in which people are not directly involved. This is enabled by smart machines, which our next three trends address. Our final four trends address the new IT reality, the new architecture and platform trends needed to support digital and algorithmic business.

See their press release for more definition and

Categories: Blogs

Targetprocess product workshops at Caterpillar Inc.

TargetProcess - Edge of Chaos Blog - Fri, 11/06/2015 - 11:45

Caterpillar Inc., the world’s leading manufacturer of construction and mining equipment, has been managing software development projects with Targetprocess since 2012.

CAT Products

While Targetprocess is used nowadays by 1400 Caterpillar employees the company was willing to help employees uncover the full potential of Targetprocess for their specific roles as well as to understand how Targetprocess can be used to more effectively manage agile projects at both the team, project and portfolio level.

Well in advance of the workshops users were offered to fill in a questionnaire so that our Product Specialist could adjust the agenda and make the workshops relevant and time-efficient. This resulted in a fully booked agenda for 5 working days at the headquarters of Caterpillar in Illinois, US.

There has been a lot of interest in the following topics:
– Agile project portfolio management
– Release management
– Request management
– QA and test management with Targetprocess
– People management
– Time management
– How to generate basic & advanced reports
– How to set up custom dashboards
– Mashups & plugins
– Creation of custom views
– Upcoming features of Targetprocess

To attract more employees to the workshops posters like the one below were displayed on TV screens around the customer office. The posters were provided with the QR code to simplify the registration via a smartphone.
CAT Worshop schedule
During most of the workshop sessions people worked in groups of 5. Every workshop included tasks with examples from real project situations. Often we started with some hands-on exercises using sticky notes and paper and when basic terms and ideas were clear we proceeded to more complex tasks in Targetprocess. Here are examples of tasks for creation of views and for generation of reports.

Some photos from the workshop sessions:

After every session people left their feedback.
Workshop feedback
One of the very important sessions for Caterpillar teams was how Targetprocess can help with agile project portfolio management. Our Product Specialist was happy to demonstrate the upcoming version of Targetprocess which should support complex custom processes and workflows of Caterpillar and enable users to:
– map requirements and track dependencies across multiple teams
– visualize team workflows and track the progress of multiple teams
– see if the deadlines set on a higher level are being met
– track progress through verticals
– prioritise work across the entire organization

In general, we should say it was a very challenging and exciting week. At the end of the workshop week the customer decided that such workshops should be held in other locations of Caterpillar as well.

Upon return our Product Specialist concluded her internal post sharing the new knowledge with our team with the following words: “How awesome and inspiring our customers are! I am so happy to work with them!”

If your company uses Targetprocess and you would also like to derive more value from the software as well as to boost productivity of your agile teams, feel free to request an onsite workshop. If you would like to customize the agenda, duration and other details, please contact your Targetprocess Product Specialist.

Categories: Companies

Higher Order React Components

Mistaeks I Hav Made - Nat Pryce - Fri, 11/06/2015 - 10:27
When writing user interfaces with the React framework, I often find that several of my components have similar behaviour. For example, I may have several components that display the eventual value of a promise, or display changing values of an Rx event stream, or are sources or targets for drag-and-drop interactions, and so on. I want to define these common behaviours once and compose them into my component classes where required. This, in a nutshell, is what “higher-order components” do. An Example Use Case for Higher-Order Components Imagine we’re writing an international e-commerce site. When a customer uses the site, the information they see is localised for the country in which they reside. The site uses the user’s country to determine the currency in which to display prices, calculate shipping costs, etc. The site displays the customer’s country in the navigation bar at the top of each page. If the user is travelling, they can select their preferred country from a menu of countries supported by the site. Both the country associated with the user’s session and the list of all countries supported by the application are fetched by HTTP from the server in JSON format and displayed by React components. For example, the user’s country is served as: {"iso": "gb", "name": "United Kingdom"} And the list of supported countries is served as: [ {"iso": "fr", "name": "France"}, {"iso": "gb", "name": "United Kingdom"}, ... ] The Country component below displays the user’s preferred country. Because country data is received asynchronously, the Country component must be given a promise of the country information. While the promise is pending, the component displays a loading indicator. When the promise is resolved successfully, the component displays the country information as a flag icon and name. If the promise is rejected, the component displays an error message. class Country extends React.Component { constructor(props) { super(props); this.state = {loading: true, error: null, country: null}; } componentDidMount() { this.props.promise.then( value => this.setState({loading: false, country: value}), error => this.setState({loading: false, error: error})); } render() { if (this.state.loading) { return Loading...; } else if (this.state.error !== null) { return Error: {this.state.error.message}; } else { var iso =; var name =; return ( {name} ); } } } It can be used like this (assuming fetchJson starts loading JSON from a URL and returns a promise of the JSON): The CountryChooser component below displays the list of available countries, which are also passed to it as a promise: class CountryChooser extends React.Component { constructor(props) { super(props); this.state = {loading: true, error: null, countries: null}; } componentDidMount() { this.props.promise.then( value => this.setState({loading: false, countries: value}), error => this.setState({loading: false, error: error})); } render() { if (this.state.loading) { return Loading...; } else if (this.state.error !== null) { return Error: {this.state.error.message}; } else { return (
    { =>
  • this.props.onSelect(c.iso)}> {}
  • ) }
); } } } It can be used like this (assuming the same fetchJson function and a changeUsersPreferredCountry function that sends the change of country to the server): There’s a lot of duplication between the two components. They duplicate the state machine required to receive and render data obtained asynchronously from a promise. These are not the only React components in the application that need to display data loaded asynchronously from the server, so addressing that duplication will shrink the code significantly. The CountryChooser component cannot use the Country component to display the countries in the list because the event handling is intermingled with the presentation of the data. It therefore duplicates the code to render a country as HTML. We don’t want these HTML fragments diverging, because that will then create further duplication in our CSS stylesheets. What can we do? We can’t achieve what we want with parent/child relationships between components, where a parent component handles the promise events and child components render the promised value. Child component props are specified in the code that creates the component hierarchy, but at that point the we do not know the prop values. We want to calculate the props dynamically, when the promise is resolved. We could extract the promise event handling into a base class. But JavaScript only supports single inheritance, so we if our components inherit event handling for promises, they cannot inherit base classes that provide event handling for other things, such as user interaction 1. And although it disentangles the promise event handling from the rendering, it doesn’t disentangle the rendering from the promise event handling, so we still couldn’t use the Country component within the CountryChooser. It sounds like a job for mixins, but React’s mixins don’t work with ES6 classes and are going to be dropped from the API. The solution is a higher-order component. Higher-Order Components A higher-order component is merely a function from component class to component class. The function takes a component class as a parameter and returns a new component class that wraps useful functionality around the class passed in 2. If you’re familiar with the “Gang of Four” design patterns and are thinking “Decorator pattern”, you’re pretty much bang on. As a shorthand, in the rest of this article, and to avoid confusion with ES7 decorators, I’m going to call class passed to the function the “wrapped class”, the class returned by the function the “wrapper class”, and the function itself as the “higher-order component”. I’ll use “wrapped component” and “wrapper component” to mean instances of the wrapped and wrapper classes. A wrapper component usually handles events on behalf of the wrapped component. It maintains some state and communicates with the wrapped component by passing state values and callbacks to the wrapped component via its props. Let’s assume we have a higher-order component called Promised that translates a promise of a value into props for a wrapped component. The wrapper component performs all the state management required to use the promise. This means that wrapped components can be stateless, only concerned with presentation. The Country component now only needs to display to country information: var Country = ({name, iso}) => {name} ; To define a component that receives the country information asynchronously as a promise, we decorate it with the Promised higher-order component: var AsyncCountry = Promised(Country); The CountryChooser can also be written as a stateless component, and can now use the Country component to display each country: var CountryChooser = ({countries, onSelect}) =>
    { =>
  • onSelect(c.iso)}>
  • ) }
; And can also be wrapped with Promised to receive the list of countries as a promise: var AsyncCountryChooser = Promised(CountryChooser); By moving state management into a generic higher-order component, we have made our application-specific components both simpler and more useful, in that they can be used in more contexts. Implementing the Higher-Order Component Here is the implementation of the Promised function: var React = require('react'); var R = require('ramda'); var Promised = Wrapped => class Promised extends React.Component { // (1) constructor(props) { super(props); this.state = {loading: true, error: null, value: null}; } componentDidMount() { this.props.promise.then( // (2) value => this.setState({loading: false, value: value}), error => this.setState({loading: false, error: error})); } render() { if (this.state.loading) { return Loading...; } else if (this.state.error !== null) { return Error: {this.state.error.message}; } else { var propsWithoutThePromise = R.dissoc('promise', this.props); // (3) return ; } } }; Promised is a function from one component class, named Wrapped in this example, to another class. Like a function, the returned class closes over definitions in the scope where it is defined, and so the methods of the class can refer the parameters and local variables of the function. The parameter name for the wrapped component must start with a with a capital letter so that the JSX compiler recognises it as a React component, rather than an HTML DOM element. Client code passes a promise of props for the wrapped component to the wrapper as a prop named “promise”. The wrapper passes all other props through to the wrapped component unchanged. This lets you configure a Promised(X) component with the same props you would use to configure an unwrapped X component. For example, you can initialise the wrapper with event callbacks that get passed to the wrapped component when it is rendered. When the wrapper renders the wrapped component, it creates the props for wrapped component by merging the properties of the promised value its own properties, except for the promise itself. The code above uses a utility function from the Ramda library to remove the promise from the wrapper component’s props, and uses ES6 “spread” syntax to remove merge the props with the properties of the promise value. Massaging Props to Avoid Name Clash The eagle eyed reader will have noticed that the AsyncCountryChooser has a slightly different API from the original CountryChooser component above. The original accepted a promise of an array of country objects. But the Promised wrapper uses the fields of the promised value as the props of the wrapped component, so the promised value must be an object with the array of country objects in a field named “countries”. We can address that by mapping the array to an object when we create the promise: {countries: list})} onSelect={changeCountry}/>, Another problem is that the current implementation reserves the prop name “promise”. This means we cannot pass a prop named “promise” through to the wrapped component. This could cause some head-scratching in the future as we evolve the system. If it is to be compatible with arbitrary components, a higher-order component must provide a way to control the interface between the wrapper and wrapped components to avoid name clash and map the data provided by the wrapper to the props expected by the wrapped component. The most flexible method, which is most frequently by libraries published in NPM, is to parameterise the higher-order component with a function that maps the state and props of the wrapper component to props that are passed to the wrapped component. That way, the client code is in full control of the interface between the wrapper and wrappee and can programatically resolve any name clash. However, in this example, letting the caller name the promise prop and and using the promise’s then method to map the promised value to props of the wrapped component is good enough. Because a Javascript class is a closure we can pass the name of the promise prop to the Promised function along with the class to be wrapped. var Promised = (promiseProp, Wrapped) => class extends React.Component { constructor(props) { super(props); this.state = {loading: true, error: null, value: null}; } componentDidMount() { this.props[promiseProp].then( value => this.setState({loading: false, value: value}), error => this.setState({loading: false, error: error})); } render() { if (this.state.loading) { return Loading...; } else if (this.state.error !== null) { return Error: {this.state.error.message}; } else { var propsWithoutThePromise = R.dissoc(promiseProp, this.props); return ; } } }; We now have to name the promises when we apply the higher-order component to define new classes. But this lets us introduce better names into the code, which (in my opinion) is a good thing. var AsyncCountry = Promised("country", Country); var AsyncCountryChooser = Promised("countries", CountryChooser); ... {countries: list})} onSelect={changeCountry}/> Further Reading You can access the full source code for this example on GitHub. Other React libraries that use higher-order components include: React Drag and Drop React Callback Register for example, in recent project we needed to compose live updates, drag-source and drop-target behaviour into stateless rendering components↩ actually, a higher-order component could take more than one components as parameters, but we only need one in this example↩
Categories: Blogs

Russian edition of Valuable Agile Retrospectives book released

Ben Linders - Thu, 11/05/2015 - 23:49

Cover Russian edition - smallThe full version of the Russian edition Извлекаем пользу из Agile-ретроспектив has been released on Leanpub. With this release there are now 8 translated editions of the successful book Getting Value out of Agile Retrospectives available.

There is an introduction discount of 50% that readers can get using this link:
Please feel free to use this link to get your personal copy, … Continue reading →

Categories: Blogs

Three Areas the Agile Community Has Missed the Boat

NetObjectives - Thu, 11/05/2015 - 22:51
In the 17 years I've been involved in Agile software development, there have three areas that are key to success that have been somewhat ignored by much of the Agile community. These are in the areas of complexity, transition and learning. Pretty surprising since everyone says software development is complex, that we must transition to a better way of being and that it's all about learning. Let's...

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

ScrumDay Oviedo, Spain, December 12 2015

Scrum Expert - Thu, 11/05/2015 - 14:30
ScrumDay Oviedo is a one-day conference focused on Scrum and Agile software development that takes place in the Spanish city of Oviedo. All the presentations are in Spanish. In the agenda of ScrumDay Oviedo conference you can find topics like Agile adoption, team coaching, technical best practices and product ownership presented by local Scrum experts. Web site: Location for the ScrumDay Oviedo conference: Auditorio – Palacio de ...
Categories: Communities

Knowledge Sharing

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