We don't want you (yet)...

The Agile Community doesn't need more people who want to "go Agile"; it needs more people to successfully "be Agile".

I guess this is a follow-up point to my earlier post. We need to stop recruiting and start teaching.

Feed a man fish and he'll be hungry tomorrow. Show a man to fish, he'll feed himself.
Teach a man to teach others to fish, everyone will eventually feed themselves.

.... or something like that.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, but then your students can't successfully do agile... you are a parasite.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, and then your students successfully do agile... you are a teacher.

Subtle difference... are you a teacher or a parasite?
History speaks for itself. Go back and see what people have done in your wake!

The Thumbtack and Hole Metrics...

Sometimes metrics can just appear in front of you very simplistically without any effort. I've discovered two new ones which I call the Thumbtack Metric and the Hole Metric.

The back story is that we use a corkboard to track our work. This is a high level view of the biggest priorities in VersionOne, our legacy ticket system, and any other queues of work we have. Because our one team supports all company operations AND does new product development, we have a hybrid balance of many different approaches. The board is our central view.

I attempted to force WIP limits onto the board so that it was a true Kanban board, but this simply didn't work in our environment for multiple reasons (nature of our work along with company culture). BUT, it has been very interesting for the team to start realizing when they are attempting to do too much. As the coach, this was something I used to pro-actively point out, but I'm learning that it is better for me to be reactive so that the team themselves can learn from experience. (Unfortunately, a child understands "hot" much better after being burned.)

This maturity and growth has led to many great conversations on the team. They start as individual discussions of philosophy between me and someone on the team, and then they become team discussions where we improve something in our process.

Through all of this, I've noticed a few things that the team now sees after it has been pointed out:

1. A problem item typically has many thumbtack holes in it (The Hole Metric). The "holier" the item, the more of a problem it is. What is the causation behind this correlation? Well, every week we scrub the board. Every few days rows get re-aligned. If an item is picked up on one day and finished the next... it has one or two holes in it. But if the item gets pushed around for days and lost under other stickies... then it get punched A LOT! So... we now have a metric that can be used to identify areas of improvement. When a "holy" item reaches DONE, it is a good topic for a quick review/mini-retrospective.
2. Every item on the board needs a thumbtack. We thumbtack stickies so that they don't get blown off while moving the board around (our board sits in a central visible area of the company and is carried into our dedicated standup meeting room every morning). Sometimes we group things with one thumbtack, but in general, there is a correlation between the amount of work on the board and the number of thumbtacks used. I haven't been successful at imposing WIP, but I have been successful in showing that when we run out of thumbtacks, we are in for trouble. This is the Thumbtack Metric. If you need more thumbtacks to stick things onto the board, you have a problem coming (or are already knee deep in it). Conversely, the CEO notices that too many unused thumbtacks might be a sign of available capacity (so I take thumbtacks off the board at times if needed ).
   

See... all those documents, white papers, conference sessions, etc you've read about metrics... they were overkill. There are simple metrics right in front of your team every day. AND, they are much easier to sell, explain, and use as an indicator moving forward.

So... what's your thumbtack metric?

Agile vs. Traditional Projects... which costs more?

Another great debate in the LinkedIn Agile Alliance forum... quite a few responses and viewpoints!

The original poster asked the following:

Should Agile Projects cost more/less than waterfall projects?

and the answers varied greatly!

The following focused on whether this was a valid question:

Proving an Agile project is less costly is not easy because your attempting to compare an alternative history -- Clay Nelson

...if we ever start to sell Agile as a way to lower costs then we just invite a a backlash against Agile -- David Nessl

And others attempted to answer it:

Agile does not aim to be a low-cost alternative. Some seem to believe so, but the aim is agility: Speed and flexibility. We become agile to shorten time to market, to increase adaptability and reap greater ROI over the lifetime of a product, to name a few reasons. -- Marcus Widerberg

Agile should cost less for several reasons, among which are: Your mistakes cost less... Earlier opportunities to start getting ROI... Failing early vs Failing late... -- Chuck van der Linden

And of course... my answer:

Most companies do a horrible job of measuring the quality and defect costs that start during the integration/testing/stabilization phases running all the way through support. All companies do a horrible job of measuring technical debt.

If agile reduces these up front, then overall Agile is cheaper from an end-to-end perspective.

But since nobody knows or tracks the cost of these things, Agile (which takes more effort/work to be successful at) will look more expensive on paper.

Tech Example: I can write code without automated tests in half the time, but what will it cost later?

Business Example: I can plan and design everything now, but what will be the cost of unknowns and market changes later when I can't handle it?

Oh, by the way, Forrester Research did a partner study with Thoughtworks... "Forrester TEI concluded our Agile delivery is 40% less expensive overall". - from a Ross Pettit presentation @ Agile East 2009

What if Congress used Agile?

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

Individual Recognition on a Scrum team

Hmmm... another conversation in the Agile Alliance LinkedIn group. Here was the question:

Should we have an individual recognition award in a SCRUM team? Lots of people says that individual award is against an Agile methodology. Award should be given to a team not to a individual team member.

I tried to play a passive role and stated the following:

I have seen these conversations occur many times in many forums and the end of the conversation always results in a "NO" with a very good list of reasons. The risks outweigh the rewards no matter how you set it up.

There is a gray area of disagreement on whether the team can spontaneously award a peer or not. But the minute you make it a regular event, it wanders back into the problem area.

The best reward is taking a respected peer out for coffee/beer and telling them you appreciate their contributions, or saying in front of the team what good they've done. This doesn't need to be organized.

And the first few responses before mine were in line with this:

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest. - Jay Conne

The only time an individual award is appropriate is if the team wants to acknowledge an individual who has made a significant contribution that made a big difference TO and FOR THE TEAM. - Shane Hastie

But then we got the extremist viewpoint thrown in:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

So I found myself having to take a stance and state the following:

Here's the best way to summarize what I'm insinuating/feel:

If an award is financially valuable... and it is regular (creating a sense of expectation), then it has a higher probability of creating individual behaviors over team behaviors unless your team remains constantly aligned to itself (resources typically fluctuate too much for this to be assumed).

If a reward is simply a show of appreciation and a call to what behaviors or achievements the team should continue to grow and repeat, then this has a higher probability of creating a collective and positive team behavior, especially if it is unexpected (not scheduled), and driven by the team.

Feel free to include your own thoughts in the comments, but I have to say that I'm not very open to debate on this one.

What is Iteration Zero?

Someone asked a very interesting question in the Agile Alliance LinkedIn group. Discussions about iteration zero have come up before, but this one was specifically focused on the situation where the architecture was not well understood.

In case you are new to Agile or Scrum, iteration zero is the term for that first sprint where you know you won't be delivering software that is adding value for the customer. It's the "let's-get-our-ducks-in-a-row-so-we-don't-bomb-the-first-sprint" sprint.

Many people use sprint zero when they transition to agile for converting their project plan into a backlog and seting up the environments needed for CI and other XP practices. Some use it to kick off a project and understand the underlying system being built on top of.

In this discussion though, it got me to thinking about a past project where we were starting from scratch. We had nothing, and we had never developed in this technology before. So, what to do?

Remember, a sprint should always have an outcome or goal. And, it should always be demonstrable! The original poster asked about unknown architecture, common impediments, and differences to non-agile projects. Here's what I contributed to the forum:

Iteration 0 should result in a compiled installable "Hello World!" system (example: user shall be able to login and logout). Common impediments are purchase, license, hardware, network, and system related.

In an ad hoc PM practice (or traditional), there would be a huge "balloon payment" (to borrow from technical debt metaphors) at the end of the project to take this built system and install it in the real world. Iteration 0 is a way of beating this problem up front and then refactoring along the way as you learn instead of having to rebuild based on the mistakes uncovered at the end during "stabilization".

What do you think?

The "decline" of Agile is our own fault...

I've been thinking about this for weeks. I'm still struggling to verbalize it. I could probably white-board it easily face to face; but I'm forcing myself to blog about it to see if anyone in the community reacts.

I'll start with the triggering thoughts first...

1. Martin Fowler gave me a new term at Agile East 2009 last week. The term is "Semantic Diffusion". He described this as the current trend of terminology diversity, dilution, and mis-use as agile has grown. He implied that it is the cost of growth and success of the movement.
2. I had a great conversation with J.B. Rainsberger while he was in Philly that same week. We discussed my thoughts and they intrigued him enough for me to continue pondering.
3. In the last year, I've had many a peer either complain about random factions in our community, or express a "loss of faith" in the movement at large. Frequently this is triggered by some new certification group or consulting firm charging high rates to "help" a group go agile with the wrong intentions.
   

I've come to the conclusion that Agile has NOT outlived its worth, its terms, or its time as seem people have started to imply (I refuse to allow Agile to be a dirty word)... instead, we are doing a bad job in the community at sustaining its applied success.

Now to the core of my point... I summarize it all right now!

By raising the issue of Semantic Diffusion, are we calling out an issue that needs to be guided more pro-actively? Or are we using this as an excuse to accept "the inevitable"? Are we doing anything to cause this problem to grow?

I'm going to state right now that I think we are. We need to stop looking outward for the cause and instead reflect inward.

When I started in the agile community, I worked with several great coaches. These were individuals who had proven experience in Scrum, XP, and other practices. They were "journeymen" with an interest in showing others how to do it. They insured that I learned how to do it correctly. I wasn't on the internet reading and learning about it, I had hands on coaching. Thus, I came up to speed quickly and I had a very positive, thorough, successful experience.

When I think of anyone entering our community, I hope they might learn through this same type of experience. Unfortunately, I believe the opposite is happening more often than not. Why?

Well, where are those agile innovators and early adopters now? Many of those folks have worked in agile for so long that it is easy for them to take these practices for granted. Their Ri level experiences have allowed them to forget the Shu level needs. They've moved on to much bigger problems like Enterprise, Off-Shore, and whole system optimization. These are good problems to solve, but you have to teach several coaches to replace you!

I also hypothesize that every new "generation" in the community learns at a quicker rate. There are more resources available, more lessons documented, more case studies published. If you take the right path, it is easier to get up to speed than in the early days. With this, people more quickly become successful (or not) and the gap between the Shu and Ri level groups becomes wider. When I entered the community, I could work with the Ha level group; but this group is a smaller percentage of the whole now.

When I went to the Agile 2007 conference in Washington D.C. (my first), I quickly learned that I was a Ha level user. As many people were asking me for insight into my experiences as I could find people to ask about theirs. It seemed that there were a small group of people that were innovating, and the rest were split evenly between learning and using. Now I feel as though (based on the community at large), the Shu level group greatly outnumbers the Ri level group due to market hype. The Ri level group is looking forward to innovate and there is not enough Ha level people to support the Shu group. I commonly find myself talking to a Shu level person asking about agile that doesn't know about the manifesto and haven't heard of the many important names or bodies of work in our community. Whoever planted Agile in this person's head didn't do a very good job in my mind.

And here is where the bottom feeders step in! Want to know about agile? Let me re-purpose my old pitches with these new buzzwords and charge you money to learn about something the wrong way. Everybody is talking about it, and you can't find anyone to help... so I'm the best you've got. Slap a few acronyms on your resume and hand you a certificate on the way out and you'll be dying to hand me $1500 to keep up with your peers.

So... if you've been doing agile for over 3 years and you've been successful at it, what are you doing to help the community? Are you bringing your experiences to folks and sharing them? Do you venture into communities where there are people at a different level than you? Do you explain what worked for you, or do you tell them how their approach is wrong? Do you throw the book at people and shake your head, or do you wrap your arm around them and bring them into the circle? Are you too focused on innovating to see who we are leaving behind? Do you focus on everything a person is doing wrong, or do you help them find something to do right? Do they see the benefits after they've tried it, or do they just follow this new set of procedures you've described?

Why does this matter? Because unless you are going to spend the rest of your career working with the same people, you may someday be working with one of these poor lost souls who has been taught everything wrong. You may take a job with a great agile company to only find out that the leadership has it all wrong and make your life one living hell. If you don't want to argue about what agile really means in five years, or have to invent a whole new set of words for the same things that we lost to "semantic diffusion"... then we have to start working on that now. I'm not talking about holding down our turf and fighting every idiot that says stupid things. I'm talking about leading by example, sharing information, proving success, and helping others. These are the same ideals that started the agile movement in the first place.

If everyone is learning faster and the gap between Shu and Ri is getting larger, then we can't expect the people behind us to train everyone that is entering the community. We have to still spend some small amount of time continuing to mentor the people catching up to us. Somewhere in that talent pool is the next Gordon Pask Award winner.

And this is why I started blogging; I wanted to pass along the knowledge that people have passed me. I have now spent a year learning by blogging and sharing by tweeting. I continue to share through Twitter and LinkedIn conversations, but I've been forced to cut back on the blogging due to the recent addition in my family. I'm asking all of you to consider these points and not forget that not long ago, you were also new to agile. People need guidance on how to start with agile, and we shouldn't allow them to be led astray by the snake charmers and other bottom feeders latching on to our community. It is in our best interest to reach back and pull people up with us as we continue to grow. That's my challenge to you!

Semantic Diffusion is a disease that should be fought during the normal lifecycle of a movement. It is a rallying cry for continued guidance and debate with the newest members of our community to insure the tribe moves in a common direction. Do not try to control the community and define it, just get involved enough to make sure you provide opportunities for people to learn from your experiences.

Note: just to be clear, I am not stating that certain people have left their posts. Everyone still hears the voices Fowler, Martin, Poppendieck, etc. I'm saying that as the numbers grow, many more voices need to be added to this core set.

Agile East 2009 by Thoughtworks

I attended this conference Thursday October 29th in Philadelphia. There were two tracks on the agenda; I attended the business track and I brought a developer with me to attend the technical track. In summary, I was not invigorated at the end of the day like the Agile 2009 conference, but this is the cost of fewer sessions to pick from. The content was relevant, but not much was new for the folks like me who have been following agile for over 5 years. That being said, it was a networking opportunity with other agilists in the area. The following are the notes I took, there’s a few good nuggets in here-

Martin Fowler – The Essence of Agile

• Very good job of explaining the “why consider agile” pitch without using the word waterfall or calling out PMI/PMBOK. This made it less combative than other things I’ve heard and was a note I hope I can carry with me during my own conversations.
• Called out the concept of “semantic diffusion”… the current trend of terminology diversity, dilution, and mis-use as agile has grown. He said it is the cost of growth and success of the movement. I like this phrase and will use it moving forward.
• Stated that Scrum = adaptive planning without forcing evolutionary design ... thus Scrum is not good enough by itself. Agile requires adaptive planning AND adaptive technology (evolutionary design) to succeed. I counted that as another vote for hybrid agile, be it Scrum/XP or other.
  

Martin Fowler – The Value of Software Design

Great overview of Technical Debt. I’ve never seen it to this level of detail and I found this to be the most valuable talk of the day. His mention of recent debates with Uncle Bob Martin on this topic was civil and talked of their similarities instead of their differences. His short impersonation of Uncle Bob was hilarious (“Thou shalt not name your variables improperly…”)

Discussed the concept of tradable quality

• lower quality = faster = more features sooner
• UI & defects - visible to user
• good modular design - not visible to user
  

Proposed the “Design Stamina Hypothesis”

• no design - over time, more effort to get more done
• good design - over time, less effort to get more done
• each start out the opposite of this, but cross and become true within weeks (much sooner than most assume)
  

Discussed accidental vs. essential complexity

• Accidental - caused by sub-optimal design
• Essential - chosen, prudent
• Both are technical debt in his mind
  

Likened technical debt to a mortgage metaphor

• the creation of technical debt is the principal
• the interest is paid every time a new feature added
• with every new feature you should decide to pay interest (build on top), or pay principal (go back and fix core)
  

Explained the cost/value of technical debt

• interest payment cost = story estimate - story estimate if debt was fixed first
• principal cost = estimate cost to fix principal/issue
  

Causes of Technical Debt

• You don't know how to do good design = reckless, inadvertent debt
• Ship now, fix later = prudent, deliberate debt
  

Debt is not right or wrong, it exists; the question is how do you deal with it?

• Being reckless with your debt is like maxing out your credit cards

Martin Fowler – The Controversial Topic of Diversity in our Industry

There is a lack of diversity in profession (Women, African Americans)

They under represented compared to population… Why?

We have a problem, especially when you bring in badly treated history for these people

This is a power issue, what do we do about?

• Don't shift imbalance of power in wrong direction with inappropriate actions
• Humor only works for lower power people towards greater power people
  

It is important for our profession that we care about the professionals in our space (both peers and customers)

• Software development is a leading role in the world!
• If we block access to these minority, then we lose access to potential talent
  

Carl Ververs – Change Leadership

If you have followed Linda Rising, Esther Derby, Diana Larsen, Dale Emery, or some of Alistair Cockburn’s work on teams, people, trust, communication, psychology, etc… then this session was a repeat of pieces of their work I’ve seen in Agile 2007 and Agile 2008 or their books or blogs.

That being said, many people in attendance that day were new to agile, and this was a great session for them!

Joseph Zenevith – Agile Estimation Patterns and Pitfalls

If you have heard about agile estimation (as a process), but are new to agile and trying to implement it… this was a good session to help you get started and avoid the pitfalls. Discussions around sprint zero, sizing, etc.

Ross Pettit – The Financial Implications of Agile

This session was over my head (and most of the other attendees based on the body language). Thank goodness they did this over lunch. That being said, it was perfect for a CFO or anyone focused on how projects affect the profit margin of the company. I took a few notes-

Capitalization - Agile projects have a higher % of potential capitalization than traditional PM

• capitalization = good = helps profitability
• Forrester claims that agile projects are 40% cheaper
  

Cash Flow – agile projects don’t mortgage the future by deferring integration, testing, NFR’s

• Less “balloon payment” surprises at the end of the project
• Story/Backlog Item = $ turned into a result (not $ turned into a % effort complete)
  

Yield - a story is a focus on maximizing yield vs. containing cost (invest in the right stuff)

Volatility – investors hate since agile since it isn’t predictive/deterministic

• old belief system is false though, so it is about education
• agile projects will fail faster, this is a risk mitigation
  

New Exposures – failed projects and lost people can’t be capitalized

• can cause a liquidity problem
• solvency is a problem if people are lost (lost investment)
• mitigate by aligning finance planning to iteration delivery and diversify investments
  

Greg Reiser – Redefining App. Dev. w/ Offshore Agile

Because I have experience in this area, I didn’t take any notes. My personal experiences were on par with their discussion. The main message- Make sure you are conscious about going down this path. It will not save the amount of money you believe up front, it can provide access to talent you don’t have, and it can be done (but not easily).

One thought that popped into my head as they were talking: How do you minimize / mitigate causes of technical debt in the offshoring model? Do you review the all code? Woah… someone should tackle that problem!

Tiffany Lentz & Manu Tandon - Applying Agile in a Non-Technical Area of the Org

This was one of the main reasons I wanted to go to this conference. Unfortunately it was a disappointment. It was a case study (I never find these as helpful as other sessions) and I missed that it said “applying” in the title instead of “convincing”. I need ways of pitching Agile to non-tech people. The session was about Scrum and a PMO setup for two teams that included non-software people (but many of the same roles you’d find on a scrum team).

One quote I liked: think of work completed as consumables downstream, not deliverables! (Interpretation- make sure people are supporting something, not just checking work off!)

The PMO had an interesting approach; instead of mandating process, they mandated required practices with multiple ways of achieving them. Examples included: estimation by the worker (not manager), work must have acceptance/done criteria, prioritization by the customer (not mgr). Because of this approach, “business value delivered” became an important discussion point within teams, unprompted and on its own.

Best Of- you've listened to me ramble for over a year!

For those of you who follow this blog, I apologize for my recent calm. I've tried very hard to provide you value, and you've rewarded me with wonderful support, great conversations, and plenty of good feedback. But... in case you haven't heard, I do have a good reason. Before her arrival, I knew this might happen and tried to combat it with my pre-written Quote Series... but I underestimated how long it might take to regain normal life flow (this topic was raised in my last personal retrospective).

I've had the energy and sleep to continue absorbing from the community; but the only thing I've been able to contribute back is my agile focused Twitter stream. It has been over a year since I started blogging and I'm pleasantly surprised by the traffic and global coverage of my visitors. Until I can get back into the rhythm of things (hopefully in the next month), I wanted to leave this "Best of Agile Commentary" list in case you joined me on this journey mid-stream.

Top 10 blog posts in the last year based on your clicks (in reverse order)!

1. Participate in change, don't expect it to happen Agile is not just about managers changing
2. Cadence... I used a metaphor of cadence from the military to understand stand ups and feedback loops in agile
3. What is Shu Ha Ri? An overview of Shu Ha Ri… a very important learning principle
4. What is sprint planning about? Focus on the core intent behind sprint planning
5. Shorten your iteration... One of my first posts… shortening your iteration avoids mini-waterfall
6. Walking the board... We were one of the early adopters of the "walking the board" approach where we don't follow the "3 questions" in our stand up
7. Create a proper estimate scale... Popular how-to on creating a story point estimation scale
   
8. UX and Agile, how do they mix? Riding on my past usability experience, one of my first posts about User Experience within Agile
   
9. Snake on the wall! A great way to easily put your finger on waste and distraction with the team… every time this post gets quiet, it suddenly fires up with traffic again after a few weeks from a new source!
   
10. Post agile, one third of you will be gone... Most popular blog post ever about my first agile transition. It created controversy, was picked up by Kent Beck and flagged high on Reddit. Some even went so far as to say I sounded like a cult-member! You either get it, or you don't. When it happened to me, I was a convert, I'm now a pragmatist.
    

And here are three of my favorite notables that didn't make the traffic-based cut:

1. Puppy vs. Pitbull... One of my first posts about team dynamics and personalities
2. Before agile came along, life was easier for me... Reverse psychology at its best about the good old days
3. Bored in the standup? Raise your hand! How we combat tangents during our stand up

Thank you for your continued reading, challenges, and criticism!

It's all about getting groceries...

