The Other Reason I Stopped Blogging

I blogged a fair amount (for me, and relative to many colleagues) before I went into consulting and continuing on into my time at Leading Agile -- right up until it became mandatory. The company had a desire to have more people write more content more often so it became expected that everyone be involved. The implementation was a well intentioned across the board writing calendar; a rotation for every consultant to write a blog post when his or her week came up.

That killed my writing motivation. 

I stopped writing. Corporate writing scheduler: "Write something!" Me: "Uh, well, no, and why don't you go pound sand." That's the lack-of-autonomy and lack-of-purpose (ref Pink's Drive) triggers for me. That was part of my writer's block.

Then I got over that (not wanting to comply) and began to think that I just couldn't write on schedule. I could write only when the inspiration hit me. Creativity can't be scheduled. There is some truth to that for me. Much of my writing was in response to either (a) a question someone asked me or (b) an answer someone gave me in response to a question I had. Even in the 1st case, the writing was a thinking tool. It helped me think though how to articulate a point or express a concept for the benefit of others.

It just now hit me that my writing also scratched the itch that Pink in Drive called mastery. As long as I was learning, I was writing. As long as I was learning how to better help others learn, I was writing. 

There came a time when my learning in some old areas slowed, and writing declined. And my learning shifted to a couple new spaces and before I figured out how to write about those things, I changed employers. 

I just discovered an important point about why I didn't start writing again in that new role. I discovered this while reading John Cutler's "TBM 9/52: Writing Culture Challenges". John wrote "A writing culture is a reading culture and a feedback-giving culture. A write-and-reading-and-feedback-giving culture requires time to think, process, and respond. Writing isn't the end goal: thinking and improving is the goal."

That's what happened when a writing schedule was put in place at Leading Agile -- writing was the goal; marketing was the goal. Well, the company's leadership might have known that writing was to develop thinking, but that's not how the expectation was expressed.

Then in the new role, the work-load set it. John says that you don't get a writing culture in "Conditions of high reactivity, cognitive load, and passivity. No one has time or energy to think, ask questions, and process. Too much energy goes into doing and reacting."

John goes on: "…you can't just 'switch' to writing culture. It has very little to do with the writing and everything to do with the preoccupation with busyness, optics, power, control, and tempo. ... Work-in-progess [sic], change-in-progress, and planning-in-progress is just too high to think." Yikes!

John gives some good suggestions, techniques in his article. Worth reading. But he doesn't tell you what to do with the high WIP, high change-in-progress problems in that article. I expect he has in some of his other articles that I haven't read. It's worth subscribing to his articles. 

"Value Stream Management is Human" Patterns

In spite of how others are redefining it to be something different, Tapping, Luyster and Shuker defined value stream management in 2002 as an 8-step lean process “for planning and linking lean initiatives though systematic data capture and analysis.” Basically, commit to lean, choose a value stream, map it, pick a future state, and create and implement kaizen plans. It’s improvement. And it’s a human endeavor. Too many people think VSM is about managing-the-work-in-the-system instead of improving-the-system.

Over my career I’ve noticed several approaches to value stream management:

“Unintentional” – Not done on purpose. In this pattern, no one is intentionally improving the value stream. Every org has a value stream whether they realize it or not, whether they think about it or not. This doesn’t mean that the organization is bad or that their value stream isn’t effective, efficient or optimized. Very talented managers could manage a value stream to great effect by pure skill and experience, not conscious of any improvement efforts. They don’t think about it. Others, however, don’t think about it and get “Value Stream Mismanagement”.

“Casual, ad hoc, decentralized and distributed” – This pattern is typified by teams doing their own retrospectives. There is little sharing of lessons learned across teams even though there may be attempts to catalog or share these. No one is driving improvement across the org.

“Intentional and distributed” – In this pattern, there is someone high up, often a CIO or VP, very much interested in process and improvement. This works well, particularly through lean, kaizen, the Toyota Kata, and the Coaching Kata. Multiple techniques/tools are often used such as A3 Problem Solving, systems thinking, and the theory of constraints. There are often measures and metrics, typically lean (flow) metrics. Kaizen moments and retrospectives are encouraged and expected throughout the organization.

“Agile Transformation / Agile Coach / Centralized” – In this pattern, there is an agile transformation initiative driving process improvement efforts. Such efforts are often time-bound, tied to the duration of the transformation initiative. Attention and efforts wane after a time.

“Biz Process Reengineering / Centralized” – This is another form of the “agile transformation” pattern but is more explicit around improving the value stream, and it’s likely much broader than just IT or software development in that it likely includes business operations as well. This might be led by a process reengineering group, expert or consultant and should involve business architects.

“Control” – I insist that value stream management absolutely, chiefly, and primarily includes the concept of improvement. However, some organizations are more concerned with control and reporting of work progress, percent completion, and due dates than with improvement. Not much improvement happens with this pattern. (I first labeled this pattern “PMO”, but decided that wasn’t fair. PMOs didn’t have the best reputation in the heyday of the agile movement. Perhaps that’s changed now, and I’ve seen many PMOs adopt agile and even drive agile transformations with some success.)

The best approach to take is “Intentional and Distributed”.

My purpose for writing this was twofold:

• I want everyone to understand the true point of value stream management, which is continuous improvement. So many people (platform vendors especially) are making it out to be something else entirely.
• I hope more people will be intentional about improvement efforts. Perhaps they’ll recognize their pattern and consider other alternatives.

Context is King: Why I stopped blogging

A lot of the articles I read about agile don't describe the context in which their advice applies. The authors don't take the time. Many authors aren't even aware of their context. They haven't seen enough different kinds of agile implementations to understand that their advice doesn't apply outside of their context.

Writing was easy for me when I worked for Leading Agile because we had a well documented and limited context. Grossly oversimplified, companies who wanted predictability in their software development efforts were attracted to our offering. We had one message, one services offering, and one target market.

Everything on our blog and everything on our website and every talk given at a conference adhered to this single context. That context was explained so much that it didn't have to be explained every time. Yet every blog post pointed back to that context in some way. It all dovetailed together.

Every aspect of agile, of teams, of org structure, of metrics, of forecasting, of planning, of funding, of portfolio management, of roadmapping, of prioritization, and on and on needed to be explained in terms of that context, so there was lots of fodder.

I stopped blogging when I left Leading Agile because of this need for the applicable context to be explained. When I left the firm I left the context. I've seen agile done many different (valid and effective) ways before my time at the firm and in many ways after. For which context should I write? How should I explain the applicability of my opinions? 

I don't run my agile programs now the way we did at Leading Agile. It's not because I didn't believe in that approach, didn't find value in it, or can't do it. In fact, I like that approach a great deal. But it doesn't apply to my context now. Predictability isn't my driver. 

This isn't anything new. People have been arguing over agile since the 90s, with much disagreement stemming from the unique and unstated context in the mind of each author and consultant.

