Marcato

A decent day of networking and rediscovery of unused technology neurons – here’s the nickel tour of the keynote and four topics I attended today:

1.  Microsoft .NET product plans for 2010 – Windows 7 is coming very soon, Azure launches in November, and .NET 4.0 and Visual Studio 2010 coming mid-2010.  Azure is the biggest play in the list, but not from a technology point of view but more because Microsoft providing a hosted cloud environment for their technologies is great news for developers with Microsoft skills.  This will definitely change the game for the hardware/hosting economics.

??? - Coon Rapids, MN

2.  PEX – short for Program EXecution- this nifty tool can be used on any managed .NET code.  Once installed, you right click on any public function in a .NET assembly and run PEX and it will perform both static and dynamic analysis of the code using a solver they provide to come up with a suite of unit tests that provide remarkably interesting examples of inputs to see how the function handles them.  Although brute force, you have control over how long you give the solver to look for interesting combinations of inputs to try, and once they are found it runs each test vector and provides a report of the output results and any exceptions generated.  The test case source generated is suitable to be included in your existing unit test library – I believe it is MSTest compatible out of the box but they mentioned support for NUnit as well.  If you are doing .NET development, this is definitely worth a look.

I asked about advice for the best way to use the tool.  It could be run each time with the build process, but probably more practical to just run it on functions that diff from the previous build.  I was surprised by how little it generated for positive tests – this speaks to the power of the tool, as it helps us realize that when we write tests we tend to write too many positive test cases and not nearly enough designed to break it in strange and mysterious ways.  The tool/assemblies are available by free download.

3.  Azure – as mentioned earlier, this is Microsoft’s cloud computing play complete with hardware hosting, full virtual PCs, SQL Server, and a set of new persistence services (blobs, tables, and queues) that are only available when deployed to the cloud.  .NET services are available but workflow isn’t working yet.  It’s available in Beta now and launch is planned for November.  Talking to Jeff after the session, he agreed that the challenges that remain are more business than technical – data privacy, compliance, SLA contracts, etc.  Learn more at www.azure.com.

4.  WPF applications with MVVM – MVVM = Model View View-Model; let me start by stating that the subtleties that drive the religious wars over whether MVC, MVP, or MVVM is the right approach for enabling effective unit testing of UI applications escapes me.  It’s about as silly as the battle between the PFJ and the PJF in “Life of Brian”.  Suffice it to say, just pick one and use it, because the benefits of capturing your logic that would otherwise live in code behind in a testable place (call it the controller, presenter, or view-model, I don’t care) is well worth the extra complexity.  I say this despite the fact that it took the presenter an hour to explain how Hello World worked…  We’ve had good experiences with a comparable approach in the past and got very high test coverage that way.  Just do it.  Why?  Because I said so.  Vegetables are full of vitamins.

5.  Prism – OK, I had an hour on this and I still don’t know exactly what it is.  It’s definitely a set of best practices, and there might be some downloadable bits; I’m not perfectly clear on that.  What it is is guidance on how to build complex WPF UIs that contain dynamically loaded modules that run in regions of the screen (think web parts in Sharepoint but richer) with an event model that takes care of propagating changes that occur across all of the modules.  If you are building a WPF UI, it’s definitely worth a look as it also promotes good practices aka MVVM above for providing good testability and modularity that supports larger team development.

Worth a day and $150 – thanks to ILM for sponsoring.

I have the luxury of actually reading and studying right now, and this morning’s reading of “Agile Adoption Patterns” included the practice of Self-Organizing Teams and Cross-Functional Teams.  In both of these practices, Amr makes mention of the power of such teams to overcome obstacles because of the flexibility and diversity they have to go through or around the challenges they face.  He also makes specific mention of all members of the team being willing to help with testing as needed so that the team is successful in achieving their goal.

This is a hot topic for me, so when I read these chapters I immediately knew I had more to say on the topic (I know, big surprise).  My first contention is that once a team finds its rhythm in a reproducible process, almost every organization will them realize that it’s bottleneck is “testing”.  I’m a little reluctant to use that phrase because a more accurate statement would be that the bottleneck is “product quality” with testing being one of the most visible manifestations of quality assurance.

