Skip to content

Feed aggregator

Practice Courage: Move Beyond Planning Into Action

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Courage is required to move beyond planning into action. The amount of courage correlates to the attachment we feel to our plans and the attitude we have about failure. Risk-averse/plan-heavy environments are discouraging — risk-tolerant/experimental environments are encouraging.

Are you stuck in planning mode?

I was coaching Product Managers working for a demanding Chief Product Officer. Not only demanding but also visionary yet particular, energetic yet moody, instinctual yet empirical, intensely focused yet integrally involved in all aspects of business — he led the creation of a multi-billion dollar product so these traits are evidently effective. The Product Managers faced intense pressure.

When I met the group, projects underway by the engineering teams were all in the name of optimization or reliability of existing features. New product ideas had been shelved and Product Managers felt paralyzed in a pattern of planning and analysis. The more they planned, the more they became attached to their plans, the more they were disheartened when the CPO rejected their plans, so the more they would plan.

To break from that pattern, I petitioned hard for a four-day hack-a-thon so the whole product development organization could self-organize and feel encouraged to try new things. With mere *minutes* of up-front planning, teams started testing new product ideas in a safe-to-fail setting.

The results were powerful. The barriers to action had dissolved and within months the company could announce new features and previously-shelved product ideas were underway.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Practice Courage: Move Beyond Planning Into Action appeared first on Agile Advice.

Categories: Blogs

Agile Scaled Framework

Agile Ottawa - Thu, 07/30/2015 - 20:04
Scaling agile methods is controversial topic in the community. Do we even know what it means? Does it make sense in our organization’s context? This meetup will introduce four agile frameworks designed to scale, and then compare their features. Disciplined Agile Delivery … Continue reading →
Categories: Communities

Agile Transformation Metrics

Learn more about our Scrum and Agile training sessions on WorldMindware.com

TL;DR

When asked to provide metrics to assess “how well” an Agile transformation is going, re-frame the discussion around measuring changes in the impact the IT organization is having (or not) on it’s Business environment, and define a small set of “fitness for purpose” metrics.

The Inevitable Question about Agile Transformation Metrics

Sooner or later, as an IT organization embarks on a transformation towards Agile mindset and practices, someone will be asked to provide “hard evidence” that the effort is paying off, and the conclusion will be that metrics is the vehicle to satisfy that request. What are your Agile transformation metrics?

It’s been my experience that this request usually leads to a discussion about measuring the specific Agile initiatives the IT organization has launched. In organizations where the emphasis has been around engineering disciplines, such metrics might be things like unit test code coverage, or integration build times. If the focus  was around teams and process, then counting number of teams “converted” to Scrum, or people sent to Scrum Master training may appear as the choice.

While those measurement might be useful indicators in some context, they have two problems. First, they are akin to measuring the performance of the car engine without looking outside the window; the engine might be performing well, but if the car doesn’t have the wheels attached, we’re going nowhere. More importantly, though, these figures are usually meaningless for Business stakeholders, who are the ones usually asking for them in the first place.  Agile transformation metrics need to be meaningful to the Business.

Re-framing the Agile Transformation Metrics Question

Agile transformation efforts can be very costly exercises, therefore it is legitimate to ask about the results of such endeavour. The important thing to realize, though, is that this question is really equivalent to another question: “is the IT organization improving its impact on its Business environment.” Another way to put it is, borrowing from the terminology used by the Kanban community: “is the IT organization becoming more and more fit for purpose?” Answering this question, of course, requires a clear understanding of what is that the Business expects from its interactions with IT.

The IT organization can be seen as providing various services to customers. Arguably, if IT has decided to “transform” in some way (perhaps by moving towards an Agile mindset), it’s doing so to improve its impact on those customers, so this is what needs to be measured to know “how the transformation” is going.

Some of those customers are different areas of the organization (like Finance, or HR.) But it doesn’t stop there, because the Business’ engagement with IT doesn’t have value for its own sake. Ultimately, the Business is using IT as a way to optimize its operations so that it can provide external customers with more effective products and services. Moreover, IT is these days the direct channel through which those products and services are delivered to external customers (for example, through web sites and mobile applications.) Therefore, the concept of “fitness for purpose” of the IT organization can be extended to consider the fitness for purpose of the Business respect the external customers it intends to serve.

Defining the “Agile” Transformation Metrics

Measuring “agile transformation success” really means measuring the success of the exchanges between IT and the Business, and between the Business and its external customers.  Measuring the internal processes and practices that IT puts in place as part of that “transformation” is beside the point. This implies starting with a careful definition of the boundaries that delineate the exchanges to be measured. There might be more to external customer fitness for purpose than IT operations, for example, and that needs to be considered when defining Agile transformation metrics, especially if we’re later going to be drawing causation conclusions.

Defining Agile transformation metrics will be, of course,  a highly contextual exercise because every business organization is different.  But we can, however, draw again from the Kanban community for some general guidelines on what to look for. Their thought leaders talk about classifying metrics into 3 categories: fitness for purpose metrics, health indicators and improvement drivers.  Using this framework, when talking about “agile transformation metrics” we are referring mainly to the first category, and perhaps a bit to the second. Based on those, improvement initiatives can be put in place, and perhaps driven with metrics belonging to the third category.

A fitness for purpose metric (also known as KPI) is an indicator of something a customer will care about. This is a key distinction: if the metric is not easily recognizable and meaningful for the customer, then it’s not a KPI. Another key characteristic is that a minimum threshold for its value can be defined: if the metric goes below the threshold, the Business is putting the relation with its customers at risk (perhaps they will walk away, initiate legal actions, etc.). In other words, the Business is no longer “fit for purpose”. We can then measure the effectiveness of the “agile transformation” by analyzing how KPI values over time compare to their respective thresholds. A typical KPI is delivery time, measured from the moment a customer request is accepted and committed to, until the moment it’s delivered to production.  This is usually a good Agile transformation metric.

Health indicators are metrics that are inwards facing. Customers don’t really care about them (or even understand), but they indicate how a given aspect of the system is operating. The key characteristic is that they are not directly actionable; they only provide information that needs to be analyzed and put in context. As the value of a health indicator changes, we can draw some conclusions about how the system works, or explain why something is happening (or not), but it doesn’t necessarily leads to concrete action. Defect count is an example of this. Customers will certainly care about quality of the product, and we can make inferences about that quality by looking at how many defects we have, but the absolute number of defects will not necessarily make the product more or less fit for purpose. It may happen that customers consider the current quality to be “good enough”, irrespective of the number of defects.

Finally, improvement driver metrics are metrics put in place to influence behaviour towards a particular change. Their key characteristic is that they are temporary: we set a target on them and once the target is achieved, the metric is no longer necessary. The reason for this is related to the unintended behaviours that a metric might encourage in people, which may lead to locally optimizing the metric at the expense of other aspects, leading to global sub-optimization of the system. An example is unit testing code coverage: if we have determined that a given service is not fit for purpose and the cause is related to poor unit test coverage, then establishing a target for minimum coverage may influence developers to work on adding tests to reverse the situation.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Agile Transformation Metrics appeared first on Agile Advice.

Categories: Blogs

Embracing the Zen of Program Management

Johanna Rothman - Thu, 07/30/2015 - 14:47

The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management.  I hope you like the information there.

 Scaling Collaboration Across the OrganizationIf you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.

Categories: Blogs

Three Leadership “Musts” for DevOps

Agile Management Blog - VersionOne - Thu, 07/30/2015 - 14:30

 

Three Leadership

 

 

 

 

 

 

 

 

A middle-of-the-night phone call is never a good thing – especially when the director of technology operations is on the other end. It was 2:00 a.m. in the summer of 2003 when I was abruptly awakened from my phone’s vibration.

My nightmare started as the director of technology operations reported that the system was down with no resolution in sight.

A company system outage is comparable to cutting off blood flow to the brain. When the system is down, there’s no cash and the business starts to die. No matter the size or stature of a company, technology leaders constantly carry the fear that even the smallest system outage could seriously damage their work. While this fear is hidden deep inside the psyche, it’s a reality that all tech leaders learn to live with.

My system outage was no different from eBay’s in the summer of 1999. The eBay auction site suffered from a series of system outages – the longest outage lasting 22 hours.

That outage cost eBay $5 million of transaction revenue. This $5 million may sound like a lot, but, in reality, it was nothing compared to the $4 billion drop in the company’s market value as the result of the outage.

WHAT ABOUT NOW?

Almost two decades later, and technology experts are still experiencing major complications in their systems.

In July 2015 alone, recent outages and system failures have affected the New York Stock Exchange, United Airlines, Department of State’s Visa system, Apple’s iStore, and – most notably – the Royal Bank of Scotland’s IT systems, which reported that a half-million financial transactions vanished from the system due to an unknown error.

They say “time heals all wounds,” but system outages may be the exception to this rule, as effects can be severe.

“For the Fortune 1000, the average total cost of unplanned application downtime per year is $1.25 billion to $2.5 billion,” says Stephen Elliot, IDC Analyst. “The average cost of a critical application failure per hour is $500,000 to $1 million.”

We are still not immune to these outages and we must take great care in avoiding these issues, or risk losing time, money and business.

WHAT IS HAPPENING?

Today’s systems are growing exponentially more complicated. Rising demand, volumes of aging data, patchwork of software, and network infrastructure each impact a system’s complexity and deployments. IDC estimates that the average amount of monthly deployments will double in two years.

To combat the case of system failures, technology leaders must adjust to an era of instant consumption – the “have to have it now” era. The world is no longer satisfied with singular massive updates to their systems every 12 or 6 months. Rather, we need to “deploy on demand,” where software can be updated several times per day with 100% resilience.

In other words, we need DevOps.

THE WAVE OF CHANGE IS HERE

Simply described, DevOps is the collaboration and communication between software developers and technology professionals in the IT value chain to deploy software to customers. Gene Kim, author of The Phoenix Project refers to DevOps as “the outcome of applying Lean Principles to the IT value stream.”

To achieve greatness, DevOps demands leadership vision and involvement. This requires sponsorship, so operational and cultural norms can change. It’s likely that your company will need to incorporate all of these changes to ensure long-term success.

