Skip to content


Encapsulation and Orchestration

Leading Agile - Mike Cottmeyer - Wed, 07/13/2016 - 12:00

I spend a lot of time thinking about these two words.

When LeadingAgile talks about forming teams and building organizational structures, we rely on the notion of encapsulation to increase local autonomy, and therefore empower the people doing the work to make local decisions.

When we talk about orchestration, we understand that anything which cannot be encapsulated requires coordination, and therefore must be coordinated. Orchestration is the means of coordinating work between dependent agents.

Scrum assumes encapsulation and therefore has minimal orchestration.

SAFe assumes little encapsulation as therefore has more orchestration.

The only way to reduce orchestration is to increase encapsulation.

You increase encapsulation, and reduce orchestration, by breaking dependencies.

The whole story we are trying to tell at LeadingAgile goes something like this.

1. Organize for encapsulation
2. Respect dependencies and orchestrate as necessary while you break them
3. Reduce orchestration as dependencies are broken.

The post Encapsulation and Orchestration appeared first on LeadingAgile.

Categories: Blogs

Back to the Beginning with Ohno, Suzuki, and Yoda

Evolving Excellence - Tue, 07/12/2016 - 19:36

yoda-the-empire-strikes-backAs I was researching the remarkable similarities between Lean and Zen for my book, The Simple Leader, one of the most interesting – and meaningful – was the concept of the beginner’s mind.

Taiichi Ohno said, “Observe… without preconceptions and with a blank mind.

Zen master Shunryu Suzuki similarly said, “In the beginner’s mind there are many possibilities, in the expert’s mind there are few.

One of the core concepts of Zen is shoshin, or “beginner’s mind.” This is a perspective that is free of preconceived ideas and opinions, and is open to new thought. We know how some Lean concepts can be counterintuitive. Embracing shoshin requires “unlearning” what you thought you already knew—in effect, creating a beginner’s mind.

Yoda, back in one of the original (and, ahem, good) Star Wars movies recognized this and told Luke Skywalker “You must unlearn what you have learned.

As we become older and supposedly wiser, creating a beginner’s mind can become increasingly difficult. It becomes even more so when an entire team or organization needs to unlearn and develop a beginner’s perspective. So how do you revert to a beginner’s mind?

Begin by focusing on questions, not answers. When observing a process, especially one you’ve seen many times, try to avoid jumping ahead to conclusions. Take one step (or, as Ohno would emphasize, one question) at a time. Similarly, be aware that what seems like common sense may not be. Avoid using the word “should” as it implies a predetermined or expected outcome. Be careful with experience. What you already know should be an input, not a perspective. Be comfortable with saying “I don’t know”—it shows a desire to learn and is a component of humility.

Being biased is a result of not having a beginner’s mind. The most common and well-known bias is confirmation bias. This is our desire to believe what we want to believe, to the extent that we consciously or subconsciously distort or interpret information to fit our preconceptions. We can also seek out sources of information that align with our biases, while ignoring non-confirming data.

You can see an example of confirmation bias in the politics of the United States – and apparently in the United Kingdom as well. It is the reason the two major parties in the U.S. are moving away from the center and more toward the extremes. Even though the number of information sources has exploded over the last couple decades, people on the right of the spectrum consume news geared toward them, because they feel it is correct. In other words, it fits their biases. The same happens on the left. This has occurred to such an extent that heroes of each party—Ronald Reagan and John F. Kennedy, for example—probably wouldn’t be welcome in their respective parties today.

A second form of bias is loss aversion. Researchers such as psychologists Daniel Kahneman and Amos Tversky have found that we’re twice as likely to try to avoid a loss than go after a gain. In effect, we are risk averse, which may be great for our survival as a species, but it hinders us as we try to create organizational change and improvement.

A third form of bias is conformity bias, also known as groupthink (e.g., “When in Rome…”). By nature, most of us don’t like to stand out in a crowd and will be willing to agree with a group, even if we know the information is incorrect.

A fourth type is survivorship bias, where we focus on the tiny fraction of people that are successful, ignoring the far greater numbers that have failed. An example of this is our fascination with and attraction to get-rich-quick gurus. We also look at highly successful people like Steve Jobs and Bill Gates, and think that could be us. We then try to model ourselves after them. We find it easy to ignore, or not even understand, that every path is unique and what works for one person may not for another, for a multitude of reasons.

Finally—and this one is very common in the business world—is anchoring, or first impression bias. This form of bias occurs because we subconsciously give the first piece of information we receive on a topic more relevance and weight than follow-up information. This is why public relations companies find it very important to get their story out first, and why it is so difficult to change minds after the fact—even if the subsequent information is more accurate.

Once we know that we’re susceptible to these biases, what can we do? The most important thing to do is to be mindful and present. Observe and ask validating questions. Why do you think this way? What are the arguments against your opinion? Review the forms of bias and honestly try to determine if they might be in play.

Taking steps to neutralize your biases will help you make smarter, more rational decisions. Observe like a beginner.  Find your inner Yoda… or Suzuki or Ohno.

Categories: Blogs

Retrospective on Steroids with Toyota Kata

TV Agile - Tue, 07/12/2016 - 15:31
You have been doing Agile for a few years now. With a regular cadence you have retrospectives and a lot of problems and great improvement opportunities are raised but you don’t seem to really improve. Let us put your retrospectives on steroids with the Toyota Kata. Building on the power of habits, Toyota Kata will […]
Categories: Blogs

Forecasting, Metrics and the Lies that a Single Number Tell Us

Notes from a Tool User - Mark Levison - Tue, 07/12/2016 - 13:52

