Crystal Methodologies - Common properties

Hope you got to know: what is crystal family of methodologies from previous post. In this post, let’s discuss about Crystal Methodologies – Commonality .i.e.nothing but properties common among all crystal family members.

These are the common properties (given below) among different methods of crystal famiy.

1.  Frequent delivery

2.  Reflective improvement

3.  Osmotic communication

4.  Personal safety

5.  Focus

6.  Easy access to expert users

7. Technical environment (With Automation testing, configuration management and frequent integration)

Out of the above, first three properties are core properties of crystal and rest are the properties which increases project safety by dealing with adverse conditions. Let’s discuss one by one in more detail.

Crystal Family members - Common Properties

Frequent delivery: 

Deliver usable software atleast once a quarter (Delivery cycle can vary from a week to a Quarter).

Crystal suggests to deliver usable software atleast once a quarter. Delivered software must be running, tested with usable functions. Delivery cycle shouldn’t be more than four months, so that problems/issues can be found and fixed early. Customers/Stakeholders can provide feedback on the working software which helps team to tailor things with respect to people/process/product.

Reflective improvement: Inspect and Improve

All team members get together atleast once in a quarter to discuss about ‘what is working good’, ‘what is not working good’ (Factors slowing down team’s work) and ‘is there any improvements/modifications to be done?’. This is called reflection workshop. Short iterations help teams to evaluate the process they are following.

Osmotic communication:

All team members working for a project to be seated in same room/same building (Co-location), which helps in effective communication and quick information flow through the team. The main objective behind all team members getting seated in the same room is that: team members can overhear the discussions happening in background (though they are not directly involved in) and pick up relevant information. Through this, Communication overhead is reduced and  it takes less time to get the answers for your questions.

Personal safety:

Team members must be able to speak to team without any hesitation/inhibitions. Members should be able to discuss with the team about anything. For example: wrong estimations, friendly disagreements etc. Main objective behind this property is creating an environment where team members can share their views without thinking about what others think about their views.

Focus:

Goals of the project is well defined and all team members should know their top two priority items/tasks to work on. Members should get at least two days in a row with two hours each day to work with out any interruptions. This will increase focus on a item/task long enough for progress towards project goal.

Easy access to expert users:

Team members should work with experts to get their questions answered. Experts/End-users would suggest improvements or solutions. Experts should be available to team (either by person or reachable by phone), so that team get answers to their questions in few hours.

Technical environment (With Automation testing, configuration management and frequent integration):

Developers need to check their code into configuration management system and run automated system tests to identify errors/problems with the changes being made. It should be done regularly to identify erros/problems early and fix it.

In this post, We have discussed about common properties among all crystal family members. Will discuss about crystal-process in next post.

Thank you for visiting my blog and spending some time. It would be great, if you could share your feedback as it helps me to improve. If you have any suggestions OR queries, Please feel free to reach out to me @ Linkedin Facebook

Linkedin: http://in.linkedin.com/in/sathrambalaji

Facebook: https://www.facebook.com/sathrambalaji

Twitter: @sathrambalaji

-Balaji Sathram

Crystal - It is about Self-awareness

Hi all, Thank you for coming back and reading my blog. I know that it’s been couple of months since my last post. My apologies for that. I was in to job trials, facing some health issues but finally could come out of it. Joined new organisation, completed all medical tests and………  back to blogging with more energy. Let’s get into our subject. In earlier post, we have discussed about kanban. Let’s discuss about Crystal methodology in this post.

Crystal is introduced by Alistair Cockburn as a family of methodologies in 1998. He says that, he developed crystal methodologies to get rid of software engineering which always questions as "Is our model accurate?". Think about "Is our product meeting the customer's needs?" and "Do we have our goals aligned as a team?", which gives you better product leading to customer satisfaction. Crystal Methods focuses on communication, with special focus on interaction, community, people and skills.

Picture: Alistair Cockburn

In Cockburn’s words, “Crystal is a family of human-powered, adaptive, ultra light and stretch-to-fit methodologies sharing a common genetic code.”

It is mainly developed based on two important things i.e. 

1) teams can streamline their process as they start working 

2) Each project is unique and dynamic which requires unique methods designed for it.

The Crystal Family:

Though it has started in 1998, New members of the family were defined in 2001 and 2004. Based on the belief that each project is unique and it may require a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics. It requires unique methodology designed for it. Crystal methodologies are categorized according to the project size (number of people of involved in the project) that they address and the criticality of the project.

Let’s discuss these factors in detail below

1) Criticality: "Criticality" is defined by the sentence "A defect in the delivered product could cause loss of "

Comfort (C)

Discretionary Money (D)

Essential Money (E)

Life (L)

                                 For example:

Loss of comfort & Loss of Life are self-explanatory

Loss of Discretionary Money (e.g.System errors which have manual fix)

Loss of Essential Money (e.g.System errors which causes bankruptcy)

2) Project size: number of people working the project. For example, L40 project is a project which involves up to 40 people developing a life-critical system. Based on the people working/getting involved in the project decides it’s size.

Crystal methodologies: 

Based on the above listed factors crystal methodologies have been grouped in to different groups. It uses different colours to denote the “weight” of the methodology. Darker the colour, heavier the methodology. Crystal methodologies named in the literature are

Crystal Clear

Crystal Yellow

Crystal Orange

Crystal Orange Web

Crystal Red

Crystal Maroon

Crystal Blue

and Crystal Violet

Out of the above crystal methodologies, The methodologies which were practically used in real projects have been defined

Crystal Orange: Introduced in 1998, targeting C40, D40 and E40 projects.

Crystal Orange Web: Introduced in 2001, targeting web development projects.

                             Crystal Clear: Introduced in 2004, targeting C6 and D6 projects.

Picture: Crystal Methodologies-Aerial View

Crystal Methodologies - Commonality:

There are some common properties (given below) between different methods of crystal famiy.

1.    Frequent delivery

2.    Reflective improvement

3.    Close or osmotic communication

4.    Personal safety

5.    Focus

6.    Easy access to expert users

7.    Automation testing, configuration management and frequent integration

Let’s discuss about these commonalities and Crystal clear-process in next post. Would like to conclude this post with some short, meaningful sentences by Alistair Cockburn. He came up with these from his discussion with participants

Scrum is about self-organization

XP is about self-discipline

Crystal is about self-awareness

Your feedback is important to me; Help me to improve by giving your feedback. I appreciate it very much! Please feel free to reach out to me @ Linkedin Facebook

Linkedin: http://in.linkedin.com/in/sathrambalaji

Facebook: https://www.facebook.com/sathrambalaji

Twitter: @sathrambalaji

-Balaji Sathram

Kanban

In previous posts, we have discussed about scrum, lean software development system. Let us discuss about KANBAN in this post.

Roots of KANBAN:

The word Kanban is a Japanese word meaning “Kan” means “card” whereas “ban” means “signal”. This card signalling concept is used to prompt “action”. For information on the origins of the term KANBAN, please check this link

Kanban concept is related to TPS (Toyota Production System) lean manufacturing and Just-In-Time (JIT) production.

JIT means making only

What is needed,

When it is needed,

And the amount needed.

By following JIT plan, process eliminates waste, inconsistencies and work on un-necessary requirements resulting in productivity improvement.

History of KANBAN:

Late 1940’s: Taiichi Ohno (a former Toyota vice president) developed a “kanban” system to implement a “just-in-time” process. Ohno described the concept as follows: “It should be possible to organize the flow of materials in production, according to the principle of a supermarket; the consumer takes a certain amount of off the shelf product, and noticed the gap is immediately replenished”.

The kanban system is also called as "Supermarket method" as the idea behind it was borrowed from supermarkets.

Kanban today is because of Ohno, TPS and other influencers. Out of other influencers William Edwards Deming and Eliyahu Moshe Goldratt has done extensive work which has guided Kanban change agents worldwide

2004: The first kanban software implementation with Goldratt’s influence. His Theory of Constraints was successfully applied in this

2006-2007: There has been lot of research after the first Kanban software implementation. In this period Donald Reinertsen has influenced Kanban implementation. He had been researching about product development flow from many years before. This work has been continued by Peter Drucker