DevOps is successful because it dramatically reduces a company’s operational risk by creating conditions that advance company culture, interactions, and tools.

Imagine a world where product, development, QA, infosec, and operations are orchestrating together to deliver business value at the fastest pace possible in an “IT value stream.” And fast execution isn’t the only benefit here – the process also has high predictability and low risk. This symphony of establishing a reliable flow across the organization – along with cultivating the right culture – is the foundation on which change can be made.

In May 2011, LinkedIn’s valuation doubled to $9 billion on its second day after IPO. With the stock soaring and a flood of new users flocking to the professional social networking site, LinkedIn was Wall Street’s golden child. Kevin Scott, LinkedIn’s top engineer didn’t feel as confident. Scott knew that the system and its engineers were being crushed by it’s own technology infrastructure inhibiting growth.

In a bold move, Scott launched Project InVersion, an initiative where all new feature development for LinkedIn stopped so that every engineer focused on rebuilding its core technology infrastructure. “You go public, have all the world looking at you, and then we tell management we’re not going to deliver anything new while all of engineering works on this project for the next two months,” Scott says. “It was a scary thing.” This work centered on LinkedIn’s ability to build out DevOps so that it could scale and accelerate while eliminating technical risks.

This resulted in extending the company’s deployment capabilities so that it can deploy changes at a moments notice at any time of day. Further, it helped support the growth of LinkedIn’s user base to over 364 million members and a market cap of $28 billion.

THE THREE LEADERSHIP MUST-HAVES

Gene Kim describes DevOps as a “philosophical movement.” And he’s right. As DevOps garners more attention, experts are deliberating its “best practices” and developing tools to support those practices.

To enable success, I have found there are 3 “musts” that leadership should have when launching a DevOps movement. These “musts” are based on the premise that DevOps requires disruptive leadership.

1. Executive Involvement

Leaders, including the CTO and the CEO, must work together to make DevOps a strategic priority. Just as soldiers, airplanes, satellites, and technology are strategic assets for the military, technology leaders need to utilize DevOps assets to achieve their goals. Leaders should engage with business counterparts when harnessing the strategic value of DevOps.

Successful DevOps transformations require executive participation and understanding. With the DevOps’ unification of the technology value stream, it becomes a unique strategic capability that enables faster innovation and faster time to market.

2. Organizational Design Focused on Agile Value Delivery

DevOps transformations are not simple. They are difficult and require creativity which leads to a journey that not all people in your company are prepared to take.

Value Driven Organizations

The best way to confront this challenge is to develop a healthy organization design. Separate organizational silos split by domains may be traditional; however, they are no longer effective. Many organizations, particularly those using Agile, are experiencing success by building cross-functional teams. Each team creates work in segments of time, or “sprints.” Each sprint results in the team delivering potentially shippable increments of work product. Moreover, place more emphasis on grouping team to swarm on delivering shared objectives. This structure will have a powerful effect on your company’s ability to collaborate and build business value.

This approach places more emphasis on teamwork. The teams design, build, and test as a team. And, throughout the development process, these teams actively coordinate with Technology Operations, InfoSec, and others to ensure that their work can be deployed.

Craftsmanship & Automation

Great DevOps companies require thoughtful and deliberate decisions to encourage great engineering craftsmanship. This craftsmanship ensures software is built with practices that encourage high quality product. The practices we follow should focus on receiving fast feedback on whether or not the code really works.

Today, practices like Test Driven Development (TDD) are used to create lines of tests before the code is written. By writing the code to after the tests are created, developers create a collection of code that, by definition, is already tested before it’s finished, thus reducing errors in increasing quality.

Automation is another key element to the product development flow. Once automated, a developer can automatically test the code with a simple click. The system can test the changes across thousands of developers’ new code in a fraction of time compared to manual tests.

3. Synchronized Product Planning and DevOps Planning

Several successful DevOps groups are also accelerating their delivery capabilities with support teams. Technology operations, infosec, architecture, and risk/compliance teams are often involved in product planning.

This results in a higher degree of coordination in the product development cycle. Aspects of security, scalability, reliability, are baked into the solution from the earliest stages of planning. Moreover, by tying together areas of release management practices at the beginning, the organization’s ability to coordinate product delivery matures faster.

DevOps may seem like a lot of work, but technology leaders should consider it a smart business investment. Companies unwilling or unable to adapt will be left behind and trapped under the weight of their own antiquated practices. Those slow to react will not be able to compete due to limitations of deployment speed and resiliency. However, it’s the companies employing DevOps that will outmaneuver and outpace their competition, leaving others in the dust.

Stacey Louie is the CEO of Bratton & Company, a leading Agile Transformation consultancy based in the Silicon Valley. As an Enterprise Agile Coach, he was instrumental in PayPal’s 400 team global agile transformation as well as supporting other Fortune 500 companies including Cisco, Hewlett Packard, and eBay. He also held the position of division CTO/CIO of public companies including Verisk Analytics and Stewart Information Systems.

 

Categories: Companies

Improve your meetings in just 5 minutes

Growing Agile - Thu, 07/30/2015 - 10:03
How often do you take 5 minutes after a meeting or training session to reflect on what happened? After every meeting we have with a client or workshop we talk about what happened and reflect. We wonder about things that worked well and why that was. We talk about things that went badly and try to understand why. […]
Categories: Companies

