Marcato

We are happy to welcome a new voice to the blog!  Riley Horan is an experienced IT project manager that specializes in Agile and appreciates its focus on the team as the central building block.  Riley and others of similar mindset have been writing about building better teams at http://buildbetterteams.blogspot.com.

Reprinted from:  http://buildbetterteams.blogspot.com/2009/08/where-is-butter.html

——————-

My daughters love butter. They can’t get enough of it. When we have pancakes they love it even more. The problem is though, if they can’t see it they don’t believe it is there.

When you put butter on a hot pancake it melts to the point that you can’t see it. If I bring the pancake to them, without viewable butter, they say “Where is the butter?”. I tell them it is there, but they don’t believe me. So I need to go back and put more butter on it to satisfy their need to “see it to believe it”.

The same thing is true when you are working with someone who doesn’t necessarily behave in a way you would expect or want.

Twice in the last few years I’ve come across circumstances where people I’ve worked with have been steady and even keeled and not subject to excitement or panic. But a perception has been that this person is not driving their team. Not building excitement and momentum.

When this is brought to my attention and I’m told they are not a driver, I ask “why”? What are you seeing or hearing that is making you think that? Because it seems like they are working well and getting their projects done. The response has been that this person is not a driver because they are not pushing their teams.

Ah…..”Where is the butter?”

It took me a while to figure this out when I was working with one person a few years back. We changed one thing. When he was talking in front of people who like action I told him to use stronger words and stronger tone. Result? First time he did this he received a voice mail from someone who thanked him how he was driving on the project and moving things forward.

Did he change any of his other behaviors? No. We did talk about using a slightly stronger choice of words and tone in certain circumstances, but overall his behaviors were the same.

Don’t get confused if at first you don’t see the butter. It may really may be there, you just can’t see it. If you are making a pancake, sometimes you just need to give people what they want to hear or see, and that will keep them satisfied.

Yesterday afternoon I was talking to a friend and client about our efforts over the last six months to build and ship a new product platform and to use that effort to inspire new customers to use our products and services and new investors to help fund us through to profitability.  The result of those efforts recently shipped to our production data center and are now in use by our current customers.  As he has been talking to investors, he is now using this proof point to demonstrate to them that we have an effective team in place that is capable of delivering on the overall vision we have for the product.  More importantly, he has been telling them that we set out six months ago to build this platform and now, after six months, we have shipped it on time.  The problem?  Nobody believes him.  You can see it in their eyes and in the questions they ask – “Nobody ships software on time.  You cheated.”

I:  ”So you say that after six months of development, you have shipped the product that you wanted on schedule.”

A:  ”Yes…well, not exactly.”

I:  ”Oh?”

A:  ”Well, to be more precise – we shipped the product that our customers need on schedule.”

I:  ”And it’s done?”

A:  ”Of course not – we just started.  Show me a software product that is done, and I’ll show you a product that was just turned off by it’s last customer.”

I:  ”OK – fair enough.  As long as you can fund the ongoing effort from your revenue stream and be profitable, I guess I get what I want.  But let me ask the question a different way.  You said it doesn’t have everything you want but what your customers need – does that mean you had to leave out features?”

A:  ”Yes.  There are things we said we wanted to accomplish when we started that were left out.  But we always left the product owner in control of those priorities, and to the degree that they were able to effectively represent our customers, we were always working on what our customers would say was most important.”

I:  ”Aha!  But that’s cheating – you didn’t actually do everything you said you would the way you said you would at the beginning!”

A:  ”No, we didn’t cheat, but yes, we compromised along the way.  To be fair, the business’ understanding of it’s product, position in the marketplace, customer needs, and financial position changed a lot along the way, too.  Staffing and priorities related to other product lines were in flux, and when we started we had not even chosen the two strategic partners we would have to integrate with to provide a significant part of the feature set.”

I:  ”So, it’s somebody else’s fault that you did not get everything done that you said would get done?  I’ve heard that story many times before.”

A:  ”I think you are looking at it wrong.  If your assumption is that everyone starts with a perfect understanding of what is needed and how to do it and all that is needed is to execute on that plan, then I suppose you could say that it is cheating.  But, if you instead assume that everyone involved is simply making the best decisions they can at the time based on the knowledge they have, then the actual path you take to get to the goal isn’t the result of cheating – it simple acknowledges that we are all always acting on imperfect information.”

I:  ”I suppose that’s true – but how can a business make good financial decisions in a situation like that?  If we don’t know what we are going to get, when we will get it, or what it will cost, then we can’t determine if the investment will be profitable.”

A:  ”Well, you can set some constraints on all of those factors so that you know roughly what the business can expect, but are you saying that even if we could somehow tell you all of those things, then you would be able to tell us exactly how much of that product you will be able to sell?”

I:  ”Hmm – not really, at least not exactly.  After all, we’re in a speculative business venture trying to do something that has not been done before, so while we can try to model how the market will behave and how the business will perform, we can’t really be sure until we do it.”

A:  ”So, what you are saying is that while you can’t list the names and dollar amounts of the people that will buy the product, you can make macro level estimates based on related products and industries and overall estimates of the market potential and then correct that model as needed based on what actually happens when you start to sell the product?”

I:  ”Yes – that we can do.”

A:  ”But that’s cheating by your own definition!  Or would you agree that as long as you get the sales you need when you need them, then the model holds together and you get the results you expect without having to try to predict or control the details?”

I:  ”I see what you are doing; don’t try to twist this around!  OK, I’ll concede that point, but you are engineers; you’re supposed to be smart and detail oriented.  Salespeople have to have some latitude for finding creative ways to make their quote – it’s the only way to retain the best.  I don’t want to micro-manage what they do – it’s just the result I care about.  Anyway, let’s switch to the other side of the coin.  You said you got it done on time – so that means everything went to plan?”

A:  ”Nope – there were lots of things that went wrong along the way, and we missed our goals by a couple of months.”

I:  ”There you go – cheating again!  How can you say you shipped on time when you told me you missed your goals?  You can’t have it both ways.”

A:  ”But you can.  There was always two plans – the public plan that we told our current and future customers and investors, and our internal plan.  Our internal goals were much more aggressive because we knew that there would be some unexpected changes along the way.  What matters was that we committed to incremental steps along the way and corrected our plan each time we discovered that it needed to change.”

I:  ”So, let me see if I have this straight.  You intentionally created an internal plan to ship in April so that you could meet your external plan of shipping in June.  The way I see it, you sandbagged by 50% and came nowhere close to meeting your goals.”

A:  ”Or, another way of looking at it is that we intentionally created urgency within the team to make sure we stayed focused only on the most critical features.  Look at it this way – let’s say you have an interview for a job you really want at noon on the other side of town.  You get a map on the Internet and it says you will need 24 minutes to get there.  Do you leave at 11:36?”

I:  ”Of course not.  You might hit traffic, and the map doesn’t account for the construction on Hwy. 36 where they have it down to one lane, plus it always takes and extra 10 minutes or so to find parking near the actual building when you can find that.  I’d probably leave around 11 just to be sure.”

A:  ”Seems reasonable, but you have to admit that you might get there early and have to wait for it to start.”

I:  ”True, but the consequences of being late are more traumatic.  Besides, if I get there early I can always get other work done while I wait.”

A:  ”The same thing applies to our software release.  What if I told you that some of the team finished early and have already started working on features for the next release?  Would you still say we were sandbagging?”

I:  ”It does help, but it still seems like you could just do whatever you want for the first couple of months and then use the last 4 months to actually build what we asked.”

A:  ”It probably seems that way, but what if I also told you that every two weeks we showed the team actual working software?  It seems hard to hide that way.  And what if I told you that every two weeks you get to decide what we will do next based on your current understanding of what is important to our customers and to the business?”

I:  ”Trust, but verify.  I guess I like that I at least get to know how my money is being spent.  I don’t want to have to watch over every little detail along the way, but I need to know I’m getting value for my money.”

A:  ”I wouldn’t want it any other way.  I know there are situations where the technical teams take advantage of the business, but that’s really hard to do with Agile.  In fact, if there is any risk, it is that the business so dominates the agenda that you do not make important but not urgent investments in upgrading technologies or staying true to your overall architectural plan.  You have to make sure you have leadership that understands how to deliver those things along the way while explaining to the business why they are important enough to invest in.”

I:  ”I feel like we’ve been talking in circles, but I at least feel like I understand what happened.  You didn’t ship what you wanted when you wanted, but you did ship what your business and your customers needed when you needed and the business had good visibility into and control over what was happening along the way.  I guess that’s not cheating – it’s just a practical approach given the situation, especially for an early stage company without a proven product or market.”

A:  ”Exactly.”

A couple weeks back I had the chance to present our use of Microsoft’s Team Foundation Server for managing our Agile development process at Kardia.  As part of this session, we also had presentations on Version One and Rally from other users, and in summary it seemed that while the other tools offer an easier to learn implementation of Agile through a user interface designed to support the natural workflows, TFS shines in providing the most complete “out of the box” Agile life-cycle management tool.  It comes with version control, continuous build, defect tracking, and test case planning, execution, and tracking all linked together to provide traceability from end to end.

For more info on what we did and why, check out the presentation below:

SEG TFS Presentation

I’m currently working with an Agile team where the team members that participate in estimation are in 4 different cities around the world.  We started the process by estimating in our heads (or writing it down on something) and then I would randomly pick someone to go first, but I always felt like this approach tended to anchor everyone in whatever the first one or two people said as their estimate, and I was never sure if people were really communicating their first impression.

I was thinking that the ideal tool would be an online app that would allow people to vote and then reveal all of the votes together – and it turns out that such a tool has existed for some time:  http://www.planningpoker.com

The site is maintained by Mountain Goat Software and uses their modified Fibonacci sequence.  Our team had been using powers of 2, but we found switching the available scores painless.  We ran the estimation on that site, but also used GoToMeeting to share a desktop where we would have the story detail.  I kind of liked this as the discussion almost always clarifies assumptions before the vote and it’s nice to capture the important parts of that dialogue directly in your story in the system of record, but we’ll probably also try exporting all the stories so that the team can see them in the website as they vote.

There are a few quirks – a given user can only join a given game once; for some reason, one guy got kicked out a couple of times, and when he was rejoining for the third time his name was something like Bill Smith (I don’t like this tool).  It allows you to re-vote a given story and will fill in the result if it detects unanimity, but we tended to just talk it through to a verbal consensus and then ask if anyone wanted to veto.

A tool like this is a must for a distributed team – give it a try!

One of my favorite aspects of Agile is that it is designed to deal with uncertainty by accepting that uncertainty.  Given that what we often do is to take teams of people that have not worked together and ask them to build something they have not built before with tools or technologies that are unfamiliar, it’s not really surprising that all software schedules are inherently risky, but my experience with early stage companies has also taught me that often the market risk is actually more significant than the execution risk.

Anticipation is building as our team has reached the point where the product we are building is actually starting to do something interesting and useful.  The rest of the team has been reasonably patient as we have adjusted scope and schedule a couple of times to try to get the functional footprint right and to adapt to changes in business tactics, positioning, and partnerships.  But we have ridden through the worst of those bumps and I’m now confident that we can see our way through to a product that we can ship with reasonable predictability in both scope and schedule.

During the lead up to our first comprehensive scenario being demonstrated, it was fairly easy to keep the dreamers at bay.  All product owners seem to share this trait – as soon as the team is hunkered down to productize what has been produced, they start to imagine what else they should try to squeeze in before the product ships.  If there is a necessary role for “adult supervision” between product owner and scrummaster, this is it.  We know from experience that minor scoping decisions come and go with regularity and are rarely if ever important in the long run, but nobody EVER forgets when you blow a ship date or go for long periods without shipping something.

