Marcato

I’m in the midst of bootstrapping a new Agile team with a client of ours – Kardia Health.  While this is familiar territory and the end game is clear, each time I go through it I am reminded about how monumentally large the small details seem to be.  It’s entirely unlike riding a bike, especially when it involves a new team working on new applications with an entirely new toolset.  It’s more like watching a small child learn how to walk – the brain knows what it wants to do but the body just doesn’t know how to do it yet.

The last few weeks have been frantic with preparation – securing our funding, lining up the team members, working to finalize the services agreement with the offshore provider, trying to get access to our lifecycle management tool of choice (Microsoft’s Team Foundation Server), trying to get a development environment set up so that work can begin soon after the first iteration starts – there seems to be an endless number of things that you want to do before you start so that you can start well.

I’m a big fan of Maslow’s Hierarchy of Needs – situations like this really help to clarify what is most important; there are lots of things that you would like to have in place before you start, but really only a few that MUST be there in order for your iteration to have any semblance to a real Agile iteration.  What are those things?

• At least two other people – a product owner to help you know what is important and another technical team member to teach.
• A duration for your iteration – I’ve already advised that you try two weeks first.
• Stories for your first iteration – some of these can be to establish infrastructure, but make sure the primary effort for the team is to build something of value to the business.
• Story point estimates – the only thing of importance at this stage is to establish a stable estimator; accuracy comes later after two or three sprints.  For now, just focus on getting a consistent team together to do the estimating.  And since most people have difficulty with the idea that these estimates have no standard, feel free to start with the arbitrary standard that a point represents one hour of effort.  With this starting point in mind, we’ve found that powers of 2 (1,2,4,8…128) represent a useful sequence that covers the range.  64 is about the practical high limit, and 128 effectively means “too large to estimate” and needs to be broken down.
• An estimate of capacity for the sprint – again, since you have no real foundation for this, just add up the person-hours available to you – we will have 3 people for 2 weeks, so our initial estimate of velocity for the team will be 240 points.
• A readiness to learn.

That should just about do it – the rest is relevant in the long run, but not essential to start.  After all, Agile is about the journey, and as long as you begin by building a culture of learning, then you have the most essential ingredient.  It would be nice to have the stories in a tracking took so that estimation and task breakdown can all be tracked, but there are low budget approaches to these things that work just fine.  It would be great to have a build process linked to a continuous integration tool, but you can get by without that too.  All these things will come in good time, but the most important thing is to just…

…start.

Scott and I are headed to the Chippewa Valley Code Camp tomorrow to present on “Using Agile to Lead Distributed Teams”.  We’re part of a track on “Building Better Software” and there will be another session on Agile as well – it will introduce basic practices and then we’ll cover a couple of case studies of teams using Agile here in Minnesota and around the world.  I’ll post the slides with this entry after we get back – they’re not done yet

Update:

I saw a couple of sessions in addition to the one we presented.  The first was by Jill Tiefel of Innovative Writing and Design – she walked us through 10 myths of usability testing and hit the nail right on the head.  I had a chance to go through this process once at Gearworks – I was skeptical going into it, but our goal was to try to get a more objective view on how to improve the usability of our products as part of a new project called 80/20.  I found that there were two very tangible benefits:

• the preparation of the paper mockups pushed us to think through the details of screen layout and navigation before we started to build the product at a level of detail that was far more complete than I had seen before
• we had hard facts to back our decisions about what was best for layout, screen flow, colors, icons, etc; this helped us deal with the many opinions we would get from senior management and others about what they thought would make for an easier to use or more intuitive design

Jill knew her stuff, and I suspect she could provide a fairly affordable alternative to some of the lab-based studies.

My second session was an introduction to Agile by Tom Steele of Three Rivers Technologies.  He did a good job of covering the basics of the methodology in the 75 minutes he had – he was really compressing a half-day session into a much shorter format.  From this I realized how hard it is to get people from a cold start to some basic understanding of the practices – there is just too much to talk about for people to feel comfortable with what they learned.  I also think there is a tendency to dwell on the philosophies as we try to create converts rather than just focusing on the history, terminology, and most common practices.

Here was our presentation – since it was clear we were addressing an audience that was new to Agile, we started with a Q&A session to try to reinforce some of Tom’s teaching.  From there we covered our own planned content in about 45 minutes – the topic was a bit too esoteric for most there, and we’ll probably start looking for alternative forums or plan to deliver only intro-level material at future code camps.  Here’s our presentation if you are interested:

Using Agile to Manage Distributed Teams

And there will be more posted at:

http://www.chippewavalleycodecamp.com

