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.

What is an Agile Coach?

This is an unusual post for me in that it's just a quote from someone else. I wanted a pointer to it from my blog, so here it comes. Brian Bozzuto over at BigVisible describes an Agile Coach thusly:

An Agile Coach is a professional, working internally as a full time employee or externally as a hired consultant, who is working to help realize a profound organizational change to better embrace the values and principles espoused in the Agile Manifesto. Specifically, this is a person who is doing a blend of a number of activities based on the situation to help that organization overcome barriers to change – be they technical, organizational, or skills based. One of the key values of such a person is their ability to play different roles based on the context, and a high level of awareness of these different potential roles can be a critical factor in their effectiveness.

You should go read the rest of Brian's article.

Compact Crank: You Want One #roadcycling

Earlier this year I finally had Atlanta Cycling put a compact crank on my road bike. I'm here to tell you about it. If you know all about bicycles and cranks and stuff, this article isn't for you. This is for those who are wondering if they should change out their standard for a compact crank. If you are wondering this as you struggle climbing hills, then you could just stop reading now and go ahead change your crank. I can say with confidence that you should. Read on if you want to understand what this is all about.

Note that I'm assuming that you don't already have a three-ring crank. If you have a three-ring crank, the only thing a compact crank might do for you is save a very small amount of weight. It will not make it easier to get up hills because a compact crank's smallest ring is going to be larger than your triple's smallest ring. Stick with what you have.

Background

The crank-set is the two or three rings with teeth connected to the crank arms. The crank arms are connected to the pedals. The pedals are connected to the cleats. The cleats are connected to the shoes. The shoes are connected to the foot bone. The foot bone's connected to the...

Anyway, a regular crank typically has 39 teeth on one ring and about 52 teeth on the other. A compact crank typically has 34 and 48, or maybe a couple more. The lower number of teeth in the compact crank-set allows you to spin faster in your lowest gear, making it easier to get up hills.

Notice that I didn't say easy. I said easier. Don't set your expectations too high or you'll be disappointed. A compact crank will not make a hard hill easy. But it can help you make it up the hill without having to mash as hard.

