buy paxil

Adopt Agile for Double Productivity, Happier People.

  • 1

Adopt Agile for Double Productivity, Happier People.

In adopting Agile methods, software development teams regularly double their productivity while increasing quality, customer satisfaction and morale. This article discusses my first application of Agile methods with a 15 person software team, and the benefits we achieved. – Robin Dymond.

I never really thought about productivity improvement the first time I used Agile methods. I was more concerned with helping the business get it’s product out the door. The team had been running for a year, had produced 125,000 lines of code, nothing could be released, and investors were nervous the startup was never going to get to market. I was hired in the fall of 2002 to turn the project around and get the product to market. Startups are often run by people who tend to be young and charismatic but not necessarily experienced. The challenge of getting the product to market was pretty straight forward – stop building buggy new features, and let’s get what we’ve got hardened (thoroughly tested and debugged), and into the hands of sales. Once this was done, the dilemma arose: Do we adopt a traditional waterfall process? We had a meeting with a large potential first client – they wanted some very different features from what we had so far, and were willing to fund that development. The week before we’d had a similar meeting with a different customer and a different set of change requests. Since I had just spent 2 years as the founder and CEO of a startup, I could completely sympathize with the business predicament. The company needed a large anchor customer, and the team had to be able to meet their needs as soon as they arrived. However the team could not wait for the customer to appear when there were so many additional features we could add.

We made the decision to put out a release every month, and not do “big” features that would prevent us from releasing for a few months. This would give sales time to land that big first customer and still keep the team busy and productive. However frequent releases would require a lot more builds, which were time consuming and kept Dave the dba away from doing database development. To solve the build issues we decommissioned Visual Source Safe and migrated to Borland (Starbase) Starteam. On advice from colleagues at Thoughtworks Canada (Servidium Inc.) we installed Cruise, a first outside of Thoughtworks at the time. Cruise control is a fantastic build automation tool. This productivity tool freed up Dave and gave everyone visibility into the health of the code base and builds.

Because we were releasing every month, we needed a better way to stay in sync as a team. The weekly developer meetings were stale and didn’t meet our needs, so we tried the daily morning stand up meeting. At first it was uncomfortable. I was trying to build a sense of self reliance in the team, and suddenly we had everyone telling me what they had done yesterday and planned to do today. So I asked the lead developer to run the meetings, and participated by giving updates on my day in the same way. The uncomfortable feeling quickly passed for everyone as we emphasized this was synchronization for the work and not a report out to management. The team grew to appreciate the transparency the stand up meeting gave into each other’s work, and so the team kept it.

Around the time we were trying out stand ups, Johnathan Rassmusson, a senior consultant at Thoughtworks told me about Scrum. It had a lot of the characteristics of what we were doing, but provided more formality around the customer interaction, prioritization, and cadence. I really liked what I found in Ken Schwaber’s book, it met all of my criteria for this team, project, and business case, so we adopted Scrum and began to get our requirements into a product backlog, with the CEO taking the customer role and the Product Manager/UI Designer becoming the Product Owner, while I, the VP Technology took the role of Scrum Master. When we met for our first product backlog session, the CEO’s priorities were A, A+, A++, A+++, A++++, and A+++++ and it was all needed immediately. We promised to work on the A priority items with 4 and 5 plusses first, and show them in one month. I think the CEO looked at me like I had tricked him into giving a priority. However 3 months and 2 releases later, with the team developing and releasing at a steady cadence, the CEO would readily negotiate on scope to get another release out, and the business team as a whole became much more engaged with the market and potential customers to determine the best priorities for new features.

We also started learning about and implementing test driven development. This was eye opening for the team. Microsoft’s recommendations (at the time) were to put business logic in stored procedures for application speed/response time and to use the ASP web controls to speed up UI development. Following these recommendations meant much of the application had only 2 tiers, and no easy way to write unit tests around small pieces of business logic. In this scenario unit tests required a test database with known (golden) data so stored procedures could be checked. For unit testing logic in the UI, session state, javascript, and other browser dependent variables were needed, making unit testing difficult and brittle.

As we continued to work on improvements to our development environment and our techniques, we embraced refactoring and the first C# refactoring plugin for visual studio. The team also began learning about patterns, and as more complex problems came up the team more frequently turned to patterns for solutions that had been proven, could be implemented in the business logic layer, were unit test friendly, and provided a path away from the 2 tier architecture that had grown in the first year of development.

The development team went from not delivering to delvering more than the sales team could sell. In the end the company’s investor’s drastically decreased funding, the business shrank, and many of us moved on. For many of us the experience was very valuable. For me, I had found a way to work that could meet the needs of fast moving businesses in competitive environments, removes the death march mentality endemic in IT, and provide an environment where transparency, safety, learning and continuous improvement are the norm.