I have had the opportunity to work with several different offshore teams and providers, but none have moved to truly embrace Agile as the preferred methodology for delivery like Coherent. Below is an article extracted from their most recent newsletter – in it you will see they echo an observation I have made many times before: the typical reaction to moving work to offshore teams seems to be one of assuming that this means that an even more significant investment in up front documentation and design is needed to manage the relationship.

In our experience, the opposite seems to be the case. Teams that approach the problem this way seem to think that this up front investment means that they will not need to interact with the remote team often during implementation. Instead, the practices and rhythms of Agile drive you to do two things that make all the difference:

• Create a local infrastructure to support and direct the remote teams
• Guarantee frequent, daily communication and regular demonstrations of functional product

For Coherent, this is more than marketing – it is integral to their business strategy. They position themselves as a service provider to the small- to mid-market product and IT organizations. Agile fits well with these organizations, and the desire to apply it is usually mutual. Because the management and technical teams at Coherent have this bias and experience, the have been a good partner past and present.

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

Agile the Perfect Match for Offshore

by Rob Duff, VP Service Delivery

Much debate has existed over the last few years on the topic of Agile development processes and their suitability for managing/coordinating offshore development projects. Our experience at Coherent Solutions during that timeframe is that Agile is superior to traditional “planned” methodologies for managing offshore teams (although traditional methodologies can be used effectively as well). This experience, however, is counterintuitive to what one would expect. Intuitively, one would think offshore would require more process overhead, more documentation, and more control and that Agile would be a poor match.

Even the author’s of the Agile Manifesto would not have predicted that Agile could work in an offshore context in 2001 when they stated “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Indeed, much of the content generated at the dawn of Agile emphasized actual physical proximity of team members to maximize communication efficacy. While proximity no doubt aids communication, the richness, ubiquity, and low price of communication technologies circa 2009 make it much less important than it was almost ten years ago when the Manifesto was written.

So what is it about Agile that is so well suited for offshore teams? About a month ago I attended the World Business Forum in New York and had the good fortune to hear a number of excellent speakers discuss the current economic climate and management strategies. I particularly enjoyed two speakers, Gary Hamel (www.garyhamel.com) and Patrick Lencioni (www.tablegroup.com), and although they were talking about management strategy and organizational concepts in general, I found much of what they said relevant to the power behind Agile methods in an offshore development context.

Gary Hamel discussed a hierarchy of employee traits analogous to Maslow’s hierarchy of needs. In ascending order these capabilities are (1) obedience (2) diligence (3) intellect (4) initiative (5) creativity (6) passion. The first three (obedience, diligence, intellect) are table stakes for organizations—essentially they represent smart people who work hard and do what they’re told. With a highly educated global workforce Hamel asserts that these traits are commodities that are easier to buy than at any previous point in history. The second three traits (initiative, creativity, passion), however, drive true innovation. These traits are particularly notable because they cannot be commanded by organizations. Instead, they must be offered voluntarily by team members. This implies the creation of a culture that encourages this high value-added behavior.

Patrick Lencioni humorously discussed the five dysfunctions of teams. This link gives a full explanation, but in summarized form they are (1) Lack of trust (2) Fear of conflict (3) Lack of commitment (4) Avoidance of accountability (5) Inattention to results. They are similarly hierarchical in nature. For example, Fear of Conflict (2) cannot be fixed until Trust (1) is built within the team. Accountability (4) can’t exist until there is (3) Commitment from the team members. They all culminate where the rubber meets the road—inattention to results.

Anyone who has worked on software development projects understands the impact people have on results. Software development is a quintessentially creative and intellectual endeavor (Hamel’s second three traits). It is not a mechanical process (Hamel’s first three traits). Further, it is the ultimate team oriented endeavor. Therefore, the state of people’s morale, energy, and willingness to collaborate makes a big impact on the productivity and quality of results. What is often lost in offshore outsourcing projects is the individuals on the other end of the phone (offshore) are actual people too. They have their own ideas, moods, and energy. What Agile does so beautifully is provide a framework for team building that constructively engages everyone as first class team members channeling ideas and energy for the benefit of the team. It is our experience that this framework maintains that personal level of engagement even when used with a distributed team. Offshore team members feel more involved in the team resulting in a higher level of personal commitment, productivity, and innovation. In short it maximizes the high value-added traits Hamel cited as necessary for success.

Agile’s attention to the softer side of management yields real benefits. It should not, however, be mistaken as a “kum ba ya” methodology. It is highly focused on results and this characteristic is equally critical to its effectiveness in offshore development. As stated in the Agile Manifesto’s principles, “Working software is the primary measure of progress.” Properly run Agile teams are held accountable to this measure combating Lencioni’s previously mentioned two highest team dysfunctions. The distributed and sometimes cross-organizational nature of offshore outsourcing teams makes accountability and focus on results challenging. Utilizing a document heavy or plan heavy methodology only exacerbates this by providing secondary measures of progress that make results easier to obscure (e.g. a pretty design model as opposed to a software module that passed x unit tests). Agile’s laser-like focus on the bottom line of working software effectively strips the complexity of software development and offshore outsourcing to its core and focuses everyone on actual results. This ensures the necessary transparency to manage offshore development teams and facilitates proper alignment between the offshore development team, its customers/users, and its customer/users’ management.

