Software the Agile Way....

While working in an Scrum projects, I have experienced that there is a need to have a continuous learning approach. In a complex project environment, we face issues/impediments on a daily basis which is quite possible if there are dependencies across many teams.In such case, though Scrum master and team need to continuously resolve issues but at the same time we need to pause and think on how can we prevent the issues to occur. If Scrum master coaches the team to become proactive then there are high chances we can reduce a lot of issues to occur. What is a proactive approach...an example would be team on the very first 2-3 days of sprint start, is able to start conversation around the dependencies and possible issues. Scrum Master need to encourage such thoughts so as to make the sprint smooth. additionally collaboration with product owner is required here so that a shared understanding is built. By practising this, everyone is continuously learning about the people,process and te...

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.

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.