Agile is becoming important in the IT field. But, what is the importance of agile certification? Adding a certification to your resume has been always appreciable. But the industry looks for candidates who can really apply agile. A certification implies that the candidate has some experience in this field. Moreover, it is easier to work with the team with an Agile professional, because team members will pay more heed to an expert. Read more about it in the article written by Sharon Florentine (writer at CIO.com) at:  http://www.cio.com/article/3033058/careers-staffing/do-agile-certifications-mean-anything.html

There is a significant shift that has happened in companies from waterfall methodology to agile methodology. Story cards are developed and bundled in milestones. Milestones are great in measuring the progress and determining the scope of the project. Milestones need not to be always set in a fixed time manner like monthly or quarterly. Often gaps are created in milestones to do other projects. A rhythm that can be set up for every Monday is a good option because it will help in getting small incremental changes that will help implementation team. But some point of time weekly cycle appears to be very fast. It is very necessary to determine that what is really feasible to achieve for the team. Read the full article here: http://it.toolbox.com/blogs/original-thinking/how-fast-does-your-agile-sprint-71351

There is a prediction that by 2017, 33% of Fortune 100 companies will experience information crises due to lack of adequate testing measures. To prevent this, the robust testing approach must be used. Developing a well-planned data warehousing, testing process will help in minimizing such risks. And while moving to agile, we can do more testing in comparison to traditional projects. The testing being done during development in parallel aids to agile development, because development and testing can be completed in a single sprint. The roadmap for building agile data warehouse will consist of following steps-

·         Build business conceptual model

·         Grass roots Data governance

·         High-level architecture with repeatable design patterns

·         Strong testing tools

·         Robust data quality program

·          Self-managing teams.

Read the full article here http://www.cio.com/article/3012097/data-warehousing/take-testing-seriously.html

I found this interesting article which described transformation to Agile using a metaphor of the train's journey. Source and destination points are described as process initiation phase and successful completion of the process. An agile coach is the driver of the train which leads the transition. This approach made sure that Agile coaches were available at the right time and helped coaches transforming 800-900 individuals per year with the help of 10 agile coaches. There were certain steps followed by each team- Agile introduction workshop, Management Start-up, Training and Start-up, Warm-up, Ongoing support, and evaluation. But this metaphor was used in the starting days of Agile. In the present time, we need something faster than a train. So, how about a racing car? Why? Because, it’s fast and will help the team in understanding the need to respond rapidly to changes. Read more at: : https://www.scrumalliance.org/community/articles/2016/january/travelling-without-moving

Yes! Agile is for everyone, not just for IT industry, though it has become a misconception because it is majorly implemented in IT world only. Let's just understand what is agile. Agile is a framework which helps in problem solving with use of teamwork, with main focus and priority for delivery and a constant effort on finding ways to improve the quality of work and the product.  So this can apply whether you are building software, a toothpaste, a dam, or managing a restaurant. There are some things which surely must be kept in mind while considering a shift to agile. Like, what am I really trying to build or achieve? How do I create a creative environment where the right people on the team? How to keep focused on the agenda? How do I measure progress? How to increase feedback and learning cycle? If you can answer these questions considering your business, then, welcome to the agile world! Read more at - https://adtmag.com/articles/2015/07/06/does-agile-apply-to-you.aspx

We often get placed or appointed for roles which we don’t want to pursue after few years but it’s not so easy to change the line of course. For example, if you are part of the technical team, it is not easy for you to switch to the managerial team. But the organizations must understand that rather than appointing people to work or designating work, they sometimes should create vacuum holes. By vacuum holes, I mean an opportunity which is open to all to work on. But then this might create a problem that everyone would want to work in some profile which they love and the actual work which is to be done will lose its priority. So the company should make policies to balance the two things. For example in Google, an employee can invest 20% of his/her work hours to do something he/she likes to do. So rather than appointing work, companies should create a vacuum and should see who steps up to fill it in.  Read the complete article by Mike Cohn (Founder of Mountain Goat Software) at: https://www.mountaingoatsoftware.com/blog/leave-work-unassigned-and-see-who-steps-forward

