What you do NOT need to do in Scrum!

I often hear discussions who is doing the "traditional" project leader tasks in Scrum. This is in general an excuse to state that Scrum alone cannot work and classical project leaders are still needed. 

Below a list of tasks you do NOT need anymore to do in Scrum.

• Make commitments on behalf of the team about how much they can get done by a certain date or estimate effort for the team,
• Coerce the team that the commitments made on their behalf are attainable,
• Coerce the team to change their estimates,
• Give direction to the team on how to implement the work,
• Monitor the team's progress to make sure they stay on schedule,
• Step in and determine the solution,
• Conduct weekly status update and face to face meetings with the team to surface issues and provide direction,
• Provide motivation and push the team to work harder than they might want to using carrots and sticks,

Found a Limited Liability Company in Switzerland

I left the company I founded 20 years ago and needed a new home to work and have access to social insurances. Therefore I had to found a limited liability company with a capital of CHF 20'000.

Here the steps for the impatient.

What is an Agile Company?

Lately people often ask me what is an agile company. They have an understanding of agile software development techniques such as Scrum, Lean, Kanban, eXtreme Programming but no clue how a company could be agile. 

One way to approach this theme is to implement concepts of the above mentioned agile approaches. These are the pillars for iterative incremental improvements.

• Transparency you trust all collaborators to provide their best when working on the product. Therefore they need full access to all relevant information: quality, progress, budget, people and financial data. They use the data to select the best alternatives to reach the company’s goals
• Inspection you cherish a failure culture because inspections will find weak points. You need a culture where people are never blamed. One consequence is that you eliminate management by objectives, and bonuses in your company
• Adaptation you are ready to learn better approaches and truly believe there is a better solution. Therefore processes change regularly bottom-up, company’s budget can only be a rolling indicative budget, and planning has to be continuously updated

Agile Trends Switzerland 2013

What are the main hurdles to introduce agile approaches in Swiss companies

• Introducing agile company-wide is a cultural change process. Such a change takes time and sometimes hurts,
• Without commitment of senior management, the initiative will fail,

• Doubt that lean or agile works for big projects, doubt you can convince your collaborators and middle management, doubt your customers agree with lean,
• At the end what matters is collaborator purpose, customer satisfaction,  business value.

Agile Trends Switzerland 2012

What are the main hurdles to introduce agile approaches in Swiss companies. 

• Introducing agile company-wide is a cultural change process. Such a change takes time and sometimes hurts,
• Without commitment of senior management, the initiative will fail,

• Doubt that lean or agile works, doubt you can find agile experts, doubt that your projects can be realised with agile approaches,
• At the end what matters is collaborator purpose, customer satisfaction,  business value.

PMI-ACP Certification

I learnt quite a few new acronyms and techniques when studying for the PMI-ACP certification program. In this post I collected these acronyms, some definition and the bibliography you should know before attending the examination. The main advantage of having it is that you no more need to argue with PMI certified project managers if agile is applicable to software projects.

The main interest of PMI-ACP certification is their collection of concepts taken from Agile, eXtreme Programming, Scrum and Lean.

Git Branches for the Impatient

You are working in a small colocated development team and decided to use branches to implement new features or fix errors. Here the cookbook to create, edit, merge and delete local and remote branches in Git (version 2.x).

The new Version of the Scrum Guide

The new version of the Scrum Guide written by Ken Schwaber and Jeff Sutherland is available since July 2011. The older version was published in May 2009. I found quite interesting the precisions about the Scrum Master responsibility. I have often discussions with the customers and companies I coach about the responsibility of the Scrum Master.

• Who is responsible for the introduction of the Scrum approach in the company? Often people state that the management should spread Scrum in the company. Ken and Jeff have a clear idea who is in charge of this.
  
  
  The Scrum Master serves the organization in several ways, including:
  

  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
  
  So the Scrum Master is a main driver for the introduction of Scrum in all departments and levels in the company. He needs indeed senior management support but the Scrum Master daily job is to spread Scrum in the company.
• Who should coach the product owner to write better backlog and clarify the vision?
  
  
  The Scrum Master serves the Product Owner in several ways, including:
  

  • Finding techniques for effective Product Backlog management;
  • Clearly communicating vision, goals, and Product Backlog items to the Development Team;
  • Teaching the Development Team to create clear and concise Product Backlog items;
  • Understanding long-term product planning in an empirical environment;
  • Understanding and practicing agility; and,
  • Facilitating Scrum events as requested or needed.
  
  So the Scrum Master should also coach the product owner and support him in the long term planning, the communication of the vision and backlog management. The vision and goals of the project should always contain an overall planning frame. During the project empirical evidence will trigger revision of the milestones and product planning.
