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

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

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

Thursday, April 13, 2017

How different is SAFe from SCRUM?

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

Sunday, February 26, 2017

Sunday, February 5, 2017

Sunday, December 25, 2016

Demonetisation - An Agile Government or an unprepared Government?

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

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

Monday, October 24, 2016

Saturday, October 15, 2016

Sunday, October 2, 2016

Sunday, September 25, 2016

Monday, September 5, 2016

Shu Ha Ri - A must know for Agile Adoption

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

  1. increasing the time spent in backlog refinement and
  2. 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


  1. 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
  2. To advance the backlog refinement meeting to the middle of their Sprint
  3. In their current Sprint, they would allocate 3% of buffer to accommodate debug log requirement which comes during refinement meeting and
  4. 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

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

Sunday, August 7, 2016

Monday, August 1, 2016

Powered by Blogger.

Featured Post

Know all about GST in India under 8 minutes

In this video blog, you will understand all about What is Goods & Services Tax (GST) in India How are the indirect taxes affecti...

Recent

recentposts

Random

randomposts
satta king tw