Agile Truth

Organizations who start on a good note to transition to Agile should not lose focus and sight of the journey. It is very important that people talk, listen to each other and repeat the same thing over and over again to ensure that there is a common understanding. One thing that i fail to understand is why does organizations fail to set the tone at the beginning of this journey. It is very important for leadership message the agile vision and mission to pretty much everyone about the end goal though there is no end goal in Agile but am talking about the journey itself. We will need to use the middle and junior management folks to carry that message across all teams corner to corner. Even handhold teams at time of crisis and when help is needed.

Understanding where you wanted to start, how to travel the journey and where to end up discussion is extremely important. If not between all but at the division level, department level. The ambition, effort and resolve have to pure and not political. 

Importantly enough, people should not try out pretty much anything by using the name of Agile. Of-course one of the fundamental or pillars of Agile continuous improvement but do you even know whats your target or end goal. Have an agenda to follow up iteration after iteration, measure the result everyday, check where did you end up after the iteration and retrospect, introspect. If I sound like a religious preacher, so be it. I took this Agile path few years back and I want to be religious enough to practice what i preach and what i learnt as basics of modern day development approaches. 

Have a resolve, establish your approach, take your time, don't be in a rush, it is OK if you fail but ensure you fail early. Most importantly take your customer into confidence which to me is the most important element of your agenda. Maintain the communication, the transparency, discuss hurdles, challenges and do everything to overcome those and ultimately am 100% sure you will win and keep winning.

                                                           ####

Agile Myth – Day After Sprint Review/Planning

Day after sprint planning/review – one of the myth of Agile

It is true that in “being Agile” you will need to make progress each day of the sprint to ensure we are meeting sprint goals. While that is true – the day after sprint planning/review may not have anything solid from the team to talk about. we know that everyday during the standup the team answers the 3 questions – what did I do yesterday, what will I do today, roadblocks if any. So in this scenario for the first question what did you do yesterday may not yield any answer or status or update – THAT IS ABSOLUTELY OK! 

Being Agile means that we are being realistic, true to our situation and transparent. The portion of myth is – just because we have to progress each day with some achievement, doesn’t mean that everyday we will have something for every question. Somebody from business, management or any stakeholder observing that a team member didn’t answer anything for first question [what did I do yesterday] doesn’t mean that we are NOT agile. Specially when the team has spent 4 hours just the day before in going thru the entire product backlog, story by story tasking out each story, checking the velocity and brought a set of stories into the sprint.

Who is a Business Analyst

Business Analyst

Imagine you go to a Restaurant. Sit at a table and you see a person walking towards you and hands you over the menu, gives you few minutes to read and understand what you want to eat. A little later, he comes back and takes your order and before he does that he answers any questions you may have or in case you want a custom made just for you, he checks with that the chef inside and confirms if its possible or not. Finally you order arrives, you eat it, pay the bill and leave.

Pretty much the same happens in a software business that for every customer there is a assigned Business Analyst who spends enormous hours with the customer to understand, elicit, document requirements. Take those to the development team and gets the software developed and delivers to the customer.

There are few add-ons that one needs to note –

Domain – Imagine a steward working in Chinese restaurant moves to work in a american restaurant OR the other way around. This is called Domain expertise. Steward from Chinese place has that specific domain expertise compared to the one who is from American restaurant. In software business as well there are domain experts like Retail, Manufacturing, Pharma, Sales, IT, Financial etc.,

Documentation – the menu can be compared to the company profile, software and services, products that are ready off the shelf or made to order. Across domains customers are looking for more customized software. The BA uses various documentation to track these that are used as references or guide while the actual solution is built.

Communication, Stakeholder, Risk and Project Management are few more areas that the BA should be hands on during the entire development duration. These help the BA to be on top of the job and ensure the product or solution developed meet the customer requirements 100% and the company’s reputation in the market gets better.