So, despite all of the hard work left to do, we’re already starting to talk about what is next.  ”We need a product roadmap!  How soon can we start to form specific plans so that we can tell people what will be coming in V2 and V3 and when they will be ready?”

Sound familiar?  It should – it happens everywhere and is very natural.  However, there is something important to remember when you are finishing V1 of a new product:  no matter what you think you know needs to be done next after V1 ships, you are wrong.

This simple fact actually led us to establish a rule around this – teams that were finishing a V1 project are not allowed to be assigned to other projects until after the first couple successful implementations of the product in the field.  Why did we do this?  Because we had too many situations where we would ship V1, assign people to other projects, then the product would get sold and we would start to get our first real information about what the market really wants.  Lo and behold, the resources were gone, so now this information disrupts all of these other efforts and commitments as portions of the original team are reassembled to try to address the product deficiencies as rapidly as possible.

I think getting that V1 product market tested is THE most important thing a company can do, and using the development team to accelerate that deployment process makes more sense than anything else they could do with their time.  As mentioned earlier, there is a very natural tendency to want to keep the team busy and maintain momentum by moving right into developing whatever features did not make the V1 cut, but if you do this you will almost certainly regret it.  The real critical path to sales is widespread acceptance by the market, and while developers often will not admit it, there is always more they can do to make sure that the feature set that they have is well documented, well understood, and successfully applied.

While I’m also finding it tempting to start the look beyond V1, it was refreshing to have this conversation with my customer.  They are worried about making sure that the feature set for V2 is carefully spec’d out months before V1 actually ships.  Starting that process now will inevitably distract the technical team with questions that are out of scope for their current work, but more importantly it would start us down the slippery slope of thinking that once these additional ideas are understood, that it would make more sense to just postpone shipping V1 until they can be included.  As Voltaire said, “The better is the enemy of the good.”

I’m convinced it is healthier for all involved to avoid having too much product backlog – I understand the value or roadmaps and of selling the future – every software company does that to some degree.  However, the more you do it the more you mortgage that future on behalf of specific customers when the market might try to take you in other directions.  It’s a delicate balance to maintain, but there is a real risk in making such commitments, especially during the development of V1.  Direct that energy to commercializing and promoting what you are building in V1 instead and you will find there is less stress within the organization.

A friend of mine bought me a copy of “The Soul of a New Machine” by Tracy Kidder to read recently.  It turns out that because of my early hardware experience it is an interesting read for many reasons, but he gave it to me because it also digs deep into the personalities and mindsets of people that are involved in high stakes, high tension development projects.  He thought I would appreciate it and be able to relate it to other project work I’m involved in (and he was right), but little did he know the other gem I would discover.

I’ve spent time on this forum talking about why the medium of software is somewhat unique for applying Agile methods, so I was surprised to see descriptions of the team dynamic at Data General that sound remarkably like high-functioning Agile teams.  For instance:

“The entire Eclipse Group, especially its managers, seemed to be operating on instinct.  Only the simplest visible arrangements existed among them.  They kept no charts and graphs or organizational tables that meant anything.  But those webs of voluntary, mutual responsibility, the product of many signings-up, held them together.  Of course, to a recruit it might look chaotic.  Of course, to someone who believed that a computer ought to be designed with long thought and a great deal of preliminary testing, and who favored rigid control, might have felt ill at the spectacle.  Criticism of that sort flattered West.  ’Show me what I’m doing wrong,’ he’d say with a little smile.

In fact, the team designed the computer in something like six months, and may have set a record for speed. The task was quite complex.”  (pp. 120-121)

Why did they operate this way?  Frankly, out of desperation, although it was clearly how they preferred to work as well.  They were in a fight for their lives with both internal and external competition and had to take big chances and make big bets or their product would not see the light of day.

I’ve been in many different situations from startup to mature organizations, but one common theme in all of these situations is that we were always trying to prove ourselves and usually fighting for our own existence whether we knew it or not.  Complacent software organizations are teams that are about to have their world disrupted, they just don’t know it yet.

