How to manage Epics across multiple channels?

This post is from by Karen Deer.

Most products these days have multiple touch points across various channels that all need to be implemented in tandem.

For instance a registration flow may start with a physical product purchased in retail, continue on a customers mobile web, with an email and/or SMS verification, then end with the download of a native mobile app. Also a version of a digital product might exist on mobile web, desktop web, wearable and native apps simultaneously.
The product owner is left with the unwieldy task of managing multiple work streams, engineering teams and retail execution teams with different workflows, timelines & cycles. Add to that the complexity of stakeholder input, feedback and approvals.
The following are a few strategies to help manage these types of situations.

Click here to see the full post.

Posted in Agile | Comments Off on How to manage Epics across multiple channels?

Failing so you can win

This post is from by Lynn Grant.

It has long been known in engineering circles that much can be learned from failure. Claude Albert Claremont, in his 1937 book on bridge building, “Spanning Space,” wrote:

The history of engineering is really the history of breakages, and of learning from those breakages. I was taught at college “the engineer learns most on the scrapheap.”

In one of my past lives, I was involved in performance car rallying. This involved racing in beefed-up cars over forest logging roads. In the ’70s, there was a driver named John Buffum. His day job was running a car dealership in Vermont, but he was also the top rally driver in the U.S. and had factory support from British Leyland, who supplied him with Triumph TR-7s, like this one:

Click here to see the full post.

Posted in Agile | Comments Off on Failing so you can win

The Science of ‘Paying It Forward’

This post is from by Milena Tsvetkova and Michael Macy.

ONE morning in December of 2012, at the drive-through window of a Tim Hortons coffee shop in Winnipeg, Manitoba, a customer paid for her order and then picked up the tab for the stranger in the car behind her in line. Then that customer paid the bill for the following customer in line — and so on, for the next 226 customers, in a three-hour sequence of spontaneous generosity.

It turns out that such “pay it forward” chains are not unheard-of at Tim Hortons (though they are usually much shorter), and news outlets have reported the emergence of many such chains in a variety of restaurant drive-throughs and tollbooths throughout North America. Last year, a Chick-fil-A in Houston experienced a 67-car chain. A few months later, a Heav’nly Donuts in Amesbury, Mass., had a run of 55 cars.

Why do these things happen? One possibility is that generosity among strangers can be socially contagious. According to this theory, if you receive or observe an act of help, you become more likely to help others, even if your own action won’t be directly reciprocated or rewarded. Rather than repay someone for helping, you “pay it forward” — a phrase popularized by Catherine Ryan Hyde’s 1999 novel of that title (later turned into a movie of the same name).

Click here to see the full post.

Posted in Agile | Comments Off on The Science of ‘Paying It Forward’

Agile Is Dead (Long Live Agility)

See also my post: “Live agile and dead Agile” by Haran Rasalingam.

This post from by Dave Thomas echoes similar concerns to the ones that I have been voicing:

Thirteen years ago, I was among seventeen middle-aged white guys who gathered at Snowbird, Utah. We were there because we shared common beliefs about developing software, and we wondered if there was a way to describe what we believed.

It took less than a day to come up with a short list of values. We published those values, along with a list of practices, as the Manifesto for Angile Software Development:

Individuals and Interactions over Processes and Tools
Working Software over Comprehensive Documentation
Customer Collaboration over Contract Negotiation, and
Responding to Change over Following a Plan

I was proud of what we did, both the process we followed and the result it produced. And I think that the existence of the manifesto has helped developers break free some some of the wasteful and soul-destroying practices of the ’80s and ’90s.

Click here to see the full post.

Posted in Agile | Comments Off on Agile Is Dead (Long Live Agility)

Evidence Based Management

This post is from by Ken Schwaber

I’ve had many, many customer ask me how they are doing, how much better they are doing than a year ago. The entrance of SAFe, the IPO of Rally, and the flood of “just in time” experts and training companies make an ability to answer that question even more important. If organizations invest heavily into “silver bullet” solutions, the credibility of the agile movement will be the one to take the hit.

Many of the efforts to “measure” agility focus on practices, such as:
• Was the retrospective held?
• Was the product backlog “ready” at the Sprint Planning meeting?
• Is QA and testing an integral part of the Scrum Team, or separate?
• Is code coverage better than before?