When the average college student goes to college, they suddenly have to fend for food themselves. Most campuses provide some type of food source insuring students don't starve to death, but cafeteria food isn't always up to snuff for the tastes of the average 18 year old so they wander out and make their first true grocery run. How does this typically develop?

Phase One- Wander around and find stuff that seems like a good idea.
Result- Realize very quickly within a few days that you forgot stuff that you needed and what you got wasn't really a wise choice. That 3 tub pack of chocolate Kozy Shack pudding seemed like a good deal until you went home and ate it all within 24 hrs. Now you need to make another trip for food that will actually give you some energy for mid-terms.

Phase Two- Realize over time that you don't like wasting time grocery shopping; make a list of groceries and go get those items.
Result- This helps add efficiency, stay within a budget, insure completeness, and aids in blocking useless (or unhealthy) purchases.

Phase Three- You quickly get bored of canned food, cheese n' mac, and spaghetti; it's time to decide what you want to eat/cook in the coming week, then make the grocery list
Result- You shift from always having stuff in your kitchen, to having what you need to make the right meals from that stuff. By working backwards, you insure you are happy with the outcome.

So, what does this have to do with agile or project management?

Phase One - I can't tell you how many companies have a development team that just wanders around and does what seems will help run the business or quiet the screaming managers. Kind of like the hungry college student's stomach, this is simply an id response to filling the basic needs. Unfortunately like the cozy shack pudding example, this doesn't always turn out best for them either.

Phase Two - There comes a point of time where the team can't keep everyone happy. Work starts falling on the floor and some things don't get done. Organization is suddenly required. The team has to start making lists and prioritizing work. They have to consciously decide which things won't get completed to insure that the right things do get completed. They need to stay focused on the list and not everything else that draws their attention (backlog management anyone?)

Phase Three- To really mature as a team, you have to start focusing on your DONE criteria. What is being accomplished? What is the goal you are trying to reach? What is the business value being achieved? The work isn't DONE until you meet this!

Now, lets assume that college student is growing up... or maybe they are maturing their cooking to impress someone they are dating:

Phase Four- ask the people who ate the food what they liked and didn't like. Adjust selected meals accordingly and then adjust the grocery list.

For the agile team... this is the retrospective.

Bees self-organize, why can't we?

There is another interesting thread on LinkedIn's Agile Alliance group. I caught up to the conversation late, so instead of adding my two cents, I just want to share the highlights here.

The Question:

In another discussion thread I saw many references to "self managing team" as being one target or goal for any Agile team.

Here are few hypothesis related to that:

True or false?
1. Teams can only become self managed if they have worked togather for long.
2. Teams (and through that companies) will never get to take advantage of their ability to be "self-managed" since the members will be transferred to different projects after they have completed their existing project.

I think the first response is the greatest, so I applaud Bob MacNeal's response:

1. False. Complete strangers are capable of self-organization. Bees do it. Humans do it too.
2. False for some teams. True for most companies. People have an amazing capacity for self-organization. Organizations habitually muck this up by layering in a mojo-killing culture of command-and-control.

Mark Ferguson:

A team that can't self-manage their own internal dynamic will fail. A manager can't micromanage each individual's interactions with other team members, although some do try!

Wayne Peacock:

Success comes only after a series of failures. Scrum or Agile is no silver bullet. The best thing about Scrum is the constant inspect and adapt cycles...

and finally, Sharan Karekatte:

Self-management is what Scrum teams do. They actually manage the user stories and tasks from the Sprint Backlog on a daily basis. They are not told 'how' to complete the work, but 'what' the Product Owner would like from the team in order to deliver the ROI and fulfill the Product Vision.

Bored in the standup? Raise your hand...

I just read this interesting post about a scrum team that borrowed the concepts of yellow and red cards from soccer to aid their standups. 3 yellow cards or 1 red card means "move on".

Unfortunately, I live in a country where soccer is not the biggest sport... and I'm sure we would just misplace the cards.

So, let me share what has been working for my team for over a year now...

If anyone in the group feels that the current topic is not relevant to the group, they slowly raise their hand. They do it slowly to not be obtrusive and rude. If other people agree with this person, they can decide to also raise their hand. If there seems to be visible consensus, the people speaking must quickly assess their conversation and decide how to close it. They can either put it on the parking lot, or realize they aren't getting anywhere with it and just stop.

The parking lot is a list on the wipeboard in the team room. The person closest to the board writes the topic and the names of the people who are involved. At the end of the meeting, those people stay behind to pick the conversation back up.

If the person raising their hand is alone when their hand is fully raised, they suddenly realize that they are alone in their stance and drop their hand. At this point they wait for the good of the team since clearly, everyone else finds the conversation valuable.

And yes... our standup is short. We have about 15-20 people every day... and we average about 17 minutes (15-20 minutes) even with these included conversations.

Recently, we had an amusing moment when someone raised their hand on themselves...

Quote Series Part 7 - Philosophy (contd.)

This is part eight of the series, to see what this series is about, click here. This is the last in this series.

Quotes on "Philosophy"

Make time to make it right, or be prepared to do it again - Denise Caron

Embrace new directions... not everything you do will be used, sometimes, the target changes. Re-aim and move on! - Denise Caron

Change is constant... don't fight it, leverage it. - Denise Caron

Don't fall in love with your product, someone will be there to change it, it's a promise. - Denise Caron

Blindly following rules is a fools errand. We have enough grey matter to discern when the rules are helpful and when they are not. We have the responsibility to continuously measure whether the rules are helpful, or whether they are not. - Uncle Bob Martin

It is solely and utterly the team’s responsibility to figure out what to do, and to do it. - Ken Schwaber

"Better" is typically a word leveraged by those in control (eyes of the speaker). "Appropriate" is typically a word referencing those affected (surrounding group). We should seek that which is appropriate, not that which is better. Avoid elitism, blanket statements, or viewpoints of limited individual experience. - Kevin E. Schlabach

Without prioritization, nothing is a priority. - unknown

The practices are not the knowing: they are a path to the knowing. - Ron Jeffries

To tolerate a problem is to insist on it. - Ron Jeffries

If it hurts, do it more often - Martin Fowler

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 7 - Philosophy

This is part seven of the series, to see what this series is about, click here.

Quotes on "Philosophy"

...initiating requires a willingness to look foolish, stupid, or uninformed. To initiate great things, you must truly not give a damn about what people think about you. - Seth Godin (Tribes book)

what you call things and their meaning matters cuz it sticks in people's mind - Twitterstream from Lean Kanban 2009 conference

No good idea can be judged by the number of people that get it - Ron Jeffries

Learning faster than our competitor is our only sustainable competitive advantage. - Denise Caron

Change happens fast, our competitors will not wait for us to get ready. - Denise Caron

Self-organize... don't wait to be told, be accountable and stride forward. Self correct! - Denise Caron

Satisfaction comes from closure- open-ended tasks can't be closed - ObjectMentor coach

Managing the project is MANAGEMENT'S responsibility... do the best you can with what you know now and program as though you have time to do a good job. - ObjectMentor coach

If you deliver every day, then no deadlines are special (or scary). - ObjectMentor coach

If it doesn’t hurt, then you’re probably not changing enough. - J. B. Rainsberger

If you just do the same things, only faster, then you’re missing the point. - J. B. Rainsberger

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 6 - People

This is part six of the series, to see what this series is about, click here.

Quotes on "People"

If you don't make mistakes, you are not working on hard enough problems - Frank Wilczek

Open yourself to critics and take your capabilities to new heights. - Denise Caron

If you goof, apologize. If you apologize, mean it. - Seth Godin

If you want something to happen your way, try asking instead of demanding. - Seth Godin

If you’re getting feedback, realize that the person must care a lot to have sent it. - Seth Godin

Anyone who uses the term “resource” when referencing people has to put $1 in the “inappropriate comment” jar! - unknown

No matter the circumstances you can always improve. You can always start improving with yourself. You can always start improving today. - Kent Beck

A tool is nothing without a skilled artisan to handle it. - unknown

Don't inflict change on people. - J.B. Rainsberger

A dead scrum master is no good to anyone. - unknown

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Does generalized roles mean a team of equals?

A very interesting discussion on LinkedIn got me to thinking...

If a Scrum/XP team adopts pair programming...
and everyone should be able to pick up anything...
and anyone should be able to test or fix the build...

does that mean there is no longer a need for team lead? tech lead?

Hmmm...

Interesting discussion.

My thoughts:

...every Agile/Scrum team I've been on has had "leaders" that fill the roles of project or tech lead. In my mind, the advantage of agile is not to normalize the team to a bunch of equals, but to reduce the distance between the outliers. Keeping some diversity in the team is critical to team wisdom (read Wisdom of Crowds).

Feel free to join in the discussion.

Quote Series Part 5 - Code

This is part five of the series, to see what this series is about, click here.

Quotes on "Code"

Code degrades naturally, it needs refactoring constantly - ObjectMentor coach

Treat the system as a growing organism... failing tests equal the need for a behavior modification - ObjectMentor coach

Always check it in in a better state than you checked it out. - ObjectMentor coach

Don't let code sleep - things happen while you're asleep. (tests must pass on "sleeping" code) - Tim Ottinger

Switch pairs whenever you need to, it is not an insult but a way towards knowledge transfer and efficiency. - ObjectMentor coach

Refactoring: A series of small steps, each of which changes the program’s internal structure without changing its external behavior - Martin Fowler

Code left unchecked-in for a week is like milk unrefrigerated for a week. Eww. - James Shore

By far the dominant reason for not releasing sooner was a reluctance to trade the dream of success for the reality of feedback. - Kent Beck

Reading other people's code is the best way to learn. - Uncle Bob Martin

The mere presence of a great source control system doesn't obligate anyone to use it in a structured, rational way. No. That takes discipline - Jeff Atwood

Architecture without executable code is just an hallucination - Ivar Jacobson

Best code = non existent code - Amit Rathore @ Lean Kanban 2009

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Burndown charts as an indicator...

Jack Milunsky posted an interesting point in the Agile Project Managers group on LinkedIn. I normally agree with him and like his work (actually, I still do here)...

His core point is quite valid. The point of the burndown shouldn't be to drive a team towards focusing on the team's ability to match a perfect trend line. This is something I totally agree with. I've seen teams with perfectly straight lines on their burndown and I've learned that this is a big flag! That being said, his following sentence:

I believe that the underlying goal should not necessarily be about staying below the estimated time line in a burndown chart (although this would be nice).

..might set the wrong tone for a newbie to agile. I wanted to address that here.

Joe Blotner captures this well with the following statement:

Scrum doesn't solve your problems, just make them visible, so you can solve them.

...which I'm sure that Jack would agree with.

But... I want to state that I think the main goal of a burndown IS to trend downwards. This isn't the same as staying below the estimated line, but I want to be clear... if the trend isn't down, then you are going backwards. As a business person (PO), I would not accept a burndown going up or flat too long. This is a sign that I'm spending money and there's no sign of progress (both in uncovering all the unknowns and in making progress). I'd almost prefer seeing the line spike up and then start working back down so I know the problem is behind us. A flatline always triggers me to ask "but when will it end?"

That being said, if this is what was happening before agile, then Joe is correct. Agile has helped you focus on this and now you can try and fix it.

Little nuances I know... but I wouldn't want to see a new scrum team looking at their burndown and saying... "eh, that's okay for now... let's figure it out in a few days (or at the end of the sprint)."

Agile is not a metric, it's a journey...

As ridiculously fluffy as that sounds, it is true! You can't measure your team's agility and say, "Yup, we are there!". It is a mindset. All of the agile approaches (XP, Scrum, Lean, etc) are simply schools of thought.

Jai put up a very good post which triggered this discussion:

... Then he added that if you are not doing pair-programming or continuous integration, how can you say that you are agile. There I got the idea that what he was confused at.

Sometimes it is hard for people to differentiate and digest the differences between the Agile practices and many of the XP practices. They somehow get mislead by the idea that the XP practices etc are part of Agile. And Agile enforces these practices with it.

Many interesting comments are starting to come in, but mine was this:

I’ve dealt with this myself. I try to explain that the manifesto was the result of many people with different ideas on how to solve the same problem. The manifesto is the solution to the problem strategically. The “denominations” of agile are tactical approaches to solving the problem. Scrum is product and schedule focused, XP is engineering focused. And oh yeah, many of them have converged over the years.

Contrasting XP/Scrum with Kanban, Crystal, Lean, etc also tends to help. When people can see the common outcomes from the different approaches, it starts defining Agile by the results and not the chosen methods.

Follow the discussion further here.

Quote Series Part 4 - Metrics & Managers

This is part four of the series, to see what this series is about, click here.

Quotes on "Metrics"

Another purpose of measuring capacity is to improve throughput. If you plan for less than your capacity, you get less done than you could have. If you plan for more than your capacity, you get less done than you could have.

Having a plan with "enough" work in it less some slack to improve the probability of meeting commitments increases the amount of work that gets done compared to planning for too much or too little. - Kent Beck

Once you start measuring something, you can easily end up in a situation where the measurement itself starts influencing the things you want to measure. - unknown

Quotes on "Managers"

Management owns the 4 T's (time, talent , treasury, target )... everything else is up to the team. If you have a issue that affects one of the T's, then ask management for input. - Tim Ottinger

Message to Management - eventually, you can push too much change at once.... back off and let the team normalize. - JB Rainsberger

In my experience, it is the leader’s (manager’s) job to intervene in the case of inappropriate behavior, and when he or she does, the rest of the team will be grateful for the intervention. It is being a “servant” to the whole team by suppressing the individual behavior that will keep the team from being successful.

It’s not about telling people what they are doing wrong. It’s about constantly steering everyone on the team in the direction of success, and never letting any individual compromise the progress of the team toward success. - Mary Poppendieck

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 3 - Stories

This is part three of the series, to see what this series is about, click here.

Quotes on "Stories"

Devalue the dollar - story points should be small, 1 pt - ObjectMentor coach

Stories add functionality, not technical layers. - ObjectMentor coach

If all stories are less than 5 days, we might not need a task breakdown. - ObjectMentor coach

All stories should be small enough to be delivered in less than a week. - ObjectMentor coach

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

A further experiment in ScrumBan…

I’ve recently evolved my company process to include WIP limits, but before I share this story, I must first provide the following background.

When I started at this company 2.5 years ago, there was a large divide. I was trained in PMI, was a CSM, and I was a staunch advocate of XP/Scrum by the book. On the other side of the divide, the company had little process, little documentation, no source control, and made minimal attempts to plan work a day or two in advance. One could say this was a recipe for disaster, but this is a startup… and the point of hiring me was to improve as they doubled the size of the company.

Several things have happened since then:

• retrospectives and weekly iterations were quickly adopted
• source control is now in place
• we put tools in place to manage our work (VersionOne)
• standups have become common for both teams and projects
• we’ve modified the 3 questions
• we now use a ScrumBan inspired board
• most importantly, I’ve learned that there is more to Agile than Scrum/XP… I’ve become an interested follower/borrower of Lean and Kanban practices. This is an important step for me as a coach since not all environments fit the Scrum/XP model. A mixed bag of tricks helps win the debate, especially when it is gamed against you!

So, what is the new problem of the day? I’ll call it the plan-to-budget problem. I’ve struggled for 2.5 years to find a way to get the company to plan work based on the available capacity. We’ve always had “BUT-we-need-to-do-ALL-of-it”-itis.

I’ve explained velocity and scrum, but this was viewed as too expensive to pursue. “Why should we estimate everything when we only care about certain parts of it meeting a specific deadline?” This is a good point. If only a small portion of our work is deadline driven, and the rest is “do as you can in this order”… then putting time into estimating and projecting everything might lead to waste. (Although this is contradictory to “I-want-all-of-it-by-next-month”-itis.)

Thus, I reduced focus and tried a top5 concept. Hey CEO, pick only 5 things that are important for this week, we’ll do our best with that set before touching other stuff. This worked well for a while since it forced us to admit we can’t get everything done and focused on fewer items. It reduced our “in flight” work… for a while. Two things derailed this approach.

1. The CEO found ways to assign work to people outside the top5 set (most people can’t say no to the CEO/founder when approached).
2. Not all items were the same size (scream together now: ESTIMATE!) so 1 large top5 item could clog the whole pipe.

We let go of this concept and evolved our breakdown further. I was happy to push for smaller stories and quicker closure. Appropriate sizing is a great stress reducer for the team, especially when you involve them in that process. But we slowly returned to our problem of demanding more work than we have capacity for.

This is where I started thinking about Kanban’s WIP limits. After all, this would fit our model well, and we already have the board in place. Unfortunately I knew that this would be bypassed just like the top5 limit. Our problem was a cultural problem, and I had to tackle it at the source.

So, we’ve started a new trial change in our process. After 3 hours of debate, I was able to convince management of the following (meaning they agree with these):

• Giving one person too many things at once will slow down throughput
• Swarming is a good way to get things done faster
• Saying we have to do everything doesn’t mean it will get done
• Not deciding on priority means it will get decided by the people doing the work
• Our biggest issue might be over-committing (actually, over-requesting since nobody was necessarily committing)

The solution? Headshots! I made little headshots of each team member. We plan the queue of work and then prioritize it. Then the CEO points at a card on the board and says “I want that first”. We put 1-N heads on it based on availability, capability, and size of work. The CEO keeps pointing at items until we run out of headshots. If he points at big things, he picks less stuff; if he points to small things, he can pick more (Budgeting to capacity!) When a person frees up, they move to something else on the board. Everyone on the team might have a few things assigned to them in VersionOne, but they KNOW which item is most important (the one with their head on it on the board). Everyone on the team focuses on helping each other finish these items before starting new things. All of this is clearly transparent on the board! It's not rigid like scrum velocity or Kanban column limits, but it is a place to start and a way to prove value (a door to further improvement).

Summary: We aren’t doing true scrum, but some of the pieces. We aren’t doing true Kanban or Lean, but some of the pieces. We aren’t truly self-empowered, self-managed… but somewhat. I would be the first to declare we aren’t “agile” as defined by most in the community. BUT, I’m getting to the point where I believe we have a system that works for us (2.5 years ago, we were a demand-and-control company led by the CEO). It’s a hybrid of many agile approaches, driven by my teaching of agile philosophies, allowing this company of ~70 work better together. Hopefully this new change will help us overcome our capacity/planning issues, only time will tell.

Agile FAIL!

Sometimes I feel like a fireman... I read things that just don't make sense and I want to pour water on it and put the fire out. I have slowly come to realize that there are more voices proclaiming stupid things about agile than I can counter.

Let me share with you what bothered me today...

Agilists seem intent on advocating their rather extreme view of agile including no documentation, little planning or architectural design and less control. The mantra is ‘give the software developers free reign and you will get better software’.

Yeah... this is a FAIL! (on the part of the "Agilists")

Most IT projects exist to enhance the capability of the organization.

I'm not completely sure what "IT project" means in this context... but they don't exist for the organization. All projects are about business value and enabling profit.

Partial Fail?

...at the very least a minimum of documentation to prove the IT team and its immediate customers understand their scope of work and other constraints and know how they will achieve the outcomes needed...

Documentation is needed in a minimal sense... but whatever happened to working, accepted, purchased software as the best measurement?

Partial Fail!

The agile extremists may do well to consider [self discipline] and focus on meeting the needs and expectations of all of the stakeholders involved in their work.

Very good point. Whoever this person got their impression of agile from.... VERY BIG FAIL!

Quote Series Part 2 - Estimates and DONE

This is part two of the series, to see what this series is about, review part 1.

Quotes on "DONE"

One of the goals of the sprint is to measure what you have done - ObjectMentor coach

Burn-up should happen every day to stop scrunch stress (all things shouldn't finish on the last day) - ObjectMentor coach

If we’re not shipping our software when it’s ready, it’s poor business practice. If we’re not sure whether our software is ready, it’s poor software practice. - Ron Jeffries

Make Ship Happen - Todd Little

Quotes on "Estimates"

Ability to estimate correctly is not an ‘ability’ … it is a fluke and lucky guess - Roy Morien

Estimates only help us take action to get to the next step - unknown

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

Quote Series Part 1 - Agile

Over the years, I've collected quotes from my agile surroundings. This collection has been growing for almost 5 years now. I've used it to inspire my teams by writing a new quote on the top of the team's wipeboard every few days. It keeps them thinking and on their toes. I've decided to do a series of blog posts to share them with all of you. (it's also good filler while I'm on leave due to the birth of my 2nd child and many in the industry are at Agile 2009.)

Quotes on "Agile"

My definition [of agile] is that you accept input from reality, and you respond to it - Kent Beck

An agile manager must: manage & deal w/ risk, be results oriented, have high energy, be a team player, have multi-tasking ability, be improvement oriented, listen first and speak second - Lee Henson

Agile is:
- A project management process that encourages frequent inspection and adaptation
- A leadership philosophy that encourages team work, self-organization and accountability
- A set of engineering best practices that allow for rapid delivery of high-quality software
- A business approach that aligns development with customer needs and company goals
- Mike Cottmeyer / Jon Strickler

Deliver Frequent Releases, Empower Teamwork, Inspect and Adapt, Build Quality In - Karl Scotland

Agile != following steps, Agile != tools training
Agile = individuals & interactions, Agile = Collaboration & Teamwork
Agile = Environment Matters! Agile = learning from experience
Agile=reflection, Agile is an adjective not a noun!
- Rachel Davies (Agile 2007)

Agility might be said to be about encountering all the problems so early and so often that the effort to fix them is less than the pain of enduring them. - Ron Jeffries

Note: where I can, I've credited or linked the source of the quote. Finding the source of a quote is like chasing a ghost. When a mentor says something witty, you might not know they are quoting someone else. If you are aware of a more appropriate source for any quote, PLEASE put a comment on the post and I'll do what I can to validate this. I mean no disrespect to anyone. I believe the risk of incorrect citings is outweighed by the value of sharing these wonderful nuggets.

The PO is part of the team, get over it!

The other day I posted about charging a fine for being late to the standup. I knew this would get some reactions, but one thing I should have been clearer about was that this wasn't a team problem, it was a PO problem. Sure enough, several of the LinkedIn forums got fired up over it and some heavy hitters had some good points to make (thanks Rachel Davies!).

I agree that this concept can backfire (fine, I'll pay the fine so I don't have to come), and there are solutions to that (double the fine for each offense). I also agree that if the majority of people need a fine to appear at the standup, then there is a much bigger problem occurring.

So, that background aside... one of the conversations appropriately focused on the issues we were having with the Product Owner. Why didn't he want to participate? Why was this an issue?

Lesson learned on that point: when this company went agile, we trained the developers, then the QA and analysts. Following the rules of Scrum & XP, we understood the metaphor of the Chicken and Pig very well. Unfortunately by following this rule, we optimized the team but de-optimized the whole value stream. It wasn't until the PO's got some agile training that they understood how to evolve for the new agile world.

This post is in response to the following comment in regards to fining the PO for being late to the standup:

Why wait for the PO for a stand up? The PO should not be in a position to cause the problem. We try and utilize the Chicken and the Pig approach.

And my response:

There are many people who feel the PO is a member of the team: http://www.danube.com/blog/dan_rawsthorne/who_is_the_project_manager_in_scrum
Thus making them a Pig.

Also, the chicken and pig concept is dead in my mind. It's a coping mechanism for bad managers: http://www.langrsoft.com/blog/2008/08/pigs-chickens-and-asses.html

As our agile team matured, we found that many of our early retrospective discussions led back to the fact that the PO wasn't accessible enough. When your PO is the voice of many customers distributed globally, the PO is very important. If you have direct access to your customers (example: internal employees), then this might not be as important.

The last thing you need is for a team to go to the sprint review and demo lots of software that fails PO acceptance. Instead of making decisions in his absence and hoping they were right, avoid this waste and just treat him as a team member. If you can't do this, then get a proxy in place (lead analyst), or get direct access to the most important users to reduce the risk (beta customer).

Managers are not Super-You's...

Nancy McCall wrote an interesting post about somebody's thought that “Your boss should do your job better than you.”

Her points were:

- Managing people requires different set of skills than developing software, or whatever the job is of the group being managed.
- Proficiency in any area is worthy of respect, regardless of whether is it your area.
- It is not all about you.

She goes into further detail, feel free to read the full post.

I commented further:

Agree. I’ve modeled my management career path after those managers that were best at enabling their team to do something great with their collective powers. This typically meant that the team was collectively much smarter than the manager, but it was the manager that helped them get there.

If I had to be a better coder than the people I help manage, I’d be out of work. Instead, I’m a valued person in my organization because I can do things they can’t… and they come much more naturally for me than for them.

Say what you'll do, do what you say...

I've been noticing something new lately. I schedule a meeting and everyone confirms it, then about 30 minutes before the meeting several people come up to me in person or by phone to confirm that we are still having the meeting.

What?

Am I that distrustful or unpredictable? Is there a history of you showing up for meetings and them not occurring?

I'm confused by this... but then I got to thinking about it more. I realized that I've had friends or family do it also with gatherings. This behavior has risen in the last few years. What I don't know is if it has anything to do with our constant micro-distractions with technology, or a decrease in respect for each other.

Don't get me wrong, it bother me that people waste my time to verify that I won't be wasting theirs... but what I'm really concerned about here is that people do this to protect themselves against something that must happen to them all the time. This something is hugely disrespectful. It's the act of not following through.

I was raised in a community and culture where you stated what you were going to do, then you did it. If for some reason you couldn't, you had better set expectations in advance as soon as you could. If you didn't, you paid the price by harming that relationship. You didn't deserve to receive mutual agreements from that person in the future after that mistake.

Agile is about this. Standups inspire this. Reviews demand this. Planning and Velocity requires it. WIP limits assume it (I've seen managers bypassing WIP on the sly!). Retrospectives if run properly will inspire it also. Without it, everything starts to fall apart.

So people: say what you'll do, and do what you say. Follow through. Get to DONE! And don't limit this to your work, but include it in your relationships with other people.

Think about how much time we can save not second guessing stuff anymore!

Late to the standup, pay a fee! (or not?)

In my last company we realized something very quickly. If the standup meeting is only 15 minutes long, then anyone who is 5 minutes late probably causes the meeting to extend by 30% while we repeat stuff. If we aren't repeating stuff for the late person, then you have to question how engaged that person is in the team.

With that in mind, we started complaining about lateness over 1 or 2 individuals... one of which was the PO. His initial solution was to start without him. We poked at this and it became "meet without me". This turned into our marginalization of his input, which degraded to major problems during sprint review because the customer (PO) wasn't on the same page as the team.

So, we agreed to make this marriage work and the PO said he'd make an effort.

The cycle started over. He always had excuses. This meant that other people started riding his coat-tails and coming late too. Eventually the standup was a mess because it wasn't predictable. People who were on time got punished by those who were late (and didn't respect the team).

How did we solve it? We added a fine. Now, Foo wrote a great blog post about how this will backfire. Once you put a price on something, it's valued a different way. Sure enough, our PO threw $50 in the goldfish bowl and stated "That will cover me for the month and buy pizza for the team" as if he was doing something good.

New rule... $1 / day for being late, fee doubles for consecutive days.
Outcome: PO is present every other day and buys pizza for the team every month or so. This was a compromise everyone could live with.

Before agile came along, life was easier for me...

The problem with Agile is that it helps us realize early that there might be problems. Granted, this gives us time to solve the problems and get the project on track, and it allows us to have a higher success rate.

But I miss the good old days where we happily worked for months until the death march started. It allowed us to stay blissfully happy and then blame management for the last 3 weeks when things went wrong. Some of us would get good at finding long projects where we could work for months on lines of code and then bail on the work and jump to another job or company right before it went into the crapper. Becoming an expert in our skillset was simply about perfecting our selection of projects and timing them well.

Now we actually have to be on top of our game every day! That's a little bit more challenging than I expected. I went and got this computer science degree so that I could sit in a cube and write code and get paid lots of money for it. What's going on here?

Yeah... unless this is the first time you've read my blog, you know how I truly feel!

Read the Cutter Consortium's version of this viewpoint.

Agile Documentation, what is it?

Elroy Serrao asked a question leading to a good discussion about documentation on LinkedIn's Agile Alliance group.

His statement:

The whole "document via index cards" idea felt a bit weird though. Partly because I haven't been able to really view physical "index cards" as something that can be tracked, searched etc over a long period of time. So I was wondering if anyone would be willing to share their experiences, best practices etc. in this area.

The following is a couple of the high notes:

From Siddharta Govindaraj:

Think about how much value a piece of documentation produces. If you think it is worth it, then go ahead. If you feel it is overhead then dump it.
You need to ask yourself three questions: Who is the documentation for? What is it for? How will it be used?

From Levent Gurses:

There is no way in the world that I, or anyone else on my team, will spend time digging a cabinet of index cards to find out about the details of a story that happened 3-4 months ago. It will just not happen.

Instead we use a modern WIKI, like Confluence - which among other things keeps page versions. Requirements and stories captured in Confluence are always current and traceable. Combined with SCM labels and release notes, any person on the team is always 100% sure what's in Production, what's in Testing and what's currently being developed.

From Kevin Schlabach (me):

I'm most aligned with Levent's answer, but here's my simplistic cut at it-

If you do TDD... add a database & architecture model to your tests and you have your tech documentation (as much as is worth keeping up to date).

If you use automated Acceptance Tests... add a domain model and you have your business documentation.

If you use an electronic system for backlog management... you have your project documentation.

If you pair program and rotate pairs daily, you insure knowledge is spread throughout the team.

If you layer on a wiki, you can capture conversations for the few days it's needed until working software is built.

If you don't do some of these things, you might require more documentation to cover you when you want to ramp up new people or explain your API's to other groups.

This is a simplistic overview, but what I'm getting at is that you still need some documentation that goes beyond your index cards, but it can be a living, breathing part of your process.

Read up on some of Alistair Cockburn's work (Crystal). By applying game theory, you always think about working today to insure success (wins) tomorrow. Documentation is meant to be a way to survive in the future when needed.

From Gary Tinnes:

I have a rule: “the amount of a document that is read is inversely proportional to its size”. If you document, keep it short with lots of white space to make it look smaller than it really is. Focus on bullet points (clarification if needed) and graphics.

DONE vs. Complete...

From time to time this topic comes up. Today it was raised in my RSS feed by Boggin of the EscApologist blog. He posits "When is a task Done"? He's on the right track, but I was worried his list was too prescriptive. I see DONE criteria as a specific area of coaching and focus for all agile teams, and I think it is more important for people to understand the reasoning behind DONE than have a solution handed to them. This will allow them to find the right answer for themselves. So, here is the nugget I left for him:

Simply put, “DONE” is the full list of stuff the team needs to complete to put the story (set of tasks or full work effort) behind them. If there is work still remaining then it isn’t done because this work will either become technical/business debt, or will delay the next work while it is being completed. This is why done can’t be measured by deployed.

This is also why teams I work with are allowed to use the word “complete” somewhat freely, but they use the word “DONE” with respect and reservation.

For every team, this list is unique… and every team should manage/evolve it as they mature. It is a critical part of agile success.

Oh yeah… and it should be filtered through the lens of business value (not tech complete), but this isn’t an issue if your team is cross-functional.

Anything you would add?

Post agile, one third of you will be gone...

About 6 years ago, I was at a company going agile... I didn't know much about it yet. I didn't realize how it was going to affect me and my career path. I had no idea that it would invigorate me and show me a better way. But there was one thing I heard immediately that I did understand, and it excited me.

The head of the division stood in front of 3,000 employees and stated

"... and after we are done going agile, I won't be surprised if one third of you will be gone."

You could have heard a pin drop. I rarely hear deafening silence, but I heard it that day.

He went on to explain...

"...some of you are managers. You are not the type of managers we will need. Some of you are employees, you won't be comfortable working this way. The pressure will go up, but the motivation and reward will also."

And finally...

"This is okay. It is where we are going. We are committed to it. I accept that this will happen and am respecting you enough to say it right now. Many of you worked hard to help us get to here, but that doesn't mean it will continue to be a good home for you."

(disclaimer: for those who were there with me that day, I know these weren't the exact words... but they were the message!)

9 months later I remembered that statement and I glanced around. I realized I was working with different people. I was on an awesome team. The team I was on before was really good, but they were all like me... the same role. Now I was on a team with really smart hard-working people that weren't like me. We were all different roles and we all have to think and work together to be successful. It WAS harder, but it was ALSO more fun.

And yes, we lost a lot of people. The people that just wanted to tell other people what to do were gone. They either left or were removed. The people who liked sitting in cubes and being told what to do left also.

This is why my first agile experience was so revolutionary. I doubt many of you had such a hard immersion through the transition, but it was wonderful!

The question is, who was left on the sidelines through all of that? Mike Cottmeyer wrote a good piece on this yesterday. How do those remaining managers adapt?

Does a SM have to be technical?

Kyle Smith asked the following question in the Agile Coaching LinkedIn group:

Often job postings prioritize extertise in a specific technology over attributes defined by Agile. Can a CSM succeed w/o being a subject matter expert for a particular technology or industry?

Keith Sterling responded with:

I don't think you need to be a subject matter expert, but I personally believe you have to have some level of understanding of the technology involved, otherwise you will find facilitation extremely difficult.
As a scrum master people will be looking for you for guideance, when you are planning and cutting tasks its important that you atleast know what the team is talking about and why tasks and plans are being proposed in a specific way.

Scott Duncan made several good points including this one:

Sometimes, skill-specific requirements are there because the org's culture will not "respect" someone in a more "mgt" or consultative position without low-level tech'l skills regardless of the fact that the role will not require them to actually use those skills.

My points were the following:

It depends on the team. Without getting into a debate of which is academically better (though I have an opinion), I see two types of agile teams...

1- a team of developers
2- a blended team of roles including dev, analyst, test, usability, etc

In option 1, it is important. You need to speak the language of the team since the team is speaking tech and you need to be the translator to the business.

In option 2, it is not. The team is a holistic group, let the tech folks speak towards business goals and value. Everyone should be focused on what is being delivered in business terms. The non-tech folks need to understand tech and vice versa. In this scenario, the CSM needs to be in between the knowledge of the tech and non-tech groups.

I haven't coded in 7+ years, but I leverage my computer science background to bridge the gap. I'm more effective due to my tech background, but I hardly ever have expertise in the specific language/tools. I have had success without being an SME of the particular technology.

It should be interesting to see if anyone takes the counter point of view.

Agile and offshoring... why it doesn't completely suck.

There have been a few posts recently in various forums about mixing agile with offshoring. At first I had a repulsive taste in my mouth. You see, I've never been in an environment where offshoring has decreased the cost of development while maintaining a similar level of quality or time (or reduced the time with the same cost). I'm not saying that it is not possible, I'm just saying that the companies I've worked in that tried it have not been good enough to make it work in their favor. In my last group, we practically had an A/B test team that proved this for me.

My personal history was then combined with my positive experiences with agile and co-located teams. I saw the huge productivity gains when everyone on the team was moved into a single room together. I saw similar gains with the product owner was moved nearby and the usability and testing roles were given hotel desks in the room to spend part of the day (they were matrixed, so they spent 2-4 hrs a day in the room). To me this was proof that closer was better. Time zone issues, communication issues, latency of conversation, team chemistry.... all of these things improve with co-location. Accountability is much higher because you can see the peer that made whatever statement.

Thus, my view was always... why would I want to work on a team that isn't co-located? I hold high expectations of myself and my work. Why would I want to immediately suppress my potential by being in that situation?

But this week, I had a new thought. Some companies offshore. Clearly the model has to work for them to continue to follow this model (or they are complete idiots). Does agile improve this model?

Yes! It would! Agile is greatly about quicker feedback loops. What better way to uncover communication gaps, quality and time issues, or any other set of problems than by shortening the window of time before you uncover them?

So... I'm suddenly in a new camp. Agile and offshoring is not a bad idea, it doesn't completely suck. Actually, if you feel that offshoring is your necessary way of gaining an advantage, then agile might be one of the only ways to manage it well. Instead of looking at offshoring as a way to ruin agile, I'm looking at agile as a way to improve offshoring.

That being said... I still want to work in a way where I can be face to face with my peers at least weekly.

Disclaimer: In no way do I want to reflect any discrimination or judgement about people in offshoring centers. Many of the people I've worked with in India, Romania, or Germany are equally capable as people I've worked with in the states. I believe the disadvantage of offshoring has nothing to do with the individuals and all to do with the structure/model in which it is set up and managed. The point is that it takes extra cost to manage, and this is a cost that doesn't exist in a co-located setting.