www.thought-bubble.co.uk

This post is from www.agile-doctor.com by Larry Apke.

So, the other day I was listening to NPR in the car (like most people when they listen to talk radio). And the talk was about peace in the Middle East. One of the experts mentioned that, in his opinion, unless both sides owned the process, it was never going to come to fruition. This reminded me of Mark Fritz, international speaker on leadership in today’s organizations, and a compelling blog post he wrote about ownership. I thought this was interesting because there was an interwoven thought he drew upon throughout the post that I believe is applicable to Agile and software development:

“You never wash a rental car.”

I have used a similar phrase many times before when describing the project-centric mentality that pervades most large software development shops. I tell people that, in order to have good quality code, in order to do the right things by the code (BDD/TDD, continuous integration, etc), you must own the code. Therefore, we must move from project to product management, from renting our code to owning the code. So now you know why my brain went from the Middle East to Mark Fritz to rental cars, and now here we are!

Also, I distinctly remember a recent talk when I proposed that in order for better quality products we must eliminate the PMO and replace it with a PPMO (Product and Project Management Office). Interestingly enough, I remember this talk was given to a roomful of project managers who conveniently heard the first part of the phrase and not the second part.

Click here to see the full post.

This post is from martinfowler.com by Martin Fowler.

One of the challenges of an automated build and test environment is you want your build to be fast, so that you can get fast feedback, but comprehensive tests take a long time to run. A deployment pipeline is a way to deal with this by breaking up your build into stages. Each stage provides increasing confidence, usually at the cost of extra time. Early stages can find most problems yielding faster feedback, while later stages provide slower and more through probing. Deployment pipelines are a central part of ContinuousDelivery.

Usually the first stage of a deployment pipeline will do any compilation and provide binaries for later stages. Later stages may include manual checks, such as any tests that can’t be automated. Stages can be automatic, or require human authorization to proceed, they may be parallelized over many machines to speed up the build. Deploying into production is usually the final stage in a pipeline.

Click here to see the full post.

This post is from scrumalliance.org by Scott Ocamb.

As we all know, the Angile Manifesto was authored at a ski lodge in Utah in 2001. These important guidelines and principles drive much of what we do. These simple, elegant words are very difficult to use in the real world and sometimes, in my opinion, are misunderstood.

I thought I would write some words about Agile from the direct perspective of the Agile Manifesto. If we remember the overall idea these people had in mind and allow for flexibility, we can increase our chances of success.

I will start with the four main points of the Manifesto. They are:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Directly following these points is the following sentence: “That is, while there is value in the items on the right, we value the items on the left more.”

The phrase “while there is value in the items on the right” is often left out of our thoughts as we deliver Agile solutions. I will explore each of the four points and provide my thoughts as to what they mean to me.

Click here to see the full post.

This post is from mountaingoatsoftware.com by Mike Cohn.

In my previous post, I wrote about alternatives to numbering sprints. In this post I want to deal with a very special number that some teams use in numbering their sprints–zero.

The concept of a “sprint zero” has become popular with some teams and so it is important to consider whether or not this is a good idea.

First, let’s agree on the basic premise of “sprint zero.” Sprint zero is usually claimed as necessary because there are things that need to be done before a Scrum project can start. For example, a team needs to be assembled. That may involve hiring or moving people onto the project. Sometimes there is hardware to acquire or at least set up. Many projects argue for the need to write an initial product backlog (even if just at a high level) during a sprint zero.

One of the biggest problems with having a sprint zero is that it establishes a precedent that there are certain sprints or sprint types that have unique rules. Teams doing a sprint zero, for example, will dispense with the idea of having something potentially shippable at the end of that sprint. How can they have something potentially shippable after all if the goal of the sprint is to assemble the team that will develop the product?

Click here to see the full post.

This post is from  agilitrix.com by Michael Sahota.

The following diagram is a powerful mental frame to help understand change efforts within organizations. It makes the discernment between tactical, strategic and cultural levels. One way to use the diagram is to position each change item or activity on the line to show what aspect it is focussed on.

More importantly, I use the diagram to engage with clients to explore what they want to achieve, why they want to achieve it, and how invested they are in the outcome.

Some typical benefits are listed above the line. Most importantly, break-through results only come from culture –  not tactical or strategic approaches.

• Tactics – “How do we work?” is about day to day practices and process elements. These are things that a team or organization can adopt.
• Strategy – “What do we want to achieve” is about aligning the company around key goals and initiatives.
• Culture – “Who do we want to be?” is about clarifying the organizations reason for existing as well as it’s values and vision.

Click here to see the full post.

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

Dealing with multiple teams in a product development organization is always a challenge!
One of the most impressive examples I’ve seen so far is Spotify. I’ve had the pleasure of working with Spotify on and off ever since the company was founded, and it’s one of the few companies I’ve seen with a truly agile culture. Spotify has grown a lot lately and now has hundreds of developers divided into 30 agile teams spread over 4 cities in 3 timezones. So how is this managed?
Check out the article: Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. I wrote it together with Anders Ivarsson, one of the agile coaches that I’m working with (Spotify has a truly awesome group of coaches!).

Click here to see the full post.

This post is from ambitiousmanager.com by Liz Rice 

Every so often, I hear someone suggest that you can’t really build a roadmap when you’re working in Agile, because you’re only planning one iteration at a time.

That, my friends, is nonsense. In this article I’ll describe a lightweight planning process for building a roadmap for strategic development items, that you can share with internal stakeholders and even external customers, without locking yourself into a detailed plan that you’ll come to regret later.

Click here to see the full post.

This post is from blog.assembla.com by Andy Singleton.

Last week Assembla posted a bunch of “agile” words on our home page.  I resisted doing this for years, because the word “agile” doesn’t necessarily have a good feel to it.  It’s a refuge for a lot of organizations and people that aren’t very agile.  The original idea is great.  It stands for releasing software frequently, with short lags for the implementation of valuable new features and ideas. The productivity of software development increases every year, and in theory you could use the word “agile” to describe many of the things that are light and bright, great and good, fast and fun about our new world.  But, if we want to use the word “agile” for this, we have to burn off the stink of stagnation that surrounds the old “agile.” So, here are seven things I hate about “agile.”

Old people: Agile has the smell of death on it.   If you go to an “agile” event you will see few people under the age of 40 and many over 50. These attendees are on average much older than the average age of programmers, and often older than the people running today’s hot software companies.  Why aren’t more younger people grasping at agile straws?

Click here to see the full post.