Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Thursday, 28 February 2008 09:26
There is great power in a simple message.
There is value in being able to articulate one way of doing something. When we are just learning, there has to be one way of doing things that will work for many of the situations we are most likely to encounter. That one way needs to be simple enough that the beginner can understand what to do, how to do it, and be assured some degree of success.
If we don’t continue to develop our skills, to go past the simple messages, we will never become effective in more complex problem domains. Our world is full of folks that have never progressed past the simple messages we learned when we were beginners. We must recognize the limitations of the early messages and develop strategies for dealing with a more complex world.
At Peace with Paper
Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Tuesday, 26 February 2008 01:07
I am an admitted Blackberry addict and I love new gadgets. That said, there is just something organic, something spiritual about scribbling on a piece of paper. I just can’t seem to shake my attraction to paper planning. I love jotting down ideas and circling key concepts. Being able to draw a line between two related concepts is powerful. Using different colors to show transitions and to communicate emphasis richly expresses what words do not. There is a place in my soul that won’t be satisfied with a little electronic checkmark next to a finished task. I need to write.
But as much as I love my planner, it does have its limitations. If I want to share my ideas with anybody, I have to either photocopy them or rewrite them electronically later on. No one else is able to see my calendar so coordinating schedules becomes a pretty labor intensive task. I am never totally sure if my wife has me booked someplace and I just forgot to write it down. I have yet to figure out a way to make it receive email and it won’t automatically remind me of anything. Did I mention that I am totally screwed if I leave it on the roof of my car?
I’ve been fighting this internal battle for the better part of 20 years. I would go through periods of time where I did nothing but paper planning but inevitably the limitations we just discussed would pull me back to using something electronic. When I would decide to go paperless that part of my soul in search of free form expression would pull me back to handwritten notes. After all this time, I’ve come to the realization that neither approach is going to give me everything I need in a planning tool, so for now, I am going to use both.
I think there is a lesson here that we can apply in our agile projects. It doesn’t have to be one or the other when it comes to planning. If we are all in the same room collaborating, exploring new ideas, and everyone is able to see and touch the same information; paper and whiteboards are the way to go. When the job requires us to manage large amounts of data, to coordinate over distance, or an ability to look at data from many different angles; software can do that much more effectively than paper.
It is really just a matter of blending the two approaches in a way that allows us to be most effective as a team and deliver the most value to our customers.
Here is a link back to my post on Agile Chronicles:
Advice or Approbation?
Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Monday, 25 February 2008 02:46
“We ask for advice, but we mean approbation” – C.C. Colton, English Cleric (1780 – 1832)
I came across this quote over the weekend and it caught my attention. I would love to say it caught my attention because of it’s profound meaning and depth of insight. In reality, it caught my attention because I did not know the meaning of the word approbation.
Well come to find out, the word approbation means approval. So said another way, the author is telling us that when we ask for advice, we are not really seeking advice, we are really just looking to have our own perspective validated. That proved an interesting and insightful observation after all… but is it true?
Colton’s observation led me to think back to a book I read in college called The Structure of Scientific Revolutions by Thomas Kuhn. Kuhn was writing back in the 60′s and popularized the terms paradigm and paradigm shift that are now so prevalent in today’s business literature.
Kuhn postulated that paradigm shifts happen in three phases: pre-paradigm, normal science, and revolutionary science. A shift to revolutionary scientific thought usually takes place after a period of crisis. Prior to such a crisis, people look for ways to fit the observed data into the existing models. When anomalies in the data force us to reconsider the foundations on which our scientific worldview is formed, we have the beginnings of a paradigm shift.
It seems that most folks are not out looking for new ways of doing things. People are generally just looking for evidence that validates their current point of view. They are so comfortable with the old ways they will go to great lengths to ignore anything that challenges their current perspective. If people blind themselves to the data, where does that leave us as leaders of change?
Kuhn offers a not-so-encouraging quote for us to ponder:
“A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it.” – Max Planck, German Physicist (1858 – 1947)
What is it going to take for us to revolutionize the software industry? What can we do to create a sense of crisis? How can we demonstrate that old solutions won’t solve our current dilemma? How do we effect the wide scale change necessary to revitalize our industry?
One company, one team, one leader at a time?
For more on Kuhn and The Structure of Scientific Revolutions, check out the following Wikipedia article:
And here is a link back to my orginal post on Agile Chronicles:
Planning for Value
Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Thursday, 21 February 2008 11:01
“Reduce your plans to writing. The moment you complete this, you will have definitely given concrete form to the intangible desire” – Napoleon Hill
“Plans are of little importance, but planning is essential” – Winston Churchill
“No battle plan survives contact with the enemy” – Colin Powell
One of the most significant contributions of the Agile community has been the realization that creating software is an uncertain business. Unfortunately, this realization has led some of us to the conclusion that the act of creating software cannot be planned. There is a big part of me that can empathize with this point of view. What’s the point of creating a plan if we know the business objectives are going to change, requirements are going to change, and even technologies are going to change? I have worked in many traditional projects where change management was the single biggest part of my job. Why not just get going and see where we end up?
The challenge is that business planning doesn’t work that way. Product owners are asked to create their business cases months in advance of the upcoming fiscal year. Once funding is approved those guys are on the hook for the revenue. This is a big part of our reluctance to let go of the big up front planning processes. As businesses, we want some sort of assurance that we can deliver on our revenue targets. To these companies, funding a project with only the promise we’ll get the most important features first is not very reassuring. We must KNOW that those features are going to deliver the EXPECTED value. Our jobs depend on it.
When the context we operate in is uncertain, we have to plan for that uncertainty. To do this, let’s look at the following three planning alternatives:
Make sure the project will yield an acceptable return with less than 100% of the desired features.
Sure… I want a crystal ball too. Problem is we don’t have one. If we have a firm date, a firm cost, and a fixed set of features; odds are we are going to fail. If time and cost are king, we have to be flexible on features. We need to know up front that we can go to market with less and still produce acceptable value to the company.
Commit to high level features so team has room to negotiate through the life of the project.
In most corporations, there are at least a few other teams that must know ahead of time what you are going to deliver and when. Marketing comes first to mind, so does sales. For those guys to be successful, they need to know what is going to be delivered much earlier than most of us are willing to commit. Committing to high-level features gives us enough specificity to communicate about the product while allowing the team to fine tune the implementation of those features as the product progresses.
Manage the project’s value stream rather than changes to features or tasks.
We know that project requirements are going to change along the way. They should. As we build the product we are going to learn more about what we need and how best to build it. Those changes still need to be managed. The company decided to invest so many dollars to yield a particular return. Do we know how any given change will impact the value of the product? Let’s start looking at how our changes impact the metrics we really care about… value.
Let’s not be afraid to plan in the name of agility. Let’s just be smart about what we are planning and leave ourselves room within the plan to be successful. At the end of the day, it is the value that we deliver to the organization that matters, not how well we followed the plan.
Here is a link back to my post on Agile Chronicles:
Peace, Love, and Agility?
Last Updated on Friday, 16 November 2012 12:53 Written by Mike Cottmeyer Saturday, 16 February 2008 01:14
I am fascinated right now by the question of what comes first… agile thinking or agile doing? Does the agile mindset have to precede implementing agile mechanics? Could we lead an agile transition by implementing the structure of agile and coach people into thinking agile while we do it?
Last night I happened to be listening to an audio version of CS Lewis’ “Mere Christianity”. I was in a section of the book where Lewis was talking about the idea of Christian love. He was making the point that God expects us to ACT with love towards others even if we do not FEEL love towards others. The act of treating people with love would engender the feeling.
As you might imagine, that got my attention. Here I am driving home contemplating the relationship between religion and agile leadership.
Don’t feel bad, my wife thinks I am strange too.
Peace, love, and agility? What’s this guy talking about? I guess I better hurry up and make my point. Let me do that by sharing a couple of examples…
As a married person, I may not always feel love toward my wife. There might be times when I don’t even like her, but… I am always expected to treat her with love. If I consciously act in a loving way, it will create space for the feeling to be sustained.
I happen to be a Catholic. Over the past few years I have worked quite a bit with the teens in my Church. Teens tend to have issue with all the “rules” in Catholicism. They just don’t get why we have all the rules. If the message of the Bible is love, isn’t that all that matters?
My typical answer goes something like this… yes, the message is love. That is all that matters. The challenge is that as human beings, we don’t always understand what love really means. I often use the example of two teens that use “love” as a justification to have premarital sex. The rules of the Church around sex help us to understand what a right understanding of love really is.
Are the rules around sex the main point of their existence? No. Do they help us along the way to understanding what it means to love and to love consistently with how God loves? I think yes. The rules, the mechanics if you will, bring us closer to the truth. They are a means to an end, not the end itself.
So our question remains… can the rules of agile help us develop agility where it does not exist? Can we be asked to behave in an agile way regardless of how agile we might feel at any given moment? Can structure create better agilists? If acting with love can engender loving feelings, can acting with agility engender agile thinking?
I think so. I would be interested to know what you think.Learn More