Retrospective 65 – NOT Scrum and Insane Agile Teams


Agile New Year – 2011 – A Year In Pictures

There are tons of things to be thankful for this year. It’s been a crazy one.

I spend a lot of time in photoshop. Mostly just to have fun and create something funny for the blog post that I’m writing.

This year I’ve decided to highlight some of my favorite posts, based on the photoshop picture. These, unfortunately, are not some of the most popular posts of 2011, but that don’t matter. 🙂

Enjoy, and I look forward to growing with the Agile community in 2012!

Favorite Blog Posts in 2011 Based on Pictures


Continue reading “Agile New Year – 2011 – A Year In Pictures”

[Giveaway Winner] – How to Create a Successful Blog Business

Winner alert:

How to Build a Successful Blog Business

WINNER: Beatriz – Shoot us an email at [info AT agilescout DOT com] with address and we’ll ship it out!

See Our Past Giveaways:

Help us give away more awesome free stuff to our community and readers! [Become a Sponsor]

Teams Over Processes – Don’t Be Insane

[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at]

Do we really need to do that?

One of the embedded issues which often exists in most cultures is the accumulation of processes. Processes make people comfortable and empowered. People are generally creatures of habit and enjoy routine. If people feel good about such things its tempting and common to see more processes emerging to strengthen or improving the existing processes. Now don’t get me wrong, certain processes and frameworks are essential and have high value to business. However sometimes where they exist, they are the main focus and not what the process was setup in the first place to achieve.

When you get a group of people together and put them on the same project they are not a team they are simply a group of individuals. By applying processes, frameworks or tools to this group it’s likely they will simply be a group of individuals using processes, frameworks and tools. Not only will this not help build a team, but could slow down the group of individuals.You don’t build teams by simply applying a framework or process. Certain processes are inherited from previous projects so they must be applied again. In some cases they didn’t even work well previously, but were in place and therefore must be re-used. There is no such thing as silver bullets which when applied guarantee success.

As the famous quote says :

Insanity: doing the same thing over and over again and expecting different results. – Albert Einstein

agile team product managementA colleague of mine recently made a profound simple statement, which was “question the value of everything, if you don’t know why or can’t remember why you are doing something, just stop doing it.”

As simple as this sounds, it’s very true. How many of us are routinely writing and/or requesting documentation, forms or following certain processes because we are used to it not because it’s really needed. If you question some of these and ask yourself why you are doing something or why do you need this information and how is it going to be used, you may find that you don’t really need to continue with it. When you stop doing such an activity from then on, you will have free time to do something of value. Not only in such cases can you improve value, but you might just stop doing something which is devaluing the situation.

In Kanban this is often seen when you are visualising workflow. By visualising the workflow you can identify routes of inefficiency and routes to improvement. The same can be discovered when undertaking Lean analysis. This regularly proves to provide fantastic results over time. However sometimes outside the direct workflow of production it’s worth questioning other not so tangible artefacts. In doing so you may eliminate waste and identify micro-management which can and needs to be challenged. A process is not beneficial unless it has a clear value which should be easily identifiable. Value isn’t something which is nice to have, but something which clearly delivers or benefits a person, group, company or product.

So next time you are about to spend 30 or more minutes writing a report or asking someone else to provide you with a graph, ask yourself “Do we really need to do that?”

Agile in Lean Manufacturing and Value Stream Mapping – I’m Here

Living it Up In the Back of A Gigantic Plant

Welcome to my view. Seriously. I could not be more excited to work for this client. I’m getting to help lead a small development team better understand and deliver a new automation system for a manufacturing/shipping plant.

What excites me the most is that, as an engineer, this really gets my blood moving. I’m literally uber excited to be part of a manufacturing automation system at work. Rock on. I’m also excited about blogging about this experience. Not many Agile Coaches get to work outside of strict technology and software product development.

One of the first things I did was spend the day understanding our value stream. After interviews, process diagrams, and conversations with the team, I built out this nice old omnigraffle of a high level view of the value chain, from receiving to moving through the system. You’ll notice that we have 2 releases of our new automation system (small font).

We need to eliminate waste AND build a system that accounts for increases in cycle time. YES! Let the challenge begin.

“Walk within yellow lines…”

Now, if I can only find my yellow hardhat.

Here is a quick and dirty video on value stream mapping and the value. 5 minutes. You’re not working anyways. It’s after Christmas. 🙂

NOT Doing Scrum – Back to the Basics

[Guest Post: Don Gray is an Agile Coach whom I have had the pleasure of working with on one of my biggest clients. There is too much to say about him. He kicks ass. You can find him blogging on his website and follow him on twitter @donaldegray] – He also purposely tries to confuse me and challenge me at any given moment.

I recently talked with a company who wanted to use Scrum for their production support team. The team had 670 defects ordered in business priority and needed to work from the top down. Corrected defects would be deployed to production once a month, except quarterly when then deployment would synchronize with new development’s deployment. No planning meetings needed and no demo prior to deployment.

About a week ago the following question was asked on the scrumdevelopment listserve:

“Sometimes, I feel ScrumMaster role is redundant. Is it possible to have Scrum without ScrumMaster?”

Once from the top with feeling

I did not define Scrum. Those who did (Ken Schwaber and Jeff Sutherlund) created a simple process framework and minimal interacting roles.

The process has these ceremonies, or meetings if you prefer:

  • Sprint planning – happens at the beginning a sprint. Sprint means a time period (usually between 2 – 4 weeks and shorter is better in my experience) where the team produces the value they agreed they would. Sprint planning often divides into two meetings: first the team estimates the amount of work they can accomplish, then they task the work and have a sanity check.
  • Daily standup – occurs every day at the same time. The team members share their progress since the last standup and report any blocking issues.
  • Sprint demo – where the team demonstrates to the product owner the value they completed in the sprint. The product owner has final say on accepting the work products, or not.
  • A retrospective where the team inspects the previous sprint and selects an improvement goal for the next sprint.

Interacting roles:

If it looks like a duck …

If you’re not following this process, and don’t have these roles in place, please don’t say “We’re doing Scrum.” You’re not. You may be following the agile principles,, and that’s great. But you’re not doing Scrum.

Retrospective 64 – The Process of Change 4 Part Series