Neo4j: Cypher – Removing consecutive duplicates

Mark Needham - Thu, 07/30/2015 - 08:23

When writing Cypher queries I sometimes find myself wanting to remove consecutive duplicates in collections that I’ve joined together.

e.g we might start with the following query where 1 and 7 appear consecutively:

RETURN [1,1,2,3,4,5,6,7,7,8] AS values
 
==> +-----------------------+
==> | values                |
==> +-----------------------+
==> | [1,1,2,3,4,5,6,7,7,8] |
==> +-----------------------+
==> 1 row

We want to end up with [1,2,3,4,5,6,7,8]. We can start by exploding our array and putting consecutive elements next to each other:

WITH [1,1,2,3,4,5,6,7,7,8] AS values
UNWIND RANGE(0, LENGTH(values) - 2) AS idx
RETURN idx, idx+1, values[idx], values[idx+1]
 
==> +-------------------------------------------+
==> | idx | idx+1 | values[idx] | values[idx+1] |
==> +-------------------------------------------+
==> | 0   | 1     | 1           | 1             |
==> | 1   | 2     | 1           | 2             |
==> | 2   | 3     | 2           | 3             |
==> | 3   | 4     | 3           | 4             |
==> | 4   | 5     | 4           | 5             |
==> | 5   | 6     | 5           | 6             |
==> | 6   | 7     | 6           | 7             |
==> | 7   | 8     | 7           | 7             |
==> | 8   | 9     | 7           | 8             |
==> +-------------------------------------------+
==> 9 rows

Next we can filter out rows which have the same values since that means they have consecutive duplicates:

WITH [1,1,2,3,4,5,6,7,7,8] AS values
UNWIND RANGE(0, LENGTH(values) - 2) AS idx
WITH values[idx] AS a, values[idx+1] AS b
WHERE a <> b
RETURN a,b
 
==> +-------+
==> | a | b |
==> +-------+
==> | 1 | 2 |
==> | 2 | 3 |
==> | 3 | 4 |
==> | 4 | 5 |
==> | 5 | 6 |
==> | 6 | 7 |
==> | 7 | 8 |
==> +-------+
==> 7 rows

Now we need to join the collection back together again. Most of the values we want are in field ‘b’ but we also need to grab the first value from field ‘a':

WITH [1,1,2,3,4,5,6,7,7,8] AS values
UNWIND RANGE(0, LENGTH(values) - 2) AS idx
WITH values[idx] AS a, values[idx+1] AS b
WHERE a <> b
RETURN COLLECT(a)[0] + COLLECT(b) AS noDuplicates
 
==> +-------------------+
==> | noDuplicates      |
==> +-------------------+
==> | [1,2,3,4,5,6,7,8] |
==> +-------------------+
==> 1 row

What about if we have more than 2 duplicates in a row?

WITH [1,1,1,2,3,4,5,5,6,7,7,8] AS values
UNWIND RANGE(0, LENGTH(values) - 2) AS idx
WITH values[idx] AS a, values[idx+1] AS b
WHERE a <> b
RETURN COLLECT(a)[0] + COLLECT(b) AS noDuplicates
 
==> +-------------------+
==> | noDuplicates      |
==> +-------------------+
==> | [1,2,3,4,5,6,7,8] |
==> +-------------------+
==> 1 row

Still happy, good times! Of course if we have a non consecutive duplicate that wouldn’t be removed:

WITH [1,1,1,2,3,4,5,5,6,7,7,8,1] AS values
UNWIND RANGE(0, LENGTH(values) - 2) AS idx
WITH values[idx] AS a, values[idx+1] AS b
WHERE a <> b
RETURN COLLECT(a)[0] + COLLECT(b) AS noDuplicates
 
==> +---------------------+
==> | noDuplicates        |
==> +---------------------+
==> | [1,2,3,4,5,6,7,8,1] |
==> +---------------------+
==> 1 row
Categories: Blogs

The Context for Agility

Agile For All - Bob Hartman - Thu, 07/30/2015 - 05:15

Some people learn best by reading. Others prefer video. So, I’ve created a video of my blog post: The Future of Agile, Changing the World of Work. The video puts agility into its historic context, examining the generational waves of new and better ways for organizations to approach their work in a world of increasing pace of change, complexity and interconnectedness.

generational-waves Lean emerged in the 1970s, Agile in the 1990s, Lean Startup in the current decade, and Organizational Agility and Leadership patterns are just beginning to emerge. It seems that it takes a generational turnover for these new mindsets to become prevalent. Continue on to watch the video.

We are passionate about helping organizations find real purpose and engagement in their work. We regularly work with organizations to combine the ideas in this video with leadership development, systems thinking, complexity science, and other related fields. If you’d like to learn more, please reach out! You can find all of my info here. Also, if you think others would find this video useful, please feel free to share it using one of the links below.

Upcoming Public Courses

The post The Context for Agility appeared first on Agile For All.

Categories: Blogs

Version R6#14.2

IceScrum - Wed, 07/29/2015 - 20:08
Will be available soon.
Categories: Open Source