Interviewing a ScrumMaster is pretty much similar to interviewing any other employee but there are certain attributes which must not be neglected. They are :

• ·         Responsible: Its Scrummaster’s responsibility to bring the best out of each team member.
• ·         Humble: ScrumMaster must work with “we” ideology rather than “I”
• ·         Collaborative: SrumMaster must ensure a collaborative environment where anybody can raise questions.
• ·         Committed: ScumMaster must be committed to success of the project
• ·         Influential: ScrumMaster leads the team without direct authority, so they must be influential.
• ·         Knowledgeable: having the knowledge of the domain or the project is a big plus

To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/advice-for-interviewing-scrummasters

Two main goals of Agile Sprint are building new functionality and building new knowledge. Building new functionality seems obvious for sprints, but teams also need to focus on building knowledge.  Each sprint should end smartly from its inception.  A UI designer should focus on both of these goals. Within a sprint, a UI designer helps in coding and testing of his/her design while simultaneously, he/she focuses on the next design feature to be built. A UI designer's top priority should be working in the current sprint. If a developer or tester needs any clarification regarding the design than he/ she should immediately halt the work and attend to their queries. But then one might say that every member of the team does so. Be its analysts, architects, database designers. The difference lies in the amount. Designers spend majority of time in building knowledge. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/incorporating-ui-design-in-scrum-sprints

Generally, product owners' role is to tell WHAT TO BUILD instead of HOW TO BUILD it. But there are some situations when product owner must specify some architectural decisions. Let's consider a scenario, years ago; when Sun was looking for the ways to promote Java, they paid companies who made certain applications using Java. But, such decisions should not be taken regularly. Product owner can decide what hardware pieces to be used to make the product economically viable. So product owner can dictate architectural decisions, but they should take good care and should make decisions sparingly, wisely and ideally. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/can-a-product-owner-dictate-the-architecture

Agile teams must embrace change. After all, that is what agile means, right? Accommodating changing customer's requirement… But the stakeholders or customers must also understand that nothing comes for free in the world. So are changes. They have a cost related to them. Scrum works on a rule that once the required changes are fully stated, a sprint begins. And no changes are allowed into a sprint. Once a sprint is started, it’s not disturbed and the team’s entire focus is on selected work. This is good and works efficiently, but can sometimes backfire. The customer can question that the foundation of being agile is to welcome changing requirements. Well, yes, but they aren’t free. Customers must understand that changes introduced beyond a certain point have a cost related to them. And both the customers and organization should work together to optimize results with the minimum cost.To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/change-isnt-free

Every project starts with a Software requirement Specification (SRS) document, but somewhere in the middle a decision to adopt agile methods is made. So the question arises whether an SRS can serve as agile's product backlog? Let's find out. An SRS is a document with all the direct or indirect requirements of the system are listed. It generally has statements like "The system shall.."

Whereas product backlog serves two purposes: 1. It lists the work that is to be done and 2. It prioritizes the work to be done. It is different with the SRS in the sense that SRS only tells about what work which is to be done, not the priorities. So just for the sake of adopting agile, SRS should not be mixed with user stories, instead a product backlog should be created which will serve the purpose well. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/can-a-traditional-srs-be-converted-into-user-stories#

There is a misconception about agile model with teams across the world. They create an iterative waterfall model and call it agile. In a traditional waterfall development, analysis of the entire project is done first, followed by design for the entire project, followed by coding and testing. In iterative waterfall, the same approach is followed, but each story is treated as a mini project. They do the analysis for one story followed by design, coding, and testing. This is not agile. They confuse both the model because they thrive to build an agile model without exactly considering its meaning. The incorporation of user stories, or treating it as short placeholders for future conversations; each story becomes a mini-specification document. Ideally, in an agile model, all types of work would finish exactly at the same time, be it analysis, design, coding or testing. It is not always possible to achieve this, but it should become team's goal. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile