Software the Agile Way....

In an ideal system the below mentioned non functional characteristics could be imagined: Highly Secure Very High performance  Massive flexible  Extremely Scalable  Easy to use Easy to support Simple to develop and maintain However this comes with a cost hence a careful up front analysis should be done to make an informed  decision on what architecture to choose for the system. Suggestion is to involve all the people involved in the delivery in the beginning of the project to think through the application. This would help identify the impact on below mentioned activities: System architecture Project schedule Test strategy Overall Cost Stories with clear acceptance criteria must be created so that these could be tracked and thinking is evaluated. Remember to avoid such acceptance criteria :  Response time must be "as fast as possible"  If no further analysis is done on such criteria then there are possibility of adding complex code in the syste

In the Scrum meetings, if the one of the team members are digressing from the agenda then  other team member will say "can we take this after this stand-up meeting" instead of Scrum Master saying this. In the daily stand-up meeting, team members are stressing on the done activities rather than discussing something which is not bringing clarity. Team is flexible to accommodate small ( non significant requirement changes) rather than becoming rigid in not accepting this. Team members respect each other and one conversation is going on during the meeting. Team members are asking question to PO on why this feature is needed? Team members are looking for improvements and taking interest during retrospective meeting to bring the topics without any fear. Team members are skilled and confident of the work and are not scared of ambiguity rather than working towards it to make it clear.  Team members respect time. Team members trust each other and do not depend on email or a

Daily Stand-up Meeting- Are team members committed to the goal of the Sprint ? This should be verified by showing the taskboard to team possibly a Kanban board and let the team team provide their opinion on where they stand. Additionally, show them the burndown chart trend on the daily basis in the meeting, if the chart is deviating from ideal graph. Sprint Planning Meeting           2.  Are the team members doing some pre-planning and preparing themselves for the planning meeting. This should be verified by checking that team is very sure about the user stories and they know what stories to be delivered and how. Sprint Refinement/Grooming Meeting     3.  Are the user stories are prepared well prior to this meeting? Are the user stories understood to PO before explaining to team? This  can be verified by ensuring that sizing of the stories are happening for the planned stories for this meeting. Sprint Review Meeting     4. Are the team well prepared to deliv

Few areas which has no direct answer in Scrum/Agile: 1. How can we estimate/forecast the project when all the user stories/requirements are not available at the beginning of the project lifecycle? 2. How can we define the architecture for the project when all the final requirements are not freezed? 3. What level of documentation is essential / Must to do in Scrum based projects? 4. How can we avoid a scrum sprint to become a mini waterfall? 5. How can Manual QA add value to a scrum sprint? Other than Testing! 6. Who is responsible of sprint delivery ? Development team/Scrum Master/Product Owner? 7.  Can we avoid controlling type of management in Scrum? Is the team really empowered in the Scrum to take decisions? What about the advise on technology where budgetary constraint would come?  8.  How to measure the value of Scrum Master? If the sprint is delivered as per commitment then can the scrum master be awarded for that? 9.  Can Scrum run with Fres

Poka-Yoke   is a device or method that prevents people from making mistakes. The word in Japanese means mistake proofing or error proofing. What habits we can have in Scrum Sprints: 1. PO must have this constant habit of thinking "Is this User story solving the problem"? 2. Developers must do code check-in when all the team members are there. This will create a stable build. 3. Scrum Master need to constantly think of not only current sprint status but also about next sprint risks/dependencies. 4. QA must have a habit of checking the software on every code check-in and not when all the features are available. If any logical feature/test case is finished QA should start verifying it. 5. QA must interact with Dev on regular basis to share the observations. Bugs reported much early in the sprint cycle is better than later. Can someone think of any other habits?

Promoting collaboration in challenging circumstances - For example - in the Delivery pipeline, due to a abnormal code check-in, a critical issue has occurred. Coach need to look for solution by collaborating instead of blaming the team member.  Searching for truth/a solution relentlessly - For example - a problem is reported by someone and it looks small and has little impact still the solution should be identified as you never know when a small issue becomes a big one.  Honesty and trustworthiness - For example - a coach need to get out of a situation where coach feels can be handled by the team. This builds trust within the team.  A learning attitude (proactive and learning from mistakes) -For example - A decision has gone wrong and does not bring the positive results . then the coach need to learn and change.  Humility and Assertiveness - For example - be open in talking to team in giving feedback.  Guiding people without controlling them - For example - be a coach.  Det

Be passionate about Scrum/Agile- Scrum Master must know Why  and How Scrum is beneficial. Self Organizing- Before managing/organizing others Scrum Master should manage himself/herself.  Scrum Master should have a clear plan for the day, how does he want to spend the whole day. Scrum Master should ask questions to understand the gaps/opportunity. Scrum Master must give importance to people and relationships. Keep the team motivated Finally the most important, be open to feedback/criticism so that you can learn new ways of tackling.

Backlog Grooming meeting should be timeboxed and ready stories should be identified prior to meeting. Ensure that the Acceptance criteria has specific details which can be tested and verified. Acceptance Criteria should be agreed with team so that they could point out any ambiguity/unknown points. Tester should have seen the acceptance criteria (prior to Backlog grooming meeting)to suggest any possible test cases which could be covered for example common UI validations. Try to identify the negative scenarios which could be critical for team to handle during implementation. Use Whiteboard to explain user stories and business flow Any assumptions/queries/risks should be noted to be handled later.  Enough details should be there so that additional found in sprint should not change the scope of work

The very first thing you must do to become Agile is establish a good relationship with your customers, users, and domain experts; who ever it is that directly or indirectly pays for your work. The first symptom of a damaged customer relationship is when your customer considers it a waste of time to participate in the project.  You may have delivered software that just doesn't meet return on investment (ROI). In any case your customer is important and you need to repair your relationship first. One way to start a partnership with your customers is to listen to their needs and respond immediately. The best way to guarantee your customer's time (and thus money) isn't wasted is to involve them enough to guarantee success. Respect your customer by acknowledging their expertise, listen carefully, defer to their authority, and never insert your own opinions into your code. Communicate with your customers simply and in a language they understand. If your customers think b

Pitfalls - Customer is there ( but not full time) and Sprint 1 started but no deliverables (working software) !! Challenges - Initial Product Backlog with must have stories are not defined which means there will be no initial design model. Engineering team is there but everyone is directionless as nobody knows where to start!! How to be prepared - Be ready with Product backlog with must have stories and requirement workshop with engineering team before starting the Sprint 1. Engineering team must have an architect to do the initial design. Requirement workshop to be conducted in presence of customer.Team should be well trained to work in Agile methodology. Plan some deliverable in the Sprint 1 

Customers are afraid that • They won't get what they asked for. • They'll ask for the wrong thing. • They'll pay too much for too little. • They must surrender control of their career to techies who don't care. • They won't ever see a meaningful plan. • The plans they do see will be fairy tales. • They won't know what's going on. • They'll be held to their first decisions and won't be able to react to changes in the business. • No one will tell them the truth. Developers are afraid, too. They fear that • They will be told to do more than they know how to do. • They will be told to do things that don't make sense. • They are too stupid. • They are falling behind technically. • They will be given responsibility without authority. • They won't be given clear definitions of what needs to be done. • They'll have to sacrifice quality for deadlines. • They'll have to solve hard problems without help. • They won't

You write emails, facilitate meetings, participate in conference calls, create reports, devise presentations, debate with your colleagues… the list goes on. According to the 7 Cs, communication needs to be: Clear -  What is your purpose in communicating with this person? If you're not sure, then your audience won't be sure either. Concise - S tick to the point and keep it brief.  Concrete - There are details (but not too many!) and vivid facts, and there's     laser-like focus. Correct -C orrect communication is also error-free communication. Coherent -  All points are connected and relevant to the main topic, and the tone and flow of the text is consistent. Complete -  In a complete message, the audience has everything they need to be informed and, if applicable, take action. Courteous -  Courteous communication is friendly, open, and honest. Source -  http://www.mindtools.com/pages/article/newCS_85.htm

The cost of change for a traditional software project When changes to a product is introduced during the development stage because of new information or a new customer requirement, a domino effect of negative consequences followed. First, the process had to go through formal change control that was intended to ensure everyone on the team, especially those handling development and QA, understood the change and that the plan of record was kept up-to-date. This meant documentation and meetings. Second, the effort had to be estimated and, often, the schedule recast. Kent Beck, who developed Extreme Programming, asks a very thought-provoking question: if our cost curve were relatively flat (Figure 1.3) Would we behave differently?  Would we delay decisions until we had better information?  Would we over-design in anticipation of future needs or just design and build to our current requirement?  Would we be able to deliver more value to the market, Would we

DO Say  what  needs to get done. Challenge the team Get interested in building a high-performance team. Practice business-value-driven thinking. Protect the team from outside noise. Incorporate change between sprints. Don’t Say  how  to do it or  how much  it will take. Bully the team Focus on the short-term deliveries only. Stick to the original scope and approach  “no matter what.” Worry the team with changes that might happen, until they become real. Allow change to creep into sprints. Advise from  Lyssa Adkins

C ommunication - Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming. S implicity - This is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.They remain constantly focused on doing the simplest thing that could possibly work. F eedback - XP teams value feedback, and the more immediate the feedback the better. This is achieved by Pair programming, Continuous Integration,Automated Testing and from customers. C ourage - XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage).They will use a metaphor and maintain a simple design through refactoring and test driven development.

