Imagine that your team is developing product for some market. There is no specific customer yet, so product owner is an internal product manager. And at some point you realize that there is lots of functionality, but from user’s point of view it just doesn’t work at all – bug here, bug there, small, but very important piece of functionality is not implemented because team is comfortable adding data via database. Product owner expresses his concerns from time to time, but it doesn’t help. Developing first version of product is quite difficult task and team loses its enthusiasm as they don’t see real customer. End quality is decreasing. What to do?
In Scrum there is a concept of sprint demo – meeting, when new version is shown to customer (product owner). Usually it is held privately – the team, product owner and possibly some stakeholders. Making sprint demo public is neither prohibited nor promoted by “best practices”.
Public sprint demo can provide the company and the team with several advantages:
- Awareness of public presentation (especially to peers) creates stronger commitment
- Awareness of public presentation makes the team think about usage from user point of view – they have to demonstrate it to the public
- It leads to more stable product – nobody wants to demonstrate how unstable the product is in front of peers
- Public presentation makes other people aware of what is going on therefore increases transparency and unites company
- Public sprint demo allows the team to show off their achievements therefore increasing satisfaction
- It increases presentation skills of the team, makes them used to public attention
- Attendees can give valuable feedback on the product
- Successful public sprint demo gives the team strong feeling of great achievement
Read more…
Software quality assurance is usually understood as ensuring that a process is adhered to. But does just following a process guarantee sufficient quality? Perhaps, if a process contains focus on quality and means to maintain it. And there are right people.
Of course, theorists would say that a process guarantees quality, that all problems are caused by violation of procedures or the project is “wrong” or all mistakes because of people not of the process. But in reality people are the most important part of success and even thorough formal adherence to the process can result into failure. Therefore software quality assurance is a misleading term. It doesn’t ensure quality of a product; it merely ensures compliance with the process.
Let’s focus on ensuring quality of a product, not just adherence to a process. Quality can be controlled or it can be built into the process of product’s creation. These approaches complement each other. If there is only control then a company will have to spend much resource on rework of low-quality stuff, if there is no control at all then risk of producing a product of inadequate quality is higher.
To increase quality the team can use some tools and techniques. It’s important to assure that we know what is to be built, how to build it properly and how to test that a product built is what the customer needs.
Quality assurance is quite a big topic. There is lots of information about each of tools mentioned below; this article is aimed at providing brief overview. Bearing in mind focus on quality one should pay attention to at least the following areas:
- Requirements gathering and analysis
- Development
- Preventing problems in the future
Read more…
Is Scrum better than RUP?
Yes.
No.
That’s an incorrect question. We can’t say that Scrum is better than RUP because we can’t compare them reliably. In fact a process is a multidimensional essence. As you know from math we can’t compare two vectors – only their norm. And norm can vary depending on the space. The same is true for processes – to compare them we need single value to work with and context.
Success rate? It depends heavily on project size, executive involvement, whether requirements are stable or not, etc.
Any process has some ideal context in which it is the most useful. We can’t say that one process fails more often – this process may have been applied in a wrong environment. For instance, if one is going to apply pure Scrum in development of new Boeing – he’d better think again. And if one is going to use full-blown process in accordance to government military agencies’ norms for developing small web-site s/he will have tough time trying to get profit.
It makes sense to bear in mind while choosing, designing or adjusting a process:
- Project’s context
- Industry experience
- Needed level of flexibility and reliability
Read more…
Retrospective is one of the most ignorable practices from agile processes. Why people don’t use retrospective? Mostly they don’t see the value yet they see difficulties that it causes.
No doubt any practice which provides no value should be cancelled. But some practices provide long-term value which some people don’t take into consideration.
Some obvious goals of retrospective:
- Gather feedback
- Improve situation using gathered data
Unfortunately it is not so easy. Main problems are:
- Insincere atmosphere prevents useful and thorough feedback, in such team (or even entire organization) retrospective can transform into “witch hunting”.
- Team members don’t take into account long-term benefits of retrospective, they look only for short-term ones, and stop conducting retrospective very quickly (or even don’t start)
- Improperly organized retrospective without clear goals produces no real results, it’s a waste of time
There are several important hidden advantages which outweigh potential problems:
- Such meeting can make the atmosphere more open, because people get used to give and get feedback
- As soon as project team see that process can be tailored to them company-wide standards meet less resistance (although any standard which usefulness can’t be explained to a team will meet resistance)
- It can help to improve company-wide processes
- It helps to react to changes
This article doesn’t cover organization strategy in part of reflection and improvement. It is mostly about how to conduct useful retrospectives. It includes:
- Benefits from different point of views
- How to conduct
- Tools for retrospective
- Company-wide retrospective
Read more…
Knowledge management is quite a controversial topic. Some companies invested big resources into knowledge management projects and didn’t get expected results. Due to these failures knowledge management is considered by some companies as just yet another “silver bullet” which doesn’t provide any real value. Some companies believe that by managing knowledge they can solve all their problems.
It seems that the truth is somewhere between. Knowledge management is not a silver bullet, but it can improve company’s bottom line by making its operations more effective. Mostly it is targeted long-term goals – optimization of company’s work (but mainly in the future), development of staff. It provides better information for making decisions because knowledge sharing increases transparency. Calculating numerical outcomes of knowledge management projects is not an easy task, but often it is much easier to calculate losses if such project is not implemented.
Companies tend to start global revolutionary projects in this sphere, despite of the fact that large projects are seldom successful. It’s a smart move to take into account statistics and split project into smaller parts:
- Having several smaller parts provides a company possibility to change strategy after implementation of each part – a company can use results of previous stages in implementation of the rest, it can change, cancel or add new phase;
- Big changes almost always meet resistance from people – when people are tired of changes they will ignore or even sabotage new projects. Splitting a big project into smaller ones can allow to separate phases in time and to give people time to get used;
- A company gets results quicker – after every part.
Another common misconception is that new technologies (e.g. ontology, knowledge base, etc) automatically improve knowledge sharing. Without appropriate corporate culture people will not use technologies. Yet technologies can help to share knowledge by making it easier.
Let’s take a look at some practical ways to share knowledge in a software development company. These methods don’t require serious investments or new systems, while providing value to a company:
- Processes
- Common practices
- Internal conferences/camps
- Trainings
- Common retrospectives
- Team review
- “Scrum of Scrums”
- Success stories
- Common place
Read more…
As a human being it’s hard to understand how other people perceive us and our behavior. But having such understanding is a way to get additional information about us, possibility to get a view from “outside”. People can approve or disapprove our behavior and thus give us possibility to react and improve ourselves. Sometimes negative feedback is even more important then positive, but people rarely give negative appraisals being afraid of conflict. 360 degree review is a method to get as positive so negative feedback from different angles.
360 degree review is developed to be used inside a company. It is based on getting opinions about a person from his subordinates, his colleagues and his boss. Results of this review can be used in several ways:
- Evaluate performance of a person
- Evaluate strengths and weakness of a person
- Provide him with feedback
Evaluation of performance or strengths and weaknesses is not the topic of this article. I’ll concentrate on using 360 degree review for providing people with feedback about themselves. Results of such review are a good base for self-development. In addition correctly organized 360 degree review can make corporate culture more open.
Read more…
Talent management is a new buzzword (actually, not even really new). This term is used to describe very wide range of activities – from gathering people with appropriate skills as a project team to designing complex corporate retaining programs. Nowadays terms talent management, human resources management and human capital management are used interchangeably.
Let’s take a look at talent management from perspectives of an employee and an employer. It seems that their goals of talent management are different.
What does a person expect from talent management? S/he needs to improve her/his skills, increase salary, get higher position, increase self-esteem and job satisfaction, etc. What does a company expect from talent management? It needs to be able to fulfill its operations in the most effective way – right people in the right place for the minimal amount of resources (resources include wide range of things – money, time, reputation, attention, etc). So, it seems logical to hire minimally qualified people who can perform a job and pay them as little as possible. Yes, requirements of a person are completely different from company’s needs.
Read more…