My point of view on quality has been heavily influenced by studying quality assurance and statistical process control in the realm of manufacturing.  While their are certainly importance areas where the analogy is flawed, there are many where the concepts are totally applicable.  Let’s start with the concept advocated by Crosby in “Quality Is Free” – cost and effort spent improving the capability of your processes reduces the production rate for errors and pays off many-fold.  He and others speak out against inspection as the least effective way of ensuring that a quality product is produced.

When a software organization decides to invest in “testing”, this usually takes the form of creating a quality assurance team.  This is where they start because they are looking for some kind of verification that will give them the confidence they need that the product that they are about to ship is good.  These teams may use automation, but usually their experience leads them to use manual testing.  Their primary responsibility is to execute the regression tests, so this is usually where they majority of their time and energy goes.

When I encounter this structure, the first thing I usually do is to change the definition of what testing is.  Passive involvement late in the development process as a final check before shipping to both frustrating to everyone involved and inefficient.  You are forced to staff for the peak load created during regression.  Testers that offer their opinions about how the product could be improved discover that the ship has already sailed – the team is up against a ship date and only the most egregious of problems get any attention.  Their opinions go unrecognized and eventually they stop offering them.  Or worse yet, a power struggle ensues as the testing organization pits themselves against the developers in an effort to influence quality.

North Shore - Two Harbors, MN

Instead, we pull the testers out of their department and into cross-functional teams.  We break the cycle of laggard testing that prevents them from being involved in the concept and design phase for the next set of features.  They test the features as they happen rather than late in the release cycle and a feature is not done until they say it is done. 

In “The Goal”, Goldratt tells a great story about a scout troop on a hike that is given the goal of getting everyone to their final destination in the shortest time – success is only achieved when the last person arrives.  At first the faster hikers move way ahead, but eventually they realize that unless they help the slowest hiker get there faster, their extra potential is wasted.  They achieve this by tying the hikers together with a rope, and then over time they help offload work from the slowest hiker (the process bottleneck) until they are all moving together at the fastest possible speed.

All of these changes work great and this always revitalizes the test organization, but even when you shift from staffing for peak regression load to staffing for the average demand needed, you don’t really get the balance you are looking for unless you change what you regression test or how you test it.  It also takes extra energy and resources to break the vicious cycle in which you are stuck.  The testers by themselves may not have the vision or technical skills to fix these problems unassisted.  Hiring more testers might help, but it also likely further embeds you in the current approach.

How do we fix this problem?  As a team, and by this I mean a self-organized, cross-functional team that recognizes that unless you get this challenge mastered, your products will not have the quality or timeliness that you desire.  Unless quality becomes the responsibility of all team members, you won’t break the code-test cycle that is at the root of the problem.  Manual regression is the software equivalent of 100% manual inspection on an assembly line.  In that world, they understand that investments in automated inspection and in earlier process measurement are the key.  However, a product may need to be altered to be testable through automated means – this could be as dramatic as a change in architecture or development tools.  Investment in developer tests can decrease reliance on manual inspection, but this means a change in working habits for the developers.  And finally, developers may need to help create the framework of an automated test suite.

Hopefully by now my message is clear – quality is the responsbility of every team member, ESPECIALLY the developers.  If the team has a quality issue or not enough test capacity, then not only is it appropriate for the developers to help, they should help.  There is one thing I know – give a developer something they consider a mundane task and not only will they do it but they are very likely to apply their creativity to coming up with a way to avoid needing to do it again.  Developers are the key to transforming how a team ensures quality – with sufficient investment in developer tests (to reduce the need for regression testing) and automation (to increase the efficiency of regression testing), you may even achieve the goal of 100% automation for regression testing.

So, if you are a developer in a feature team and you can see that your tester needs help, then roll up your sleeves and figure out how to either make the testing more efficient or reduce the need for testing in the first place.  The reasons for doing to are entirely selfish – staffing is usually a zero sum game;  once it is evident that the team needs more testers, they may only be able to afford this by having fewer developers.  If you are not sure where to start because you really don’t understand how testing is done, then this is an even better reason to volunteer to help using the current methods.  Instead, if you can change the technology and methods used to test, use your knowledge of the product and changes to influence what gets tested and when, and assume more responsibility for developer testing so that you create a more capable process, then in the longer run you get the best of both worlds.

