A software engineers view on the career benefits of working Agile

  • -

A software engineers view on the career benefits of working Agile

I recently came across this excellent post on why going Agile can be a big benefit for the people on teams. We regularly see morale increase and people enjoy themselves more at work once they are over the change curve and using Agile. In his blog post, Theodore explains in detail why he thinks working Agile is better for his career. His take is insightful, some of my favorite quotes are:

“You develop strong relationships and you are able to learn so much from other people’s experiences and perspectives. Pair programming has helped me develop a better understanding of what I don’t know and an even stronger understanding of what I already know. And it’s not only other developers you develop these relationships with. As requirements change, you interact with people from marketing, product, legal, qa, project managers, designers, and the list goes on.”

“Understanding requirements is often the most difficult part of developing software. As requirements change, with constant engagement from the customer you have a better chance at meeting those requirements. The other piece of this value has to do with deadlines. Contracts are hard deadlines. In the software development, with all its moving pieces, it’s pretty silly to commit to arbitrary dates six months from today. But if you engage stakeholders into your development process, they have clear visibility into the progress of the project. You don’t have to make excuses for why the project is late. They already know what you’re working on and where you are. How does this benefit you? Well, you get to deliver software that actually meets the customer’s needs. Who’s the rock star now?”

I won’t spoil the punchline, you’ll have to read on Theodore’s blog


  • -

Agile 2008 Toronto August 4-8

Agile 2008 is coming, and we’d like to invite you to participate. Deadlines are quickly approaching for participants to submit proposals. We encourage you to document and submit your agile experiences, training ideas, practices, and how you are succeeding with Agile and Lean. We also want to hear about development practices, organizational change, and how ideas from Lean, Six Sigma, and other process improvement initiatives compliment or conflict with Agile. Agile is a small but rapidly growing community and Agile 2008 promises to be the most innovative and successful Agile conference yet.

Innovel’s David Douglas is participating in Agile 2008 as a reviewer of the French language Stage. David is submitting proposals on Agile in non-IT projects and decision making in Lean and Agile environments.

Robin Dymond is participating in Agile 2008 as an Assistant Producer of the Learning and Education Stage, and a reviewer of the Agile User Experience and usability stage with colleague Jeff Patton. Robin is submitting proposals on Product Owner training, Integrating Lean and Agile, and other topics.

We look forward to seeing you at Agile 2008!

Agile 2008 Banner


  • 2

Core Principles Lost When Microsoft Solutions Framework Meets Agile

In discussion with a client last November I learned that MSFT was proposing a new, updated version of Agile, called MSF Agile. Intrigued that I had not heard about this, I did some research, and was very surprised! I posted my findings to the Scrum Development Group, where 4500 members discuss Scrum and Agile implementation, adoption, “how to” issues, tools, etc. OK, I admit that, by design, my initial post was provocative and generated some vigorous responses. Over 150 replies were posted on this topic, many from thought leaders in the Agile community. The discussion has revealed some very interesting points of contention between those who worked for Microsoft and the Scrum and Agile community, and many real grounded concerns.

As consultants we need to deliver a business goal when helping clients adopt Agile techniques – a faster, more productive team that consistently delivers valuable benefits to the customer and the business. Helping numerous large clients adopt Scrum and Agile techniques, we face on a day to day basis the challenge of change. Agile methods have some inherently difficult to implement principles for most organizations. Some of these include self organizing around the work, deemphasizing roles – asking team members to take on tasks not in their specialization, servant leadership, elimination of big design and planning efforts up front, direct and continuous involvement of the business in the delivery process, and early then continuous delivery of business value throughout a project, to name a few.

It turns out that Microsoft did some market research, and found out that some companies are struggling with these issues, and that implementing Agile methods is hard. This is not news. Microsoft’s response to this research however cuts to the core of the issue. With MSF for Agile Microsoft chose to re-define “Agile”, by adding numerous traditional phased/waterfall practices back into the process, presumably in order to make Microsoft’s “MSF for Agile” product more saleable,. What are the impacts of these changes? I would prefer to quote Ken Schwaber’s analysis:

“[MSF for Agile] defines roles within the development team, so it isn’t cross-functional. It tells the team what to do, so it misses self-management. It defines what steps to take, so it isn’t empirical. It has increments that aren’t potentially shippable, so it isn’t lean. Lots of artifacts and no emerging list of requirements and architecture, so it is wasteful and not lean/agile.”

Removing many of the core principles that make Agile the most effective way to work isn’t the only issue. Microsoft chose to roll this process into their tools and the marketplace without independent peer review, without testing it with real teams, and with no comparative analysis on this new software development process vs. proven Agile methods such as Scrum. Should we expect better from the world’s largest software development tool vendor? Microsoft has enormous market presence, and as such has the opportunity to influence many billions of dollars of IT projects. Microsoft had the opportunity to make proven Agile methods the centerpiece of a tool suite that could help customers make the transition to much improved productivity. Instead Microsoft co-opted an important brand (Agile), but delivered a process that is missing key Agile principles and practices, and cannot provide the business value seen by teams adopting Scrum, XP, or other market tested and proven methods.

MSF for Agile: BUYER BEWARE!


  • -

The Scrum Development Mailing List

Ever had a question about scrum but you didn’t know who to ask? Ever wished you could discuss a burning issue with an author or thought leader in the Agile community? The Scrum development list is the most active forum for the Scrum community. Subscribers include authors, thought leaders, newbies, working scrum masters / agile coaches, project managers, and interested members of the agile community. Scrum Development is an Yahoo group email list. Subscribers receive emails sent to the list from other subscribers. This allows subscribers to post a topic, and reply to each other’s posts and carry on “public” conversations. The group has approximately 4,500 members, and membership is moderated, so spammers cannot access the list. The postings can also be read on the group’s website http://groups.yahoo.com/group/scrumdevelopment/. The topics on the list run the gamut, and include everything from beginner/newbie questions about how to do scrum on a first project to advanced topics on enterprise conversion, and everything in between. Authors such as Mary Poppendeick, Jeff Sutherland, Mike Cohn, and Ron Jeffries regularly contribute to discussions on the list.

Given the amount of traffic it can be hard to keep up with all of the topics. If you subscribe, scan topics quickly, and delete articles that have questionable topics. Long discussions with lots of contributors are good signs, it means that the topic is interesting to many, and
that there are some good debates/discussions in progress.


  • 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 control.net, 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

Methodology

Ad Hoc

Agile – Scrum and XP

Developers

2-8

8

QA

1

3.5

Lines of code written

125,000

245,000

Releases

1

3 releases, 10 production updates

Complexity

Low-Med

High

  • 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

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, 3isite.com, 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 Salesforce.com, 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.