Software the Agile Way....

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

Comparing to other Scrum Meetings, Sprint retrospection meeting is sometimes considered boring by the Scrum Teams. Team do not find much value in participating in this meeting. What could be cause of such feelings. Sometimes this becomes repetitive and same issues/pointers are discussed. SM need to think over it. I advise the Scrum Master to follow the below mentioned pointers to make retrospective meeting effective: 1) This is a place for team to talk about the people, process, relationships and tools which are delicate matters as there are chances team members start pointing fingers to one another for the failure. SM master need to avoid such discussion to popup. Lets keep this meeting healthy. Note it down and discuss it later with the concerned member. 2) See all the team members are getting the opportunity to talk and share their thoughts on the sprint.  3) This meeting to thank to all the people who helped during sprint execution. There could be dependencies ...

One of the Agile Manifesto principle says " Individual and interactions over process and tools " this needs to be practised on a daily basis to make it a habit. In a team, you can have team members of different behaviour, some talk less, some talk more and some try to hide their feelings. In such situations, it is the responsibility of Scrum Master to ensure team members are talking to each other and the conversations are happening. Scrum Master can do this by having casual, informal conversation and this would help team to collaborate often and this could minimize the issues. Encourage face to face conversation if possible. Another very important responsibility of Scrum master is to promote discussions which requires attention from other team members. Most of the project fails due to communication issues hence this principle must be taken very seriously and scrum master need to keep innovating the ways of handling this! How do you want to promote this principle...

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.

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

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

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

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?

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.