This is an odd belief as there is a strong tendency for people within the Scrum community (where the Product Owner and Scrum Master roles come from) to talk about Servant Leadership which seems to be the opposite of outranking team members.
As an aside, I've never really been a fan of "servant leadership". Instead, I like the idea of Host Leadership.
Extreme Programming used to distinguish Customer Rights vs Programmer Rights (and then eventually Managers and Testers wanted in on that action) in order to clarify accountabilities and essentially balance power.
I wonder whether being explicit about rights like in earlier Extreme Programming would address the problem of people misinterpreting the roles of Product Owners and Scrum Masters.
But there's a reason why rights aren't really discussed that much anymore.
The point is not a fight for power and rights but rather how to work together as humans for a common goal, aka Whole Team.
As Agile hit the mainstream with the dominance of Scrum and the rise of Kanban and SAFe, the complaints seem to have shifted to be about how Agile was just for managers and seen as a management fad. Ironically, there are even complaints now that Agile doesn't focus enough on programming.
A fundamental idea of Agile was and is to bring people together. The somewhat clumsily worded version in the Agile principles is:
"Business people and developers must work together daily throughout the project."DevOps is a natural evolution if we ignore the clumsy wording and realise the underlying concept of bringing people together.
Agile can't be just for programmers OR just for managers OR just for any particular group or perspective BECAUSE the insight is that you can't deal with problems effectively by taking only one perspective.
Because of this, most of the "new" arguments you hear are not actually that new but typically reflect the same misunderstanding (whether accidental or deliberate) of what XP / Agile is about. This is not to say that all new arguments have been made before nor that every argument whether old or new is completely devoid of merit. However, it's rather tiresome and perhaps not too useful to respond to the exact same objections that have already been answered.
To that end, let's try to capture some of the patterns of misunderstanding and explain why they are misled and wrong.
Patterns of Agile misunderstanding
- Agile is just some new fad.
- Agile was invented by consultants to make money.
- Agile is just X (where X can be any one trait).
- Agile is just for managers OR Agile is just for developers.
- Waterfall is just a strawman (implying that Agile is not solving any real problem).
- Product Owners and Scrum Master outrank the team members.
- Agile leads to technical debt.
- Agile is not sustainable.
- Agile comes from extroverts while most people in software are introverts
- You don't need Agile, you just need to let engineers do what they think is right.
- You don't need Agile, just get rid of the deadweight developers
The phrase "technical debt" was coined by Ward Cunningham in 1992. Ward is known for a few significant things: wikis, CRC cards, and influencing Extreme Programming (XP).
XP was by far the dominant "lightweight methodology" when the Agile Manifesto was created.
So it seems rather odd to suggest that Agile leads to technical debt. All the talk about technical debt came from Agile people.
Here's Ward talking about the history of "technical debt":
Here's a couple articles by Martin Fowler on technical debt:
Ward and Martin are signatories of the Agile Manifesto, which makes sense because they participated in creating it.
It's really ironic that people today might believe that Agile leads to technical debt.
But I can understand the belief.
XP is no longer what people typically think of when they think "Agile". There has been a shift to Scrum and Kanban and management issues in general. I can understand that people exposed to Flaccid Scrum might believe that Agile equates to poor technical practice.
The more controversial, though unoriginal, claim would be that XP practices lead to technical debt. In other words, claiming that the community that developed and embraced the concept of being mindful of technical debt advocates practices that lead to it.
How does a 120-year-old insurance company get more value out of its agile transformation in 2 years than a high-tech company that’s been practicing agile for 14 years? Well, it has something to do with bad habits that form when organizations don’t scale agile beyond the team level. Or they coordinate work to include the business and program management roles but don’t focus on best practices and continuous improvement to maintain results.
Here are some common traps organizations can fall into around team-level agile:The Easy Road
It’s human behavior to take the path of least resistance. In the context of agile, I’ve seen teams and delivery groups (even those that religiously do retrospectives) take the easy route to tackle a problem rather than take on time-consuming — and sometimes contentious — changes to improve how they work. This ultimately leads to technical debt, and worse, unhealthy agile practices.Developer-only Agile
The whole premise of agile is to connect the business and development to deliver value. Even in companies where strong development teams are killing it with agile, it’s pretty common for those teams to exclude outsiders. When that happens, teams start working in isolation, losing sight of what other teams and the business need, when they need it. Responsiveness, predictability and value delivered quickly become disconnected from market windows and what customers want. Organizations trying to retain valuable programming talent do the same thing — make decisions that keep developers happy instead of thinking about what’s best for their customers and the company.Managing the Matrix
Enterprises experimenting with agile often try it within existing organizational structures. While agile teams can exist that way for a while, more often than not they end up isolated and can’t consistently deliver the value that the company needs to win in the market.Developer Musical Chairs
Sustaining dedicated teams over time is key to agile success. When you start moving developers around to solve various problems that pop up, you create an extra learning curve, lower capacity and, sometimes without intending to, make decisions that can derail the features you’re trying to deliver.Unmanaged Chaos
Companies that start to slack off on disciplined agile practices (like Kanban and Scrum) end up with highly reactive environments. This creates hidden work, high levels of work in process (WiP), lack of focus and even purposeful focus away from the company’s vision. Teams feel helpless and frustrated because they’re constantly playing defense.Where Do You Start?
Sure, these problems can be overwhelming and prompt organizations to start questioning their investments in agile. But you can get back on track just by getting back to the basics.
Get back to basics. Re-establish great team-level practices (proper Scrum and Kanban), limit WiP and use metrics to help teams stay focused. Create value streams that follow the work, maintain dedicated teams and build strong delivery groups.
Adopt agile at scale. You won’t get to the next level of agile just by doing it at the team level — you need to launch a whole program right from the start. Organize for the work and find the courage to make your company structure part of the transformation. Create an agile center of excellence — and give it authority and funding — that guides the practices and evolution of your organization’s agile teams, delivery groups and people.
Include product and program management. Understand how to build a good agile roadmap and collaborate with your customers. Talk to them not only about what you’re currently delivering but about your future plans — and smooth the flow of work to teams so they’re working on the right things at the right time.
Invest in continuous improvement. Establish a culture of continuous improvement and support it with a mix of qualitative and quantitative measurements. Strategize collaboratively with big room planning that includes everyone in the delivery group. Watch how our customer, Seagate, uses big room planning to speed delivery, save costs and become a predictable engine for the business.Achieve 4x Improvement
Achieving the true promise of agile (4x improvement) comes by connecting the whole system (not just teams) and making sure you’re always transforming and fine tuning to guide your agile journey.
Remember those two companies I mentioned? By launching its agile transformation at scale from the get-go, the insurance company (the agile rookie), Physicians Mutual, saw a 50-percent increase in major release frequency and the delivery of hundreds of items during the course of just one year. Read the case study. I was directly involved in helping the high-tech agile veteran (Rally) get back to basics to achieve 2x feature output and deliver 100 percent on our roadmap commitments.
If you want to learn more about how to effectively scale agile in your organization, I’m hosting a “Next Level Agile” webinar on August 19 at 11 a.m. MST in the U.S. and 2 p.m. BST in the UK. Register here for the North America webinar and here for the EMEA webinar.Ryan Polk
Watch this webinar to find out how asking a simple question can improve your delivery speed. About This Webinar To help teams make effective day-to-day decisions that support Lean-Agile principles, we’ve created a simple yardstick at LeanKit called FSGD — Frequent, Small, Good, Decoupled. Easy to remember and apply, “Fizz Good” is a way of […]
This is a continuation of my musings on Strategy Deployment, the X-Matrix and Kanban Thinking (including Strategy Deployment as Organisational Improv and How Do I Know If Agile Is Working). I’ve been thinking more about the overlap between Strategy Deployment and Kanban and come to the conclusion that the intersection of the two is what could be called “Kanban Deployment” .
Let me explain…
To begin with, the name Strategy Deployment describes how a centralised decision is made about strategy, which is deployed such that decentralised decisions can be made on defining and executing plans. The people who are engaged at the coal face are the people who are most likely to know what might (or might not) work. In other words its the strategy that is deployed, not a plan.
Similarly, Kanban Deployment can be used to describe how a centralised decision is made about kanban as an approach to change, which is deployed such that decentralised decisions can be made on defining and executing processes. Again, the people who are engaged at the coal face are again the people who are most likely to know what might (or might not) work. Its kanban that is deployed, not a process.
With this perspective, we can look at how the X-Matrix could be used to describe a Kanban Deployment in terms of Kanban Thinking. (For a brief explanation of the X-Matrix see a post on how we used the approach at Rally).
The Results describe the impact we want the kanban system to have, and the positive outcomes we are looking to achieve with regard to Flow, Value and Potential. Just like with ‘regular’ Strategy Deployment, an economic model as recommended by Don Reinertsen is likely to provide clues as to what good results would be, as will a good understanding of fitness for purpose.
For Strategies we can look to the Kanban Thinking interventions of Study, Share, Stabilise. Studying the system is a strategy for learning more about the current context. Sharing knowledge is a strategy for creating a common understanding of the work and the way the work is done. Stabilising the work is a strategy for introducing policies which will enable and catalyse evolutionary change.
The Indicators are equivalent to the Kanban Thinking intervention Sense. These measures of improvement, while proxies, should give quick and regular feedback about whether the kanban system is likely to lead to the results.
Lastly the Tactics are equivalent to the Kanban Thinking intervention Search. These are the specific practices, techniques and policies used as part of the experiment that are run. The Kanban Method core practices can also provide guidance as to what tactics can be used to design the kanban system.
While I’m not sure I would want to be overly rigid about defining the strategies, I find the X-Matrix a useful model for exploring, visualising and communicating the elements of a kanban system and how they correlate to each other. As with all tools like this (i.e. A3s) its not the template or the document that is important, its the conversations and thinking that happen that have the value.
 I did consider the name “Kanban Kanri” for the alliteration, but apart from preferring to minimise Japanese terminology, it’s probably meaningless nonsense in Japanese!