Agile methods and offshore development teams are two independent phenomena that are no doubt here to stay in the software development industry. Historically, these phenomena were seen to be incompatible. Increasingly, however, leading organizations have discovered they are actually complimentary. This discovery has allowed these organizations to capture even more value from their offshore development partnerships and unlock the innovation needed to compete in today’s hyper competitive environment.

About Coherent Solutions

Since 1995, Coherent Solutions has helped over 100 clients successfully create and integrate an affordable outsourced software development capability for commercial grade software products. With offices and highly experienced teams in both the U.S. and Eastern Europe, the company’s high-touch relationship approach includes unparalleled U.S. delivery management, strong integration throughout the service delivery supply chain, and a commitment to surpassing expectations. For more information, please visit www.coherentsolutions.com.

This week I had the pleasure of having lunch with a Marcato partner and a new acquaintance.  The conversation started as they always do – talk about our respective backgrounds and experiences and given the small size of this town, looking for points where our paths nearly crossed.  Then the story turns to the common themes of my own experiences leading up to the decision to found Marcato – building Agile, high functioning teams, supporting distributed development, creating and rewarding a culture of performance, a focus on shipping as the ultimate expression of our art, etc.  Then magic happens…

When you get to this point, you either connect or you don’t.  I had no idea what would happen, because frankly, the organization where he works today is not really known for its technology accomplishments or savvy.  Rather, it has the curse of deep pockets, allowing it to fund teams that are too large to be effective and goals too audacious to ship.  Would there be too large a gap for finding common ground?

Hardly.  We seemed to first click over comparing notes between our mutual experiences with large organizations that want to have or use software technology but just can’t seem to figure out how.  We agreed that it is due to fundamental mistrust of the practitioners (partially well founded – come on folks, admit it – the software highway is littered with the smoking ruins of past edifices to the gods) but also largely due to forcing upon those teams resource and project managers that simply do not understand the technology and people that they are trying to lead.

Then things really started to pick up as the conversation turned to past experiences with high functioning teams.  We all got more animated as we learned about his experiences building and leading a large IT organization that operated top to bottom as an Agile team should.  We talked about the challenges of convincing the business, marketing, and product managers to break the culture of “up front contract” but how once people have crossed over they become converts for life and never want to cross back.

We talked about the team he had built years ago – how he had recruited them, how they were organized, how they functioned, what they delivered – everything was picture perfect.  This was when I knew I was talking to a true believer – his energy wasn’t coming from intellectual curiosity based on something he had read in a book or blog but from the clarity of vision that comes from having experienced something profound.  He had built something special, and you could tell both that he missed it and that lightning would definitely strike more than once – this was a leader that knew what he wanted and whose energy and enthusiasm could move people to change.

Unfortunately, I’m not sure that opportunity will happen in the organization he is in – they would have to realize that they need to place their trust in leaders like him and invest in letting them organize for success.  It was painfully obvious to all of us that they had far too many people working on their projects, and worse yet, that they lacked the management visibility to be able to accurately identify the bottom 25% of the performers so that they could start to fix it.  A vicious cycle to perpetuate mediocrity on the whole despite the efforts and talents of a few scattered throughout the organization.

I think there is an unwarranted association with this problem being evident in organizations using offshore teams.  Granted, it’s easy to let this happen, but it all hinges on the quality of personnel you maintain in the onshore part of the organization.  If you retain and recruit the best people you can find for these critical roles and make sure that they have a sustainable lifestyle, then great things can happen.  If you try to eliminate this layer by using a combination of business analysts as architects and project managers as leaders (probably even sourced by the offshore provider), then you will get poorly conceived and poorly executed projects.

Our guest said something particularly profound that I’ll attempt to paraphrase:  ”They are smart enough to know that their purchasing department should be led by people that used to be buyers or their finance team by someone that used to be an accountant, but for some reason they don’t think the leaders of the software teams need to be people that used to build, test, and ship products.”  I have certainly seen that in my own career and it likely explains why I am always attracted to software “product” companies instead of IT organizations within a larger entity.  The latter needs software systems but do not understand them, the former lives and breathes them – they are the “factory” and the business is built around creating and sustaining a software eco-system or it fails.  A large manufacturer can have sub-par internal applications and still be successful.

It’s always good to meet another true believer – it gives me hope for what we are trying to accomplish with Marcato.  I find it hard to believe that we will not find a way, some how, some day, to work together.