Iterations may be the heart of the Agile product engine, but the product owner is the brain.  Or maybe a more appropriate metaphor is the car and the product owner is both the driver and the fuel pump.  Either way, bad things happen when the product owner is not fulfilling the expectations of their role.  As driver, they are responsible for setting overall expectations of the release schedule and for choosing the stories that will be built in each iteration.  If these expectations are mismanaged, then the customers that they proxy are disappointed, or worse yet, uninterested.  The driver needs to be awake at the wheel or risk driving off the road and into a tree.  As fuel pump, they need to keep a healthy supply of meaningful work flowing into the team in the form of actionable stories.  If the supply dries up, then the engine will cough, sputter, and stall and it is at least a 10 mile hike to get more gas.

I’ve had the pleasure of working with several great product managers over the years.  No matter how firm an advocate for Agile that they might become, they all started with a certain amount of FUD (fear, uncertainty, and doubt) concerning what would happen.  How would they make sure that Product Development was accountable if scope or schedule was missed enough to affect the business?  How would they provide enough access to make sure the feature teams had the details they needed when they needed them?  How involved would they need to be in product testing and acceptance?  Would it really be easier to shift the priorities of the team if the customers or market shifts?

There are lots of reasons to have the doubts given any typical past experience.  Product development leadership is often hard headed and slippery.  We fight scope change, evade making schedule commitments, and mask our motives as we try to steer our resources to work on things we want to do instead of things that the business needs.  Schedules can overrun by 50 to 100% as the team struggles to find “done” and to harden the product to ready it for release.  Important external commitments are missed, wasting product marketing expense or frustrating existing or new customers.  It’s amazing these people will even talk to us!

Harriet Island - St. Paul, MN

Let me try to address a few of these concerns, albeit from the somewhat biased perspective of development management.  I do have some credentials for doing so as I spent a couple years at Highjump as our Product Owner for our platform, but I admit that I still tend to approach the role from a technical rather than business perspective.

———————————————–

How would they make sure that Product Development was accountable if scope or schedule was missed enough to affect the business? 

This one is tough, but the trust is earned over time by showing that PD will behave in a way where they accept responsibility for schedule rather than try to point fingers.  Trust is the key, and this can NEVER be violated – the product owner owns WHAT we do and PD owns HOW we do it and WHEN it will get done.  Once the Agile feature teams stabilize, I would expect to see iterations accurate in delivery to within 10% of the promised features.  

Since the only real tool we have for managing scope is schedule, we defer to ALWAYS driving to the scheduled date and only change that date if the content of the release that is ready as that date approaches is inadequate to justify a release.  My experience has been that we usually choose to push the available product to market and simply commit to working on the highest priority features next and releasing again soon if that is justified.  Agreed, the product owner rarely gets everything they want, but they do get most of it, and they do get the most important things on their list (because we built the features in order of priority to the market and the business).

Waterfall thinking involves placing a point at some future space-time and building a contract (some would call this a shared delusion) around hitting that point.  Yes, this is a bit like hitting an airplane with a slingshot.  Agile thinking is based an focusing instead on the path that is taken.  We make sure we are always pointed straight at the target even when it moves by correcting the path as we go.

How would they provide enough access to make sure the feature teams had the details they needed when they needed them? 

 The usual thought is that it’s most efficient to batch this work.  I’ll just sit down and write out all of the details around what I want.  Even though I have other responsibilities, it will be easier to convince others that those can wait while I take a few weeks (or months) to get all of this written down.  As I start to write, I get increasingly worried that I better record as much detail as possible because I may not get to see the product until the end.  From past experience, I find that the developers are usually sick and tired of working on the feature by then and they fight any changes or refinements I suggest.  To compensate, I start capturing more and more detail, carefully designing screen shots and explaining field by field exactly how I want the screen to behave.

In the mean time, the technical team sits semi-idle filling time by fixing defects or working on technical initiatives related to tools or infrastructure.  Idle hands start refactoring code just because it needs it.  We learn our lesson and commit that next team we will start this preparation even earlier so that it is ready when the team is ready for new assignments, but those good intentions just don’t seem to happen.

Agile provides an alternative – focus on small, evocative documents that describe the themes and intent of the release and associated stories, then sort the details out on a Just In Time basis.  Development teams can and will get most of the details right given only a crude skeleton as long as you help get them into the mindset of the users.  The errors that remain are quickly caught during the iteration or at the iteration review.  Because you focus on answering only the questions that are essential, your average investment in time is actually less AND you are able to head off misunderstandings quickly.  I would expect your time commitment to be 5-10 hours per week.

How involved would they need to be in product testing and acceptance? 

Because Agile feature teams have testers embedded in them and these testers are responsible for determining the more detailed definition of “done” for the story at the start of the iteration (by documenting the exit criteria and test cases), you should expect them to have questions at the start of the iteration.  In return, they act as your proxy during the iteration and you should be able to expect high quality, usable features to try throughout and at the end of the iteration.  The team should be making the product available to you constantly during the iteration so that you can try these things out as they happen – builds should get promoted to a TEST environment that you are free to use. 

If you see something you want to change, mention it now in case it is easy and appropriate to fix it now, but also be prepared for the possibility that the change needs to be purchased as a story in the next iteration.  That’s perfectly natural, and the next iteration is never more than two weeks away.  Record the story now, it will get estimated for you at the next estimation meeting, and make sure you keep track of it so you can buy it for the next iteration.  If at that time you decide that there are other more important things to buy – great!  It will still be there in the product backlog if and when you decide it is the right thing to do next.  Instead of being a burden, this is the source of your visibility and control.

Would it really be easier to shift the priorities of the team if the customers or market shifts?

This is perhaps the most successful aspect of Agile for a product manager, although it does depend on changing your behavior to batch change into what I would call “punctuated equilibria”.  I first heard this idea in the context of evolution – species some to change very little over long periods of time, and then suddenly lots of things change very quickly, followed by another period with little change.  As mentioned earlier, change is natural and expected.  Every developer wants their feature to be right – if you give them feedback they can accommodate during the iteration, they will very likely try.  If not, then it just goes into backlog and you pick it up at the next cycle.

My experience has been that keeping iterations short (2 weeks) helps make sure that there is enough ability to react to a change in business need without thrashing the development team.  Constant changing of priority leads to lack of confidence and motivation in the team – the discipline to control your change to predefined periods of time in the cycle is a small price to pay for higher feature output from the team.

 —————————————-

This is really only the beginning of what I expect to be a conversation that is rich enough that you could write a book on this topic alone.  I’ve also sent out invitations to several of these product owners to see if they are willing to share more of their own perspectives and it looks like we will have a few of these to post soon.  In a recent conversation with one of these champions, Kate Bolseth, I learned that within her current organization, she is actually creating pull for Agile practices by having the Product Management Team request them from the Product Development team.  I find this case fascinating, as my own experiences (including when first working with Kate) have been with these changes starting internal to Product Development and with us needing to convince others, especially Product Management, that it would work.  I will watch with interest to see if having the stimulus come from outside PD is even more effective at creating an Agile organization – since this is usually the biggest external challenge PD would face, I suspect that it will.

Heretic!!!  Outcast!!!  Unclean!!!

OK, I just need to get this off of my chest.  I know that all of the books you read on Agile (and I’m reading more lately as I round out my practice with current theory) say that you are welcome to modify the practices as you see fit.  But I also worry that I am somehow letting them down by frowning on even one of the practices, especially if that turns out to be THE one that makes “Agile” agile.  After years of adherence to most if not all of the remaining practices, I think it is finally time to say:

I don’t believe in pair programming.

Now, I know that pair programming can exist (I’ve heard enough stories to confirm it) and I even believe that its practice can accomplish what it purports – higher quality code at the expense of some (experts argue – let’s see if we can agree on 20%) productivity.  Expressed as such a tradeoff, this sounds more like a business decision – I’m the manager and we’re about to make embedded software for a heart defibrillator, so I think I’ll just turn the “Quality” knob up to 11, watch the productivity meter drop to 80%, and enjoy watching the flawless code come out of the sausage machine.

My concerns come from two levels – let’s start with the personal level first and just get that out of the way.  Then we can have a more informed and vigorous debate of the merits of the practice from the point of view of a manager of an Agile team.

Brooklyn Bridge - New York, NY

In case you haven’t heard the term “flow”, let me briefly introduce it.  I first ran into the concept when I read the first edition of “Peopleware” by Tom DeMarco and Timothy Lister.  Flow is that almost transcendental state that programmers can achieve where their brain is so focused on a problem that they lose all sense of time.  As a younger developer, I could do 10 hours of programming standing on my head and not even break a sweat.  I used to constantly arrive home late because I lost track of time or needed to finish just one more thing or the problem would bug me all night long.  That’s what flow is, and as I started to move into leadership roles, that is the thing that I missed the most.

I can’t get into flow when I’m pair programming.  If I’m at the keyboard, then my mind and fingers seize up as I devote too many cycles to thinking about how the other person is thinking about the problem instead of the problem itself.  If I’m observing, then I’m bored most of the time and wondering why the other person can’t solve the problem.  In short, pair programming spoils everything that I would say I enjoy about the creative construction process.

Now, if anybody else out there is like me, can I get a “Holla back!”?

I have a rule that has served me pretty well as a manager – don’t expect others to do what you wouldn’t do yourself.  If I would call B.S. as an individual contributor, then how can I possibly stand up in front of the group and preach the virtues of the same practice?  Because of this rule, I have conducted a bit of an experiment over the last 5 years.  I have explained what pair programming is, I have voiced my support for it, but I have never crossed the line to forcing it to happen.  Over that time, I have only witnessed spontaneous pair programming a couple of times and never as a sustained practice.  When it did happen, it was always in a senior/junior coaching scenario with the junior programmer at the keyboard, but as the individual found their footing, the practice stopped.

I’ve been reluctant to publicly express my opinion on this topic before because I needed to allow for the possibility that I was very different from others and that their experience would be better than my own, but after all of these years I think it is time to say with more conviction that while I admire the idea of pair programming, I don’t believe in its practice.

My son and I were talking last night about this year’s debate resolution; it happens to pertain to the United Nations and the role it should take in actively solving one or more of the world’s problems.  He said “I used to be a big believer in idea of the UN, but now that I’ve seen how little it can accomplish, I don’t feel that way anymore.”  Given my understanding of some of his political leanings, I was a bit surprised by this kind of cynicism in a 17 year old.  “What good is it if it just doesn’t work in practice.  Paint a picture of it and hang it on the wall so you can look at it.”

He’s wise for a 17 year old.  SNAP…just took a picture of “pair programming” in my mind.  BANG, BANG, BANG…just hung it in my mental gallery between my pictures of the UN and the pet rock.  Ahh…isn’t it lovely.

I know many of my friends from Gearworks are a core group of followers on this blog, so I thought I would take some time to record the moment for you as a private citizen and not as an executive at Gearworks.  I need this for closure and I hope you will find some comfort in it too.

Let me start by saying that despite all the emotion surrounding the event itself, I’m truly content with the decision and excited to find a new path.  I know I will look back at this and see it as the springboard that pushed me out of the nest.  Having said that, there are still a number of things that I wish were different.  I don’t like living with regret, so hopefully this will prove to be the cathartic experience I need – I’m going to say these things once and not look back.

Foggy Morning - Coon Rapids, MN

I wish that I did not feel disappointment about letting all of you down.  We did a LOT of things right, but if we had done everything right, then we would not have found ourselves in the position of merging Gearworks out of existence.

I wish I felt that I was done with what I set out to accomplish here – this is strange to say as so many of our efforts turned out more successful than I could ever hope, but the “maximizer” in me can’t help but see that even more was possible.

I wish our new platform was already a market success.  I know this is coming, and even plan on continuing to participate in the process, but I had hoped to see FFM and Etrace shipping on ThinAir to new customers and to see the economic benefits that I know will come as you finish that transition.

I wish that I could keep working with Rob.  We make a freakin’ wicked duo with my yin to his yang.

I wish that we had lived every day like the most important thing to do was to find the formula for profitability.  Looking back I can now say that in the end, this was what really mattered more than anything else.  The strategy to get there was sound but we didn’t move far enough fast enough, and now that I see what we are capable of doing to adjust to merging into a new organization and finding new cost efficiencies, I wish we had done these on our terms instead.

And finally, I wish all of you the success that you deserve.  Xora is lucky to have you, and I know you will find your footing and create a winning combination.  I am encouraged by the recognition you are receiving for the strength of your skills, of your product, and especially of your processes, and for that I am quite proud.  Now get out there, be Xora, and be brilliant!

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