Click here to see the full post.

Posted in Agile | Comments Off on Evidence Based Management

Employee Commitment: A Recipe for Peak Performance

This post is from by Frank Sonnenberg.


For today’s employee, being part of something special and making a difference in the world is much more important than the rewards sought by yesterday’s “me” generation. Employees of this new breed want to work for an organization they can feel proud of — one that contributes back to society; an organization that has values and viewpoints compatible with their own; an organization that is oriented toward the long haul, working toward the prevention of ills, not just curing the symptoms; an organization that cares about morals and ethics and doing what is in the best interests of its customers; an organization that doesn’t dominate their lives but rather allows them ample time to spend with their families. Employees want this because they recognize that such an organization will also care bout them.

Click here to see the full post.

Posted in Agile | Comments Off on Employee Commitment: A Recipe for Peak Performance

Kanban or Scrum? Know your constraints before you take the plunge

This post is from by Tom Sedge.

Many people think that the answer to their problems is to pick an agile approach and use it to deliver their services. In doing this they frequently put the needs of service development ahead of the wider organisation and risk overlooking well-known constraints and context that will trigger failure. Kanban, Scrum and XP each have several key implications which need to be properly understood before taking the plunge.

Whooah! Stop and hold that decision, just for a moment. Before you make a choice that might trap you.

There are a thousand places where you can learn about how Scrum and Kanban work but few properly explore their wider implications. The reality is that service development doesn’t exist in a vacuum – it is intrinsically linked to strategy, market conditions, sales, delivery cycles and support considerations, and of course customer need, let’s not forget that!

Click here to see the full post.

Posted in Agile, Kanban, Scrum | Comments Off on Kanban or Scrum? Know your constraints before you take the plunge

Making Scrum SAFe

This post is from by Al Shalloway.

Two of the major market forces in last decade with the greatest impact on Organisations has been the emergence of the ‘Digital Enterprise’ and ‘Organisational Agility’.  If used smartly, both can give significant competitive advantage to the Business.

Simply put, a Digital enterprise is an organization that uses technology as a competitive advantage in its internal and external operations. On the other hand Organisational Agility means the enterprise has made the journey from ‘Doing Agile’ to ‘Being Agile’ across the horizontal business functions and vertical organisational structure.

TCS has good experience helping organisations embrace a Digital enterprise strategy using an holistic framework to guide companies through the digital universe and enable them to maximize digital opportunities in a coordinated, integrated approach.  TCS believes a combination of pervasive networking, the explosion of big data, the availability of advanced analytics and social media, and the fact that mobile technology will become the businesses’ new face of engagement means that, in the very near future, “digital” and “business” will be synonymous. Using Big data, cloud computing, social business, and mobility as key transformation tools, TCS effectively creates the Digital ecosystem to drive the ROI across Technology & Business.

Click here to see the full post.

Posted in Agile | Comments Off on Making Scrum SAFe

The safe way to lean software developement

This post is from by Colin O Neill ,Gillian Clark and Gareth Evans.

There are mistakes in the paragraph, please check carefully. I know you cannot copy and paste this page, but I have taken the text from the source code:

Lean Thinking makes a significant impact on organizations that are keen to stay competitive in a rapidly changing world. Because software is ubiquitous in most modern products and services, scalable agile software development techniques based on Lean principles are creating successful outcomes for numerous government and industry organizations around the globe.

The Scaled Agile Framework® (SAFe) is a proven, publicly available framework for applying Lean|Agile principles and practices at enterprise scale. SAFe, created by Dean Leffingwell, synchronizes the alignment, collaboration, and delivery of large numbers of agile teams across an enterprise and employs key Lean principles to underpin its constructs. SAFe is fundamentally based on five Lean practices as represented in the metaphorical House of Lean, located in the upper left corner of the SAFe Big Picture (depicted below). The purpose of this article is to illustrate how Lean principles buttress the constructs of the Scaled Agile Framework in both theory and practice. The following sections provide insight into how each of these Lean principles are intrinsically embodied in SAFe.

Click here to see the full post.

Posted in Agile | Comments Off on The safe way to lean software developement

Live agile and dead Agile

by Haran Rasalingam

Agile is dead! Long live agile!

