RisingTideHarbor: Matt Barcomb's Blog on Lean Agile Business Software Development

Preaching to the Choir

2011-12-27T23:44:00.000-06:00

Recently, I was giving a class and during a portion of the class I discuss some of the cultural changes usually required for organizational progressive elaboration of work. During the break that followed this particular discussion, one of the class attendees came up to me and said:

"Seems you're preaching to the choir here. We all agree with what you're sayin'…but it wont do any good unless we get the managers in here."

While I certainly understand this reaction, and unfortunately find that it's not that uncommon, I still find it a bit disheartening…and a little frustrating.

This attitude of "I can't change the things that influence me", and "what I can control isn't big enough to really change anything" is entirely the wrong attitude.

Changing the things that you can control, no matter how seemingly insignificant, should never be down-played. One can always take complete control of their own actions, behaviors, and reactions. Combined with a little learning and a bit of creativity this can become very powerful indeed. So, try changing the things you can; the things over which you have direct control. Share what you've tried, what you've learned, what worked well and what didn't. Share up, share down, make it visible, let people ask about it and then share with them too. Eventually this can influence up, down, and across the network of an organization.

Sometimes it only take one person to make a significant change. Other times it spreads slowly before snowballing into a major organization shift. And many times making a "major" or "significant" change isn't even needed. Sometimes it's the little things that count.

So, the moral of the story is that even the choir can use the message, and even the choir is able to go out into the world and try to make it a better place through their own actions…and employees who think their organization could be better are just as much on the hook for trying to improve it as the managers and executives are.

Tribes: A Retrospective Technique

2011-10-07T15:46:00.000-05:00

I tried a new retrospective technique this week that seemed to go fairly well. I called it Tribes after the ice-breaker activity that was facilitated by Tobias Mayer this year at Agile Coach Camp US. (Not sure if I should change the name is using and evolving it as a retro technique, but I'm toying with the idea of "islanders" or "migratory swallows".)

Original Tribes:
To facilitate, you get a bunch of folks standing in an open area with enough space for walking around comfortably. Individuals then say, loudly enough for the entire group to hear, some aspect about themselves or something in which they are interested. Other participants then join the person who has said something with which they identify or have in common, thus creating a "tribe". This process repeats as more individuals think of things to say aloud and tribes continually form and reform around new individuals.

As an ice-breaker activity I really liked tribes. It was a fun and active way to see the faces of people who shared things in common with you as well as hear what kinds of things others found interesting while learning more about the whole group in general.

Adapted for retrospection:
In order to adapt this for a retrospective I decided to tweak a few things (though for some forms of retrospective the original format would still be very useful).

To adjust, I asked the participants to only say aloud topics with regard to how the past iteration went or how they would like the next iteration to go. I intentionally wanted to leave this open-ended so any idea was acceptable (went well, could be better, something new to try, confused, frustrated, etc…) Further, I also asked individuals to only change tribes if they felt more interested or aligned with a newly stated topic. While I knew this could greatly reduce the amount of changes, I was hoping it would also take the place of an activity like dot-voting. Finally, I time-boxed tribe creation to 5 minutes.

Realizing that the bulk of the tribe creation activity is only useful as a data gathering technique, I then asked each tribe to elect a "chieftain" who would act as scribe and be willing to share outcomes. Next, I had each tribe spend the next 10-15 minutes attempting to root-cause their topic. During this time I wandered between the tribes, mostly listening and keeping folks from jumping to a solution too fast by asking open ended or socratic questions to help.

Next, I had each tribe spend another 10-15 minutes brainstorming and refining possible countermeasures to the root cause of their topic, keeping track of all the countermeasures they thought viable (at least 2-3).

Finally, the entire team got back together and each tribe shared all key factors, interesting take aways, root cause problems and all viable countermeasures. The entire team then weighed in on implementation of countermeasures creating at least one action item for which one team member took primary responsibility.

All in all, the entire activity took just over an hour.

What went well:
The feedback I received from the team was generally positive. They felt it was very different from other data gathering activities they had done in the past and liked the variance. They felt more engaged during the tribes activity and also felt the small group discussions were more interesting and focused. Also the communal sharing was appreciated and they felt that was the way to go instead of the small groups also deciding on action items.

What could have been better:
The number of participants was only 10, which the team felt worked okay, but might be better if there were more people. They didn't think the activity would have worked very well with a smaller team.

There were only a few ideas (5 total) that were shouted out, and only a few reformations (2) of tribes. Even though we had set a time-box of 5 minutes, all tribe creation was finished in about 2 minutes.

Other ideas or considerations:
It was a nice day so we did this outside, and while a bit warm, the team liked getting outside and being a bit active after lunch. They also felt the company cafeteria would be a good space in the winter.

Perhaps spending a few minutes before tribe creation for each team member to gather their thoughts and jot down a few ideas onto an index card would help tribe creation be more dynamic and fluid.

Using a larger time scale, for example a whole release or an entire month, may be better suited for this activity as people may have more thoughts and ideas remembering over a longer period of time.

Possibly useful for a larger cross-team retrospective (at any time scale). This could also blend some of tribes usefulness as an ice-breaker activity as sometimes people from different dev teams know one another. It would also help people see what problems are common across teams.

Beer.

The bottom line:
So even though the team thought of some things that could be better, they liked the activity and would like to do it again. They further liked using the activity across a larger time scale. Both the team and I had ideas for further evolutions of this activity, and we would all recommend you try it sometime with your teams!

Splitting Story Points is a Smell…Stop it!

2011-08-17T15:45:00.003-05:00

I was mostly sure we (as a community of practitioners) decided that splitting a story's points across multiple iterations was a bad practice a while ago, but I still see it being proposed or worse, actually happening.

What I feel is the biggest problem with story point splitting is the pattern of behavior associated with it. I often hear development team members complain that, if points aren't split, that they aren't "getting credit" for that portion of the work.

…seriously? …getting credit?! What is this, a college class?^[1] A story/feature is either done or not. No partial credit for half-baked features!

To be clear, I actually place the onus of this problem not on the development team, but on the individuals responsible for building and fostering the culture of that team. Why do the team members feel that partial credit should be recognized? Are the team's iterations really mini-death-marches? Are they being held to a velocity metric as a minimum? Is all the testing being left 'til the end?

In the end, the team should be working at a sustainable pace and should feel comfortable with a story not getting done by the end of the iteration.

Another problem is that splitting storie points artificially smoothes a team's velocity trend. This effectively masks any underlying problems that are causing the fluctuating velocity in the first place.

I also see a push to split storie points across iterations coming from a Dev-Manager, Scrum Master, Product Owner or some-such. Usually this comes from the desire to make some chart or table look better. It might be velocity "actuals", it could be projections of future done dates or even large standard deviations. It doesn't really matter what chart or metric it is; just making it look better on paper or Excel or whatever is not helping solve the problem that is making the chart or metric look bad in the first place.

What a team, including the leadership, should be focused on is not the beautification of reports, but on the removal of obstacles and variability in executing the work involved with delivering valuable, working software. Sometimes these charts and graphs can help, but not if we change them just to make them look good to others.

So, if anything you are running into on your team leads to someone saying "maybe we should/could just split the story points", stop there and dig deeper into the situation. I can promise you, you don't want to split the points :)

^[1] I first heard the comparison of "getting credit" for story points to college credit from Tim Wingfield.

Which is easier, Scrum or Lean?

2011-08-01T19:49:00.000-05:00

The answer? Neither…it's unfortunate, but I see this question being asked more and more. Worse, I continue to see assertions that Lean is easier than Scrum.

Realistically, I don't even think this is a fair question. Comparing Lean and Scrum is apples to oranges. Lean, to me, is a set of values and principles that have some practices associated with them. Scrum, agnostic of agile, is simply a framework for work flow.

Some in the Lean camp seem to think Lean is easier to adopt because Scrum requires an entire organizational retooling to implement correctly, whereas Lean can just sit on top of your existing system.

To some extent, this is true. To adopt scrum correctly does require major organizational change. However, most places don't. When they "adopt" Scrum they simply just change some job titles and meeting names and send folks off to get certifications. That's pretty dang easy…of course, it's also not correct and doesn't really change anything (accept the Scrum Alliance's bottom line ;)

Lean claims, on the other hand, you can just lay it on top of what you currently do. Luckily most proponents of Lean would also say you should make your work visible. This alone can sometimes take an act of the gods, ousting some current tool that hides work and process. But, even if you do make the work visible, if you don't change anything it doesn't really matter does it? So we're at the same point as a poor Scrum adoption. In order for Lean to really work its magic you have to inspect and adapt. Further, if this is going to be sustained, you must also create a culture of continuous learning and improvement. Now, I dunno about you, but in most places I've been that constitutes major organizational change!

So, which is easier? Neither! Which is harder? Both! There are still no silver bullets. If you are desirous of getting better at delivering software, or integrating software holistically into your business, or creating a real organizational value stream you are likely faced with major organizational change. This change will be ideological and cultural, it will involve values and principles, and you will change methods and practices…and it will take a long time.

Good luck on your journey, there a lot of good people and good companies that can help you get to where you want to go, but it wont be easy. However, if you keep the right attitude, it can be fun!

Scrum: Helpful or Harmful?

2011-07-25T13:25:00.001-05:00

I've noticed an interesting side effect of agile "mainstreaming". I spend less time convincing folks that certain processes and practices aren't crazy. The downside of this is that often times only the processes and practices are in place.

I've recently written a couple of blogs with regard to "commitment" and "estimates". Both are two words I hear quite frequently at places that have "adopted" the Scrum framework, and are also frequently abused. Many of these places haven't taken the time to read the original scrum book, or usually any scrum book, or sometimes any book at all, or blogs, or even just the Agile Manifesto!

This leads to problems such as "sprint commitments" being in conflict with "sustainable pace" for a development team and many other general contradictions of the underlying values and principles of agile that were originally behind Scrum.

The basic problem I see with Scrum is also its benefit: it's very easy to adopt. Change some titles around, rename some meetings and *poof* we're an agile organization now! And some places operate under this assumption for a long time. Because of this, some members of the organization get a bad taste for agile, while others see some initial benefit but then are surprised when things slow down or relapse.

There are two reasons for this slowdown or relapse:

One is the missing technical practices. For the most part XP has taken care of this, but how well understood or implemented the XP practices are in places such as these is questionable.

The second, more insidious problem, is that no underlying culture change ever took place. No spirit of inspect and adapt or continuous learning was ever instilled. The 'why' behind the 'what' was never explored and understood.

So in the end, has Scrum helped or harmed? I find this still a tough question to answer. I do feel that Scrum did a great job of getting many of the ideas spread around. On the other hand, I find a lot of need to un-Scrum, or rather work to instill the missing values and practices now, with the added baggage of over coming the fact folks thought they already made a big change.

Learn, Reflect, Adapt

2011-07-06T21:35:00.000-05:00

The point isn't to do Scrum or Lean or Kanban or XP or Crystal or Pair Programming or Continuous Integration or Test First or any other specific practice or methodology.

I'm not advocating Scrumbut, Kanbanbut or any other but.

I'm not encouraging "that wont work here".

I'm certainly not promoting "if it ain't broke don't fix it".

I'm also not in to change for change sake.
(though sometimes I encourage change to learn, but never just to be different for no reason)

What I do advocate, encourage and promote is folks figuring out what the next best improvement to their environment is and then making it happen…and doing it thoughtfully and intentionally. There are lots of good reasons to not do things. There are also lots of good reasons to do things. Your goal is to understand the difference then take action to make things better given your context. Why? Because one thing is certain; nothing is perfect, everything can be made better and in this day and age complacency is not an option for continuance.

So first you must know what all (or at least some) of the various options for "better" are.

There are technical practices, management methodologies, and organizational techniques and lots of other stuff. There is a veritable buffet of information out there, all one has to do is start to consume it. But consumption isn't enough, one must also reflect about what they are taking in and how it fits in to their context. But reflection isn't enough either! One must adapt. On top of all this, I will next ask you to do all these things continuously…and sometimes simultaneously :)

If this sounds familiar, good…it's really just a different spin on Plan -> Do -> Check -> Act and other such ideas that have been around for about 3 decades.

One small difference though. I said do them all continuously. Not linearly, not in a cycle, not in phases. Each of these things is a thread that can be started separately from the others and continue on until its own natural end or transition. For example, if you are learning about something, it might just make you think about something else you previously learned. And just because you are learning a thing does not mean you can't be adapting your environment simultaneously. And you will almost certainly be both reflecting and learning while you are adapting a change to your set of circumstances.

So…
Learn stuff; read books, blogs, go to classes, attend workshops.
Reflect on stuff; think about what you've learned.
Adapt stuff; trying things out, learn more by doing, take some action.

These things may come in ebbs and flows. You can't be dialed to 11s 100% of the time. Remember, continuously also implies sustainably ;) So it's also important to know your capacity for these things. Also, working in a pair or group can help tremendously for learning, reflecting or facilitating change.

In the end, even if you are not able to adapt your environment, you will have adapted yourself…and at least you will be improved for it. Hopefully you can improve things around you as well. And you never know what lives you might unknowingly touch in the process. So no matter what, you win!

How I was Introduced to Agile

2011-06-24T20:29:00.000-05:00

A few folks at some clients have asked me this and seemed to think it was an interesting story, so I thought I'd share…

…A long time ago, it what now seems like a galaxy far away,

I decided to get a Master's degree. The employer I was with at the time valued the checkbox and was willing to help pay to check it. At the time I was the equivalent of a "tech lead" doing Java work. I decided I wanted to go for something interesting and challenging and somewhat related to my job so I began down the path of a MS in Operations Research with a concentration in Artificial Intelligence.

After getting about halfway through with that I started thinking I might want a new job as I wasn't enjoying the one I had anymore. So I started looking for Ops Research jobs and what did I find? About the best thing you can do with a Master's in OR is get a PhD in OR…not the life for me. Now, I had previously noticed that one of the other concentrations for OR was Project Management so I did some poking around. What I ended up settling on was switching my Masters to Project Management with a concentration in Ops Research. I thought if I wasn't enjoying certain aspects of my job I can learn about how it should be done and then work to change them. That didn't turn out how I expected, but that is a different story :)

So all excited to learn about PM and change the world I got my first text book for my first PM class, started to read through it…and was horrified. As I read though this book I thought "no No NO! this wont work for software! These are all the same things that are going wrong on the job now". At the time I didn't think in terms of "traditional" PM, but I did know that software was not the same as construction or manufacturing, and this book kept using those for examples.

So I scoured Amazon for a book specifically on software project management. I stumbled upon Manage IT by Johanna Rothman, and after reading the reviews decided it was worth a shot…I had struck gold! Reading through her book gave me the exact opposite reaction to my course's textbook. As I read through Manage IT I kept thinking "yes Yes YES! This is what I have been saying, or thinking, or trying to say and think but haven't articulated well". Some where in Manage IT Johanna mentions agile, almost in passing. Something to the effect of "agile" is easier to say than "incremental and iterative".

Well, I got to wondering if "agile" was actually a methodology…boy was I surprised. I soon discovered the Agile Manifesto and realized it was a lot more than a methodology…it was an entire ideology; a set of values and principles through which to perceive the world. I decided to do some research on the signatories and soon found books and blogs. Some I had heard of already as I was familiar with their technical books, but I eventually found the Scrum book, a book on XP and Alistair Cockburn's Crystal Clear. I was originally leaning toward XP, but in the end decided on Crystal because Alistair referred to it as XP-lite as it focused more on the habitability of projects. I liked that Crystal acknowledged you wouldn't always have the best people and the best situations at work, and that was certainly the case at that employer.

And the rest you could say is history. I spent the next two years of my Masters refuting the concepts of traditional project management and the teachings of my professors using both Manage IT and Crystal Clear in literally every research paper I had to write. Along the way I kept reading more books and blogs and joined the conversation on Twitter and learned a huge amount. I also discovered a wonderful community of practitioners out there and it helped immensely to know that I wasn't alone in my ways of thinking, doing, and valuing things. I spent a couple more years after finishing my degree attempting to apply what I had learned to change my organization. Though I neither realized it nor appreciated it at the time, that huge futile attempt taught me a great deal as well.

So that is how I was introduced to agile.

Thank you Johanna and Alistair…you helped me get a 4.0 in my MS in PM, taught me a tremendous amount and introduced me to a whole new world that is now a career I love.

Team "Commitment"

2011-06-07T10:45:00.001-05:00

It seems like I've been hearing a lot about team commitment recently, or perhaps I've just being thinking about it more and am simply more aware of conversations involving commitment, but either way, most of what I'm hearing is bothering me.

Now, before I start, I want to be clear that I don't think Scrum or iteration-based team processes are inherently bad. I will say however, that most of what I've been hearing is within the context of iterations or at a more general level of what I believe is organizational mistrust of employees.

I'd also like to say, that I don't think commitment it bad. Quite the opposite in fact. Commitment is very good, and required for a healthy team, but it often seems organizations talk or think about commitment in a wrong-headed way.

To me, good commitment has three parts, in no particular order:
- First, is the team's commitment to each other (membership).
I believe this is imperative to a team's ability to gel and the longterm sustainability of a team that will continue to work together.

- Second, is the commitment of the individuals on the team to doing a good job (professionalism).
Each team member should be committed to coming in to work each day and doing the best job he or she knows how to do.

- Finally, is the team's commitment, at a high level, to the organization (alignment).
Ultimately, every org has a purpose, and everyone in that org should be committed to helping meet it. This means that, in addition to the first two parts, teams have responsibility of understanding their org's value system and purpose. If you don't like your org's purpose or value system, help change it or leave. (I'd also point out here, it is management's responsibility to communicate and share that purpose, but that is a different blog post :)

So what is bad commitment?

Well, the easy answer is anything that's more or different than what I stated above ;)

Here are a couple examples:
- Asking a team to "commit" to getting work done in an iteration (ignorance).
There are lots of understandable and improvable reasons why work doesn't get finished. There are also lots of unexpected and unforeseeable reasons too. If a team feels that failing to meet an iteration "commitment" is unacceptable, they will not be operating in an environment in which they feel safe to learn, adapt and improve.

- The belief that not asking a team to "commit" to work will decrease a team's accountability (mistrust).
This assumes that without asking for "commitment" team members are more likely to slack off. This is treating your professional knowledge workers at best like children, at worst like untrustworthy thieves.

- Using "commitment" to motivate the team to get more done (poor leadership).
If you feel that you have to have an arbitrary deadline to motivate your team, then you have hired the wrong people. However, what is the more likely case is that the right people have been hired, but they've not been operating in an environment conducive with success. Leadership should focus more on building environments from which successful situation are likely to emerge, and less on products and projects.

So that's it. There are many other stories and examples of bad uses of "commitment". Normally though, they all seem to boil down to mistrust, ignorance, or poor leadership (or usually a cocktail of all three). Commitment should revolve around three things: membership, professionalism, and alignment. No more, no less. If you feel that your team is being asked to commit to more than the above, you should question it. If you are the one asking a team to commitment to something more, you should ask your self why.

Woodland Creature Story Sizing

2011-05-31T19:27:00.002-05:00

I'm not a big fan of story "estimates". In my opinion, it conveys a notion of accuracy that simply isn't possible. I prefer story "sizes" instead…still not perfect, but better.

I'm also not a big fan of using numbers to size stories, again, because numbers encourage folks to do math that doesn't make sense.

So what do I recommend for sizing?

Woodland creatures!

Here is my "normal" list:
- Shrew
- Squirrel
- Badger
- Boar
- Deer
- Bear
- Elk
- Caribou
- Dragon*

The reason I like woodland creatures is:
1) you can't do math with them (though they do multiply!)
2) they imply a size or category, but not an accuracy, and
3) they keep the team from taking the activity too seriously, but differences in opinion still get discussed.

Personally, I've only ever made cards and used them for various planning activities. Others have suggested finding various animal stickers and sticking them right on the card (I like this idea but have never gotten the stickers). The list of animals obviously doesn't matter. They simply need to go from small to large if used for sizes, or any animals if you're simply assigning a category or class of work.

*Note: You may have noticed the last animal in the list above was a dragon, and might be thinking, "wait a sec! dragons aren't woodland creatures!"…and you would be right :) However, I usually reserve this special animal for stories the team think needs to be broken down further. Then we either assign a "dragon slayer" to ensure the story gets broken down, or we simply avoid it for now.

My preferred planning activity is "Creature Sizing". This is basically T-shirt sizing; assigning a category of work to a story. Select a handful of woodland creatures to use. Normally three is fine to start off with (I use Shrew, Badger, and Bear). Next, a subset of the team (about 3 members) is asked to discuss key points of the stories. If another team member with special knowledge is needed they are "tagged in" at the last moment. These team members then assign a woodland creature to the story. If the team is less mature or lacking confidence then the whole team could be used for this activity.

I should also mention, that when possible, I like the categories of work (and therefore number/types of animals) to emerge over time instead of selecting them up front. This isn't always possible if an entire initiative is needing to be relatively sized for a governance decision. Also worth mentioning is that this level of planning can be continuous, with little disruption to the team.

I've also used the woodland creatures with Planning Poker (my least favorite sizing game) and 1-N Table Walking (which I like better than Planning Poker, but still sub-optimal/less mature in my opinion).

So there is it! If you think your team or your product owners are getting too hung up on the "accuracy" of your "estimates" or start doing "crazy velocity math", consider using Woodland Creatures as an abstraction that may help :)

Agile Up 3 Here: Reflections on the past

2011-05-23T00:09:00.000-05:00

So I'm writing this the evening before I fly out to San Francisco, heading to Pleasanton CA actually…Agilistry Studio specifically…for Elisabeth Hendrickson's second annual Agile Up X Here event, "Agile Up 3 Here" (the first one was 2, because 0 and 1 based numbering is so overdone :)

Looking forward to this week got me reflecting a bit about the first event. The people there were all amazing, talented, and interesting in many ways…and they liked PUNS!

However, meeting amazingly awesome people wasn't the only great part. For me, it was also finally getting to see what a truly high performing team could do with all the agile principles and practices I had been studying and attempting to apply in my large corporate environment. What I really enjoyed was watching the interactions of all these people unfold into working software and a happy customer.

Now we had it good! We had a small group of talented people (and me). The team space had all the wall-space, index cards, and hamsters a team might need. It was as close to perfect as you could get.

However, even with everything being stacked in our favor, we still hit a few snags, some because it was the first time running the event and everyone was learning, and others because we were a group of humans working together.

But at the end of the day, we did it! The team had delivered, through multiple iterations, working software. We focused on the needs of and value to the customer. We used good technical practices. We interacted, collaborated, reflected, learned and adapted.

At this point, you might be thinking "of course it worked, you had a small group of people working in a near-optimal environment". So why is this all so great?

For me, at that time, it was great because it demonstrated that it is actually possible. It may have been the metaphorical "top of the mountain", but still it worked; it gave me hope. It breathed fresh vigor in to the various initiatives I was attempting at work, and eventually lead me to leave that employer, to take a new job where I could help other places realize at least a little bit of what I experienced at Agilistry.

I knew from my 6 years in large corporate IT that the path to the top of the mountain is long, and difficult, but Agile Up 2 Here showed me that it was possible. Since then, in my new position, I continue to reflect about the things I learned that week, and use that as motivation with the many teams I've worked with since.

I'm really looking forward to this coming week; catching up with old friends and meeting new ones. I'm also super excited for the new experiences we will have and the new learnings and reflections they will provide me in the future.

Thank you Elisabeth for providing me that opportunity a year ago, and being kind enough to have me back!

Unmotivated or Demotivated?

2011-05-18T00:03:00.001-05:00

I’ve worked with a few unmotivated teams in the past. Folks on unmotivated teams lack energy. They see things as just the way they are; the status quo. They come in, do their job and go home. Things are normal...good enough.

I find it a fun challenge to motivate unmotivated teams. Getting to know folks a bit, finding out their interests or passions and helping them map those back to their job or career is quite rewarding, but I recently ran across a problem.

I began working with a team that had been working together on a project for a while. They were displaying all the signs of an unmotivated team. I had heard tell of some negative stories about “management” but nothing I wouldn’t have tacked up to normal enterprise candor and so I set out down my usual path to motivation...and met with failure. Everyone listened, asked some questions and generally interacted appropriately. Nobody was overly negative, they simply lacked energy.

After trying a few more tricks with no real traction I started poking around at the negative stories I had heard before. After some digging it became apparent that some pretty heinous treatment was given and the team just took it on the chin...a few times. This completely demotivated them.

Not having been present for these acts, and only joining the team months later, what I was seeing was the exact same outward signs as unmotivated people, but really they were demotivated...which runs much deeper.

As I stated earlier, unmotivated teams simply lack energy. When something is lacking you just need to replace it. However, with demotivated teams something isn’t missing, something has been torn down, and must now be rebuilt. That is a much harder task.

Demotivation is a trust violation. Rebuilding trust is hard in any relationship but I think especially so between an organization and a team.

When one party violates another’s trust, the violating party needs to admit to some wrong doing. This is hard because an org needs to send a consistent message here. That means that those folks need to agree they did something wrong in the first place. It also means they can’t take the same or similar actions again in the future.

Orgs also can’t buy their way out of this. No third party can be brought in to do the actual rebuilding. A consultant may be able to identify the problem and advise on how to handle it, but the people in the org that enacted the trust violation need to be the same people to take action to resolve it (or be gotten rid of).

So where is all this going?

Well, if you are a consultant; beware! If you think you’re working with an unmotivated team, the problem could be worse. If you identify a trust violation, change gears to facilitate rebuilding if possible.

If you are in a leadership position and think you have an unmotivated team on your hands; beware! If motivating the team doesn’t seem to be working, they may be demotivated and perhaps some trust needs to be rebuilt instead.

If you think there is a chance you may be the person who demotivated the team; beware! Don’t go in and try to motivate people, especially in a “ra-ra go-team” sorta way. In my experience that just adds insult to injury. Maybe get some help from a coworker or externally.

One side note. A fun fact about rebuilding trust is that many of the actions are a lot like building trust. An interesting side effect of teams within orgs that are actively trying to build trust, is that sometimes those teams get motivated that their org is showing interest and taking action.

So...be aware of de vs. un motivation and work to build trust no matter what!

Lean/Agile: Why you don't need it!

2011-05-03T22:50:00.003-05:00

So you've been hearing a lot of hype about this lean/agile stuff. Of course let's be honest…by "a lot" we really mean an article in a trade magazine don't we? In fact, we were on the pot during that particular read and there were two other, more interesting articles on cost-accounting and tools to manage resource processes; so we really only read the title of that agile article…didn't we? And what's wrong with that? I mean with a title like "Agile: All the Unicorn Giggles without all the Unicorns" what could possibly go wrong…right?

I mean what would really need to change anyway? Your painful annual budgeting process and five-year project plan has worked well forever! Your hiring and training processes have certainly maintained the skill level and interest of your cost-center-style IT department. Besides, you just sent your VP of HR all the acronyms and version numbers of all the tools and technologies listed in the past 6 monthly trade magazines…man... you're on top of it!

Either way, I'm sure your company is in a stable, non-commoditizable market space. I mean yeah, you mostly deal in information now that it's 2011, and your major competitors have likely eeked the last few iotas out of their measurable primary operations over the past few decades just like you…but they just don't get it like you do! And anyhow, your shareholders were amazed with last quarter's dividends…when have they ever been wrong? Heck! They are even considering an IPO! All signs point to yes! …jeez wont you be rich once they decide to go public?…probably shouldn't rock the boat now!

As for employee engagement and more rewarding work and lifestyles…what a bunch of hooey! Those people should just be glad to have jobs right? The ones that made it past the last round of layoffs that is. I mean, have they seen the economy? Anyhow, your company is the best in town right? After all, you work there and you're no loser! They should feel proud to be part of the same thing you are…that same vision of …well…we don't really remember the vision…I mean, we printed it out a few months ago on those plotters we got…for, you know…printing out the vision statement. Damn that was an expensive year…almost didn't make EBITDA that year…good thing we cut the training and conference budget so we could get the plotters! …but yeah…we printed that vision out…mostly because it was too long to remember. Something about increasing something and something else about shareholder value. I think they mentioned something about customers, or maybe employees…oh wait…both were there, but "employees" were termed "service personal"…that's right…yeah…so the plotters were a good investment!

Anyhow, you've likely asked around at the office about lean and agile by now and one thing is clear. No one can agree on what it is…they were going to buy some books and send some people to conferences a couple of years ago, but that budget got cut…something about vision and plotters…They do agree on one thing though! That it isn't easy! It is hard and takes a long time to really "go agile". Even so, lots of folks seem to be getting pretty excited by it. What would they know though? None of them have MBAs…or at least you bet they wouldn't if you took the time to ask…they certainly don't get business and how things work in the real world. At least not the same way you get it, you devastatingly clever bastard!

Well, like it or not, a lot of your people are clamoring about this, and a few of your competitors have been recently "going agile". You don't want to fall behind! Here is a surefire way to change nothing while still "going agile":

1. Send your three best managers (the ones who do the best job commanding and controlling their resources) and your three worst managers to "Certified Scrum Master" training. This may seem odd, but you effectively get six certified Masters of Scrum, the leading Agile Methodology, for effectively half the price! (Nobody misses those other three guys anyhow…we aren't really sure why we keep them, but we never seem to fire anyone for any reason)

2. Go back and actually read that whole article in that trade mag. If you can't find the ten minutes that takes at least skim the bold print and italicized words. This way you know the lingo! You will be able to hang with the geeks and tell if they are bullshitting you! If you want to be a true lean/agile thought leader in your organization, repeat this step for at least two more trade magazines. If you still have time, consider a book summary to round out your agile education. Do not bother reading anything else. As you will soon learn from your Lean Words that is called "waste"...nonessential reading and learning. Besides, not much has changed since Fredrick Taylor developed Management Science over three decades ago...but you knew that, because you got an executive MBA a few years back to get that promotion!

3. All change requires a manager of the change process. We all know this. Choose a manager that has been around for a while and isn't really going anywhere with his career and appoint him to "Director of Agile". His duties will be reading the full articles in the trade magazines and maybe even a whole book. He should also know at least 10 names of book authors and know approximately 35% more buzz words than you. He will make lots of checklists to give to your new agile teams and report back to you on the new agile status of your agile projects in your agile project management software…I recommend Version One…it does so much that you'll never need, but DAMN it's expensive and you will get to brag about how much you spent on "going agile" with your friends on the executive golf course next month! Besides…the reports and charts you can make with that thing…it's every PMPs wet dream! You can even track things that don't even make sense!

4. Do more of what you have always done. I mean you're successful right? So do more of that. No need to actually question the status quo or actually change things. We all know change introduces risk and there is that IPO to think of. One caveat to this is if your company is struggling. In that case it is especially true that you not change anything! I mean, are you crazy? If you know what you are doing isn't working why on earth would you try something different? Just do more of what got you there…it's obvious you weren't doing it enough, otherwise you wouldn't be having problems. Also, don't confuse not changing anything with not spending money. Buying fancy tools and expensive consultants to not listen to is often the easiest way to appear to be taking action in the face of adversity.

So the bottom line is, you and your company are already the shizznit! You know this. I know this…but you can accept that times change and sometimes we need to use different words to do the same thing…that is business my friend, of which you are well aware.

Go forth! Learn new words! Be AGILE!

Your team space should deliver a message

2011-04-22T00:16:00.001-05:00

Recently I've been helping a new team setup their team space. Now, I'm a big fan of hanging stuff on walls. Big visible stuff. But there's more to it than that. When deciding what you should put where you are actually crafting a message to anyone that walks into the space.

My personal metric for knowing when you've done this effectively is to answer the following question: Does it change someone's mood?

In my opinion, when anyone walks into your team space, from the newest dev to the most senior executive, what's hanging on the walls should make them feel differently within a matter of minutes. If that doesn't happen, something's off.

Now I'm not advocating that teams throw a bunch of crap up to simply appease people, especially those not usually in the space. In fact, the big visible stuff should be minimalistic; the least amount of information required to paint a deep, rich picture of what is going on, what value is being added, when things are happening, and anything else that is useful.

I'm not going to go into what specifically any of the stuff should be. There is tons of information out there on that such as information radiators, styles of team boards, card maps and lots more. Instead, I encourage you to think about the message you want your space to convey.

Here are a few things to consider in addition to the actuall stuff you choose to hang up:

1) If it's hanging up, make sure it's actually big and visible --Sometime I wish plotters were never invented. Release burn-down charts and code coverage trends are examples of useful things to hang up. Too often though, I see people (usually PMs with whiz-bang tools) print them out. I assume they do this because they think it's easier, but walk across to the opposite side of the team space and tell me if you can read it…all of it. It's not enough to see the trend lines if you don't know what the chart is trending or what the axes are. Instead, draw it out on some paper or a white board with a big fat marker. Now go walk across the room…yeah, betcha can read that!

2) If it's hanging up, make sure it's useful --I like to think of this as pruning. Something that was once useful may have run its course. If so, tear it down. If you need it later, recreate it. However, before just tearing stuff down, make sure the whole team agrees that what ever it is is no longer useful. When in doubt leave it up, there are usually ways to make more room if you need it. It's also important for the team to consider organizational usefulness. Not everything will be the most useful to the team itself, but sometimes to managers or other stake holders. PMs like release burn downs and cost burn-ups, CFOs like value stories etc… These should not dominate the space, but they are still useful, and it's important for the team to understand their organizational usefulness as well :)

3) If you need something useful, make sure you hang it up --The space is not a fixed thing. Obviously if we can tear stuff down we can put new stuff up. The process of software development is journey or learning and discovery. Visualizing different things along the way can help a team communicate, both with each other as well as those outside the team. If you think something might be useful, hang it up for a while, try it out. If it doesn't add the value you thought, ask how it can be improved. If after a while it is still not providing value, see #2.

4) If it's hanging up, make sure it's in a good position --Not all wall space is created equal. This could be due to many things such as lighting, vantage point, furniture arrangement etc… The best thing to do is plan a little bit before you hang something up. How often will it be updated? Is it a conversation centerpiece? Should it be visible to a passer-by? Once decided, go hang it up. If things change and it needs moved, move it…it's only paper and tape right?

