Learn Software Development » Performance

Not pushing the team too hard – a fine balance that can be easy to miss – Part 2 ..

ashish — Tue, 17 Jan 2012 15:34:14 +0000

The previous post (Pushing the team, maybe too hard) detailed some of the problems that a team that was under-performing started experiencing when it decided that it would not longer under-perform and started to move up the performance chain, but in the end, the focus on productivity started taking a toll on the team members. There were a number of factors that were not considered when it started becoming a bit more clear that the team was getting fatigued.
One of the biggest factors that we had to re-consider was the notion that we would not say no to a request or a project without doing a lot of deliberation, and if there was a chance, then we would be aggressive and push for doing the project. This worked beautifully for a while, since earlier we would be conservative, and when we would do a resource and risk assessment, if there was a chance of some risk (around 20-30%), we would say no to the project. This was giving the group the title as a No saying group. So, we worked hard at this aspect. Over a period of time, when a project was proposed and we were evaluating the project, we would do a calculation of the risk, but we would also do a strong focus on seeing whether the risks could be mitigated. So, when there were risks, senior members of the team which was doing the evaluation would be encouraged to take a look at the risks, and see whether there were steps that could be taken to manage these risks, and even if this required extra effort, it would be worthwhile to take the extra effort and get these things done. In addition, an incentive was given to the team, in terms of promises of higher rewards for higher productivity, and with differentiation between team members based on the effort that they would undertake (and this was a big deal in terms of encouraging people – if many team members felt that extra effort was being recognized, you had several of them putting in an hour or two of extra effort on a daily basis in order to show that they were capable of doing more effort).
Well, all this had the desired effort. This factor about being more aggressive had an important effect on the reputation of the team, and we were being known as the team that could get work done that seemed more difficult for the other teams. But, at the same time, there was a risk in terms of what we were doing. Since we were taking more chances on the risk front, we were pushing the envelope, and this did hit us in a couple of occasions where we ended up taking last minute risks with the project, and in one case, had to get people from other groups, else the project was a goner. These cases did cause some amount of re-thinking, but not a drastic change in policy, and we continued on. So, what were some of the pointers to the fact that we were heading towards a case where we were trying to chew more than we could do ? Well, for one, we had people from other teams and from senior management asking the team management whether we knew our limits / constraints, and was our risk calculations on the right side of sanity ? These queries were coming up more recently, and these also started a re-think on the level of aggressiveness we were following.

Continued in the next part …

Outswim the Sharks: How to Quadruple Your Team’s Productivity with Kindness	How to Unleash the Collaborative Genius of Teams for Increased Engagement, Productivity, and Results	Visual Meetings: How Graphics, Sticky Notes and Idea Mapping Can Transform Group Productivity

Scrum failure – trying to get a Business Analyst to play the role of a Product Owner

ashish — Sun, 19 Jun 2011 15:34:23 +0000

One of the biggest problems in trying to do Scrum projects is when an existing team is sought to be converted to using Scrum methodology. Consider the case where the team has a Project Manager to run the project, and Business Analysts to convert the requirements into specific documentation that the developer team can use. Now, when the team wants to start doing Scrum, the Project Manager would typically become the Scrum Master (although the roles vary drastically between the Project Manager and the Scrum Master), and the Business Analyst takes on the role of the Product Owner.
However, in a couple of projects, after discussion across the organization, we found that these conversions were not so simple. Taking on the role of the Scrum Master from that of the Project Manager was a challenge of its own. The Project Manager has absolute authority over the project, and over the team members; the Project Manager works with the leads to ensure that work is broken down into different tasks and these tasks are assigned to different team members. Typically, there is a big MS Project sheet that the Project Manager tracks along with the leads and uses that like the Bible for the execution of the project. When the Project Manager starts working on the Scrum methodology as the Scrum Master, there is a perceived huge loss of authority. The tracking of the tasks is done in terms of how much effort is still pending, with many tools not even trying to track how much the project is running over the time limit (this can be very jarring for the Project Manager when they are introduced to Scrum and tracking as part of Scrum). In a couple of cases, I have found that the Project Manager found the change in role so jarring that they decided to change teams and move over to other projects which were not based on Scrum.
The bigger problems was when the Product Owner role was seen as the perfect place for the Business Analysts to do. Now, typically the Business Analysts were expected to take the client requirements and convert these into a form that the Development team can use. Now, the role of the Product Owner in Scrum is a specific role, which requires a certain amount of skills. They have the flexibility to make changes to the priorities of the features, and also to modify the scope of the features of the projects. This is typically not what a Business Analyst does, and it was strange to see the Business Analyst converted into the Product Owner trying to do these part of the roles. The team had got the training, and seen role plays and examples, and expected their Product Owner to work the same way. However, like anybody doing the role for the first time, the first few Sprints was very difficult for the Business Analyst and the required responsibilities were difficult to acquire. The team saw these issues, especially the clear inability to re-scope the work and put some amount of pressure on the Business Analyst. It was also getting realized that this pressure was reducing the credibility of the Product Owner with the team claiming that decisive actions were not being taken. Eventually the concerned Business Analyst made their way off the team, something that we tried to prevent (it is hard to get a person who is readymade for a role – in most cases, you get a person and try to fit them into a role, and it takes some time to be ready).

Testing of Web Applications

ashish — Sun, 01 Mar 2009 17:35:38 +0000

The quality of a web application can be pretty evident right from the onset (from the beginning of testing). Some of the key things to check for, and that are visible right in the beginning are:
- Slow response time,
- Problems with the accuracy of information,
- Bad design / workflow problems or not having ease of use will compel the user
to click to a competitor’s site
Problems such as these that are easily visible directly translate into loss of users, declining or stagnant sales and a very poor image of the company.

These are outcomes that companies seek to avoid at any costs, and that is why there is the need for a strong QE effort. As a part of this, the following techniques can be used to do a more thorough checking:
1. Good Functionality testing – This sort of testing makes sure that the features that are visible to a user and affect interactions are working properly and as desired.
Some of these objects in a WebApp include: User enterable forms, Searches and their results, Pop-up windows (most users hate them because of their heritage), shopping carts.

2. Usability testing – Many users have a low tolerance for anything that is difficult to use, making having a usability testing program a critical part of the testing of any WebApp. You need to ensure that a user’s first impression is very important; what makes this more complex is that now-a-days applications have become complicated and cluttered with an increasing number of features.

The main steps involved in usability testing are:
– Identify the purpose of WebApp.
– Identify the intended users.
– Define the tests, review them for thoroughness and conduct usability testing.
– Collect information through various mechanisms.
– Carry out an analysis of the acquired information.
– Make the necessary changes based on the acquired information.

3. Navigation testing – Navigation testing makes sure that all navigation syntax and semantics are exercised to uncover any navigation errors. It should not happen that a user clicks on a navigation aid and then either reaches a dead end or goes off into a wrong direction.

4. Forms testing – WebApps that use forms requires tests to ensure that each field is working properly (including the validations such as not allowing users to enter more than a certain amount of text, fields not being left blank, etc) and that the form posts all the data as intended by the designer.

5. Content testing – Content is evaluated at both a syntactic and semantic level.At the syntactic level, spelling, punctuation, and grammar are assessed. At semantic level, correctness, consistency, and lack of ambiguity are all assessed. It creates a very bad impression if the user finds spelling mistakes (user assumes that there must be something wrong if the company put wrong spellings or wrong grammar and did not find it till now, or the company does not care that there are problems on the site)

6. Compatibility testing – This testing is done by executing the webApp under every browser/ platform combination to ensure that the web applications are working properly under different environments. This sort of testing is easier said than done, since the number of browsers and operating systems in the market are huge.

7. Performance testing – This testing evaluates the system performance under normal and heavy usage. An application that takes long to respond may frustrate the user which could result to move to a competitor’s site. This testing ensures that the website server responds to browser requests within defined parameters. The system should work perfectly and speedily under normal expected usage, and if possible, should be handle some amount of extra load.

8. Load testing – The purpose of this testing is to present real world experiences, typically by generating many users simultaneously accessing the web application. Typically, companies use automated test tools to increase the ability to conduct
a valid load test as it emulates thousand of users by sending requests simultaneously to the application. Critical, as failure under heavy loads does not convey a good impression, and may make the system susceptible to attacks by recreating heavy loads.

9. Security testing – Security is one of the primary concerns when communicating and conducting businesses over internet. One break-in can spoil the reputation of a company and lead to loss of business, stealing of user data, and other such cases with horrible consequences. Finding the vulnerabilities in an application that could grant an unauthorized user to access the system is important. Equally important is being able to track all access to the system, and do a frequent scan of these accesses.