My Blog is moved to https://unthinking.org/
Krishna
9:10:00 PM
Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts
Monday, March 23, 2020
How to manage teams remotely
Krishna
12:45:00 AM
With the whole world coming to a standstill due to corona, many responsible organisations have declared work from home for their employees. Unlike the challenge of managing projects across geography, this situation is unique, where each team member is working remotely from their homes and each of them would have their own challenges and distractions. If you are a project manager or a program manager, here are some tips on how you can manage your project’s remotely
1. Setup a recurring online standup meeting. This could be the same as what you used to do in office, except that people are joining remotely and your standup time may go a little longer than earlier. Initially you could have one in the morning and another at the end of day, to assess the progress. You may need the two standup, at least initially, unless your team members are used to regular WFH. Google hangout is a useful tool to collaborate
2. Have clear communications, by that I mean, have clearly defined tasks, owners with planned completion time. If a task needs more than one person to collaborate, identify an owner, who will tie-up the loose ends. You will not be able to individually track everything. List the tasks in a google sheets or any tool where people can collaborate
3. Create a virtual room like a hangout meeting, the same link that you used for standup, and let that be active throughout the day. So the hangout link becomes like the virtual room where all of you are present and any random communication is shared osmotically to everyone else. If multiple people needs to discuss on diverse topics simultaneously, they could create another link, finish the discussion and come back to this link. Just like how you physically go to a meeting room, finish the discussion and come back to your place
4. Use communication tools such as Slack, Hangout group, WhatsApp group for cross team communication. You may have two types of communication, one as information for others, the other as specific communication or action item. For the latter, ensure you tag those who need to take action
5. Share everyone’s contact numbers in a common location. Not having this will be a productivity killer. With people working from home, they are open to many distractions and when one team member pings for an info and doesn’t get a response, they should be oriented to call up and check, rather than wait indefinitely losing precious time
6. Ensure business continuity i.e. if you are in that part of the world, where you have power shut downs, invest in a UPS which can take the light load of the router, so that you are continuously connected to your VPN
7. Have a specific place at home where you would work everyday. This will help you mentally to switch on and off, just like office space and home space
8. Take planned breaks and encourage your team members to also take planned breaks. Have specific lunch break timings and end of work timing. The major problem with WFH is indiscipline, we get so much flexibility that we may take fewer breaks or more breaks and have calls planned even during late in the night. Initially it may look productive however eventually you and your team members will burn out and you would start losing productivity
These are just a few points that would help you and your teams to work more productivity considering the prolonged WFH. If you have any more suggestions, do add them in the comments for the benefit of others
Monday, January 29, 2018
9 steps on how to transition a multisite organisation to Agile
Krishna
10:33:00 PM
Here are 9 steps on how to transition a multisite organisation to agile development
Feeling lazy? watch the below 5 min video, rather than reading
1. Identify Agile coaches for each of the deployment centres
They are going to be the torch bearers of Agile, who will train, coach & be the eyes and ears for your Agile deployment. Pick your Agile coaches who have hands-on experience on what you are developing, who understand the local dynamics of the organisation & most importantly those who can influence their peers
2. Understand the existence of Cross Cultural differences
It may be subtle or more prominent but it is something that you should take care off. Cross cultural differences could be in terms of leadership styles, where some center’s maybe used to only command & control style; if so, you will need to put in more work in allaying the leadership concerns in these sites. Further you need to look for the underlying ‘politics’, within and between the sites & handle them appropriately. A big organisational change such as this will affect status-quo
3. Communication
Agile is all about communication. Communication between people and communication between people and code. You may need to set-up two types of meetings
a. Setup a regular Scrum of Scrum meeting, where the teams discuss project related dependency status - start with weekly once or twice and then increase or reduce based on need
b. Setup a regular Agile transition meeting, where the Agile coaches sync up and discuss issues, learnings & solutions. When you start it off, you may need to meet at least once a week and keep tweaking the agreed process or find new ways to handle program level issues. As you progress across sprints, the need for this meeting becomes less frequent
4. Architecture
An architecture that supports feature level ownership cannot be emphasised more. Such an architecture or design will help you vertically slice the product, where the distance between developers & users is at the minimum. However for legacy products this may not be always possible, in such cases evaluate possibilities of complete ownership of a set of features by one centre & another set of features by another centre. You will need a mature agile team & agile practices to have features spread across locations, so when you start out new, look out for clear boundaries
5. Slicing PBIs vertically
Get the teams to understand on how to slice the Product Backlog Items vertically. Since progress is measured through working code, PBI slicing is the key to measure progress. If they aren’t sliced properly, early integration of code will not be possible
6. Identify dependency and acceptance test cases
Identify dependency between PBIs and share acceptance test cases for cross-site dependencies. The acceptance test cases will ensure that the team delivering the dependency is clearly aware of what is expected of their delivery. This will save a lot of effort & bugs for the entire program
7. Single Mainline branch
Work on a single mainline branch where everyone commits code irrespective of the location. The build should always pass on this integrated branch. If your Continuous Integration system isn’t mature enough or doesn’t have automated testing, you can temporarily have a team level scrum branch for each team, which is the mirror of the Main line during start of every sprint. Each of the scrum team develops on this branch and merges the changes on the Mainline, after testing in the latest context, at least once at the end of the Sprint. This though not an optimal approach, will initially help the team to maintain the integrity of the Mainline thus not impacting other teams
8. Joint Sprint Reviews
Have joint sprint reviews. Plan it on the last day of the Sprint & choose a convenient time considering the time difference. During the sprint review, each of the scrum teams, across the centre’s will demonstrate their Sprint output from the same Mainline build. This will ensure that the product is continuously maturing, sprint on sprint
9. Tooling
All the above is only possible through proper cross-site unified tooling - for both project, configuration & build management. There are many free tools available on the internet. Choose and deploy them globally
Monday, July 17, 2017
How to manage org wide change while implementing Agile?
Krishna
1:39:00 AM
So you’re an Agile coach who has been hired to implement organisation wide agile. The organisation has also been hiring SMs & POs. You find that each of them bring their own baggage of agile
Thursday, April 13, 2017
How different is SAFe from SCRUM?
Krishna
1:01:00 AM
A question that change agents often mull over is - should we steer the organisation the Scrum way or the SAFe (Scaled Agile Framework) way. In this short video, I run you through the difference between the two frameworks and which could best suite your organisation
Monday, March 20, 2017
5 Traits to get the best from your (Agile) team
Krishna
11:03:00 PM
Whether you are a Manager or an Agile Scrum Master handling a team, here are 5 traits that can help you get the best from your team
Sunday, February 26, 2017
5 Tips to learn new things quickly
Krishna
10:22:00 PM
Whether one is in school or if one is a professional, the one thing that differentiates ordinary from the extraordinary is the capability for one to learn new things
In this video, I give you 5 tips which will help you learn new things faster
Sunday, February 5, 2017
Does Agile Projects need Project Managers?
Krishna
5:58:00 PM
Through this short video understand whether you need a project manager and if so when you need one in Agile / Scrum projects
Sunday, December 25, 2016
Demonetisation - An Agile Government or an unprepared Government?
Krishna
8:19:00 PM
If you have been following the news on demonetisation in India, you would have heard the opposition blaming the government on the ever changing rules and that things haven’t been thought through. On the other hand, the government defends itself by saying its a cat & mouse game and everything could not have been thought through
In this video, I take you through the changing demonetisation implementation rules where-in you can decide for yourself whether we have an Agile Government or an unprepared Government
Sunday, December 4, 2016
How to prioritise your product backlog in Agile using WSJF method
Krishna
11:36:00 PM
If you are in a dilemma whether to implement a feature which has a high business value and a large implementation time compared to another feature which has a relatively lesser business value but a faster implementation time, then through this short video you will learn on how to prioritise your product backlog using Weighted Shortest Job First method
Sunday, November 13, 2016
How to ensure team commitments are honoured by Agile teams
Krishna
11:04:00 PM
Have you had a situation where the Agile team has agreed on something during the retrospection however as the Sprint progresses, one or two members stop honouring the commitment and eventually the whole team dishonours the commitment?
This short video would give you some insights on how you can handle this situation
Monday, October 24, 2016
Learn how to vertically slice stories or PBIs in Agile
Krishna
4:49:00 PM
One of the most important aspect to successfully realize a Sprint is by splitting the requirements vertically such that they deliver functionality in increments across Sprints
In this video, you will learn the techniques to slice stories/PBIs vertically
Saturday, October 15, 2016
How to do upfront top-down estimation in Agile for project bidding?
Krishna
10:50:00 PM
Sunday, October 2, 2016
Can Agile/Scrum be implemented in non-software projects
Krishna
11:45:00 AM
One of the most asked question is whether Agile / Scrum can be implemented in non-software projects
Here is a brief explanation of how it is implemented in a non-software, non-technical atmosphere
Sunday, September 25, 2016
10 steps to convince your management for change
Krishna
1:59:00 PM
Do you have a bright idea that could change heaven & earth but you're wondering how to convince your superiors?
Here are 10 steps to convince your management for a #change - be it transitioning to #Agile or for a new product idea
Monday, September 5, 2016
Shu Ha Ri - A must know for Agile Adoption
Krishna
2:32:00 AM
If you are a change agent and you are helping an Enterprise or a team to move to Agile, you ought to know this Japanese martial art principle called Shu Ha Ri
Don't like reading? Never mind, instead watch the video!!!
Japanese believed that martial art learning went through three sequential phases called Shu Ha Ri. Martin Fowler & a few other thought leaders redefined this in context of Agile
Shu means following the exact practice that your Master is teaching without any variation - Follow the rule
Ha means realising the principles & theory behind the practice and learning new styles & improvements from other Masters - Adapt & learn new rules
Ri means breaking away from earlier practices and re-inventing your own rules & practices - Be the rule
Lets take the practice of Backlog Refinement meeting of a Scrum team called The TradeBull and see how they transitioned across these phases
In their Shu phase, in the first few Sprints, TradeBull implemented backlog refinement As-Is i.e. they allocated 10% of their current Sprint effort to refine the PBIs for the next set of Sprints and the team & PO discussed and refined the PBIs
TradeBull from their past Sprint experience realised that they couldn’t do justice to the backlog refinement with just 10% of the Sprint effort for backlog refinement. Also, over a date, one of the TradeBull member learnt from his girl friend, who works in a different team that they were inviting the maintenance team for backlog refinements, so as to help deriving maintainability requirements
The next day, he spoke to TradeBull’s maintenance team and learnt that the average fix time needed by the maintenance team which handled field issues of their product was very high. They realised that implementing certain debug logs will improve the average fix time during maintenance
Therefore in the Ha phase, TradeBull decided to modify their practice by
- increasing the time spent in backlog refinement and
- adopting the other teams practice of inviting maintenance team in the backlog refinement meeting
As TradeBull kept progressing in the Sprints, the Maintenance team was elated because their average fix time had reduced & Customer’s were happy
Currently the lead time by when the logs were implemented & the software released to Customer was 1 Sprint + 1 week i.e. maintenance team gave requirements in the current Sprint’s backlog refinement meeting, which was taken in the next Sprint for implementation & release
The Maintenance team discussed with TradeBull and asked if they can give requirements for the running Sprint itself based on their daily analysis of issues. The TradeBull team considered this request & in the interest of the Customer decided to go ahead and accept the requirements in the same sprint
So in the Ri phase, TradeBull team decided to have their own rules
- They will accept requirement inputs from Maintenance team in two phases for the running Sprint - one before Sprint Planning meeting & the other during backlog refinement
- To advance the backlog refinement meeting to the middle of their Sprint
- In their current Sprint, they would allocate 3% of buffer to accommodate debug log requirement which comes during refinement meeting and
- Continue with their existing practice of refining PBIs for their subsequent Sprints
Thus Maintenance team had the additional window to squeeze in any important requirements they came across between the start of Sprint & backlog refinement meeting
You can thus see, how TradeBull sequentially went through each of the phases
A word of caution, many a times, I have observed teams attempting to skip the Shu & the Ha phase and directly go to the Ri phase. They go ahead with a lot of Scrum-Buts & eventually fail.
Therefore as a Change Agent, it is imperative that you ensure that the team goes through these phases & only advance to the Ri phase when they have understood the principles and sprit behind the practice
Sunday, August 28, 2016
10 reasons why Agile projects fail
Krishna
2:12:00 AM
As important as it is to understand Agile, it is also important for us to understand why Agile fails
Is Agile the only sole saviour for software development?
Surely no, however if you have decided to implement Agile or are implementing Agile, it is imperative you familiarise with the top reasons for Agile failures so that you can lookout for these signs in your organisation
Don't like reading? Watch the video on why Agile fails!!!
1. Following Agile for Novelty sake
Following Agile for Novelty’s sake . This may sound weird or almost unbelievable but it is a fact. Either a Project or the Organisation may have decided to move to Agile because everyone else in the industry is using Agile & the term “agility” may give them some brownie points in contracts
2. Management not fully aware or committed to the change
Becoming Agile is not just about fancy name changes to Scrum Master or Product Owner or Sprint, etc. The investment goes beyond that and includes cultural transformation, e2e change in the s/w development flow, changes in HR practices & a lot more, Management may have committed to go Agile without being fully aware or committed to these changes
3. Mandated by Higher Management to employees
On the other extreme, is an over zealous Management which may have mandated teams to move to Agile without ensuring teams buy-in. Agile thrives in an atmosphere of trust & teams wanting to inspect & adapt to improve the product & processes. With a non-buy-in team, teams could actually work against agile!
4. Not ready for the Learning curve
When an organisation decides to adopt Agile from a traditional development methodology, they choose to transform rather than transition. This has a steep learning curve and they may not be ready to embrace the short-term impact
5. Don’t have budget to train & coach
A need for successful transformation is to have a subject matter expert focussing on ensuring that everyone understands and implements the practices by spirit. The Organisation may not consider the budget to train employees or allocate a coach and expect each team to figure-out agile for themselves, while this may work for some team, for many it fails
6. ‘Agile like’ practices
Something not very uncommon are organisations having agile like practices & defending that it can be mapped to Agile practices. While this maybe true, however we are not doing a gap-analysis for an ISO audit or a CMMI appraisal. More likely than not, the practices can be ‘mapped’ only on paper and not on intent on how it was implemented
7. Lack of automation
While Scrum doesn't explicitly talk about automation, in order to scale, it is implicit that one needs to invest in automation & Extreme Programming practices can help here. Not investing in automation of repeated activities & test cases will increase the project effort exponentially as we move from one sprint to the other; this will eventually increase validation effort and the project would start compromising on quality
8. Not handling technical debt
Not handling technical debt is another cause for Agile failures. A project with a large base code implementing Agile without a roadmap to improve the code quality would pretty soon end-up with a deluge of bugs and blame Agile - for exposing them!
9. One size fits for all
Expecting one size fits for all. This unknowingly stifle teams from ‘inspect & adapt’ of the project process by enforcing organisation level processes expecting that ‘one size fits for all’
10. Dependency with External non-Agile Teams
Dependency with External non-Agile Teams can be another cause for failures. If you have large dependencies with external teams who do not follow agile, it will be an uphill task to expect intermediate good quality delivery from them for integration & test. This may eventually defeat the purpose of your Sprint releases as you may not be able to validate in the product context
These are some of the causes why agile fails. If you have come across other reasons, do leave them in the comment section
Monday, August 15, 2016
Know all about Sprint Review & Sprint Retrospection under 5 minutes
Krishna
1:44:00 AM
In this video blog, you will understand
+ What happens in a Sprint Review & Sprint Retrospection in Scrum
+ How should you conduct it practically
+ What are the things to be taken care off
Sunday, August 7, 2016
Know all about what happens within a Sprint in SCRUM
Krishna
11:47:00 PM
Understand from a first person account on
+ what practically happens inside a Sprint
+ what is the format for a standup meeting
+ how burndown chart works
+ what happens in backlog refinement
Monday, August 1, 2016
Know all about Sprint Planning and Agile Estimation under 6 minutes
Krishna
12:02:00 AM
- what preparation need to be done before Sprint planning meeting
- how to conduct the Sprint planning meeting
- how to do Agile estimation - effort based and story point based
Social Counter