5) If it's hanging up, take pride in making it --Remember, you are crafting a message. You want things to be visible, digestible and useful. Those traits can be hard to achieve if your big visible stuff looks messy, half-assed or cluttered. It doesn't take that long to use a straight edge instead of free-hand drawing. Create a color scheme of post-its or stickers. Use different size index cards to mean different things. Create a legend. It doesn't have to be a work of art, but it should be tidy (within reason) and professional looking to communicate your message effectively. If you think something has gotten too messy over time, clean it up or redo it…it usually doesn't take very long.

6) If it's hanging up, it's a living document --Don't be afraid to enhance anything that's hanging up. Feel free to draw, stick stickers, add post-its or whatever else adds value. You can usually tell which documents (big visible charts) a team find the most useful by the amount of enhancements made to it!

Finally, don't forget to test this stuff out when you think you are done. Stand back from your space and look at it. What does it say to you? Stand in the doorway or hallway and look in. What does it look like from there? Have people from other teams walk through. Is there anything that is unclear to them? Ask a manager, director or executive to walk by. What were they able to tell by just looking? Maybe do a few of these every now and then as your space evolves with different stuff.

Ultimately, don't forget that original question from way up there: Does it change someone's mood? Folks should feel better about what the team is doing, where the project is headed, and what they are getting for all the team's effort. If this is the case, then you've successfully crafted both an effective team space as well as an effective message.

Professional development: Little time, Lotta value

2011-04-04T20:17:00.002-05:00

I had a good chat today with someone about taking the time out of one's personal life to do personal/professional development. The outcome of our conversation was that it really doesn't take that much time to do a decent amount. In fact, I suggest it is often the feeling of being overwhelmed or not knowing where to begin coupled with generally poor time management that keep us from achieving this goal.

Now, this individual's life situation isn't that uncommon for those who feel strapped for time. He is married, and they are a younger couple with a small child. Family time is important as is quality grown-up alone time as well as some individual relaxation time for personal/individual hobbies or interests.

Here was my "challenge":
1) Read 4 books a year
2) Subscribe to a dozen blogs and keep up with them
3) Start writing a blog or keeping a professional journal

To some, this may not seem like a whole lot, to others it may seem like an insurmountable objective. In either case it's a whole lot more than I see most folks doing in most organizations. I equate the above activities to understanding theory, keeping up with current events, and critically thinking and applying what you've been learning. There are of course other things folks could do, and ways people can get more engaged with their careers or the community in general, but I set this rung as the minimum. Also, the above activities are all cheap or free, have low barriers to entry and are fully within the control of the individual.

Here is how the time involved broke down:
- One 300 page book: 10 hours; 100 minutes every other week
- Keep up with blogs: 1 hours a week; 10 minutes of skimming/grooming, 50 minutes reading
- One blog post/journal entry a month: 3 hours; brainstorming (30min), outlining (30min), writing (90min), reviewing (30min).

Now your times may vary if you are a slower/faster reader, writer, etc... and you may prefer to follow different formats or techniques when creating or consuming information. The details aren't really important, just more of a guide for anyone who wants it.

The totals from above are: 31 hours per quarter or approximately 2.6 hours per week.

I'm going to assume you get about 8 hours of sleep a day (which is a lot for me) and that your work week is about 40 hours. This should mean 5 (workdays) * 8 (hours of free time) = 40 hours + 2 (weekend days) * (16 hours of free time) = 72 free time hours per week!

For most people, the numbers should work out. Even for a young spouse with a few little ankle-biters running around, 2.5 hours out of 72 seems easily doable. I mean 2.5/72 is less than 3.5% of your free time. Even if you are only 25% efficient with your time usage (you waste 75% of your free time) it is only 14% of your total weekly free time!

So where does the time go?!

I'm not overly interested in writing an article on time management, but here are a few ideas:

- Lots of people I know seem to sink a wasteful amount of time into tv, video games, surfing the web, etc... A little is good for relaxing, a lot is wasteful.

- Plan a little bit. Set an appointment or reminder for yourself. Talk to your family about what you are wanting to do and get them to help you too.

- Set some small measurable goals. Track those goals if it helps. Set daily or weekly goals to achieve the desired outcomes.

- Make the first book you read a time management book ;)

Why should I do this on my own time?

I've had conversations, similar to the one above, with others in the past. Sometimes I got feedback along the lines of "I shouldn't have to do this in my free time". Well, maybe, maybe not. I do agree that more organizations should encourage learning and professional growth during work hours as part of the organizational culture. Unfortunately this is just not the case and you need to choose what to do. It's your career. What is working for you today may not work tomorrow, or worse in 10 years when your skill set has completely atrophied. My personal opinion is that continuous learning is just a good habit to form, and spending at least a little of your own time to develop yourself is not a waste. If you dislike your work so much, the thought of doing more or anything related to it in your free time disgusts you, perhaps it's time to find a new career or at least a new employer.

What if I need more/other development?

So, my conversation above was with a manager and the goals all boiled down to just reading or writing. Hopefully this new knowledge would eventually be applied and reflected on at work. It can be challenging to practice skills like these outside of work, but perhaps you belong to some social group or organization where you can try them.

Perhaps you are a programmer or a tester and you need to stay abreast of various technical practices, tools or techniques. I will admit that these things are more time intensive, but perhaps in this case some of the reading and the writing can be lessened or forgone in favor of technical learning and practice. Go more deep and less broad.

In any case, in most situations the time commitment involved above is fairly small. If you have chosen a career path that requires double or even triple the time investment, it still is fairly reasonable, and all the same concepts still apply.

The Story of the Agile Coach and Traveling Tinker

2011-03-03T07:41:00.002-06:00

A Tinker, in olde times, was a traveling handyman, a merchant of various hard to aquire odds and ends, and often times a source of news from other villages as well as a swapper of stories. Tinkers were generally well received by most villages because of their various wares and services, but children and young adults were usually steered clear of them.

You see, the village elders, who were set in their ways and had firmly planted roots in their village, appreciated hearing news from surrounding villages and always enjoyed the stories of mystery and adventure that were shared by the Tinker. However, while the elders were wise and understood these tales of fantasy for what they were, the youth of the village would often find intrigue, inspiration and sometimes a longing to leave the village.

These youth, of course, were silly! Wanting to pursue individuality and autonomy, seeking to perhaps improve or master their skills, and most naively of all, a desire to be a part of something bigger than themselves; to find a grand purpose.

The village elders, who were wise in the ways of the world and knew how things really worked, found that these intrinsic motivators were a powerful force on the impressionable minds of the village youth. Given how unreasonable and strong willed youth can be it was much easier to simply have the youth avoid the Tinkers than expose the youth and then attempt to dissuade them. After all, it was the best thing for the village strategically, and change to the normal order of things in the village would only cause upset. Besides, how would the village ever survive, as it always has, if the youth ran off to explore, discover, and learn new things instead of filling their duty to the village; plowing fields, thatching roofs, and all the other tasks needed to sustain village life as it has always been. Madness and chaos would surely ensue!

Yes, Tinkers were useful. They would come in and fix a few small things, and that is all the village really wanted. A village would never intentionally expose their youth to them and bring in unwanted change.

The danger of bringing in an external Agile Coach...

When an organization doesn’t understand that agile will expose cracks in a foundation, that its continuously optimizing nature is inherently holistic, there is danger. The danger lies in being brought in to “only improve a team”. This is a local optimization, but can certainly be done; practices and methods can be made better. The small things can be “fixed”. Eventually though, as the team gets better all around, they will also understand this is a sub-optimization. They might start asking questions, seeking autonomy, mastery, and purpose. They might want to improve more than just themselves. They may ask the rest of the organization to embrace this philosophy and to embark on a journey of exploration, discovery, and learning.

But of course the organization’s elders, who are wise in the ways of the world and know how things really work will discourage this. However, the team may have heard stories of mystery and adventure from the Agile Coach about other companies that were trying new things, doing things differently and embracing change.

The danger is obviously these unreasonable, strong-willed team members may be inspired to leave the village, and then the village will surely die!

Top-Down vs. Bottom-Up Agile

2011-02-14T00:52:00.000-06:00

Now, the systems thinker inside me knows that both top-down and bottom-up are just local optimizations. The correct (or at least better answer) lies somewhere in the middle. Surprise! Like most things in life, balance is better :) It’s also very likely that the decision of how much to one side or the other is dependent on the context of the given organization. Dang it! No one-size-fits-all solution again!

Top-Down
Interestingly, I’ve never actually experienced what I would consider a true top-down agile transformation. Oh sure, I’ve been at places where managers, directors, and even executives say all the right words, but when push comes to shove, it’s usually business as usual; pushing forward to hit some arbitrary date or BDUF in Scrum clothing or some other nonsense...folks just determined to not understand how software development actually works.

In many of the top-down scenarios I’ve seen or heard of, the dev teams feel as if some new silver bullet process is being forced on to them. Here we go again, the big wigs found something shiny in the latest trade magazine while they were on the pot and now we all gotta learn new words and have new meetings just to keep doing the same ole thing.

Bottom-Up
Unfortunately, bottom-up or grass-roots initiatives don't seem that much better. Sure the teams may have adopted some better engineering practices such as TDD, pair programming or continuous integration, but to what end? The business is usually still some level of disengaged from the team; or the organization as a whole hasn’t adapted to produce a constant flow of value through its high performing software teams.

Eventually it seems, if the teams become high performing, the team members realize that the bottlenecks to creating value lie outside their sphere of control and then get frustrated. This tends to lead individuals down one of two paths: either find a new employer or become detached from the organization and slump back into a zombie-like status quo.

Which one is better?
Obviously neither! I guess if you forced me to choose, I’d pick bottom-up as the lesser of two evils...but that’s just because I have seen and heard of too many botched top-down, process-driven, prescribed, checklist style agile transformations. At least with bottom-up something of value is created whereas with a botched top-down it’s usually just wasteful. Also, with some luck, maybe some mid-level or senior leader may realize how to actually get something done with these locally optimized high performing teams.

So what to do?
As indicated above, the answer lies in the middle. The perfect situation would have the enthusiasm and inertia of a bottom-up style transformation with the trusting top-down support needed to create an environment in which the transformation can flourish.

Sounds like a pipe dream, I know...but it makes sense right? We are basically saying that to even have a chance of optimizing the whole, everyone from every layer of the organization has to be involved. Anything else will be a sub-optimization. Everybody must question the status quo, empower the most appropriate nodes of responsibility and above all continually reflect, learn, and adapt.

It is in this way the transformation will be successful. Oh, by the way...what exactly are we transforming? Software development; from a necessary evil into a competitive advantage!

The Fundamental Unit of Agile: The Self Organizing Team

2011-01-13T15:01:00.000-06:00

[This blog post is a reprint of an original article I wrote for PM Boulevard. I’m reprinting it here as they require signup to read their stuff.]

In the Agile space there is a lot of talk around “self-organizing teams”. This term is plagued by the same problem as many other trendy catch phrases; it’s made up of a bunch of words that everyone knows which are strung together in such a way that everyone believes they understand what they mean.

There is already a ton of information out there on what a self organizing team is, but for the sake of completeness I will give a quick review.

A mature self organizing team should:
- Understand generally what its goals and constraints are.- Continuously learn about itself, its environment and be able to adapt.- Routinely question the status quo, seeking to remove waste and improve.- Be given the responsibility and authority to actually do everything above.

Sometimes folks get the impression that self organization is a purely ad-hoc, do-what-feels-good, Lord of the Flies environment conjured up by developers to get rid of management and that it will never scale to the enterprise. This could not be further from the truth. Self-organization requires professionals to maintain a high level of discipline in a structured environment. A true self organizing system will scale indefinitely, and, while many of the ideas involved with self-organization indeed challenge traditional Taylor-esque management structures and styles, it does not imply a lack of leadership, communication or coordination.

Often times organizations struggle with how to achieve self organization. This is especially true for businesses that are migrating from traditionally “managed” teams or a command-and-control hierarchal structure. Two areas that cause the majority of the problems with creating self-organizing teams are 1) an understanding and supportive organization and 2) a willing and able team.

An understanding an supportive organization:
It’s one thing for an organization to say it supports self organizing teams and another thing to actually do it.

The first step is to get the current software development management around the teams to understand their new role. The wrong thing to do is just let go of the reins and expect teams to all of a sudden fend for themselves. Management needs to transform into mentors, coaches, and motivational visionaries there to guide teams and help them overcome the eventual obstacles they will encounter.

The second step is to engage the rest of the business to understand their needs and work organizationally to adapt business needs to self organizing practices. This will likely be new information to many other departments in the organization and there could be some challenges as their status quo gets ruffled. The key is to show them the benefits of what they are gaining and mitigate the feelings of loss due to change.

To be certain, this is not an IT-only shift. The biggest mistake management or senior leadership can make is to assume this is not a fundamental change in how the organization, as a whole, will operate moving forward.

A willing and able team:
Not to be underestimated are the challenges and changes an individual team will undergo during its metamorphosis to self organization.

First there has to be a level a willingness on the team, even just to try. The basics should be described to every team member; that they all have a shared accountability for the success and improvement of the team, that is it everyone’s job to learn, ask questions and to challenge things that don't seem to make sense and so on. Sometimes teams jump at this opportunity and others shy away from it. If many of the members are used to traditional hierarchal teams they may want to just come to work and “do their job”. It is important to explain to those individuals why the particular changes are being made and how these types of teams increase the quality of software as well as allow the organization to adapt to changes more fluidly over time.

Unfortunately, not all individuals will acclimatize to this. While this is pretty rare, occasionally it may be required to inform a team member that this is the intended direction of the team, and that if they are not comfortable with the new environment, perhaps they would be better suited elsewhere in the company. To be clear, a transfer of this type should be made genuinely and not as a my-way-or-the-highway threat.

The second consideration is to determine if the team in it’s current state is able. A team needs to have some members that are likely to emerge as leaders as well has have individuals with technical proficiencies and domain knowledge. Sometimes the team lead, tech lead or manager is already providing sufficient leadership, but not always and not always in all areas that require leadership. Often times, in a self organizing team, multiple leaders will emerge. That’s okay. It’s not like leadership is defined or imbued with a title anyway right?

So this all seems really complicated and risky. Why bother?
To be sure, migrating from traditional teams to self-organizing teams should not be trivialized. Quite often it can be useful to being in someone from the outside to spend time with a team to help them with this transformation. This “coach” is certainly not required, but having an effective change agent knowledgable of agile engineering practices and methodologies generally is, whether that person be internal or external. It’s also important to remember it doesn’t have to happen overnight (and probably shouldn’t), simply keep the principles in mind and continually adjust towards the goal.

Edwards Deming showed that, even with automotive factory workers, empowering the lowest levels of an organization greatly increased quality, productivity, and job satisfaction while simultaneously keeping problem solving and decision making flexible and adaptive. This is especially true, and perhaps even necessary, for long-term success when “managing” or organizing knowledge workers. However, in the end your organization can reap the same benefits Deming found. Your software teams will be able to create higher quality products while feeling more autonomy, purpose, and mastery in their jobs while keeping your organization more responsive to change.

Facilitating Change by Reaching for the Stars

2011-01-04T02:10:00.002-06:00

Tonight I attended a local agile meetup where I was participating in an interesting discussion about self-organizing teams, emergent behaviors and scalability of such things to a larger organization.

At one point during this conversation, one of the other attendees shakes their head and, in summary, asserts that I’m an idealist. All of my claims may be fine in theory but would never actually work in practice, especially in a large enterprise. Another attendee then pipes up to ask where or if I’ve ever seen large-scale self-organization implemented successfully. My answer to this was “no where, but that doesn’t matter”.

It was at this point I felt that we had simply reached a philosophical impasse. It seemed my colleagues didn’t believe my claims were possible and the fact that neither they nor I had ever witnessed such was proof enough. After all, all I had was a vision of possibilities; of how things could or should be. While they on the other hand, had a litany of concrete practical reasons why none of those things would work in their various organizational environments.

Now, this post isn’t about self-organizing teams; not exactly. That was just the topic at hand that made me wonder why many people in the past have considered me an idealist while I tend to consider myself a pragmatist...and then it hit me; I’m both. Just like other hyphenated concepts in agile (such as the generalizing-specialist) I’m a pragmatic-idealist.

My favorite metaphor for this is that pragmatism is the path, while idealism is the compass. Metaphors are great, but let’s break it down:

- How do you use the compass (idealism)?
Easy, you look at the needle and follow a path in that direction, then you stop after a while, check the needle, adjust your direction if necessary, then follow the path in that direction; repeating until you reach your destination. 

- How do you follow the path (pragmatism)?
One step at a time (incrementally) making sure you take in your environment and understand your situation so that you make the most appropriate next step.

- What is the destination (idealism)?
In many cases I like to set an ridiculously high, yet imaginably possible goal; one that seems almost unattainable. Why? Because it encourages continuously striving towards something better because if you can imagine something being possible you can often figure out what the nearest thing is stopping you from getting there.

So all in all, I guess I agree I’m an idealist. It’s the ideal situation that motivates me and drives me to do my best work and continue on in the face of adversity. And yeah, I’m a pragmatist. We aren’t going to be ideal overnight, we need to consider the realities of our current situation and pivot to the next best place to be, but oh no, we aren’t done; we’re never done until we hit the ideal, which may never happen, but that’s okay. So in the mean time I better keep learning, adapting, and acting to the best of my abilities, and I encourage you to be a pragmatic-idealist too!

Comments on “No True Agile, No True Lean, No True Latte”

2010-11-22T20:10:00.002-06:00

This post is in response to Jurgen Appelo’s “No True Agile, No True Lean, No True Latte”. I agree with most of Jurgen’s message in his blog but had a couple of thoughts along the way while reading it. I highly recommend you read it...while drinking a latte :)

Jurgen:

WRT “There is no objective way of determining who is right and who is wrong”
As far as details and minutia go, I think I agree with you. However, in the broader sense I think we can safely agree that Agile and Lean (and maybe even Lattes) exist to help organizations deliver better value from their software development efforts.

While the word “better” is certainly not objective, an organization should have at least some understanding of what “better” means to them within their given context.

So, while I agree there may not be an objective way to find what practices/values are right or wrong, I would think an org should be able to tell you what is working for them and what is not. That should count for something even if it is subjective or relative or whatever.

WRT “[…] attributing relative weights to versions of the model depending on how often they are being referred to.”
So, this is an awesome way to sum up a good idea. This basically describes learning, or at least learning the way a neural net learns...which I’m sure you’re aware of being a complexity guy and all.

My key issue here is that the process of assigning weights to pathways to nodes of stored information is the process which is important for an organization to understand and continue to propagate. This learning is the key to understanding what pieces of the whole (aggregate model) work for the holistic organization in its context.

While I’m positive we don’t disagree on this, my concern is that the people who may need to understand your blog the most may take away from it that it’s possible for an “aggregate model” to get created and ironically become the One True Aggregate Model (or at least treat it as such).

WRT “It’s no use pointing out what an original document actually meant in the past”
I guess I half-disagree with this...meaning while I totally agree the main thing to focus on is the current best understanding of Lean/Agile, I also completely disagree that there is no use in understanding the original intent.

I’ve always liked the phrase “Those who don't learn from history are doomed to repeat it”. I believe it is important to understand that history. What was the struggle? What was the point? Are we solving the same problem? How have things changed? Is this still useful? All good questions to ask, but need a starting point or some beginning context.

So while I don’t think folks should just blindly assume past original intent is still applicable to current problems, I think it serves them well to know how things started as well as how we got to where we are now from there.

My Takeaway on Your Takeaway
I guess I’ll just go back to my opinion that the learning is the key. I don’t really think there is right or wrong, just better or evolutionary. I think the process of building one’s own aggregate model is the useful task, not the having of an aggregate model. So to that point I’m not sure if an “all models are wrong” stance is the best, but perhaps an “understand many models, adapt your own and keep adapting” would be better...although they may effectually be saying the same thing :)

One note on “context”
I know I’ve mentioned orgs doing things in context a few times...so while I think almost everything needs to be considered in its context, I don’t subscribe to not trying new things because “that just wont work here” or “we’ve tried that before”.

So now I’m an Agile Coach...whatever that means.

2010-11-01T19:39:00.002-05:00

So for those who don’t already know, I recently left my previous employer and have moved into a consulting position with Pillar as an Agile Coach and have been doing that now for just under two months. So while I did a lot of what I would consider coaching at previous positions, this is the first time I’ve been hired to do it specifically.

Overall I find that I am loving what I do and look forward to all the various challenges and opportunities that present themselves everyday. However, one thing I have discovered is that the title “Agile Coach” is a troublesomely nebulous term. The sorta title where you ask ten different people “what is an agile coach” or “what does an agile coach do” you are likely to get ten different answers...or just the famous “it depends”.

In an attempt to help clarify the role and duties of an “Agile Coach”, below I’ve listed a few of the hats I’ve worn or feel I have been expected to wear over the past few weeks:

Software team anthropologist
Application architect
Scrum master
TDD Coach
Developer guide
BS caller
Business consultant
Behavioral psychologist
Staff aug. project manager
Product Owner
Furniture mover
Pragmatist/Realist
Executive coach
PMO advisor
Marketing advisor
Finance & Budgeting advisor
SDLC theorist
Software Craftsman
Group therapist
Team defender
Turok: Dinosaur hunter
Project portfolio planner
Test engineer
Assertive Team Leader
Motivational Speaker
Troublemaker
Driver of business value

So basically, after almost two months of doing it, I still don’t have a very clear definition or elevator speech to give someone :)

Something I have noticed is that I seem to be a bit different to some of the other Agile Coaches I have met in the past. Specifically, I come from a very strong developer background and still keep one foot squarely planted in the technical arena. I also have spent a lot of time studying (formally and informally) various aspects of business, economics, operations and project management, as well as organizational behavior. So in short, I feel comfortable running the organizational gamut. Not all coaches are like this, but instead specialize in some area, and likely have deeper knowledge and understanding within a particular arena.

My personal philosophy driving my knowledge portfolio is to be a jack of all trades, master of a few ;) At the end of the day, the dev teams are the folks actually doing the work to deliver value to the business and if I can’t interact with them on their level I feel I won’t be as useful and may have trouble gaining their respect and building trust. Just as important however, is that those dev teams are operating in a business or enterprise that care about many other things. If I can’t speak that language and advise on those topics I may not be as effective in facilitating changes, building bridges and closing gaps.

For me, I find having this breadth is important but maintaining an appropriate depth is of equal concern. In some cases it is good enough to just be aware of a topic, in others you need to be able to hold an intelligent and informed discussion about a topic, in yet others you need to have a working, practical level of knowledge. Experience will help you figure out what works best for you and the type of work you like doing.

So what is the point of all this?

If you are thinking about bringing in an Agile Coach, spend some time thinking about what your organizational objectives are, but realize you may need some outside perspective on what it is you are trying to undertake. In my experience many organizational objectives are connected and it’s usually impossible to just tug one string without changing the entire tapestry. Therefore I would tend to start with a generalist who can also help at the team level. Review and revisit your agile adoption/transformation routinely and bring in specialists as needed.