As an aside, developing a fast cadence is good. 'Fast' is, say, faster than 90 RPM. A compact crank isn't going to help you have 90 RPM up a steep hill. I'm just saying that a fast cadence everywhere else is better for your knees and muscles (it's easier n them). It's also better for your heart and lungs (gives them a better workout, which they could probably use). Your heart and lungs can recover more quickly and take punishment for longer periods. There are other benefits to a fast cadence such as the ability to respond and accelerate more quickly. Coach Levi wrote a nice article on this topic.

The Verdict

I like my new crank. As I said above, if you are thinking you might want a compact crank but you are just not sure, just be sure. I'm sure; you want one. I can get to the top now with less fatigue. Not "no fatigue"; less fatigue. If you don't ride much, you might not even notice how much easier it is. I ride the same hills every week and have done so for 4 years or so. That's enough riding that I can notice the difference. If you ride some big hill only once per month, you might not notice the benefit of the compact crank, but it's there.

I also enjoy the 3-gaps North Georgia mountain route much better with a compact crank.

Concerns Debunked

Some people say that a compact crank will make you run out of gear and cut your top-end speed. Eh, well, maybe. They note that you'll "spin-out". Spin-out isn't wiping out, thankfully. Spin-out is when you can't or don't want to pedal any faster. With the compact, I spin-out north of 37 MPH (though I don't remember when I ran out of gear with the standard -- sorry). And I can still coast down hill at 40 miles per hour on my rides. That's fast enough for me. Besides, I'd just as soon coast down hill to rest up for the next climb. I don't need any more top-end. I'd rather enjoy the easier up-hills than the faster down-hills.

Another concern you might have is that you'll run out of gear on the small chain ring and that you'll therefore need to spend more time in the big chain ring. You may be concerned about having to do more shifting. Well, I guess this is true. I do spend more time in the big chain ring. And I do change gears using the front derailleur more often. However, it's not quite as much as you might think. Besides, with the compact crank I can start off from a standstill in the big chain ring as long as I'm not pointing up hill. You need to get good at shifting anyway and if your bike doesn't shift well, fix it.

If you are young, strong and getting stronger, a compact crank may make you slower and cause you to plateau. If you find a mountain climb strenuous, but you can do it and enjoy it in a standard crank, then keep using the standard. It will make you stronger. But if you are young, strong, and getting stronger, then this article probably isn't for you anyway.

Cadence

I wasn't expecting to have a faster average cadence with the compact, but it looks like I do. I was expecting my cadence on most of the route to be the same, with a faster cadence only on the worst hills. I thought the time spent in the lowest gear would be short enough to not impact the average over the length of the ride.

My average cadence on my regular ride used to be 84 to 88. Now it's 87 to 90. Nice. But I do not think it has impacted my pace.

Here's an example with the regular crank: http://connect.garmin.com/activity/29757090

Here's a comparable example with the compact: http://connect.garmin.com/activity/72575356

Same pace, same time of year (winter), faster cadence.

My Dunwoody Cycling group does a faster pace in the summer and fall. My otherwise comparable rides with the regular crank have a lower cadence: http://connect.garmin.com/activity/55940780

But I'm Not Mechanical

I'm quite mechanical and am confident that I could have figured out what to buy and how to change out the crank-set. But I'm not really interested in bicycle maintenance these days. Too many other time demands. If you enjoy bicycle maintenance, then you probably know whether you could do this yourself. If you are unsure, then take it to a bicycle shop. That's what I did and don't regret it.

What's it cost?

I paid less than $350 (January 2011) for a new compact chain ring and crank arms and new shifter cable guides, including labor. It would have been more like $500 if I went with a Shimano Ultrega crank-set, but I went the cheaper route. There are certainly lots of variables, so your cost could be much different.

Recommendation

Just do it. If you switch (or have switched) to a compact crank, share your experience in the comments.

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.

Bias

The other night I found a credit card receipt from The Pampered Chef. This is one of those Tupperware party kind of things that women go to and overpay for stuff because they feel guilty for insulting the party giver if they don't buy something. I told Laura before she went to that party to not buy anything. I had just started my own business and had made it clear in a Family Meeting that we're going to restrict our spending until I see what kind of cash flow we're going to have. We were to buy nothing unless we could eat it.

So, as Laura was heading off to this Pampered Chef party the other day and I told her not to buy anything, she told me she was getting a free meal out of it so I should relax. I can't remember if she explicitly agreed to not buy anything but I know she heard and understood my request to not-buy-anything.

What was she thinking? I stewed over this all night. Laura was already asleep when I found the receipt. I didn't think I should wake her up to discuss this. I knew that wouldn't go over well. So I stayed up thinking about how I'd approach this in the morning.

I avoided my wife for a while the next morning. When I could avoid her no longer I told her I thought we agreed that she wasn't going to buy anything at that party. Laura calmly told me she bought me a birthday present. A $22.26 birthday present. She bought something inexpensive which is exactly what I would have wanted her to do. And I bet it's an incredibly thoughtful gift.

Man did I feel like a heel.

I've been reading lately about biases. In The Principles of Product Development Flow, Donald G. Reinertsen says that psychologists know that "…[humans] have a general bias to interpret the behavior of other people negatively."

There is a nice list of cognitive biases on wikipedia. Some that are particularly relevant to this topic are:

• Actor–observer bias – the tendency for explanations of other individuals' behaviors to overemphasize the influence of their personality and underemphasize the influence of their situation (see also Fundamental attribution error), and for explanations of one's own behaviors to do the opposite (that is, to overemphasize the influence of our situation and underemphasize the influence of our own personality).
• Fundamental attribution error – the tendency for people to over-emphasize personality-based explanations for behaviors observed in others while under-emphasizing the role and power of situational influences on the same behavior (see also actor-observer bias, group attribution error, positivity effect, and negativity effect).

These are amplified by an additional set of biases:

• Bias blind spot – the tendency to see oneself as less biased than other people.
• Negativity bias – the tendency to pay more attention and give more weight to negative than positive experiences or other kinds of information.
• Availability cascade – a self-reinforcing process in which a collective belief gains more and more plausibility through its increasing repetition in public discourse (or "repeat something long enough and it will become true").
• Halo effect – the tendency for a person's positive or negative traits to "spill over" from one area of their personality to another in others' perceptions of them (see also physical attractiveness stereotype).
• Illusion of asymmetric insight – people perceive their knowledge of their peers to surpass their peers' knowledge of them.
• Illusion of transparency – people overestimate others' ability to know them, and they also overestimate their ability to know others.
• Illusory superiority – overestimating one's desirable qualities, and underestimating undesirable qualities, relative to other people. (Also known as "Lake Wobegon effect," "better-than-average effect," or "superiority bias").
• Ingroup bias – the tendency for people to give preferential treatment to others they perceive to be members of their own groups.
• Projection bias – the tendency to unconsciously assume that others (or one's future selves) share one's current emotional states, thoughts and values.

But why would I assume the worst of my spouse? That's ridiculous. Of all the people in the world, I should not have these biases towards her. If this can happen within my family, how much more so can it happen in the workplace?

What I learned from this experience is how real these biases are and how on-guard we as humans need to be. Poor communication skills (or just a simple mismatch in communication styles), fear of reprisal and fear of confrontation can make matters worse. The problem with poor communication is we always assume it's the other person who can't communicate.

Kerth's Retrospective Prime Directive hints at a solution:

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

How do you encourage that other than posting it and reviewing it before retrospectives?

And in Coaching Agile Teams, Lyssa Adkins says to "...create a positive regard for them. Do this by changing your view of them. Regard the person as a human being with hopes, dreams and desires (like your own) so that you can approach them with love and compassion..."

How do you foster this in an organization?

Reinersten offers this advice:

This tendency [toward bias] is reduced when we get to know others as complex hum beings, much like ourselves. Task related (job related) communications by itself is not enough to create an appreciation of this complexity. Non-task-related interpersonal communication that comes from colocation is key to developing cohesive teams.

Chats around the water cooler, going out to lunch together, after-work drinks, post iteration and post release celebrations and kick offs beforehand are good things to try. Fantasy football and office baby birth date/weight pools and the like can help. Team working agreements (norms) posted on a big visible chart can help. Praying daily for your co-workers by name helps remarkably well. Other ideas?

We can bring up the elephant in the room in our retrospectives, but other than just hashing it out, what techniques or exercises have you found useful?

Most of us don't enjoy a tense and confrontational workplace. Likewise, most of us don't recognize how much we ourselves contribute to that situation.

What additional advice do you have to combat bias, increase non-task-related interpersonal communication and improve interpersonal relationships?

Sizing with Incomplete Information

Some teams that I work with that are new to agile struggle to size their first big agile release. The team is often still trying to gel, assimilate new members, and increase their velocity while spending lots of time creating, understanding and refining the product backlog. One of the challenges they face is learning to estimate with imperfect and incomplete information. How quickly they adapt seems to depend on what they are presented with during their 1st agile/relative estimating session.

Some teams new to agile start with a new project and need to estimate the whole thing with little info, perhaps during a "sprint 0". Those teams are forced to deal with ambiguity right from the start. From then on they accept that they'll have to estimate fuzzy stories. This helps them accept that stories will change, both the details of individual stories as well as what stories make up the backlog. Sometimes revealed detail changes an estimate (up or down). Sometimes it doesn't. But that's life and we can deal with that quite well on an agile project. More on that in a moment.

Other teams I work with already have a project well underway. They have a product in maintenance when they go agile. They've got lots of small and well understood stories. Or if they aren't well understood, they can get that way quickly. The 1st stories they estimate are detailed and certain. But a day will come when the team is forced to estimate some new release or some new product with less than full information. That can be frightening. As these estimates are recorded, we can note that the estimates were made with less info and certainty, but that seldom provides much comfort to this type of team.

However, what you'll find (on a healthy team) is that:

• Large estimates on the larger stories tend to drive the Product Owner to decompose those behemoths and then ask for new estimates.
• The team is allowed and even encouraged to revise the estimates (up or down) as more information is revealed.
• Many of the estimates will not need to be revised. Any additional detail or certainty often doesn't affect the estimate after all.
• Consistency is good, but accuracy and precision are not necessary. Wrong estimates have an offsetting impact on velocity. That's the beauty of using relative estimates and the empirically measured velocity to compute a release end-date -- an incorrect increase in one gives an offsetting decrease in the other.
• There will be details that are overlooked. Developers tend to be optimistic with estimates. But that too will soon be taken into account in the velocity (unless you implement all the well understood stories 1st and always save the others for later). (Do note, however, that the shorter your release is the shorter your iterations need to be in order for a change in velocity to be noticed in time.)
• And management will heed the warning signs when presented with the estimates and velocity and not pressure the team into short-cutting craftsmanship, quality or sustainable pace. (Remember that I said /healthy/ team.)

Seeing is believing

On the second type of team this learning happens slowly. You can have a conversation around these things to try to speed up the learning or to provide some comfort. It's certainly worth trying. But don't be surprised if your convincing arguments are met with disbelief.

Engineering Practices Necessary for Scrum

Atlanta has a wonderful tech community. User groups abound. We even have three different agile user groups that meet each month (or more than that if you count the craftsmanship meetup as an agile group and SPIN as partly so). Earlier this year Semeer Bendre asked on twitter why we have these different communities, copying Mike Cottmeyer, Dennis Stevens and I. I tweeted back that #atlantascrum tends to focus more on #scrum whereas #agileatlanta is more free to cover other stuff, such as dev practices. Mike Cottmeyer quickly corrected me, saying they cover fundamentally the same material and XP isn't oob at #scrumatlanta. Then to prove his point, to show just how wrong I was, Mike signed me up to do a talk at #atlantascrum on "Exploring the Engineering Practices Necessary for Scrum." (Let that be a warning to you to tweet wisely.) This blog post came out of that talk. It's pretty much what I said, edited some for this format.

If I have any bias concerning this topic it is that I'm a long-time strong believer in eXtreme Programming. Heck, I was agile when agile wasn't cool. In fact, it wasn't even called agile yet back then. We founded XP Atlanta before the manifesto meeting in Snowbird. And back in 2000 my team gave me a red cape with a big XP on the back. It wasn't until later that I realized that they thought of me more as a super-villain than a super-hero. They wanted me to wear the cape so they could see me coming. And hear me when I made the swooshing noises. But I digress.

I'm otherwise fairly balanced with half my career using a plan driven approach and the later half using an agile approach; and most of my career as a programmer but more than several years in management and product management.

ENGINEERING PRACTICES IN XP

So, first, before we look at Scrum, let's look at the engineering practices in XP. This is the briefest of summaries of these practices.

As an aside, the non-programmers on our teams need to understand and appreciate what this stuff is. Be kind and explain it to them in a way they can understand. Offer them a non-technical, or at least very lightly technical, lunch and learn. This will help us all work together in harmony.

Pair Programming is far more than continuous code review. The pair is thinking on multiple levels: one about the low-level details, names, indentation and syntax while the other is thinking about the big picture, whether this test is sufficient, whether it's the right test, what's the next step, about the next refactoring, and may be helping look up something in the language or API docs. Pairing improves quality and speed of development, or it at least increases the longevity of the codebase by holding entropy at bay. Pairing supports simple design and helps enforce the use of these other practices (peer pressure).

If you are just watching the other guy code, you aren't pairing. Pairing is active. Who has the keyboard should change every minute or three. Try using the ping-pong technique whereby one programmer codes a failing test. The other programmer then makes that test pass and codes the next failing test. Then the first programmer takes over again, and so forth.

Test-Driven Development is where a test (that fails) is coded before the production code (that makes the test pass) is written. TDD supports Refactoring and Collective Code Ownership and Continuous Integration and other things like small releases and iterative development. Out of doing TDD you get automated unit tests for all code. (Or automated acceptance tests for all stories for ATDD.) A related technique is to write an automated test to reveal a defect before the defect is addressed.

Continuous Integration is where you integrate changes daily and preferably much more often. The opposite, of course, is leaving integration until later, which is often a tedious, lengthy, buggy and painful process. A student of lean will learn that leaving integration for later will lessen the likelihood of good luck. Or, delay causes waste.

Refactoring is improving the design without changing the functionality. Many don't do this right or well. It's best done "in the small" all the time, not in large steps and infrequent. The later may be design change, but I'm loathe to call it refactoring. Good examples are small things like rename class, extract method, move method, introduce variable, etc. Most of these common refactorings are supported by the IDEs we use today, such as Eclipse, Intellij, and VisualStudio with Resharper. Proper Refactoring supports simple design and testing.

Coding Standards supports Pairing and Collective Code Ownership. I don't recommend writing your own. There are many published coding standards. I suggest adopting one of those.

Collective Code Ownership is where everyone on the team is responsible for that team's code. All team members may change all the code. We're assuming we have a small team (or teams) of 7 +/- 3 coders. This practice reduces delay (waiting/blocks) and risk. For this, you need pairing and tests.

Simple design -- It's simple design, not simplistic design. Simple design makes code understandable and therefore more maintainable and modifiable.

System Metaphor is a story that everyone can tell about how the system works. This usually yields a system of names. It supports Collective Code Ownership and Simple Design.

So, that's just the XP engineering practices, not all of XP's practices. And that's about XP. That's not about Scrum.

BACK TO SCRUM

But the topic proposed for Atlanta Scrum group was "Exploring the Engineering Practices Necessary to Support Scrum".

So let's get around to that, but before we do, let me take one more detour. If I wanted to find a definition of agile on the internet, where might I look? I'd look on Wikipedia: http://en.wikipedia.org/wiki/Agile_development

Lo and behold, a definition of agile. And, there's a picture of Sutherland. I'm a little miffed that Scrum gets top billing, but at least if I page down, I see a picture of a couple pair-programmers practicing XP.

Now, what are agile engineering practices? I've shown you the XP ones above. What are the 'Scrum' or 'agile' engineering practices? Can't I find that on wikipedia too? Not as of today, but it was suggested to me during my talk that I should fix that.

My point here is that there is no commonly accepted definition of what the agile engineering practices should be, at least not well enough to make it to wikipedia. I say all that to point out that the stuff written below is more of my opinion than are the facts about XP I've stated above.

ENGINEERING PRACTICES NECESSARY FOR SCRUM

What are the engineering practices necessary to support scrum? Go ahead. Write them down. I'll wait.

That's a nice list you have there, but does Scrum make them necessary? Are they necessary because you are doing Scrum? Is it specific to Scrum or is it agile in general? Here's my list of engineering practices necessary to support Scrum:

• none

I categorically say no to all the practices on your list. None. There are no engineering practices necessary to support Scrum.

The question is a non-starter for me. And I say that as an XP fan, a process that believes in the importance of a specific set of engineering practices. I take exception on two grounds. The first is the word necessary.

Necessary is a bit of a strong word. It's kind of like saying always or never. You never take out the trash. You always make me walk the dog. You never put your dirty clothes in the hamper. You always leave the car on empty. You never say you love me any more. Things like that.

The second is the assumption that if you are doing Scrum you must also be involved in software development somehow. You might not be engineering anything at all.

Lots have blogged on this and there was a good debate on twitter about it (involving Jeffries or Shalloway or Sutherland or Schwaber?). It was about Scrum being sufficient or whether it needs development practices. One side said Scrum by itself is insufficient. The other said Scrum is what it is, it's fine as defined, please do use engineering practices, but Scrum doesn't need to be changed.

My wife runs our household using scrum. She's not the housewife, homemaker, domestic engineer: She's the product owner. (My 13 year old daughter who is made to clean the bathrooms is the scum master. But that's another story.) The point is, there are no engineering practices needed for Scrum to be useful in a household.

A team I once coached was the payroll department. They weren't engineering anything. They were building nothing. But they had initiatives and duties that they managed using Scrum. No engineering practices needed.

Pillar's recruiting team uses an agile approach. Pillar's on-boarding process uses an agile approach. Pillar's management uses an agile approach to manage our internal process improvement initiatives. These don't need engineering practices.

However, I know what you mean. I understand the real question. Maybe this is the question to ask:

When you are doing software development and Scrum, are there engineering practices that help?

Now you can bring out your list again.

But does Scrum make them necessary? Or are they universally necessary when doing software development in the current set of popular high level programming languages, namely Java and C# and Ruby? For the most part, I'd say universally helpful. So, we should scratch Scrum from that question and state it thusly:

Are there engineering practices that help if you happen to be on a project involving computer programming?

Absolutely.

Given that, here's my ordered list of useful software engineering practices. I am representing these as tiers upon which the more basic and most important are the foundation upon which the others are built.

FIRST TIER

Starting at the bottom, we have Continuous Integration and Automated Unit Testing. You get a lot out of this. It can hook most people, being a gateway drug, I mean, can help most people and it's a great place to start. Everything else is harder without this

I didn't list source code control, because, everyone does that now, right? I guess there are some things I just assume, and that's one of them.

I could put pairing in the bottom and that would make the other things more likely, but the rest could happen without pairing, so that is later. Besides, the business reality is that it's hard to find enough pair-programmers, so I'm resigned to think that I'll often have a non-pairing team somewhere in my organization.

Similarly, TDD makes sure UTs, refactoring, and emergent-design happen and has other advantages. But you canunit test without TDD, so TDD is higher up in my list.

How about sustainable pace? Is that a technical practice? I'm thinking it's more of a (project) management practice than a strictly technical practice. Otherwise, I'd stick it here.

SECOND TIER

You need tests before refactoring. Some would argue that you need refactoring to do automated testing. Lots of truth to that, but strictly speaking, you could test without refactoring. But you need TDD and Refactoring to support Tier Three.

THIRD TIER

In this tier is Simple Design. Simple is hard. To make things simple, you have to be quite knowledgeable about numerous design concepts. And you also need to be just plain good. You have to be knowledgeable in areas that can make your designs anything but simple if misused, which is why I said you also have to be 'just plain good' in addition to knowledgeable.

Also in this tier is Knowledge of Design Patterns. I didn't say use of design patterns. Use them in your conversations as shorthand, for a concise, rich with meaning way of communicating. But use them in your code carefully.

You should know SOLID design principles if your system is object oriented.

Emergent Design and Emergent Architecture is about recognizing the fact that we aren't going to get it right the first time. Let the design emerge/evolve over time as we learn. Even very very smart folks, the top folks in this field say they don't get it right the 1st time. (Seems like I should try to give a reference to that. Eh, I'll just put an unsubstantiated claim that I bet Cunningham, Jeffries, Uncle Bob, Joshua Kerievsky, Kent Beck, Corey Hanes, and may others would agree.)

This tier is really all supported with 'Ongoing Education', continuous learning. I really think there's lots to learn there and the field continues to grow. This is so difficult to do really really well, that we can never stop learning.

FOURTH TIER

Collective Code Ownership and Pair Programming require a Coding Standard.

As I mentioned earlier, Pair Programming is really a foundational technique, but I can't say that it's for everyone. I'm a strong believer in the technique and have required most of my employees give it a try for at least a month, though it can take two or three to really get accustomed to the approach.

FIFTH TIER

This is the just good old good to know tier. In here are some things that may change or be replaced by something else over time, more so than the ones in the other layers. This tier also includes things to have in your tool box, though you may never pull them out to use them:

• Code Coverage
• Cyclomatic Complexity
• Other Code Metrics
• BDD
• ATDD
• Domain Driven Design

Some might argue with me for putting ATDD or maybe BDD so high up. There are numerous techniques for automated testing at a higher level than unit testing that teams can choose from. I didn't want to list them all and I didn't want to say that one was better than others in all cases.

Likewise, Domain Driven Design is a useful technique, but I can't say every team must use that technique over another.

BACK TO SCRUM

Is there anything in Scrum that should lead us to do these things? You need these things to be agile software development team and these things support time boxed iterations. But there is also the Definition of Done. Some Scrum teams define what done means and hopefully it includes explicitly or implicitly some of these things.

After my talk at Atlanta Scrum on this topic last week I gave a demonstration/explanation of TDD. Surprisingly, I got more positive feedback about that than I did the presentation. Not that either was stellar, but I was expecting a different crowd than what showed up.

Contact me for a TDD demonstration or agile lunch-n-learn at your office.

Comprehensive Documentation - Bad Assumptions

Agile is easy to dismiss. Many people hear something that doesn't sound right, something that sounds different than what they are accustomed to, and they develop misconceptions. They share their misconceptions with others. They dismiss agile without any more thought. A common misconception concerns documentation.

This came across my inbox recently:

I spoke to …, and he doesn’t have a requirement for Agile. He is familiar with the methodology, and his concern is comprehensive documentation. He believes that is a critical part of development that becomes less critical with the Agile methodology.  If his assumptions are incorrect, please let me know.

Are his assumptions incorrect? There are likely a lot of assumptions in that short statement:

• "Comprehensive documentation is a critical part of development." That may be true for his project. But it is not true for many projects. If he assumes that comprehensive documentation is too critical to do without on any project, his assumption is incorrect.
• "Comprehensive documentation becomes less critical with the Agile methodology." Often this is true. But that's a good thing. So, he's probably concerned about this…
• If he assumes you can't write comprehensive documentation on agile projects, his assumption is incorrect.
  You can write all the documentation you want.

Agile simply warns against using documentation as a measure of progress. Instead, agile favors working software as a measure of progress. If comprehensive documentation helps you get to working software, or adds value after the software is written, then create comprehensive documentation. If you have a regulatory environment you can't get around, then meet your regulatory requirements, but be creative and try to find an automated approach to generating it. If we're talking end user documentation and you can't make your application usable without end-user documentation, then write end-user documentation. If we're talking about installation instructions, agile favors automation, but if you can't automate and can't make it easy, then document it. If you have published APIs, create them with great care, provide great documentation and treat them as contracts.

If we're talking about requirements specifications, agile prefers requirements documentation in the form of user stories, constant collaboration between the givers of the requirements and the implementers of the requirements, and automated story tests. If you aren't there yet, if you don't know how to do that yet, then keep writing requirements documents for now, and strive for continuous learning and continuous improvement.

If we're talking about comprehensive technical documentation of the implementation, agile favors the software craftsmanship approach of refactoring towards small methods with very clear and descriptive method, variable, and class names. This leads to readable and self-documenting code. Agile also favors high code coverage through automated unit tests, which documents how to use the implementation and the intent of it.

Every instance of agile is unique. Each adoption of agile must be tailored for the context in which it will live -- the organization.

Usually, however, comprehensive documentation is waste. If the documentation doesn't match the source code, the documentation is wrong. Documentation is almost always wrong. Using misleading documentation is wasteful. Maintaining documentation is expensive and it rarely achieves a defect free state. More waste.

At the very least, this person shouldn't throw the baby out with the bath water. A lot of value remains in agile even if he disagrees with its warnings about documentation. I'm not saying that agile is suitable in his environment -- it in fact might not be. He may have no change or uncertainty in his environment. He may have a very repeatable and predictable situation, ideally suited for a plan driven approach.


In any event, this person is most assuredly concerned about how something will be handled, be it support (handled by pair-programming and a coded test suite) or design (handled by design-all-the-time, pair-programming, test suite, refactoring) or coordination (handled by collaborative space, published and documented APIs as contracts), or etc... I could assuage his fears if I new what was underlying them. That would require a face to face conversation. I'd welcome that opportunity. With him, or with any of you, my readers, or with any of your colleagues. My email address and phone number are noted at the top of my blog. Contact me at any time.

Scrum Fundamental: Planning and Iterating

This is my last post, for now, in this series on common issues teams have with fundamental Scrum concepts. Here are a few tips, reminders actually, for planning and iterating.

Make story estimates visible to the Product Owner. Understanding the relative costs of features helps make better trade-offs.

Product Owners reprioritize work not started. Always work on the highest value story and risk reduction stories first.

Plan a second release from the start. This takes the pressure off. “We’ve just got to have feature X!” becomes “ok, we’ll put feature X in the second release and not worry about it now.” You may never do feature X, or release two, but it helps the first release move along unhindered.

If you need to know when you’ll be done, make a build up chart for the release. See Alistair Cockburn’s article on this topic.

Minimize the amount of work in process (WIP). Limit this in two ways: In each iteration, have the whole team work on just a few stories (like, three to six, depending on size). I put some rules of thumb on this in an earlier post. Don’t start work on something that cannot be completed in the iteration. With traditional project management using Gantt charts, you identify and care for the critical path. With agile projects, you limit WIP and increase cross-training, teamwork, team goals and collaboration to care for the critical path.

In addition to limiting the number of stories in the iteration, limit how many stories can be in progress at any one time. Limiting WIP to, say, one-third of the number of stories committed to the iteration might be about right. Then work towards limiting it to just one.

That’s it for now. But there is so much more that can be said. I welcome your own thoughts and lists and links to other relevant information in the comments below.

Scrum Fundamental: Communication, Delegation

I’ve been blogging lately on common issues in teams practicing Scrum or otherwise trying to be agile, and not having complete success. Yesterday's post covered a hodgepodge of items very loosely related to measuring progress. Last week's post covered user stories. Today I thought I’d talk about communication and delegation.

Communication

The purpose of the daily stand-up/scrum is communication. This is very important. The idea is to keep the meeting short (so make everyone stand) and have everyone share just the info that most everyone else needs to know. This can often be done in five or ten minutes.

Some teams cover what they did yesterday, what they plan to do today and roadblocks. It’s useful to mention some significant change that they are about to commit to source control.

Teams that are co-located and that pair-program with collective code ownership and limited Work In Process don’t typically need to discuss those topics because everyone already knows what everyone else is working on. Those teams just talk about less about what they are doing and more about their impediments – things that are slowing them down.

Decide what is most important for your situation. Whatever your standard topic is, don’t go into much detail or resolve anything during the meeting. Those that need to follow-up or work together or have a deeper discussion get together afterwards.

Whatever your standard topic is, vary it. Don’t get stuck in a rut. If you usually go in order by person, once in a while go in order by story. Throw in a different question to answer, perhaps related to something you are trying to improve upon identified in a retrospective.

The standup is a start, but don’t stop there. Stop using email. Get out of your seat and speak to someone face to face. And working with the whole team in an open space is a really really really good idea.

Delegation

Let go of assigning tasks to people. Let the team manage task assignment themselves. People will choose the correct tasks most of the time. When they don’t, let that be a learning experience.

Let the team estimate the stories.

Let the team come up with the tasks.

Make time for yourself. Take time to think about and to improve the system. By ‘system’ I’m referring to the process and the organization, not the software you are developing.

Next

Next up should be a post on planning.

What is on your short list of common problems related to some fundamental aspect of Scrum?

Scrum Fundamental: Measures of Progress

In my user stories blog post last week I claimed that problems on Scrum teams are often due to lack of knowledge about a Scrum fundamental. Today I’ll tackle the next item in my short-list of common problem areas:

• measures of progress,
• delivering value,
• demos,
• getting feedback,
• keeping it working,
• continuous integration,
• and testing.

Yeah, so, that’s more than one item, but one kind of leads to the next.

Requirements and Design

One way, the traditional way, to try to build trust and understanding between a development team and the business or client is to spend a lot of time on designs, analysis, and wirefames. The problem is that it’s difficult to predict the future with much accuracy. You will likely miss details and misunderstand how the app will be used in practice. Requirements and priorities will change.

The agile prescription, therefore, is to not spend much time figuring out details for some story that you may never implement or that may change drastically in the ensuing months. Understand the stories at a high level. Get into development and begin delivering working software as soon as possible. Get feedback sooner and begin reaping the benefits of the software sooner.

Defer any decision and any work that can be deferred. You’ll be smarter next month, you’ll understand the system and the requirements better. Let the design speak to you, refactoring as you go.

This would be a good place to say something about lean and systems thinking and Pillar Technology’s “Business value over working software” appendage to the Agile Manifesto and about not building software when it would be better to redesign the system, without IT, then automate what makes sense. But that’s another whole post.

One good thing about working software is that you can have demos.

Demos

Favor demos over status reports. After completing each small story, demo it at least internally. Get to where you can have frequent (weekly or bi-weekly) demos to your clients/users. That early feedback is very important. This also holds staff accountable for quality, for “keep it working”, and for getting to done.

The demo isn’t for the Product Owner. Your Product Owner should have been involved with the team while the story was being implemented. Your Product Owner should have seen the story before the demo. There was an interesting discussion on the Agilistas LinkedIn group about who should do the demo, and why.

Keep it Working

Employ the “keep it working” principle. Build a usable system early on and keep it working continuously. The source in the version control system must always be usable. Set up an automated build/test process using a tool like CruiseControl, Cruise, or Hudson. Have it inform everyone when the build breaks. You should have a demoable product at all times. At the end of each iteration you should have a shippable product.

This requires automated testing. Pick a level with which to start coding test cases. Most often this is at the lowest level, unit tests. I recommend the xUnit framework or RSpec, but there are other good choices. [Hmmm. I feel compelled to say something about cucumber or BDD, but I intend this to be a fundamentals post. BDD ought to be fundamental, but it isn't as fundamental as this other stuff, particularly if I'm talking about Scrum. Admittedly, this post has left Scrum and is off in generic agile-land. But I digress.]

Sometimes, however, your methods are too large and have too many dependencies to be tested well at this level without first doing much refactoring. In those cases, automate your tests at a higher layer, then refactor and employ unit testing as you go. I’ve used Selenium and Rational Functional Tester for UI-based testing, but there are other choices out there. Working Effectively With Legacy Code by Michael Feathers comes highly recommended.

If you do a good job here, you’ll reduce the amount of manual testing you have to do. You can limit that to usability, break-the-box, and exploratory testing rather than regression testing.

Just a short word about testers. QA professionals think differently and approach testing in ways that developers do not. I like getting QA involved with the developers, pairing. I like getting development involved with anything that QA is taking the lead on automating. And I really like getting QA involved with the Product Owner to help define good stories and good acceptance criteria.

Parting Note

I almost abandoned this series of posts. There’s really nothing new here. I’ve said nothing better than it has been said before. I’ve just said it differently. Sometimes ‘different’ resonates with someone who hadn’t understood the way it was put to them before. So, I’ll press on with these posts. Unless I change my mind.