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.
Continuous Delivery – Continuous Integration
Part of the reason why the traditional ways of developing software for customers has failed is because of they weren’t getting what they wanted or needed in time. Customers realized that the deliverable isn’t exactly what they needed or wanted and that too after spending significant amount of money.
What am trying to explain thru this blog is by decoupling various jargon used in Agile conversations.
Continuous Delivery is what the customers or stakeholders expect. For this to happen we need to develop software in small chunks. [why – because large chunks take time and that is not what we are talking about] Next – when you develop software in smaller chunks in short windows of opportunity (sprints – scrum/ iteration – XP) we need to have a Continuous Integration. What happens here is we test [Unit and Regression] smaller chunks by integration to the master code base and keep the software ready for release. The defects of course have to be fixed before we release the software to production for customer usage.
For the above to happen regularly and seamlessly – the following are extremely (cannot emphasize more…) important to have in place.
- Simple architecture, design, coding principles – to make changes easily
- Automated Test Scripts ready to test the code continuously – no scope of escaped defects
- Customer Collaboration – Stand-ups to Demos to Review to Backlog prioritization
- Transparency – If there is risk of any sort, should be brought to attention of pretty much everyone [customer, development team, stakeholders, entire project group]
- Knowledge Sharing – very essential for the team to keep sharing knowledge – technical, functional. Again documentation is required for quick references but barely sufficient.
To conclude – nothing in agile is long term. We keep experimenting new ideas, stuff, reflect and adapt to new trends in “how we do things”.
Scrum Ceremonies execution for a Large group of people
After a decent thought, i decided that why shouldn’t I write about that way I contributed to the agile transformation in my current client. I wanted to talk about the challenges, opportunities, workarounds we as a team reap benefits from agiles/scrum framework.
The context here is running agile for a large group of people who are divided in several teams. We tried our best to and then kept the count of each team in control but we ended up having a little more than the what is considered to be a perfect count of an agile team. Also the members of the group come from various functional backgrounds like Development, Testing, Service Delivery, Business Analysis, Project and Product management
- Daily Standups – This was my challenge right of the bat. On one hand i had the rule for myself that i should run the standup for more than 15 mins and on the other hand i had to ensure the every team is given an opportunity to talk about 3 important things covered during standup. a) what have i done yesterday b) what will i do today c) are there any roadblocks that impede progress. Initially i failed to tie all ends, but over a period of time after trying several options/attempts i succeeded in tying all ends. Since I know that the people who attend the meetings are from various functional backgrounds we decided to go by the development first, testing, service delivery and business analysts. This way we ensured that we complete our standup in precisely 15 mins.
- Story Grooming and backlog prioritization – The Project/product that we belong to from customer service background so there are many business groups who send requests to us to have their functionality, data, feature hosted on our platform. So after all the intake/demand/delivery discussions are done the Product management group comes with the list of approved or prioritized projects list. That is the demand or in short very high-level projects or epics. As a first step our Business Analysts would create the epics and stories under each epic and create a high-level backlog. Initially we followed a schedule of doing 2 – 2 hour sessions per week of story grooming but over a period of time we didn’t create enough stories for the development team to take up work for each sprint. We were always behind the expected backlog considered the teams velocity. Then we use to have a 2 hour user story grooming each day for about a week and come up with the product backlog items. This way we created a separate bucket of time in each release to ensure we are DONE with backlog creation before we start our functional sprints.
- Sprint Review/Product Demo – Given those many business groups or customers who wanted to see their functionality, features in our product, having them all sit in one demo in like 2 hour meeting in a single day was next to impossible. We had challenges from logistical angle, meeting schedule etc., Though we had our internal mini demos/reviews whenever the sprint backlog was DONE or not DONE or partially done, to me the critical review/demo was when i scheduled consecutive 2 or 3 day session inviting all stakeholders to the demo either the end of sprint OR release. That way we strived a fine balance between customer/stakeholder satisfaction and sticking onto having a review/demo ceremony once at the end of each sprint
- Sprint Retrospective – Given the no of people in each development team it posed a challenge to me that the most important ceremony of all to reflect and adapt [Retrospective] doesn’t carry the value or momentum it provides to the team. So i split this ceremony into 2 groups. I had a Retrospective meeting once every sprint where people from development groups are invited and contribute and then I had a another group of people who are mainly the functional managers of the people of first group. Though this may not be a not so effective or standard way of running Sprints but given all constraints to me this sounded the balanced way. Bottom-line this worked and we had satisfaction from everyone involved in the Project.
Continue reading Challenges and Workarounds in Agile Journey
Decision making in Agile Transformation
One of the key elements during Agile transformation is about having your employees participate or totally own the decision making at the product feature or functionality requirements. Specially when they have spent many years in Business Analysis or Design products.
During the Agile boot camp the leadership teams must train people about the key business priorities and metrics on what makes the product success which makes the business a success. Dont hold them back or not add the “yes you are allowed to take decisions” to their job role during transformation.
By not doing so, you are not only not following the Agile principles but also not creating transparency and having employees to reach out to management for every decision which could hurt the time factor which is critical.
The only key metric or deliverable is the Continuous Integration OR Continuous Delivery that makes end users engaged in the business
Beyond, each organization anyway will have performance measurement or people evaluation methods each year or at some point that way the organizations will be able to assess if the allowed decision making power is working OR any imporvements or reassessments to be made.
Email communication in the modern corporate or business environments –
Email writing in the modern day corporate world has certainly changed. With offices spread globally, large teams, multi cultural teams, increased customer expectations, 24/7 information exchange, high end infrastructure, enhanced transparency, service level agreements etc., have added to “how exactly an email or communication has be drafted and sent to the intended recipients”.
Based on my experience the following have to be given most importance while drafting email –
- Include recipients who are precisely need the information are included in the To list. Avoid a thought that this person may need or should be kept in the loop unless you are not escalating any issue that has gone beyond a certain stage
- Unlike a conservative approach or too diplomatic directly get into the subject may be from second or third line. If the recipient has no prior background or the context of the subject you are talking, please make use of the first 2 lines to quickly mention about the subject and then get into the detail
- Do not beat around the bush – get right into the detail why are you sending this email and that too today (now). Your perspective, any data or statistics you have for the recipient to read thru and understand better. Remember “Data” than “opinion” always carry more weight
- Note that avoid paragraphs of email body unless you are writing a newsletter which is not considered email at all. People in the modern day corporate environment are ALREADY overloaded with data from various devices, contexts, people etc., so your email should carry enough relevance for the recipient to read, understand and do something about it. Crisp communication is all we need
- In my experience of dealing with superiors or people that i report to or stakeholders have always asked one question- “what do you expect me to do” or “what should i do” or “what do you need from me”. This always told me that the next time i go to them or send email – I MUST tell them something that spurs their action about the subject. Now that doesn’t mean they will immediately taken some action but it helps to be more directive or draw out their action or helps them to think in terms what you expect them to do or dont.
Ensure your email is always goes first before you go to them directly to talk about a subject. Email always gives the recipient opportunity to read, understand and be ready with the context before you setup meeting with them or go meet them in their office directly.
One of the essential and fundamental elements why Scrum is becoming very important is that when the team sits together to discuss and groom the stories, is because of the grooming and tasking of efforts.
When the product owner or manager brings the intent and create a high level user stories, the team does detailed study of the story in understanding the value that feature or functionality brings to the user and starts writing the tasks to be done to meet or build the end user functionality.
A Scrum Master has to enable the team to write the story and detailed tasks required. This is important because each day when the team comes to work they should not squander around OR search OR go back to drawing board as to what needs to be done. Ideally the team member open the agile tool > go to the user story > read the tasks > start working on each task by task. This way its a total heads down approach to crank thru the work required of the sprint and provide the required user functionality by the end of the sprint.
To conclude, it is extremely important that the entire team understands this way of story grooming is must and should, otherwise the daily stand up calls or any other adhoc meetings happen during the sprint will not yield any value and simply Agile wont work.
Qualities of a Good Scrum Master
Servant Leader - An empathetic listener and healer. This self-aware steward is committed to the growth of people
Coach - Can Coach the other team members on how to use Scrum in the most effective manner
Framework Champion - Is an expert on how Scrum works and how it should be applied
Problem Solver - Protects the team from organizational disruptions or internal distractions or helps remove them
Facilitator - Neutral participant who helps group of people understand their common objectives and assists them to achieve these objectives
Qualities of a Bad Scrum Master
Boss - Has the ability to hire and fire others
Task Master - Myopically focused on assigning and tracking of progress against tasks
Product Manager - Responsible for managing schedule, budget and scope of the product
Apathetic - Lacks interest in or concern about emotional, social, or spiritual well being of others
Performance Reviewer - Responsible for documenting and evaluating job performance