Beyond Control Charts and Cumulative Flow Diagrams

Improving projects with xProcess - Wed, 07/29/2015 - 18:54
Control Charts (CCs) and Cumulative Flow Diagrams (CFDs) are powerful ways to display information about a flow system, such as a Scrum or Kanban development process. Unfortunately the very fact that the charts display so much information means that it is often difficult to extract specific information from them. That is why it's useful to also plot some of the key attributes of the systems on their own - this allows us to look at these aspects specifically, alongside the rawer view of the data that you get from CCs and CFDs.

The graphic on the right shows a number of diagrams all of which were derived from very simple data about each item that flowed through this system:
  • when it arrived into the system; 
  • when it departed the system; and
  • whether the item was "delivered" or "discarded".
Note: I use the term "discard" here as a general term to include an exit from the system at any point in the system and for any reason. It includes aborting/abandoning the item after commitment, as well as postponing the item by moving it back to a part of the process upstream from the system under study. For the definition of this and other terms used here please see this Glossary.The first diagrams in the graphic is the Control Chart - actually this is simply a scatter plot of the time each item stays in the system under study. I refer to this as "Time in Process - TiP - or alternatively "Time in _______" where the blank stands for whatever the process or part of the process is under study. For example it could be the Time in Preparation, Time in Development, Time in Acceptance, etc. The scatter plot highlights (in orange) the items which were not "delivered".
Below it is the CFD. Unlike some very stripy versions, this one has only 3 bands (as limited by the input data), corresponding to arrivals, all departures (including discards), and deliveries.
The remaining diagrams all highlight one or more aspects of the same data. Firstly the terms from Little's Law:
  1. Average Delivery Rate. This is measured in items per week, and the average is taken over 1 week. Note this only shows actually delivered items. Alternatively a plot of "Throughput" could have been used which includes all items that have passed through the system.
  2. Average Time in Process (TiP). This is measured in weeks and again the average is taken over 1 week.
  3. Average Work in Progress (WiP). This is measured in number of items, again averaged over one week. Care must be taken when calculating average WiP for a day, particularly on days when an item arrives in or departs from the system, to ensure that it is consistent with the calculations of average TiP.
In addition to these standard quantities from Little's Law a number of flow balance metrics are shown. These are:
  1. Net Flow. Simply the difference between the number arriving and departing over the previous week.
  2. Delivery Bias. This is a measure of the degree to which Delivery Rate is higher or lower than would be predicted by Little's Law for the given period (1 week in this case). If it is non-zero it indicates away from stability. Further discussion of this quantity is found here.
  3. Flow Debt/Credit. This is a measure of the degree to which the average TiP varies from that predicted by the CFD. This also indicates a degree of instability if it varies significantly from zero. See Dan Vacanti's book [vaca] for further discussion.
  4. Age of WiP Indicator. This compares the average age of the WiP with half the average Tip. It is another indicator of imbalance.
Recently I have been discussing these four quantities with colleagues and with Troy Magennis and Dan Vacanti as they show promise for predicting significant changes in the TiP, a very important aspect of the effectiveness of the system.
A spreadsheet containing the means to generate these diagrams from your data will shortly be made available from gitHub. Watch this space!
References
  • [vaca] Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)
Categories: Companies

What is Insight?

J.D. Meier's Blog - Wed, 07/29/2015 - 18:34

"A moment's insight is sometimes worth a life's experience." -- Oliver Wendell Holmes, Sr.

Some say we’re in the Age of Insight.  Others say insight is the new currency in the Digital Economy.

And still others say that insight is the backbone of innovation.

Either way, we use “insight” an awful lot without talking about what insight actually is.

So, what is insight?

I thought it was time to finally do a deeper dive on what insight actually is.  Here is my elaboration of “insight” on Sources of Insight:

Insight

You can think of it as “insight explained.”

The simple way that I think of insight, or those “ah ha” moments, is by remembering a question Ward Cunningham uses a lot:

“What did you learn that you didn’t expect?” or “What surprised you?”

Ward uses these questions to reveal insights, rather than have somebody tell him a bunch of obvious or uneventful things he already knows.  For example, if you ask somebody what they learned at their presentation training, they’ll tell you that they learned how to present more effectively, speak more confidently, and communicate their ideas better.

No kidding.

But if you instead ask them, “What did you learn that you didn’t expect?” they might actually reveal some insight and say something more like this:

“Even though we say don’t shoot the messenger all the time, you ARE the message.”

Or

“If you win the heart, the mind follows.”

It’s the non-obvious stuff, that surprises you (at least at first).  Or sometimes, insight strikes us as something that should have been obvious all along and becomes the new obvious, or the new normal.

Ward used this insights gathering technique to more effectively share software patterns.  He wanted stories and insights from people, rather than descriptions of the obvious.

I’ve used it myself over the years and it really helps get to deeper truths.  If you are a truth seeker or a lover of insights, you’ll enjoy how you can tease out more insights, just by changing your questions.   For example, if you have kids, don’t ask, “How was your day?”   Ask them, “What was the favorite part of your day?” or “What did you learn that surprised you?”

Wow, I now this is a short post, but I almost left without defining insight.