What triggered me to write this was some things John Cutler wrote. "…the key to putting bets in motion is to tailor your working approach to the bet." How you develop the idea of the bet and how you implement the bet should vary based on the nature of the bet, the uncertainty of the opportunity, the uncertainty of the solution, urgency, size, allowance for failure, level of collaboration needed, and etc. There's no single agile prescription that's best for every kind of bet. John explains the anti-pattern of when companies "lack any sense that the things they are doing have different characteristics. They try to use a mono-process for everything." "Impact: picking less-than-optimal ways of working." And "Mono-process kills companies." 

Don't bother trying to do agile "right" and don't fret over other people's advice when it doesn't match your context.

Sprint "Commitments" are an Amortized Death March

Matt's tweet is provocative: Sprint "commitments" are an amortized death march.

If sprint commitments lead to a death march, something is wrong in your organization. Sprint commitments could be used by poor managers to browbeat the team.

Hey, you guys committed to this. I expect it to be done!

Not good.

The risk of a death march, however, is not the reason to not have a strong sprint commitment. You can (possibly) fix that problem. You can (possibly) have good, enlightened managers. Besides, there are many ways to use Scrum poorly. Should we throw out every misused practice?

No. But sprint commitments are dubious.

It's not the sprint commitment we are after. It's not what we really want in the end. It has no value on its own. What we're after is that thing we hope to get from having the sprint commitment. What we hope to get is a team that is committed to each other, working together to finish what they set out to do. We hope everyone works on what we agree to work on rather than whatever darn thing anyone wants to do. We hope to not have unfinished work at the end of the sprint.

Sprint commitments → no unfinished work at the end

Too bad this is a fallacy. The fallacy is that for each desired outcome B there must exist a cause A.

A → B

In complex adaptive systems it doesn't always work out that way. I might even say it rarely works that way. Whether the sprint goes well or poorly, there are side effects of such policies. But this post isn't about the side effects. For the manager, though, when the sprint goes poorly the best possible outcome is...

Darn, this is harder than anticipated. But I committed to getting it done. Guess I'll put in some overtime.

If what is committed to is generally kept low (appropriate), pace should be sustainable over the long run even with some rare overtime. When appropriate overtime does happen:

That stunk! Not doing that again. Let's commit to less and plan better.

In this way, sprint commitment should drive careful planning.

But is careful planning in batch necessary or is it waste? It can be useful in some contexts, but bogus in others. What's the point of a sprint commitment if you are committing to something very small, knowing that you are going to add more work to the sprint? If we plan less work to meet a strong sprint commitment, and also plan to add more work to the sprint later, then we are approaching continuous planning and might as well make the jump to iteration-less flow (e.g. and use Kanban).

We want a stable velocity. We want teams to be predictable. But requiring a strong sprint commitment is neither necessary nor sufficient. It's other stuff that makes us predictable, namely: finishing sprints cleanly every time; good backlog grooming practices; good story estimation practices (if using Scrum); limiting WIP; not starting work you can't finish in time; the "keep it working" principle; refactoring and SOLID design principles; good release planning and intelligent use of spikes; and so forth.

Just work directly on that stuff.

Truthfully, I've used sprint commitments and have also gone without them. They are useful in certain context, and dangerous in others. I consider the leadership, the managers and scrum masters, the team's agile experience, and how much time I'll have to coach the team before making the call on sprint commitments.

Related Articles:

Matt Barcomb wrote a nice article on good and bad commitments. Go read that and the very thoughtful comments posted in reply.

I briefly touched on sprint commitments in my post on unstable velocity.

Space Theories

I once created an agile space that my teams could choose to use. They had decent cubes they could also use. (Decent cubes -- an oxymoron?) Anyway, when the space was created it got used lots. Over time, it got used less. Late one night I pondered why and came up these thoughts. I'm posting it just for fun. Consider your space in light of these thoughts.

The Distance Theory

The likelihood of a team voluntarily using an agile space...

• is indirectly proportional to their proximity to each other.

Teammates are unlikely to use the shared space if their cubes are only three steps apart.

• is directly proportional to the sum of the distances between the cubes of the team members.

The more scattered the members are, the more likely they are to meet in a common location. Therefore, the likelihood of a team using the space may be proportional to the team size. This rule holds as long as that aforementioned sum of the distances is greater than the sum of the distances from the cubes to the agile space.

• is directly proportional to their proximity to it relative to their proximity to each other.

No one will use an agile space that is much further away than whichever cube is most central.

The Equipment Theory

The likelihood of an individual voluntarily using an agile space...

• is directly proportional to the computer speed and display size of the team computers relative to that of the computers in their cubes.

Equip the agile space with the most powerful PCs and beautiful monitors, and keep it that way.

The People Theory

The likelihood of a team voluntarily using an agile space...

• is directly proportional to likelihood that the team-lead (or some core, key individual(s)) can usually be found the lab.

Social aspects and the exchange of info/ideas matter.

• is directly proportional to the cohesiveness of their tasks.

Programmers working on disjoint tasks are less likely to use a shared space.

• is indirectly proportional to the number of teams using that space.

I can easily listen in or tune out discussions between my team members. Discussions between members of other teams are not easily tuned out. (Cognitive dissonance.)

The Environment Theory

The likelihood of an individual voluntarily using an agile space...

• is directly proportional to the positiveness of daylight.

Daylight is a positive and negative factor.

• Daylight good.
• Glare bad.
• Looking at distant objects good. Reduces eye strain.
• Heat bad.
• Working shades are good.
• Dysfunctional shades are bad.

Constellations and Deep Democracy

Constellations can be used as effectively with just one or two statements as well as with dozen, making it an effective tool for Deep Democracy.

One of the tools I picked up from Lyssa Adkins' book, Coaching Agile Teams, is called Constellation. (It really should be plural, Lyssa.) Briefly, the purpose of Constellations is to gain a better understanding of your team and their individual preferences, values, interests, or opinions.

Mechanically Constellations works like this: Put something in the middle of a big open room. Have everyone stand in a big circle around this object. Explain that you are going to read some statements. (Such as: "I like Scrum." "I get value out of our retros." "We should TDD more." "I think Agile will work for us." Etc.) Instruct the team to orient themselves closer or further away from this object after each statement is read to represent the extent to which they agree with that statement. If they agree, move in. If not, move out. Tell them to not over think it. Tell them to stand where their heart and head tells them to stand, not where they think they should stand. Then have the team observe the Constellation of people and discuss what it means. There are some considerations for how that discussion is facilitated, but that's a topic for another post.

The way it's described in the book is that the facilitator might want to read numerous statements. This is a great way for a team to get to know each other. I've done this exercise with about a dozen different teams. Now, I'm no longer surprised by what I find. A common surprise to the team is when they discover that their Product Owner doesn't like to run the demo but that someone else one the team has been dying to do it. Another: There's often an ah-ha moment when the team begins to understand that the quiet person just needs time to think before he speaks.

Anyway, I've done this lots and lots and have used 20 to 40 statements each time. Some of the resulting Constellations aren't interesting. I move on quickly and don't have discussion for those. Some are very revealing. I have a short discussion on the spot for those. Even the teams that are well established have interesting revelations using this technique. The number of questions and amount of discussion is bounded only by the team's willingness to continue standing.

Building on Michael Spayd's talk on Deep Democracy at Agile 2009, during the Atlanta Scrum Gathering in 2012, Lyssa Adkins and Michael Spayd led a Constellations exercise and only asked 2 questions.

They used the technique for Deep Democracy (Arnold Mindell). They were working with a large random group of people from the conference; I usually work with a team that has at least a little work history, and often a long history with each other. They facilitated the discussion carefully, more carefully than I would with a known group. Lyssa started with the inner ring and encouraged all voices to be heard, one ring at a time, an important aspect of Deep Democracy. Lyssa was careful to give voice to each ring in the Constellation and to set the ground rules: don't state that someone else's opinion is wrong or challenge someone else, use "I think" or "I feel" or "my opinion is", all opinions are valid, I will step in if you violate these rules, etc.

What I learned directly from Lyssa that I didn't get out of the book is that the Constellations technique can be useful with just one or two questions. In particular, it's useful when you have a specific narrow topic, even a controversial one -- when Deep Democracy is needed. This can provide a safe environment in which to speak and allows the facilitator to manage diverse opinions in a logical progression. It's also useful to reduce the number of questions as the size of the team grows (since it takes more time to allow more people to voice their opinion).

I would love to hear about your experiences with Constellations and Deep Democracy, together or separately. Are there other variations on this theme? Other ways to use this technique?

Management at the Solstice

The winter solstice is upon us here in the Northern Hemisphere. The earth is tilted on its axis, making the days shorter as the earth goes about it's elliptical orbit around the sun, reaching the shortest day on the winter solstice. This doesn't coincide with the dead of winter, however, because of seasonal lag caused by us having lots of water around, giving off stored heat. (A little something to look forward to -- three more months of cold weather.) Speaking of colds, our solstice does, however, occur right after the start of cold and flu season. Lower relative humidity indoors and us being indoors more makes us more susceptible to viruses. The shortening days and more time spent indoors gives us the winter blues. Depression, more prevalence of illness, compounded by the dreaded annual performance review and holiday stress makes a nasty combination. All of this ultimately leads to poor productivity and unhappy people.

So what? What's that to do with me?

The manager's job is to create an environment in which people can be productive, even healthy. Help your team attack the winter blues and defeat viruses. Help them find their happy hat.

But how?

You've got to come up with your own ideas for your own environment, but here are some examples.

Improve lighting for a better mood. We might be saving energy, but we're killing productivity with those glare and headache inducing, flickering fluorescent lights. Indirect non-fluorescent lamps are easier on the eyes. Or set up a light therapy room in some meeting room or office. Why not?

And sunlight is great. Open the blinds and schedule some outdoor activities, maybe a team lunch that you can walk to or at least drive to. In other words, get out of the building during the middle of the day.

Stock the break rooms with fresh fruit, nuts, and disinfectant wipes. Oranges are great to have around, being good for overall health. The smell of a fresh orange around the office makes people smile inside, doesn't it? Apples are easy to wash and eat and some say provide a pick-me-up as good as coffee. But please, get a good eating apple like a Pink Lady. Shoot, do something unique -- buy and peel a pomegranate for each person in your group. Most folks have probably never seen a pomegranate. You'll be expanding their horizons.

As for nuts, we grow tired of peanuts and who likes cashews anyway? Try pecans, the healthy nut with the highest amount of anti-oxidants. Almonds and walnuts work too.

While you are passing out the hand sanitizer and disinfectant wipes, encourage hand washing.

Do this and you'll create a happy, healthy work environment. Happy people are productive people. For more bright ideas, check out last December's post.

Yet Another Agile Reading List

(Updated October 2018)

I'm often asked for an agile reading list and each time I wish that I had already blogged it. What's kept me from doing it so far is that I tend to write a somewhat new list each time depending on the requester's level of experience, unique situation, and context. Such a list is also likely to change over time, but that shouldn't stop me from posting it -- this post is my thoughts at this point in time. My thoughts are likely to change.

That said, and without further ado or proof reading, here is an agile reading list.

Getting Started
Just go read the Scrum Guide. If you've never read it, you really should. It's short. But you might need something beyond that to gain a better understanding of how and why agile works, so don't stop there...

I could make this easy for me and just say read Cohn's signature series plus the Beck signature series. That'd keep you busy for a while and cover the topic pretty well.

But I can put a little more effort into this. Don't let this long list scare you. Start with this 1st block, then supplement with some of the others. I'm writing this from the point of view of helping a total agile novice get started.

Most importantly, you need to understand the agile values: http://agilemanifesto.org/ and http://pmdoi.org/ and either http://www.extremeprogramming.org/values.html or http://www.softwarereality.com/lifecycle/xp/four_values.jsp or http://xp123.com/xplor/xp0209b/index.shtml.

Here are some links about agile in general and two specific agile processes, XP and Scrum, and one lean/agile approach called Kanban. Just read as little or as much of these as you desire to get the gist of what it's all about:
http://en.wikipedia.org/wiki/Agile_development
http://en.wikipedia.org/wiki/Extreme_Programming
http://en.wikipedia.org/wiki/Scrum_%28development%29
http://en.wikipedia.org/wiki/Kanban_%28development%29

You need a good understanding of the Scrum process since it's the market share leader right now. I really really like Kenny Rubin's way with words and his Essential Scrum book is excellent. This is good: Succeeding with Agile: Software Development Using Scrum by Mike Cohn. Subscribe to Mike's blog.

Here's a good short, quick, easy to read intro to Scrum: "The Elements of Scrum" by Sims and Johnson. It includes some extra stuff that you really should do if you are using Scrum. I liked that. Well written.

I think I'll throw in http://scrumpocketguide.com/# from my friend Peter Saddington. I haven't read it, but it sounds short. :-)

Alternatives or Slightly More Advanced Items
Subscribe to my blog and LeadingAgile's blog :-).

These next few are a bit old, but you need to have read something by "Uncle Bob" and Alistair. You could substitute some other book by them if you wish:
Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin.
Agile Software Development by Alistair Cockburn.

These eXtreme Programming books are great and short and solidly apply to Scrum:
Planning XP by Beck.
XP Installed by Jeffries.
XP Explored by Wake.
Don't get the original white XP Explained book by Beck. It's talks about Load Factors and Ideal Engineering Days which I don't recommend.

If you want to broaden beyond Scrum and XP, read about Crystal Clear and the other Crystal methods by Alistair Cockburn.

Product Owner
Now we move beyond the basics into some specifics. First, let's take a look at the Product Owner related literature:

http://www.agilemodeling.com/artifacts/userStory.htm

Agile Estimating and Planning by Mike Cohn.

User Stories Applied: For Agile Software Development by Mike Cohn.

Here are some great posts from my colleague on The Product Owner:
http://www.leadingagile.com/2011/03/why-a-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-who-needs-to-play/
http://www.leadingagile.com/2011/03/one-real-life-product-owner-team/
http://www.leadingagile.com/2011/03/product-owner-team-design-considerations/

Scrum Product Ownership by Robert Galen. It's not an intro to agile. It's a good, thorough book on product ownership. It's full of good advice and tips and warnings against certain dysfunctional behaviors. The book contains some typos and passive voice that will annoy some people.

The Product Owner role in agile is a big job. And very important. Many say it can't be filled by just one person because no one has all the necessary skills. They say you often need a team of people with diverse skills and responsibilities to do the job well. I tend to agree. Here is some food for thought:
http://blog.xebia.com/2008/05/22/scrum-the-mythical-product-owner-role/

Scrum Master
Next, someone on your team needs to understand retrospectives in depth. If you don't get what you need to know out of the above books, this one is wonderful: Agile Retrospectives: Making Good Teams Great by Esther Derby. Subscribe to Esther's blog.

I highly recommend Scrum Mastery by Geoff Watts. This is an excellent book filled with very practical and though provoking advice.

Lyssa's book, Coaching Agile Teams, is very useful, but the novice should read the others first.

Technical
Here are some more assorted topics:

Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin. And check out her sequel also: More Agile Testing.

Read Beck's TDD book, Fowler's Refactoring book, Evans' Domain Driven Design book, and Williams' Pair Programming book.

Specification By Example by Gojko Adzic should be in this list as should The Cucumber Book by Wynne and Hellesoy.

Lean
At some point, you might need to know what people mean by Lean as it applies to software. Poppendieck wrote the books on it:

Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck

Leading Lean Software Development: Results Are not the Point by Mary Poppendieck.

To really understand lean, really and truly, read Toyota Kata by Mike Rother. This is about getting everyone in the org to make process improvement part of their daily job, to be very intentional about understanding the current and target condition, and to be very intentional about mentoring everyone about everything I just mentioned. This text will help you have a proper understanding about everything else you read about lean, all the techniques, all the metrics, all the approaches. 

Then read The Goal: A Process of Ongoing Improvement by Eliyahu M. Goldratt, a delightful book. We also have his Theory of Constraints (ToC) text. Goldratt is becoming a very important person to have read, at least for lean/agile consultants.

However, if you read Goldratt, you must also read The Principles of Product Development Flow by Reinertsen. Reinertsen takes exception with the over simplified or at least naïve implementations of ToC (et. al.).

ToC brings us to the kanban process which is gaining popularity. Kanban by David J Anderson is a wonderful book,but lacks specifics on how to do the metrics when the rubber meets the road. Subscribe to the kanbandev yahoo group. Anderson's Agile Management I would say is more advanced and should be read by serious agile managers or coaches. It's a good cross section of lean, pre-kanban, ToC, etc.

Rother's book Learning To See is about value stream mapping from a manufacturing perspective. I enjoyed working through it, but i'm weird that way. Most people in software development organizations won't need this.

Scale
There are books on scaling agile: Practices for Scaling Lean & Agile Development by Larman and Vodde. And Scaling Software Agility, Leffingwell.

Manage
Management 3.0 by Jurgen Appelo is the most important book for anyone leading or managing IT knowledge workers.

Dan Pink's Drive: understand autonomy, mastery and purpose.

Not sure whether to put DeMarco's Slack, Getting Past Burnout, Busywork and the Myth of Total Efficiency here or up under Lean. I have a blog post on slack.

Fin
Sadly, I cannot recommend this book, even thought I have a chapter in it: XP 2003 Proceedings.

Finally, find a local agile/lean/scrum user group to attend and make connections. I can tell you all about the ones in Atlanta and can connect you to people who know all about the ones in Ohio and Chicago and RTP, NC.

There are probably a thousand other folks with their own agile reading list. I wouldn't mind it at all if you were to post your list here or link from here to your site.

Slack and the Manager's Role in Scrum

photo credit: flikr dcwriterdawn

In his book Slack, Tom DeMarco makes the point is that you can't be creative when you are overworked or overburdened. Stress kills innovation as does busyness. To be creative, your mind needs to feel free and unallocated, uncluttered even.

In a waterfall shop, slack abounds. There's the project fuzzy front end where some are idle. There's the test and fix or stabilization cycle at the end of the project where some folks are slammed, and others are trying to not look as idle as they are. And there are times in the middle where this person or that one doesn't have enough work to do. Or maybe they are blocked. If you can put that slack time to good use improving the product, the work environment, your skills, or your process, then good for you.

The problem with Scrum and eXtreme Programming in particular and with iterative development in general is that they wring all the slack out of an organization. There is no unaccounted for time on a Scrum team. You must deliver value in every story. Every sprint must deliver valuable working software. You must help your teammates finish their work for the sprint if they get in a bind. Or add another small story to the sprint if possible. "If ya ain't working on the sprint backlog, ya ain't getting paid!" Little slack leads to little time to look around leads to little improvement.

Thankfully, we have a solution.

We have more than one, in fact. Let me first tell you about the solution that this article is not about. You can introduce slack into your organization with regular slack time. There are numerous well known examples of companies that do things like Fed-Ex days, time set aside for self-directed work, not allocated to Prioritized Product Backlog Items. Dan Pink recently endorsed this approach. As an aside, I like what Dan has to say about what motivates knowledge workers.

But there's another solution to the lack of slack that we should entertain first. In fact, you are less likely to do the FedEx day if you aren't first doing the following. But to introduce this I must first point out something that Scrum says about managers. Scrum doesn't say a whole lot about managers, but it does say at least this: mangers must stop assigning tasks. Too bad that many managers get their power and sense of self-worth from this activity. Deciding how to get the work done in Scrum is left up to the self-organizing cross-functional team. The people who can best decide how the work should be done are those closest to the work.

Just to be clear, managers in Scrum and eXtreme Programming should not:

• make assignments
• hand out work
• direct people or tell them what to do
• make the hiring decision solo
• SW architecture (in my opinion - debatable)
• do work
• be an individual contributor
• be a hero

Well, gosh, then shat should a manager do? Well, I'll tell ya! You could manage more people. You can still step in when the team needs help (but not too quickly). You are still an agent of the company, handling legal stuff, signing off on expenditures, etc. You can still manage risks, especially if you are a skilled Project Manager.

But you could also do something else.





Be the Slack.

Move up to a higher level of value to the organization. Be the slack that has been wrung out of the team. Here are some specific suggestions:

• Keep an eye on the system, looking for improvements
• Ensure cross-training is happening (not by making assignments, but making the team handle it)
• Understand the dynamics of the organization
• Understand how value is created
• Protect the team from interference
• Make the organization effective; learn to look at it as a system
• Support the team
• Clear roadblocks
• Provide good facilities -- fight the facilities police (better: teach facilities how value is created and how better facilities helps you guys create value)
• Ditto with more powerful computers, sufficient build machines and test machines (the people on the team are far more expensive than a PC)
• Use Derby's 13 essential questions for managers or the book on this topic she is working on
• Read Deming
• Watch interpersonal interaction -- watch when one team member pulls back, withdraws in a brainstorm (for example)
• Help the team learn TDD by making room for them to learn (time - remove the schedule pressure while they learn)
• Understand the capacity of the team (also a team and scrummaster job)
• Think through policies, procedures and reward/review systems and improve them (what messages do they send?)
• Understand what motivates knowledge workers (see the previous reference to Pink) and let creating that kind of environment be an imperative

I contend that we should focus on continuous improvement of process, of people’s skills and knowledge, with a strong focus on empowerment and self-organization. And work on open, honest feedback. You’ll have better results if you do all that and just completely scrap the individual annual review.* I love quoting Drucker here: "“the average person takes 6 months recovering from a performance review.”

I'm really straying off the point of the article there. Let me bring it back together by saying you can't do a good job with this other higher value stuff if you are down in the weeds assigning tasks to people. Delegate more. In fact, delegate everything, freeing yourself up to be the ultimate in valuable slack.


----------------------------------------------------------------
* Not sure if that sentence is in my words or whether I've co-opted someone else's way of saying that. I think I've read a similar sentiment in either Management 3.0 or in Coaching Agile Teams. I don't think I've plagiarized there, but will gladly give due credit if I have.

How to Engage an Agile Coach

I'm often asked by companies how they can engage me as an Agile Coach. What would you do? For how long would you be there? How long would it take? My response is always tailored given their specific context. Each situation is different. However, here's an attempt to give a very general response to that question.

In short, you can pretty much design your own ideal engagement with an Agile Coach. I'm sure there is a coach out there that will be willing work with you toward your goals or activities, whatever they are. Although some coaches only do deals of a certain size or of a certain type of work, there is generally lots of flexibility to be found.

For example, depending on what you are after and on your budget, the number of days and the frequency of involvement can vary.

• Very limited: A day or a small number of days
• Regular or periodic: A day or three each iteration
• Full time but temporary: like 1 to 6 months
• Full time permanent: unbounded

A single small team that just wants some outside eyes once, or once in a while, can get help with a small budget. Involving the coach with more teams and more people typically means more days are needed to accomplish your improvement or transformation goals. An organization looking for coaching for many large non-collocated teams is a much larger deal.

The engagement can be just as simple as "hey, I think we're doing pretty good, but we'd like to have a fresh set of eyes to point out what we're overlooking." That could lead to any number of recommendations that the team is free to tackle on their own. Or that could lead to an additional engagement designed to address some specific issues. Or an engagement can be as broad as be here every day and work with us for three months.

As for the type of work that a coach may do for you, the work of the coach may be in the form of training and workshops, mentoring, coaching, consulting/advising, or getting his hands dirty.

Here are some examples of what you might engage a coach to help you with. This is not an exhaustive list.

• Limiting WIP and setting limits
• Using Kanban and Lean metrics
• Eliminating delay, prioritizing work via cost of delay, and improving flow
• A3 problem solving
• Demonstrate many retrospective techniques, lead retrospectives, mentor others as they use these techniques
• Spotting and removing impediments and managing risks
• Creating and sizing / estimating the release backlog, using velocity
• Identifying the MMF set
• Story mapping
• Project chartering, vision casting
• Planning and preplanning
• Communicating
• Using BVCs and information radiators, addressing why they are stale and not being used
• Space and facilities
• Pair programming, SOLID design, emergent architecture, TDD, CI, continuous deployment, etc.
• Defining Done
• Coding katas
• Design patterns, refactoring, etc., for example through lunch-n-learns
• Designing and tasking-out of stories; design review; shared task list and working as a team on each story
• A myriad of dysfunctions
• Issues with interpersonal relationships, working agreements, appreciation, active listening and working as a genuine team instead of as a simple working group, team accountability
• Team goals, rewards, recognition, MBOs and other HR/management policies
• The management role, including management influence and interference, people management
• Scrum of scrums, multi-layer scrum and kanban
• Working effectively with remote workers
• Project portfolio management
• Documentation
• Q&A - Address the team's concerns and questions such as:
  
  • "How should we handle defects and minor changes in our specific context? Plan them and estimate them? Treat them as high priority and don't plan/estimate?"
  • "What should we do if we don't finish a story in the iteration?"
  • "On what day of the week should we have planning?"
  • "We're considering changing the way we do xxxxxx, what do you think?"
  • "We have work left over at the end of each iteration. What do we do?"
    

This list could go on and on and on. Each coach has their specialties and strengths and would come up with a somewhat different list.

Give me a call and we'll set up a time to craft an engagement of your own, suitable for your needs and your context.

Partial Points and an Unstable Velocity

Years ago, back when I was dumber…

Once every three months or so we'd have some incomplete story and we'd split the points, allocating some to this iteration and some to the next iteration. That's dumb.

Instead, for the last couple years when this happens I give no points to this iteration and points remaining (we estimate the remaining work) to the next iteration. Back then, the lower velocity would have caused angst in upper management, but read on.

We estimated our stories in points. We did not estimate our tasks. Our tasks were very fine grained. Most tasks were half an hour to half a day. We did not come up with tasks in planning. I wouldn't change any of that. In fact, it's what I currently try to get my clients to do. The difficult part seems to be the very fine grained tasks.

For us, 0 and 1 point stories were trivial. Normal estimates could be 5, 10, 15, 20, 30, or 40 points. If it was 40 or below, the story could go into an iteration. We would also use 60 and 100 point estimates, but those stories had to be split. Our problem was that the 30s and 40s were always underestimated relative to the 5s through 20s. The scale wasn't linear. We knew this. Knowing it didn't fix it. That made our velocity unstable.

Our unstable velocity caused lots of heart-burn in the upper management ranks and contributed to a lack of trust. If I had a do-over, I would solve this by narrowing the range of estimates allowed which would drive more of the larger stories to be split. I'd limit the range to, say, 5 to 20.

I've also considered solving an unstable velocity by clearly setting a high level of commitment for each iteration. Not stretch goal. Not aggressive goal. A high level of commitment. The team would of course still say what they would commit to. But I would have expected them to meet it. (This has sense been deemphasized in Scrum, and I didn't do it then and I wouldn't do it on most teams now, but it might have helped in this situation, as I describe next.) This surely would have initially led the team to commit to a smaller amount of work. And it would have eventually led to more care being made at the start of the iteration and in advance of the iteration in order to have a well thought out plan. We would have gotten back to committing to the normal amount of work over the long term, but would have given us a much more stable velocity and more predictable pace. Maybe. If done wrong it would have just angered the programmers.

Another way of getting at smaller stories and better planning would have been for us to drop from two-week to one-week iterations. That would also force us to split the larger stories. We already had a great design/task-creation/review approach, but we did that design just in time, during the iteration, immediately before development. With one-week iterations, we could do that work for each story on the 1st day of the iteration between planning and commitment.

And yet another way to crack this nut would have been to switch to a cycle time metric (as in Kanban) or publish only an average velocity measured over four to six iterations.

A BVC for Tech Debt

Thinking back to some of my days in management years ago, if I had a do-over, I would create a better big visible chart for our technical debt. What we had was a list of code examples to not follow, some cleanup tags in the code, the occasional debt reduction story card, and sometimes a list of debt-full areas written on the whiteboard.

What else we needed was a consolidated list of our debt on a single Big Visible Chart (BVC). We'd write each technical debt on the BVC as we either encounter it the first time or when we knowingly introduce it. Then each time we encounter it thereafter we could put a dot next to it. A dot for each day it slows us down or for each day of impact it causes.

