Monday, November 23, 2009

Scrum: a process that enables Innovation?

One criticism that occurs most often in Scrum is that it is, once again, a software development process. This is exactly the question that I had to answer recently after an awareness session to Scrum in my company.

One of points for the resistance comes from the fact that the organization is afraid of losing its capacity for creativity and innovation.

If you've read my previous post on Lean Software Development and Scrum, one of the key feature is to fight for eliminating waste.
In my opinion, Scrum is not only a framework that implements practices encouraging waste reduction, but it is a process that encourages innovation.

Traditionally, application design is upstream of the software development cycle, which prevents, in most cases, the return of brilliant ideas during the project, or even integration.
Depending on the customer value of new and innovative ideas discovered during a sprint, they could eventually be integrated directly into the next sprint. The traditional approach can stifle innovation with cumbersome change control. Scrum allows a flexible and creative team to build the best solution for the customer.
 

2 principles to keep in mind:

  • Adapt to change
  • Innovation-value
Respond to change rather than follow a pre-established plan, taking into account the fact that the conditions and objectives of an enterprise can evolve over time, even while the project is under progress, corresponds perfectly to the vision of innovation inherent in Agile development methods, such as Scrum

In the software industry and in high technology sector, we have many examples that demonstrate Scrum does not break Innovation:

  • Google
  • Yahoo
  • Salesforce.com
In the last example, Salesforce.com has been able to introduce big changes and the plan was to do a big bang within 3 months.
The immediate result was: 
They did suddenly the shortest release cycle ever

The immediate consequences:

  • Predictability  - On Time
  • Releases - more often

Since the implementation of Agile: 
“Every agile release has been deployed on time (down to the exact minute)”

Results:
  • +94% in feature request delivered between 2006 and 2007
  • +38% of feature request delivered per developer
Now:
Business wants to slow the development down, because they  can not handle the output of the development any more. They deliver too  much.


Salesforce.com - Large scale agile transfomation

Thursday, November 19, 2009

Lean Software Development and Scrum

Last Tuesday I attended the 2009 edition of the Valtech Days.
I was able to attend 2 very interesting workshops on Lean Management and Lean Software Development, an agile methodology that has been implemented by Thales.
Several interesting points that I was interested in:

  • The first is the culture change by introducing the value for customers
  • The other principle is the elimination of waste, the objective is to implement practices for improving the efficiency of the process to add value to the customers

What is the relationship with Scrum?

Scrum defines practices that enable process improvement and waste
cutting.
How can we define the concept of waste in software development? It is any activity that absorbs resources (human, machine, etc.) without adding value to the customer.

In software edition industry, wastes most often observed are:

  • Too many features
  • Work done partiallyCommunication
  • Knowledge Transfer
  • Switching between different tasks
  • Delays
  • Defects
For me, Scrum is the ideal framework for eliminating all waste:

  • Iterative development can meet the challenges of "Work done partially"
  • TDD (Test Driven Development), Refactoring and continuous integration can eliminate the problems of "defects"
  • Backlog & sprint planning meetings, Pair-programming and one cross-functional team can eliminate the problems of "communication", "knowledge transfer", "defects" and "too many features".
  • Adding Sustainable rythm, collective responsibility of the code and the Scrum dashboard can eliminate the problems of "delays"

Monday, November 16, 2009

Valtech Days 2009

Tomorrow, I will participate to the Valtech Days 2009:
Three sessions are organized:
  • Agile methodologies
  • E-Business & Web 2.0
  • Technological Innovations

B.A.T. and courage...

For those who are familiar with XP, one of the founding values is COURAGE:
  • Courage to tell the truth.
  • Courage to implement practices every day.
  • Courage to adapt the team to changes.
  • Etc.
A few months ago, I implemented a process to improve the quality of development delivered to the testing team, the BAT (Build Acceptance Tests):
  • The BAT is generally a short set of tests, which exercises the main functionalities of the application
  • If the BAT fails, the build is rejected, and testing continues on the previous build (provided there has been at least one build that has passed the acceptance test)
Why BAT is important? What are the benefits?
  • It lets developer know right away if there is a serious problem with the build 
  • It saves the QA team to waste time and to get frustration by avoiding test of an unstable build 
  • It minimizes integration risk when the different team members combine or "integrate" the code they have been working on separately 
  • It reduces the risk of low quality 
  • It supports easier defect diagnosis on something that happened between the two builds broke the product  
  • It improves motivation

We have succeeded in defining the scope of testing with development teams to find an acceptable and accepted agreement by all the stakeholders of the product cycle. After many iterations, the BAT has revealed what we were suspecting:
  • Not enough testing practice during code phase
  • Not enough integration practice during code phase
  • Severe bugs reported during the BAT
The main consequence of the application of the BAT process was to delay the campaigns performed by testing team and finally to slip the delivery date of the product.

You will certainly ask why "Courage"?

Faced with the reality of the quality of builds, some managers want to call into question the principle of the BAT. At this moment we must have the courage to leave our comfort to face obstacles.
What is important to do is to leave a form of struggle, to be aware of the interest of good practices and finally demonstrate that over time, these practices are beneficial for all.