Software the Agile Way....

Agile manifesto clearly says give more value to Individuals and Interaction than to process and tools. This means there can be occasions while building product/feature we come across change sometimes small enough (Remember, in a software development phase it is very much possible to get changes) that could be easily absorbed in a sprint but if team says we need to prioritize this in next sprint as this is a change and should be followed as a process then we really need to rethink on this. Scrum is a lightweight framework and this clearly means we should try to avoid too much of process. This "we" includes  Product owner,Team. When a change need to be accommodated within the sprint then team should see if this impacts overall plan for the sprint, if yes just talk to PO and negotiate with some low priority work. if no then they should just implement instead of wasting efforts in following process. And at the same Product owner should try to think through the solu...

Issue - While the concept of User story is now quite old but still there are still cases where we see the stories are incomplete and not having enough details which would make team feel confident. Possible Cause of the Issue - Reason for such issue could be due to the culture change. With Agile culture, documents are converted into discussions and Product/business feel that details are not required for documented as this is already discussed in the team meeting. And this will remain in either emails or with some people with whom it was discussed.  Another reason is that it takes time to understand and clarify the requirements queries coming from team by the product/business who are not exactly the user rather some documenting people whose job is to write stories. Tips to handle such issues  - To handle issues with culture, I would advise to listen to team and collaborate with team. It is very much important to understand what team wants. Documenting details would ...

It has been always asked what is a typical day look like for Scrum Master and I would say it is not the same every day. Here's why: Lets say it is 2 weeks sprint then during the first day SM is busy facilitating the Sprint planning and ensuring the team members have committed the stories which they find it fully confident. 2nd day onwards, SM is talking to PO to ensure the for the coming backlog refinement/grooming meeting there is clear requirement defined with clear expectations. SM is lucky if he/she has knowledgeable PO who not only understands the Scrum but also understand why it is so important to have clear requirement defined. This can give SM to sit relaxed, however if this is not the case then SM's most of the time goes in coaching PO and impractical world it is dependent on the person who is playing the PO's role. lets say during backlog grooming meeting, we discussed some requirement which is understood and some which have gaps identified by team then ...

Who needs to prioritize? In a typical project execution we have several roles who participate in making things happen. In a scrum framework we have Product owner, Scrum Master, development team  All these roles have a common goal which is to make project a success.But what does success mean is defined by customer and her needs/wants/desires.  Hence it is very much important for Product owner to first prioritize what will help her first. The same prioritization can be translated to Team and Scrum Master.  Hence the answer is Prioritization is for everyone however team can influence PO in making the right decision.  How to  prioritize? There is no magic formula for prioritization, though there are techniques like MOSCOW rule  but i have noticed for customer everything is MUST HAVE. This will not help customer as it would lead to a wrong product which may not help customer. Remember 80/20 rule, 80 perc of the user use 20per...

While Scrum Guide clearly mentions what Product Owner role is and what is expected. But in the real life projects, there are number of cases where Product owner role is not played as per the expectations. Why? There can be many reasons to it but the prominent is budget constraint to companies. Due to which PO is given at a time 3-4 projects to work on. While this may be working in some cases but in most cases this scenario never works and gives bad results. Ideally,  PO need to focus on a single product backlog by continuous conversations with stakeholders, Users and SMEs and translate the most clear defined requirement to team for development. But this never happens, PO gets the requirement and do not have time to analyze so the half cooked requirement is explained to team and more conversations are happening without any constructive results. here's what needs to be done to correct it: PO need to be sure of "what User wants vs What User Needs"  PO m...

These days Agile word is quite popular  and many companies are adopting the principles of Agile however there are companies who start well but soon find difficulty in implementing scrum. There can be many reasons to it 1) Top management feels that team is taking advantage of Scrum process and not delivering the business value which is expected. Team may be questioning a lot in terms of priority and clear product backlog. And for some top management everything is MUST and they feel that why cant team work on all the priority items and deliver the maximum productivity. 2) Another reason could be that Top management do not have enough resource (RIGHT people) to play the scrum roles hence they expect people to play multiple roles which in turn creates a lot of other issues which top management does not realize. 3) finally top management think they are losing control over team and they need to follow what team says. They can't direct team and push them to do what they want. W...

I am often told by people who are senior to me to challenge the team and increase the productivity. After all we are in business and if we deliver more than we will in good shape. This s true to some extent as we are ultimately human beings and require some sort of push/motivation to continuously deliver more. I would address this in 2 different ways: A team that is self organized, disciplined,hard working and consistently performing then I would suggest to act as a friend and constantly ask this question " How can we improve" Let the response comes from them. It may be possible that team is doing their best however team may come up with certain areas of improvement. See as a Scrum Master if you can help them. A team which is in its initial stage and may not realize the areas of improvement on their own. In such cases I suggest to act as a coach and keep sharing the best practices with them. The little areas of improvement can change the team to the next level and b...

Why Scrum is easy to understand because: It does not talk anything new. We are still talking about software development lifecycle phases. We have clearly defined roles here with their responsibilities. Simple to understand ceremonies. Ceremonies have clear objectives defined.  but it is difficult to master because: Roles described do not follow as per the definition,  Ceremonies are happening but are not productive, not timeboxed. People still have difficulty in understanding the ceremonies within Scrum we follow mini waterfall Management do not value much on coaching and cultural change People do not understand that it is lightweight  so what must be done to master Scrum: Deploy the RIGHT people in the roles defined. Management should be committed to follow Scrum and they should get the coaching first.

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 ...

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 ...

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?

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...

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 mar...

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

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 formulat...

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...

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