—Kent Beck, Approaching a Minimum Viable Product

Many thanks to Dave Morehouse for forwarding the quote and link to me – it’s perfect.  I happened to read it again while also reviewing a paper written by a friend that highlighted some of the challenges of introducing software and software-related services at a large, successful manufacturing company.  My past experience has always suggested that shipping is not only important, but it is THE most important thing.  There are lots of things to worry about – does it have the right features, is the quality level there, etc – but despite all of these worries, when you have reached that crisis of confidence, this is when you have to double down and ship.  I’m fond of saying that in the end game there are lots of reasons to NOT ship – that’s why shipping is the hardest thing to do.  If you don’t have a maniacal focus on getting your product born, you risk the serious possibility of it never seeing the light of day.

Coon Rapids Dam - Coon Rapids, MN

This mentality is where the motto of “Shipito Ergo Sum” comes from – “I ship, therefore I am”.  Very early on I discovered the rule of thumb that “organizations can’t stand to wait more than 4-6 months to see a product release come to life“, and if you take longer than that, then some crisis will divert the attention or resources of the company away from your goal and you will be left without a mandate.  I saw this happen once – saw six months of effort by a half dozen people flushed down the drain (and some of the people with them) – very sad.

By the way, the corollary to this is “Life is too short to build things that no one will buy“.  There was a point where I was willing to build just for the sheer joy of learning, but those days are long gone.

Enough about that – what was the message from my friend’s paper?  Because of the past success of this organization in other areas, they were particularly conservative about protecting their brand image and shoring up any potential legal liabilities, and as a result they had even more reasons to NOT ship than the typical software organization.  It’s hard to imagine how to bring balance between these concerns and the need to throw “Minimum Viable Products” at the wall to see if they stick.  In my opinion, this could even be the fatal flaw that prevents organizations from venturing into software and related services unless their current success came from the software realm – large companies with much to lose have a hard time putting it at risk to compete aggressively enough to win at new markets.

Here’s a link to the full article if you are interested in learning more:  http://www.threeriversinstitute.org/blog/?p=333

I only started this book over the weekend and I’m gulping it down – “Agile Adoption Patterns: A Roadmap to Organizational Success” by Amr Elssamadisy. I’ve mentioned the book “The Goal” before – the opening chapter of “Agile Adoption Patterns” starts with the premise that when driving Agile adoption, and even later while executing work within a self-directed team, learning is the bottleneck.  In “The Goal”, Goldratt explains his Theory of Constraints and the notion that the output of any process with a series of dependent steps is limited to the capacity of the bottleneck resource in the process.

During the initial transformation, this premise is absolutely true.  To catch the spirit of the team, you have to find one or more champions and nurture their interest in learning.  I’ve also seen that knowledge can wane over time due to turnover or lack of attention, and while the established rhythms might continue, you would not see the same level of understanding or commitment throughout the organization.  Only the “high priests” might really understand why the rituals are important, and this puts the practice itself in a fairly precarious position.  I recently met with Amy Pabich from Highjump and she described a “Recommitment to Agile” training process that they went through several years after the initial adoption which included better documenting their own spin on Agile and a training effort with the new distributed teams that they had acquired.  I heard from her and others that were there at the time that this was instrumental in revitalizing team productivity.

One thing that I have seen consistently in every organization I have worked with is that once you get the team trained in and executing with a repeatable rhythm, the next obvious bottleneck that seems to always arise is “testing”.  I have also seen that this is usually the combination of understaffing and a “not in my job description” attitude within the team that needs to change.  I won’t go into that in more detail now as it is probably worth a topic of it’s own.

Chapter 2 continues by identifying the most common cause of failure in adoption – failure to take responsibility.  Amr analyzes a “Responsibility Process(TM) Model” introduced by Christopher Avery and Bill McCarley and relates the approach to identifying those individuals within the organization that are ready to assume responsibility for what is happening and demonstrate personal agility.

Autumn Arrives at St. Croix Vineyards - Stillwater, MN

The next two chapters are fantastic – Chapter 3 enumerates possible sources of business value that can be delivered by Agile and encourages you to clearly identify why it is important to you.  All of his listed topics are spot on, but I would probably add a few more subtle suggestion to the list – “improved predictability” and “increased intensity”.  I’ve had occasion to work with other senior managers in Agile shops that are now working with other companies and these are the things they miss.  While Agile isn’t designed to exploit engineers, its focus on frequent, visible and measurable deliverables does create a more consistent output from the team and at least the perception that everyone is working harder because there is more transparency around the business value of what they are doing.