Freight Trains and Software Teams

2010-08-18T11:24:00.000-05:00

So what do freight trains and software teams have in common? If they don’t get a little slack every now and then, they wont ever go anywhere!

Something I’ve been doing with my teams for a while is adding “slack action” between iterations. I’ve found that adding this time helps with code quality, planning, reflection, morale, responding to adhoc requests, and a slew of other things.

One metaphor I’ve used when describing this idea to others is that of a freight train pulling its cars. Rail cars are loosely coupled to one another, leaving a little slack in between each one. When a locomotive starts moving forward, the slack causes the first car to be jerked forward, which in turn jerks the next car, and the next, on down the line; each car using its own momentum to help get the other cars moving. Finally, the train actually starts moving down the line as a whole. This jerking between cars is know as “slack action” and without it, freight trains would never be able to move. In fact, without it, the engine’s wheels would just spin and literally burn through the track.

I find the same to be true with software teams. Too often I’ve seen or heard stories about teams that get burned out from doing too many back-to-back iterations. This is especially true of environments where software development is ongoing, such as “maintenance” teams or organizations with continuous program delivery. The problem here is not the ongoing nature of software development, in fact I quite agree that ongoing/continuous is a great fit for software. The problem is a human problem, in that sometimes a team just needs some time to breathe and mentally shift gears for a while.

I propose that one solution to this problem is to give a team its own version of “slack action”, or a gap of time between iterations. This is more that just a retrospective and iteration planning time. I’m talking on order of multiple days. During this time the team can focus on other aspects of their product, their craft or themselves instead of delivery delivery delivery.

Here are some rules of thumb that I use for providing slack:

Keep iterations between 5 and 20 days.
Try not to start an iteration on a Monday or Friday.
Use a ratio of about 1 day of slack for every 5 days of iteration.
Keep scheduled planning and reflection times and activities.
Use a minimum of 2 days slack. (This is because most of my best ideas have not always occurred to me during the scheduled planning or reflection times, but instead in random places like my bed, or the shower, where generally the rest of my software team is not :)
As with anything else, adjust and adapt as necessary to the needs of the team and the context.

One issue I’ve run into with pitching this idea to “management” is the misconception that slack action is just unstructured playtime or “days off”. I argue that, in fact, it is highly structured, but in a more guided creative way rather than a controlled deterministic fashion. I then politely explain that we are not off, and proceed to list the activities that can and are going on during this time.

Some slack action items include:
- Allowing the team to work on pieces of the project that were in need of refactor, but that were not able to be cleaned up during the iteration.
- Professional development activities (book club, katas, applicable R&D)
- Respond to adhoc requests (that were pushed out of the iteration because we *knew* we had slack time coming up)
- Planned Retrospective, Iteration & Release planning
- If there is truly nothing else to do, the team can always start the work for the next iteration (while I can’t think of a time this has ever happened, it makes “management” happy to hear it :)

I know there are other ways to achieve this, but this is one way I’ve tried that works in my environment. As always feedback and ideas are welcome and appreciated!

Agile2010: Day -2

2010-08-08T04:17:00.002-05:00

Well, I finally made it to a conference; and not just any conference, but the premier Agile conference for North America (and maybe the world?): Agile2010!

I decided I would show up a couple days early to check out the venue and relax a little before things got too crazy with whatever goings-on would be involved in the conference, and boy am I glad :)

Walt Disney Dolphin Resort Hotel

After a fairly uneventful set of flights from Omaha, Nebraska to Orlando, Florida (met a geologist and a grain accountant) and a Mears Shuttle ride to the Walt Disney Dolphin resort hotel (met a CS major from NC) I had arrived at the venue. So far so good. The grounds and public areas of the hotel were quite nice and everything you would expect from a Disney resort. The hotel employees were very friendly and extraordinarily helpful. Inside the room, there was nothing special, just your standard two-double-bed room with a bit of extra space (closet, separate sink area, and a coffee area). The furniture, your standard hotel fare, and the colors in the room seem like they were taken from a toned down Miami Vice episode...and the air was...moist, even though I could hear the A/C running, but I guess that is hard to avoid in Florida.

I dropped off my stuff, and made a quick call home, then set off to find the hotel lobby bar as the twittersphere had been abuzz with other conference attendees meeting up there. Within a matter of minutes I meet half a dozen new folks whose names slipped immediately off my Teflon brain. After a short while, Lisa Crispin strolled by informing us of a larger collection of folks downstairs at the swanky Bluezoo lounge, so we all moved on down. After another round of introductions which are also lost due the the ever-thickening coating of brain-Teflon, I realized that most of the folks I just met were people whose books or blogs or tweets I've been reading for over a year; just hanging out like old friends (because they are!). After a bit a few of us decide to go out to forage for sustenance as we hadn't eaten dinner yet that day. We wound up at a Japanese sushi & karaoke place that had good food, and prices that would also reflect your likely expectations of a Walt Disney resort...ouch!

The evening continued on this way, meeting new people, talking, laughing, & sharing stories; some professional, and some a bit less and some a lot less.

My overall impression so far? Great big fun, a bit clique-ish, but still very friendly. What an awesome community to begin being apart of!

Here's looking forward to tomorrow!

An Academy for Software Development?

2010-05-23T16:06:00.001-05:00

So I’ve been poking at this idea of an ‘academy’ for Software Development for a while now.

The rest of this blog is actually an expanded version of an email I sent Corey Haines. While we apparently had our ideas independently he wrote up a blog on this a while back and I feel we are in strong alignment on the subject in general.

What’s an Academy?

This Academy would be created in the same style as those setup during ancient times. It would be a center of learning and craftsmanship for the field of software development. The goal would be to create a place where apprentices would come to learn a craft, but also a place where journeymen would stop to work with various masters along their journey as well as a place where itinerant masters could come to experiment with new ideas, meet other masters and influence journeymen and apprentices. The Academy would also act as a hub for educating the community (the businesses that use software or software development services).

What would actually go on there?
Another key principle that I would want an Academy to incorporate is the concept of “it takes a village”, by which I mean incorporating and training the other crafts of software development besides Coding (such as Testing, Interaction Design, and product development facilitation). I also really like Corey’s idea about teaching new comers to the field its history, important names & thinkers, and classic and modern concepts.

For apprentices and journeyman other related topics may also be needed. While I’m still undecided on this, providing opportunities for advanced education in math and some science or engineering fields may be useful. However, I also think exposure to seemingly unrelated fields of study such as Journalism, Anthropology, Psychology, Economics, Rhetoric and perhaps others could also be useful. The key would be to ensure that these topics were always tied back into how they relate to software development or the environments in which software development is used.

Who would this cater to?
While I think the model will work with anyone with the talent, drive, and capacity to be a good software developer, at this time I would prefer to target high school seniors. This is mostly because I’d like to demonstrate that we don't need an official “college degree” to be great developers, just good training and experience (provided by the field for the field?). We’ve done a fairly good job showing that the requirement of a 4-year degree is rather silly and has been routinely proven pointless for business software development.

Another, smaller reason is because I have witnessed that a significant amount of unlearning must be done with most folks coming out of a normal Comp. Sci. or MIS program. This is overhead that can certainly be overcome but does require additional effort. Though any capable entrant should not be ruled out.

Where would you get money for all this?
Part of a problem of running an Academy would be how to fund it. I like Corey’s model of structuring a school as a craft-based workshop that sells it’s services at a lower cost, but then is able to provide training through hands on, real-world projects. I had also toyed with the idea of getting funds via normal educational routes (student aid, loans, etc...) but decided against that due to the constraints those place on the whole educational experience as well as the ability to adapt that experience. However, it might be possible to partner with more progressive companies or traditional academic institutions that are further down the path of really groking software development.

Mind you, everything I’m outlining here is the pie-in-the-sky idealistic goal. The entire undertaking would have to start small and iterate, adapt, and grow.

What about degrees and accreditation?
While I’m not particularly fond of degrees or accreditation, I know that businesses still look for and care about them so they probably need to be accounted for, at least to begin with.

I’m still rather fuzzy on how either would work, but my initial idea is to replace the concept of a “degree” with a “portfolio-transcript”. The idea is to provide something of a history or pedigree of what work was done, at what level, for whom and under what master’s supervision. The goal is to provide a much richer contextual view of what was learned and experienced.

As for accreditation, I would prefer to scrap it all together and replace it with some kind of endorsement model, if with anything at all. I would like to see the outcome of the Academy able to speak for itself. In lieu of that (or to start with?), perhaps endorsement routinely given by various people or organizations for specific things would provide more transparency and information about what is actually going on and what it is worth.

Signing off...
So this whole thing is still sorta in its warm liquid goo phase in my mind. But if anyone else out there has thoughts or ideas lets go through them! If you are involved in getting something like this or related to this going, please let me know, I’d love to get involved :)

Agile Community: A little less talk and a lot more action

2010-04-06T20:44:00.001-05:00

So I've been reading a lot of blogs lately (like this, and this, and this and this and more...) involving the drama surrounding various certifications and alliances and how this all impacts the agile movement and community.

Where I stand...

Personally, I believe certifications should endorse the fact that an individual has demonstrated they can apply some concept successfully (even if only at a basic level). How does a community certify its members on the application of guiding values or high-level principles? I think the root of the problem is that you can't. Something else is needed.
We need...

...a little less talk

The good...

Certifications do promote interest in the topics we, the community, hold dear; they are also providing some level of basic education on these topics; and they will help spread the values and principles by injecting these good ideas into individuals who may attempt to apply them where they work, and perhaps become more involved in the greater community.

The bad...

The certifications don't certify much. They may also attract trainers that are no more than terminology resellers. As a result, employers may make poor choices, yet continue to not understand the underlying causes of their problems. We fear a misplaced trust in something fragile or empty by practitioners or business consumers of software development services.

The reality...
As many have already stated. This <insert mode of transportation here>has already <insert method of departure here> So what can we do?

I feel the basic problem is that businesses want easy ways to make choices about things they don't fully understand or value. This is what causes organizations to require things like degrees, certifications, arbitrary years of experience, knowledge of a plethora of specific (yet easily trainable) skills, and a whole bunch of other things that don't really indicate someone knows anything or will be effective, productive, passionate, etc... etc...

We need a stop gap measure...

Given that the certs are here to stay (at least for now) we need our community members that don't despise certs and truly understand the concepts and are passionate about the community to be the trainers leading these certification classes. These trainers should know, and discuss during training, the shortcomings and realities of the various certifications. Allow these people to reduce the impact of "the bad" while propagating "the good". We will owe them a debt of gratitude while the rest of us get our acts together!

Perhaps a way to drive this is with some type of grass-roots, community driven "white list" of endorsed trainers (like this?)? I would feel a lot better about getting a training class (aka certification) from John Doe Trainer if I saw he was endorsed by folks like James Shore, George Dinwiddie, Cory Foy, Brian Marick, or Robert Martin. Seeing a bunch of substantial positive reviews from other folks that I see are active in the community via blogs, conferences, events, etc. wouldn't be a bad either!

...and a lot more action

What we really need...

We need to start providing something better or more useful or more meaningful than certifications (or degree programs). We need a better way to select, produce, and sustain quality software development professionals. We need to do a better job choosing folks that have the character and talents we believe necessary to be life-long craftsmen in our industry. We need to imbue these individuals with the skills, knowledge and theory that will lead them towards further experience and wisdom. Finally, we need a better way to provide consumer education. Our community of professionals need to be tasked with educating and demonstrating to "business" the value of doing things the way the software development community finds to be the most practical and effective.

Areas of focus...
In short there are three broad categories we need to improve on as a software development industry and community.
1. Entrance/Selection
2. Continuance/Sustainability
3. Consumer Education/Support

Entrance/Selection
We need to raise the bar when it comes to new professional "coming out of the pipe". Perhaps we need to revise (replace?) the academic programs that simply crank out CompSci and MIS majors that get most of their useful knowledge their first few years after college? Maybe we need more shadowing or apprenticeship style programs? Maybe we need more boutiques and medium-sized dev shops to align and realize the real competition is not one another, but rather the the pervasive lack of understanding both within our industry and outside, in business regarding how to value our trade?

For example, I would love to see an apprenticeship-style dev shop that auditions high school students that show interest and promise in the craft. Get this shop endorsed by some community leaders and active members, then let these new professionals grow and flourish. Get them involved in the community through events, conferences, writing, speaking all the while learning about and developing outstanding software products.

Bottom line, if we think the system that produces new professionals is broken, we need to fix it. If we deem it can't be fixed, then we need to build a new system.

Continuance/Sustainability
Once we have raised the bar on selection and have systems in place that are producing high quality software professionals, we need to make sure the learning, sharing, and experience doesn't stop. After all, these folks will still have most of their careers ahead of them.

I strongly believe that any field which has the potential to outpace its individual members with useful and applicable information needs to do a good job at "continuance"; be it medicine, law, education, whatever. I personally feel most of these knowledge-based fields don't do a good job at this now, and the software profession is no different. I think what makes these kinds of fields advance more quickly as a collective is their complex social natures and the fluidity of mental capital that drives progression in these fields. We need something just as fluid to keep up. I believe that conduit is community. We already have it in a fledgling state, and using technology it's even more accessible than it has ever been. But we need it to be bigger, better, and more adaptive. The community needs a touch more solidarity, if only to be proud to be part of something greater than ourselves. Continuous involvement in, and acceptance by the community should be expected, and a driving force of which individuals feel comfortable staying within the profession. It would also wind up being something looked for or appraised by possible consumers of our industry's services.

Consumer Ed./Support
Here is the kicker. We perform to how we are measured right? At the end of the day this could all be for naught because we can't all be altruistic idealists...at least not all the time. We get "measured" by getting jobs and getting paid, so ultimately the people that employ and pay us dictate what criteria they will make those decisions on. So we want them to understand and think like we do as much as possible, so they can make the best decisions possible. If we are right, all the altruistic idealistic stuff pays off and we all have better lives with jobs and pay :) If not, at least we now have a supportive adaptive community that will figure out how to change next.

The best way I can think of to educate our consumers is to (possibly) take a hit and show them that it works. This is sort of like needing to slow down to speed up. This could take the form of working with smaller companies to help make them more competitive. This could mean living what we speak, and as community members, voting with our feet. This could be difficult, but in the end if we are able to show enough consumers what it's like to really understand and value their software assets we will be in a much better place.

The call to action...

Ultimately this is our community, whether we consider it to be agile, scrum, developer, tester, whatever...it's not anyone else's job to make it better but our own. If businesses are requiring useless pieces of paper because they don't understand what we do or how to value us, who do we have to blame but ourselves? Businesses know they need our services, now more than ever to remain competitive in our shrinking global economy. We owe it to them and ourselves to teach them how to value us and thus provide our own community with the mechanisms that will ensure businesses we can deliver the competitive value they need.

I hope it is obvious that I do not purport to have the answer. I don't believe any one person does or will. I hope to see a discussion start that will lead to an answer that the community grows and evolves. I don't believe agile has outlived its usefulness or is fading away. I believe it is simply going through the growing pains of adolescents. We can do this...we just need to start!

A Simple Algorithm for Agile Adoption

2010-03-29T21:35:00.004-05:00

Here is my simple algorithm for anyone attempting an agile adoption:

1. Stop doing what doesn't make sense.

2. Start doing what does.

(Of course I believe you can't do either effectively with out continuous learning and reflection!)

Below is a diagram I've used to explain some of the many different terms generally flung around under the umbrella of "Agile" to help folks just getting started.

About the diagram...

[DISCLAIMER] I know most of the methodologies do not necessarily build off Scrum "officially" and, in most cases, were developed on their own, but Scrum seems to have distilled down the basic incremental, iterative, reflective processes they all have in common, leaving various details out (intentionally) so teams could adapt the processes to their situation. I believe XP, Crystal, and most other methodologies add that detail (although many could argue that Crystal is also a framework).

As for Kanban, I'm more than willing to take and make corrections on this as at the time of this writing my knowledge of Kanban is very weak. I believe it can stand on its own, but I've also heard of Scrumban, so it seems it can also be used as yet another implementation of the Scrum framework? Wouldn't mind some education here :)

Consider this (please!)...

It is important to understand the problems Lean, Agile, and all the various methodologies were intended to address before going off and attempting to implement a solution. It is important to educate from the bottom up. I've seen and heard of more problems or failed "agile implementations" because the powers-that-be knew something wasn't right but just wanted to adopt or buy into a methodology or process that would fix it.

Also, most things must actually be tried first, before claiming "they wont work here"...they might not, but you wont know how to tweak them to get them to fit if you just stand around talking about what wont work. Generally more information is gleaned from action than inaction, theory, and speculation.

How agile are we now?
In the diagram, I make reference to using the 4 values in the Agile manifesto as a sliding scale. I first read this idea somewhere out in the blogosphere, but cant remember where; but I'd like to think that it's a great place to start when considering how agile anything is; from an idea or process to a project or organization. Here is what that sliding scale looks like to my mind's eye:

Now you can use this to evaluate all kinds of things. You can ask yourself questions like:

Is this process focused more on individuals and interactions or on processes and tools?
Does this organization more value working software or comprehensive documentation?
Does my project rely more on customer collaboration or on contract negotiation?
Will my idea help more with responding to change or does it simply follow a plan?

Remember, the manifesto doesn't say the stuff on the right is bad or unneeded, it just says that things which are more agile tend more towards the things on the left.

Hope this may be useful to someone out there. It helped me just to write it up :) I would certainly appreciate any thoughts of feedback about the diagrams or opinions in this article (especially with regard to Kanban!)

The truth about the '7 truths about Agile and Scrum that people don't want to hear' that people don't want to hear :)

2010-03-09T21:57:00.001-06:00

I was reading through the intro and first two parts of Kai Gilb's seven part series entitled "7 truths about Agile and Scrum that people don't want to hear" and I had a strange sensation of yes-but-no.

The yes feeling comes from the very general underlying theme of the articles. I'm a big proponent of having specific, measurable features to deliver in a software product and I agree that it is important to ensure stakeholders are getting a good value for the cost. Further, I believe strongly in developer creativity and that software development is in general a creative social process.

So in general I agree with all the stuff that Kai seems to be saying is important and that we should be doing. So where did my but-no feeling come from? It's the blaming of agile for these shortcomings.

Before going on, I'll state some of my opinions about agile and scrum. I see agile as a general philosophy or a mindset for developing software . The agile manifesto (also referenced by Kai) lays this out using four values and twelve principles, but at the end of the day its about programming in code to create a deliverables. As for Scrum, I believe it is merely a framework that gives a team the ability to adhere to agile values and principles, but again, Scrum is about actually programming within a controlled context to create a given product or feature set.

I guess the key here is that neither agile nor scrum addresses much if anything about gathering or defining requirements, only what to do once the requirements are obtained. Perhaps this is Kai's point, but is this a truth people don't want to hear? I don't think so. It's true that requirements gathering and definition is still important, just as much now as they always have been, but I believe agile doesn't address these issues because it was not intended to.

This assertion to me would be akin to claiming that agile and scrum don't ensure developers write clean code, use best practices, or have appropriate architectures. Well of course they don't! The principle "Continuous attention to technical excellence and good design enhances agility." doesn't explicitly define clean code or writing tests first or any other best practice, nor should it.

By the same token, the princple "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." doesn't explicitly define valuable or how to determine value and, again, it shouldn't. Please do not misunderstand that I don't think this is important.

I do agree with Kai's claim that use-cases are not the same as specific functional requirements, but again I would say they were never meant to be. I do like the small examples of what I assume is the Gilbs' Planguage tool to define requirements, but that would be an example of a tool used for the job it was intended, not a shortcoming of agile or Scrum.

After reading and thinking about Kai's articles, I felt like I was missing something; like I didn't get the title or many of the claims (maybe I am as I've only read 2/7 of the series, but at this point that's all there is). Was it just intended to be a blog to attract attention? I wasn't sure because to me Kai was stating a lot of the obvious. Perhaps a better title would be "Dont forget to gather and define the requirements for your software project before implementing it with scrum"? (probably too long)

Does your company have Secondary IT Operations?

2010-02-14T16:03:00.001-06:00

I've been thinking about an issue that has probably been around for a while but will continue to grow as more types of businesses continue to utilize IT to sustain and grow their operations in an increasingly competitive environment.

The issue is that, traditionally, there have been two main roles for IT with regards to business function: Primary Operations or Support Function. However, I believe a new, third role has emerged. I've dubbed this role simply Secondary Operations as I haven't yet found this idea described by any other term yet.

The two traditional roles of IT as a business function:

Primary Ops of a business are what that business does to bring home the proverbial bacon. A business could have many Primary Ops if multiple, internal business functions are equally important to its competitive sustainability and growth. Within the context of IT we may think of Microsoft, Google, Apple, or even Amazon as companies with an IT function that is a Primary Op.

Support Functions for a business are those functions a business uses, either internally or externally, to ensure the routine goings-on of its Primary Ops. We often find these functions to be things like Human Resources, Legal, Accounting, and even IT in many cases. Examples of using IT as merely a Support Function are: buying a store-bought package, outsourcing a custom software solution, hiring third-party consultants, or even staffing a small group of IT employees to react to the business' needs.

What is most notable about these two traditional roles is that they tend to be intentional choices for the business. A business with Primary IT Ops knows that, and understands the importance of its IT function as well as how to valuate and make trade-offs for it.

The emergent role of IT as a business function:

Secondary Operations differs from these traditional roles, as I believe it evolves over time, starting out as a Support Function and gradually growing in complexity, integration, and importance. It still shares some characteristics of a Support Function because it has no place in the organization without the existence of the Primary Ops. However, it also has similarities to Primary Ops in that it has grown into a significant internal business function that is part of the long-term strategy. In short, a business now needs to understand and treat an IT Secondary Op the same as any Primary Op with regards to valuation and trade-off decisions to leverage it as a competitive advantage.

How do you know when a Support Function has grown into Secondary Operations?

There is no black-and-white answer or nice, neat checklist. However, here are some signs that a business' IT function is moving towards or has reached the status of Secondary Operations:

The IT function cannot or should not be externalized to a third party.
The IT function is of a significant size/cost with proportion to the rest of the company.
There is significant business risk associated with the failure of IT systems.
Removal of the IT function completely would degrade Primary Ops significantly over time.
Lack of an IT function would eventually result in the inability for the business to sustain a competitive advantage in the market.

So... Why is any of this important?

The way a business treats a Primary Operation versus a Support Function is very different. The level needed for understanding business value, utilization of industry best practices, and proper management techniques is lower for a Support Function than a Primary Operation. Additionally, the long-run cost (or debt) of routinely making short-term trade offs for immediate benefit are less important and make a less significant impact on the company as a whole.

Contrast this against how a company treats its Primary Operations. Much time and effort is spent understanding the details and subtle interplays to maximize business value. Much more structure and attention is given to best practices and management techniques. This does not come as a surprise, because a company that did not do this would eventually lose its competitive edge.

So what happens when an IT function becomes a Secondary Op (which should be treated like a Primary Op) but continues to be treated like a Support Function?

Depending on many internal and external business factors the outcome could be as severe as the company eventually failing (or being taken over) or as moderate as the business never realizing its full potential within the market (limping along with a reduced value).

Luckily the solution is easy enough:

First - Non-IT companies should routinely assess the usage of their IT function, perhaps using the "5 signs" above as a guide. The pitfall here is that the company's leadership needs to be honest with itself. Sometimes it can be difficult for a company's leadership to admit that IT has evolved into something almost as important as Primary Operations, especially if they have been with the company for a while, and especially if there are non-IT/operations execs :)

Second - Once the leap has been made from Support Function to Secondary Operation, start treating your IT function a lot more like your Primary Operations. Pretend your IT function is a mini-Primary Operations IT firm whose sole customer is the rest of the company. This may mean that you have to bring in someone from the outside to help get it right. It also might mean that you may have to sacrifice a little upfront to ensure this transition goes smoothly, but that's okay because sometime that's what needs to be done for long-term strategic investments. Lastly, a organization may have to impact existing (and sometimes operational) procedures to allow for this new growth of IT. It may take some getting used to, but will eventually pay off.

A note of caution - The more unlike an IT company the non-IT company is, the harder the above two steps seem to be. There is some type of "degrees of separation" idea here, but I'm not sure what all the factors may be yet.

Here are some initial guesses:

Class of work of Primary Ops vs. IT (blue collar vs. while collar)
presence of unions?
Geographic dispersion of the company's functions
High variance of education levels among employees
High barriers to entry to the market
Current technology use/prevalence in the primary ops industry
(years with IT / years without IT) ratio ?
Amount of turn over throughout organization
Average age of employees?
Hierarchical leadership in Primary Ops
Levels of trust and communication

Of course, everything really is more likely to depend on a company's given culture and leadership.

Anyways...this has been an interesting mental exercise for me. I'd be very interested in any feedback or other opinions, especially people's experiences with this issue :)

What is software "maintenance" anyways?

2010-01-22T11:49:00.001-06:00

Something that has been beginning to annoy me lately is the term "software maintenance". Why? Because the metaphor of maintenance is meaningless to a technical person and implies too much meaning, that doesn't fit software, to business people. What are these oh-so-bad implications? Ever hear any of these?

- "Maintenance projects can't use, or are not a good fit for Agile."

- "[Jane/Joe Programmer] is a maintenance developer."

- "80% of a (software) project's costs are from maintenance."

- "Maintenance funding is a corporate expense." (vs. a capital investment)

- "[Project X] is in its maintenance phase."

Some of these sound important, like project funding or costs, and others sounds absolutely ridiculous.

First, let me define maintenance using my favorite definition:

"The work needed to keep an asset in a condition that enables it to retain its original value or service potential. Maintenance does not extend an asset's normal expected life." -- [Here is the original source I tweaked it to be a bit more specific.]

Next, let's take a look at the kind of tasks one might see on a so-called maintenance project.

1. Bug fixes

2. Performance tuning

3. Infrastructure/Technology upgrades

4. Refactoring (improving code without changing its function)

5. Enhancements and changes

6. Adding whole new features

After reviewing the list above, a few things jump out at me:

First, only items 1-3 fit squarely into the definition of maintenance given above.

Second, for every maintenance project I've ever been on, 60%-80% of my time was spent on items 4-6.

(So why do we say that 80% of a project's costs are in maintenance when so much "maintenance" activity is not even really maintaining the product?!)

Third, (and most importantly) all the items on the list are things I do on new development projects!

My conclusion?

It's all just software development! I know this isn't exactly a great revelation to techies or anything, but it is important that this is realized, especially by managers and business folks. "It's all just software development" is the technical equivalent to "he's just not that into you". This realization frees the mind from the flawed metaphor of maintenance and all the wrong preconceived notions it drags along with it. Of course Agile principles sill apply; its software development! So-and-so is not a maintenance developer. So-and-so is just a developer! Software doesn't have a maintenance phase that is costly. There is simply a choice of whether to continue to add value to the business by enhancing the software or not.

A few caveats before I get flamed.

Yes, continually enhancing code can become very costly if corners are cut, test harnesses are not in place, and technical debt continues to pile up. Usually at some point, a critical mass is hit and, if the system is needing to be enhanced, a rewrite will be required. This brings on problems of its own that could (and maybe someday will) warrant its own blog post.

Yes, there is such a thing as maintenance for software, but I will assert that it is only items 1-3 in the list above. Those are the only items that simply maintain the software in its original intended state, providing its original intended value to the business.

So what is missing? If its "all just software", why do I like some projects and not others? What is the key differentiator?

Well, some projects I don't like because I inherited them and they were poorly designed or poorly written or dont have any tests, or seems like some amorphous blob attempting to suck out my soul. But you know what though, while these can be sluggish to wade through, there is also some sense of accomplishment in getting to make it all better! It is a different kind of joy than getting to design and implement a brand-spankin-new solution, but both are programming and both can be enjoyed for different reasons. So I dont really believe any of those negative aspects of Legacy Code are the key differentiator.

I think the real issue is something I have started calling the Development/Support Dichotomy, or DSD for short. DSD occurs when some piece of a software project is being used in production. The problem this causes is when something breaks hard and business stops or is severely impacted and the team or individual working on the project must stop planned work and react to unplanned work.

My next article will be more detail on DSD as well as ways to solve it. For now, can we all agree that true software maintenance is pretty narrowly defined, and not actually that bad? Could we further agree that, most of the time, what we are asked to do under the term "maintenance" is actually some other kind of on going software operations? (or even better, continued investment?) Great! Now let's get the business and management types thinking and speaking that way!

On Corporate IT Innovation

2010-01-18T01:00:00.002-06:00

So the place where I work is going through some sort of "innovation phase". That's not quite the right term, but I dont know exactly what the right term would be. I'll try to explain.

So we've recently been hearing from our CIO about innovation. Apparently we are wanting to do this. What confuses me though is that I'm not even really sure what this means.

What I do know is that we get "innovation emails" from the CIO. These emails are all examples of innovation that have happened somewhere else, and often not even in IT. The last one I actually read had to do with the guy that came up with the idea of "kids stay free" at hotels?!?

So you can imagine that these emails soon became the butt of many jokes around the proverbial water cooler, and more often than not wind up getting deleted unread (if you're reading this big guy, sorry, but that's the truth).

More over, all the emails (that I've read) were all what I would call Grand Slams. They are the kind of things that massively change something big; a business, an industry, a paradigm, our lives.

Are these the things we are being asked to produce? Probably not, but then what is the message being sent by these emails? I couldn't really tell you...though I guess it doesnt really matter as not too many people read them anyways...but what a waste; all those electrons :(

In my opinion, the outcomes of those emails are not what should be studied or sought after, but the environment that allowed them to happen. Sure it's possible that occasionally someone just gets a really bright idea that revolutionizes something. It's also theoretically possible that an infinite number of monkeys with an infinite number of typewriters will eventually write a Shakespearean play.

More often than not an environment that fostered and encouraged innovation is what allowed the innovation to happen. What type of environment is that? Glad you asked :)

- An environment free of blame and fear, and full of trust

- An environment that allows for creativity

- An environment where continuous small improvements are appreciated

- An environment that encourages people to learn, reflect, and grow

- An environment that values diversity of thought

- An environment that embraces emergence and evolution

- An environment where change is considered an opportunity, not a threat

- An environment (for software development) where more is measured than just delivery

I could probably go on, and before you know it we would all be singing koom-by-ya around a campfire and giving each other back rubs...why? Because all those things are that squishy leadership/management/organizational behavior stuff that is hard to measure and impossible to mandate, yet necessary for individuals to flourish.

Most importantly these things take time. Some executive cant just decide "We havent innovated in a while boys! Lets do that now!" It takes someone with vision and faith, and I don't mean religious faith, but the same principle applies. Belief in something that is hard (or impossible) to measure, but you just know is the right thing to do.

I'm not saying that everyone should just do what ever makes them feel good. I mean heck! There is a business to run right?! But it is possible to put mechanisms in place that revolve around certain ideals that, over time, build the kind of environment that allows for innovation.

So stop trying to innovate or be innovative (and please dont create an "innovation award"...yes we have that too >_>) and take a good look around and ask yourself what small thing can I do today that would help build an environment where people will be able to innovate tomorrow.

It Has Begun...

2010-01-02T18:48:00.001-06:00

Hi, I'm Matt Barcomb and for better or worse I've decided to add my $0.02 to the blogosphere.

I plan to use this blog to talk about issues revolving around software development that interest me. Currently such topics are (in no particular order):

little-'a' agile
alignment between software development and business
software testing & design
leadership & communication
non-technical organizations with internal software departments
software craftsmanship
education/training of software practitioners
culture building and transmission
some occasional random rant, most likely vague and ideological

Some background (semi stream-o'-consciousness)...
I'm married to a Brit who lovingly introduced me to stinky cheese, mouthy red wine, fresh vegetables, travel outside the U.S. and <mushy>has given me more that she will ever know.</mushy> I've also got some pets: 2 dogs, 2 cats, and 1 son ;) We pretty much always have a blast, so thats< really cool.

I was introduced to programming in 3rd grade (Apple basic ftw!) and started programming on my own in 5th grade (GW Basic ftw!) and have just sorta always been doing it ever since. However, I've been a *professional* software developer for just over 11 years now. Spent about 6 years at a couple of small, boutique consulting companies in Kansas and for the past 5 years I've been here in Omaha doing programming for the railroad...oh, and I also have been teaching some IT and business classes in the evenings at a local college since i've been in omaha.

I've recently (months) changed paths from programmer to manager. Why? Heh, sometimes I wonder myself, but generally because the bigger, fuzzier, and more variable the problem the more I like it. Also, because the way I'm wired is to get involved where I see a problem I want to change and software management at my non-tech transportation company was where I saw the bigger, fuzzier, more variable problem :) Plus, I can always program on the side on my own time...kinda hard to do that the other way around :P Who knows...we'll see where this takes me for now. If I don't like it I can always become a guitar playing scuba instructor back in Florida!

As for hobbies, just about anything interests me initially enough to read and investigate and conversate. Oddly, given my tech background, I'm also strangely intrigued by agricultural things...probably something about the growing/building/creational aspect or something. I like almost anything outdoorsy especially involving water, but recently activities haves been mostly walks and camping (and there isnt a lot of water around Omaha that is worth being around). However, I'm thinking about getting back into scuba diving (yes, in Nebraska, and *no* I dont think it sounds silly) and have been thinking about getting sailing lessons. There is also this acoustic guitar in my basement that taunts me to learn how to play it >_<

What else...well, I'm from Florida, but currently live in Omaha...yeah...don't ask...I'm not overly happy about it, but it is what it is for now :P I was in the military for a few years (FA w00t!). I went to K-State where I did comp-sci and MIS. I eventually got my masters in project management with a concentration in operations research. No I didn't get my PMP 'cause I dont think the PMP is worth the time, effort, or money when applied to the software industry, though that may be changing with PMI-Agile...we'll see...I can always get one later.

As for my blogging, as you may have seen, I'm not overly fond of capitalization, and the apostrophe and I are on shaky terms as well. I do hope someone gets something out of this besides me, but me is mostly who I'm doing this for...dang it...i mean; me is for whom I am doing this (yeah, that just sounds weird) so I'm likely not following the right blogging rules or whatever, but if you've made it all the way down here, I hope you were as entertained reading this as I was writing it :D