ALERT: Bold assertion: The problem with the Agile movement is that it has been around too long. The capital “A” of “Agile” has institutionalised it. It has been appropriated and standardised by the very same forces who have successfully turned all other office work into a stultified, brain-deadening graveyard.


There was recently a post on LinkedIn entitled “Agile vs. Waterfall”. The argument was that Agile and Waterfall are not opposites, but they are complimentary. Some things need Waterfall and some things need Agile. Some things need a phased approach, some things don’t, for example. The article discussion moved in the direction of suggesting that perhaps Agile vs. Waterfall was the wrong distinction to draw. Perhaps it would be better to distinguish between planning up front and not planning up front. I did ask one commenter to give an example of this, but the example given was not software related, instead pointing to the erstwhile structural engineering building a bridge analogy. The debate moved on and then the suggestion was made that the distinction should instead be between fixed planning and adaptive planning.

But although I was myself involved in the discussion, I went away dissatisfied with the conclusion. Is that all it’s about? Phased approach vs. non-phased approach. Up-front planning vs. no up-front planning. Fixed vs. adaptive.

If I am honest, when people start talking about Waterfall/Agile hybrids, I find it immensely irritating. Deep down, what I feel that it usually means is that someone is working in an organisation which is extremely dogmatic about their way of working, but they don’t mind talking about things in small chunks (they latch on to the “iterative” part and usually forget about “incremental”, not to mention self-organising, people over process, etc, etc). It means that the organisational structure is so siloed and everyone is very cosy in their little siloes and they probably hate everybody else. It means they are very institutionalised and disempowered and probably don’t care at all whether software actually gets delivered or not, whether it is done efficiently, whether it is profitable or wasteful. This is what I would call a dead environment.

The spirit of agile (I’ll use a small “a” here) is all about a living, breathing software development effort. It is buzzing with the energy of lots of people caring about the work that they are doing. They are passionately focused on the same common goal and they all pull together to deliver software in the best, most efficient, most sustainable and most pragmatic way possible. This is what I would call a live environment.


So one might be tempted to contest my theory as follows:

– Is it necessarily the case that a phased approach, up-front planning or “fixed” plans lead to a dead environment?
I would say no. However, such approaches, in my view, create a large probability of this being the case.
For me, a live environment is all about caring and a dead environment is about not caring. For example, if a phased approach involves different groups of people doing a piece of work and then handing it off to another group of people, then those handing off have no direct stake in the actual end goal, which means they are less likely to care about the actual final delivery.
Similarly, if we attempt to make all plans up front or remain rigidly fixed to a plan, then once again, the software development process is less owned by the people doing the work in the here and now. They are detached, less invested and hence care is likely to be reduced.

OK, let’s turn the question the other way:

– Does a non-phased, adaptive approach automatically lead to a live environment?
Once again, I would say no. However, there is a much greater probability of this being the case. Such approaches do not imply a live environment in and of themselves, but they prepare the ground for a live environment in a much better way.
For example, if we don’t have the illusion of a full and complete plan (for illusions are what they usually are), this brings to light with much greater transparency the need to continuously think about what needs to be done. It results in a thinking, creative, intelligent atmosphere. And if the goal of each piece of work is to deliver working software, then this means that the goal is clear for everyone to see and thus everyone is more likely to be working towards that same goal in a focused way.

However, many are the “Agile” software development efforts which look more like dead environments than live ones. Why is this so? I have often seen the sprint cycle and the working through of the backlog also turn into a monotonous grind. This means that dogma has set in. The spark has gone because too many of the people involved in the project do not care anymore. I often hear about companies who are already “doing Scrum”, but they need someone to come in to “freshen things up”. This means that the team is doing “dead Agile” and they need to be doing “live agile”.
The “dead Agile” state of affairs comes about when a team is probably not as self-organising as it could be. Perhaps the person carrying out the role of Product Owner is not really the owner of the product, which means that they do not really make the decisions and also that they do not really care. Perhaps there is no drive coming from anywhere to get things delivered, perhaps no one close enough cares how much it is all costing. In summary, I would say that it is a question of care. If people care, the environment is live, if not, then it is dead. And I believe that Agile approaches give companies a better chance of setting things up such that people close to the actual work care about delivery.

Which kind of environment do you work in? A dead one or a live one? Because that’s the real point.

Posted in Agile | Comments Off on Live agile and dead Agile