S mall releases -  By the end of each iteration( 2 to 3 weeks long)  the team is responsible for delivering working, tested code that can immediately be put to use. The p lanning game -  Prior to the start of each iteration, the team and customer plan the iteration. This involves selecting the highest priority stories that can be completed in the iteration and then identifying the specific tasks necessary to complete the story . R efactoring -  Refactoring (Fowler 1999; Wake 2003) refers to the restructuring or rewriting  of code so as to improve the code without changing its external behavior.Refactoring is one of technique used by XP to replace upfront design. T esting -  XP puts the tests right up front in a practice called test-driven development (Beck 2003; Astels 2003). On an XP project the developers write automated unit tests and the customers write acceptance tests, which are often automated either by the customers themselves or with some help from the devel

1. Story point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on. 2. The first approach is to select a story that you expect to be one of the smallest stories you’ll work with and say that story is estimated at 1 story point. 3. The second approach is instead to select a story that seems somewhat medium-sized and give it a number somewhere in the middle of the range you expect to use. 4. Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration. If the team completed three stories each estimated at five story points then their velocity would be fifteen. If the team completed two five-point stories their velocity would be ten. 5. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering em

PO and team to demonstrate the working software increment to other stakeholders. The goal is to solicit feedback and then make changes to the backlog if appropriate. Think of it as User Acceptance Testing. Talk about the release plan and how the current sprint affected it. The PO should also be highlighting what is comming up in the next sprint. How are we going to deliver the potential business benefits of Agile? Did we pick the right delivery approach for the product and the right stakeholders? Did we coach and engage them well enough? Do they understand the importance of incremental, iterative development and the frequent feedback loops? If business is not available or interested are we really working on the right thing in the right setting? Are we engaging business in the right way?

Normally enterprise architecture should take place before the project even starts.It should be part of the project start-up or mandate.  In particular the organizations application architecture and integration architecture should be done.  Its unlikely that there will be a enough information at this point for information architecture,This will need to evolve as the project progresses. As for the other enterprise level architectures, many of these will be defined and form part of a definition of done. Typically in the start-up of a project, a BA, product owner will capture epic ideas and these will be broken down into high level feature stories/requirements. Note this is not going to be detailed and ready for a team to implement, but it covers enough knowledge that an architect should be able to formulate a technical approach. This also servers as a high level release plan. A good technical/system architect should be able to look at these feature requirement and formulate a techn

Do Each active participant in the daily standup is supposed to share what they did yesterday and what they are doing today on work that progresses the work defined for the sprint. Others may certainly attend and listen. Don't Any detailed discussion,  revisions of requirements,  changing of priorities,  changing of the backlog or any other decisions are not to be made in the daily standup. NOTE - If the information shared in the daily standup warrant detailed discussion, changes or decisions, that should happen in a subsequent sit-down meeting  with relevant participants  in which the PO should probably be an active participant.

Programming with Confidence:  unit tests increase your confidence about the code you are developing because the tests will clearly show if the changes you made caused the failure of some part of your code. This way you can fix the code, run the tests again, and if all pass, you can continue to work with the confidence that everything is still working properly. Continuous Integration of Code:  unit testing ensures that the new features developed didn’t cause side effects on the code that was already working, so you have more confidence that the new features developed are working properly and also that they did not harm other parts of the software that previously had been already checked and perhaps even validated. Better confidence on the quality of your code:  with unit testing, you are not only  supposing  that your code is working, but instead you are  sure about it , because when all your tests are passing you know that your system is behaving exactly the way you expect it

Technical proficiency -  automation can free the time of testers to do more exploration, which allows discovery.   Investigative curiosity Observational skills Communication skills Writing skills and bug advocacy Domain knowledge Willingness to learn Social skills Humor Practice "Testing is questioning a product in order to evaluate it . Software testing is about revealing the unknown." Source-  http://www.ebaytechblog.com/2013/01/31/becoming-a-world-class-tester/#.VTNlhNKeDGd http://java.dzone.com/articles/3-technical-skills-every

Jez Humble and Dave Farley defined the following principles in their Book “Continuous Delivery”: Repeatable reliable process  – use the same release process in all environments. If a feature or enhancement has to work through one process on the way into the integration find a way of popping up. Automate everything  – automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results. Version control everything  – code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon. “Bring the pain forward”  – deal with the hard stuff first. Time-consuming or error prone tasks should be dealt with as soon as you can. Once y

1.  Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. 2.  Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change. 3.  Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. 4.  End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust. 5.  Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs. 6.  Institute training on the job. 7.  Institute leadership. The aim of supervision should be to help people and machines and gadgets to do a bett

How should the software perform when the network is slow? How should the software perform when the network has 5% packet loss? How about 10% or 30%? If the software requires a persistent connection, what needs to happen when the user steps into an elevator, or when the device goes to sleep, or when the application is interrupted by a phone call? The standard screen resolution for smartphones is 320x300 pixels, but tablets are larger and next-generation mobile devices can support HD screens. What should the user see in all that extra white space? We integrate with Facebook, Twitter or Google login. What do we do when that service is down, and how can we test it? Source- http://searchsoftwarequality.techtarget.com/tip/Mobile-application-requirements-Same-process-new-challenges

Tips for Effective Ice-Breakers ·          Keep it simple. ·          Make it fun. ·          Be creative. ·          Consider various types of Ice-breakers--don't just stick to "questions." ·          Consider your audience. ·          Be aware of time constraints ·          Keep in mind technology requirements. Consider using an ice breaker when: ·          Participants come from different backgrounds. ·          People need to bond quickly so as to work towards a common goal. ·          Your team is newly formed. ·          The topics you are discussing are new or unfamiliar to many people involved. ·          As facilitator you need to get to know participants and have them know you better. Source-  https://twt.wikispaces.com/Ice-Breaker+Ideas  and  http://www.mindtools.com/pages/article/newLDR_76.htm

For sustainability, the team really should own and evolve their standards instead of them being handed a bible. The coding standards can and should change over time. The key is clarity, testability, extensibility and maintainability of the code itself.   It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one team member.  Pair programming is the best way to get consistent adherence to standards. The key is the discipline of unit testing and refactoring

http://scn.sap.com/community/design-thinking/blog/2013/05/10/design-thinking--so-what http://forty.co/value-balancing-desirability-feasibility-viability

- Programmers write more automated testes and focus on higher automated testing  - Manual testers are more focused on exploratory testing  - Documentation of BRS, FRS, Test Plans are totally reduced to a simple list of features with scenarios; i.e. BDD. This provides a common language that business users, programmers, testers can all understand share and collaborate on.  - Development Team is structured that programmer and testing skills are in the team.Instead team members pair up to both do development and testing in a highly iterative and incremental nature.  - Culturally the team succeeds when the work is done and meets the quality standards defined by the "Definition of Done". If something is wrong, all fail.  - Defects found in Sprint are actually not logged, but the developer / tester pair simply chat and fix it on the spot as the work to the Product Owner is not "Done" yet.  - Missing requirements are not bugs, but simply new requirements in th

A good TCM application should contain those fields and if not should allow for customization of fields.  It's a good idea to categorize the test cases down by Feature/Function  Test Case Template  Test Case ID:  Unique number that identifies the test. Allows to build library of unique test cases  Test Title/Summary:  A sentence summarizing the Test case  Objective/Goal:  What we expect to achieve with this test case  Description:  Multiline paragraph field that explains what the test case does and will perform in detail  Setup :  What is required to setup the test scenario? Could be bulleted list of setup steps, hardware/software required, lab resources required etc.?  Test Steps:   Bulleted Test steps; each step detailing exactly what step needs to be performed and how. Some companies have to comply with some Govt. regulations etc., in that instance each test step should have an expected result (Pass/Fail Criteria) and a signature field for validation. Certain critical

When to use Waterfall Methodology: Requirements are very well known Product definition is stable Technology is understood New version of an existing product Porting an existing product to a new platform. Weakness of Waterfall: All requirements must be fully specified upfront Deliverables created for each phase are considered frozen – inhibits flexibility Can give a false impression of progress Does not reflect problem-solving nature of software development – iterations of phases Integration is one big bang at the end Little opportunity for customer to preview the system (until it may be too late)

Strategy First  it should be clear about what your strategy for automation is. (And don't say Automate everything. The people who think you can automate everything are just as wrong as the people who think you can manually test everything. Automation can help, but you need to know its strengths and weaknesses.) Plan Secondly, you should decide what success might look like. Most teams will do a lot better if they try to achieve something close to the testing pyramid , that being where developers write a lot of unit tests and specific integration tests with dependencies, and then a combination of devs/testers write service level, and API tests, but in a smaller proportion. lastly any UI should probably be kept small and focused on critical areas of the software (because they are so slow). Implement Another thing you should consider, is that automation efforts slow down, the further from the code it actually tests it is to develop. This means that while your testers may be pur

What is a User Story?  Simply put, written from the context of the user as a simple statement about their feature need. They should generally have this format. "As a -role-, I want -goal/desire- so that -benefit-" How is a User Story different than a Use Case?  While a use case is highly structured and tells a story, the User Story sets the stage by stating the need. A User Story is the prelude to the use case by stating the need before the use case tells the story. How does the User Story fit into the process?   User Stories are great as an activity in collecting and prioritizing the high level features. Getting this initial feedback from the customer is a simple way of trying to get all of their needs identified and prioritized. The User Stories will then morph themselves into the   business requirements   and use cases. USE CASE Template-  Use Case Element Description Use Case Number ID to represent your use case Application What system or applica