David J.Anderson wrote a book titled “Lessons in Agile Management”. Hw wrote about many topics in this book .i.e. Leadership, Management, Peter Drucker, Theory of Constraints and Eli Goldratt, W. Edwards Deming, Human Resource Departments and Policies, Agile, Lean and Leading Change Initiatives.

Post 2007: Through continuous improvements, the kanban method has evolved and it’s been applied in variety of fields. the Cynefin framework developed by  Dave Snowden and the research on behavioural economics by Daniel Kahneman answered many of the questions on applicability of Kanban in different contexts.

Now, we know how Kanban has evolved. Let us discuss more about Kanban with respect to software development.

KANBAN in Software Development:
Kanban is one of the agile methodologies which manages creation of software products and emphasizes on continuous delivery without overburdening any of the team members. Kanban uses work-in-progress (WIP) limited pull system as its main focus is to uncover process problems and improve it.

In Kanban, the tasks are represented by cards (Post-It Notes) which are pasted on a board called Kanban board. These cards are grouped based on their status in the flow i.e. To Do, Doing/In Progress and Done. Kanban board gives information about team’s activities, their status and next activities for the team. This helps in reducing dependency and make the team self-directing.

Out of agile methodologies scrum is simple and Kanban is simpler, it helps teams to work together more effectively. Kanban has 3 basic principles and 5 core practices

Kanban Principles:

1.       Start with What you know

2.       Agree to pursue incremental, evolutionary change

3.       Initially respect current process, roles, responsibilities and job titles

Kanban Core practices:

1.       Visualize

2.       Limiting work in progress (WIP)

3.       Manage flow

4.       Make management policies

5.       Improve collaboratively using ‘Safe to fail’ experiments

Let’s discuss these principles and core practices one by one.

Principles of Kanban

Start with what you know:

Kanban doesn’t prescribe certain setup to start with. Go with the process your team is following and evolve your current process. It makes Kanban implementation easy as you do not have to make more changes to current process. Kanban properties can be placed on top of your current process to make team self-directing over time.

Agree to pursue incremental, evolutionary change:

Don’t try to get change in process over night. If you do it, it will fail because of increased resistance from team/team members due to fear of uncertainty. Start to change the current process with baby steps. A slow, incremental and evolutionary approach is the right way to implement Kanban initiative. In David J. Anderson’s words it is called as “baby steps to awesomeness!”

Initially respect current process, roles, responsibilities and job titles:

Kanban values the value in existing process, roles, responsibilities and titles which in turn gains broader support for Kanban initiative. Every process has something worth preserving, preserve those elements which are working good for the team and respect them. Focus more on elements which are not creating value in the flow. Kanban neither stops the change nor prescribes the change. Even if you do some changes to the existing process, Kanban encourages incremental change as it creates less fear to team members when compared with other implementations which sweeps in changes overnight

Core practices of Kanban

Visualize: Visualizing the workflow

Understand the end to end workflow to optimize any step of the workflow. For example: In software development process, end to end is from requirement collection to shippable product increment. Main objective of the Kanban is to make positive changes in the system leading to workflow optimization. It is possible only after understanding how each step in the workflow functions.

The common way of visualizing workflow is through Kanban board with cards and columns. Each column in the board represents one step in the workflow. Keep your focus on incoming work which will give you more ideas on executing the same work in different workflows. There is no one specific right workflow to execute one task.

Never ever try to implement changes without understanding the end to end workflow as it is useless to the system and harmful too.

Limiting work in progress (WIP):

Limiting WIP is nothing but identifying the critical elements/steps which are in progress in the workflow and limiting it to some number based on past performance. In other words, the number of work items can be in each stage of the workflow at a given time. New work is pulled only when there is available capacity within the decided WIP limit.

Limiting WIP indicates that we have implemented pull system through out the workflow. For example in below picture, analysis can be done only for 3 tasks maximum. You will take another task for analysis only after moving one task for development.

If any of the stage is blocked, it holds up the entire workflow. WIP limiting identifies problem areas in the workflow quickly, thus team can work collaboratively and resolve them leads to faster completion and great focus. Limiting WIP and pull system of tasks are highlights of Kanban. 

Manage flow:

Always remember, implementing new process is a journey. It takes time to see the results. Main objective behind implementing Kanban is to bring positive change in the workflow. You need to have knowledge on value flow through out the workflow to identify where value is getting hindered and implement the change for fast, smooth value flow. After implementing the change, review the impact of the implementation whether it has created positive or negative effect on the workflow. Keep going, take feedback continuously and improve. 

Make Management Policies:

No body can improve something which they don’t understand. The process which you are following needs to be defined and published to leadership & team very clearly and concisely. You need to make policy makers understand how things work and how the work is actually done by using this process. Without this understanding any discussion of problems might tend to emotional, unreliable and subjective.

When everybody in the discussion understands what you are doing and your goals, then you can make change decisions which will move team in positive direction. The choices now will be more balanced, practical and to the point. Good understanding facilitates consensus around improvements/changes.

Improve collaboratively using ‘Safe to fail’ experiments: (using models/scientific method)

It is the WIP limit which exposes problems early and encourages discussions around solving them. After discussions, team has many options i.e. Break the WIP limit, ignore the problem and continue work, face up the issue, suggest a change or solution. Team needs common understanding of the workflow to choose the right option.

When all team members are in same pace with respect to understanding of the work, workflow, risks and process, then they understand problem in more or less similar manner and reach consensus in suggesting improvement actions.

You might have heard about the word Kaizen while reading about Kanban. Kaizen is a Japanese word meaning "improvement" or "change for the best” refers to practices that focus upon continuous improvement of process. Kaizen is key part of Kanban. The Kanban method suggests using scientific approach to implement continuous, incremental and evolutionary changes.

Scientific approach is nothing but predicting the outcome using a model and comparing actual and predicted results. Scientific approach always provides learning at individual and organization level. There are some existing models which can be used for these

1.    The Theory of Constraints (the study of bottlenecks)
2.    The System of Profound Knowledge (a study of variation and how it affects processes)
3.    Lean Economic Model (based on the concepts of “waste” ; discussed in Lean post)

Irrespective of the models you use, team needs to have regular feedback loops, where you get feedback and measure pros and cons of process changes. Feedback can be anything which gives input on how your process is performing. Keep improving and performing…

With this we came to conclusion of our discussion of Kanban principles and core practices. There is major difference between ‘doing agile’ and ‘being agile’. Always be in ‘Being agile’, get started

Hope you got an idea of Kanban, Kanban – Principles and Kanban – Core practices. Thank you for stopping by and reading my blog, it means a lot to me. Help me to improve by giving your feedback. I appreciate it very much! Please feel free to reach out to me

Linkedin: http://in.linkedin.com/in/sathrambalaji

Facebook: https://www.facebook.com/sathrambalaji

-Balaji Sathram

Lean Software Development: Values and Principles

Hi Folks, I know it’s been more than a month from my earlier post. I had been busy with my certification preparations, apologies for not maintaining constant pace. Till I start writing this post, I was thinking Lean as one of the agile methodologies but it is not. It is beyond that. It can be part of any agile methodology by providing its values, principles and practices to implement to eliminate waste & improve efficiency. In this post let’s discuss about Lean History, Lean’s connection with agile, Lean values, Lean principles and Lean practices. Let’s get started with Lean history

Lean – History:

1988: The term “Lean” was first coined by John Krafcik in his article, "Triumph of the Lean Production System," based on his master's thesis at the MIT Sloan School of Management. Krafcik was working as a quality engineer in a joint venture in California by the Toyota, GM (General motors) and NUMMI (New United Motor Manufacturing, Inc.) 

1991: Word “Lean” was mentioned in the book “The Machine That Changed the World: the Story of Lean Production” by James Womack, Daniel Jones, and Daniel Roos as a term to describe the Toyota management approach. The idea that lean can be applicable to software development is developed only after 1-2 years after the term was first used

1992: The term Lean Software Development was first coined as the title for a conference organized by European Union in Stuttgart, Germany.

1993: Robert “Bob” Charette explored better ways of risk management in software projects and suggested the concept of “Lean Software Development”

1995: Five pillars of Lean thinking are defined in the book titled “Lean Thinking: Banish Waste and Create Wealth in your Corporation” by Womack, James P and Daniel T. Jones