• What is the meaning of done and a piece of potentially shippable product?
  
  
  When the Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the “Definition of “Done”” for the Scrum Team and is used to assess when work is complete on the product Increment.

Development Teams deliver an Increment of product functionality every Sprint. This Increment is useable, so a Product Owner may choose to immediately release it. Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

As Scrum Teams mature, it is expected that their Definition of “Done” will expand to include more stringent criteria for higher quality.
  
  
  The Increment is the sum of all the Product Backlog items completed during a Sprint and all previous Sprints. At the end of a Sprint, the new Increment must be ““Done””, which means it must be in useable condition and meet the Scrum Team’s Definition of “Done”.

It must be in useable condition regardless of whether the Product Owner decides to actually release it.
  
  So at the end of sprint all stories realized since the start of the project must be correct. Therefore you need automated acceptance tests to guaranty their correctness. The Scrum team must guaranty that at the end of each sprint all functions of the product work as specified and accepted by the product owner in the current and previous sprint reviews.
  
  Higher quality is reached through extreme programming approach: test driven development, clean code, pair programming, pair check-in, coding dojo, static analysis tools.
• Does Scrum consider long-term planning?
  
  Yes it is a major activity performed by the Scrum Master and Product Owner. See the above point about the Scrum Master coaching the Product Owner. See if anyone states that long-term planning is not part of the Scrum theory you should challenge them and give them the Scrum Guide to read.
• What can be changed during a Sprint? Often customers have heated discussions what can be changed during a sprint. Here a clear statement.
  
  
  During the Sprint:
  

  • No changes are made that would affect the Sprint Goal;
  • Development Team composition and quality goals remain constant; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
• What is measured in a burn down chart?
  
  
  Scrum does not consider the time spent working on Sprint Backlog Items. The work remaining and date are the only variables of interest.
  
  The only relevant information is the amount of work still open and when this work will be completed. This is true for sprint, release and whole backlog burn-down chart.

I am glad that these precisions were added to the new version of the Scrum guide. I simplify my daily work. I can now simply refer the official Scrum Guide to convince people how aspects of Scrum should be understood.
The older version of the Scrum Guide is still relevant because it contains hints and best practices no more part of the new version.

Scrum Master is a full-time Role

I am very happy we discuss in depth the role, responsibilities and activities of a good Scrum Master. And I fully agree with Scrum advocates that Scrum Master is a dedicated full-time job. 

I am also convinced a Scrum Master can support multiple experienced Scrum teams. The Large Scale Scrum framework LeSS states a full-time Scrum Master supports 1 to 3 teams. 

Books for Persons interested in Agile Approaches

Often I am told that it is difficult to use Agile/Scrum approaches for brown field projects or for big projects or for distributed projects or for in other situations. 

Interestingly these persons also state that the same problem exist for RUP/OpenUP, Waterfall model DIN XT, Swiss variant called Hermes. 

Currently agile approaches are the standard for new projects and are thought in technical universities. 

Scrum is the main agile method and state of the industry approach for the implementation of software projects.

To open the discussion and bring the discussion back to objective arguments I often recommend the following books

Why I use a MacBookPro and OS X

As a young developer I loved Linux, compiled new kernels during evening sessions and struggled days to have the correct drivers for the graphic card and communication components of my notebook.

I grew older and decided to enjoy my evenings and weekends. And surely I would prefer to have no virus, trojan and other evils on my workstation. So I went to MacOS and Apple notebooks without regrets.

Do Agile Methods - Scrum - Motivate your Team?

Well my current experience is that the answer is a sounding YES. 

Developers love to develop software using Scrum. The motivation and positive energy just explodes. People talk together, build as a team better products and enjoy the daily activities.

Stakeholders and in particular customers or users embraces the advantages they get.

Still a whisper can be heard that yes is not without consequences for the organization. 

Minimizing Undone Work when Working with Regulatory Departments

The Scrum and agile mantra is to have a "ready to ship" product each time a sprint is completed. You must avoid any incomplete activities at any price. 

Incomplete activities are also called Undone Work; they are technical debts in your software, hindering its delivery to customers.

 

Regulatory and traditional quality insurance departments requests all kinds of documents such as review, test results, risk analysis matrix to insure that their view of quality is fulfilled.

 

Scrum sees quality similar to the lean production approach. Quality is build into the product and you do not need any documents proving you have fulfilled this goal. Your sole goal is to optimize the process to produce best products, not to repair them after production.