Chapter 4 lists “smells” that are easily identified and symptoms of a sick process; the value of this diagnosis is that with this information you can more clearly identify particular Agile practices (or groups) that are likely to help improve that aspect of your process.  This helps lay out a roadmap for adoption.  Much of the remainder of the book is a catalog of Agile practices in pattern form – this familiar approach will help analytical engineers overcome their bias against discussions of process as too soft a science and also provides prescriptive, actionable steps to take and references to additional information. 

Get a copy and enjoy – it will be required reading for my current and future pupils.

Geese In Formation - Coon Rapids, MN

In a previous post (Two Phase Commits in Agile) I introduced the idea of two levels of estimation – coarse story points that are suitable for managing the funnel of work into the teams and another level of estimation within the iteration designed to build buy-in within the team for the iteration itself.  Jeff Whiteside, one of our feature team leads, has been particularly innovative in this respect, so I asked him to share his thoughts and methods with us.  Here goes – thanks Jeff!

———————————————————————

Students are taught to fly planes relying only on their instrument panel. They wear hoods or glasses limiting their vision to see only their controls. They must learn to trust the controls and their own instincts. Of course the instructor is always there to help if things get out of control. Now imagine if the controls were unavailable as well and all you had to rely on is the instructor reassuring you that everything was fine.

As I began leading my development team in Belarus, I found my role somewhat analogous to the student. As our two-week iterations progressed, I would get frequent status updates from my team, usually, very positive, hailing the great progress and always promising to complete features on-time. Yet, iteration after iteration, we failed to deliver. The code was usually complete; however, the testing was not.

I challenged my team to find a solution for this problem. They determined that the story estimates we provided them were not accurate. After failed attempts to involve them in story estimation, I asked them to estimate the stories. The story estimates we provided were in abstract story points. The estimates they would provide would be in person hours including both developers and testers. The estimations would be done during iteration planning. Now we had always done iteration planning, but I could never be sure what was really occurring. I got the sense that they spent a few minutes looking at the stories and then jumped back into code to finish up the work they didn’t finish in the previous iteration. I wanted them to really analyze the stories and personally and publicly commit to completing each. As a bonus they would be allowed to reject or split stories they could not commit to. Of course it would be the product owners prerogative as to which stories were removed.

In order to get accurate estimates, the team needed to break down each story into actionable tasks and estimate each. This process of breaking down tasks forced them to thoroughly analyze the requirements and get immediate clarification for anything unclear. Since the tester was also responsible for estimating their effort, they were more engaged in the task breakdown so they better understood the stories. The engineers were also encouraged to design and prototype any complex stories during iteration planning, improving estimates. This process usually took between two and four hours. For complex stories with a lot of design or prototyping, it could take a full day. I was okay with this as long as the process produced stories with actionable tasks and reasonable estimates.

Each day the team re-estimated each story determining how much work was remaining. This was plotted on a graph against the number of hours available in each day. The result is a burndown chart that visually shows the teams progress against the expected progress, clearly indicating if the team is on schedule or falling behind. If the actual was on a slope equal or greater than the baseline we were on track, but if the actual began to creep above the baseline we were falling behind.

Example Iteration Burndown

So how did all this help us? First, since the team was publicly committing to completing the work, a new sense of urgency surfaced. They also took more ownership of the stories. Second, since we were estimating in person hours, we could better predict the right amount of stories to add to the iteration by comparing the estimate to team capacity. This normalized our velocity and improved the teams rhythm. Third, it provided a immediate visual feedback allowing us to adjust, refocus, or renegotiate with the product owner. These changes made dramatic improvements in how the team functioned and its effectiveness and I new feel less like I am flying blind.

- Jeff Whiteside