According to the dictionary, insight is “The capacity to gain an accurate and deep intuitive understanding of a person or thing.”   Or you may see insight explained as inner sight, mental vision, or wisdom.

I like Edward de Bono’s simple description of insight as “Eureka moments.”

Some people count steps in their day.  I count my “ah-ha” moments.  After all, the most important ingredient of effective ideation and innovation is …yep, you guessed it – insight!

For a deeper dive on the power of insight, read my page on Insight explained, on Sources Of Insight.com

Categories: Blogs

On my ToDo book shelf

Agile Complexification Inverter - Wed, 07/29/2015 - 17:57



A wish list of books I'd like to read...




Passionate Performance  by Lee J. Colan

This quick read cuts through the clutter to offer practical strategies to engage the minds and heart of your employeees. Learn why this is such a powerful advantage for your organization. Read it and conquer your competition!

Team of Teams: New Rules of Engagement for a Complex World   by General Stanley McChrystal


A NEW APPROACH FOR A NEW WORLDMcChrystal and his colleagues discarded a century of conventional wisdom and remade the Task Force, in the midst of a grueling war, into something new: a network that combined extremely transparent communication with decentralized decision-making authority. The walls between silos were torn down. Leaders looked at the best practices of the smallest units and found ways to ex­tend them to thousands of people on three continents, using technology to establish a oneness that would have been impossible even a decade earlier. The Task Force became a “team of teams”—faster, flatter, more flex­ible—and beat back Al Qaeda.
Categories: Blogs

2015 State Of Scrum Report Released by Scrum Alliance

Scrum Expert - Wed, 07/29/2015 - 17:42
The Scrum Alliance has announced the release of its 2015 State of Scrum Report. Almost 5,000 individuals and companies in 108 countries participated in this year’s Scrum survey. Most organizations in the market today are still leading and managing under an Industrial Age model. Not only is the speed of change growing exponentially, Agile and Scrum frameworks are showing companies how to draw on the full talents and capabilities of those doing the work in order to continue innovating for success. “Survey findings show where Scrum is today and where ...
Categories: Communities

How could we measure Team Happiness?

Agile Complexification Inverter - Wed, 07/29/2015 - 17:29
Do you believe that what you measure you will get?  If so you want to start to measure team happiness.  So what techniques do we have to measure something so ephemeral?


The health care industry has studied measuring pain and have very good data on their ability to measure and administer pain drugs upon a subjective self report.  Maybe we could do the same in knowledge worker teams and work groups.

Team Happiness Net Promoter Score sheetHere's a riff upon the classic Net Promoter Score for measuring team happiness.

 "How likely is it that you would recommend our team to a trusted friend that is looking for a job?"
To calculate the NPS - the continuum is divided into 3 groups; the detractors (1 - 6), the passive (7 & 8), the promoters (9 & 10).  The passive are ignored - they do not promote your objective.  The NET promoter score is the percentage of people promoting your objective minus the percentage of people detracting from your objective.

     NPS = Promoter % - Detractor %  (valid range +100% to -100%)
How does this objective of promoting your team as a recommendation for a friend seeking a job a proxy for team happiness?  I've not met many good people that would shaft a friend by recommending an unhappy team - have you?
Note:  with small populations (like a scrum team) there is high variability based upon a few people's scoring,  another companion metric would be the percentage of people participating in the survey.  Did the whole team play - or do you have a core group that is the in-group?

See Also:
NPS on WikipediaVisualizing Agility: Agile Metrics that Matter by Jay Packlick

Categories: Blogs

Pitfall of Scrum: Cancelled Sprint – Failure to Restart

Learn more about our Scrum and Agile training sessions on WorldMindware.com

Although a cancelled Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint. One team I heard of was doing two week Sprints, cancelled due to a major tool problem, and then waited three months for the vendor to fix the problem before going back to Sprinting. Instead, they should have used their creative problem-solving skills to find a way to continue delivering value and restarted their Sprints immediately.

The Scrum Guide puts Sprint cancellation under the authority of the Product Owner:

A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.

It is important to note that older descriptions of Scrum will sometimes mention that the ScrumMaster or the Development Team can also cancel a Sprint. This is no longer part of the core definition of Scrum.

Cancelled Sprint Emotions

A cancelled Sprint can sometimes be emotionally challenging for a Scrum Team. There are three reasons for this difficulty:

  1. Cancelling a Sprint, particularly later on in the timebox means there’s a lot of work already in progress (and possibly done). The psychology of sunk costs comes into play: we’ve invested some much in the Sprint so far, let’s just keep going to see if we can “fix” it. Going against that impulse can be very difficult.
  2. A cancelled Sprint is an acknowledgement that the fundamental direction of the current Sprint is no longer the right thing to be doing. This can seem to be an insult to the team: why didn’t “you” get it right earlier? If there are certain people on the team who advocated strongly for the current set of work, they could take Sprint cancellation particularly hard.
  3. Cancelling a Sprint may require undoing technical work and may be complex. If team members have made changes that they are particularly proud of, they may resist undoing that work more than would be called for simply due to the time involved in undoing it.