A few weeks ago, I announced a free SonarQube User Conference in Geneva on the 23rd and 24th of September. More than 100 people have already registered.
We want this 2-day conference to be as valuable as possible for participants, and thus want to have a variety of speakers. That’s why we are opening a call for papers, and invite anyone who wants to talk about SonarQube to submit a presentation. The CFP will close on Friday the 14th of August.
To submit a talk, simply send an email to firstname.lastname@example.org with the title, abstract and duration of the presentation. We are eagerly awaiting your proposal!
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!
The post Practice Courage: Move Beyond Planning Into Action appeared first on Agile Advice.
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!
The lovely folks at Thoughtworks interviewed me for a blog post, Embracing the Zen of Program Management. I hope you like the information there.
If you want to know about agile and lean program management, see Agile and Lean Program Management: Scaling Collaboration Across the Organization. In beta now.
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.
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) + 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) + 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) + COLLECT(b) AS noDuplicates ==> +---------------------+ ==> | noDuplicates | ==> +---------------------+ ==> | [1,2,3,4,5,6,7,8,1] | ==> +---------------------+ ==> 1 row
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.
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
- Certified Scrum Master, Lehi Utah, Aug. 17-18
- Certified Scrum Product Owner, Lehi Utah, Aug. 19-20 (with Hart Shafer)
- Certified Scrum Master, Chandler AZ, Oct. 5-6
- Certified Scrum Product Owner, Chandler AZ, Oct. 7-8
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".
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:
- 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.
- Average Time in Process (TiP). This is measured in weeks and again the average is taken over 1 week.
- 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.
- Net Flow. Simply the difference between the number arriving and departing over the previous week.
- 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.
- 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.
- Age of WiP Indicator. This compares the average age of the WiP with half the average Tip. It is another indicator of imbalance.
A spreadsheet containing the means to generate these diagrams from your data will shortly be made available from gitHub. Watch this space!
- [vaca] Vacanti, Daniel S. "Actionable Agile Metrics for Predictability: An Introduction". LeanPub. (2015)
"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:
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.
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.”
“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
Passionate Performanceby 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 McChrystalA 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 extend 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 flexible—and beat back Al Qaeda.