We’ve previously seen that our mental models often make false assumptions due to cognitive bias. Giving a Single number in a report has a similar problem.

The classic Agile number is ‘Velocity’: the average rate at which your team delivers work. It is often shared as just one number. E.g. our team achieves 20 pts a Sprint.

You’re walking and come to a river – there is a sign that says the average depth is 1 foot. Can you safely walk across? You don’t know. For most of its width, the river may be only 6 inches deep, but for a critical 1 foot stretch, it’s 6 feet deep. Not safe to cross.

You’re told the average grade on a test in your class is 75%. What does this tell you about your own mark? Nothing.

The problem with reporting velocity as a single number is that it implies the average number will continue into the future at the same rate. It implies that there will never be any variance.

Consider reporting a range[1][2].

  • Best three sprints in the past year – this is the highest you’re likely to achieve
  • Last three sprints – you’re 50% likely to achieve this number
  • Worst three sprints in the past year – the least you’re likely to achieve

Forecasting Metrics burndown

Along with projecting a cone of uncertainty in your burndown/burnup/cumulative flow diagram, it can also be used to illustrate which items in the product backlog are more or less likely to be achieved by drawing lines in the product backlog.

If you need a more sophisticated model than these, consider using a Monte Carlo simulation. Larry Maccherone has a Chrome only example: and code showing how he uses it:

Forecasting Metrics confidence lineWith five Sprints to go, we have a clear picture of where in the product backlog we will likely get.

So instead of forecasting a number, now we’re forecasting which items will be delivered, i.e. we’re forecasting value. This drives a better quality conversation because we can have real discussions about which stories or features to sort into which part of the Product Backlog.

This brings up the final problem with velocity as a number (or even range). The number of Product Backlog Items, Features, or User Stories don’t necessarily correlate with how happy the customer is. A small feature may delight the customer if it’s done well (example: ability to freeze the first row in Excel), while a large feature (example: SmartArt in Word) may not make the customer(s) happy.

So even with ranges and probabilities, the use of numbers can still hide the most important thing: Is the customer happy?


Image attribution: Agile Pain Relief Consulting

[1] Note that even this model of reporting velocity has an implicit bell curve behind it.
[2] Even elections are now forecast with ranges by the better forecasters: Eric Grenier:


Categories: Blogs

The Executives Guide to Leading Agile Transformation – Intro and Overview #Agile2016

Leading Agile - Mike Cottmeyer - Tue, 07/12/2016 - 12:00

I’ve got most of this week dedicated to pulling together my Agile2016 presentation. This isn’t the latest I’ve ever waited to start writing my talk, so I kinda feel like I am ahead of the game. In reality, this talk is effectively the next step, the next chapter if you will, in the story I’ve been trying to tell for the last 6-7 years. I’m not expecting the content to be super hard to pull together.

So… let’s spend a minute on the evolution of the story.

Two years ago, I did a talk called ‘Why Agile Fails in Large Enterprises and What You Can Do About It’. In that talk you see my first clear articulation of The Three Things and the Four Quadrants, but the main point of that discussion was really to assert that transformation isn’t something that is self-organized, it is something that has to be planned and coordinated. That talk introduced how.

One year ago, I did a talk called ‘The Three Things You Need To Know To Transform Any Sized Organization Into An Agile Enterprise’. In that talk we go deeper into the Four Quadrants, The Three Things, and we spend a bunch of time on why it’s so important to break dependencies. Finally, we introduce the notion of Expeditions and Basecamps as an organizing metaphor for Agile Transformation.

My talk this year will explore the mechanics of Agile Transformation and what we’ve learned in trying to maintain organizational focus in the face of large scale change, disruption of the status quo, and significant investment on the part of executive stakeholders. Asking people to trust you when you’re spending millions on coaching, training, doesn’t typically fly in most organizations.

Why a talk for executives and why now?

Executive support for adopting agile tends to fall into one of several categories. We’ve got the executives that are willing to fund a transformation, want the benefits of agility, as long as nothing really changes and we are able to still meet time, cost, and scope constraints established at the beginning of the project. These execs tend to look at agile as just another way of doing the work.

Some executives realize that adopting agile goes deeper than just adopting a process. These executives are willing to lead change and can articulate the value prop of agility. They sincerely want to help their organizations get there. That said, many of these executives don’t fully understand the nature of the changes that have to be made, or the impediments they’ll face, and are surprised when they struggle.

Executives need to know the specific types of changes they are going to have to make, the specific impediments they’ll face, and the specific kinds of investments that are going to be required… before they get started. They have to manage, and to some degree, control the change. They have to incrementally demonstrate progress towards goals and justify the investment they are making within the organization.

You see, the game has changed.

We aren’t talking about grass roots movements anymore. More often than not, I am speaking not just with CIOs, but with COOs, and CFOs, and CEOs. I have met with boards of large banks where the decisions to go agile are really being made. At this level, the conversation isn’t about user stories and teams, the conversation is about return on investment and what can and cannot be capitalized.

At that level, the game is not only about showing progress, but about proving it. It’s about maintaining influence and dealing with the politics that inevitably come into play when you hit pockets of resistance and groups of people that don’t want to change. It’s about constantly demonstrating what you are doing is making progress against the broader organizational goals we are trying to solve.

