Software the Agile Way....

We all know it is people and technology which is accountable to deliver a software project successfully but how they deliver the project. How people get together and how they interact to ensure the project goal is understood by them and they are on track to deliver the same. Lets imagine there is no well established process and we need to deliver a project which is large sized and can be estimated to be 1 year or more involving 30-40 people. How is this achievable. Software projects are dynamic in nature and what customer is asking today may no longer be valid tomorrow then in such situation what is needed to ensure project is on track and will be delivered as per customer expectation. In the absence of any well established process, organization will have to rely on people for the project delivery. It requires a huge motivation in people to use technology and consistently work towards the  project goal to deliver on time on schedule and on budget. This can create communication...

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

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

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?

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

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