Once people experience these emotional effects from a cancelled Sprint, they will want to be cautious to avoid them re-occuring. That sense of caution will lead people to make arguments to the effect of “let’s make sure when we start our next Sprint that we have everything right” or simply, “I don’t want to go through that again… we better get it right this time around.” In order for the ScrumMaster to avoid falling for these arguments, it is important for the ScrumMaster not to be a hands-on contributor to the work. In other words, to be emotionally detached from the work. Those arguments can be persuasive unless the ScrumMaster can remind the team about empiricism.  The ScrumMaster must always support the Product Owner if the product owner believes that a cancelled Sprint will lead to the best business outcomes.

Scrum is an empirical process that allows for “failure”. Of course, it probably helps to not call it that. Instead, a Scrum Team and the organization around it need to think of every Sprint as an experiment. There’s a good analogy here with the various stages of drug trials. When a company wants to research a new drug, the drug will go through various stages of experiments. The early stages of research are based on chemical reactions in the proverbial test tubes – laboratory experiments. Subsequent stages of research are often based on animal experiments. After that come human trials. At any stage if the drug in question is showing adverse effects outweighing the therapeutic effects, then the current stage is cancelled. Of course, the research done to that point is not a waste, but nor does it immediately result in a useful drug with net therapeutic effects. In Scrum, each Sprint is like a stage in the drug trials. If the work of the Sprint will not result in a net benefit, it only makes sense to cancel the work as soon as that information becomes obvious.

Waiting for Perfection

The pitfall, then, is that after a cancelled Sprint a team will feel pressure to wait until conditions are perfect before continuing on the next Sprint. Scrum does allow for the team to do a bit of a review of the reasons that the Sprint was cancelled, perhaps even to do a retrospective, and then start another Sprint planning meeting. The Sprint Planning meeting might be a bit longer than usual. The ScrumMaster does need to be sensitive to the needs of the team.

Cancelled Sprints and Synchronized Teams

One other factor may be a consideration: if the team is working with other teams on a larger-scale effort, there may be pressure to have all the teams with synchronized Sprints. For example, the Scaled Agile Framework emphasizes cadence and synchronization among multiple Scrum teams. In this case, a cancelled Sprint may mean that a team sits idle for a short time while they wait for the next synchronization point, as illustrated:

Cancelled Sprint in SAFe

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
facebooktwittergoogle_plusredditpinterestlinkedinmail

The post Pitfall of Scrum: Cancelled Sprint – Failure to Restart appeared first on Agile Advice.

Categories: Blogs

Great Review of Predicting the Unpredictable

Johanna Rothman - Wed, 07/29/2015 - 14:31

Ryan Ripley “highly recommends” Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. See his post: Pragmatic Agile Estimation: Predicting the Unpredictable.

He says this:

This is a practical book about the work of creating software and providing estimates when needed. Her estimation troubleshooting guide highlights many of the hidden issues with estimating such as: multitasking, student syndrome, using the wrong units to estimate, and trying to estimates things that are too big. — Ryan Ripley

Thank you, Ryan!

PredictingUnpredictable-small See Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule for more information.

Categories: Blogs

Neo4j: MERGE’ing on super nodes

Mark Needham - Tue, 07/28/2015 - 23:04

In my continued playing with the Chicago crime data set I wanted to connect the crimes committed to their position in the FBI crime type hierarchy.

These are the sub graphs that I want to connect:

2015 07 26 22 19 04

We have a ‘fbiCode’ on each ‘Crime’ node which indicates which ‘Crime Sub Category’ the crime belongs to.

I started with the following query to connect the nodes together:

MATCH (crime:Crime)
WITH crime SKIP {skip} LIMIT 10000
 
MATCH (subCat:SubCategory {code: crime.fbiCode})
MERGE (crime)-[:CATEGORY]->(subCat)
RETURN COUNT(*) AS crimesProcessed

I had this running inside a Python script which incremented ‘skip’ by 10,000 on each iteration as long as ‘crimesProcessed’ came back with a value > 0.

To start with the ‘CATEGORY’ relationships were being created very quickly but it slowed down quite noticeably about 1 million nodes in.

I profiled the queries but the query plans didn’t show anything obviously wrong. My suspicion was that I had a super node problem where the cypher run time was iterating through all of the sub category’s relationships to check whether one of them pointed to the crime on the other side of the ‘MERGE’ statement.

I cancelled the import job and wrote a query to check how many relationships each sub category had. It varied from 1,000 to 93,000 somewhat confirming my suspicion.

Michael suggested tweaking the query to use the shortestpath function to check for the existence of the relationship and then use the ‘CREATE’ clause to create it if it didn’t exist.

The neat thing about the shortestpath function is that it will start from the side with the lowest cardinality and as soon as it finds a relationship it will stop searching. Let’s have a look at that version of the query:

MATCH (crime:Crime)
WITH crime SKIP {skip} LIMIT 10000
MATCH (subCat:SubCategory {code: crime.fbiCode})
WITH crime, subCat, shortestPath((crime)-[:CATEGORY]->(subCat)) AS path
FOREACH(ignoreMe IN CASE WHEN path is NULL THEN [1] ELSE [] END |
  CREATE (crime)-[:CATEGORY]->(subCat))