We looked back at the 2 years and made some startling discoveries:

What Changed

Year 1

Year 2


Ad Hoc

Agile – Scrum and XP







Lines of code written





3 releases, 10 production updates




  • There was a dramatic increase in quality – from 1 buggy release to 13 production releases.
  • There was a 96% improvement in productivity based only on lines of code. While lines is often not the best metric, in combination with the above fact it shows a startling improvement.
  • A deathly quiet project room occasionally punctuated by teasing/sarcasm to a hive of collaborative activity that included laughter, engaging conversations, and of course an occasional 1 week crunch to get a big release out.

The improved results were driven by focusing on continuously improving our Agile implementation, making architecture changes to support Agile engineering practices, and experience gained with C# and .NET. All of these changes required a focus on learning, providing time for change, and creating a discipline of experimentation, of test and learn. As a leader my success is defined by how well I can help others succeed. With this turn around we had very few personnel changes, yet the success of the people was dramatically different. It is critical that leadership in the twenty first century realize that the systems and organizations in which we work can define our ultimate success or failure. Agile and Lean are two systems that help people succeed, and as such unleash far more productivity than ever envisioned. This is why I am making a career out of helping businesses adopt Lean and Agile.

For more information see the MSDN presentation on Agile and .NET in our articles section.

  • -

Growing an Agile Coach Community

The Growth of an Agile Coach Community
Adopting Agile takes courage, perseverance, and continued reinforcement. The growth of an Agile Coach community can add sustainability to your Agile adoption. Read an Experience Report from the Agile2007 conference about this very topic.

  • -

Four Weeks

Tags : 

Zara ModelThink delivering working software every 30 days is difficult? Got an idea for a great new outfit? How long would it take to see that idea become a piece of clothing available in 1000 stores? As we look to improve our businesses’ ability to respond quickly to its customer needs, its helpful to look at other businesses that have used speed to generate huge advantages and gain marketshare from much larger rivals. An unlikely place to look is fashion retailing.

When Madonna gave a series of concerts in Spain, teenage girls were wearing at her last performance the outfit she wore for her first concert. When Spain’s Crown Prince Felipe and Letizia Ortiz Rocasolano announced their engagement in 2003, the bride-to-be wore a stylish white pant suit. Within a few weeks, hundreds of European women were wearing something similar. All thanks to Zara, the pioneer of fast fashion. In April 2006, the company owned by the Inditex Group, took the lead in fast fashion apparel away from giant Swedish retailer, Hennes & Mauritz (H&M) by posting $8.15 billion in sales in 2005, compared to H&M’s $7.87 billion.

Zara Tokyo store

How can Inditex thrive when Europe’s entire textile industry is under threat from cheap imports from China? After all, labor costs in Europe are 17-20 times higher than in Asia. In a word – speed. It takes Zara four weeks to go from identified consumer need and fashion concept to clothes in its stores. Most of Zara’s inventory is sourced through this fast channel. To enable this speed Zara owns the complete supply chain, from manufacturing through distribution and retail. Some 300 designers work at the firm’s head office in La Coruña in Galicia in northern Spain, producing 1000 new styles per month. They are in daily contact with store managers to discover bestselling items. The remaining inventory is sourced through low cost off shore manufacturers, similar to other retailers.

Zara’s fast products are deliberately created in small batches to avoid oversupply. Most lines are replaced quickly with yet more new designs rather than with more of the same. This in turn generates scarcity of supply. Shoppers cannot be sure that something that has caught their eye will appear in the store again—or can be found at another Zara store, even in the same city. A higher average selling price is maintained.

Zara’s production cycles are much faster than those of its nearest rival, Sweden’s Hennes & Mauritz (H&M). While an entirely new Zara garment takes about four to five weeks from design to delivery; a new version of an existing model can be in the shops within two weeks. This process takes six to twelve months for an average retailer. In a typical year, Zara launches some 11,000 new items, compared with the 2,000-4,000 from companies like H&M or America’s giant casual-fashion chain, Gap.

Text box - reacting quickly Don’t try to predict, react.
The fast production chain at Zara removes a significant amount of risk that comes with fashion forecasting. So Zara finds itself in the “blessed” position of not really having to take a bet on fashion as much as follow it. A 2004 Bain & Co. study found that fast-fashion outlets in Spain and Britain posted average double-digit sales growth, compared with 4% growth in overall retail sales in those countries.

Zara Open Concept Work Space

Zara’s design work space is open concept and highly collaborative.

Fashion trend identification is a daily constant effort. All of Zara’s shops use point-of-sale terminals to report directly to La Coruña. On top of that, every evening store managers consult a personal digital assistant to check what new designs are available and to place their orders according to what they think will sell best to their customers. In this way, its store managers help shape designs. Zara does not employ star designers but often unknowns, many of whom are recruited directly from top design schools. Inditex is extremely clever in how it uses technology, says Andrew McAfee, a Harvard Business School specialist in the corporate use of information technology. The company keeps its technology simple—even a little old-fashioned—but as a result spends five to ten times less on information technology than its rivals.

Zara Toronto store Zara is also more parsimonious with advertising and discounts. It spends just 0.3% of sales on ads, compared with the 3-4% typically spent by rivals. “We try to avoid markdowns” says JM Castellano, Inditex’s deputy chairman. For many retailers 35-40 percent of total merchandise is sold at hefty discounts. “This business is all about reducing response time” says Castellano. “In fashion, stock is like food, it goes bad quick.”

    This article contains material from various internet business news sources including The Economist,, AMR Research, and others.

  • 1

The “W” Campaign

The “W” Campaign

Take a look at the cards on your team’s board. Which tasks your team does in this iteration actually add value for your Product Owner? How many are done to meet regulatory or end customer needs? How many are done that don’t add value to the customer? How many of the tasks are repetitious and manual? What tasks have artificial delays built into them?

We know there are many tasks in every team that are non value add. That’s why we are starting the W Campaign. We are asking teams, your teams, to identify waste (non value add activities) in the software development process, and help enable the company to remove it. So if you have a task on the board that is waste, grab a red marker, and write a red W on it. After your team has reviewed your board and put red W’s on the waste, invite your product owner, and team’s stakeholders to discuss the waste. Ask management to remove it, politely, but insistently. Removing waste and continually improving processes are highly effective value add activities managers are uniquely positioned to do. Teams go faster when waste is removed. Team members are happier when they can focus on adding value. Below are some ideas for recognizing the seven forms of waste in your software development process. If you are not sure it is waste, discuss it with your team members or product owner.

The seven wastes of software development1

Partially done work – Partially done development ties up resources in investment that has yet to yield a result. Minimizing work in process is a risk reduction as well as a waste reduction strategy.

Extra processes – Did you ever ask, is all that paperwork necessary? Do three groups really add value reviewing that report? A good test of the value of paperwork is to see if there is someone waiting to use what will be produced to add additional customer value. There should be a constant search for the most efficient, effective means to transmit the information.

Extra features – It may seem like a good idea to put some extra features into a system “just in case” however this is a serious addition of waste. Every bit of code in the system has to be tracked, compiled, integrated, and tested every time the system is changed. It increases complexity and is a potential failure point. It may become obsolete before its used, and may be removed or changed before it is ever used.

Task switching – Assigning people to multiple projects or teams is a source of waste. Every time a person switches between projects, there is significant loss of productive time as they get into the flow of the other work. The fastest time to complete projects is to do them one at a time.

Waiting – One of the biggest wastes in software development is usually waiting for things to happen. Delays in starting, staffing and onboarding, reviews and approvals, testing, and deployment are waste. When critical customer need, like a defect arrives in you’re your organization, the speed at which you can respond is directly related to the systemic delays in your development cycle.

MotionWhen a tester or analyst asks a question, how much motion does it take to find out the answer? Each hand off of artifacts: code, documentation, tests, etc. between team members is full of waste. Moving artifacts from one team or project to another is a huge source of waste. The waste is that handoffs and their artifacts don’t, and can’t contain all of the information a person needs to know. Documents are low bandwidth, and require lots of interpretation, which takes time and generates assumptions and errors. Face to face communication is high bandwidth, the interaction allows assumptions to be checked and greatly reduces the amount of interpretation required.

Defects – The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected. The way to reduce the impact of defects is to find them as soon as they occur. To reduce defect waste, the team must test immediately, integrate often, and release to production as soon as possible.


Learning to see waste is an ongoing process of changing the way you think about what is really necessary.

1. Lean software development, Tom and Mary Poppendieck, pp. 4-8.

  • 1

APLN Leadership Summit on “Leading Agile Adoption” a Success!

Leading Agile Adoption – what does it take to transform an organization to a completely new and very different way of working? This was the theme for the first stand alone National APLN Leadership Summit in Richmond on October 18th, 2007. The full day event brought together leaders from companies such as, Wachovia, Genworth, PPH, Headwaters, BMC Software, and many others. Along with my fellow event Committee members, I feel the event was very successful, and I invite everyone engaged in adopting Lean and Agile in their organization to attend future summit events.

If you are building new business capabilities, how do you determine where to invest? Give a list of 1000 requirements, which are most important, and which should you be buying and NOT building? This was the subject of the keynote by Niel Nickolaisen, CIO and Director of Strategic Planning, Headwaters, Inc. Neil’s take on strategy is that it should define the lens by which you can quickly decide what is critical to your customers. Niel demonstrated a model that the audience could take a use to make value judgments on features, or even a project portfolio. A number of audience members were applying the model at the conference on their current projects, and making some very interesting findings. It is not often that you can apply the ideas in a talk immediately, but, like many people in the Agile community, Niel is looking to spread his innovations and raise the level of the game Agile companies bring to the table. In discussions with Niel, we compared his model with the Hedgehog concept, a model from Jim Collins’ book Good to Great. The two tools are complementary in that the Hedgehog concept helps better define what is differentiating in your business, while Niel’s model helps define what strategy should be taken with the other non-differentiating projects and work. More information on Niel’s model is available in his presentation, which will be available in the next couple weeks. The Innovel Product Owner course will benefit from Niel’s ideas, as we see them as a great addition to the Product Owner’s toolkit.

Israel Gat is a Vice President at BMC Software, where, after 3 years into the Agile adoption journey, they now feel their teams are starting to really get how to be Agile. It is no surprise for us that 3 years into it they still are learning. The continuous improvement, the application of lean, and the changes the test driven development and automation bring to a software company fundamentally change how people work. This change takes time to implement, and in turn requires cascading changes throughout the organization. The talk focussed on these cascading changes, and how the teams at BMC Software are outpacing the ability of the Marketing and Sales department to do their traditional campaigns for these new capabilities. As often happens, the first reaction at BMC was to ask the 500+ person development organization to “Slow Down!” This often is how people react when Agile and speed starts to fundamentally alter a company’s structure. In BMC’s case, they rejected the call to slow down and started thinking hard about the competitive advantage this new speed could give them. BMC is applying speed to allow them to create custom version of their products for strategic customers, allowing an unheard of level of service in their market. The really clever thing is that BMC is bypassing the Sales and Marketing department, realizing that speed can allow them to deliver new custom differentiated features directly to the customer without the need to invest in marketing these capabilities to whole market. The challenge we see for BMC is that, as Toyota first found a way to use one assembly line for many different types of cars, BMC will need to ruthlessly tackle complexity. Supporting many customers with different custom tailored features must not undo the speed advantage they have created with their Agile delivery system.

  • -

Agile 2007 Day 1

Today we offered the first public class of our Product Owner Training as a tutorial at Agile 2007. We had 40 people in the 3.5 hour tutorial that was presented by Mark Pushinsky and myself. The session was very well received by the participants, who had a high level of engagement with the exercises and material. The Product Owner Framework developed by Dymond and Pushinsky is based in part on Jim Collins’ fantastic book Good to Great. The Hedge Hog Principle, a foundation for all of the Good to Great companies drives clarity of purpose throughout the business. It gives a single economic metric with which to measure decisions and investment. The business case study includes determining the Hedgehog concept for this business, and using this information to influence the backlog creation process. This innovation, combined with a product owner framework that transitions the business case to a flexible product backlog and release plan allows participants to really get a feel for the decisions that will need to make as Product owners. With less that 40 slides, most of the time is spent working in groups and learning from the hands on exercises. As instructors we try to keep a class engaged with both the material and their colleagues, both within their group and outside of it. The strategy seems to work as their is a clear emotional engagement by the end of the session. We plan to offer this training with additional valuable material in the future, please let us know if you are interested in this training for your customer team. You can find an earlier version of the session materials on the Agile 2007 web site.

  • 1

Why Agile and Lean? Why Change?

Many IT centric business executives are starting to hear about Agile, and wonder if it is something they should implement. A key to adopting Lean and Agile is having a clear and pressing issue to motivate people to change. We like to refer to this as “the burning platform.” In most organizations people become comfortable. Comfortable with there position, comfortable with their role, and even with their cubicle. Agile changes all that. It makes people uncomfortable. At least initially, then, most start to really like this new way of working. However the burning platform is the energy source that drives the motivation for people to put up with their discomfort, to suppress their resistance to change. What is your burning platform? Why will you adopt Agile?

  • -

Accelerating Your Business

Tags : 

 In the face of increasing cost pressure, fast moving competitors and faster moving markets, how can your business thrive? Innovel helps large scale enterprises develop sustained competitive advantage. Our goal is to give your people and organization the tools needed for sustained innovation and market advantage for the long term.

Our clients have experienced the following benefits:

  • 80% reduction in time to market for new capabilities on a complex IT Platform
  • A critical business operations process reduced from 70 to 10 days
  • Employee surveys that show significant improvement in morale
  • “This has changed the way we do work” – Senior Executive

Let us show you a truly different way to organize and deliver value to your customers with unprecedented speed.

seroquel without perscription canadian