We are no longer speaking to the enthusiasts. We are not speaking to the people that have felt the pain. This is no longer an emotional response to that pain, but a rational investment in finding a better way to build products. If we want to make the changes that are going to really lead toward greater business agility, our executives are the only ones empowered to make the investments required`

To do this, we have to show them what its going to look like when they are done, they have to see that change… a path forward… is possible. We have to help them get started in a structured and systematic way so they can hold their teams accountable. We have to help them take the first steps, constantly reinforcing the economics of the change, and justifying continued investment.

Given all that, here is where I plan to go with this.

First I want to go back and deal with some of the thinking tools that make this talk necessary.

  1. Can we really expect self-organization to happen at scale, especially in the face of constraints and dependencies. Not unless we release all requirement to plan, coordinate, or get things done on a schedule. The short answer is no.
  2. We have a choice to make with our transformation. Do we lead with culture change or agile practices. Do we start both simultaneously. My assertion is that we lead with structure and governance, reinforce with practices, and guide culture to emerge.

Next I want to go over the patterns LeadingAgile has introduced over the past 5 years to help solve these problems and lead large scale change

  1. We believe that transformation starts by focusing relentlessly on three things. Forming teams, building backlogs, and producing working tested increments of products. Anything that gets in the way is a dependency that has to be removed. We call this model the Three Things.
  2. By identifying what an organization values from a planning perspective and comparing that against what it’s market values, can help us understand how to tailor our approach to meet a company where it is and help it get to where it needs to be. We call this model the Four Quadrants.
  3. We believe that change can be coordinate and planned and that by defining the end state, incrementally and iteratively introducing change, and building infrastructure to sustain change with a tight change management program is what will lead to long term lasting change.

All that foundation has to go quick because I’ve done whole talks around these topic areas, deeply explaining the rationale for my thinking.

What’s going to make this talk different, is that I want to give executives a meaningful framework for holding their consultants and their organizations accountable during the transformation.

To do this, I am going to fall back to one of my favorite slide sequences in the Three Things talk.

In that talk, I make the case the building backlogs, forming teams, and producing working tested software gives us a model to establish clarity, hold people accountable, and to measure progress.

Our Transformation Execution Framework seeks to do the same three things.

  1. Give the executive and the organization clarity around where it’s going, what it’s doing, and how it’s adapting to changing conditions on the ground. This means we are going to have defined end state, a mechanism to pilot the plan, and a means to do incremental and interactive rollout along the way.
    • Roadmap
    • End State Vision
  2. Create an accountability infrastructure made up of specific people, with specific responsibilities, responsible for maintaining artifacts like the transformation roadmap, rolling 90-day plans, agendas for 30-day checkpoints, and what needs to be communicated in a weekly status.
    • Executive Leadership Committee
    • Transformation Leadership Team
    • 90-Day Plans
    • 30-Day Checkpoints
    • Weekly Update
  3. Finally we want to have a way of measuring progress that clearly shows how the transformation dollars spent are producing better organizational performance, and how the organizational performance is leading to better business performance for the key stakeholders.
    • Transformation Metrics
    • Business Metrics

The goal is to provide very specific guidance around the kinds of things that have to be done, what those things look like, and maybe even some downloadable templates that folks could use as a starting point for their own transformation work.

Last, I want to at least make a nod to the stuff that gets change leaders in trouble, even if they are doing all the clarity, accountability, and measurable progress stuff right. This stuff is difficult and tough to do right, but is every bit as important as the technical aspects of the transformation.

  1. Creating safety
  2. Being influential
  3. Dealing with resistance
  4. Holding space
  5. Maintaining permission
  6. Managing change

I am clearly going to have to prioritize in this talk around what is most essential to cover without losing any of the context necessary to understand where we’ve been and where we are going.

whitepaper-cta 2

The post The Executives Guide to Leading Agile Transformation – Intro and Overview #Agile2016 appeared first on LeadingAgile.

Categories: Blogs

Links for 2016-07-11 []

Zachariah Young - Tue, 07/12/2016 - 09:00
Categories: Blogs

Agile2016 Preview: Hardware Development and More

Agile Product Owner - Mon, 07/11/2016 - 18:29

I’m looking forward to meeting with many of you at Agile2016, which is just a couple of weeks away. Together with my co-presenter, Harry Koehnemann from 321 Gang, we created a short video to help you guys get a sense of what are we going to talk about as part of our presentation: “Lean-Agile Development for Large Enterprises: Adding Hardware to the Mix.” Here is the video:

Also, I’m sure you will be interested to find out more about what the rest of Scaled Agile team is presenting at Agile 2016. Here’s a brief list of all our team talks with links and times on the conference agenda:

Building Large, Mission Critical Software and Systems with SAFe 4.0
with Dean Leffingwell, SAFe Founder and Chief Methodologist 
Monday, July 25 3:45pm

The Four Fictional Faces of Scaled Stakeholder Management
with Drew Jemilo, Co-Founder and SAFe Fellow
Tuesday, July 26 3:45 pm

Value Points: Maximizing Digital Services ROI Using Multi-Criteria Decision Analysis
with Stephen Mayner, SPC and Principal Consultant
Wednesday, July 27 3:45 pm

Lean-Agile Development for Large Enterprises: Adding Hardware to the Mix
with Alex Yakyma, SAFe Fellow
Thursday, July 28 10:45am

AstraZeneca: Agile Transformation That Was Taught, Not Caught
with Michael Stump, SAFe Fellow
Thursday, July 28 2:00pm

Look for us at Agile2016; we will be glad to talk to you guys! As always, please share your thoughts below.


Categories: Blogs

Strategy Deployment and Spotify Rhythm

AvailAgility - Karl Scotland - Mon, 07/11/2016 - 17:28

This is the third in what has turned into a mini series exploring the relationship between Strategy Deployment and other approaches (see Strategy Deployment and Fitness for Purpose and  Strategy Deployment and AgendaShift).

Last month, Henrik Kniberg posted slides from a talk he gave at Agile Sverige on something called Spotify Rhythm which he descibes as “Spotify’s current approach to getting aligned as a company”. While looking through the material, it struck me that what he was describing was a form of Strategy Deployment. This interpretation is based purely on those slides – I haven’t had a chance yet to explore this more deeply with Henrik or anyone else from Spotify. I hope I will do some day, but given that caveat, here’s how I currently understand the approach in terms of the X-Matrix Model.


The presentation presents the following “taxonomy” used in “strategic planning”:

Company Beliefs – While this isn’t something I don’t talk about specifically, the concept of beliefs (as opposed to values) does tie in nicely with the idea that Strategy Deployment involves many levels of nested hypotheses and experimentation (as I described in Dynamics of Strategy Deployment). Company Beliefs could be considered to be the highest level, and therefore probably strongest hypotheses.

North Star & 2-Year Goals – A North Star (sometimes called True North) is a common Lean concept (and one I probably don’t talk about enough with regard to Strategy Deployment). It is an overarching statement about a vision of the future, used to set direction. Decisions can be made based on whether they will move the organisation towards (or away from) the North Star. Strategy Deployment is ultimately all in pursuit of enabling the organisational alignment and autonomy which will move it towards the North Star. Given that, the 2-Year Goals can be considered as the Results that moving towards the North Star should deliver.

Company Bets – The Company Bets are the “Big Bets” – “large projects” and “cross-organisation initiatives”. While these sound like high level tactics, I wonder whether they can also be considered to be the Strategies. As mentioned already, Strategy Deployment involves many levels of nested hypothesis and experimentation, and therefore Strategy is a Bet in itself (as are Results , and also Beliefs).

Functional & Market Bets – If the Company Bets are about Strategy, then the Functional and Market Bets are the Tactics implemented by functional or market related teams.

DIBB – DIBB is a framework Spotify use to define bets and “make the chain of reasoning explicit” by showing the relationships between Data, Insights, Beliefs and Bets. Part of that chain of reasoning involves identifying success metrics for the Bets, or in other words, the Outcomes which will indicate if the Bet is returning a positive payoff.

@DReinertsen @KentBeck @ragavendra1 But it's very useful to make the chain of reasoning explicit. Makes us less likely to lose the Why.

— Henrik Kniberg (@henrikkniberg) July 8, 2016

While this isn’t an exact and direct mapping it feels close enough to me. One way of checking alignment would be the ability for anyone to answer some simple questions about the organisations’ journey. I can imagine how Spotify Rhythm provides clarity on how to answer these questions.

  • Do you know where you are heading? North Star
  • Do you know what the destination looks like? 2 Year Goals (Results)
  • Do you know how you will get there? Company Bets (Strategies)
  • Do you know how you will track progress? DIBBs (Outcomes)
  • Do you know how you will make progress? Functional & Market Bets (Tactics)

One final element of Spotify Rhythm which relates to Strategy Deployment is implied in its name – the cadence with which the process runs. Company Bets are reviewed every quarter by the Strategy Team (another reason why they could be considered to be Strategies) and the Functional and Market Bets – also called TPD (Tech-Product-Design) Bets – are reviewed every 6 weeks.

I’d be interested in feedback on alternative interpretations of Spotify Rhythm. Or if you know more about it than I do, please correct anything I’ve got wrong!

Categories: Blogs

Dealing in Abstraction

Leading Agile - Mike Cottmeyer - Mon, 07/11/2016 - 16:12

Back when I was a project manager I read something that stuck with me.

Great project managers take the complexity of what’s happening on the ground and reflect that in a plan such that people can understand and make good decisions.

Said another way, the plan is a useful abstraction of reality.

I used to tell people that all the real work goes on in between the lines of the project plan.

I think that most folks have a tough time dealing with abstraction.

That’s a bit of a problem.

You see, what goes on in the world is complex. In some ways indescribable.

Abstractions allow us to deal with complexity in a way that we can understand.

If we demand exactness, it’s often too complicated or too expensive to model.

I used to tell people we need our plan to be close enough to reality that all the smart people working with us can get it figured out.

The real work goes on in between the lines of the plan.

If the abstraction is too far from reality, it’s not useful. It doesn’t get us close enough.

If it’s too close, it doesn’t add clarity and understanding.

I live in a world of models and abstractions and metaphor

Teams, Backlogs, Working Tested Software

Compass, Journey, and Roadmap

Structure, Governance, and Metrics

Scrum is an abstraction

SAFe is an abstraction

LeSS in an abstraction

These are tools designed to help people understand.

Frankly, there is no way to write a book about how to run YOUR company.

There are patterns that tend to work in lots of companies.

Those patterns are abstractions.

If the abstractions are close enough to reality, they simplify the story.

If not, they add to the confusion.

We have to get our systems close enough to reality that they help.

We have to understand no system will be an exact reflection of what is really happening

We have to leave it to the smart people to work it out as they go.

The post Dealing in Abstraction appeared first on LeadingAgile.

Categories: Blogs

A Brief History of the Learning Consortium

Scrum Breakfast - Mon, 07/11/2016 - 08:35
The Scrum Alliance has had a bumpy two months, with a total of 4 out of 10 directors resigning and 2 new directors coming on board -- with specialties in Corporate Governance and Ethics(!). Some of the discussions have centered around the Learning Consortium, and apparently ethics and governance are hot topics as well. To help people understand what the Learning Consortium is about, I have attempted to summarize the goals, purpose, history and probable future of the Learning Consortium.

I have known Steve Denning since he started looking for reviewers for what became 'The Leaders Guide to Radical Management'. I attended his Radical Management Gathering in Washington, DC back in 2011, and he and I were among the hosts of the Stoos Gathering in 2012. if there is a common theme to these events, it was about building bridges across compatible schools of thought.
The Story of the Learning ConsortiumIn 2014, Steve -- by then a director at the Scrum Alliance -- was arguing that to transform the world of work, it was necessary to transform the organizations where people work. He wanted to reach the business schools and thought leaders, to get Agility on their radar screens. In November, he launched the idea of the Learning Consortium (LC):
"'We have arrived at a turning point,' says the launch abstract of the Global Peter Drucker Forum 2014. “Either the world will embark on a route towards long-term growth and prosperity, or we will manage our way to economic decline.... While there is a broad consensus emerging on the direction of change, there is less reliable information on the 'how' of making these shifts. What are the opportunities? What are the constraints? How much change is actually happening on the ground? What are the benefits? What are the costs? What are the risks? The Learning Consortium is designed to shed light on these questions."

-- November, 2014 draft of the call for participation Exploring A Learning Consortium For The Creative EconomyThe idea was to identify companies that were systematically facing the challenges that Scrum helps them address, document their cases, and publish the results.

The leadership was provided by the Scrum Alliance, and the three principal organizers were:
  • Steve Denning, a board member of Scrum Alliance
  • Jay Goldstein, Adjunct Professor of Entrepreneurship at McCormick School of Engineering at Northwestern University,
  • Michael Pacanowsky, holder of the Gore-Giovale Chair in Business Innovation at Westminster College in Salt Lake City, Utah
I attempted to recruit some Swiss companies to participate. I did not succeed for reasons that have more to do with local market than the Learning Consortium itself, so my direct involvement was limited to the beginnings. I have however talked to Steve Denning and Jay Goldstein about the progress of the Learning Consortium from time to time over the last year and half or so.

My recollection is that the Scrum Alliance Trainers and Coaches ("TCC") Community did not react strongly to the LC initiative. Perhaps 10% or 20% participated in the webinar. So the LC got started as a board-level initiative without much support (nor AFAIK much resistance) from the TCC Community at the time.

The LC started building the bridge between Agile management and classical management - One aspect was the Scrum Alliance LC webinar series. Quite a number of thought leaders appeared, including Gary Hamel, John Hagel, Rod Collins, Roger Martin and Curt Carlson, as well as CSTs like Joe Justice, Simon Roberts and myself. (Man am I honored to be on the same page with these people!) The series was quite popular: iirc about 4000 people signed up for the webinar I participated in.

The Learning Consortium also created a group of companies, whose purpose was to share knowledge at the leadership level among companies who were facing the challenges of the Creative Economy. These companies included:
  • agile42
  • Brillio
  • C.H. Robinson International
  • Ericsson
  • Magna International
  • Menlo Innovations
  • Microsoft
  • Riot Games
  • SolutionsIQ
They organized a series of site visits so they could learn from each other. After a year, they held a members-only conference to share results. Due to the sensitive nature of the information they were sharing, they made working agreements about what to share and how to communicate that information beyond the LC. Out of this conference, the principals wrote the concluding paper.

The concluding paper was presented in November, 2015 to the annual Drucker Forum, while the Scrum Alliance was a sponsor of that event. Imagine, the thought leaders of management thinking listen to how Agile was being used to successfully master the challenges of the 21st century! AFAIK this is the first time Agile has been on the radar screen of the thought leaders of management.

BTW - If you haven't read the report, I recommend it. You can download it from the Scrum Alliance (officially) or without going through their registration wall. The paper is "Presented by ScrumAlliance", authored by Steve Denning and two others. It is licensed under the Creative Commons Non-Commercial Share-Alike license. The essential message is that Agility is a mindset. Just applying the tools and processes is not sufficient to give you the results you are looking for.
What is planned?My understanding is that the company visits were very well liked by the participants. The NPS scores were very high and the participants decided to continue. The members have founded a new non-profit organization. The Scrum Alliance is a founding member, is making a significant financial contribution and is represented on the board.

The new LC will participate in the 2016 Drucker Forum (scroll down to "Large-scale Organizational Transformations Enabling Rapid Business Innovation"). Executives from Learning Consortium members will join Steve Denning and management guru Gary Hamel to discuss innovative management practices. (Note how they avoid the "A-word" -- this is speaking the language of business leaders).
My analysis of the situationI don't understand why the Learning Consortium is controversial. The alignment with the Scrum Alliance mission is clear. Surely the Scrum Alliance board has approved this every step of the way, especially given that the Scrum Alliance is a dues-paying member of the new LC and has seats on its board.

The Learning Consortium was and continues to be non-profit. AFAIK Steve Denning has worked and continues to work on a pro-bono basis, i.e. without any financial compensation other than reimbursement of travel expenses. Rumors of people using this to launch their consulting practice seem unfounded.

The mission of the Scrum Alliance is to "transform the world of work." This transformation is first and foremost a change in mindset, not just introducing a set of processes and tools. To be effective and sustainable, the leadership of an organization must adopt the mindset. The Learning Consortium has a plan and a vision for taking that message to the top leaders of business, via the schools and thought leaders who influence that leadership.

I hope the Scrum Alliance and its former board members will resolve their differences quickly, without a long, messy and expensive divorce. The Scrum Alliance is doing great things for the transformation. The Learning Consortium is doing great things for the transformation. Any differences between the people in these organizations should not detract from the more important mission of Transforming the World of Work.

Update: 11.Jul.2016: Added Ericsson, which I had somehow not included. Thanks Erik Schön!
Categories: Blogs

Python: Scraping elements relative to each other with BeautifulSoup

Mark Needham - Mon, 07/11/2016 - 08:01

Last week we hosted a Game of Thrones based intro to Cypher at the Women Who Code London meetup and in preparation had to scrape the wiki to build a dataset.

I’ve built lots of datasets this way and it’s a painless experience as long as the pages make liberal use of CSS classes and/or IDs.

Unfortunately the Game of Thrones wiki doesn’t really do that so I had to find another way to extract the data I wanted – extracting elements based on their position to more prominent elements on the page.

For example, I wanted to extract Arya Stark‘s allegiances which look like this on the page:

2016 07 11 06 45 37

We don’t have a direct route to her allegiances but we do have an indirect path via the h3 element with the text ‘Allegiance’.

The following code gets us the ‘Allegiance’ element:

from bs4 import BeautifulSoup
file_name = "Arya_Stark"
wikia = BeautifulSoup(open("data/wikia/characters/{0}".format(file_name), "r"), "html.parser")
allegiance_element = [tag for tag in wikia.find_all('h3') if tag.text == "Allegiance"]
> print allegiance_element
[<h3 class="pi-data-label pi-secondary-font">Allegiance</h3>]

Now we need to work out the relative position of the div containing the houses. It’s inside the same parent div so I thought it’d probably be the next sibling:

next_element = allegiance_element[0].next_sibling
> print next_element

Nope. Nothing! Hmmm, wonder why:

> print, type(next_element)
None <class 'bs4.element.NavigableString'>

Ah, empty string. Maybe it’s the one after that?

next_element = allegiance_element[0].next_sibling.next_sibling
> print, type(next_element)
[<a href="/wiki/House_Stark" title="House Stark">House Stark</a>, <br/>, <a href="/wiki/Faceless_Men" title="Faceless Men">Faceless Men</a>, u' (Formerly)']

Hoorah! Afer this it became a case of working out how the text was structure and pulling out what I wanted.

The code I ended up with is on github if you want to recreate it yourself.

Categories: Blogs

Neo4j 3.0 Drivers – Failed to save the server ID and the certificate received from the server

Mark Needham - Mon, 07/11/2016 - 07:21

I’ve been using the Neo4j Java Driver on various local databases over the past week and ran into the following certificate problem a few times:

org.neo4j.driver.v1.exceptions.ClientException: Unable to process request: General SSLEngine problem
	at org.neo4j.driver.internal.connector.socket.SocketClient.start(
	at org.neo4j.driver.internal.connector.socket.SocketConnection.<init>(
	at org.neo4j.driver.internal.connector.socket.SocketConnector.connect(
	at org.neo4j.driver.internal.pool.InternalConnectionPool.acquire(
	at org.neo4j.driver.internal.InternalDriver.session(
Caused by: General SSLEngine problem
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.wrap(
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.runHandshake(
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.<init>(
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.<init>(
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.<init>(
	at org.neo4j.driver.internal.connector.socket.SocketClient$ChannelFactory.create(
	at org.neo4j.driver.internal.connector.socket.SocketClient.start(
	... 14 more
Caused by: General SSLEngine problem
	at Method)
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.runDelegatedTasks(
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.unwrap(
	at org.neo4j.driver.internal.connector.socket.TLSSocketChannel.runHandshake(
	... 19 more
Caused by: Unable to connect to neo4j at `localhost:10003`, because the certificate the server uses has changed. This is a security feature to protect against man-in-the-middle attacks.
If you trust the certificate the server uses now, simply remove the line that starts with `localhost:10003` in the file `/Users/markneedham/.neo4j/known_hosts`.
The old certificate saved in file is:
The New certificate received is:
	at org.neo4j.driver.internal.connector.socket.TrustOnFirstUseTrustManager.checkServerTrusted(
	... 28 more

I got a bit lazy and just nuked the file it mentions in the error message – /Users/markneedham/.neo4j/known_hosts – which led to this error the next time I call the driver in my application:

Failed to save the server ID and the certificate received from the server to file /Users/markneedham/.neo4j/known_hosts.
Server ID: localhost:10003
Received cert:

I recreated the file with no content and tried again and it worked fine. Alternatively we can choose to turn off encryption when working with local databases and avoid the issue:

Config config = Config.EncryptionLevel.NONE ).toConfig();
try ( Driver driver = GraphDatabase.driver( "bolt://localhost:7687", config );
      Session session = driver.session() )
   // use the driver
Categories: Blogs

10 Statements You’ll Hear In a Maturing Agile Team

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


A maturing agile team functions quite differently than any other team environment. Here are 10 examples of statements you’ll hear in a developing agile team.


  1. “Change is to be expected. Change is welcomed and embraced.”
  2. “Your work is already fantastic but the team is growing. How can we support you in developing the skills to adapt to our advancing team?”
  3. “You need to change. So do we all. What can we put in place as an organization to support this advancement?”
  4. “Let’s do an experiment. It might be right or it might be wrong but we won’t know until we try, learn, reflect.”
  5. “No one is to blame.”
  6. “Sure. We have all made mistakes but pointing them out gets us nowhere. We can say instead, ‘I am learning how to do… ‘such and such’ in a more effective way,’ and move forward confidently.”
  7. “Let’s talk about this with the whole team.”
  8. “Let’s take a vote.”
  9. “Let’s keep doing our work as we sort this out. Maturing teams mature when individuals keep doing their positive work.”
  10. “You have a choice about what work you do, when and how.”

Scott Ambler writes more on Agile teams in his article Roles on Agile Teams: From Small to Large Teams and elaborates on how “generalizing specialists” are the key to successful cross-functional teams. He writes, ” Generalizing specialists are the sweet spot between the two extremes of specialists, people who know a lot about a narrow domain, and generalists who know a little about a wide range of topics.”

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

The post 10 Statements You’ll Hear In a Maturing Agile Team appeared first on Agile Advice.

Categories: Blogs

Links for 2016-07-09 []

Zachariah Young - Sun, 07/10/2016 - 09:00
Categories: Blogs

Agile2016 is Coming!

Agile Tools - Sun, 07/10/2016 - 07:19


“This is where the Agile tribes meet.”

Agile2016 is swiftly approaching. I’ll be there in Atlanta doing a couple of talks this year. If you are going to be there you should definitely come check them out:

The Self-experimentation workshop is something that I originally developed a few years ago for XP2013. It is very hands-on, each attendee contributing their own experience to the workshop. To date it has been very popular. Some attendees have described it as one of the most invigorating talks they have ever attended. That’s pretty high praise – it’s probably my all-time favorite workshop.

If you are interested in getting a bit of a sneak preview of what this self experimentation stuff is all about, you can check out the experiments that I have run on the onestandardman blog. There is also background material here and here.

On the impediments front, there is a lot of material that you will find right here in this blog. For example there is this, and this and this. And then of course there is The Little Book of Impediments. There will be copies of the book at the bookstore for purchase at the conference. Catch me and I’ll be happy to sign one.

There will also be an Agile Management Conference meetup that will be held in the Open Jam area (time & date at the conference is TBD – check the Open Jam Board) so please join us for that if you are interested.

Filed under: Agile, impediment Tagged: Agile Management Conference, Agile2016, Impediments, Self-experimentation
Categories: Blogs

R: Sentiment analysis of morning pages

Mark Needham - Sat, 07/09/2016 - 08:36

A couple of months ago I came across a cool blog post by Julia Silge where she runs a sentiment analysis algorithm over her tweet stream to see how her tweet sentiment has varied over time.

I wanted to give it a try but couldn’t figure out how to get a dump of my tweets so I decided to try it out on the text from my morning pages writing which I’ve been experimenting with for a few months.

Here’s an explanation of morning pages if you haven’t come across it before:

Morning Pages are three pages of longhand, stream of consciousness writing, done first thing in the morning.

*There is no wrong way to do Morning Pages* – they are not high art.

They are not even “writing.” They are about anything and everything that crosses your mind– and they are for your eyes only.

Morning Pages provoke, clarify, comfort, cajole, prioritize and synchronize the day at hand. Do not over-think Morning Pages: just put three pages of anything on the page…and then do three more pages tomorrow.

Most of my writing is complete gibberish but I thought it’d be fun to see how my mood changes over time and see if it identifies any peaks or troughs in sentiment that I could then look into further.

I’ve got one file per day so we’ll start by building a data frame containing the text, one row per day:

files = list.files(root)
df = data.frame(file = files, stringsAsFactors=FALSE)
df$fullPath = paste(root, df$file, sep = "/")
df$text = sapply(df$fullPath, get_text_as_string)

We end up with a data frame with 3 fields:

> names(df)
[1] "file"     "fullPath" "text"

Next we’ll run the sentiment analysis function – syuzhet#get_nrc_sentiment – over the data frame and get a score for each type of sentiment for each entry:

get_nrc_sentiment(df$text) %>% head()
  anger anticipation disgust fear joy sadness surprise trust negative positive
1     7           14       5    7   8       6        6    12       14       27
2    11           12       2   13   9      10        4    11       22       24
3     6           12       3    8   7       7        5    13       16       21
4     5           17       4    7  10       6        7    13       16       37
5     4           13       3    7   7       9        5    14       16       25
6     7           11       5    7   8       8        6    15       16       26

Now we’ll merge these columns into our original data frame:

df = cbind(df, get_nrc_sentiment(df$text))
df$date = ymd(sapply(df$file, function(file) unlist(strsplit(file, "[.]"))[1]))
df %>% select(-text, -fullPath, -file) %>% head()
  anger anticipation disgust fear joy sadness surprise trust negative positive       date
1     7           14       5    7   8       6        6    12       14       27 2016-01-02
2    11           12       2   13   9      10        4    11       22       24 2016-01-03
3     6           12       3    8   7       7        5    13       16       21 2016-01-04
4     5           17       4    7  10       6        7    13       16       37 2016-01-05
5     4           13       3    7   7       9        5    14       16       25 2016-01-06
6     7           11       5    7   8       8        6    15       16       26 2016-01-07

Finally we can build some ‘sentiment over time’ charts like Julia has in her post:

posnegtime <- df %>% 
  group_by(date = cut(date, breaks="1 week")) %>%
  summarise(negative = mean(negative), positive = mean(positive)) %>% 
names(posnegtime) <- c("date", "sentiment", "meanvalue")
posnegtime$sentiment = factor(posnegtime$sentiment,levels(posnegtime$sentiment)[c(2,1)])
ggplot(data = posnegtime, aes(x = as.Date(date), y = meanvalue, group = sentiment)) +
  geom_line(size = 2.5, alpha = 0.7, aes(color = sentiment)) +
  geom_point(size = 0.5) +
  ylim(0, NA) + 
  scale_colour_manual(values = c("springgreen4", "firebrick3")) +
  theme(legend.title=element_blank(), axis.title.x = element_blank()) +
  scale_x_date(breaks = date_breaks("1 month"), labels = date_format("%b %Y")) +
  ylab("Average sentiment score") + 
  ggtitle("Sentiment Over Time")

2016 07 05 06 47 12

So overall it seems like my writing displays more positive sentiment than negative which is nice to know. The chart shows a rolling one week average and there isn’t a single week where there’s more negative sentiment than positive.

I thought it’d be fun to drill into the highest negative and positive days to see what was going on there:

> df %>% filter(negative == max(negative)) %>% select(date)
1 2016-03-19
> df %>% filter(positive == max(positive)) %>% select(date)
1 2016-01-05
2 2016-06-20

On the 19th March I was really frustrated because my boiler had broken down and I had to buy a new one – I’d completely forgotten how annoyed I was, so thanks sentiment analysis for reminding me!

I couldn’t find anything particularly positive on the 5th January or 20th June. The 5th January was the day after my birthday so perhaps I was happy about that but I couldn’t see any particular evidence that was the case.

Playing around with the get_nrc_sentiment function it does seem to identify positive sentiment when I wouldn’t say there is any. For example here’s some example sentences from my writing today:

> get_nrc_sentiment("There was one section that I didn't quite understand so will have another go at reading that.")
  anger anticipation disgust fear joy sadness surprise trust negative positive
1     0            0       0    0   0       0        0     0        0        1
> get_nrc_sentiment("Bit of a delay in starting my writing for the day...for some reason was feeling wheezy again.")
  anger anticipation disgust fear joy sadness surprise trust negative positive
1     2            1       2    2   1       2        1     1        2        2

I don’t think there’s any positive sentiment in either of those sentences but the function claims 3 bits of positive sentiment! It would be interesting to see if I fare any better with Stanford’s sentiment extraction tool which you can use with syuzhet but requires a bit of setup first.

I’ll give that a try next but in terms of getting an overview of my mood I thought I might get a better picture if I looked for the difference between positive and negative sentiment rather than absolute values.

The following code does the trick:

difftime <- df %>% 
  group_by(date = cut(date, breaks="1 week")) %>%
  summarise(diff = mean(positive) - mean(negative))
ggplot(data = difftime, aes(x = as.Date(date), y = diff)) +
  geom_line(size = 2.5, alpha = 0.7) +
  geom_point(size = 0.5) +
  ylim(0, NA) + 
  scale_colour_manual(values = c("springgreen4", "firebrick3")) +
  theme(legend.title=element_blank(), axis.title.x = element_blank()) +
  scale_x_date(breaks = date_breaks("1 month"), labels = date_format("%b %Y")) +
  ylab("Average sentiment difference score") + 
  ggtitle("Sentiment Over Time")
2016 07 09 07 05 34

This one identifies peak happiness in mid January/February. We can find the peak day for this measure as well:

> df %>% mutate(diff = positive - negative) %>% filter(diff == max(diff)) %>% select(date)
1 2016-02-25

Or if we want to see the individual scores:

> df %>% mutate(diff = positive - negative) %>% filter(diff == max(diff)) %>% select(-text, -file, -fullPath)
  anger anticipation disgust fear joy sadness surprise trust negative positive       date diff
1     0           11       2    3   7       1        6     6        3       31 2016-02-25   28

After reading through the entry for this day I’m wondering if the individual pieces of sentiment might be more interesting than the positive/negative score.

On the 25th February I was:

  • quite excited about reading a distributed systems book I’d just bought (I know?!)
  • thinking about how to apply the tag clustering technique to meetup topics
  • preparing my submission to PyData London and thinking about what was gonna go in it
  • thinking about the soak testing we were about to start doing on our project

Each of those is a type of anticipation so it makes sense that this day scores highly. I looked through some other days which specifically rank highly for anticipation and couldn’t figure out what I was anticipating so even this is a bit hit and miss!

I have a few avenues to explore further but if you have any other ideas for what I can try next let me know in the comments.

Categories: Blogs

Connecting AWS CloudWatch Alarms to Pager Duty with Terraform

I have a small item to share from the trenches today: connecting AWS Cloudwatch alarms to Pager Duty using Terraform. No back story here… just a simple “here’s how you connect these two up.”


Categories: Blogs

Personal Design Thinking

I'm currently reading the book Design the Life You Love by Ayse Birsel. The book takes a look at Design Thinking and applying it to your own life. It is based on the success that the author has had as a product designer.
The book takes you through a four-step process; Deconstruction, Point of View, Reconstruction, and Expression. She uses examples from her own design career to help illustrate the steps of the process. 
In the Deconstruction phase, there are exercises to break your life down into some of its pieces. For example, in one exercise you start with the number of areas including family, work, friends, and hobbies and break those down into more meaning for you. It's really just a mind map that you're trying to create. 
The section on Point of View is meant to help you try to look at things differently. For example, she talks about how Steve Jobs looked at a rice cooker with a magnetic power cord and thought that would be a great idea for a laptop. The idea is taking something in one context and moving it to another context. 
Reconstruction is taking the pieces that have been identified and put them back together in a different way. 
Finally, Expression is about how you externalize this effort. There are some different ideas including vision letters and vision maps. 

This really is a workbook that you want to spend time on every day to go through the exercises. I would not recommend getting the book in an electronic format, it is much more practical to have the physical book that you can draw in as you go through the exercise. There are some exercises that involve drawing, mind mapping, etc and throughout the activities, you want to go back and review earlier work. 
I'm working through the last section, so I don't know how it will all turn out, but I have had some valuable insights. The book is laid out logically and it does get you to think. 
In closing, there is a quote from Ralph Caplan, author of By Design;
When it comes to life,
There is no such thing as design
There is only redesign
Categories: Blogs