Monday, July 28, 2014

Agile - Scrum Implementation - Grass is certainly greener on your side


Moving from a traditional development life cycle to Agile is like quitting smoking, you know it is good for you but at times the temptation to fall back on the old ways is too strong. This article is mainly intended for newly minted Scrum Masters or for people who are looking forward to implement it effectively in their projects. Yes, a cursory glance with feedback from the Agile gurus and experts will also be appreciated. 

Agile Manifesto : 
Before we start , lets have a look at the Agile Manifesto . Following are the four main points of the manifesto
-Individuals and Interactions over processes and tools
-Working Software over comprehensive documentation
-Customer Collaboration over contract negotiation
-Responding to Change over following a plan

"That is , while there is value in the items on the right, we value the items on the left more"

These simple elegant looking words mentioned above can be deceptive in nature when it comes to practicing them,will explain the manifesto in detail later in the post.

By now,many of you may have perceived it as just another "shout it aloud Agile" post and probably would be thinking of utilizing your time in some better article. Probably something more flashy , creative , dynamic lauding author's prowess as a blogger.
But if you are still here ,  following could be the reasons:
-Your willingness to know the Subject -Agile-Scrum Implementation
-Your willingness to implement it
-If already implemented the your willingness to correct it

I am not sure about  what kind of management support , or what kind of knowledge your team has for Agile-Scrum implementation  , however the good part is you have the will, right intentions to embrace the change and the best part is probably you don't have the in house skills and support on it.
The challenges that you face now while implementing Agile-Scrum in your new project would help you to understand some key concepts that people with experience and expertise on it often fail to.

As per my knowledge and experience following should be the order of Implementation :
-Get your Product Backlog ready : Arrange the requirements in the form of user stories with the priority ones on the top .This will give you an idea about first things first, you can either use excel or any open source/ low budget test management tool for it.
-Set up the sprint length (2-4 weeks) : Sprint length is dependent on agility of the team, frequency of changes and the technical complexity of the project. There is no hard and fast rule for choosing one , however the chosen one should remain same for the entire release.
-Start with basic formal Scrum ceremonies i.e.Sprint Planning, Stand Up , Sprint Review and Sprint Retrospective , you may perform the ones like Estimation and Sizing and Backlog refinement informally for now. Once you get a hang of things , you can start performing the other ones formally too.
-Get a certified Scrum coach or master involved to train the Scrum team, facilitate the ceremonies and maximize the productivity by taking care of Unforeseen impediments.However if the option is just not viable , you may go through some very helpful videos/articles that are readily available over internet.
-Plan your sprint once the refined Product backlog is ready ,by pulling the priority items from the Product backlog to the Sprint backlog. Please keep in mind one very important fundamental of Agile Manifesto while planning the sprint - "Working Software over comprehensive documentation " . Plan your sprint in a such a way that you have something to demo to the Product Owner and other stake holders at the end of the Sprint in Sprint Review Meeting .
-Stand up Meetings :Once you have the Sprint backlog ready , please start the Sprint.Use daily Stand up Meetings to check the health of the sprint and discuss impediments if any.Involve the Product Owner in it so that the team can clarify any doubts. Please keep in mind important fundamental of Agile Manifesto-"Individual and Interactions over processes and tools" . If you are not using any tool please use a white board as your team's Collaboration Hub. Mark up five columns on it - Sprint Backlog, Tasks to Do, Work in Progress, QA Ready and Done. Use Post it stickies describing the requirements on the white board.Apart from it Use daily Burndown Chart to track the progress.
Many projects that have elaborate project plans with detailed Gantt charts have failed. We make the plans so complex and detailed that they're difficult to modify when changes occur. Agile process replaces project plans with release schedules and burn-down charts that can accommodate change. Another Agile Manifesto fundamental comes into picture here- "Responding to change over following a plan"
- Use Sprint Review Meeting to showcase what you have accomplished during the sprint. Typically this takes the form of a demo of the new features. Feedback from the customer and all the other stakeholders are taken . Agile welcomes changing requirements , even late in development. Agile process harness change for the customer's competitive advantage. We practice "Customer Collaboration over contract negotiation " principle of Agile Manifesto here.
- Use Sprint Retrospective to find ways to improve in future sprints.

There is so much to write on Scrum Implementation , I hope the above points can at least get you started on it or if already started can help you in improving the things.One last thing that i would like to caution you against is the temptation that may arise to fall back on to half agile/waterfall kind of methodology due to initial Sprint failures. Congratulate yourself if your initial 1-2 sprint fails as those failures would eventually prove to be the stepping stones of the grand success lying in the bright future.
You may think grass is greener on the other side but if you take the time and put the efforts to water your own grass, it would be as greener.

Monday, July 21, 2014

Futurespective - Predicting the Unpredectible



Apart from the regular Scrum ceremonies - Sprint Planning and Commitment, Daily Stand up, Sprint Review and Sprint Retrospective , a new one has emerged that has proved to be quite effective for ensuring higher productivity across the future sprints.

Futurespective - It is a powerful technique that uses the concepts of Retrospective to make the future better. The idea is simple. Think of your new project and mentally take the team to the final deadline. Assume the project has been a miserable failure, brainstorm about what happened on the project to make it fail thinking of People, Organization, Systems, Processes, Facilities and Logistics and put all ideas up on a flip chart. Now look at all of the things that have been written down as a team. Ask them to vote to determine which of these are starting to happen (e.g. poor communications with Product Owner) in the current project. At the end of the session you'll have a list of priority actions that you should take now to resolve the problems that haven't happened yet. It is like taking a mythical Sprint Plan and then thinking of ways to make it fail.
During this exercise team asks themselves two questions:
 Assume this Sprint is a complete failure, and based on what we've committed to deliver, what are we going to do on this Sprint to make that happen?
 What actions can we take now to stop that happening and make our Sprint successful

Future-spectives help the team to establish practices and collaboration patterns early on that transforms a group of individuals to a real team faster.
This is more of a forward approach than backwards , it is more positive where the team can work together in advance to avoid problems. As a result the team feels more in control and is far more likely to put ideas into actions.