The move toward modern SAAS models and “the cloud” is proof of this – the traditional economics of licensed software and recurring support are giving way in all industries to models that depend on mass customization and efficient delivery at low margins.  In this world, software is expected to constantly evolve with high quality software constantly flowing out of the team and into the customer’s hands.  To quote General Eric Shinseki:  ”If you don’t like change, you’re going to like irrelevance even less.”

Be Agile, or be irrelevant.

“The Soul of a New Machine” was written in 1981.  If you have earlier documented descriptions of Agile teams, I would love to hear them!

Engineers are funny – when we get wrapped up in building something, the rest of the world tends to fade away.  Just ask our significant others; they’ll give you a knowing look and roll their eyes.  It gives new meaning to the word “obsession”.

It’s not a bad thing, at least not in healthy doses, and the Scrum process and sprints tend to bring us up out of our collective reverie as we pause briefly to observe what we have wrought, and then plunge back into it for another two weeks.  My current project team has been flirting with the transition to ship mode  for a while now – I actually declared it too early and had to rescind it when the scope shifted on me.  The focus has been evident in the last couple of sprints – long days and nights and lots of work left to do.

Unfortunately, for teams new to Scrum, this is also when fresh habits already start to fail you.  No sooner did we start to get into the heat of battle when we stopped doing our retrospectives.  Now, on the surface that doesn’t seem to be such a bad thing; maybe everything was going reasonably well and we didn’t really need them.  However, as the coach for the team, my job is to to try remain more objective about the state of the project and the team and to make sure that good habits are sustained.  There is no good excuse – we were simply all too busy to think.

On a personal level, this also became clear as I watched my once frequent writing habits lax into near nothingness.  Every once in a while a thought would fire, but no action resulted – the pressure to produce in other areas was too great.  Whenever I have some time available, my mind runs through a quick triage – the one hundred unread emails in my inbox, the project designs that are incomplete, the urgency of the next team milestone and the developer that is stuck and needs help, or even the code that needs to be written.  All of these are more important than taking the time to think, reflect, and to write.

It reminds me of the frog in hot water – the temperature keeps rising until it approaches dangerous levels, but the frog is unaware.  Retrospectives represent a chance to take the frog out of the water, adjust to new surroundings, and then find out what it will take to get it back into the water again.  By doing this, we keep our expectations of ourselves realistic and we create the culture of learning that make Agile so great.  After all, no matter how much pressure you are under, do you really not have the time to see if you can fix it?

There is always pressure during the final stages of any project, but a retrospective will help you tell between normal pressure and unrealistic expectations that need to be fixed.  As the leader in the team, you are more susceptible to this than most – you set your course and sprint out ahead to lead the team.  While doing this, it is so easy to get absorbed in the immediate issues of the day that you don’t realize that you have lost your team.  Retrospectives represent a chance to stop, let everyone catch up, and to figure out if they are all still with you to the end.

Kudos to Simon Bennett on this post – for once, I’m speechless

Purist Is A Dirty Word

My son is a linguist-in-training; he tells me that “semantics” is the study of the meaning of words.  I guess that’s why I find it funny when someone says, “You’re just arguing semantics”.  Really?  If you are not arguing about ideas and what they mean, then what else would you argue?

When you work in an industry where ideas are evolving and changing, it’s interesting to watch how existing or new words get introduced to describe these new ideas.  We have all seen that this can happen for a variety of reasons – sometimes the ideas are truly new and more useful than the old ones and therefore you need a new lexicon to describe them.  Other times it is just rebranding or co-opting of existing ideas for the purpose of trying to create distinction and demand in the marketplace.

I’ve been watching this happen as the notions of Lean and Kanban first introduced in the context of manufacturing are now getting reapplied to the domain of software development.  Given my focus on operations management in MBA school, I feel like I got a decent grasp of these concepts and how they are applied, and I can understand the allure of the analogy.  The principles of Lean cross over very well to software development and I’ve been making comparisons for some time now and I would describe Agile as an appropriate application of Lean principles to software development.

BUT (you knew that was coming, didn’t you), given my understanding of what Kanban is in the manufacturing realm, I find that term not only dangerous to apply to our domain, but in a sense it’s just plain wrong.

There is an idea behind Kanban that is very powerful if not disruptive, in operational systems.  It’s a simple pull-replenishment system in which the request for one unit of output sets up a chain reaction that triggers pulling your needed sub-components from nearby until that stock location needs replenishment.  The “kanban” was the card used to trigger the replenishment through a very simple signalling system.

Behind that simple idea is a very powerful implication – if your source for replenishment can give you a fast response time and never run out, then you can run your manufacturing system with much less planning and much less work in process and inventory while actually increasing throughput in the system.

You can realize that same goal in a software development organization – Agile is about identifying and eliminating process bottlenecks and accomplishing that same kind of reduction in work in process in your development organization.  You build only what your customers really need by reacting quickly to their demand signals.  The analogy this far is great, but this is where they start to lose me.

As mentioned earlier, Kanban is a means for signalling that a downstream dependent process step needs something, and the idea is that when this signal arrives it would get produced or replenished “just in time”.  It establishes a continuous flow of subcomponents into final products.  Software development does contain dependent process steps, and I can see the attraction to the idea that the movement of work through concept, design, coding, and testing should just flow freely upstream until the team has everything it needs to do the work.

BUT (here’s where I explain my concern) the challenge is that shipping software always requires the convergence of many parallel paths to a moment in time.  There is always a need for “ship mode”, always a need for a collective push that leads to the pinnacle of the project.  I know that in principle that happens at the end of every Sprint, but in practice there are usually special activities associated with shipping a product, the least of which is coordinating marketing, etc around the launch of that product to the market.

Now, I can imagine that there may be organizations where the either the gradual release of features makes sense (especially if they are internal) or that are willing to commit to delivering features that are off by default until they get revealed later by turning them on. I can also imagine a world where our product truly is DONE in every sense of the word every two weeks, but the closest we ever got is a three week delay to launch.

My second concern is that time-boxing is not only an important feature, it is the most important feature of Agile methodologies.  Software projects are a gas – they always expand to fill (and slightly exceed) the available volume.  Any idea can be improved, and refactoring can go on forever unless something like a deadline brings it to a stop.  I know every engineer on the planet is convinced that this is the reason that they never get to build the perfect product, but time is not really the enemy.  The real issue is economics – time is money, and there is limited money available for any software product.  Sprints help snap us out of our collective concentration and to realize – oh yeah, we’re supposed to have something done now.  We always have many paths to an acceptable solution – sprints help make sure we chose an economical one.

Finally, as much as I respect the industrial revolution, developing software remains a creative, human enterprise.  A healthy team ebbs and flows, and no one can maintain a constant and unending flow of work.  We need to form a collective vision, refine the ideas needed to deliver it, bear through the crisis point, and celebrate our success when it is done.  High functioning teams are driven by this rhythm and it is part of what helps them remain together long enough to achieve that exceptional performance.  Software development can learn from manufacturing, but it will never be manufacturing.

We’ll update this from time to time as new and interesting material is published or discovered.  Feel free to comment if you have any strong recommendations yourself.

Recommended

1. “The Goal, Third Edition” by Eli Goldratt and  Cox, J.
2. “Implementing Lean Software Development: From Concept to Cash” by Mary Poppendieck and Tom Poppendieck
3. “Agile Adoption Patterns:  A Roadmap to Organizational Success” by Amr Elssamadisy
4. “Peopleware” by Tom DeMarco and Timothy Lister
5. “Quality Is Free: The Art of Making Quality Certain” by Philip B. Crosby
6. “Practices of an Agile Developer” by Venkat Subramaniam and Andy Hunt

Other Noteworthy Agile- or Software-Related Blogs

1. “Joel On Software”, http://www.joelonsoftware.com/
2. “Project Connections”, http://www.projectconnections.com/articles/glory.html
3. “The Agile Management Blog”, http://blog.versionone.com/blog/versionone

Other Supporting Background

1. “Managing Offshore Development Projects: An Agile Approach” by Upadrista Venkatesh