Five pillars of Lean thinking are value, value stream, flow, pull and perfection. These pillars have become the working definition of Lean for the next decade. People started identifying waste activities in the workflow and started eliminating them to reach perfection which made Lean to reach wider audience. Since then eliminating waste has become exclusive property/practice of Lean till date.

Womack and Jones didn’t share the definition to the world, Toyota management principles are difficult to describe or to analyze. The word “Waste” is described in detail with three Japanese terms:

Muda – literally meaning “waste” but implying non-value-added activity

Mura – meaning “unevenness” and interpreted as “variability in flow”

Muri – meaning “overburdening” or “unreasonableness”

In any process, perfection is achieved through identifying and eliminating the waste (non-value-added activity). We do not have specific definition for Lean as there are many

How Lean is connected with Agile:

In 2001, Bob Charette was invited to attend the meeting at Snowbird, Utah, where the agile manifesto for software development was authored. But Bob couldn’t attend it. Despite of Bob missing agile manifesto meeting, Lean was considered as one of the agile approaches to software development.

Lean Software Development – Definition: it is very challenging to define Lean Software Development as it is not equal to specific method or process. Instead we could say any software development process is “Lean” if it is aligned with the values and principles of the Lean Software Development. So, one must tailor his/her software development process by understanding Lean principles and by adopting the core values of Lean. Let’s discuss on Lean values and principles

Lean values:

In 2011, the Lean Systems society published a set of values. Those values are

·         Accept the human condition

·         Accept that complexity & uncertainty are natural to knowledge work

·         Work towards a better Economic Outcome

·         While enabling a better Sociological Outcome

·         Seek, embrace & question ideas from a wide range of disciplines

·        A values-based community enhances the speed & depth of positive change

Accept the human condition:

To develop any product, we need people (Human beings) and process. So if you want to develop any product, you need to deal with process and people. Dealing with human beings is quite complex as human behavior is led by their emotions, thoughts, traits. Very important thing to note is that human behavior is not constant; it changes with stress, situations, workload and fatigue. Thus human psychology must be considered when designing the processes within which humans work. Accept and embrace the human condition at any situation rather than to denying it and expecting robot like behavior.

Accept that complexity & uncertainty are natural to knowledge work:

In software product development, there are many unpredictable things like the behavior of customers, product market, defects, required rework, process workflow and team work. There is high chance of random behavior in all the things mentioned. The purpose of the project, vision and scope tend to change based on these unpredictable things. In most of the project initial stages complexity and uncertainty is unknown & is known up to some extent after several studies which helps in managing risks. But variability can’t be anticipated in advance. Thus systems of Lean Software Development should be in a position to adapt to changing circumstances

Work towards a better Economic Outcome:

Lean Software Development should focus on producing a better economic outcome. Let’s see who deserves what

Investors and owners of businesses deserve a ROI (Return on investment).

Employees and workers deserve a fair rate of pay performing their work.

Finally, Customers deserve a good product/service for a fair price.

Better economic outcome is nothing but more for less by managing the capital in most effective way possible. Capitalism is acceptable till it contributes business value and customer satisfaction.

While enabling a better Sociological Outcome:

Organizations need to create a great place to great work where employees respect each other by accepting different human conditions; in turn it develops a system which respects the psychological and sociological nature of people

Seek, embrace & question ideas from a wide range of disciplines:

Teams need to seek continuously for new ideas, brainstorm on it and embrace them to improve quality of process and product. This kind of culture needs to be developed in all disciplines involved in software product development

A values-based community enhances the speed & depth of positive change:

Share your new ideas/innovations and discuss with a value based community which in turn gives more improvements as many people practice your ideas in their projects. Sharing knowledge with good community always helps in going deeper with the positive change and helps in continuous improvement

Lean Principles:

Coming to Lean principles, there are 7 lean principles which seems to agreed & practiced globally with most of the software development processes.

The 7 principles of Lean Software Development are

1.          Eliminate Waste

2.          Create Knowledge

3.          Build Quality In

4.          Defer Commitment

5.          Optimize the whole

6.          Deliver Fast

7.          Respect people

Eliminate Waste:

To reach perfection, you need to identify all non-value added activities in the process and eliminate them. Waste can be in any form i.e. communication cost, co-ordination cost, people meetings, rework etc. Team needs to eliminate all these to increase efficiency in people, process and product quality

Don’t create anything which doesn’t give value to the customer. You need to be careful with the process you follow, people in your team that both are creating value to the customer.

Value has a value only if its value is valued. So, create innovative and technologically advanced products which are valued by your customers. Eliminate anything that does not add customer value

Developers need to write less code as it is directly proportional to the tests they need to write & automate while developing software

Create Knowledge:

Create a work environment where employees are continuously having scope to improve and they are working on it. Team should be like a small research institute, where they do lot of experiments and share the output with value driven community.

Team should get trained in problem solving methods. Leaders should listen to their team members and encourage them to find solutions to the problems encountered.

Use short iterative cycles to provide quick, constant feedback to ensure focus on the right things and make sure that team is working constructively on the action items identified & set.

Build Quality In:

Quality product developer needs to think about product intrinsic quality before he/she starts writing single line of working code, should not wait till integrating with other code

Automate wherever possible i.e. automate anything which is routine like unit testing, integration testing, builds, installations.

Refactoring plays main role in achieving high quality of the software. Refactor the code, the tests and the documentation continuously to keep it simple. There shouldn’t be any duplication

Keep Validating and re-validating all the steps involved in the process. If you find any metric or practice with no value, discard it.

Defer Commitment:

Don't make decisions until enough is known to make the decision, Defer important decisions to the later point till it is mandatory to decide so that you will be discovering more information about the same day after day. Sound understanding of the problem is mandatory to make the decision

To start any work with uncertainty, start with known information and explore the unknown. The most important thing is to keep the team in the right direction

Increments developed should be coupled as loosely as possible to enable implementation in any order. Implementing change will be easy in later stages as components are not that dependent on each other

Optimize the Whole:

Optimization should happen by keeping whole system (or process) in mind and shouldn’t optimize parts with the hope that it will optimize the whole by itself.

Always focus on the entire value stream even if you are working for a small change requested by stakeholder i.e. customer.

To optimize the whole, Organizations need teams with great leaders, great engineers, business analysts, process coaches, sales, marketing gurus, secretaries, functional architects etc. All together can deliver great final products to their stakeholders

Deliver Fast:

To deliver fast, you need to repeat the good things which worked well for you and eliminate practices which created obstacles for you

Management need to keep searching for hidden issues within the team whether it be process or people. Stabilize the work environment based on continuous feedback from the team.

Keep the work in progress items based on your capacity (Velocity). Learn to say NO to new work items if you feel it will impact your current work/or over burden you

Focus on all the possibilities by which you can reduce cycle time. Brainstorm, come up with innovative ideas, stream line the process and reduce time to market

Respect People:

Respect your team & team members for what really it is, for what they do and how they do. Encourage them for their passionate involvement in the organization’s work

Work culture, the most important factor created by employees & organization and empowers employees in the organization

Organizations need to provide training and guidance to the leadership team members to implement lean thinking in their work environment

Move responsibility and decision making to the lowest possible level, because employees at low level know better how to implement difficult algorithms and apply state-of-the-art software frameworks than anybody else. Let them think and decide on their own.

Lean Practices:

Apart from lean values and principles, there are quite a number of practices commonly adopted. Some of the lean practices are mentioned below. Let’s discuss about these in detail in later posts

ü  Cumulative Flow Diagrams

ü  Visual Controls

ü  Virtual Kanban Systems

ü  Small Batch Sizes / Single-piece Flow

ü  Automation

ü  Kaizen Events

ü  Daily standup meetings

ü  Retrospectives

ü  Operations Reviews

To conclude this post, there are no hard and fast prescriptions to follow from Lean Software Development. Follow any of the available software development methodologies but make sue that actual process definitions are aligned with the Lean principles and values to be lean. Definitely Lean is a methodology which will trim the fat from the software process (Starting from requirements to product delivery to the customer)

Hope you got an idea of Lean software development and its value and principles. Thank you for stopping by and reading my blog, it means a lot to me. Help me to improve by giving your feedback. I appreciate it very much! Please feel free to reach out to me

Linkedin: http://in.linkedin.com/in/sathrambalaji

Facebook: https://www.facebook.com/sathrambalaji

-Balaji Sathram