The team sat down to breakfast a week ago to tackle a number of subjects, but the most interesting of them was “profit sharing”.  Our business model proposes revenue sharing from a number of different channels including our own billable time and this revenue goes into a pool.  Shared costs are deducted from that pool and the result is a net profit for the period for the company.  Generally speaking, LLCs are better off distributing any net gains for the period to the partners as they will be usually be taxed at a lower individual rate than the corporate tax and since we have an intentionally lightweight structure (we don’t intend to have any employees), there really isn’t a reason to be sitting on a large bank account.  We need enough liquidity to cover payments to suppliers and to allow for the inevitable delay in receivables, but that is about it for now.

Spider Web - Coon Rapids, MN

So, the possibilities for determining the distribution percentages range from a straight split (simply divide by 3) to a fully weighted percentage based on some other criteria and the possibility of hybrids in between.  The tradeoffs are many:

• Simplicity in tracking
• Incentive to generate new work by finding new clients
• Incentive to deliver work
• Incentive to maintain satisfied clients

Given that the purpose of a partnership is to share risk, there is a certain elegance to planning to share rewards equally.  Oddly (and I think this is a good sign for the partnership!) we spent most of our energy trying to look out for each others interests – Scott and Adam thought that I might have more success in bringing in new business to the organization, but I felt that I would need everyone’s help figuring out how to deliver it.

In the end, we opted for a hybrid – we will give preferential treatment to the “finder” of a revenue stream, but only slight.  Instead of splitting the proceeds in even 3 parts, we will instead pay out 40% to the finder and 30% to each of the other two partners.  This tips the majority of the compensation towards shared reward but still provides some incentive for bringing in new profit streams.  I’m sure it will take a few cycles of this to iron out the system, but this seems like a good place to start.

I just finished reading “Managing Offshore Development Projects:  An Agile Approach” by Upadrista Venkatesh.  I picked this book up as I have a more than passing interest in the combination of Agile and distributed teams – after 3 different experiences now, I’m convince that Agile is a great way to create an operational rhythm that spans the globe.  I think there is a book idea in there, so I figured I better get a sense of what others have said in the space.

To my surprise, the book really didn’t talk about Agile having any unique qualities that make it relevant to offshore.  Instead, the only real value proposition were the examples of customer satisfaction improving when customers were able to see the work output from the team more often.  This is a somewhat universal phenomena and not at all surprising, so I thought maybe there would be more about how the flow of work and product worked between the local and remote teams.  Instead, the model cited focused on the importance of having the offshore provider embed onshore resources with the client team.

Fort Snelling Cemetary - St. Paul, MN

This was a bit disappointing to me as it’s a too common refrain among the offshore contractor shops – you don’t need to do anything different;  we’ll just send some of our staff to live and work directly with you and they will take care of everything.  By the way, the onshore staff usually cost as much or more than it would for you to provide your own employees in the same roles.

Our experience has been quite the opposite – once the intent to use offshore to perform strategic work is clear, we’ve had great success identifying leaders from the existing personnel.  With coaching they can quickly make the transition to team lead and quickly come to appreciate the power of having a much larger team at their command.  Since we combine the team lead role with technical architect for the features, these leaders also find that their technical interests continue to be challenged.  We make accommodations in workstyle so that they have the flexibility to work when and where they need to in order to get the job done.  I’ve now seen 6 different people make this transition with success – these include Adam Henry, Jamie Bolseth, Eric Welch, Jeff Whiteside, David Morehouse, and Ken Dombeck.  Each did the job a little differently, but all were successful in sustaining the role for a long period of time and were able to use Agile scrum to manage the flow of work to their teams.  All depended on the use of shared tools to support story collection, estimation, defect tracking, version control, and continuous build processes.  None would have accepted having an intermediary between themselves and their teams.

Back to the book – there are a couple of interesting ideas worth mentioning, although they are not particularly related to offshore or Agile; they simply relate to the deep program management experience of the author.  The first is that for sufficiently large teams of contractors, the leadership needs to be careful to not mistake billing for productivity.  A contractor can and will maximize billing by placing as many resources into the account as possible regardless of their strength in the technologies at hand.  As a result, work quality and efficiency begins to suffer.  The author notes a couple of examples where he was able to improve team output by making sure each person’s skills fit their role and in some cases even removing people from the team.  He also mentions the value of recruiting team members in parallel with pursuing new business and gives advice on how to best manage this situation if the business doesn’t close as expected.  Useful advice if you are the provider of contractor resources, but not really related to making Agile and offshore work together.

There seems to still be plenty of room for a good book on using Agile and offshore together