The key members from the technology group are waiting to hear about the new project that the director is going to announce. The meeting is about to begin, and the room is filled with silence. They know that the project has something to do with Java, Oracle, and the cloud. The director starts explaining the importance of this strategic project and delivering it on time to the customer.
Read the complete article on Cutter
This article was published on Techwell, the place to go for what is happening now in software development.
The daily standup meeting is a critical element of scrum teams. Its simplicity and benefits have even attracted the attention of practitioners of waterfall development.
The term “daily standup” originated from Extreme Programming (XP) while the term “daily scrum meeting” goes back to Scrum, of course. One should note that both XP and Scrum derived the concepts of daily meetings from software pioneer Jim Coplien and his paper on the Quattro Pro spreadsheet program.
In the simplest sense, a daily standup meeting is accomplished by having team members stand around in a circle with each person answering a few questions. But wait, life is not as simple as it sounds, and there are certain rules to be followed during these meetings. The rules cover the team’s time commitments, location of the meeting, and the meeting’s overall rigor, all of which make up the secret sauce for success.
Holding a standup meeting in a collocated environment is simple compared to holding a meeting with distributed teams, in which you need to be cognizant of time zone differences and language barriers. The use of tools—teleconferencing technology, webcams, and instant message software—can help you deal with remote teams. For more help on that front, you can read the Practical Guide to Distributed Scrum, which provides an overview of different tools and their associated pros and cons.
Most people recommend holding the meetings in the morning, keeping in mind what time the last team member arrives for the event. For some, noon seems to work as well.
As agile coach Rachel Davies explains, scrum meetings are not only about sharing yesterday’s work, but they are designed to help team members plan for the day and look to the future. If you’re working in a distributed environment, you might find help in this guide by Rally, which discusses fine tuning your meetings.
Keep in mind that there are several ways that daily scrum meetings can result in trouble for your project. For example, team members might stop attending the meetings or they could even complain that the meetings do not add any value or are a waste of time. The worst is when people make this a status update meeting.
There are several ways to fix these troublesome issues, including reinforcing the values and principles behind the meetings. Also, remember that command-and-control management issues might lead to many people-related problems, and you’ll need to address those issues if they apply to you.
Finally, if you still are having issues with standup meetings, Jason Yip, a principal consultant at ThoughtWorks, recommends a few good tips, like rotating the facilitators, breaking too much eye contact, and using improvement boards.
Following article got published on Zephyr recently.
During the waterfall era, at the end of development, the completed code was thrown at testers who in turn would identify defects. These defects would get registered onto a tracking tool. In response to these defects, the developers would swarm around them and fix all of them for the next one week. This process used to continue until the QA team signs of on all the defects.
Now with the popularity of the Agile, Lean and Continuous Deployment, the developers are required to be more vigilant while coding. They are recommended to follow practices like TDD, ATDD to improve the code quality, reduce defects among other benefits. Since these practices are supposed to reduce the burden on testers, a lot of people are questioning the need for dedicated testers in the software development.
In this article, I will address questions around the need for testers, the value they bring in, and their role in the context of Lean and Agile.
Why do we need to build the quality in?
Let me begin with the Lean Principle #2, Building Quality In. Before jumping to solution mode, let us understand the ways the quality issues crop up and the cost associated with it. Quality issues originate at the beginning of the project and the top 3 reasons could be grouped into:
Irrespective of whether the mistake is by the customer or the developer, there is an effort involved in testing and rewriting the code. As per the 1:10:100 rule, the failure to identify the defect upfront could cost a fortune to the company.
Solving the quality issues:
First issue mentioned above could be solved by the development teams building the prototype and showcasing to the customer even before touching the code. Second and third issues could be solved by practices like TDD and ATDD.
If developers and customers work closely, ensure to fill the gaps and write quality code, can we still delivery a quality product without testers ?
In recent days, some of the lean startup companies have tried customer testing and crowdsourcing the testing without involving the testers. However, it is still not proven if this is the right model. A lot of people also agree that even the most experienced developers make mistake. The developers come with a specialized technical background and they won’t have the same eye as a tester. They are good at unit level testing, and they cannot effectively do the integration/system level testing. This is not something which could be improved by automating the tests.
Role of tester in Agile, Lean environment:
Many teams have tried building products just with developer testing and have got bitten badly as well. As one could see from this discussion, people have reverted back to include testers.
There is no doubt now that dedicated testers are needed in all projects. We still need testers to provide a neutral eye and their specialized skills to improve the quality. In fact, testers have now more empowering role to play than before.
To conclude:
Image courtesy of ponsulak / FreeDigitalPhotos.net
In today's rapidly changing business environment, innovation is key for survival. Companies may become obsolete in no time in the absence of new and innovative products. A classic example of this phenomenon is the demise of Kodak. At the same time, companies like Apple and Google have not only contributed toward building innovative products but at the same time made their investors many times richer.
Check this complete article out on Cutter
Following article got published on Techwell
All of you have probably heard the news involving the recent ban on larger soda sizes in New York and the subsequent un-banning. There are people who are arguing against the soda size ban, and they are challenging government not to micro-manage their lives. On the other hand, there are people with views who vouch that this ban would help improve the health of overall society as well as reduce the tax burden.
These conflicts in thinking that occur in societies in which a group of people resist an unpopular decision are nothing new and not restricted to large societies at all. We see these things in our day-to-day life—even in our work places.
Have you come across situations where project teams have resisted changes suggested by their leader? To add another twist, what if the teams were self-organizing, as in the agile world?
Self-organizing teams are supposed to have clear goals and manage their own priorities to achieve them. This does not mean that they are leaderless. Let me clarify at the outset that self-organizing teams have leaders and someone to monitor and support them.
As author and developer Jim Highsmith says, they need light-touch leadership. Leadership needs to step in if the self-organizing team are treading in the wrong direction, thus moving away from the goal.
I heard a story from the trenches about a particular self-organizing team going through this journey. This new agile team felt it was a waste of time to do Scrum rituals and collectively decided to skip the daily stand ups and retrospectives.
As expected, the ScrumMaster stepped in, did the root-cause analysis, and found no reason to skip the rituals. The ScrumMaster then tried coaching the team about the importance of rituals and why team members should not ignore them.
However, the team members decided to escalate further to senior management to get support for their cause. Let’s say you are part of senior management. Would you be supporting the ScrumMaster or the team? I am sure most people would agree to support the ScrumMaster since the daily stands ups and retrospectives help agile projects, teams, and their own bottom-line in the long run.
However, what if management supported the team's skipping the rituals? Supporting the ScrumMaster would have caused more agitation by the team, which would result in a loss of team morale. Tying this story about self organization back to the New York soda ban, I see that Mayor Michael Bloomberg (ScrumMaster) had all the good intentions to save lives by bringing this change; however, he didn’t get support from the citizens (self-organized teams).
How would a ScrumMaster bring about change in the above situation? What kind of management practice could help team members change their minds?
