Software the Agile Way....

Even though  Scrum Guide   clearly defines the roles and responsibility of Scrum Master despite this in practical situations there are multiple activities where a Scrum Master need to get involved. This sometimes makes things difficult for a Scrum Master. This means Scrum master has to deal with all types of situations if the team is not self organized and not practiced Scrum for a long time. Some of them are: Behavioral issues,  Not having enough backlog for coming sprints,  dependencies with external teams Required people not available during a scrum events leading to reschedule of the scrum event Skill set issue ( from PO or Team) leading to spill over Conflicts within the team members action items follow up Blockers like environment down Scrum Master managing 2-3 scrum teams (which are not self organized) will have to face these issues quite frequently which may lead to scrum master's backlog becoming too big which ultimately will be unorganized a...

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

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

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?

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

Step 1: Identify the Problem Step 2: Work Out the Major Factors Involved Step 3: Identify Possible Causes Step 4: Analyze Your Diagram Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. http://www.mindtools.com/pages/article/newTMC_03.htm http://www.techrepublic.com/blog/tech-decision-maker/create-fishbone-diagrams-with-the-xmind-open-source-tool/

TFS infrastucture  For PROD, you may like to have Nightly Builds, for Development you want to have a build triggered at every check-in and so on…  These builds require a build server.  You can use 1 build server for all the builds or you can have a separate build server for each Repository, or you can share build server between 2 repositories. The decision to use one-build server or more depends on the peak-load, expected build queue, h/w infrastructure and a lot of other parameters.  If you do not want build services, you do not need to configure a build server at all. http://www.codetails.com/2013/11/23/team-foundation-server-understanding-the-architecture/   Set Up a Dedicated Build Server Installs the build service on the team's build server Set Up the Drop Folders A folder where the Team Foundation build service can drop the builds. Give the folder permissions to the server that runs the build service Create the Continuous-Integ...

The SM should NEVER tell the team what to do but rather facilitate with Asking why? Did this work for you? What do you think? Have you thought about? It sucks to be you, what are you going to do to change it? The team must learn to see their failures and recognize them early. This is the principal of fail fast. Jeffrey Sutherland prefers weekly sprints to allow fast failures and quick adaptation to issues. To reaffirm, the SM should not make decisions for the team, but instead help the team make the right decision. The SM must also create a safe environment allowing the team to fail, Fail fast and fail safely.