RETURN COUNT(*)

This worked much better – 10,000 nodes processed in ~ 2.5 seconds – and the time remained constant as more relationships were added. This allowed me to create all the category nodes but we can actually do even better if we use CREATE UNIQUE instead of MERGE

MATCH (crime:Crime)
WITH crime SKIP {skip} LIMIT 10000
 
MATCH (subCat:SubCategory {code: crime.fbiCode})
CREATE UNIQUE (crime)-[:CATEGORY]->(subCat)
RETURN COUNT(*) AS crimesProcessed

Using this query 10,000 nodes took ~ 250ms -900ms second to process which means we can process all the nodes in 5-6 minutes – good times!

I’m not super familiar with the ‘CREATE UNIQUE’ code so I’m not sure that it’s always a good substitute for ‘MERGE’ but on this occasion it does the job.

The lesson for me here is that if a query is taking longer than you think it should try and use other constructs / a combination of other constructs and see whether things improve – they just might!

Categories: Blogs

Python: Difference between two datetimes in milliseconds

Mark Needham - Tue, 07/28/2015 - 22:05

I’ve been doing a bit of adhoc measurement of some cypher queries executed via py2neo and wanted to work out how many milliseconds each query was taking end to end.

I thought there’d be an obvious way of doing this but if there is it’s evaded me so far and I ended up calculating the different between two datetime objects which gave me the following timedelta object:

>>> import datetime
>>> start = datetime.datetime.now()
>>> end = datetime.datetime.now()
 
>>> end - start
datetime.timedelta(0, 3, 519319)

The 3 parts of this object are ‘days’, ‘seconds’ and ‘microseconds’ which I found quite strange!

These are the methods/attributes we have available to us:

>>> dir(end - start)
['__abs__', '__add__', '__class__', '__delattr__', '__div__', '__doc__', '__eq__', '__floordiv__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__mul__', '__ne__', '__neg__', '__new__', '__nonzero__', '__pos__', '__radd__', '__rdiv__', '__reduce__', '__reduce_ex__', '__repr__', '__rfloordiv__', '__rmul__', '__rsub__', '__setattr__', '__sizeof__', '__str__', '__sub__', '__subclasshook__', 'days', 'max', 'microseconds', 'min', 'resolution', 'seconds', 'total_seconds']

There’s no ‘milliseconds’ on there so we’ll have to calculate it from what we do have:

>>> diff = end - start
>>> elapsed_ms = (diff.days * 86400000) + (diff.seconds * 1000) + (diff.microseconds / 1000)
 
>>> elapsed_ms
3519

Or we could do the following slightly simpler calculation:

>>> diff.total_seconds() * 1000
3519.319

And now back to the query profiling!

Categories: Blogs

Women on the Rise

Bobtuse Bobservations - Bob MacNeal - Tue, 07/28/2015 - 16:49
illustration by Sascia DäumichenThe demand for women programmers is on the rise because the software industry realized it has a long-standing brogrammer problem and remains economically stunted from...

Bobtuse can be wildly informative
Categories: Blogs

Agile2015 Talk: Product Owner Team – Why? 

Leading Agile - Mike Cottmeyer - Tue, 07/28/2015 - 15:50

Agile2015 is just a week away. I will be presenting my talk on Product Owner Teams: Leading Agile Program Management and want to share some thoughts ahead of time on the problem we are solving with the PO Team.

I summarize the Goals in a couple of bullet points:

  • Provide Agile Teams with the support, guidance and coaching they need to get the job done
  • Improve and accelerate your product delivery by improving your Agile Transformation

I focus the talk on four key Objectives:

  • Provide clarity through a well defined feature backlog
  • Hold Agile Teams accountable for making and meeting commitments
  • Demonstrate measurable progress by facilitating the demonstration of integrated features
  • Provide timely information to Portfolio Management for investment decisions

Here’s more detail from the abstract for my talk:

“Building a clear and effective product backlog to deliver on strategic initiatives in an enterprise attempting agile can be difficult. Now add the competing needs of other work with various stakeholders across the organization. And that’s not the hardest part. The real challenge is prioritizing and coordinating considering risks, technical viability and planning dependencies.

The Product Owner Team wrestles with these organizational challenges to provide Agile Teams with the support they need to get the job done. This team ensures the work is strategically aligned and prioritized with Portfolio Management. Only then can the team establish, maintain and coordinate a clear feature backlog for Agile Teams in a complex environment.

The Product Owner Team will improve and accelerate an organization’s agile transformation. This talk presents a proven framework for leading Agile Program Management including the roles, artifacts and activities for an effective Product Owner Team. Additionally, this talk introduces an Agile Program Management starter kit so participants can get started quickly in their own organization.”

The work of the PO Team is challenging. It requires motivated individuals with a clear plan. I hope to help by providing a starting place for the plan.

Are you attending Agile2015? If so, drop me a note and let’s chat.

Update: below are my slides from the talk – enjoy.

Product Owner Team: Leading Agile Program Management from Agile2015 by Dean Stevens from LeadingAgile

The post Agile2015 Talk: Product Owner Team – Why?  appeared first on LeadingAgile.

Categories: Blogs

Knowledge Sharing


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