Thursday, April 24, 2014

The Value of Learning with your Consultants

A common problem in software consulting (and business in general) is a focus on utilization over effectiveness. Companies want to avoid any perceived non-value producing time that could be billed to them. One symptom of this is that customers sometimes come with a solution rather than a problem. Customers would like to be able to provide a well thought out solution and simply have a contractor implement it.

The issue with this approach is that for projects of any real scale and/or complexity it is very difficult to truly know the scope of work. This one issue manifests itself immediately in two ways.

The first way is that the design doesn't really address every detail of the problem. There is always some gap, black swan, or misunderstanding.

The second way is that the spec includes more than is actually required. I call this 'Kitchen Sink Syndrome,' but differentiate it from scope creep. When business users are asked what the need in a solution they frequently include everything they can think of because they don't know when they may ever get another chance to affect the product.

Turn your consultants into domain experts

An alternative to the big design up front approach is for the customer and consultancy to work iteratively, learning together and for the solution to emerge from that learning. Begin with a minimal solution to the problem, gather feedback, refine the solution, rinse and repeat.

Through such a process a product of higher value is created, waste in the form of time spent creating a detailed specification is eliminated, waste in the form of unneeded features is avoided, and frequently the return on the investment is faster.

See how GE's use of Lean Startup practices helped them to improve


Wednesday, March 26, 2014

The Value of Collaboration

Collaboration - “the action of working with someone to produce or create something”

Collaboration is a key tenet of Agile software methodologies. It is mentioned or implied in both the agile manifesto and the the twelve principles behind the manifesto.

From the manifesto:
Customer collaboration over contract negotiation

From the principles:
Business people and developers must work 
together daily throughout the project.

The most efficient and effective method of 
conveying information to and within a development 
team is face-to-face conversation.

The best architectures, requirements, and designs 
emerge from self-organizing teams.


The manifesto and it’s backing principles (as well as the associated methodologies) are interleaved and synergistic. That is, when they are taken as a whole their effect is greater than the sum of their parts. The same is true for the nine items I identify as specific aspects of working with a lean-agile solutions provider which provide client value. While there is value in each of the items listed, taken as a whole their value is amplified. Nevertheless, I’m going to take them one at a time. :)

So, Collaboration...
It might be productive to distinguish between team level collaboration and business level collaboration, but I’m not going to. Instead I’m going to focus on collaboration at all levels because the benefits are similar.

Also, collaboration in the simple definition above is probably not enough to ensure it is valuable. It must be effective and efficient collaboration. Consequently I will put some definition around what it takes to be efficient and effective collaborators.

Effective collaboration implies active participation by the people involved. It requires engagement. There is no sitting at the back of the class and never raising your hand.

Active participation on the part of all involved helps to break down silos (or cliques, or tribes) which in turn eases the flow of information. Information transfer from one group to another (or from individuals) has a cost and that cost is reduced when information flows most easily and is transferred in small batches.

Active participation helps the best solution for a problem to emerge. Diversity of opinions and of views is a strength as long as it does not lead to analysis paralysis. A more effective solution (within constraints) is generally a more valuable solution.

Individuals who are active participants are pro-active. This translates to a very short if not instant feedback loop within a team or organization. Fast feedback leads creates agility. Corrections can be made early preventing expensive rework or failure demand.

Effective collaboration means shared ownership.

Team members are all respected as owners of the product. When this is more than lip service - when people are invested in the success of the product - morale increases. Morale is a velocity multiplier. High morale creates energy and that translates into better, faster work. Better, faster work decreases development costs because d’uh. Work that is completed faster than it may have been gives the potential for earlier ROI as well.

Shared understanding and shared learning are implicit in collaboration

Two people are not collaborating effectively if they do not have a shared understanding of what they are doing. They may even be working at cross purposes. This problem is multiplied with larger groups.

Emergent design is one way of helping to ensure the sharing of understanding and learning. When a client comes with a problem to be solved rather than a solution to a problem the final solution will be better. A broader range of experience will be applied to solving the problem.

When problem solving is part of the effort (as opposed to simply implementing a preconceived solution) the solution is likely to be better and much waste will be avoided. This is because a lean-agile provider will work iteratively with the client to provide a minimum solution initially and build on that as needed. This allows a solution to emerge that is narrowly focused on the problem and avoids the ‘everything but the kitchen sink’ typically found when requirements are being argued over prior to any design and development work being done.

Transparency and Visibility are key factors in effective collaboration

Two other facets of effective collaboration are transparency and visibility.

Transparency, in this respect, means not hiding information. The earlier information is available the sooner the information can be acted on. This is especially important when the news is bad, but can also be important with good news. It is good policy to adhere to the rule of least surprise. This helps to optimize the system rather than a single part of that system.

