www.thought-bubble.co.uk

This post is from mountaingoatsoftware.com by Mike Cohn.

User stories are great. When you’ve got users, that is. Sometimes, though, the users of a system or product are so far removed that a team struggles to put users into their stories. A sign that this is happening is when teams write stories that begin with “As a developer…” or “as a product owner….”

There are usually better approaches than writing stories like those. And a first step in exploring alternative approaches is realizing that not everything on your product backlog has to be a user story.

Click here to see the full post.

This post was written by me and first published on the trainline engineering blog.

The big selling point of Agile is the fast return on investment it promises. But what excites me most about Agile is its emphasis on people – agility done well injects humanity back into activities which Waterfall has made bureaucratic and devoid of care. In short, care does not scale. Waterfall’s “inhumanity” comes from the command-and-control paradigm. Teams are not empowered to make the best decisions based on their know-how. Instead this is taken out of the hands of the team and decided by others who are not actually going to get their hands dirty.

Agility is equated with empowerment, but how is empowerment achieved? I often find teams expecting empowerment to come packaged and delivered to their desks: “we want to be empowered, but we are waiting to be told so” …

Click here to see the full post.

This post is from rallydev.com by Alex Pukinskis.

Last week I met with a strategy leader for an Australian financial services organization, who was trying to work out how to bring his executive team together on a regular cadence to align around strategy. He’d built a great Kanban board to visualize the large strategic projects the organization was pursuing — sort of an executive-level roadmap — and wanted some ideas for how to bring execs together around it.

In my role I spend a lot of time promoting a quarterly, one-day, Agile business steering meeting that brings leaders together to align on strategic priorities and harmonize their quarterly tactics. I think that such a meeting really is the heartbeat of business agility at scale. But once you’re aligned around your intentions for the quarter, how do you steer within the quarter?

Click here to see the full post.

This post is from tryingtokeepitagile.com by Lynn Grant.

In my last post, Agile Development in the ’80s, I talked about the team I was on in the early ’80s that was, in many ways, a Kanban team. I was discussing this with a colleague the other day, and he pointed out that my team lacked one very important attribute of an agile team: sustainability.

In the intervening 30 years, I may have fallen prey to the The Way We Were effect (“What’s too painful to remember, we simply choose to forget.”) There were several aspects of the team that were not sustainable.

Click here to see the full post.

This post is from blog.crisp.se by Henrik Kniberg.

Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn 

Click here to see the full post.

This post is from agile.dzone.com by Dave Rooney.

If you have spent any time at all working in an Agile software development environment, you’ve heard the mantra to split your Stories as thin as you possibly can while still delivering value. This is indeed great advice, but the term “thin” is relative – our notion of what thin means is anchored by our previous experience!

To help communicate what I mean when I say that Stories should be thinly sliced, I’m going to provide examples from a recent client who was building a relatively standard system for entering orders from their wholesale customers.

Click here to see the full post.

This may seem like a strange question coming from an Agile Coach, but what I want to do is to try to make the reasons less mushy and abstract. Many is the time when discussing (and usually disagreeing on) the need to carry out a certain “Agile” activity that the actual reasons can seem to carry very little weight in the heat of the real world. Continue reading →

This post is from eliassen.com by Dave Nicolette.

I’m one of six technical Agile coaches engaged by a large bank to support an initiative to improve software delivery performance. The IT department is an established agile software development shop that uses the SAFe framework with Scrum at the team level. They are seeking to achieve continuous delivery, improve software quality, establish a developer-friendly working environment, and foster a culture of continual improvement.

Click here to see the full post.