Most teams I've seen could benefit from quantifying technical debt in this way. You've got to make the impact visible. Otherwise it can be difficult to get the understanding of, or even support from, others in the business. It easy for those who don't interact regularly with the developers and who don't have a recent development background and experience with better practices to lack trust. Not only that, quantifying debt can help a team prioritize their debt reduction efforts and keep them on top of it.

Off the Road Again

I'm back! I'm definitely back in Atlanta and hopefully back into my blog as well. As of this month I'm once again focused on the Southeast, but now as an independent lean and agile coach.

Working with Pillar Technology was fun. They are a great bunch of people and have some amazing programmer talent. I'm glad I followed Mike Cottmeyer to Pillar and really enjoyed working with him. I can't thank him enough for the help he gave me early on. I'm appreciative of the slack and the support Matt VanVleet gave me. Working with Pillar also gave me lots of opportunity to work with and be challenged by Matt Barcomb. Always a plus. But going independent gives Pillar and I some relief from the costs and pressures of my travel to the Northeast.

I am engaged with a great client here in Sandy Springs but my calendar through the end of the year isn't full. Help me fill it! I’d enjoy talking through your projects and the challenges they bring and how we can work together. Let's meet up. Give me a call or drop me an email.

These last couple of years I've re-learned how passionate I am about coaching and training. I've never had more joy from work than when I help a team improve their environment and see their appreciation. I've been blessed to be able to do that as part of my job from '99 through '09. And I have been even more blessed to make it my sole focus since then.

Each context is different, a unique challenge requiring a unique prescription. I'm looking forward to bringing this passion and experience to new challenges, in your context, to your environment.

CAN: Shifting the Voice of the Business to the Team

I've been thinking about Mike Cottmeyer's "12 Keys to Success with Agile", specifically his bullet #3, single voice of the business, where he says "This cannot be shifted to the team..."

It can.

Earlier this week Scott Chacon of GitHub presented his approach to projects, called Developer Driven Development, in a keynote address at CodeMash 2011. I won't try to explain DDD here, since the details aren't germane to this post.

However, key to DDD is that you must have careful hiring practices, careful to the point that you only hire people that already demonstrate a commitment to the project and possess great knowledge of the domain. (My words, not his, but I think he'd agree.) Hire those that are already involved in the project or in related ones. Clearly, to be already involved in the project before you are hired likely implies you are either involved in an open source project or are an actively involved customer or user of the product, be it open source or commercial.

Can that be applied to Corporate America? Not completely sure, but we can certainly apply some lessons. If your team hasn't already caught the vision, you need to help them catch the vision. This is important on any project, agile or not. But its importance is indirectly proportional to the extent to which you have an effective voice for the business involved with the team. That is, the less that the team understands the business need already, the more that vision casting is needed. The more that the team knows the business need own their own, the less involvement the team needs from "the business".

I've been on at least one team of note in Corporate America that the single voice of the business was successfully shifted to the team. In this case the team sold the business on a need. The team was given the leeway to run with the idea. Each person brought to the project what they thought the project needed. Each person on the team had a voice in prioritization. Anything that was to get done had to have the support of the team. (So, this wasn't a free-for-all to the extent that an open source project would be. Everyone did not go off and build whichever feature they wanted. The team agreed to the iteration's backlog.)

This worked because the team wanted it to. We wanted to keep doing what we were doing. We liked the product, the project, the team. To keep it going we had to demonstrate value to the organization that was paying the bills. So, we listened to those using the product and took their needs and suggestions into consideration.

It worked much like the open source model: I build what I want, what is interesting to me. But motivation is multifaceted. I'd like help from others, so I have to consider their interests. I'd like my product to be useful, to be used. I'd enjoy a little fame or appreciation from others. I'd like enough money out of the project to take money off the table. So if I'm relying on the product to pay the bills or support my multifaceted motivation, then I'm going to listen to my users and supporters.

It's going too far to say that you cannot shift "single voice of the business" to the team. A trusting cross functional team with empowered team members sharing accountability who have the vision can BE the single voice of the business.

My Road to Agile

For those of you without the patience to read yesterday's long post, here is the abridged version. My route to agile wasn't overnight.

Fist exposure to an automated regression test suite in '89 (with the IBM 3174 Communications Controller).
Many years of coding and laboriously testing stuff by hand.
Wanted to try my hand at management in '96.
Project managed wrongly what could have been a nice agile project.
Felt ignorant.
Started studying.
Went back to programming.
Fell into an XP project in '99.
Fell in love with XP.
Studied it.
Tried to spread it.
Practiced it on a number of projects.
Wrote about it.
Spoke about it.
Disappointed people didn't flock to it.
Wanted to try my hand at managing in an agile fashion in '05.
Did much better.
Wanted to practice it on more projects, so became a coach for hire.

The moral of the story:
Consider all that led up to you buying in. Then guide and encourage those you work with, but give people space to find their own road to agile. Have patience with those you coach.

photo credit: Tomasz Wiech

How I Got Into Agile

This is long, but there is a moral to the story.

I had been programming for several years when I became tired of supporting the PPP and Frame Relay code in IBM's first router. No, that's not it. What really drove me away was the threat of having to pick up support for LU6.2. Maybe it wasn't LU6.2. Maybe it was something else, but it was definitely SNA. That's not the direction I wanted to go in. I wanted to work on IP. Any part of IP. I'd have been happy supporting basic IP, UDP, TCP. Developing any of the routing protocols would have been great. That's where the future was going to be. SNA? Yuck.

Prognostication in the early '90s -- score one for me.

I pleaded with the manager of the IP group to take me on. He had no openings. Or he no likey me. Or I had no IP knowledge. Whatever.

My manager at the time was Tom, a great manager and a real character. Tom was often railing about how many worthless meetings we had and how many people we had in them. Tom wrote a program in those days to compute the cost of meetings. All you had to know was the salary bands for the various levels and what level each of the attendees were -- stuff most people knew. Today you can get a program that does this for your iPhone. I digress. Tom was disappointed by my desire to leave his group, but was supportive in helping me find a place where I could grow and be happy. We'll come back to Tom in a bit.

A good friend, Sam, was working in the same division on some Smalltalk apps. Cool stuff, I thought, but I didn't realize how cool. Smalltalk will never make it, I thought. "What you are doing is kind of hard to buy into", I thought. C++ is where you want to be. I later said the same thing about Java.

Prognostication in the mid '90s -- Although Smalltalk didn't make it in the market, it would have been the thing to learn. Score one for me against Smalltalk's market-share; But -1 for being against Smalltalk as an important language; -1 against Java.

Sam's manager, Joe, offered me a position and made hints toward his retiring soon. I was thinking that if I couldn't work on IP I just might as well go into management. So I joined up. Sure enough, Joe very soon retired and handed the reigns over to me.

Now back to Tom. Not one month into my new role as manager, something was found to be lacking in our software. I don't recall whether it was a bug or an enhancement request. Whatever it was, Tom needed it for his product. My former manager, Tom, was now my customer. So, wanting to be a strong manager with a backbone, one who could make the tough decisions and stand by them, protect his team and his schedule, I said no. I either said simply 'no', or I gave him a delivery date way out in the future, which might as well have been 'no'. Although Tom was the man who helped me get this job, had given me a promotion along the way, and was now my customer, and although his request was quite small, I said no. When I became a manager I threw out the window all I knew about being collaborative. I stopped practicing what I believed in as a developer. I did what I thought managers were supposed to do. Tom wasn't my only customer. I had bigger customers with big projects and big demands. Tom was furious.

What I didn't know then was that this team of Smalltalkers was quite agile. Of course, we didn't have that term back then. Gosh. This was in the midst of the ISO 9000 certification heyday. I had to document our process. I never new managers had to do that kind of stuff! "What have I gotten myself into?" I thought. I really didn't know how to describe our process. I kind of knew what we did, but document it? I knew I'd need help and thought the team would be as annoyed as I with this task. I dreaded asking the question and I didn't fully understand the answer: "Iterative and Incremental" with a few other words wrapped around it. So, I wrote down Iterative and Incremental on the process document, wrapped a few other miscellaneous made up words around it, then whipped out MS Project and got my project plan in shape. And it was a doozey! Spread out, the project plan covered a very large conference room table. I was so proud. (But it was really quite disgusting.) I could demonstrate when we'd be done (well after everyone wanted it), how I carefully put the plan together (with painstaking detail), and how many more expensive Smalltalk contractors we'd need (don't ask). I knew nothing of negotiating scope. I project managed wrongly what could have been a nice agile project.

I knew I was missing something. I felt ignorant so I started studying. I went back to programming while trying to figure out what I was missing. Steve McConnell's Rapid Development and Steve Maguire's Debugging the Development Process and Fred Brook's The Mythical Man-Month stand out as books that began to point me in the right direction.

Then in '99 I discovered jUnit and very soon after got invited onto an XP team, thanks to Greg Houston. Greg would say I resisted XP. Perhaps I did. But I soon fell in love with it after I got used to pair-programming. That took some number of months. Then I began studying XP, writing about it and tried to spread it. I was there at the start of XP Atlanta, which was led at the time by Obie Fernandez and which we later renamed Agile Atlanta. I attended XP Universe in 2001. I practiced XP on a number of projects then started speaking about it within the company, at a local user group and at a nearby college. I also submitted an experience report and a research paper to XP 2003 in Genova. I knew I'd be using agile for a very long time.

I thought I could convert people, that people would readily see the light and that in just a few short years everyone would be doing XP. They would be won over by my passion if nothing else. People would flock to our XP user group. jUnit would lead people to XP and the XP books would convert everybody. And I knew this would happen throughout the industry.

Prognostication in the early '00s -- score one for industry wide fear, uncertainty and doubt with a big helping of resistance to change.

My Prognostication Score: 2 out of 5.

After some years of being an agile developer and advocate in an organization lukewarm to the concept, I decided that I wanted to get onto a team where everyone really wanted to do XP and management supported it. And I wanted to try my hand at managing again, this time in an agile fashion. I found such a team to manage and I did much better this time (though considering how bad the first time was, this might not be saying much). This project eventually brought me to my desire to practice lean/agile on more projects, so I became a coach for hire.

So that's how I came to agile and here's the moral of the story: I think it's important to remember the route you took and how long it took. For most of you I suspect it wasn't really overnight. It might seem that way on the surface. "I got the book, read it, tried it, loved it, all overnight." Not likely. There was a road that got you prepared for the switch. Those we work with, those we try to coach, are on their own road. Have patience with them.

photo credit: Tomasz Wiech

Getting Your Team to Take Short-Cuts

I was once in a software product company teetering on the edge of financial problems. And who in this business hasn't been? We had only one customer of consequence and they were unhappy with the cost of what was essentially custom development. This turned into pressure to deliver more features per dollar of cost. I.E., to develop the features faster. Right away. Pronto. How do you make a team of programmers immediately faster?

I had already looked at our process and had evaluated our use of best practices and our quality. We were following XP well, so if you subscribe to XP being a good set of best practices, we had that covered. Our development speed was average for enterprise software vendors using Java/Swing. But our quality was best in class. I am basing my evaluation mainly on the work of Capers Jones' recent books and metrics gathered from the team's history. That's about as objective as I could get. I also considered what I know of the industry and other groups, a more subjective measure. From what I've seen since, that team's velocity was actually quite good. To get the performance boost, there was only one thing left to do.

You may be able to get a short boost of speed at the expense of incurring technical debt, or, more technical debt than normal as your case may be. But to do that, to get a short boost in the rate of delivered features, you’ve got to paint a good picture of the situation to development. Why? Because you’ve got to get them to understand the seriousness of the situation and give them a vision of how long or how much or how many of what is needed so that they can buy-in to changing their habits and their preferred, ingrained and natural method of working. Saying "preferred way of working" makes this sound like a choice. A team's preferred way of working is indeed a preference, but it isn't much of a choice. It's a compulsion. You must realize when you demand speed, when you ask the team to take short-cuts, you are asking them to work-differently. You are asking them to work in an unnatural manner.

To illustrate: You are most likely right handed. Pick up your pen with your left hand and write a long letter to your spouse or your mom. Get the picture? The unnatural is difficult to achieve.

In Complete Control and Not Controlling

My regular followers know I post on lean/agile IT topics as well as bicycling and faith-based views. You agile IT guys – hang with me and I’ll tie a little agile into this before the end.

One of my favorite bloggers is Joe Gibson, co-author of the Ant Developer’s handbook. I like his opinionated writing on topics of interest to me: Java, Scala, Groovy, Ruby, Lisp, Koine Greek and religion. His own translation of old Greek manuscripts and commentary on other translations are quite interesting.

Joey posted a few days ago on how those who use the Bible too often "selectively edit scripture to fit a particular message, or to fit nicely with a pithy saying." This is essentially eisegesis (to draw in) rather than proper exegesis (to draw out). That is, reading stuff into the text rather than more appropriately getting out of it what the author intended. I was passionately into his post, in complete agreement.

Now Joey and I don’t see eye to eye on a number of matters of faith. Yet even when we strongly disagree there is usually some point in his writing that I strongly support. So I was with him right up until he said this:

...the minister was going on about how we need to "stop worrying" and just know that "God is in complete control" and blah blah blah… I’ve always hated that way of thinking. I despise the Sandy Patty song, "God Is In Control," because I do not believe that is true. (Bold emphasis added.)

So I crafted a nice and timely, intelligent, thorough and sound response. Joey’s blog seems to have a multi-step click-post, preview, click-post-again are-you-sure, captcha phrase kind of process that I obviously flubbed because my response never made it to the blog. Time has passed and now I’m here rambling on, many times over what I so eloquently put in my initial response.

So back to Joey. Joey’s next statement shows a misunderstanding of "complete control" and he has made quite a leap.

...if you believe that he is in "complete control" then you have to take that to its logical conclusion. If you believe that every good thing that happens to you is because God wanted it to be that way, then you must also accept that every bad thing that happens to you is because God wanted it that way.

The error here is the assumption that to believe that God is in complete control is to believe that everything that happens to you is because God wanted it to be that way. Let me explain. My kids run wild at times. This is not what I want. "Hey kids! Run around the house, fight some, and drive your mother and I crazy." It’s not what I want, but that’s what happens. I give them some room to exercise their free will. Notice I said some room. I have boundaries and my kids test them. I’m not controlling my kids, at least not most of the time. At least I try to not be controlling. Anyway, I assure you I’m in complete control of the situation at home and am quick hand out corporal punishment when boundaries are reached. In control, but not controlling.

A good agile manager or agile architect does likewise. They aren’t controlling. Rather, they set some boundaries, and otherwise let the team self-organize. They give the team much latitude to decide how to get the work done within some boundaries. Rather than hand out tasks, they encourage the team to select their own work tasks. Yet they remain in complete control.

[Sorry – I have no analogy for you bicyclists. I control my bicycle, but am never fully in control, much to the disappointment of my Dunwoody Cycling buddies.]

Notice that God told Adam that he is free. Free to eat of any tree in the garden but one. God gave man free will. But God also set some boundaries. So Adam was hanging out in this cool garden in complete fellowship with God Himself. But Adam poked God’s boundary so Adam and all of us now suffer the consequences. God’s will is for man to love God and obey his boundaries. God sends no one to hell. God’s will is that no one perishes, but that everyone accepts his free gift of salvation by faith in Jesus Christ alone. But for love and obedience to be real, there has to be a choice. A choice to disobey. Therefore, God is not controlling our every action and decision. And we will all suffer the consequences of my sin and your sin and Adam’s sin and the sin of others. God does not wish this on any of us.

Witness Job. God allowed Satan to bring disaster on Job and his family. But God set boundaries for Satan. "Go this far and no further" in effect. So God certainly allows bad things to happen, within boundaries. I wouldn’t wish Job’s trials on anyone, but I’m sure glad it happened. There are a lot of lessons for us to learn at Job’s expense, in particular, that God is in control.

Boundaries – God is not going to allow us to interfere with his plans. We can’t blow up the earth, for example, and kill everyone. We can’t wreck the environment such that we all die. Unless, of course, that is God’s plan for how the "first earth" will pass away (Revelation 21). But in that case, there is nothing we can do to stop it from happening either. But in any case, we’ve got boundaries and God is in control. We can certainly kill many and do big-time damage. But we can’t mess up his plans. God will intervene.

God does directly intervene at times. See 1 Kings 22:23 -- "You see, the LORD has put a lying spirit into the mouth of all these prophets of yours, and the LORD has pronounced disaster against you." The Bible says that what Joseph’s brothers meant for harm, God used for good. And there are the New Testament miracles.

This is getting long and a bit rambling, and my argument is beginning (or perhaps continuing) to trail off, so rather than wrap it up and put a nice bow on it like Joey does, I’m just going to quit here.

Attributes of a Great Manager

I've been thinking about what makes a good software development manager for quite some time. A friend recently asked for my thoughts on this so I thought I'd jot them down. Let me know what you think.

People management is top priority. Developing people is what it's all about. The job is to empower, delegate, motivate, reward and recognize. And it is to be done frequently. And that is all. It's okay to be a customer advocate given spare time, but that should not be the manager's job. It's good to use the application his group is building. And it's good to understand the competition. But QA and competitive analysis is not the manager's job. It's okay for the manager to be a proxy for the customer for a short while, but that's the product manager's job. And the manager can be the benevolent dictator (final arbiter) if there is no one else to do it.

A manager should encourage, reward, even expect continuous learning. This means more than just paying for appropriate books and sending a few employees to training each year. It also means encouraging employees to keep learning and sharing what they learn. Recognize employees that are involved in study groups and user groups. Encourage the use of software development best practices.

A good manager will take time to meet regularly with employees, in small groups and one-on-one. You'll likely find a good manager eating lunch with his employees or chatting in the break room. You may even find him playing video games, ping-pong or foosball. High levels of communication is very important. It's the best way to understand the organization's health, to discover employees' career goals and aspirations, and to find out what type of work they enjoy. Without this understanding, how can a manager mentor and develop his people?

Regularly is also the most appropriate time to give feedback. Managers should comment on good and bad work right away. Don't wait for the end of the project. And certainly don't wait for the annual review.

Perhaps the most difficult aspect of good management for most of us techies, oddly enough, is fostering creativity. We are all pretty creative. But we get in ruts and lose our edge. A good manager spends his time thinking of how to keep our brains creative.

I don't think a manager necessarily has to have been a programmer, though it can help. It helps to be technical enough to be credible, to have something in common with the engineers. And it helps to know when someone is trying to pull the wool over your eyes. It's useful to know how to do all the stuff I say don't do (below), but develop those skills in others rather than do the task yourself.

One of my favorite quotes is from Andy Hunt.

Management's responsibility: remove the obstacle. Team's responsibility: identify the obstacle.

It's the idea of management serving the employees, not the other way around. The employees get the real work done. Managers make sure the right folks are trained and aware of what needs to get done. Managers make sure employees have the information they need to do the job well.

A manager should not spend his time "doing" stuff. Richard Lowe expresses this best: "This means ALL tasks must be delegated, except for those tasks directly related to getting other people to do their jobs." The mistake is "doing actual work instead of managing." If a manager's job is to observe, motivate, reward, develop people, improve morale, and all that other stuff, then, if done well, there will be no time for anything else.

Managers should never make design or coding decisions. Nor should they make architectural decisions except to enforce whatever constraints come from product-family concerns or testability, reliability, redundancy, serviceability, availability, and other requirements of that ilk. But managers often can't resist. Where does this come from?

Often we take good developers and promote them into management. Not because they possess the attributes of a good manager, but for all the wrong reasons. "Fred did a great job on the hoohoppy project. He handled all the technical details. He's our most senior developer and we have this open management position..." This makes about as much since as, well, as me trying to make a weak analogy right now.

Of course it isn't always quite so black and white. Sometimes a manager may find himself in a situation in which no one knows how to do some necessary and urgent task and either the manager has a real junior team or has some seriously tight deadline. In this situation, I don't mind if a manager pitches in to learn how to get this thing done. But it shouldn't become the manager's job. Rather, he should teach someone else to do it and delegate that responsibility.

What about project management? Isn't that a manager's job? I don't think so, though that's where it usually ends up. Good managers should train up their team-leads to handle that responsibility. Managers should ensure that it gets done and should teach others how to do it if necessary. It's the same with risk management. Ensure it gets done, but don't do it yourself. "We need to have more trust in one another," Lou Gerstner Jr in his tenure as CEO of IBM wrote to employees -- "confidence that our colleagues can lead and do the right thing, so we don't have to attend every meeting and check every detail."

There is more, of course. But it all involves thinking about what needs doing, rather than the doing itself.

It should go without saying: Treat employees with a great deal of respect. Treat them like the intelligent human beings they are. Sadly, I've seen a few managers that just don't understand this. Or they never spend time in self-reflection, examining their behavior. So I'll leave you with this thought. Managers, reflect on your organization's effectiveness. And reflect on your effectiveness.

P.S. Before anyone points out that I don't walk the walk, let me add that all of this is very hard. To do it well requires either a tremendous amount of courage or like-minded upper management who will hold us accountable.