Take for example a software development team that will finish ahead of schedule but which chooses not to be transparent about its timeline because they want to hedge. In a project with a high cost of delay they may be missing a chance to advance their timetable and thereby save money. If they development team surprises the organization by completing early and the marketing and operations teams are not prepared because they are working to the expected schedule an opportunity may be missed.

Visibility is a good partner for transparency. Perhaps in the above situation the development team says, “we weren't hiding the information, no one asked about it.” In other words, they were being ‘transparent’ but they didn't make the information visible. It’s a nuanced difference perhaps, but an important one. We may think that the information is only relevant to us, but we may not be correct. Better to let others decide if the information is relevant to them or not. If there is a case of information overload, take a poll and see what information is useful. Information generally falls into categories or types (e.g. timeline, risks, surprises) that can be identified as important or not.

Thursday, March 6, 2014

What's in it for the Client?

Are there advantages in partnering with a Lean-Agile contractor/solution provider for companies looking to outsource work?  

A company presumably wants to present a problem, have a solution recommended, created and delivered to them and they want to know before they get started what it will cost and when it will be delivered.

To address this, using the 'Big Design Up Front' model, at the beginning of the project we do  analysis and design, a lot of estimating/guesswork as to how long it will take to deliver, padding of that estimate, the determination of the critical path of development, and we probably establish a heavyweight change management/request process.

There is a lot of CYA that goes on between two companies any time they work together, but I suspect that much of the focus on contracts and deliverables at the onset of a project arises from two things: Companies want to have what they need provided for them with a minimum amount of effort on their part; Companies (on both sides of the contract) fear that their collaborators will take advantage of them if they do not explicitly define all the details of the arrangement (e.g. lack of trust).

Traditional contractors/solution providers operate in simpatico with this approach, and in most cases it probably benefits the provider to do so.  if the client company decides something needs to be altered in the requirements due to a market change or new understanding, the change management process is invoked to adjust the timeline and to add additional billing for the change. At the end of the whole process the client is delivered something shiny and new and hopefully fitting the bill of their needs.

A Lean-Agile contractor/solution provider approaches the relationship a little differently.  

When working with a company or on a project my thoughts and actions are guided by the principles behind the agile manifesto, the principles of lean software development and of the Kanban Method.

What does this mean for clients?
  • Collaboration
  • Learning
  • Value
  • Quality
  • Holistic View
  • Eliminating Waste
  • Transparency
  • Early Delivery/Early Exit
  • Pursuit of Perfection
Over the next few weeks I will expand on each of these items explaining the value of each for the client.


Tuesday, August 3, 2010

The smallest good deed is better than the greatest good intention

Everyone has heard this platitude - which of course, doesn’t make it false.  Here’s another way to think about it: Limit your W.I.P. - it’s better to get one little thing done than to have a mountain of unfinished “good intentions” and as soon as you get one thing done, finish the next.

Now, I’m not saying do one thing at a time, but I am saying limit your work in progress such that you are completing tasks in a timely manner. As you complete tasks begin new tasks that are pending. Get into a cadence where you’re delivering value frequently. Actually getting work done makes much more business sense than trying to make yourself (or your department) look like a dragon slayer by taking on too much simultaneous work. If you’re doing everything, you’re likely getting nothing done.

Tuesday, February 16, 2010

Reduced maintenance costs pay for the overhead of TDD

Interesting study on TDD done by Microsoft (link at bottom). The study seems pretty thorough - focusing on four different projects and using control groups working in the same problem domain on similarly complex tasks.

The study shows a 15 - 35% increase in overhead at the time of coding. That could be costly. It should be pointed out that only one team saw that an increase of over 25%. The other's maintained below that. The study points out that pre-release defects were reduced between 40 and 90% (FTW) - -All the teams demonstrated a significant drop in defect density: 40% for the IBM team; 60–90% for the Microsoft teams..

"From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality (Erdogmus and Williams 2003), an observation that was backed up the product teams at Microsoft and IBM." - from the study

Pretty good defect decrease, not to mention the added maintainability garnered from the decoupling required to add good test coverage, better focus on design (as is the real goal of TDD), and the bonus of having thorough test coverage for fast regression testing.

Less technical debt at release, easier maintenance due to decoupling, assurance through existing tests that maintenance updates and bug fixes haven't affected existing functionality (introduced new bugs) adds up to a lot more budget available for creating new business capabilities instead of spending on keeping the ship floating.

"Our experiences and distilled lessons learned, all point to the fact that TDD seems to be applicable in various domains and can significantly reduce the defect density of developed
software without significant productivity reduction of the development team." - from the study

Read about it: http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf