Lean Software Development
The Software Development Life Cycle is a process just similar to any other process. Noble thinking with the right life cycle will ensure that meaningful software is built. Each phase in the life cycle has its own process and deliverables that feed into the next phase. As per experts there are typically 5 phases starting with the analysis and requirements gathering and ending with the implementation.
Adding to the cycle BSN believes that the most critical two points of the cycle are the first two steps prior to setting up are analysing user requirements and having the right design. We at BSN believe after sales service too plays a pivotal role as most of the companies do not look at this aspect. We believe truly that once a partner will always should be a partner in the cycle of business.
Requirements Gathering/Analysis
This phase is critical to the success of the project. As a company enriched with Lean experts from this stage itself BSN will look at the system design with the elimination of eight types of waste. Expectations (whether of a client or your team) need to be fleshed out in great detail and documented. This is an iterative process with much communication taking place between stakeholders, end users and the project team. The following techniques can be used to gather requirements:
- Identify and capture stakeholder requirements using customer interviews and surveys.
- Build multiple use cases to describe each action that a user will take in the new system.
- Prototypes can be built to show the client what the end product will look like.
- Identify focus groups for discussions and conduct value stream mapping to get the right stream
In a corporate setting, this means taking a look at your customers, figuring out what they want, and then designing what a successful outcome would look like in a new bit of software.
Design
Technical design requirements are prepared in this phase by lead development staff that can include architects and lead developers. The Business Requirements are used to define how the application will be written. Technical requirements will detail database tables to be added, new transactions to be defined, security processes, hardware requirements and system specifications will be designed in detail.
Let’s look in more detail at some of the activities involved in this stage:
Risk analysis
- Threats and vulnerabilities which may arise from interactions with other systems.
- External or legacy code needs to be analysed to determine if there are security vulnerabilities.
- High-risk privacy projects could require review with a legal department. This review should consider what personal data to collect, how to collect it, and permissions/authorizations to make changes. This type of review is especially necessary with corporate projects.
Functional Specifications
- Includes a description of interface requirements such as definition of data entry fields (allow numeric or alpha only, can it be left blank?)
- Important details, like: can date entered be before current date? What time zone will user logins default to?
- Workflow – after clicking approve button, which screen appears next?
- Audit trail for every update on the database. This is where error monitoring and logging tools can be useful.
Non-Functional Specifications
- Extensibility of the system – will current system easily allow new enhancements or features with the next rollout? This is critical for any application that you’ll be adding new features and updating often.
- Has the current or future capacity been analysed for database requirements? Will the current build plan result in capacity issues shortly after you finish building?
- Performance and response time – Has the expected response time been determined?
- Resource Constraints – Are there constraints that need to be taken into consideration in this phase? Common ones include disk space, bandwidth, etc.
“Lean” Software development
Traditional software development advocate a ‘lessons learnt’ process, but it generally takes place at the end of a project. By this time, things are forgotten, people have changed, the context has changed, and the team may be disbanding to move on to another project. As a result, the team may never really get a chance to put these learnings and changes into practice.
There are seven key principles of LEAN SOFTWARE DEVELOPMENT
- Eliminate waste
- Build In Quality
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect people
- Optimise the whole
- Eliminating Waste
Waste is any substance which is discarded after primary use, or it is worthless, defective and of no use.
Some waste is obvious. But other forms of waste are more difficult to palpable or to solve. In most organizations it’s sometimes very difficult to identify what is waste and what is not. Some processes or conventions might seem wasteful, but actually provide real value elsewhere in the organization, or prevent other forms of waste from emerging later. Other activities may seem valuable, but actually do not add value to organization.
There are eight particular types of wastes identified in the process of software development.
- Over-production
- Unnecessary transportation
- Inventory
- Motion
- Defects
- Over-processing
- Waiting
- Skills
In lean software development, which translate these wastes into some things more specifically relevant to software development.
For Example:
- Unnecessary code or functionality
- Starting more than can be completed
- Delay in the software development process
- Unclear or constantly changing requirements
- Slow or ineffective communication
- Partially done work
- Defects and quality issues
- Task switching
- Build In Quality
Quality is obviously extremely important, or inevitably create all sorts of waste further down the line. Build quality in. Build it in as early as possible in the process to avoid quality issues materializing. And build it in throughout the entire development process, not just at the end.
- Create Knowledge
In software development, that knowledge is paramount. There’s only one developer that can work on something, at least productively, or even at all. Nothing beats the knowledge that’s created when someone actually writes the code.
So, if knowledge is important, and helps the longer term productivity and flexibility of the team, need to take some specific actions in the short term and put some specific things in place to ensure that create it.
Here are something to help create knowledge
- Pair programming
- Code reviews
- Documentation
- Wiki-to let the knowledge base build up incrementally
- Thoroughly commented code
- Knowledge sharing sessions
- Training
- Defer Commitment
This one could easily be misunderstood. It doesn’t mean should put off committing to anything indefinitely, or defer all decisions – that would obviously be a very bad idea.
What it does mean, is decide as late as possible, particularly for decisions that are irreversible, or at least will be impractical to reverse. Time box critical decisions for the latest point can be made without causing problems.
Obviously it is also important not too leave decisions too late. This can delay the team and make projects difficult. But, the later can safely leave critical decisions, the more information will have available to make the right decision when the time comes.
Keeping decisions about features and the development of those features close together helps to ensure that the right product is delivered, because it leaves less room for change.
Deciding too early, run the very likely risk that something significant will have changed, meaning end product might meet the spec, but it might still be the wrong product! This is one reason why so many projects fail.
So, that fewer commitments are irreversible. And defer commitment on irreversible decisions to the latest point possible.
- Deliver Fast
Speed to market is undoubtedly a competitive advantage. There is considerable evidence that companies who gain ‘first mover advantage’ go on to be the most successful companies in their chosen sphere. Companies can copy, and sometimes even come along later and do things better, but often it is the first to establish itself that wins the day and becomes the long term leader in its field.
Advantage of delivering fast is that, if there is as little time as possible between the Product Owner stating the requirements and the team delivering the product, there is little chance of the requirements changing. Less time minimizes the chances of changes in the market, changes in people, or even simply a change of mind.
Requirements of Go faster:
- Have the right people
- Keep it simple
- Work as a team
- Eliminate waste
- Build In Quality
- Respect people
It’s important to treat everyone with the same respect, whatever their job. It doesn’t matter whether they’re the CEO, assistant, executive, manager, the receptionist or the cleaner, respect everyone equally.
Same respect means responding to people promptly, listening attentively, hearing their opinions and not dismissing them even when they are different to your own. It means encouraging people to have their say. Having empathy for their point of view and trying to see things from their perspective.
But, it doesn’t necessarily mean that always agree with them! That would be a very unhealthy situation. So one of the arts of respecting people is learning how to be assertive and disagree with a point of view, without sounding aggressive or threatening or just plain argumentative.
Another important part of respecting people is giving people the responsibility to make decisions about their work. To achieve this, it’s important to build knowledge and develop people who can think for themselves. People who can think for themselves and are experts in their area often need to be empowered to feel respected.
- Optimise the whole
A lean organisation seeks to optimise the whole value stream, not just individual functions or teams. It is extremely common for big delays in projects and processes – as well as communication issues and misunderstandings leading to other problems – to be caused by handoffs between teams, departments or organizations. The fact is that crossing organizational boundaries – even internal ones – is expensive.